[{"content":"Die Lizenz steckt schon in der Firmware Viele Leute besitzen eine Lizenz für das Fisher-Price OS (Windows), ohne je ihren Produktschlüssel gesehen zu haben. Sie kam mit der Maschine, und der Schlüssel lebt in der Firmware dieser Maschine, in einer kleinen ACPI-Tabelle namens MSDM.\nDann ist die Maschine nicht mehr der Ort, an dem die Arbeit passiert. Entweder will ihr Besitzer diese Lizenz in einer VM, die er jetzt bei dir mietet, oder die Maschine selbst wird gelöscht, zu einem Proxmox-Host gemacht, und die Kopie des Betriebssystems, mit der sie ausgeliefert wurde, soll als VM obendrauf zurück.\nTechnisch ist es eine QEMU-Option. Genau das ist das Problem. QEMU reicht jede Tabelle ungeprüft an einen Gast weiter, der Gast aktiviert mit dem Schlüssel, den er findet, und nirgends im ganzen Stapel fragt irgendetwas, ob die Lizenz das alles erlaubt. Dieser Beitrag behandelt, was die Tabelle ist, wie man sie in eine VM bringt, ohne eine kaputte weiterzureichen, was Microsofts Bedingungen über den Umzug sagen, und warum eine Volumenlizenz nie in ihre Nähe kommt.\nWas die Tabelle ist Seit OEM Activation 3.0 druckt ein PC-Hersteller den Schlüssel nicht mehr auf einen Aufkleber unten am Gehäuse, wo jeder mit einer Handykamera ihn abschreiben kann, sondern der Schlüssel kommt stattdessen in die Firmware der Maschine. Microsofts Fabrikwerkzeug „injects the product keys into the firmware“, und sein Prüfschritt kontrolliert, „that the MSDM table exists“ und dass Header und Einträge „comply with the correct formats“1. Eine so eingerichtete Maschine ist „activated by using the OA3 DPK in the firmware“2. MSDM ist eine gewöhnliche ACPI-Tabelle, und unter Linux liest man sie direkt aus der Firmware:\nsudo cat /sys/firmware/acpi/tables/MSDM \u0026gt; msdm.bin Der Laptop, auf dem dieser Text geschrieben wurde, trägt eine. 85 Byte.\nMicrosofts veröffentlichte Spezifikation definiert den üblichen ACPI-Header mit 36 Byte und der Signatur MSDM, und hört dann auf. Alles nach dem Header ist eine „Proprietary data structure that contains all the licensing data necessary to enable Windows activation“3.\nByte Enthält Bekannt aus 0 bis 35 der übliche ACPI-Header: Signatur MSDM, Länge, Prüfsumme, OEM-ID Microsofts Spezifikation 36 bis 55 20 Byte an Feldern: Version, Datentyp, Datenlänge echte Tabellen, keine veröffentlichte Spezifikation 56 bis 84 der Produktschlüssel mit 29 Zeichen, fünf Gruppen zu fünf echte Tabellen, keine veröffentlichte Spezifikation QEMU reicht alles weiter, was du ihm gibst -acpitable file= in QEMU nimmt die „whole ACPI table from the specified files, including all ACPI headers (possible overridden by other options)“4, und der Gast sieht dann eine MSDM-Tabelle genau so, wie die Firmware eines Laptops sie präsentieren würde. Das wurde mit einem absichtlich gefälschten Schlüssel geprüft. Die Byte kamen auf der anderen Seite identisch heraus, von der Signatur bis zum letzten Zeichen.\nQEMU lehnt nichts ab. Das macht hw/acpi/core.c mit einem kaputten Upload5:\nWas an der Datei falsch ist Was QEMU tut Was der Gast sieht Länge im Header passt nicht zur Datei warnt, dann überschreibt es die Länge mit der echten Größe einen gültigen Header Prüfsumme ergibt nicht null rechnet sie neu, bei jeder Tabelle, jedes Mal eine gültige Prüfsumme Schlüssel abgeschnitten oder verstümmelt nichts, die Daten nach dem Header gehen es nichts an eine gültig aussehende Tabelle um einen kaputten Schlüssel Der Gast kann den Unterschied nicht erkennen, und du auch nicht, bis jemand ein Support-Ticket aufmacht. Das Erste, was man davon hört, ist ein Kunde, dessen Aktivierung fehlgeschlagen ist.\nWenn Kunden diese Tabellen also hochladen, prüf sie, bevor QEMU sie je zu sehen bekommt:\n#!/usr/bin/env python3 \u0026#34;\u0026#34;\u0026#34;Refuse anything that is not a well-formed MSDM table before QEMU sees it.\u0026#34;\u0026#34;\u0026#34; import re, struct, sys t = open(sys.argv[1], \u0026#39;rb\u0026#39;).read() fail = lambda why: sys.exit(f\u0026#34;{sys.argv[1]}: {why}\u0026#34;) if len(t) \u0026lt; 56: fail(f\u0026#34;{len(t)} bytes, too short for an MSDM table\u0026#34;) sig, length = t[:4], struct.unpack_from(\u0026#39;\u0026lt;I\u0026#39;, t, 4)[0] if sig != b\u0026#39;MSDM\u0026#39;: fail(f\u0026#34;signature is {sig!r}, not MSDM\u0026#34;) if length != len(t): fail(f\u0026#34;header says {length} bytes, file is {len(t)}\u0026#34;) if sum(t) \u0026amp; 0xff: fail(\u0026#34;checksum does not sum to zero\u0026#34;) ver, _, dtype, _, dlen = struct.unpack_from(\u0026#39;\u0026lt;5I\u0026#39;, t, 36) if (ver, dtype) != (1, 1): fail(f\u0026#34;version {ver}, data type {dtype}: expected 1 and 1\u0026#34;) if dlen != 29 or 56 + dlen != length: fail(f\u0026#34;data length {dlen}: expected 29\u0026#34;) key = t[56:].decode(\u0026#39;ascii\u0026#39;, \u0026#39;replace\u0026#39;) if not re.fullmatch(r\u0026#39;([0-9A-Z]{5}-){4}[0-9A-Z]{5}\u0026#39;, key): fail(\u0026#34;data is not a 5x5 product key\u0026#34;) print(f\u0026#34;OK OEM {t[10:16].decode(errors=\u0026#39;replace\u0026#39;).strip()!r} key *****-*****-*****-*****-{key[-5:]}\u0026#34;) Prüft Misst die Datei an Ein Fehlschlag heißt Signatur, Länge, Prüfsumme Microsofts dokumentiertem Header die Datei ist kaputt Version, Datentyp, Datenlänge, Form des Schlüssels der Form, die echte Tabellen haben sieh dir diese von Hand an, nicht „die ist gefälscht“ Er gibt nie den Schlüssel aus, nur die letzte Gruppe. Ein Produktschlüssel in einer Logdatei ist ein Produktschlüssel, den jemand anderes benutzen kann.\nGegen eine gute Tabelle und drei kaputte Kopien davon laufen gelassen:\nOK OEM \u0026#39;EXMPLE\u0026#39; key *****-*****-*****-*****-EEEEE bad-sum.bin: checksum does not sum to zero bad-trunc.bin: header says 85 bytes, file is 70 bad-sig.bin: signature is b\u0026#39;SLIC\u0026#39;, not MSDM Wo sie hinkommt, und wer sie dort hinlegen darf Vom Upload des Kunden bis zum Schlüssel, mit dem der Gast aktiviert Tabelle des Kunden msdm.bin, 85 Byte von seiner Maschine Validator Signatur, Länge, Prüfsumme, Schlüssel Abgelegt /etc/pve/priv/ nur root, jeder Knoten VM-args -acpitable file= nur root setzt es QEMU schreibt die Länge um, rechnet die Prüfsumme, lehnt nichts ab Gast MSDM in ACPI, Aktivierung liest Schlüssel Der Validator sitzt vor QEMU, weil QEMU einen kaputten Header zurechtbiegt, statt ihn abzulehnen. Die Tabelle lebt in der privaten Hälfte des Cluster-Dateisystems, sie folgt der VM also auf jeden Knoten, und nur root kann sie lesen. Ein Produktschlüssel ist ein Geheimnis. Er gehört nirgends hin, wo www-data ihn lesen kann, und pmxcfs gibt dir in /etc/pve genau einen Ort, an dem das nicht geht6:\nWo die Tabelle liegen könnte Wer sie lesen kann Auf jedem Knoten, auf den die VM migrieren kann /etc/pve/priv nur root ja irgendwo sonst in /etc/pve für die Gruppe lesbar, www-data der Weboberfläche eingeschlossen ja ein Verzeichnis auf einem Knoten was immer du einstellst nein Mit 85 Byte ist sie nirgends in der Nähe der Dateigrenze von 1 MiB in pmxcfs7:\nmkdir -p /etc/pve/priv/msdm check-msdm.py upload.bin \u0026amp;\u0026amp; cp upload.bin /etc/pve/priv/msdm/9000.bin qm set 9000 --args \u0026#34;-acpitable file=/etc/pve/priv/msdm/9000.bin\u0026#34; qm set --args ersetzt die ganze Zeile. Trägt die VM schon SMBIOS- oder Firmware-Optionen in args, schreib sie alle zusammen aus. Und weil args nur root setzen darf, ist das eine Aufgabe für deine Provisionierung, nichts, was ein Kunde aus der Weboberfläche tun kann. So herum ist es richtig. Der Kunde liefert die Datei, deine Werkzeuge prüfen sie und hängen sie an.\nDie Tabelle bewegt einen Schlüssel, kein Recht Hier braucht die Funktion einen klaren Kopf. Die MSDM-Tabelle in eine VM zu bringen bewegt den Schlüssel. Nicht die Lizenz.\nMicrosofts eigene Bedingungen sagen das, und die Zeilen, auf die es ankommt, passen in eine Tabelle:\nFall Was Microsoft sagt Quelle OEM-Lizenz, Umzug an einen anderen Nutzer übertragbar „only with the licensed device“ OEM-Lizenzbedingungen8 OEM-Lizenz, wie viele Installationen „only one instance of the software for use on one device, whether that device is physical or virtual“ OEM-Lizenzbedingungen8 OEM-Lizenz, in einfachen Worten „locked“ an den ursprünglichen PC „and cannot be transferred to any other PC“ Microsofts Blog für kleine Unternehmen9 Die Ausnahme die Übertragungsbestimmungen „do not apply“, wenn die Software in Deutschland oder einem von mehreren anderen Ländern erworben wurde OEM-Lizenzbedingungen8 Für Kunden hosten das Services Provider License Agreement ist für „hosted applications to end customers“ SPLA10 Desktop-Editionen als gehostete VMs „VMs must be hosted by a Qualified Multitenant Hoster (QMTH)“ Microsoft Learn11 Die Tabelle kommt immer von der eigenen lizenzierten Maschine des Kunden, nie von deinen Hosts. Der Fall, der klar innerhalb des Wortlauts liegt, ist der einfachste: die Maschine, mit der die Lizenz verkauft wurde, jetzt mit Proxmox, und dieselbe Kopie des Fisher-Price OS (Windows) in eine einzige VM darauf umgezogen. Das ist immer noch eine Instanz auf einem Gerät, und die OEM-Bedingungen erlauben das „whether that device is physical or virtual“8. Eine zweite VM, oder eine andere Maschine, und es ist das nicht mehr.\nIn diesem einen Fall sind die Maschine des Kunden und der Hypervisor dieselbe Kiste, es gibt also nichts hochzuladen und nichts zu kopieren. Der Proxmox-Kernel legt die MSDM-Tabelle der Firmware schon unter /sys/firmware/acpi/tables/ offen, nur für root lesbar, und QEMU läuft unter Proxmox als root, kann die Tabelle also direkt von dort nehmen:\nqm set 100 --args \u0026#34;-acpitable file=/sys/firmware/acpi/tables/MSDM\u0026#34; Auf die Live-Tabelle zu zeigen statt auf eine Kopie hat zwei Folgen. Der Pfad wird auf dem Knoten gelesen, auf dem die VM startet, das gehört also auf einen einzelnen Host und nicht in einen Cluster: Migrierst du die VM, bekommt sie entweder die Tabelle dieses Knotens, eine andere Lizenz auf einer anderen Maschine, oder sie startet gar nicht, weil QEMU eine fehlende Datei mit can't open file … No such file or directory ablehnt. Und es ist eine Zeile, also ist es eine Zeile, die man in eine zweite VM einfügen kann. Diese zweite VM ist der Fall, den die Bedingungen nicht abdecken, also bekommt eine VM es und keine andere.\nBau die Funktion also. Der Mechanismus ist solide, und es gibt Kunden, die ihn nutzen dürfen; einer, der seine Lizenz in Deutschland gekauft hat, kann durchaus darunter sein. Aber leg die Berechtigung dorthin, wo sie hingehört: in deine Nutzungsbedingungen. Der Kunde sichert zu, dass er eine Lizenz hat, die den Betrieb in deiner VM abdeckt, und er tut das, bevor der Upload-Knopf irgendetwas tut. Der Validator beweist, dass die Tabelle wohlgeformt ist. Nichts beweist, dass er sie benutzen darf.\nVolumenlizenzen kommen nie in die Nähe der Tabelle Kann ein Kunde mit einer Volumenlizenz denselben Weg nehmen? Nein. Es gibt nichts, was die Tabelle tragen könnte.\nMSDM gehört zum OEM-Kanal und sonst nirgends hin. Microsofts eigener Planungsleitfaden sagt, OEM-Aktivierung „is available only for computers that are purchased through OEM channels and have the Windows operating system preinstalled“12. Volumenlizenzen aktivieren über eines von drei anderen Modellen, „Multiple Activation Keys (MAK)“, „KMS“ und „Active Directory-based activation“12, und bei jedem davon wird der Schlüssel im Betriebssystem installiert. Nichts liest ihn aus der Firmware.\nMethode Wo der Schlüssel lebt Mit wem der Gast spricht In einer Proxmox-VM OEM, OA 3.0 die MSDM-Tabelle in der Firmware Microsofts Aktivierungsserver der Weg über -acpitable oben MAK im Gast installiert Microsoft, einmal, gezählt gegen die Aktivierungen des Schlüssels geht mit Internetzugang oder per Telefon KMS ein generischer Schlüssel (GVLK) im Gast der KMS-Host des Kunden auf TCP 1688 braucht eine Route dorthin, und 25 Clients oder 5 Server, bevor er irgendetwas aktiviert Active Directory ein GVLK im Gast die Domänencontroller des Kunden, mindestens alle 180 Tage braucht die VM in seiner Domäne AVMA ein generischer Schlüssel im Gast die eigene Datacenter-Lizenz des Hyper-V-Hosts gar nicht verfügbar Für einen Volumenkunden gibt es auf dem Hypervisor also nichts zu bauen. Sein Schlüssel kommt in sein Image, und dein Teil ist der Netzwerkpfad: Port 1688 zu seinem KMS-Host, oder ein VPN zu seinen Domänencontrollern. Der MSDM-Platz bleibt leer, und so soll es sein.\nZwei Dinge erwischen die Leute. Der generische Schlüssel auf Volumenmedien aktiviert für sich allein nichts, denn „the GVLK doesn\u0026rsquo;t work unless a valid KMS host key can be found“12, eine VM, die aus dem Enterprise-ISO des Kunden ohne Route nach Hause gebaut wurde, bleibt also unaktiviert. Und eine Desktop-Volumenlizenz ist für sich allein keine Lizenz. Volumenprogramme „cover upgrades to Windows client operating systems only“, und „an existing retail or OEM operating system license is needed for each computer“12. Die Volumenlizenz sitzt auf einer Basislizenz, sehr oft derselben OEM-Lizenz, um die es im letzten Abschnitt ging, und ob sie in deiner VM laufen darf, ist immer noch die Hosting-Frage aus dieser Tabelle, keine Aktivierungsfrage.\nAVMA verdient eine eigene Zeile, weil es so aussieht, als wäre es die Antwort. Es ist Microsofts Weg, wie ein Host seine eigenen Server-Gäste aktiviert, indem er „the VM activation to the licensed virtualization host“ bindet, und es verlangt „a Windows Server Datacenter edition with the Hyper-V server host role installed“13. Microsoft sind beim Rest deutlich: „AVMA doesn\u0026rsquo;t work with other server virtualization technologies“13. Unter Proxmox aktivieren Server-Gäste über deine SPLA-Schlüssel oder über den eigenen KMS des Kunden.\nNichts im Stapel prüft die Papiere Jede Schicht hier tut ihre Arbeit und nichts darüber hinaus. Die Firmware speichert einen Schlüssel. QEMU kopiert die Byte und räumt den Header auf. Der Gast liest den Schlüssel und aktiviert damit. Keine davon kann sagen, ob die Maschine darunter die ist, mit der die Lizenz verkauft wurde, und keine davon sollte das je können.\nDie Prüfung landet also bei dem, der den Hypervisor betreibt. Eine Lizenz ist eine Vereinbarung zwischen dem, der sie gekauft hat, und Microsoft, und deine Plattform ist keine Partei davon, aber sie ist das, was den Schlüssel bewegt, und das macht die Frage zu deiner, ob du sie haben wolltest oder nicht.\nSchreib die Antwort auf, bevor der Upload-Knopf irgendetwas tut. Eine Maschine, eine VM, die eigene Lizenz des Kunden und sein Wort, dass sie das abdeckt. Kostet nix, und es schützt dich genauso wie ihn. Die Software bewegt jeden Schlüssel, den man ihr gibt. Ob sie das hätte tun sollen, ist eine Frage, die nur ein Mensch beantworten kann, also sorg dafür, dass einer es tut.\nMicrosoft Learn, OA 3.0 on the factory floor — „injects the product keys into the firmware“; /Validate prüft, „that the MSDM table exists“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMicrosoft Learn, Validate an OEM Activation key — „is activated by using the OA3 DPK in the firmware“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMicrosoft, Microsoft Software Licensing Tables (SLIC and MSDM) — Tabelle 2, Offset 36: „Proprietary data structure that contains all the licensing data necessary to enable Windows activation.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nQEMU, System Emulation, Invocation — -smbios-Felder pro Typ; -acpitable „For file=, take whole ACPI table from the specified files, including all ACPI headers“; -boot „Currently Seabios for X86 system support it.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nQEMU v11.0.3, hw/acpi/core.c — „ACPI table has wrong length“ ist ein warn_report, danach wird die Länge überschrieben und die Prüfsumme neu berechnet.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\npve-cluster, src/pmxcfs/pmxcfs.c — Pfade unter priv werden auf 0777700 maskiert, alles andere auf 0777750.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\npve-cluster, src/pmxcfs/memdb.h — #define MEMDB_MAX_FILE_SIZE (1024 * 1024) // 1 MiB.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMicrosoft, Windows 11 OEM licence terms — „you may transfer the license to use the software directly to another user, only with the licensed device“; die Übertragungsbestimmungen „do not apply if you acquired the software in Germany“ oder in den aufgeführten Ländern. Archivierte Kopie; die Live-Seite verweigert automatisierte Anfragen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMicrosoft, small business blog archive — „the OEM Windows license is \u0026rsquo;locked\u0026rsquo; to the original PC it comes with and cannot be transferred to any other PC.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMicrosoft, Services Provider License Agreement — „for service providers and software development companies licensing eligible Microsoft products to provide software services and hosted applications to end customers.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMicrosoft Learn, Windows subscription activation for VDA — „VMs must be hosted by a Qualified Multitenant Hoster (QMTH).“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMicrosoft Learn, Plan for volume activation — die drei Modelle der Volumenaktivierung; die KMS-Schwellen von „at least five computers“ für Server und „at least 25 computers“ für Clients, auf TCP-Port 1688; Active Directory-based Activation braucht die Domäne „at least once every 180 days“; „the GVLK doesn\u0026rsquo;t work unless a valid KMS host key can be found“; Volumenlizenzen „cover upgrades to Windows client operating systems only“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMicrosoft Learn, Automatic Virtual Machine Activation in Windows Server — „AVMA requires a Windows Server Datacenter edition with the Hyper-V server host role installed“; „AVMA doesn\u0026rsquo;t work with other server virtualization technologies.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://blogs.damiendye.uk/de/proxmox/moving-an-oem-licence-into-a-proxmox-vm/","summary":"Eine OEM-Lizenz für das Fisher-Price OS (Windows) lebt in der Firmware des PCs als ACPI-Tabelle namens MSDM, und QEMU reicht jede solche Tabelle ungeprüft an einen Gast weiter. Dieser Beitrag behandelt, was die Tabelle enthält, einen Validator, der fehlerhafte Tabellen ablehnt, bevor QEMU still ihre Header repariert, ihre Ablage in der privaten Hälfte des Cluster-Dateisystems von Proxmox, Microsofts Bedingungen für den Umzug einer OEM-Lizenz, den einen Fall, den sie klar erlauben, die Tabelle direkt vom Host zu nehmen, wenn die lizenzierte Maschine der Hypervisor ist, und warum MAK, KMS, Active Directory und AVMA die Tabelle nie berühren.","title":"Eine OEM-Lizenz in eine Proxmox-VM bringen, und was dabei mitwandert"},{"content":"Was dein Kunde sieht, wenn deine VM bootet Du verkaufst virtuelle Maschinen unter deinem eigenen Namen. Ein Kunde schaltet eine ein, und das Erste auf dem Bildschirm ist das Logo von jemand anderem.\nDas ist eine Standard-VM unter Proxmox. Nichts ist kaputt, und Proxmox machen nichts falsch: Es ist ihr Produkt und ihr Name, sie haben die Firmware und die Oberfläche geschrieben, in der er erscheint, und sie dürfen ihn dort hinsetzen, so wie ein Serverhersteller sein Abzeichen vorn auf das Gehäuse setzt. Es ist nur eben nicht deins.\nDas Logo ist erst der Anfang. So meldet sich ein UEFI-Gast mit der aktuellen Firmware von Proxmox, pve-edk2-firmware 4.2026.08-1, aus dem Gast heraus mit dmidecode gelesen:\nWo der Gast nachsieht Was er liest Wessen Name Bootbildschirm das Logo von Proxmox Proxmox Firmware-Hersteller (SMBIOS-Typ 0) Proxmox distribution of EDK II Proxmox Firmware-Version 4.2026.08-1 die Paketversion von Proxmox Systemhersteller (Typ 1) QEMU QEMU Produktname (Typ 1) Standard PC (Q35 + ICH9, 2009) QEMU Gehäusehersteller (Typ 3) QEMU QEMU Mainboard (Typ 2) gar nicht vorhanden niemandes Web-Verwaltungsoberfläche das Logo von Proxmox, oben links Proxmox Beim Bootlogo hört es auch nicht an der Firmware auf. UEFI-Firmware gibt das Bild, das sie gezeichnet hat, über eine ACPI-Tabelle namens BGRT, die Boot Graphics Resource Table, an das Betriebssystem weiter. Die Tabelle existiert, um zu sagen „an image was drawn on the screen during boot“1, und das Betriebssystem zeichnet es dann auf seinem eigenen Bootbildschirm noch einmal. Das Fisher-Price OS (Windows) setzt es über seinen Kreisel, und Microsoft nennt die BGRT „the standard interface that Windows uses to access the logo“2. Das Standard-Theme von Plymouth bei Fedora macht unter Linux dasselbe3. Ein Gast auf der Firmware von Proxmox zeigt das Logo von Proxmox also zweimal, bevor sich überhaupt jemand angemeldet hat.\nNichts davon ist schwer zu ändern. Es geändert zu lassen schon. Das nächste apt full-upgrade stellt still die Hälfte davon wieder her, und die Hälfte, die es nicht wiederherstellt, ist die, die dir Sorgen machen sollte. Um die geht es in diesem Beitrag vor allem.\nWo jedes Stück Branding in den Boot kommt Einschalten QEMU baut SMBIOS und ACPI aus der Konfig Firmware OVMF zeichnet sein Logo, SeaBIOS einen Splash Übergabe SMBIOS-Tabellen, ACPI mit BGRT und MSDM OS-Bootbildschirm zeichnet das Firmware-Logo aus der BGRT neu Laufender Gast liest die Strings, die Aktivierung liest den MSDM-Schlüssel VM-Konfig Paketdatei VM-Konfig Paketdatei VM-Konfig liegt in /etc/pve, übersteht jedes Upgrade liegt unter /usr/share, apt ersetzt sie Branding kommt an fünf Stellen in den Bootvorgang. Drei davon stammen aus der eigenen Konfiguration der VM und überstehen alles, was apt tut. Zwei kommen aus Dateien, die einem Proxmox-Paket gehören, und die holt sich ein Upgrade zurück. Die MSDM-Tabelle in dieser Übergabe ist überhaupt kein Branding. Sie trägt einen Lizenzschlüssel, und wie man einen in eine VM bringt, hat einen eigenen Beitrag: Eine OEM-Lizenz in eine Proxmox-VM bringen.\nAlles unter /usr/share gehört apt Eine Regel entscheidet jede Wahl weiter unten. Eine Datei, die ein Paket installiert hat, ist die Datei des Pakets. Ändere sie an Ort und Stelle, und das nächste Upgrade dieses Pakets überschreibt deine Änderung ohne ein Wort, denn aus Sicht von dpkg legt es nur seine eigene Datei dorthin zurück, wo es sie gelassen hat.\nJedes Stück Branding muss also irgendwo leben, das apt nicht gehört. Ein Proxmox-Knoten hat drei solche Orte, und jeder kostet etwas anderes:\nWo es lebt Wie es dorthin kommt Übersteht ein Upgrade Was es dich kostet Die VM-Konfiguration in /etc/pve smbios1, und args für alles andere Ja, Konfiguration fasst kein Paket an args darf nur root setzen, und es erscheint nicht in der GUI Eine Datei, die dpkg in Ruhe lassen soll dpkg-divert Ja, die Kopie des Pakets landet stattdessen unter einem .distrib-Namen Upgrades erreichen die Datei nicht mehr, und das zählt, wenn die Datei Firmware ist Dein eigenes Verzeichnis, außerhalb des Paketbaums /usr/local, aus args referenziert Ja, kein Paket besitzt es Du musst es selbst auf jeden Knoten bringen Debians eigene Beschreibung einer Umleitung ist die klarste: „a way of forcing dpkg not to install a file into its location, but to a diverted location“4. Das deckt die Weboberfläche ab. Für die Firmware ist es eine von zwei Möglichkeiten, und die gefährlichere.\nDas Gehäuse ist eine Handvoll Strings und eine Rechteprüfung SMBIOS ist die Tabelle, mit der eine Maschine sich selbst beschreibt: wer sie gebaut hat, welches Modell sie ist, ihre Seriennummer, was Mainboard und Gehäuse sind5. dmidecode liest sie, jedes Inventarisierungswerkzeug, das du je auf ein Netz losgelassen hast, liest sie, die Systeminformation des Fisher-Price OS (Windows) liest sie, und die meisten Lizenzprüfungen, die entscheiden, ob eine Software auf einer bestimmten Maschine überhaupt läuft, lesen sie auch. Bei einer VM schreibt QEMU sie. Daher QEMU und Standard PC in der Tabelle oben.\nTyp 1 über smbios1 Proxmox legt eine einzige SMBIOS-Struktur in der VM-Konfiguration offen: Typ 1, System Information, als smbios16. Sie nimmt manufacturer, product, version, serial, sku, family und uuid.\nDer Haken steckt in qemu-server, nicht in der Doku. Jedes Feld außer uuid muss auf ein Base64-Muster passen, [A-Za-z0-9+\\/]+={0,2}, ein einfacher Wert mit einem Leerzeichen darin wird also glatt abgelehnt. Echte Strings werden Base64-kodiert und mit base64=1 markiert, und qemu-server dekodiert sie wieder, bevor es die QEMU-Befehlszeile baut7. Der SMBIOS-Editor der GUI macht das bei jedem Speichern, mit dem Kommentar „smbios values can be arbitrary, so encode and mark config as such“8. Auf der Kommandozeile ist es deine Aufgabe:\nb() { printf %s \u0026#34;$1\u0026#34; | base64 -w0; } qm set 9000 --smbios1 \u0026#34;uuid=$(qm config 9000 | sed -n \u0026#39;s/.*uuid=\\([0-9a-f-]*\\).*/\\1/p\u0026#39;),base64=1,\\ manufacturer=$(b \u0026#39;Example Cloud Ltd\u0026#39;),product=$(b \u0026#39;EC Compute Instance\u0026#39;),\\ version=$(b \u0026#39;2026.10\u0026#39;),family=$(b \u0026#39;General Purpose\u0026#39;),sku=$(b \u0026#39;ec-gp-4c16g\u0026#39;)\u0026#34; Beachte, dass die uuid wieder mit hineinkommt. Sie ist die Maschinenidentität des Gasts, und was du an --smbios1 übergibst, wird als ganze Option gespeichert, also lies sie vorher aus und behalte sie.\nBrande die Vorlage, nicht jede einzelne VM. Ein Klon unter Proxmox bekommt eine frisch erzeugte UUID und behält jedes andere smbios1-Feld, jeder Klon kommt also mit eigener Identität und deinen Strings heraus9, mit einer Ausnahme, siehe unten.\nTypen 0, 2, 3 und 11 über args smbios1 endet bei Typ 1. Firmware-Hersteller, Mainboard, Gehäuse und die OEM-Strings laufen alle über args, die Zeile, die Proxmox direkt an QEMU weiterreicht und die seine eigene Dokumentation „for experts only“ nennt6. Die QEMU-Option -smbios nimmt die Felder für jeden Typ10:\nargs: -smbios \u0026#39;type=0,vendor=Example Cloud Ltd,version=EC-FW 1.0,date=10/04/2026,uefi=on\u0026#39; -smbios \u0026#39;type=2,manufacturer=Example Cloud Ltd,product=EC Virtual Board,version=1.0\u0026#39; -smbios \u0026#39;type=3,manufacturer=Example Cloud Ltd,version=1.0,asset=EC-ASSET-123,sku=ec-gp\u0026#39; -smbios \u0026#39;type=11,value=example-cloud:instance=123\u0026#39; Mit diesen Zeilen auf QEMU gebootet, liest dmidecode im Gast:\nStruktur Feld Standard Gebrandet Typ 0 Vendor Proxmox distribution of EDK II Example Cloud Ltd Typ 0 Version 4.2026.08-1 EC-FW 1.0 Typ 1 Manufacturer QEMU Example Cloud Ltd Typ 1 Product Name Standard PC (Q35 + ICH9, 2009) EC Compute Instance Typ 1 Family nicht angegeben General Purpose Typ 2 Manufacturer Struktur fehlt Example Cloud Ltd Typ 2 Product Name Struktur fehlt EC Virtual Board Typ 3 Manufacturer QEMU Example Cloud Ltd Typ 3 Asset Tag nicht angegeben EC-ASSET-123 Typ 11 String 1 Struktur fehlt example-cloud:instance=123 Unterwegs sind vier Fallen aufgetaucht. Alle vier sind still.\nWer Typ 0 liefert, verliert „UEFI is supported“. OVMF schreibt seinen eigenen Typ 0 nur, wenn QEMU keinen geliefert hat; die Schleife, die durch die Tabellen von QEMU läuft, setzt NeedSmbiosType0 = FALSE, sobald sie auf einen Typ 0 trifft11. Dein Herstellerstring ersetzt den von Proxmox, und genau darum geht es. Aber der Typ 0 von QEMU ersetzt auch die Firmware-Eigenschaften von OVMF, und ohne uefi=on verschwindet die Zeile „UEFI is supported“ aus dmidecode. Hol sie mit uefi=on zurück. Für UEFI-Gäste gibt es für den Herstellerstring ohnehin ein besseres Zuhause, in der Firmware selbst, weiter unten.\nDer Gehäusetyp lässt sich nicht setzen. Der Typ 3 von QEMU nimmt manufacturer, version, serial, asset und sku, und sonst nichts10. Er bleibt Other.\nZwei Definitionen eines Typs werden zusammengeführt, und die spätere gewinnt. qemu-server setzt sein -smbios type=1 früh in die Befehlszeile und deine args ganz ans Ende12, ein zweites -smbios type=1,manufacturer=… in args wirft das erste also nicht weg: QEMU hat sie Feld für Feld zusammengeführt, der Hersteller kam aus args, und die UUID blieb, wo smbios1 sie hingesetzt hatte. Das zählt für die vierte Falle.\nDie beiden Hälften haben verschiedene Besitzer. qemu-server prüft Rechte Option für Option. smbios1 steht bei den Hardware-Optionen und braucht VM.Config.HWType, während args in den Auffangzweig ganz unten fällt, der sagt „only root can set“13. Mainboard, Gehäuse, Firmware-Hersteller und OEM-Strings gehören dir allein. Typ 1 nicht. Jeder, dem du Hardware-Rechte gegeben hast, kann ihn umschreiben, und bei einem gehosteten Produkt kann das sehr wohl der Kunde sein. Wenn der Herstellerstring zählt, setz ihn auch in args. Die spätere Definition gewinnt.\nDie Seriennummer steht schon in der Konfiguration Das meiste, was in Typ 1 gehört, steht schon in der VM-Konfiguration. Der Name gibt eine gute Seriennummer ab, weil qemu-server dort nur einen DNS-Namen akzeptiert14: kurz, druckbar, nie ein Komma darin, und das eine an der VM, das ein Kunde wiedererkennt.\nFeld in Typ 1 Genommen aus Für eine VM mit 4 Kernen und 16 GiB namens web-01, getaggt production;web Serial Number name web-01 SKU Number cores × sockets, und memory ec-4c16g Family der erste Eintrag in tags production UUID die smbios1-UUID, die sie schon hat unverändert Manufacturer, Product deine eigenen festen Strings Example Cloud Ltd, EC Compute Instance Zwei Dinge bleiben draußen. Der Knoten ändert sich bei jeder Migration, und vmgenid soll sich ändern: Seine ganze Aufgabe ist, dem Gast zu sagen, dass er aus einem Snapshot wiederhergestellt oder aus einer Vorlage gebaut wurde15. Keins von beiden ist eine Identität.\n#!/bin/bash # /usr/local/sbin/ec-smbios VMID: rebuild smbios1 from the VM\u0026#39;s own config. set -euo pipefail id=$1 cfg=$(qm config \u0026#34;$id\u0026#34; --current) get() { sed -n \u0026#34;s/^$1: //p\u0026#34; \u0026lt;\u0026lt;\u0026lt;\u0026#34;$cfg\u0026#34;; } b() { printf %s \u0026#34;$1\u0026#34; | base64 -w0; } name=$(get name) [ -n \u0026#34;$name\u0026#34; ] || { echo \u0026#34;VM $id has no name to use as a serial\u0026#34; \u0026gt;\u0026amp;2; exit 1; } cores=$(get cores); sockets=$(get sockets); vcpu=$(( ${cores:-1} * ${sockets:-1} )) mem=$(get memory); mem=${mem#current=}; mem=${mem%%,*}; mem=${mem:-512} (( mem % 1024 )) \u0026amp;\u0026amp; size=\u0026#34;${mem}m\u0026#34; || size=\u0026#34;$(( mem / 1024 ))g\u0026#34; tag=$(get tags); tag=${tag%%;*} uuid=$(get smbios1 | grep -o \u0026#39;uuid=[0-9a-fA-F-]*\u0026#39; | cut -d= -f2 || true) uuid=${uuid:-$(cat /proc/sys/kernel/random/uuid)} s=\u0026#34;uuid=$uuid,base64=1,manufacturer=$(b \u0026#39;Example Cloud Ltd\u0026#39;),product=$(b \u0026#39;EC Compute Instance\u0026#39;)\u0026#34; s+=\u0026#34;,serial=$(b \u0026#34;$name\u0026#34;),sku=$(b \u0026#34;ec-${vcpu}c${size}\u0026#34;)\u0026#34; [ -n \u0026#34;$tag\u0026#34; ] \u0026amp;\u0026amp; s+=\u0026#34;,family=$(b \u0026#34;$tag\u0026#34;)\u0026#34; qm set \u0026#34;$id\u0026#34; --smbios1 \u0026#34;$s\u0026#34; Die Vorgaben sind die von qemu-server selbst, ein Kern, ein Sockel und 512 MiB16, eine Konfiguration, die sie weglässt, bekommt also trotzdem eine wahre SKU. Gegen die Konfiguration aus der Tabelle laufen gelassen, mit einem Skript anstelle von qm, das sie auslieferte, ging die geschriebene Zeile so dekodiert an QEMU, wie qemu-server sie dekodiert, und dmidecode im Gast las web-01, ec-4c16g, production und die UUID zurück, die er schon hatte. Eine VM ohne Namen wird abgelehnt, statt eine leere Seriennummer zu bekommen.\nDas naheliegende Zuhause dafür ist ein Hookscript. Es ist das falsche. qemu-server führt den pre-start-Hook innerhalb der Konfigurationssperre aus, die es zum Starten der VM genommen hat, und baut die QEMU-Befehlszeile aus der Konfiguration, die es vor dem Hook geladen hat17. Ein Hook, der die Seriennummer umschreibt, ändert den nächsten Start, nicht diesen.\nLass es also aus deiner Provisionierung laufen, an den vier Punkten, an denen sich seine Eingaben ändern: Anlegen, Klonen, Umbenennen und Größenänderung. Beim Klonen beißt es. Ein Klon behält jedes smbios1-Feld außer der UUID9, lass den Schritt also aus, und jede VM, die aus web-template gebaut wurde, meldet den Namen der Vorlage als Seriennummer.\nDas Bootlogo lebt an zwei verschiedenen Orten Welches Logo ein Gast zeigt, hängt von seiner Firmware ab. Die beiden Firmwares, die Proxmox ausliefert, holen es von völlig verschiedenen Stellen:\nSeaBIOS (bios: seabios, die Vorgabe) OVMF (bios: ovmf, UEFI) Woher das Logo kommt ein JPEG, das QEMU beim Booten übergibt eine Bitmap, die in die Firmware kompiliert ist Die Datei von Proxmox /usr/share/qemu-server/bootsplash.jpg, 640×480 Logo.bmp, 400×120, 8 Bit, eingebaut in OVMF_CODE_4M*.fd Besitzendes Paket qemu-server pve-edk2-firmware-ovmf Pro VM ändern args: -boot splash=… args, das die VM auf andere Firmware zeigt Ändern, ohne etwas neu zu bauen ja nein Erreicht das Gast-OS über die BGRT nein ja SeaBIOS: ein JPEG auf der Befehlszeile qemu-server setzt bei jeder VM, die es startet, dieselbe -boot-Option, menu=on,strict=on,reboot-timeout=1000,splash=/usr/share/qemu-server/bootsplash.jpg18. Die Dokumentation von QEMU sagt, das Bild werde gezeigt „when option splash=sp_name is given and menu=on, If firmware/BIOS supports them. Currently Seabios for X86 system support it“10. OVMF nimmt daraus nichts außer splash-time, das es als Timeout für das Bootmenü verwendet, und in OvmfPkg gibt es nirgends einen Verweis auf die Splash-Datei19.\nErsetzen ist eine Zeile in der VM-Konfiguration:\nargs: -boot splash=/etc/pve/branding/splash.jpg Ein zweites -boot kämpft nicht mit dem ersten. QEMU führt es genauso zusammen wie -smbios, der spätere Wert gewinnt, und mit zwei angegebenen Splash-Dateien zeigte der Screenshot die zweite. /etc/pve ist das richtige Zuhause für die Datei, weil es das Cluster-Dateisystem ist und jeder Knoten denselben Splash sieht, und seine Grenze von 1 MiB pro Datei ist weit weg von einem JPEG mit 640×48020.\nDas Bild selbst muss drei Bedingungen erfüllen, und wer eine davon falsch macht, verliert das Logo oder seine Farben:\nBedingung Warum Was sonst passiert JPEG oder 24-Bit-BMP QEMU prüft die Datei, bevor die VM startet splash file … format not recognized; must be JPEG or 24 bit BMP Baseline-JPEG, Chroma 4:2:0 der Decoder von SeaBIOS kann nichts anderes21 ERR_NOT_SEQUENTIAL_DCT oder ERR_NOT_YCBCR_221111, und ein leerer Bildschirm 640×480, wie das von Proxmox SeaBIOS fragt das VGA-BIOS nach einem Modus mit genau der Größe des Bilds kein passender Modus, kein Splash Die meisten Bildwerkzeuge schreiben standardmäßig Baseline mit 4:2:0, der übliche Weg, das Logo zu verlieren, ist also eine dieser „Für Web speichern“-Optionen, die still progressive Kodierung einschaltet. Das sieht in jedem Bildbetrachter, den du hast, genau gleich aus, und SeaBIOS zeichnet gar nichts.\nDie Farbfalle Die hier hat einen Nachmittag gekostet. Dasselbe JPEG, von zwei Builds von SeaBIOS 1.17.0 gezeichnet, kommt in zwei verschiedenen Farben heraus:\nEs steckt in jpeg.c von SeaBIOS. Der Schreiber für 24 Bit pro Pixel hat einen Little-Endian-Zweig, der Blau in das erste Byte jedes Pixels setzt, und der Schreiber für 32 Bit pro Pixel, PIC_32, hat keinen solchen Zweig und schreibt dort stattdessen Rot21. Auf einem Little-Endian-Framebuffer vertauscht das Rot und Blau. Blau kommt als Gold heraus, und Orange käme als Blau heraus.\nWelcher Schreiber läuft, hängt vom Videomodus ab, den das VGA-BIOS anbietet:\nFirmware VBE-Modus für 640×480 Bit pro Pixel Farben Das vorgebaute SeaBIOS 1.17.0 von QEMU upstream, wie pve-qemu-kvm 11.0.3-4 es ausliefert 0x111 16 richtig, auf 65.536 quantisiert Fedora 44s eigener Build seabios 1.17.0-10 0x142 32 Rot und Blau vertauscht Die Modusnummern stammen aus der eigenen Tabelle von SeaBIOS22, und die Proxmox-Zeile wurde gegen genau die Blobs im Paket geprüft: Byte für Byte identisch mit dem vorgebauten rel-1.17.0-0-gb52ca86e094d von QEMU. Unter Proxmox stimmen deine Farben also, aber es gibt nur 65.536 davon, und ein feiner Verlauf bekommt Streifen. Und falls dein Logo irgendwann auf einem anderen Hypervisor in falschen Farben erscheint: Es ist nicht dein JPEG.\nDas UEFI-Logo ist in die Firmware kompiliert UEFI-Gäste sind die schwierigere Hälfte, und auf einem modernen Proxmox sind sie die meisten Gäste.\nEs gibt keine Splash-Option zum Überschreiben. Das Logo ist eine Bitmap im Firmware-Image, und der Build von Proxmox setzt es mit einer Zeile in debian/rules dorthin:\ndebian/setup-build-stamp: cp -a debian/Logo.bmp MdeModulePkg/Logo/Logo.bmp Das kopiert ihr Logo.bmp mit 400×120 und 8 Bit über das von TianoCore, bevor edk2 gebaut wird23. Dieselbe Datei setzt den Firmware-Hersteller als Konstante zur Build-Zeit, PcdFirmwareVendor=L\u0026quot;Proxmox distribution of EDK II\u0026quot;, und daher kommt der Typ-0-Hersteller in der ersten Tabelle23.\nNeues Logo, neue Firmware. Der Weg zu einer, die sich genau wie die von Proxmox verhält, ist, sie genau so zu bauen wie Proxmox: ihr Baum an dem Tag, der zum ausgelieferten Paket passt, ihre Patches, ihre Flags, und eine Bitmap ausgetauscht. pve-edk2-firmware 4.2026.08-1 pinnt edk2 auf 2970e56, und das ist der Upstream-Tag edk2-stable20260823.\ngit clone https://git.proxmox.com/git/pve-edk2-firmware.git cd pve-edk2-firmware git checkout f37039e52d228a7844a90aa2aaf1e161ebd04fcd # 4.2026.08-1 git submodule update --init --recursive cd edk2 QUILT_PATCHES=../debian/patches quilt push -a cp /path/to/your/Logo.bmp MdeModulePkg/Logo/Logo.bmp . ./edksetup.sh \u0026amp;\u0026amp; make -C BaseTools F=\u0026#34;-DNETWORK_HTTP_BOOT_ENABLE=TRUE -DNETWORK_IP6_ENABLE=TRUE -DNETWORK_TLS_ENABLE -DSECURE_BOOT_ENABLE=TRUE -DPVSCSI_ENABLE=TRUE -DTPM2_ENABLE=TRUE --pcd PcdUninstallMemAttrProtocol=TRUE -DFD_SIZE_4MB\u0026#34; P=(--pcd \u0026#34;PcdFirmwareVendor=LExample Cloud Ltd\\\\0\u0026#34; --pcd \u0026#34;PcdFirmwareVersionString=L4.2026.08-1+ec1\\\\0\u0026#34;) build -a IA32 -a X64 -t GCC -p OvmfPkg/OvmfPkgIa32X64.dsc $F \u0026#34;${P[@]}\u0026#34; -b RELEASE cp Build/Ovmf3264/RELEASE_GCC/FV/OVMF_CODE.fd OVMF_CODE_4M.fd rm -rf Build/Ovmf3264 build -a IA32 -a X64 -t GCC -p OvmfPkg/OvmfPkgIa32X64.dsc $F -DSMM_REQUIRE=TRUE \u0026#34;${P[@]}\u0026#34; -b RELEASE cp Build/Ovmf3264/RELEASE_GCC/FV/OVMF_CODE.fd OVMF_CODE_4M.secboot.fd Die Flags sind aus debian/rules übernommen, so wie es an diesem Commit steht. Achte auf den Herstellerstring: Ihr Makefile schreibt ihn in doppelten Anführungszeichen, die Shell von make entfernt sie, und edk2 bekommt ihn nackt. So wird er hier auch übergeben, und ihn ein zweites Mal zu quoten ist ein Build-Fehler. Lass die Bitmap bei 400×120 und 8 Bit wie ihre, dann verschiebt sich sonst nichts auf dem Bootbildschirm.\nDu brauchst beide Images. qemu-server bootet jede Q35-VM mit einer 4M-EFI-Disk auf OVMF_CODE_4M.secboot.fd, dem Build mit verpflichtendem SMM, und nimmt das einfache OVMF_CODE_4M.fd nur für i440fx24. Auf einem aktuellen Proxmox läuft fast jeder UEFI-Gast mit dem Secboot-Image.\nSo gebaut, mit nichts gegenüber dem Baum von Proxmox geändert als der Bitmap und zwei Strings, bootet das SMM-Image so:\nUnd die Sicht des Gasts auf seine eigene Firmware ändert sich mit, ohne eine einzige -smbios-Option auf der Befehlszeile:\nIm Gast gelesen 4.2026.08-1 von Proxmox Aus demselben Baum neu gebaut Firmware-Hersteller Proxmox distribution of EDK II Example Cloud Ltd Firmware-Version 4.2026.08-1 4.2026.08-1+ec1 „UEFI is supported“ aufgeführt aufgeführt ACPI-Tabellen BGRT, WSMT und der Rest derselbe Satz Damit ist der Hersteller zur Build-Zeit die bessere Antwort für UEFI-Gäste. Es ist der eigene Typ 0 von OVMF, das UEFI-Bit bleibt also stehen, ohne dass irgendwer an uefi=on denken muss. Der Weg über args für Typ 0 ist für SeaBIOS-Gäste, und für alle, die gar keine Firmware neu bauen.\nZwei Wege, einer VM die neue Firmware zu geben qemu-server kodiert fest, wo es nach Firmware sucht: OVMF.pm hält eine Tabelle von Pfaden unter /usr/share/pve-edk2-firmware/, nach Maschinentyp und Secure-Boot-Optionen geordnet, und es gibt nirgends in der VM-Konfiguration, der GUI oder der API eine Option, die eine andere Datei wählt24. Zwei Wege bleiben.\nGebrandetes OVMF bauen, und die zwei Wege in eine VM Baum von Proxmox pve-edk2-firmware 4.2026.08-1 Dein Branding Logo.bmp + Herstellerstring Gleicher Build, gleiche Flags OVMF_CODE_4M.fd + .secboot.fd A: umleiten auf jedem Knoten jede UEFI-VM bekommt es, keine Änderung an VM-Konfigs B: pro VM über args VM für VM aktiviert, Dateien von Proxmox unberührt apt full-upgrade Neue Firmware von Proxmox kommt, deine bleibt alt Post-Invoke-Hook Versionen weichen ab, also vor dem nächsten Start neu bauen Ein Build, zwei Wege hinein. So oder so installiert das nächste Upgrade die neue Firmware von Proxmox neben deine und lässt deine, wie sie war. Darum gibt es den Hook ganz unten. Weg A: auf jedem Knoten umleiten. Sag dpkg, dass die beiden Code-Images von Proxmox jetzt woanders hingehören, und setz deine an ihre Stelle:\nD=/usr/share/pve-edk2-firmware for f in OVMF_CODE_4M.fd OVMF_CODE_4M.secboot.fd; do dpkg-divert --package example-branding --add --rename --divert \u0026#34;$D/$f.distrib\u0026#34; \u0026#34;$D/$f\u0026#34; install -m 0644 \u0026#34;/root/branding/$f\u0026#34; \u0026#34;$D/$f\u0026#34; done Ab dem nächsten Start bootet jede UEFI-VM auf dem Knoten deine Firmware. Keine Änderung an irgendeiner VM-Konfiguration.\nWeg B: ausgewählte VMs darauf zeigen lassen. Behalte die Images in deinem eigenen Verzeichnis und überschreibe die Firmware VM für VM. Seit dem Umstieg auf -blockdev hängt qemu-server das Code-Image als Blockknoten namens pflash0 an und nennt ihn in -machine24, und QEMU führt ein zweites -machine genauso zusammen wie -boot, args kann also einen eigenen Knoten hinzufügen und pflash0 stattdessen darauf zeigen lassen:\nargs: -blockdev driver=raw,node-name=brandcode,read-only=on,file.driver=file,file.filename=/usr/local/share/example-branding/OVMF_CODE_4M.secboot.fd -machine pflash0=brandcode Das wurde auf dem langen Weg getestet. Die Secboot-Firmware von Proxmox wurde genau so als pflash0 angehängt, wie qemu-server es macht, mit SMM an, dann kam diese args-Zeile dahinter, und der Gast bootete das gebrandete Image mit Logo und Herstellerstring. Daher stammt der Screenshot oben.\nWeg A, umleiten Weg B, args pro VM Welche VMs es bekommen jede UEFI-VM auf dem Knoten nur VMs, bei denen du es setzt Die Dateien von Proxmox nach .distrib verschoben unberührt VM-Konfiguration unverändert eine args-Zeile, nur root Maschinentyp muss passen erledigt, beide Images sind umgeleitet deine Aufgabe: Secboot-Image für Q35 Rückgängig machen dpkg-divert --remove --rename die Zeile löschen Migration Zielknoten muss auch umgeleitet sein Zielknoten muss die Datei haben Das Code-Image ist etwa 3,5 MB groß, bei einer Grenze von 1 MiB pro Datei in pmxcfs20. Deshalb kann es nicht in /etc/pve liegen, und egal welchen Weg du nimmst, es muss auf jeden Knoten. Migrierst du eine VM auf einen Knoten ohne es, bekommst du je nach Weg eins von zwei Ergebnissen: unter Weg A wieder die Firmware und das Logo von Proxmox, oder unter Weg B eine VM, die gar nicht startet, weil QEMU eine Datei nicht öffnen kann, die nicht da ist.\nDas Upgrade, das dich zurücklässt Eine Umleitung ist das richtige Werkzeug für ein Logo. Firmware ist etwas anderes.\nEine Umleitung bedeutet, dass die Upgrades von Proxmox die Datei nicht mehr erreichen. Genau das hast du verlangt. Genau das hält auch Sicherheitskorrekturen von edk2 von deinen Gästen fern: Das Changelog von Proxmox für 4.2026.08-1 beginnt mit „Besides many bug and security fixes“ und führt dann eine Korrektur für CVE-2024-13745 auf25, und ein gebrandeter Build aus dem Release davor hat nichts davon. Nichts sagt es dir.\nDas wurde getestet, nicht angenommen. In einem Debian-trixie-Container mit dem Repository von Proxmox kam pve-edk2-firmware-ovmf 4.2025.05-3 hinein, beide Code-Images wurden umgeleitet, und das Paket wurde auf 4.2026.08-1 aktualisiert:\nNach dem Upgrade Ergebnis dpkg-query -W pve-edk2-firmware-ovmf 4.2026.08-1 Das neue Image von Proxmox als OVMF_CODE_4M.fd.distrib installiert, Hash geändert Das gebrandete Image unverändert, immer noch aus 4.2025.05-3 gebaut Irgendetwas dazu auf der Konsole nichts, bis zum Hook unten Also kommt ein Hook dazu. apt führt nach jedem Lauf von dpkg eine Liste von DPkg::Post-Invoke-Befehlen aus26. Halte fest, aus welcher Proxmox-Version du gebaut hast, und vergleiche nach jedem Lauf:\ncat \u0026gt; /usr/local/sbin/example-branding-check \u0026lt;\u0026lt;\u0026#39;EOF\u0026#39; #!/bin/sh built=$(cat /usr/local/share/example-branding/ovmf.built-from 2\u0026gt;/dev/null) now=$(dpkg-query -W -f \u0026#39;${Version}\u0026#39; pve-edk2-firmware-ovmf 2\u0026gt;/dev/null) [ \u0026#34;$built\u0026#34; = \u0026#34;$now\u0026#34; ] \u0026amp;\u0026amp; exit 0 echo \u0026#34;W: branded OVMF was built from pve-edk2-firmware-ovmf $built, Proxmox now ships $now.\u0026#34; \u0026gt;\u0026amp;2 echo \u0026#34;W: guests still boot the old firmware. Rebuild before the next VM restart.\u0026#34; \u0026gt;\u0026amp;2 exit 0 EOF chmod +x /usr/local/sbin/example-branding-check echo \u0026#39;DPkg::Post-Invoke { \u0026#34;/usr/local/sbin/example-branding-check\u0026#34;; };\u0026#39; \\ \u0026gt; /etc/apt/apt.conf.d/80example-branding Bei genau diesem Upgrade gab er aus:\nW: branded OVMF was built from pve-edk2-firmware-ovmf 4.2025.05-3, Proxmox now ships 4.2026.08-1. W: guests still boot the old firmware. Rebuild before the next VM restart. Er endet absichtlich mit 0. apt bricht ab, wenn ein Post-Invoke-Befehl fehlschlägt26, und eine Branding-Prüfung ist kein Grund, einen Knoten halb aktualisiert stehen zu lassen. Eine laute Warnung reicht.\nNoch etwas. Neustarts. Ein Gast bekommt neue Firmware erst, wenn sein QEMU-Prozess neu startet, ein Neubau bedeutet also ein Stoppen und Starten aus Proxmox heraus statt eines Neustarts im Gast, und genau so erreichen auch die eigenen Firmware-Updates von Proxmox eine laufende VM. Die brauchen nur nicht, dass du vorher an einen Neubau denkst.\nOder lass die Firmware von Proxmox in Ruhe Jeder Logo-Weg bisher ändert die Firmware, und der letzte Abschnitt ist die Rechnung dafür. Es gibt einen, der das nicht tut, und er wurde für diesen Beitrag als Prototyp gebaut.\nEin PCI-Gerät in QEMU kann ein Option-ROM tragen, jede Datei, die du mit romfile= angibst27, und OVMF führt den EFI-Treiber aus, den es dort findet. Der Build von Proxmox führt ihn aus, ob er signiert ist oder nicht: OVMF setzt PcdOptionRomImageVerificationPolicy auf 0x00, immer ausführen28. OVMF zeichnet sein eigenes Logo spät in der Auswahl des Bootgeräts29 und baut die BGRT erst bei ReadyToBoot, dem Moment, bevor es an einen Bootloader übergibt. Und der BGRT-Treiber von edk2 nimmt über EDKII_BOOT_LOGO2_PROTOCOL ein Ersatzbild an und baut die Tabelle bei ReadyToBoot neu, wann immer sich das Bild geändert hat30.\nMehr braucht es nicht. Der Treiber wartet bei TPL_NOTIFY auf ReadyToBoot, was vor dem eigenen Handler des BGRT-Treibers bei TPL_CALLBACK läuft, löscht den Bildschirm, zeichnet sein Logo und übergibt dasselbe Bild. Gebaut ist es eine Datei von 8 KB, angehängt mit einer Zeile:\nargs: -device pci-testdev,romfile=/etc/pve/branding/brandrom.rom Mit 8 KB liegt sie weit unter der Grenze von 1 MiB in pmxcfs20, anders als ein Firmware-Image mit 3,5 MB kann sie also in /etc/pve leben und der VM auf jeden Knoten folgen.\nGetestet wurde sie gegen die eigene Firmware von Proxmox, direkt aus pve-edk2-firmware-ovmf 4.2026.08-1: OVMF_CODE_4M.secboot.fd mit den vorab eingetragenen Schlüsseln von Microsoft in OVMF_VARS_4M.ms.fd, auf Q35 mit SMM, und gebootet über den signierten Shim von Fedora, sodass Secure Boot an war und durchgesetzt wurde:\nAus dem Gast gelesen Ohne das ROM Mit dem ROM Variable SecureBoot 1 1 Auf dem Bildschirm das Logo von Proxmox das von Proxmox für etwa 250 ms, dann deins BGRT-Bild, 400×120 bei 440,340 das von Proxmox, SHA-256 be5afe4b… das des ROMs, SHA-256 6c494576… Geänderte Firmware-Dateien keine keine Auf die letzte Zeile kommt es an. Die Firmware von Proxmox ist unberührt, ihr nächstes Sicherheits-Release erreicht deine Gäste also mit dem nächsten Neustart, und nichts aus dem vorigen Abschnitt gilt.\nUmsonst ist es nicht:\nKosten Warum Das Logo von Proxmox ist etwa eine Viertelsekunde zu sehen OVMF zeichnet es, bevor irgendein Option-ROM-Treiber den Bildschirm bekommt; nur ein Neubau vermeidet das Der Gast sieht ein PCI-Gerät mehr, ohne Treiber das ROM muss auf einem Gerät mitfahren, und pci-testdev ist das Nichtstuer-Gerät von QEMU Typ 0 sagt immer noch Proxmox der Herstellerstring ist einkompiliert; setz ihn über args mit uefi=on, wie oben Nur root es ist eine args-Zeile Und der Befund darunter will deutlich gesagt sein. Ein unsignierter Treiber lief in der Firmware eines Gasts mit eingetragenen Microsoft-Schlüsseln und durchgesetztem Secure Boot, weil das OVMF von Proxmox Option-ROMs nicht prüft. Hier ist das nützlich. Es bedeutet aber auch, dass Secure Boot auf dieser Firmware Bootloader prüft, nicht das, was die Hardware-Konfiguration der VM anhängt, und weil nur root args schreibt, ist das eine Frage danach, wer auf deinen Knoten root hat.\nEs ist ein Prototyp. Es lief auf QEMU 10.2.2 mit der Firmware von Proxmox, noch nicht auf einem Proxmox-Knoten, und was folgt, ist Quellcode, kein Produkt:\ngithub.com/damo2929/RebrandPCIRom: der Option-ROM-Treiber, der Logo-Konverter und der Container-Build.\nDie Weboberfläche sind zwei Pakete Das Logo oben links in der Weboberfläche ist nicht in pve-manager. Workspace.js fragt nach einer Komponente proxmoxLogoSvg mit dem Präfix pwt, und die lebt in proxmox-widget-toolkit, das sich Backup Server und Mail Gateway teilen31. Nur die Tab-Icons sind in pve-manager:\nWas Datei Paket Header-Logo, gezeichnet mit 200×35 /usr/share/javascript/proxmox-widget-toolkit/images/proxmox_logo.svg proxmox-widget-toolkit Icon im Browser-Tab /usr/share/pve-manager/images/favicon.ico pve-manager Icon mit 128×128, auch das Touch-Icon /usr/share/pve-manager/images/logo-128.png pve-manager Alle drei sind einfache Dateien, das ist also ein Fall für dpkg-divert, und hier gelten die Kosten aus dem letzten Abschnitt überhaupt nicht, denn ein Logo hat keine Sicherheitskorrekturen, die es verpassen kann, und niemandes Gast ist unsicherer, weil ein Knoten noch das Favicon vom letzten Monat ausliefert.\ndivert() { dpkg-divert --package example-branding --add --rename --divert \u0026#34;$1.distrib\u0026#34; \u0026#34;$1\u0026#34; install -m 0644 \u0026#34;$2\u0026#34; \u0026#34;$1\u0026#34; } divert /usr/share/javascript/proxmox-widget-toolkit/images/proxmox_logo.svg /root/branding/logo.svg divert /usr/share/pve-manager/images/favicon.ico /root/branding/favicon.ico divert /usr/share/pve-manager/images/logo-128.png /root/branding/logo-128.png Im selben Container getestet, gegen echte Pakete:\nSchritt Ergebnis Umleitung auf proxmox-widget-toolkit 5.2.9, eigenes SVG installiert das SVG von Proxmox umbenannt in proxmox_logo.svg.distrib Upgrade auf 5.2.10 eigenes SVG noch an seinem Platz, die Kopie von Proxmox aus 5.2.10 in .distrib dpkg --verify proxmox-widget-toolkit keine Beschwerden, dpkg weiß von der Umleitung apt-get install --reinstall proxmox-widget-toolkit eigenes SVG noch an seinem Platz dpkg-divert --remove --rename das Original von Proxmox zurück, Byte für Byte Zwei Dinge bleiben bei Proxmox. Das Header-Bild wird in einem festen Kasten von 200×35 gezeichnet, zeichne dein SVG also in dieser Form, sonst wird es gequetscht. Und der alt-Text sagt Proxmox, und das Bild verlinkt auf https://www.proxmox.com, beides in die JavaScript-Komponente geschrieben statt in eine Datei, die du umleiten kannst31. Das zu ändern heißt, ein minifiziertes Bundle zu patchen, das bei jedem Upgrade bricht. Für einen Alt-Text lohnt sich das nicht.\nWas Lizenz und Marke von Proxmox von dir verlangen Proxmox VE steht unter der AGPL Version 332, und Abschnitt 13 dieser Lizenz ist die Netzwerkklausel: „if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network … an opportunity to receive the Corresponding Source of your version“33. Zählt das Austauschen von drei Bildern als Änderung des Programms? Das ist eine Frage für einen Anwalt. Die billige Antwort ist, deine Bilder und das Umleitungsskript irgendwo öffentlich abzulegen und von der Anmeldeseite darauf zu verlinken. Kostet nix und klärt die Frage.\nDie Markenseite ist klarer. Das Media-Kit von Proxmox sagt „Don\u0026rsquo;t alter the logo or incorporate the logo or symbol into your logo“34. Ersetze ihres also vollständig durch dein eigenes, nie durch eine umgefärbte oder überarbeitete Version davon, und halte Proxmox aus dem Namen deines Produkts heraus.\nDein Name darauf heißt deine Wartung Eine VM zu branden ist billig. Eine Handvoll SMBIOS-Strings, ein JPEG, eine Bitmap und drei Bilder in einer Weboberfläche: die Arbeit eines Nachmittags, das meiste davon damit verbracht, herauszufinden, wo die Dinge liegen.\nEs zu halten ist die eigentliche Arbeit. Es ist auch der Teil, der ausgelassen wird.\nDie SMBIOS-Strings und der Splash kümmern sich um sich selbst, weil sie in Konfiguration leben, die kein Paket je anfasst, und das Logo der Weboberfläche kümmert sich um sich selbst, weil dpkg davon weiß. Die Firmware nicht. An dem Tag, an dem du dein Logo in ein Firmware-Image setzt, hast du ein Stück vom Release-Prozess eines anderen übernommen. Proxmox bauen, testen und liefern neue Firmware mit Sicherheitskorrekturen, die ihre Kunden mit dem nächsten Upgrade bekommen, und deine bekommen sie, wenn du dazu kommst, neu zu bauen.\nDieser Tausch ist in Ordnung, wenn man ihn wissentlich macht. Ein Hoster, dessen Gäste Firmware booten, die zwei Releases zurückliegt, weil das Logo wichtiger war als das Changelog, hat kein Produkt gebaut. Er hat einen Aufkleber gebaut.\nWenn dein Name auf dem Bootbildschirm steht, ist die Firmware dahinter deine, um sie aktuell zu halten, egal wer sie geschrieben hat. Niemand wird es prüfen. Genau deshalb muss es gemacht werden.\nUEFI Forum, ACPI Specification 6.6, §5.2.23 Boot Graphics Resource Table — „The Boot Graphics Resource Table (BGRT) is an optional table that provides a mechanism to indicate that an image was drawn on the screen during boot“. Archivierte Kopie; die Live-Seite antwortet automatisierten Anfragen mit 403.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMicrosoft Learn, Boot screen components — „This is the standard interface that Windows uses to access the logo.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nFedora Project, Changes/FlickerFreeBoot — „a new plymouth theme which incorporates the firmware\u0026rsquo;s bootsplash image“; Fedoras plymouth.spec macht bgrt zum Standard-Theme.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nDebian, dpkg-divert(1), trixie — „File diversions are a way of forcing dpkg(1) not to install a file into its location, but to a diverted location.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nDMTF, DSP0134 System Management BIOS Reference Specification 3.10.0 — Typ 1 System Information, Typ 2 Mainboard, Typ 3 „the system\u0026rsquo;s mechanical enclosure(s)“, Typ 11 „free-form strings defined by the OEM“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nProxmox VE, qm.conf(5) — smbios1: „Specify SMBIOS type 1 fields“; args: „Arbitrary arguments passed to kvm … this option is for experts only.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nqemu-server, src/PVE/QemuServer.pm, das Format von smbios1 und der Aufbau der Befehlszeile — jedes Feld außer uuid hat das Muster [A-Za-z0-9+\\/]+={0,2}; die Werte werden dekodiert, wenn base64 gesetzt ist.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\npve-manager, www/manager6/Parser.js, printQemuSmbios1 — „smbios values can be arbitrary, so encode and mark config as such“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nqemu-server, src/PVE/API2/Qemu.pm, Klonen — „auto generate a new uuid“, die anderen smbios1-Felder bleiben erhalten.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nQEMU, System Emulation, Invocation — -smbios-Felder pro Typ; -acpitable „For file=, take whole ACPI table from the specified files, including all ACPI headers“; -boot „Currently Seabios for X86 system support it.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nedk2-stable202608, OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c — OVMF fügt seinen eigenen Typ 0 nur hinzu, wenn NeedSmbiosType0 nach dem Durchlauf durch die Tabellen von QEMU noch gesetzt ist.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nqemu-server, src/PVE/QemuServer.pm, eigene Argumente — args werden aufgeteilt und ans Ende der Befehlszeile gehängt.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nqemu-server, src/PVE/API2/Qemu.pm, Rechteprüfung der Konfiguration — smbios1 ist eine Hardware-Option und braucht VM.Config.HWType; der Auffangzweig „catches args, lock, etc.“ und bricht mit „only root can set“ ab.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nqemu-server, src/PVE/QemuServer.pm, die Option name — format =\u0026gt; 'dns-name'.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nqemu-server, src/PVE/QemuServer.pm, vmgenid — „notify the guest operating system when the virtual machine is executed with a different configuration (e.g. snapshot execution or creation from a template)“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nqemu-server, src/PVE/QemuServer/Memory.pm — Speicher default =\u0026gt; 512; cores und sockets haben in QemuServer.pm die Vorgabe 1.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nqemu-server, src/PVE/QemuServer.pm, vm_start — lock_config in Zeile 5457, exec_hookscript($conf, $vmid, 'pre-start', 1) in 5581 und config_to_command in 5634 mit demselben $conf, dazwischen nicht neu geladen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nqemu-server, src/PVE/QemuServer.pm, -boot — menu=on,strict=on,reboot-timeout=1000,splash=/usr/share/qemu-server/bootsplash.jpg.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nedk2-stable202608, OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c — OVMF liest etc/boot-menu-wait, den Wert von splash-time, und sonst nichts aus -boot.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\npve-cluster, src/pmxcfs/memdb.h — #define MEMDB_MAX_FILE_SIZE (1024 * 1024) // 1 MiB.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nSeaBIOS, src/jpeg.c — PIC schreibt auf Little-Endian Blau zuerst, PIC_32 in Zeile 946 schreibt Rot zuerst, ohne Endian-Zweig; ERR_NOT_SEQUENTIAL_DCT und ERR_NOT_YCBCR_221111 sind die einzigen abgelehnten Formate.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nSeaBIOS, vgasrc/svgamodes.c — Modus 0x111 ist 640×480 mit 16 Bit, 0x142 ist 640×480 mit 32.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\npve-edk2-firmware, debian/rules bei 4.2026.08-1 — cp -a debian/Logo.bmp MdeModulePkg/Logo/Logo.bmp, der String PcdFirmwareVendor und die Build-Flags für OVMF.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nqemu-server, src/PVE/QemuServer/OVMF.pm — die fest kodierte Firmware-Tabelle unter /usr/share/pve-edk2-firmware/, die Wahl von SMM und der Blockknoten pflash0.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\npve-edk2-firmware, debian/changelog — 4.2026.08-1: „Besides many bug and security fixes … fix CVE-2024-13745“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nDebian, apt.conf(5), trixie — „Pre-Invoke, Post-Invoke: This is a list of shell commands to run before/after invoking dpkg(1) … should any fail APT will abort.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nQEMU v11.0.3, hw/pci/pci.c — DEFINE_PROP_STRING(\u0026quot;romfile\u0026quot;, PCIDevice, romfile), eine Eigenschaft, die jedes PCI-Gerät hat.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nedk2-stable202608, OvmfPkg/OvmfPkgIa32X64.dsc — gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x00, die Plattformdatei, die Proxmox baut.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nedk2-stable202608, OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c — BootLogoEnableLogo (), aufgerufen aus PlatformBootManagerAfterConsole.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nedk2-stable202608, BootGraphicsResourceTableDxe.c — SetBootLogo2 in Zeile 239 kopiert das Bild; der ReadyToBoot-Handler in 417 deinstalliert die Tabelle und installiert sie neu, „If BGRT data change happens“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nproxmox-widget-toolkit, src/Logo.js — proxmoxLogoSvg, 200×35, alt: 'Proxmox', verlinkt auf proxmox.com; verwendet aus pve-manager Workspace.js mit prefix: 'pwt'.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nProxmox VE wiki, FAQ — „Proxmox VE code is licensed under the GNU Affero General Public License, version 3.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nGNU Affero General Public License v3, §13 Remote Network Interaction — im Text oben vollständig zitiert.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nProxmox, Media kit — „Don\u0026rsquo;t alter the logo or incorporate the logo or symbol into your logo.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://blogs.damiendye.uk/de/proxmox/branding-a-proxmox-vm/","summary":"Eine Standard-VM unter Proxmox zeigt beim Booten das Logo von Proxmox, nennt Proxmox als Firmware-Hersteller und bezeichnet sich in jeder SMBIOS-Tabelle als QEMU. Dieser Beitrag ersetzt all das durch den Namen deines Produkts: SMBIOS-Typen 0, 1, 2, 3 und 11, Seriennummer und SKU aus Name und Größe der VM selbst, der SeaBIOS-Splash und seine Farbfalle, ein OVMF mit eigenem Logo, gebaut aus dem Baum von Proxmox, oder ein Option-ROM-Treiber, der Logo und BGRT unter Secure Boot ersetzt, ohne die Firmware anzufassen, und das Logo der Weboberfläche. Jede Änderung sitzt so, dass ein Upgrade sie nicht still rückgängig machen kann, und die eine, die ein Upgrade gefährlich veralten lassen kann, die Firmware, bekommt einen Hook, der es meldet.","title":"Eine Proxmox-VM mit eigenem Branding, und wie es das nächste Upgrade übersteht"},{"content":"Alles in diesem Beitrag lief gegen ein NetBox 4.7.2 auf meinem eigenen Schreibtisch, mit einem echten Bestand darin: ein Standort, ein Schrank, vierzehn Geräte, verkabelt, mit Strom versorgt und adressiert über drei Kunden hinweg. Jeder Screenshot ist diese Instanz, und jede Fehlermeldung ist eine, die ich wirklich bekommen habe.\nEs geht in der Reihenfolge, in der du dem Ganzen begegnen würdest. Was das Ding ist, warum du eins haben willst, der Fork, von dem du innerhalb einer Woche Suche hören wirst, wie du eins aufsetzt, die Reihenfolge, in der du es füllen musst, und dann, was du wieder herausbekommst. Die Anpassungs- und Erweiterungsarbeit steht am Ende, weil davon nichts Sinn ergibt, bevor du die Form dessen gesehen hast, was du erweiterst.\nWas NetBox ist NetBox ist eine Datenbank mit einer sehr bestimmten Meinung darüber, woraus ein Netzwerk besteht, und eine Webanwendung darauf. Es ist eine Django-Anwendung auf PostgreSQL, es ist seit der Freigabe durch DigitalOcean im Juni 2016 Open Source unter Apache 2.0, und das Projekt wird heute von NetBox Labs gemeinsam mit einem Team freiwilliger Maintainer betreut.12\nDarunter sind es 149 Modelle in zehn Anwendungen, erreichbar über 146 REST-Endpunkte und einen GraphQL-Endpunkt. Gezählt an der Instanz, die ich dafür gebaut habe, nicht von einer Feature-Seite abgelesen:\nAnwendung Modelle Anwendung Modelle dcim 56 virtualization 7 extras 23 tenancy 6 ipam 18 wireless 3 circuits 11 users 7 vpn 10 core 8 Sechsundfünfzig davon sind DCIM, die physische Schicht: Standorte, Locations, Racks, Gerätetypen, Geräte und jede Art von Port, Bay und Kabelabschluss, die ein Gerät haben kann. Achtzehn sind IPAM. Der Rest deckt Leitungen, Tunnel und IKE-Policies, virtuelle Maschinen und Cluster, Funkstrecken, Mandantenfähigkeit und die Maschinerie ab, die das Ganze erweiterbar macht.\nDie Zahl ist nicht der Punkt. Die Joins sind es, und der schnellste Weg, das zu sehen, ist der Bildschirm, für den NetBox am bekanntesten ist.\nFang mit dem Schrank an, denn das ist der Bildschirm, der das Ding verkauft.\nDiese Elevation wird aus den Daten gezeichnet, nicht hochgeladen. Jedes Gerät ist dort, weil irgendetwas sagt, dass es diese Höheneinheiten belegt, in diese Richtung zeigend, und die Farben kommen von der Rolle, die du ihm gegeben hast. Die Platzauslastung liest 28,6 %, weil NetBox das ausgerechnet hat. Niemand pflegt diese Zahl.\nZwei Dinge folgen daraus, die mehr wert sind als das Bild.\nDu kannst fragen, welche Einheiten frei sind, und bekommst eine Antwort, mit der du arbeiten kannst. Du kannst Einheiten auch reservieren, bevor irgendetwas darin eingebaut ist, und das ist der Unterschied zwischen dem Verkauf von Platz, den du hast, und dem Verkauf von Platz, von dem du glaubst, du hättest ihn.\nWas es bewusst nicht tun wird Ein Produkt, das weiß, was es nicht ist, ist seltener als eines, das alles schlecht macht, und NetBox\u0026rsquo; eigene Dokumentation ist da unverblümt. Es bietet kein Netzwerk-Monitoring, keinen DNS-Dienst, kein RADIUS, kein Konfigurationsmanagement und kein Facility-Management.1\nWichtiger noch: Es hält den gewünschten Zustand deines Netzwerks, nicht seinen Betriebszustand, und die Dokumentation sagt, der automatisierte Import des lebenden Netzwerkzustands sei „strongly discouraged“, weil jeder Datensatz zuerst von einem Menschen geprüft werden sollte.1\nDas ist die Entscheidung, auf der alles andere aufbaut, und es ist die, über die Leute streiten. Das Argument geht so: Eine Source of Truth sollte doch die Wahrheit sein, also entdecke das Netzwerk und lade es hinein. Die Antwort ist, dass ein entdecktes Netzwerk dir sagt, was da ist, und was da ist, schließt jeden Fehler ein, den irgendwer jemals gemacht hat. Ein Switch-Port, der 2021 im falschen VLAN gelassen wurde, ist eine Tatsache. Er ist keine Absicht.\nNetBox hält die Absicht. Dein Monitoring hält die Wirklichkeit. Die interessante Zahl ist die Differenz zwischen beiden, und eine Differenz kannst du nicht aus einer einzigen Eingabe berechnen.\nDer andere Grundsatz steht genauso klar da: Wenn du zwischen einer relativ einfachen Achtzig-Prozent-Lösung und einer viel komplexeren vollständigen wählen kannst, nimm die einfache.1 Das wirst du beim ersten Mal spüren, wenn du etwas modellieren willst, was es nicht modelliert, und es gibt gegen Ende einen ganzen Block von Abschnitten darüber, was du dann tust.\nNetBox tut NetBox tut nicht Festhalten, was da sein soll Abfragen, was da ist Das vorgesehene VLAN für einen Port halten Dir sagen, dass der Port unten ist Sagen, welchem Kunden ein Prefix gehört Es ihm in Rechnung stellen Die Konfiguration eines Geräts aus einem Template rendern Sie auf das Gerät schieben Leitung, Provider und Commit nachhalten Die Leitung überwachen Sagen, in welchem Rack ein Gerät steht, und in welcher U Den Schrank aufmachen Lies die rechte Spalte als Liste der Werkzeuge, die du weiterhin brauchst. Lies sie falsch, und du wirst versuchen, NetBox zu allen davon zu machen, und genau so wird aus einer Source of Truth noch ein System, dem niemand traut.\nWarum du eins brauchst Frag einen Managed-Service-Provider, wo die verbindliche Aufzeichnung des Netzwerks eines Kunden liegt, und du bekommst eine Antwort. Frag zwei seiner Techniker getrennt, und du bekommst zwei.\nEiner zeigt auf eine Tabelle. Einer zeigt auf ein Diagramm, das zuletzt von jemandem gespeichert wurde, der 2023 gegangen ist. Noch jemand sagt, die Firewall-Konfiguration sei die Dokumentation, was wenigstens ehrlich ist, denn eine Konfiguration beschreibt tatsächlich, was eine Kiste tut. Sie beschreibt nur nicht, warum, oder wer das wollte, oder welcher der vier Kunden hinter dieser Kiste für die Regel bezahlt.\nDas Versagen ist nie der Tag, an dem du merkst, dass die Aufzeichnung falsch ist. Es ist der Tag, an dem jemand sie braucht.\nDer Moment Was du vorlegen musst Was es kostet, wenn du es nicht kannst Ein Verlängerungsgespräch Eine Einzelaufstellung, was die monatliche Gebühr kauft Das Angebot des Mitbewerbers ist aufgeschlüsselt, weil er nachgezählt hat Ein Techniker kündigt Alles, was er wusste, aufgeschrieben Sechs Monate Herausfinden, ein Ticket auf einmal Ein Kunde geht Eine Beschreibung seines eigenen Bestands Drei Wochen, um sie zusammenzutragen, und eine Referenz, die er ehrlich geben wird Ein Prüfer stellt eine Scope-Frage Welche Systeme personenbezogene Daten halten und wo sie physisch stehen Einer Aufsichtsbehörde wurde etwas erzählt, was sich später als unwahr erweist Eine Migration braucht einen Preis Eine Zählung dessen, was wirklich da ist Du bietest auf eine Schätzung und frisst die Differenz Nichts davon ist exotisch. Das ist Dienstag.\nWas du dafür bekommst, ist keine Dokumentation. Dokumentation ist etwas, das du schreibst und dann nicht mehr pflegst. Was du bekommst, ist eine Datenbank, die sich weigert, einen Widerspruch zu halten, und die Fragen beantwortet, die ihr vorher niemand zu stellen gedacht hat. Weiter unten in diesem Beitrag gibt es einen Schrank, der sich als 28,6 Prozent voll mit Technik und 90,7 Prozent voll mit Strom entpuppt. Niemand hat sich vorgenommen, das zu finden. Es fiel daraus heraus, einmal eine Wattzahl an einem Gerätetyp eingetragen zu haben.\nDer ehrliche Vorbehalt kommt mit dazu, und der letzte Abschnitt handelt davon. Eine Aufzeichnung ist nur so viel wert, wie es dich kostet, sie richtig zu halten. Aber die Alternative ist ein Unternehmen, das sich selbst nicht beschreiben kann, und der Erste, der das herausfindet, ist üblicherweise ein Kunde.\nDas andere: Nautobot Darauf stößt du innerhalb von etwa einer Woche Suche, also lohnt es sich zu wissen, was passiert ist.\n2021 hat Network to Code NetBox geforkt und das Ergebnis Nautobot genannt. Kein Soft Fork und keine Distribution: ein harter Fork, der seit fünf Jahren auseinanderläuft. Seine eigenen v1.0-Release-Notes beschreiben ihn als „a divergent fork of NetBox 2.10“, das Repository wurde am 19. Februar 2021 erstellt und v1.0.0 kam am 26. April 2021.3\nDie genannten Gründe stehen im eigenen Blog und sind in ihren Worten lesenswerter als in meinen. Drei Dinge trieben es an. Sie wollten Enterprise-Support verkaufen: „We need to offer high-touch support models with Service Level Agreements (SLAs) we can guarantee. We need flexibility to offer Long-term Support (LTS) for customers who can\u0026rsquo;t upgrade at the pace of a fast moving open source project.“ Sie wollten, dass die Source of Truth im Zentrum einer Automatisierungsplattform sitzt, statt Dokumentation zu bedienen. Und „there became a growing divergence in our vision about what a Source of Truth for networking should look like and how to get there“.4\nDem ersten Grund muss man das Datum anhängen, denn er ist nicht mehr wahr. Im Februar 2021 gab es kein Unternehmen hinter NetBox, das dir irgendetwas verkaufen konnte. NetBox Labs wurde erst 2023 gegründet, als Spin-out aus NS1, nachdem IBM es übernommen hatte, mitgegründet von NetBox\u0026rsquo; eigenem Lead Maintainer.5\nUnd es ist kein Dritter, der ein Geschäft auf dem Projekt eines anderen aufgebaut hat. NetBox Labs ist der Sachwalter von NetBox: Die Dokumentation des Projekts selbst sagt „the open source project is stewarded by NetBox Labs and a team of volunteer maintainers“.1 Sie verkaufen NetBox Enterprise für selbst verwaltete Installationen, hosten es als NetBox Cloud für dich und bieten Support rund um die Uhr.6\n„you cannot buy support for NetBox“ war also eine faire Aussage, als Network to Code forkte, und ist heute keine faire Aussage mehr. Hinter beiden Projekten steht ein kommerzielles Unternehmen, das etwas unterschreibt, und im Fall von NetBox ist dieses Unternehmen dasjenige, das das Projekt betreut.\nDie Zeile, die die meisten übersehen, ist die nächste, und sie ist der Grund, warum das keine schmutzige Geschichte ist: „the NetBox project team suggested that we should consider forking.“\nZivilisierter wird ein Fork kaum. Zwei Gruppen wollten Unterschiedliches, sagten das über einen längeren Zeitraum und trennten sich, statt sich um eine Codebasis zu streiten. Beide Hälften sind weiterhin Apache 2.0. Niemand hat etwas genommen, worauf er kein Recht hatte.\nWozu der Fork wirklich da war Die Release-Notes von Nautobot 1.0 listen auf, was es gegenüber NetBox 2.10 hinzugefügt hat, und die Liste erzählt das Argument besser als jeder Blogbeitrag:3\nWas Nautobot 2021 hinzufügte Wo NetBox heute steht GraphQL-Unterstützung NetBox hat es Git-Integration als Datenquelle NetBox hat es, als synchronisierte Datenquellen Single Sign-on NetBox hat es Secrets NetBox hat es über ein Plugin Scripts und Reports zu Jobs zusammengefasst NetBox zieht Scripts in 4.7 in ein Plugin aus Custom Fields auf allen Modellen NetBox hat breite Custom-Field-Unterstützung Data-Validation-Plugin-API NetBox hat Custom Validation Rules Anpassbare Status als Datenbankobjekte NetBox\u0026rsquo; Status sind weiterhin ein Python-Choice-Set Benutzerdefinierte Beziehungen zwischen Modellen NetBox hat kein Äquivalent UUID-Primärschlüssel NetBox nutzt Integer-Schlüssel Verbesserungen der Plugin-API NetBox\u0026rsquo; Plugin-Framework ist seither stark gewachsen Die obere Hälfte ist größtenteils zusammengewachsen. Mehreres, was Nautobot 2021 ausgeliefert hat, kam danach in NetBox an, und das ist üblicherweise, was passiert, wenn zwei Projekte dieselben Probleme öffentlich lösen.\nDie unteren drei sind nicht zusammengewachsen, und sie sind architektonisch, nicht kosmetisch. Ich habe heute beide Codebasen geprüft, statt den Notizen von 2021 zu trauen.\nNautobots Status ist ein Datenbankmodell, in seinem eigenen Quellcode beschrieben als „Model for database-backend enum choice objects“, also ist ein Status eine Zeile, die jemand in der UI hinzufügen kann. NetBox\u0026rsquo; Status kommen aus einem Python-Choice-Set, weshalb der Abschnitt weiter unten einen hinzufügt, indem er configuration.py bearbeitet und neu startet. Nautobot hat Relationship- und RelationshipAssociation-Modelle, du kannst also eine Beziehung zwischen zwei bestehenden Objekttypen definieren, ohne Code zu schreiben. NetBox\u0026rsquo; Antwort auf dieses Problem ist ein Plugin, und das ist der letzte Block von Abschnitten in diesem Beitrag. Und Nautobots Primärschlüssel sind UUIDs, wo NetBox\u0026rsquo; Integer sind.\nSie haben auch das getan, wofür sie geforkt haben. Heute veröffentlicht Nautobot 3.2.x und 2.4.x am selben Tag, was eine echte Long-Term-Maintenance-Linie neben der aktuellen ist, und das war einer der drei genannten Gründe.\nWelches von beiden Zuerst die ehrlichen Zahlen. NetBox hat 21.625 Sterne und 3.133 Forks; Nautobot hat 1.617 und 422.7 Bei beiden wurde innerhalb der letzten zwei Tage gepusht, beide sind Apache 2.0, und hinter beiden steht inzwischen ein kommerzielles Unternehmen, das Support und Hosting verkauft.\nDieser Abstand ist kein Urteil über Qualität. Er spiegelt fünf Jahre Vorsprung und die Tatsache, dass die meisten, die eine Source of Truth brauchen, zuerst NetBox finden. Aber er entscheidet das, was meist mehr zählt als Features: wie viele Plugins, Integrationen, Ansible-Module, Forenantworten und Kollegen du für das findest, was du wählst.\nAlso: Wenn du ein Inventar und eine Source of Truth willst, die andere Systeme lesen, und du das größte Ökosystem und die leichteste Einstellung willst, ist die Antwort NetBox, und darum geht es im Rest dieses Beitrags. Wenn dein Grund für eine Source of Truth speziell ist, Automatisierung daraus zu betreiben, oder wenn du Status und Beziehungen von deinem Team definiert haben willst statt von einer Konfigurationsdatei und einem Neustart, dann sieh dir Nautobot richtig an, bevor du entscheidest.\nLass dir keines von beiden allein über Support verkaufen. Beide Seiten haben das inzwischen abgedeckt, und die Unterschiede, die in fünf Jahren noch da sind, sind die in der Tabelle oben.\nWas du nicht tun solltest, ist eines zu wählen, weil dir jemand gesagt hat, das andere sei tot. Keines ist es, und beide haben diese Woche noch Releases ausgeliefert.\nEins zum Laufen bringen Zwei Wege, und ich habe beide dafür durchgespielt. Container, wenn du es in zwanzig Minuten laufen haben willst, Pakete auf einem Host, wenn es tragend wird.\nDer Container-Stack Die Community pflegt netbox-docker, und das ist die schnelle Antwort:8\ngit clone -b release https://github.com/netbox-community/netbox-docker.git cd netbox-docker tee docker-compose.override.yml \u0026lt;\u0026lt;\u0026#39;EOF\u0026#39; services: netbox: ports: - 8000:8080 EOF docker compose pull docker compose up Das gibt dir die Anwendung, PostgreSQL, Redis und einen Background-Worker, miteinander verdrahtet. Ich habe dasselbe von Hand unter podman gebaut, um die Teile zu sehen, und die Teile sind es wert, sie zu kennen, denn zwei von ihnen erwischen Leute:\nContainer Macht was Wenn du ihn weglässt netbox Die Django-Anwendung hinter gunicorn nichts funktioniert postgres Die Datenbank, 15 oder neuer nichts funktioniert redis / valkey Zwei Datenbanken: eine für Tasks, eine fürs Caching nichts funktioniert netbox-worker rqworker, der die Task-Queue abarbeitet Webhooks feuern nie, Background-Jobs laufen nie, und nichts warnt dich netbox-housekeeping Das periodische Aufräumen Changelog-Einträge verfallen nie Diese vierte Zeile ist die entscheidende. Ohne Worker sieht alles gesund aus. Event Rules stapeln sich und bleiben liegen.\nZwei Dinge haben mich beim ersten Lauf gebissen, und keines steht in einer Fehlermeldung, nach der du suchen würdest.\nDie erste Migration dauert lange. Keine Minute. Auf dieser Maschine waren es mehrere, weil NetBox 4.7 django-mptt durch PostgreSQL ltree ersetzt und dabei jede hierarchische Tabelle neu aufbaut. Der Container sitzt einfach da und wendet Migrationen an. Lass ihn in Ruhe.\nOhne API_TOKEN_PEPPERS kannst du kein v2-API-Token erstellen, und das einzige Anzeichen ist eine Warnung im Log:\nUserWarning: API_TOKEN_PEPPERS is not defined. v2 API tokens cannot be used. Setz mindestens eines, mindestens fünfzig Zeichen lang, bevor du anfängst zu suchen, warum die API dich abweist.\nAuf einem Host, aus den Paketen Der dokumentierte Weg ist auf Ubuntu 24.04 getestet. Ich habe ihn auf einem frischen von Anfang bis Ende durchgespielt, und es lief darauf hinaus:\nKomponente Was 24.04 mir gab Was NetBox 4.7 braucht PostgreSQL 16.15 15 oder neuer Redis 7.0.15 6.0 oder neuer Python 3.12.3 3.12, 3.13 oder 3.14 Django 6.1.1 kommt mit NetBox NetBox v4.7.2 Diese Mindestversionen sind NetBox\u0026rsquo; eigene, und 4.7 hat sowohl die PostgreSQL- als auch die Redis-Untergrenze angehoben.9\nDer ganze Job sind fünf Schritte.\n# 1. the services sudo apt install -y postgresql redis-server sudo -u postgres psql -c \u0026#34;CREATE DATABASE netbox;\u0026#34; sudo -u postgres psql -c \u0026#34;CREATE USER netbox WITH PASSWORD \u0026#39;something-you-generated\u0026#39;;\u0026#34; sudo -u postgres psql -c \u0026#34;ALTER DATABASE netbox OWNER TO netbox;\u0026#34; sudo -u postgres psql -d netbox -c \u0026#34;GRANT CREATE ON SCHEMA public TO netbox;\u0026#34; # 2. the build dependencies sudo apt install -y python3 python3-pip python3-venv python3-dev build-essential libxml2-dev libxslt1-dev libffi-dev libpq-dev libssl-dev zlib1g-dev git # 3. the application, at a release tag rather than at main sudo mkdir -p /opt/netbox \u0026amp;\u0026amp; cd /opt/netbox sudo git clone https://github.com/netbox-community/netbox.git . sudo git checkout v4.7.2 sudo adduser --system --group netbox sudo chown -R netbox /opt/netbox/netbox/media/ /opt/netbox/netbox/scripts/ /opt/netbox/netbox/reports/ # 4. the configuration: five values, no more cd /opt/netbox/netbox/netbox/ sudo cp configuration_example.py configuration.py python3 /opt/netbox/netbox/generate_secret_key.py # run it twice sudo $EDITOR configuration.py # 5. let the upgrade script do the rest sudo /opt/netbox/upgrade.sh Diese fünf Werte sind ALLOWED_HOSTS, DATABASES, REDIS, SECRET_KEY und API_TOKEN_PEPPERS. Erzeuge die letzten zwei getrennt und verwende nicht eines für das andere. Lass den Key-Generator also zweimal laufen und füge die Ergebnisse in verschiedene Zeilen ein.\nupgrade.sh baut die virtuelle Umgebung, installiert jede Python-Abhängigkeit, führt die Migrationen aus, baut die Dokumentation für die Offline-Nutzung und sammelt die statischen Dateien ein. Wenn es auf einer frischen Kiste fertig ist, gibt es eine Warnung aus, die alarmierend aussieht und es nicht ist:\nWARNING: No existing virtual environment was detected. A new one has been created. Update your systemd service files to reflect the new Python and gunicorn executables. (If this is a new installation, this warning can be ignored.) Dann ein Superuser, und der läuft so:\nsource /opt/netbox/venv/bin/activate cd /opt/netbox/netbox \u0026amp;\u0026amp; python3 manage.py createsuperuser Für alles Echte setz gunicorn davor statt runserver. Die Konfiguration und die Unit-Dateien liegen schon im Repository, und das ist das Detail, das man kennen sollte, weil Leute ihre eigenen schreiben:\nsudo cp /opt/netbox/contrib/gunicorn.py /opt/netbox/gunicorn.py sudo cp -v /opt/netbox/contrib/*.service /etc/systemd/system/ sudo systemctl daemon-reload sudo systemctl enable --now netbox netbox-rq netbox.service fährt gunicorn auf 127.0.0.1:8001, netbox-rq.service fährt den Worker, und nginx oder Apache steht davor, um TLS zu terminieren und /static auszuliefern. Zwei Dienste, und der zweite ist derselbe Worker, den der Container-Stack braucht.\nDie Reihenfolge, in der du es füllen musst Ein frisches NetBox ist eine leere Datenbank mit Meinungen, und die erste Stunde damit geht meist dafür hin, herauszufinden, welche das sind. Du gehst hin, um ein Gerät anzulegen, und es lässt dich nicht.\nDiese roten Sternchen sind die ganze Lektion. NetBox hält nichts fest, bevor die Dinge existieren, an denen es hängt, und es ist nicht bockig: Ein Gerät ohne Typ ist eine Zeile, die keine der Fragen beantworten kann, für die ein Gerät da ist.\nStatt zu raten, habe ich also das Modell gefragt, welche Fremdschlüssel wirklich zwingend sind, und dann versucht, jede Regel über die API zu brechen, um zu sehen, was zurückkommt.\nPOST /api/dcim/device-types/ no manufacturer {\u0026#34;manufacturer\u0026#34;: [\u0026#34;This field is required.\u0026#34;]} POST /api/dcim/devices/ no device type {\u0026#34;device_type\u0026#34;: [\u0026#34;This field is required.\u0026#34;]} POST /api/dcim/interfaces/ no device {\u0026#34;device\u0026#34;: [\u0026#34;This field is required.\u0026#34;]} POST /api/ipam/aggregates/ no RIR {\u0026#34;rir\u0026#34;: [\u0026#34;This field is required.\u0026#34;]} POST /api/circuits/circuits/ no provider, no type {\u0026#34;provider\u0026#34;: [\u0026#34;This field is required.\u0026#34;], \u0026#34;type\u0026#34;: [\u0026#34;This field is required.\u0026#34;]} POST /api/virtualization/virtual-machines/ nothing at all {\u0026#34;__all__\u0026#34;: [\u0026#34;A virtual machine must be assigned to a site, cluster, or device.\u0026#34;]} Jedes einzelne hat verweigert und genau gesagt, was fehlte. Hier dieselbe Information als Liste von Voraussetzungen:\nZum Anlegen von Vorher nötig Optional, aber du willst es vorher Tenant nichts eine Tenant-Gruppe Region, Site group nichts ein übergeordnetes gleicher Art, sie verschachteln Site nichts eine Region, eine Site group, ein Tenant Location eine Site eine übergeordnete Location, ein Tenant Rack type ein Manufacturer Rack eine Site eine Location, Rack group, Rack role, Rack type, Tenant Device type ein Manufacturer Device role nichts eine übergeordnete Device role, sie verschachteln Device eine Device role, ein Device type, eine Site ein Rack und eine Position, eine Platform, ein Tenant Interface und jede andere Komponente ein Device Cable zwei Dinge zum Abschließen ein Tenant Aggregate ein RIR ein Tenant VLAN nichts eine VLAN group, eine Role, ein Tenant Prefix nichts eine Site, ein VLAN, eine Role, ein VRF, ein Tenant IP address nichts ein Interface, dem es zugewiesen wird, ein Tenant Circuit ein Provider und ein Circuit type ein Tenant Circuit termination ein Circuit eine Site zum Landen Cluster ein Cluster type eine Cluster group, eine Site, ein Tenant Virtual machine eine Site, ein Cluster oder ein Device eine Platform, ein Tenant VM interface eine Virtual machine Die zweite Spalte ist die, die dich etwas kostet. Prefixes, IP-Adressen, VLANs und Tenants brauchen gar nichts, es hält dich also nichts davon ab, sie an Tag eins in beliebiger Reihenfolge anzulegen. Ob sie dann nützlich sind, ist eine andere Frage, denn eine Adresse ohne Interface dahinter ist eine Zeile in einer Liste, und ein Gerät ohne Tenant ist ein Gerät, das du später noch einmal bearbeitest.\nDie Reihenfolge, in der man wirklich arbeitet Daraus ergibt sich eine Abfolge. Arbeite sie ab, und nichts verweigert dir je etwas.\nZuerst die Dinge, an denen alles andere hängt. Nichts davon ist aufregend, und alles davon ist billig falsch zu machen.\nTenant-Gruppen, dann Tenants. Mach die vor allem anderen. Achtundzwanzig Modelle nehmen einen Tenant, darunter Site, Location und Rack, wenn die Kunden also noch nicht existieren, kannst du sie nicht unterwegs mitstempeln und wirst später massenhaft nachbearbeiten. Regionen und Site groups. Beide optional, beide in sich verschachtelbar, und sie sind unabhängig voneinander. Regionen sind für Geografie, Site groups für Funktion, und du kannst eines, beides oder keines nutzen. Sites. Die Wurzel von fast allem. Eine Site braucht nichts, weshalb sie das Erste ist, was du wirklich anlegen kannst. Locations. Die brauchen eine Site, und sie verschachteln, eine Halle mit Reihen mit Pods ist also ein Modell in drei Ebenen. Rack roles und Rack groups. Beide optional. Rack groups sind flach und stehen neben Locations als zweite Achse, was für Reihen und Pods praktisch ist. Manufacturers, dann Rack types. Ein Rack type braucht einen Manufacturer. Lass Rack types weg, wenn du die Schränke selbst nicht modellierst. Racks. Die brauchen eine Site. Wenn du einem auch eine Location gibst, muss diese Location zu dieser Site gehören, und NetBox prüft das. Dann der Hardware-Katalog, nicht die Hardware. Bevor du ein einziges Gerät anlegen kannst, brauchst du Manufacturers, Device types, Device roles und, in der Praxis, Platforms.\nManufacturers. Einige hast du vielleicht schon aus Schritt 6, denn Rack types brauchen sie auch. Module types ebenso. Device types, jeder mit einem Manufacturer. Device roles, die verschachteln, und Platforms. Das ist der Schritt, den Leute überspringen, und es ist der Schritt, der entscheidet, wie viel Tipparbeit der Rest des Jobs kostet. Ein Device type trägt seine eigenen Interfaces, Ports und Bays als Templates, jedes Gerät, das du daraus anlegst, kommt also mit den richtigen Komponenten schon daran. Mach den Typ einmal richtig, und vierzig davon einzuracken sind vierzig Namen.\nPlatform ist der Sonderfall in dieser Liste, denn ein Gerät braucht streng genommen keine. Mach es trotzdem jetzt. Sie trägt später das Config-Template und den NAPALM-Treiber, und sie auf einem bestehenden Bestand nachzutragen ist derselbe Abend, den du für Tenants aufgewendet hättest.\nDann die Technik selbst.\nDevices. Rolle, Typ und Site sind alle zwingend. Rack und Position sind optional, und wenn du sie angibst, müssen sie zur Site passen. Komponenten, falls der Device type sie nicht schon geliefert hat. Kabel, zwischen den Komponenten. Dann die Adressierung, denn eine Adresse will ein Interface, auf dem sie lebt, und das Interface existiert erst nach Schritt 12.\nRIRs, dann Aggregates. Prefix- und VLAN-Rollen, VRFs, VLAN groups, dann VLANs. Prefixes, dann die einzelnen IP-Adressen. Dann die kommerzielle Schicht.\nProviders, Provider accounts und Circuit types. Circuits, dann terminiere sie auf Sites. Und der virtuelle Bestand, der den physischen spiegelt.\nCluster types und Cluster groups, dann Cluster. Virtuelle Maschinen, die eine Site, ein Cluster oder ein Device brauchen, dann deren Interfaces. Die Schritte 1 bis 10 sind ein Nachmittag und fühlen sich wie Verwaltung an. Daran ist nichts glamourös. Sie sind auch der Nachmittag, der entscheidet, ob Schritt 11 einen Morgen oder zwei Wochen dauert.\nDie Regeln, die später beißen Pflichtfelder sind die leichte Hälfte, denn sie scheitern sofort und sagen dir, warum. Die Leute erwischt es bei den Konsistenzregeln, und die feuern erst, wenn du genug Daten hast, um dir selbst zu widersprechen:\ndevice at Leeds, put in a Manchester rack {\u0026#34;rack\u0026#34;: [\u0026#34;Rack MCR1-A07 (A07) does not belong to site Leeds Edge.\u0026#34;]} device at Leeds, in a Manchester location {\u0026#34;location\u0026#34;: [\u0026#34;Location Hall 2 does not belong to site Leeds Edge.\u0026#34;]} rack at Leeds, in a Manchester location {\u0026#34;__all__\u0026#34;: [\u0026#34;Assigned location must belong to parent site (Leeds Edge).\u0026#34;]} a second device in a unit that is already taken {\u0026#34;position\u0026#34;: [\u0026#34;U39.0 is already occupied or does not have sufficient space to accommodate this device type: MX204 (1.0U)\u0026#34;]} Die letzte ist die, auf die ich zeigen würde, wenn jemand fragt, warum man sich das alles antut. NetBox weiß, dass das Gerät 1U hoch ist, weiß, was im Schrank steht, und lässt dich nicht zwei Dinge im selben Raum festhalten. Deine Tabelle lässt dich das den ganzen Nachmittag machen und sagt kein Wort, und du findest es heraus, wenn jemand mit einem Karton in den Händen in der Halle steht.\nNichts davon ist konfigurierbar, und nichts davon sollte es sein. Das ist der Unterschied zwischen einer Aufzeichnung und einem Wunsch.\nIm Einsatz: Was jeder Bildschirm dir gibt Mit eingepflegtem Bestand ist hier, was du wirklich wieder herausbekommst. Alles Folgende ist dieselbe Instanz: ein Schrank, vierzehn Geräte, verkabelt und adressiert über drei Kunden hinweg.\nEin Gerät sind seine Komponenten Klick in einen dieser Hypervisoren hinein, und der interessante Tab ist nicht die Übersicht, sondern die Interfaces.\nLies eine Zeile quer. Das Interface, seine Geschwindigkeit, was du darüber geschrieben hast, die Adresse darauf, das Label am Kabel und der Port am anderen Ende. Das ist eine Abfrage, und es ist die Antwort auf die Frage, die alle wirklich stellen, nämlich „was hängt hier dran“.\nBeachte, wo die Adresse sitzt. Sie ist auf eno1, nicht auf dem Server. Das klingt nach Pedanterie, genau bis du eine Kiste mit einem Management-Interface, zwei Daten-Interfaces und einem Loopback hast und jemand fragt, welche Adresse für sie antwortet. Ein Modell, das Adressen an Geräte hängt, kann es dir nicht sagen. Dieses kann es, und es kann auch den völlig gewöhnlichen Fall von vier Adressen auf einem Interface halten.\nDem Kabel folgen Kabel enden an Komponenten, nicht an Geräten. Ein Interface an einem Ende, ein Interface am anderen, oder ein Front Port, ein Rear Port, eine Power Outlet, ein Circuit Termination. Das ist das Detail, auf dem das ganze Feature ruht, und es ist der Grund, warum die Interface-Liste oben das andere Ende in einer eigenen Spalte ausgeben konnte, ohne dass man es ihr gesagt hat.\nModelliere ein Kabel von Gerät zu Gerät, und du hast ein Bild gemalt. Schließ es an den Ports ab, und NetBox kann es ablaufen.\nHier ein Hop, weil es ein Direct-Attach-Kabel ist. Setz Patchpanels in die Mitte, und es läuft sie ab, Panel für Panel, und sagt dir, was am anderen Ende einer Strecke durch drei Schränke hängt. Das ist der Job, der sonst eine Taschenlampe und jemanden braucht, der das andere Ende einer Tonsonde hält.\nDie Verfolgung gibt außerdem den vollständigen Ort jedes Endes aus. Standort, Halle, Schrank, Seite, Höheneinheit. Wenn du je in einem Telefonat versucht hast, einem Remote-Hands-Techniker zu erklären, welche Kiste er ansehen soll, ist diese Zeile der ganze Wert.\nAdressen, als Baum statt als Tab IPAM ist die Hälfte, für die Leute kommen.\nDie Einrückung wird aus den Adressen selbst berechnet. Du sagst NetBox nicht, dass 10.20.20.0/24 in 10.20.0.0/16 sitzt, es rechnet das aus, und es wird es weiter ausrechnen, wenn nächstes Jahr jemand ein /26 mitten hinein setzt.\nJede Zeile trägt die Dinge, nach denen du wirklich filterst: das VLAN, auf das sie zeigt, die Rolle und den Kunden, dem sie gehört. Die Auslastung wird auch berechnet.\nÖffne eines, und du bekommst die Adressen darin, und die Lücken.\nDiese grünen Zeilen sind der freie Raum, in einer Linie mit dem belegten gezeigt. Es gibt einen API-Aufruf, der dir die nächste freie Adresse aus einem Prefix gibt, und das ist das eine Stück IPAM-Automatisierung, das sich sofort bezahlt, denn es ist das, was Leute sonst machen, indem sie auf eine Tabelle schielen und hoffen.\nEin Interface nimmt so viele Adressen, wie du willst, aus beiden Familien, und du benennst je eine als primäre des Geräts.\nZwei IPv4 und zwei IPv6 auf einem Port, was ein gewöhnlicher Dienstag ist und etwas, das ein gerätezentriertes Modell überhaupt nicht ausdrücken kann.\nTrag Adressen mit der Maske des Netzes ein, auf dem sie liegen, nicht als /32. NetBox nimmt 10.20.20.11/32 an und sortiert es unter das richtige Prefix, denn die Zugehörigkeit wird aus der Host-Adresse ermittelt. Was es nicht tut, ist dich hinterher zu überstimmen: Die Maske wird genau so gespeichert, wie sie getippt wurde, und so an alles weitergegeben, was sie liest, ein /32 auf einer LAN-Adresse rendert also ein /32 in die Gerätekonfiguration. Die Stelle, an der das beißt, ist drei Monate später in einem Config-Template, nicht heute im Formular.\nEine Installation, drei Kunden Die meisten Objekte in NetBox können einem Tenant zugewiesen werden. Ein Unternehmen nutzt das für Geschäftsbereiche. Wenn du Managed Services verkaufst, legst du einen pro Kunde an.\nDieses Panel rechts ist die Antwort auf „was hat dieser Kunde“, und es hat sich selbst zusammengestellt. Kein Report, keine Tabelle, kein Fragen des Technikers, der es gebaut hat.\nEs lohnt sich, bei der Bedeutung von Tenancy genau zu sein, denn es an Tag eins falsch zu machen bedeutet ein Jahr Entwirren später. Ein Tenant heißt, das Objekt ist diesem Kunden zugeordnet. Ein Router, der nur ihn bedient, bekommt seinen Tenant. Eine Firewall, die vier von ihnen bedient, gehört keinem von ihnen, bekommt also keinen, und die Beziehung geht woandershin. Dazu weiter unten mehr, denn das ist der Punkt, an dem die meisten merken, dass sie etwas Eigenes hinzufügen müssen.\nTrag die Zahlen am Gerätetyp ein Das ist der Schritt, der ein Inventar von etwas trennt, das Fragen beantwortet, und er kostet etwa zehn Minuten pro Gerätetyp.\nEin Device type kann sein Gewicht tragen und, über seine Power-Port-Templates, seine Leistungsaufnahme. Trag die einmal am Typ ein, und jedes Gerät, das du je daraus anlegst, erbt sie. Lass sie weg, und NetBox sagt dir bereitwillig, dass ein Schrank zu 28,6 % voll ist, und nichts weiter.\nIch habe allen fünf Typen hier ein Gewicht gegeben, jedem zwei Power-Port-Templates mit einer maximalen und einer zugewiesenen Aufnahme, dem PDU-Typ einen Inlet und zwölf Outlets, dann ein Power Panel und zwei Feeds in den Schrank angelegt und das Ganze verkabelt: jedes PSU1 jedes Geräts an PDU A, jedes PSU2 an PDU B und den Inlet jeder PDU an ihren Feed.\nDann verändert sich die Rack-Seite vollständig.\nPlatzauslastung 28,6 %. Stromauslastung 90,7 %.\nDieser Schrank ist zu einem Drittel voll mit Technik und nahezu ohne Strom, und das ist eine Tatsache über deinen Bestand, die keine Tabelle jemals von sich aus beisteuern wird. Es ist auch die Tatsache, die entscheidet, ob die nächste Bestellung dort oder woanders eingeracked wird, und sie fiel aus Daten heraus, die du einmal eingetragen hast, an den Typen.\nZwei Dinge, die es auf null stehen lassen Ich hatte zuerst 0,0 %, zweimal, und beide Ursachen sind es wert, sie zu kennen, denn keine erzeugt einen Fehler.\nDie Outlets müssen auf den Inlet verweisen. Eine Power Outlet an einer PDU hat ein Feld power_port, das auf den vorgelagerten Port am selben Gerät zeigt. Lass es leer, und die Kette ist gebrochen: NetBox hat keine Möglichkeit zu wissen, dass diese zwölf Outlets von jenem Inlet versorgt werden, also aggregiert nichts.\nLass die Aufnahmefelder des Inlets leer. Das ist das Gegenintuitive. NetBox berechnet die Aufnahme eines Power Ports aus dem, was daran hängt, nur wenn seine beiden eigenen Aufnahmefelder leer sind:\nif self.allocated_draw is None and self.maximum_draw is None: ...aggregate the downstream power ports... # otherwise return {\u0026#39;allocated\u0026#39;: self.allocated_draw or 0, ...} Ich hatte hilfsbereit maximum_draw: 7400 am PDU-Inlet gesetzt, denn darauf ist die PDU ausgelegt. NetBox hat mir daher geglaubt, allocated_draw als nicht gesetzt genommen und null gemeldet. Lösch beides, und es rechnet es aus:\nmcr1-pdu-a INPUT -\u0026gt; allocated 5340 VA, maximum 8480 VA, across 12 outlets mcr1-pdu-b INPUT -\u0026gt; allocated 5340 VA, maximum 8480 VA, across 12 outlets feed MCR1-A07-A: available 5888 VA (230 V x 32 A x 80% max utilisation) RACK power utilisation: 90.7 % RACK weight: 166.6 kg of 900 kg Die Regel lautet also: Trag echte Zahlen an den Blättern ein und lass die Zwischenports leer, damit NetBox sie zusammenzählen kann. Ein administrativ gesetzter Wert gewinnt immer gegen den berechneten, was korrektes Verhalten und an einer PDU genau das Falsche ist.\nKühlung, die neu ist Version 4.7 hat Kühlung zu DCIM hinzugefügt, und sie kam mit der Hälfte an, die teuer wird. Ein Rack trägt eine Cooling capability von Luft, hybrid oder flüssig und eine Kapazität in Kilowatt; ein Device type trägt eine Cooling method. Darüber sitzen Cooling Sources für die Kältemaschinen und CRAC-Einheiten, Cooling Feeds, die einen Kreislauf zu einem Rack darstellen, und Intake- und Outflow-Komponenten an den Geräten selbst für Kühlplatten und Verteiler.\nDer Schrank oben liest Hybrid, 15,00 kW, weil ich das dem Rack so gesagt habe. Wenn du dieses Jahr flüssiggekühlte Technik annimmst, ist das ein Modell für das, was du gerade in einer Tabelle hältst.\nEine Installation, viele Kunden Tenancy ist der Grund, warum ein Provider ein NetBox betreiben kann statt eines pro Kunde, und es lohnt sich zu verstehen, was es tut und, wichtiger, was es nicht tut.\nAchtundzwanzig von NetBox\u0026rsquo; Modellen tragen ein Tenant-Feld. Sites, Locations, Racks und Rack-Reservierungen. Devices, Kabel und Virtual Device Contexts. Prefixes, IP-Adressen, Ranges, Aggregates, VLANs, VLAN groups, VRFs, Route Targets, ASNs. Circuits und Circuit groups. Cluster und virtuelle Maschinen. Tunnel, L2VPNs, Wireless LANs und Links. Power Feeds und Cooling Feeds.\nDas ist jedes abrechenbare Substantiv. Setz es konsequent, und „was hat dieser Kunde“ hört auf, eine Ermittlung zu sein.\nAber ein Tenant ist ein Label, kein Schloss. Er sagt, das Objekt ist diesem Kunden zugeordnet. Er hält niemanden, der sich anmelden kann, davon ab, das Ganze zu lesen, was innerhalb einer Firma in Ordnung ist und überhaupt nicht mehr, sobald ein Kunde ein Konto hat.\nZwei Dinge folgen daraus, und das zweite ist das, was Leute falsch machen.\nEin Tenant heißt zugeordnet. Ein Router, der nur einen Kunden bedient, bekommt dessen Tenant. Eine Firewall, die vier bedient, gehört keinem davon, bekommt also nichts, und du hältst die Beziehung stattdessen an dem fest, was du tatsächlich verkauft hast. Einen Tenant auf geteilte Technik zu zwingen macht jeden Report, der auf Tenancy aufbaut, still und leise falsch.\nUnd Zugriff ist ein völlig eigener Mechanismus.\nIn den Permissions sitzt die Isolation NetBox\u0026rsquo; Object Permissions nehmen eine JSON-Einschränkung, und die Einschränkung ist ein Django-ORM-Filter. Sie verengt das Queryset, bevor irgendetwas daraus gebaut wird, jede Ansicht, jeder Export, jeder API-Aufruf und jede Suche wird also damit verengt.\nDrei Felder machen die Arbeit. Die Objekttypen, für die sie gilt, die Aktionen, die sie gewährt, und diese Einschränkung unten. Alles andere ist Buchhaltung.\nHier die Geräteliste als Administrator.\nUnd hier dieselbe URL, dieselbe Installation, angemeldet als der Kunde.\nZwei Zeilen statt vierzehn, und schau auf das linke Menü. Es ist auf die vier Dinge zusammengefallen, die dieses Konto anfassen darf. Das hat niemand konfiguriert. Die Navigation wird aus denselben Permissions gebaut, ein Kunde sieht also nie einen Link auf etwas, das ihn abweisen würde.\nDie zwei Arten, nein zu sagen Das ist das Detail, das man kennen sollte, denn die zwei Abweisungen bedeuten Unterschiedliches, und beide sind gewollt.\nDas Token des Kunden fragt nach Es bekommt /api/dcim/devices/ 200, eine Zeile von zwei /api/dcim/devices/1/, sein eigenes 200 /api/dcim/devices/2/, das von jemand anderem 404 /api/tenancy/tenants/ 403 /api/dcim/sites/, nie gewährt 403 gar kein Token 403 404 heißt, der Typ ist deiner, aber diese Zeile nicht. Die Einschränkung hat sie aus dem Queryset entfernt, für die Anfrage existiert sie also nicht. Ein 403 dort würde bestätigen, dass sie existiert, und einem neugierigen Kunden erlauben, deinen Bestand durch Ablaufen der IDs zu zählen.\n403 heißt, der Typ war nie deiner. Tenants und Sites wurden nie gewährt, sie verweigern also direkt, und der Kunde kann nicht aufzählen, wer sonst auf der Plattform ist.\nDann lass sie schreiben Nur lesen ist der leichte Fall. Die echte Frage ist, ob man einem Kunden mit Schreibrechten diese zutrauen kann, ich habe also change unter derselben Einschränkung gewährt und nach dem Weg nach draußen gesucht.\nVersuch Ergebnis Sein eigenes Gerät bearbeiten 200, gespeichert Das Gerät eines anderen Kunden bearbeiten 404 Sein eigenes Gerät bearbeiten und auf den Tenant des anderen Kunden verschieben 403 Sein eigenes Gerät löschen 403, delete wurde nie gewährt Die dritte Zeile ist die entscheidende. Das eigene Gerät dem Tenant eines anderen zuzuweisen ist der naheliegende Ausbruch, denn das Objekt ist bei Ankunft der Anfrage innerhalb deiner Einschränkung und danach außerhalb. NetBox prüft die Einschränkung gegen den Zustand, in dem das Objekt zurückbleiben würde, also verweigert es. Ich habe das Gerät zurückgelesen, statt dem Statuscode zu trauen, und der Tenant hatte sich nicht bewegt.\nDas ist das Loch, das selbstgebaute Mandantenfähigkeit meist offen lässt, und gefunden wird es normalerweise von einem Kunden und nicht von einem Test.\nVariablen, die vererben müssen Hier die Unterscheidung, die Leute falsch machen, und sie richtig zu machen erspart viel Bearbeitung.\nEin Custom Field ist ein Wert an einem Objekt. Du setzt ihn pro Objekt, und dort bleibt er. Gut für eine Tatsache über das Ding selbst: ein Asset Tag, eine Supportvertragsnummer, ein Inbetriebnahmedatum.\nEin Config Context ist ein Wert, der an einer Eigenschaft hängt und den alles erbt, was auf diese Eigenschaft passt. Gut für eine Variable, die durchrieseln soll: deine NTP-Server, deine Syslog-Ziele, deine SNMP-Community, deine DNS-Domain, dein Management-VLAN, dein Backup-Fenster.\nWenn du dich dabei erwischst, dasselbe Custom Field an vierzig Geräten auf denselben Wert zu setzen, wolltest du einen Config Context.\nEin Context ist beliebiges JSON, und er kann an eine Region, Site group, Site, Location, einen Device type, eine Rolle, Platform, ein Cluster, einen Cluster type, eine Cluster group, Tenant group, einen Tenant oder ein Tag gehängt werden. Tenant steht in dieser Liste, und für einen Provider heißt das: Eine Tatsache, die für einen Kunden überall gilt, folgt ihm auf jedes Gerät, das du je für ihn anlegst.\nDie Zusammenführung erfolgt pro Schlüssel, und das Gewicht entscheidet, wer jeden einzelnen gewinnt.\nLies das rechte Panel gegen das linke. Die Region liefert vier Schlüssel mit Gewicht 1000. Die Site liefert einen Schlüssel mit Gewicht 2000. Der gerenderte Context behält Domain, NTP-Server und Community der Region unangetastet und nimmt den Syslog-Server der Site, denn das ist der einzige Schlüssel, um den irgendetwas gestritten hat.\nDu schreibst die Ausnahme, nicht eine frische Kopie von allem mit der Ausnahme darin. Das ist der ganze Wert, und deshalb skaliert das, wo eine Variablendatei pro Gerät es nicht tut.\nLokaler Context gewinnt gegen alles darüber Der Vererbungsstapel hat eine Spitze, und das ist das Objekt selbst. Local Context Data an einem Gerät gewinnt gegen jeden Source Context, der darauf zutrifft, egal welche Gewichte.\nIch habe das an mcr1-core-01 gesetzt:\n{\u0026#34;syslog_servers\u0026#34;: [\u0026#34;10.20.10.99\u0026#34;], \u0026#34;note\u0026#34;: \u0026#34;this box logs somewhere else\u0026#34;} und sein gerenderter Context wurde:\n{ \u0026#34;note\u0026#34;: \u0026#34;this box logs somewhere else\u0026#34;, \u0026#34;domain\u0026#34;: \u0026#34;mcr1.example.net\u0026#34;, \u0026#34;ntp_servers\u0026#34;: [\u0026#34;172.16.10.22\u0026#34;, \u0026#34;172.16.10.33\u0026#34;], \u0026#34;snmp_community\u0026#34;: \u0026#34;n0rthwest\u0026#34;, \u0026#34;syslog_servers\u0026#34;: [\u0026#34;10.20.10.99\u0026#34;] } Der lokale Syslog-Server hat sowohl das Site-Override mit Gewicht 2000 als auch die Region mit Gewicht 1000 geschlagen. Alles, worüber er nichts gesagt hat, wurde weiter vererbt, die Domain, die NTP-Server und die Community kamen also unangetastet durch, und der neue Schlüssel wurde einfach hinzugefügt.\nDas ist die Notluke für die eine Kiste, die wirklich anders ist, und das Panel sagt dir klar, dass es alle Source Contexts überschreibt. Wenn du dich dabei erwischst, das an vielen Geräten statt an einem zu nutzen, hast du eine Eigenschaft gefunden, die diese Geräte teilen, und wolltest einen Context, der darauf zugeschnitten ist.\nDrei Fallen Ein Context ohne Zuweisung ist global. Leg einen an und vergiss, ihn irgendetwas zuzuweisen, und er gilt für jedes Gerät und jede virtuelle Maschine, die du hast. Das ist dokumentiertes Verhalten und gelegentlich das, was du willst. Es ist auch lautlos.\nSchlüssel dürfen keine Bindestriche haben, wenn du sie einfach erreichen willst. Context-Daten sind JSON, ntp-servers ist also völlig legal, aber Jinja-Variablennamen sind keine JSON-Schlüssel. {{ ntp-servers }} wird als Subtraktion geparst und löst UndefinedError: 'ntp' is undefined aus. Schreib {{ ntp_servers }} gegen Daten mit Bindestrich, und du bekommst einen leeren String, HTTP 200 und nirgends eine Warnung. Nimm Unterstriche in den Schlüsseln, und das naheliegende Template funktioniert.\nEin Profil kann die Tippfehler stoppen. Ein Config-Context-Profil gruppiert verwandte Contexts und erzwingt beim Speichern ein JSON-Schema auf deren Daten. Ich habe einem ein Schema gegeben, das syslog_servers als Array von IPv4-Strings verlangt, und dann die zwei Fehler gemacht, die Leute wirklich machen:\n{\u0026#34;syslog-server\u0026#34;: [\u0026#34;10.1.1.1\u0026#34;]} singular, by accident 400 Data does not conform to profile schema: \u0026#39;syslog-servers\u0026#39; is a required property {\u0026#34;syslog_servers\u0026#34;: [...], \u0026#34;syslog_port\u0026#34;: 99999} 400 Data does not conform to profile schema: 99999 is greater than the maximum of 65535 Abgewiesen dort, wo jemand sie gemacht hat, und nicht vierhundert Geräte später.\nDie Konfiguration rendern Context-Daten plus ein Jinja-Template geben dir eine Konfigurationsdatei. Das Gerät ist als device im Scope, sein zusammengeführter Context ist als gewöhnliche Variablen im Scope, und du kannst seine Komponenten ablaufen.\nAlles auf dieser Seite kam von woanders her, und das ist der Punkt:\nZeile Woher sie kam host-name mcr1-core-01 vom Gerät domain-name mcr1.example.net vom regionalen Config Context location \u0026quot;Manchester DC1 / MCR1-A07 / U39\u0026quot; von der Site, dem Rack und der Position darin server 172.16.10.22 vom regionalen Context, Gewicht 1000 host 10.20.10.99 any notice vom eigenen lokalen Context des Geräts, das sowohl Site als auch Region schlägt family inet address 10.20.10.11/24 von der Adresse auf diesem Interface, mit der Maske wie getippt Das Template wird über das Gerät, dann die Rolle, dann die Platform aufgelöst, und die Anfrage scheitert, wenn keines der drei eines hat. Du weist also einer Platform einmal ein Template zu, und jedes Gerät, das diese Software fährt, rendert daraus, sofern nicht seine Rolle oder das Gerät selbst etwas anderes sagt. Dafür ist eine Platform da: das Betriebssystem oder die Softwarefamilie des Herstellers, nicht die Hardware.\nNetBox rendert. Es schiebt nicht. Die Ausgabe auf die Kiste zu bekommen ist die Aufgabe deiner Automatisierung, und an dem Tag, an dem ein Template-Fehler sonst vierhundert Geräte umkonfiguriert hätte, wirst du froh sein, dass das zwei verschiedene Systeme sind.\nPlugins Ein Plugin ist eine Django-Anwendung, die neben NetBox installiert wird. Es kann Modelle hinzufügen, Seiten hinzufügen, beide APIs erweitern, Inhalte in bestehende Templates einspeisen, Navigation hinzufügen, Background-Job-Queues hinzufügen und weitere Django-Apps laden. Es gibt sehr wenig, was es nicht kann, denn darunter ist es einfach Django.\nEines zu installieren sind vier Befehle und ein Neustart:\nsource /opt/netbox/venv/bin/activate pip install netbox-topology-views netbox-qrcode # add the package names to PLUGINS in configuration.py, then python3 manage.py migrate python3 manage.py collectstatic --no-input sudo systemctl restart netbox netbox-rq Im Container-Stack kommen dieselben Pakete in plugin_requirements.txt und du baust das Image neu. In beiden Fällen gilt: pinne die Versionen und prüf vorher die Kompatibilitätsmatrix, denn ein Plugin, das einem NetBox-Release nicht nachgekommen ist, verweigert den Start der ganzen Anwendung, statt sich selbst zu deaktivieren.\nDer veröffentlichte Katalog listet 31. Diese sind die, die man kennen sollte, mit der Lizenz, unter der jedes wirklich ausgeliefert wird:\nPlugin Was es tut Lizenz DNS Zonen, Records und Nameserver als Source of Truth MIT BGP Sessions, Communities und Routing-Policies Apache 2.0 Topology Views Grafische Topologiekarten, aus deinen Kabeln gebaut Apache 2.0 Floorplan Grafische Standort- und Location-Karten LGPL 3.0 QR Code Codes auf Racks, Geräten und Kabeln, für Asset-Labels Apache 2.0 ACLs Access-Lists und Regeln Apache 2.0 Prometheus SD Liefert Prometheus seine Hostliste direkt aus NetBox MIT Documents Dokumente, an Circuits und Geräte angehängt Apache 2.0 Lifecycle Hardware-End-of-Life, Lizenzen und Verträge Apache 2.0 Contract Verträge und Rechnungen MIT Reorder Rack Höheneinheiten per Drag and Drop Apache 2.0 Branching Isolierte, zusammenführbare Branches deiner Daten NetBox Limited Use Custom Objects Neue Objekttypen, in der UI definiert NetBox Limited Use Prometheus SD ist die ehrliche Form der ganzen Idee. NetBox weiß, was existiert, also lass NetBox es dem Monitoring sagen und hör auf, eine zweite Hostliste zu pflegen, die auseinanderdriftet.\nEines solltest du wissen, bevor du auf den letzten zwei Zeilen aufbaust. NetBox selbst ist Apache 2.0 und ist das seit der Freigabe durch DigitalOcean 2016, und das Projekt wird heute von NetBox Labs gemeinsam mit einem Team freiwilliger Maintainer betreut.21 NetBox Branching und NetBox Custom Objects sind es nicht: Sie werden unter der NetBox Limited Use License 1.0 ausgeliefert, die die Nutzung „only as part of a NetBox installation obtained from NetBox Labs or a NetBox distributor authorized by NetBox Labs, and only for your own internal use“ gewährt und die nicht das Recht gewährt, die Software zu nutzen, „to provide a managed service or software products that includes, integrates with, or extends NetBox in a way that competes with any product or service of NetBox Labs“. Wenn du NetBox Community von GitHub installiert hast und es im Auftrag von Kunden betreibst, lies die Bedingungen selbst, bevor du ein Schema dahinter stellst.10 NetBox\u0026rsquo; eigene Installationsanleitung empfiehlt beide Plugins, ohne das zu erwähnen.11\nCustom Fields Ein Custom Field fügt einem bestehenden Modell ein Attribut hinzu. Werte werden als JSON neben jedem Objekt gespeichert, es gibt also keine Migration und keinen Neustart, und es gibt dreizehn Typen, darunter Objekt- und Multi-Objekt-Referenzen auf andere NetBox-Datensätze.\nZwei Felder dort, gruppiert unter einer Überschrift „Asset“, die ich gewählt habe. Beachte das Panel Dimensions rechts davon: 9,5 kg, die niemand an diesem Gerät eingetippt hat. Sie kamen vom Gerätetyp.\nCustom Fields werden validiert, und es lohnt sich zu wissen, dass sie es werden, denn es ist ein echter Unterschied zum Weg weiter unten. Ich habe dem Vertragsfeld einen regulären Ausdruck gegeben, und die API hat ihn erzwungen:\nPATCH {\u0026#34;custom_fields\u0026#34;: {\u0026#34;support_contract\u0026#34;: \u0026#34;nonsense\u0026#34;}} {\u0026#34;__all__\u0026#34;: [\u0026#34;Invalid value for custom field \u0026#39;support_contract\u0026#39;: Value must match regex \u0026#39;^[A-Z]{2,4}-[0-9]{6}$\u0026#39;\u0026#34;]} Zwei Dinge haben sich in 4.7 geändert, die in der Breite zählen. Ein Feld mit einem Standardwert anzulegen oder ein Feld zu löschen muss die gespeicherten Daten jedes Objekts umschreiben, für das es gilt, auf einer großen Tabelle wird diese Arbeit also an einen Background-Job übergeben, und das Feld meldet „provisioning“ oder „deleting“, während das läuft. Ein Feld ist nur live, solange es aktiv ist: Während einer dieser Operationen erscheint es nicht an Objekten, nicht in Formularen, nicht in Filtern und in keiner der beiden APIs. Dafür muss ein Worker laufen, sonst bleibt es unbegrenzt in diesem Zustand.\nNimm ein Custom Field, wenn du eine Tatsache über das Ding selbst hinzufügst. Nimm einen Config Context, wenn der Wert durchrieseln soll. Nimm den nächsten Abschnitt, wenn das, was du brauchst, nicht existiert.\nEigene Auswahlmenüs, und das Überschreiben dessen, was ausgeliefert wird Zwei verschiedene Mechanismen liegen unter dieser Überschrift, und sie lösen verschiedene Probleme. Einer ist für deine eigenen Felder. Der andere schreibt NetBox\u0026rsquo; um.\nEin Choice Set, für dein eigenes Auswahlfeld Ein Custom Field vom Typ „selection“ zieht seine Optionen aus einem Choice Set, einem Objekt, das du in der UI verwaltest wie alles andere. So wird „support tier“ ein echtes Dropdown statt Freitext, den jemand auf drei Arten schreibt.\nEs wird erzwungen, auch über die API:\nPATCH {\u0026#34;custom_fields\u0026#34;: {\u0026#34;support_tier\u0026#34;: \u0026#34;platinum\u0026#34;}} {\u0026#34;__all__\u0026#34;: [\u0026#34;Invalid value for custom field \u0026#39;support_tier\u0026#39;: Invalid choice (platinum) for choice set Support tier.\u0026#34;]} Choice Sets werden geteilt, ein Set kann also dasselbe Feld auf mehreren Modellen tragen, und die Liste an einer Stelle zu ändern ändert sie überall.\nFIELD_CHOICES, für NetBox\u0026rsquo; eigene Felder Das ist das, von dem Leute nicht wissen, dass es existiert. Mehrere der eingebauten Auswahlfelder von NetBox können aus configuration.py erweitert oder ersetzt werden, darunter Gerätestatus, Standortstatus, Rack-Status, Circuit-Status und viele weitere.12\nHäng ein Plus an, um zu dem hinzuzufügen, was ausgeliefert wird. Lass es weg, um die Liste komplett zu ersetzen.\nFIELD_CHOICES = { # add to what NetBox ships with \u0026#39;dcim.Device.status+\u0026#39;: ( (\u0026#39;burn-in\u0026#39;, \u0026#39;Burn-in\u0026#39;, \u0026#39;cyan\u0026#39;), {\u0026#39;value\u0026#39;: \u0026#39;awaiting-rma\u0026#39;, \u0026#39;label\u0026#39;: \u0026#39;Awaiting RMA\u0026#39;, \u0026#39;color\u0026#39;: \u0026#39;orange\u0026#39;, \u0026#39;description\u0026#39;: \u0026#39;Faulty, with the vendor\u0026#39;}, ), # replace the stock list outright \u0026#39;dcim.Site.status\u0026#39;: ( (\u0026#39;surveyed\u0026#39;, \u0026#39;Surveyed\u0026#39;, \u0026#39;purple\u0026#39;), (\u0026#39;building\u0026#39;, \u0026#39;Building out\u0026#39;, \u0026#39;orange\u0026#39;), (\u0026#39;active\u0026#39;, \u0026#39;Active\u0026#39;, \u0026#39;green\u0026#39;), (\u0026#39;closing\u0026#39;, \u0026#39;Closing\u0026#39;, \u0026#39;red\u0026#39;), ), } Genau das habe ich auf diese Instanz gelegt. Der Gerätestatus kam mit den sieben Standardwerten und meinen zwei zurück:\noffline, active, planned, staged, failed, inventory, decommissioning, burn-in, awaiting-rma und der Standortstatus kam nur mit meinen zurück, die Standardliste war weg:\nsurveyed, building, active, closing Eine Auswahl kann ein einfaches Tupel aus Wert, Label und Farbe sein oder ein Dictionary, das zusätzlich eine Beschreibung nimmt, die im Formular als Untertitel erscheint. Und sie verhalten sich überall wie native Werte, denn für den Rest von NetBox sind sie native Werte:\nDieses Badge ist mein Status, in meiner Farbe, sortiert und filtert wie jeder andere.\nDrei Dinge solltest du wissen, bevor du es nutzt.\nErsetzen löscht die Standardwerte aus dem Menü, nicht aus der Datenbank. Jedes Objekt, das schon einen davon hält, behält ihn, aber der Wert wird nicht mehr angeboten und wird beim nächsten Bearbeiten dieses Objekts keine gültige Auswahl sein. Wenn du eine Liste ersetzt, prüf, dass nichts auf einem Wert sitzt, den du gerade entfernt hast.\nEs lebt in der Konfigurationsdatei, braucht also einen Neustart und ist nichts, was ein UI-Nutzer ändern kann. Für einen Provider ist das die richtige Richtung: Welche Status dein Geschäft anerkennt, ist eine Governance-Entscheidung, keine an einem Dienstagnachmittag.\nErweitere, bevor du ersetzt. Die Standardwerte sind das, was jedes Plugin, Script und jede Integration zu sehen erwartet. Anhängen kostet nichts. Ersetzen ist eine Entscheidung, die du für immer besitzt.\nCustom Objects Hier ist eine echte Lücke. NetBox modelliert Cluster, virtuelle Maschinen und virtuelle Disks. Es modelliert nicht den Datastore, auf dem diese Disks wirklich liegen, und für jeden, der Proxmox oder VMware betreibt, ist das das Objekt, das den gekauften Speicher mit der Last verbindet, die ihn nutzt.\nDas Custom-Objects-Plugin lässt dich einen neuen Objekttyp aus der UI oder der API definieren, ohne Code zu schreiben. Also:\nSieben Felder, von denen zwei der ganze Punkt sind. cluster ist eine Einzelobjekt-Referenz auf ein echtes NetBox-Cluster, auf protect gesetzt, damit niemand ein Cluster unter seinem Speicher weglöschen kann. provisioned_by ist eine Multi-Objekt-Referenz auf die Geräte, die ihn wirklich bereitstellen.\nDas gibt dir ein erstklassiges Objekt mit eigenem Navigationseintrag, Listenansicht, Filtern, Import und Export:\nUnd weil die Referenzen echt sind, zeigt sich die Beziehung auch vom anderen Ende. Öffne das Cluster, und die Datastores sind dagegen aufgeführt.\nEin Custom Object Type erbt das meiste von dem, was ein NetBox-Objekt zu einem NetBox-Objekt macht: Listen- und Detailansichten, einen Navigationseintrag, REST-Endpunkte, Volltextsuche, Change Logging, Journaling, Tags, Bookmarks, Import und Export, Event Rules und Benachrichtigungen. Nichts davon musste geschrieben werden.\nEs ist auch kein JSON-Blob, der eine Tabelle vorgibt zu sein. Das Plugin setzt echtes DDL ab, und was in PostgreSQL erscheint, ist eine echte Tabelle mit echten Constraints:\nTable \u0026#34;public.custom_objects_2\u0026#34; Column | Type | Nullable | Default -----------------+----------+----------+------------------ id | bigint | not null | identity name | varchar | | cluster_id | bigint | | backing | varchar | | capacity_gb | bigint | | thin_provisioned| boolean | | Indexes: \u0026#34;custom_objects_2_name_key\u0026#34; UNIQUE CONSTRAINT, btree (name) Foreign-key constraints: ... FOREIGN KEY (cluster_id) REFERENCES virtualization_cluster(id) ON DELETE RESTRICT Das protect, um das ich gebeten habe, wurde zu ON DELETE RESTRICT, und es funktioniert: Dieses Cluster zu löschen kommt als 409 zurück und nennt, was davon abhängt.\nZwei Dinge, die man wissen muss, bevor man sich darauf verlässt Die Validierung sitzt am Formular, nicht an der API. Das ist die, die eine Automatisierung erwischen würde. Ich habe required, einen regulären Ausdruck und numerische Grenzen an den Feldern eines Custom Object Type deklariert und dann über die REST-API darauf geschrieben:\nWas ich deklariert habe Was ich gesendet habe Ergebnis validation_regex einen Wert, der auf nichts passt 201 Created required: true das Feld ganz weggelassen 201 Created validation_minimum: 1 eine negative Zahl 201 Created unique: true ein Duplikat 400, abgewiesen on_delete_behavior: protect das referenzierte Objekt löschen 409, abgewiesen Die zwei, die gehalten haben, sind die zwei, die zu Datenbank-Constraints wurden. Der Rest existiert nur am Webformular, ein tippender Mensch ist also eingeschränkt und ein nächtlicher Sync nicht. Vergleich das mit dem Core-Custom-Field weiter oben, wo derselbe reguläre Ausdruck über die API erzwungen wurde. Bis sich das ändert, stell alles, wovon eine Rechnung abhängt, hinter ein echtes Constraint.\nEinen Typ zu löschen wirft eine Tabelle weg. Ein Feld zu löschen wirft eine Spalte weg. Das ist DDL aus einem Webformular, ausgeführt von wem auch immer die Berechtigung hat, und die Dokumentation sagt genau das.13 Schränk ein, wer die löschen darf.\nWann du stattdessen ein echtes Plugin schreibst Wenn das Objekt wichtig ist, wenn Automatisierung darauf schreibt und wenn es dich ärgern würde, Müll darin zu finden, schreib das Modell selbst. Ein minimales NetBox-Plugin ist ein PluginConfig, ein Modell, ein Serializer, ein Viewset, eine Tabelle, ein Formular, ein paar Views und eine URL-Map, und es kommt auf unter zweihundert Zeilen überwiegend Deklarationen. PrimaryModel zu subclassen gibt dir Tags, Custom Fields, Change Logging, Journaling, Export-Templates und Ownership gratis, und jedes Constraint, das du an das Modell hängst, wird überall erzwungen, denn NetBox\u0026rsquo; eigene Serializer-Maschinerie führt es aus.\nEs gibt ein Cookiecutter-Template und ein vollständiges Plugin-Tutorial, von der Community gepflegt. Fang damit an und nicht mit einem leeren Verzeichnis.\nUnd es hat die Lizenz, die du wählst, was später niemand ändern kann.\nCustom Validation und Validierungsklassen Alles oben dreht sich darum, festzuhalten, was da ist. Hier geht es darum, zu verweigern, was nicht festgehalten werden sollte.\nNetBox validiert jedes Objekt, bevor es es schreibt, und du kannst eigene Regeln obendrauf legen. Es gibt drei Mechanismen, sie leben alle in configuration.py, und zusammen decken sie fast alles ab, was ein Hausstandard braucht.\nEins: einfache Regeln, kein Code Ein Validator kann eine einfache Zuordnung von Feldnamen zu Bedingungen sein. Kein Python, und es ist zwischen Installationen portabel, weil es nur Daten sind.\nCUSTOM_VALIDATORS = { \u0026#39;dcim.site\u0026#39;: ( {\u0026#39;description\u0026#39;: {\u0026#39;required\u0026#39;: True}}, ), \u0026#39;dcim.device\u0026#39;: ( {\u0026#39;name\u0026#39;: {\u0026#39;regex\u0026#39;: r\u0026#39;^[a-z0-9]+-[a-z]+-([0-9]{2}|[a-z])$\u0026#39;}}, ), } Die verfügbaren Bedingungen sind min, max, min_length, max_length, regex, required, prohibited, eq und neq. Du kannst mit einem Punktpfad in ein verbundenes Objekt hineingreifen, region.name an einer Site ist also erlaubt, und du kannst auf request.user.username prüfen, auch wenn die Dokumentation dir völlig zu Recht sagt, dafür lieber Permissions zu nutzen.\nBeide Regeln feuern sofort:\nPOST a site with no description {\u0026#34;__all__\u0026#34;: [\u0026#34;Custom validation failed for description: [\u0026#39;This field must not be empty.\u0026#39;]\u0026#34;]} POST a device named \u0026#34;Server1\u0026#34; {\u0026#34;__all__\u0026#34;: [\u0026#34;Custom validation failed for name: [\u0026#39;Enter a valid value.\u0026#39;]\u0026#34;]} Die zweite ist ein Namensstandard, erzwungen. Nicht auf eine Wiki-Seite geschrieben, nicht in jemandes Kopf, nicht etwas, wofür der Neue drei Wochen später in einem Review gerügt wird. Die Datenbank nimmt es nicht an.\nZwei: eine Validator-Klasse, wenn die Regel ein Satz ist Einfache Regeln prüfen ein Feld gegen eine Konstante. Echte Hausregeln sind meist bedingt: das zählt nur, wenn jenes. Dafür subclasst du CustomValidator, überschreibst validate() und rufst fail().\nIch habe drei davon in ein Modul unter /opt/netbox/netbox/house_rules.py gelegt:\nfrom extras.validators import CustomValidator class BillableKitNamesItsCustomer(CustomValidator): \u0026#34;\u0026#34;\u0026#34;Anything in a role we sell has to say whose it is.\u0026#34;\u0026#34;\u0026#34; BILLABLE_ROLES = {\u0026#39;hypervisor\u0026#39;} def validate(self, instance, request): role = getattr(instance, \u0026#39;role\u0026#39;, None) if role and role.slug in self.BILLABLE_ROLES and not instance.tenant: self.fail( f\u0026#34;A {role} is billable kit, so it must name the customer it belongs to.\u0026#34;, field=\u0026#39;tenant\u0026#39;, ) class RackedDeviceNeedsAPosition(CustomValidator): \u0026#34;\u0026#34;\u0026#34;A device in a rack with no rack unit is a device nobody can find.\u0026#34;\u0026#34;\u0026#34; def validate(self, instance, request): if instance.rack and instance.position is None: if instance.device_type and instance.device_type.u_height: self.fail( \u0026#34;A device in a rack needs a rack unit. Somebody has to find it.\u0026#34;, field=\u0026#39;position\u0026#39;, ) und sie per Punktpfad verdrahtet:\nCUSTOM_VALIDATORS = { \u0026#39;dcim.device\u0026#39;: ( {\u0026#39;name\u0026#39;: {\u0026#39;regex\u0026#39;: r\u0026#39;^[a-z0-9]+-[a-z]+-([0-9]{2}|[a-z])$\u0026#39;}}, \u0026#39;house_rules.BillableKitNamesItsCustomer\u0026#39;, \u0026#39;house_rules.RackedDeviceNeedsAPosition\u0026#39;, ), \u0026#39;ipam.prefix\u0026#39;: ( \u0026#39;house_rules.CustomerPrefixNeedsATenant\u0026#39;, ), } Beachte, dass ein Modell ein Tupel von Validatoren nimmt, einfache Regeln und Klassen frei gemischt, und sie laufen alle. Auch ein einzelner Validator muss als Iterable übergeben werden, und das sind leicht fünf verlorene Minuten.\nDann tun die Regeln, was sie sagen:\nPOST a hypervisor with no tenant {\u0026#34;tenant\u0026#34;: [\u0026#34;A Hypervisor is billable kit, so it must name the customer it belongs to.\u0026#34;]} POST a device into a rack with no position {\u0026#34;position\u0026#34;: [\u0026#34;A device in a rack needs a rack unit. Somebody has to find it.\u0026#34;]} POST a prefix with role \u0026#34;customer\u0026#34; and no tenant {\u0026#34;tenant\u0026#34;: [\u0026#34;A customer prefix must be assigned to a tenant.\u0026#34;]} POST a leaf switch with no tenant accepted, because a leaf switch is not in BILLABLE_ROLES Weil fail() ein field nimmt, landet die Meldung am richtigen Kasten im Formular statt oben auf der Seite, und das ist der Unterschied zwischen einer Regel, die Leute lernen, und einer Regel, die Leute übelnehmen.\nDas ist auch die Antwort auf die Lücke im Custom-Objects-Abschnitt. Die Validierung dort existierte nur am Webformular. Ein CustomValidator läuft in der Modellschicht, gilt also für die UI, die REST-API, GraphQL-Mutationen, Bulk-Importe und alles, was ein Script tut. Es gibt eine Stelle, an der die Regel geschrieben wird, und keinen Weg daran vorbei.\nDrei: Protection Rules, fürs Löschen CUSTOM_VALIDATORS wacht über Schreibvorgänge. PROTECTION_RULES wacht über Löschvorgänge, und es nimmt genau dieselben zwei Formen.\nPROTECTION_RULES = { \u0026#39;dcim.device\u0026#39;: ( {\u0026#39;status\u0026#39;: {\u0026#39;eq\u0026#39;: \u0026#39;offline\u0026#39;}}, ), } Das sagt, ein Gerät kann nur gelöscht werden, wenn es offline ist. Was dies ergibt:\nDELETE an active device {\u0026#34;detail\u0026#34;: \u0026#34;Deletion is prevented by a protection rule: [\\\u0026#34;Custom validation failed for status: [\u0026#39;Ensure this value is equal to offline.\u0026#39;]\\\u0026#34;]\u0026#34;} set it to offline, then DELETE 204 No Content Zwei Tastenanschläge Reibung zwischen jemandem und einem laufenden Gerät, und es ist die billigste Versicherung in der ganzen Anwendung. Mach den Außerbetriebnahmeprozess zu dem, was den Löschknopf freischaltet.\nDie eine, die dich erwischt Bestehende Daten werden erst geprüft, wenn du sie das nächste Mal anfasst. Eine Regel hinzuzufügen geht nicht zurück und validiert, was schon da ist. Sie liegt still, bis jemand ein Objekt speichert, das sie bricht, und dann bekommt der einen Fehler über eine Entscheidung, mit der er nichts zu tun hatte.\nIch habe zugesehen, wie es passiert ist. mcr1-hv-06 wurde angelegt, bevor ich irgendetwas davon geschrieben habe, als Hypervisor ohne Tenant. Es lag vollkommen zufrieden da. Dann habe ich seine Beschreibung bearbeitet:\nPATCH {\u0026#34;description\u0026#34;: \u0026#34;touching it to trigger revalidation\u0026#34;} {\u0026#34;tenant\u0026#34;: [\u0026#34;A Hypervisor is billable kit, so it must name the customer it belongs to.\u0026#34;]} Die Änderung hatte nichts mit dem Tenant zu tun. Die Regel hat trotzdem gefeuert, denn die Validierung läuft über das ganze Objekt.\nDas ist korrektes Verhalten, und es ist auch, wie aus einer neuen Regel ein Support-Ticket wird. Bevor du eine einschaltest, frag die Objekte ab, die daran scheitern würden, und reparier sie zuerst. Die API macht das leicht: Die Regel ist ein Filter, frag also nach den Geräten mit dieser Rolle und ohne Tenant, und du hast deine Liste.\nSchalt die Regel danach ein. Dann erwischt sie nur noch neue Fehler, und dafür ist sie da.\nSteuerung aus Ansible Eine Source of Truth, die niemand liest, verrottet. Die Collection netbox.netbox ist, wie die meisten das verhindern, und sie funktioniert in beide Richtungen: NetBox sagt Ansible, was existiert, und Ansible sagt NetBox, was es gebaut hat.\nSie steht bei Version 3.23.0, ist unter GPL-3.0 lizenziert und wurde über 13,4 Millionen Mal aus Galaxy gezogen. Sie trägt 91 Module und ein Inventory-Plugin.14 Alles Folgende lief gegen dieselbe Instanz, aus einem Container, in dem nichts war außer ansible-core 2.21.4, pynetbox 7.8.0 und der Collection.\nDas Inventar ist eine Abfrage, keine Datei Das ist die Hälfte, die sich am ersten Nachmittag bezahlt. nb_inventory baut dein Ansible-Inventar direkt aus NetBox:\nplugin: netbox.netbox.nb_inventory api_endpoint: http://netbox:8080 token: \u0026#34;{{ lookup(\u0026#39;env\u0026#39;, \u0026#39;NETBOX_TOKEN\u0026#39;) }}\u0026#34; config_context: false group_by: - sites - device_roles - tenants - racks device_query_filters: - has_primary_ip: true Das erzeugt dies, ohne dass jemand eine Hostliste pflegt:\n@sites_manchester-dc1: @device_roles_hypervisor: |--mcr1-core-01 |--mcr1-hv-01 |--mcr1-core-02 |--mcr1-hv-02 |--mcr1-hv-01 |--mcr1-hv-03 |--mcr1-hv-02 |--mcr1-hv-04 ... |--mcr1-hv-05 @racks_MCR1-A07: @tenants_ravenscroft-legal: |--mcr1-core-01 |--mcr1-hv-01 |--mcr1-core-02 |--mcr1-hv-02 ... @tenants_padgate-foods: @device_roles_core-router: |--mcr1-hv-03 |--mcr1-core-01 |--mcr1-hv-04 |--mcr1-core-02 @tenants_hartley-components: |--mcr1-hv-05 Schau auf die rechte Spalte. Weil Tenancy an den Geräten gesetzt ist, bekommst du eine Gruppe pro Kunde gratis, --limit tenants_ravenscroft-legal fährt ein Play also gegen genau die Technik eines Kunden. Füge ein Gerät in NetBox hinzu, und es ist beim nächsten Lauf in der Gruppe. Nimm eines außer Betrieb, und es ist weg. Niemand bearbeitet irgendetwas.\nJeder Host kommt mit dem an, was NetBox über ihn weiß:\nansible_host \u0026#34;2001:db8:20:20::11\u0026#34; primary_ip4 \u0026#34;10.20.20.11\u0026#34; primary_ip6 \u0026#34;2001:db8:20:20::11\u0026#34; device_roles [\u0026#34;hypervisor\u0026#34;] sites [\u0026#34;manchester-dc1\u0026#34;] racks [\u0026#34;MCR1-A07\u0026#34;] tenants [\u0026#34;ravenscroft-legal\u0026#34;] device_types [\u0026#34;sys-1029u-tn10rt\u0026#34;] manufacturers [\u0026#34;supermicro\u0026#34;] status {\u0026#34;label\u0026#34;: \u0026#34;Active\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;active\u0026#34;} Zweiundzwanzig Schlüssel insgesamt, und einer davon ist es wert, ihn zu bemerken, bevor er dich überrascht. ansible_host ist die IPv6-Adresse, weil dieses Gerät eine primäre v6 gesetzt hat. Ich habe es gegen zwei andere geprüft, die nur v4 haben, und die kamen mit v4 zurück, die Regel ist also, dass das Plugin v6 bevorzugt, wo eine primäre v6 existiert. Was korrekt ist und auch die Art Sache, die du lieber jetzt entdeckst als beim Grübeln, warum ein Play über einen Pfad verbindet, an den du nicht gedacht hattest.\nZurückschreiben Die Module sind die andere Richtung, und das, was man haben will, ist die IP-Vergabe, denn NetBox weiß, was frei ist, und dein Playbook nicht.\n- name: Rack the device netbox.netbox.netbox_device: netbox_url: \u0026#34;{{ nb_url }}\u0026#34; netbox_token: \u0026#34;{{ nb_token }}\u0026#34; data: name: mcr1-hv-07 device_type: SYS-1029U-TN10RT device_role: Hypervisor site: Manchester DC1 rack: MCR1-A07 position: 14 face: Front tenant: Hartley Components state: present - name: Let NetBox pick the next free address out of the customer prefix netbox.netbox.netbox_ip_address: netbox_url: \u0026#34;{{ nb_url }}\u0026#34; netbox_token: \u0026#34;{{ nb_token }}\u0026#34; data: prefix: 10.20.22.0/24 tenant: Hartley Components assigned_object: device: mcr1-hv-07 name: eno1 state: new Beachte, was nicht darin steht. Keine IP-Adresse. Du benennst das Prefix, und NetBox gibt die nächste freie zurück:\nTASK [Let NetBox pick the next free address out of the customer prefix] **** changed: [localhost] \u0026#34;device : mcr1-hv-07 (created)\u0026#34; \u0026#34;interface: eno1 (created)\u0026#34; \u0026#34;address : 10.20.22.1/24 (allocated)\u0026#34; Und eine Sekunde später ist es in der UI, noch an nichts verkabelt, aber eingeracked, mit Tenant und adressiert:\nDie Falle in diesem Playbook Lass es ein zweites Mal laufen, ohne eine Zeile zu ändern, und das passiert:\n\u0026#34;device : mcr1-hv-07 (already correct)\u0026#34; \u0026#34;interface: eno1 (already correct)\u0026#34; \u0026#34;address : 10.20.22.2/24 (allocated)\u0026#34; Das Gerät und das Interface sind idempotent. Die Adresse ist es nicht, und das ist kein Bug. state: present heißt „mach, dass es so aussieht“. state: new heißt „gib mir eine neue“, jedes einzelne Mal, und genau das hat es getan: zwei Adressen auf einem Interface nach zwei Läufen.\nDas ist in Ordnung, wenn du wirklich etwas Neues bereitstellst, und es frisst still ein Prefix auf, wenn du es in einen nächtlichen Job steckst. Vergib einmal und halte das Ergebnis fest, oder nimm state: present mit der Adresse, die du schon hast. Das Modul tut, was du verlangt hast. Die Frage ist, ob du verlangt hast, was du meintest.\nEs ist nicht nur Ansible Die Collection bekommt die Aufmerksamkeit, weil Ansible dort ist, wo die meisten Netzwerkteams schon sind, aber die API ist das Produkt, und eine Menge Dinge sprechen sie.\nDing Was es ist Lizenz pynetbox Der Python-Client, den die Collection selbst nutzt Apache 2.0 terraform-provider-netbox NetBox-Objekte als Terraform-Ressourcen verwalten, aktiv gepflegt von e-breuninger MPL 2.0 nornir_netbox NetBox als Nornir-Inventar, für Leute, die Python statt YAML machen Apache 2.0 Prometheus SD Liefert Prometheus seine Scrape-Targets aus NetBox MIT go-netbox Ein Go-Client, allerdings seit Mai 2025 nicht angefasst siehe Repository Diode NetBox Labs\u0026rsquo; eigene Ingestion-Pipeline, um entdeckte Daten hineinzuschieben NetBox Limited Use Der Terraform-Eintrag ist der interessante für jeden, der Infrastruktur schon so verwaltet, denn er lässt einen einzigen Plan die Cloud-Ressource und den NetBox-Datensatz anlegen, der sie dokumentiert, statt die zweite Hälfte jemandes Gedächtnis zu überlassen.15\nDiode trägt dieselbe Lizenz wie Branching und Custom Objects, es gilt also dieselbe Lektüre, bevor du darauf aufbaust.\nWas der Nachmittag wirklich kauft Alles oben hat mich einen Tag auf einer Maschine gekostet, und der größte Teil dieses Tages ging dafür hin, Daten zu säen, damit die Bildschirme etwas enthielten. Die Installation sind zwanzig Minuten, so oder so. Die Entscheidungen sind der Teil, der zählt, und sie werden alle in der ersten Stunde getroffen: Tenants vor allem anderen, Gerätetypen vor Geräten, die Zahlen an den Typen statt an der Technik.\nWas du dafür bekommst, ist keine Dokumentation. Diese Unterscheidung macht niemand, bevor er beides hatte: Dokumentation ist etwas, das du schreibst und dann nicht mehr pflegst. Was du bekommst, ist eine Datenbank, die sich weigert, einen Widerspruch zu halten: Sie lässt dich nicht zwei Dinge in eine Höheneinheit setzen, oder ein Rack in eine Location, die zu einer anderen Site gehört, oder ein Gerät auf einen Typ, der nicht existiert. Jede dieser Verweigerungen ist eine Diskussion, die du in sechs Monaten nicht führst.\nUnd es wird dir Dinge sagen, nach denen niemand gefragt hat. Dieser Schrank ist 28,6 % voll mit Technik und 90,7 % voll mit Strom. Niemand hat sich vorgenommen, das zu finden. Es fiel daraus heraus, einmal eine Wattzahl an einem Gerätetyp eingetragen zu haben, und es ist der Unterschied zwischen dem Einracken der nächsten Bestellung dort und dem Herausfinden auf die harte Art.\nDer ehrliche Vorbehalt ist derselbe, den jede Source of Truth hat. Sie ist nur so viel wert, wie es dich kostet, sie richtig zu halten, und die einzige Version davon, die ein geschäftiges Quartal übersteht, ist die, in der sichtbar etwas kaputtgeht, wenn die Daten falsch sind. Verdrahte dein Monitoring, dein Provisioning oder deine Firewall-Regeln so, dass sie daraus lesen, und ein falscher Eintrag hört auf, ein Dokumentationsproblem zu sein, um das sich irgendwann jemand kümmert. Er wird zu einem Ausfall um halb zehn an einem Dienstag, mit einem Namen daran. Das klingt wie ein Kostenpunkt. Es ist der ganze Mechanismus.\nDanken wird dir dafür auch niemand. Eine korrekte Aufzeichnung zeigt sich als die Migration, die zwei Wochen statt eines Quartals gedauert hat, als die Prüfung, die einen Nachmittag gedauert hat, als der Kunde, der am Telefon eine gerade Antwort bekommen hat. Nichts davon erscheint in einem Report neben deinem Namen.\nMach es trotzdem. Die Alternative ist ein Unternehmen, das sich selbst nicht beschreiben kann, und ein Unternehmen, das sich selbst nicht beschreiben kann, wird nicht geführt. Es wird erinnert, von jedes Jahr weniger Leuten.\nNetBox, Introduction — „Today, the open source project is stewarded by NetBox Labs and a team of volunteer maintainers“, und die Herkunft bei DigitalOcean 2015, Open Source seit Juni 2016.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNetBox, LICENSE.txt — Apache License 2.0, Copyright DigitalOcean, LLC. Herkunft und Betreuung aus der Einführung.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRelease-Notes zu Nautobot v1.0.0 — „a divergent fork of NetBox 2.10“, veröffentlicht am 26. April 2021, und die Liste dessen, was es gegenüber NetBox 2.10 hinzufügte.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNetwork to Code, „Why Did Network to Code Fork NetBox?“, 25. Februar 2021 — die Begründung mit SLA und Long-term Support, die auseinandergehende Vision und „the NetBox project team suggested that we should consider forking“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNetBox Labs wurde 2023 als Spin-out aus NS1 nach der Übernahme durch IBM gegründet, mitgegründet von NetBox\u0026rsquo; Lead Maintainer Jeremy Stretch, und gab im April 2023 eine Series A über 20 Mio. $ bekannt: NetBox Labs, „Let\u0026rsquo;s Go: Announcing NetBox Labs“ und die Series-A-Ankündigung.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNetBox Labs, NetBox Enterprise — die selbst verwaltete kommerzielle Edition, mit „24/7 expert assistance from the NetBox Labs team“; NetBox Cloud ist das gehostete Angebot. Konkrete SLA-Bedingungen sind auf dieser Seite nicht veröffentlicht.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nStern- und Fork-Zahlen, Release-Daten und Lizenzen beider Projekte am 30. September 2026 über die GitHub-API abgelesen: netbox-community/netbox und nautobot/nautobot. Nautobots parallele Releases 3.2.x und 2.4.x sind beide auf den 28. September 2026 datiert.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nnetbox-community/netbox-docker — der Container-Stack der Community, Apache 2.0.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNetBox, Installation — die Tabelle der unterstützten Versionen, und die Release-Notes zu v4.7 für die angehobenen PostgreSQL- und Redis-Mindestversionen. Version und Edition abgelesen aus netbox/release.yaml.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNetBox Limited Use License 1.0 — getragen von netbox-custom-objects und, identisch, von netbox-branching. Beide zitierten Klauseln sind wörtlich.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNetBox, HTTP Server installation, „What\u0026rsquo;s Next?“ — „Some of the most popular plugins include“ NetBox Branching, NetBox Custom Objects, NetBox DNS und NetBox BGP, ohne Erwähnung der Lizenzbedingungen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNetBox, Data Validation configuration — FIELD_CHOICES und das Plus-Suffix, das erweitert statt ersetzt: „To replace the available choices, specify the app, model, and field name separated by dots \u0026hellip; To extend the available choices, append a plus sign“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nDokumentation zu netboxlabs/netbox-custom-objects — „Deleting a Custom Object Type drops an entire database table and should be done with caution.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nnetbox.netbox auf Ansible Galaxy und netbox-community/ansible_modules — Version 3.23.0, GPL-3.0, 91 Module plus das Inventory-Plugin nb_inventory. Download-Zahl am 30. September 2026 bei Galaxy abgelesen. Alles Gezeigte lief mit ansible-core 2.21.4 und pynetbox 7.8.0.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nLizenzen, Aktivität und Stern-Zahlen am 30. September 2026 bei jedem Projekt abgelesen: pynetbox (Apache 2.0), terraform-provider-netbox (MPL 2.0, v6.0.0-rc.1 in der Terraform Registry), nornir_netbox (Apache 2.0), netbox-plugin-prometheus-sd (MIT), go-netbox (letzter Push am 9. Mai 2025) und Diode, das dieselbe NetBox Limited Use License 1.0 trägt wie Branching und Custom Objects.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://blogs.damiendye.uk/de/netbox/what-is-netbox/","summary":"Ein praktischer Rundgang durch NetBox 4.7.2 mit einem eingepflegten Bestand statt einer leeren Demo. Was jeder Bildschirm enthält und was du damit machst: Rack-Elevationen, Kabelverfolgungen, der IPAM-Baum, Dual-Stack-Interfaces und der Schrank, der sich als 90,7 Prozent voll mit Strom und nur 28,6 Prozent voll mit Technik entpuppt. Wie du eins als Container-Stack und auf einem Host aus den Paketen aufsetzt, beides von Anfang bis Ende durchgespielt. Die Reihenfolge, in der du es füllen musst, abgeleitet daraus, welche Fremdschlüssel wirklich zwingend sind. Wie eine Installation in Kunden zerlegt wird, sodass das Gerät eines anderen Kunden 404 liefert und ein nicht gewährter Objekttyp 403. Config Contexts und die Vererbung, die sie wertvoller macht als Custom Fields. Eigene Werte in NetBox\u0026rsquo; eigenen Status-Menüs. Drei Wege, das Objekt hinzuzufügen, von dem dein Geschäft lebt, darunter ein Datastore ohne eine Zeile Code. Wie du Validierungsregeln und Validator-Klassen schreibst, damit die Datenbank verweigert, was dein Hausstandard verbietet. Und die Geschichte des Forks von 2021, aus dem Nautobot wurde, wozu er da war und was seither zusammengewachsen ist. Dazu die Steuerung des Ganzen aus der Ansible-Collection netbox.netbox, wo das Inventar eine Abfrage statt einer Datei ist und ein Modul-Argument bei jedem Lauf stillschweigend eine neue Adresse vergibt.","title":"NetBox: Was drin steckt, und wie du deins hineinbekommst"},{"content":"Jeden Namen, den deine Maschine heute nachgeschlagen hat, hat sie geglaubt. Deine Bank, deine Updates, deinen Mailserver. Eine Antwort kam aus dem Netz zurück, und nirgendwo hat irgendetwas geprüft, ob sie von der Organisation stammt, der der Name gehört, oder von demjenigen, der als Erster ein Paket loswurde. Auf einer gewöhnlichen DNS-Antwort liegt keine Signatur, es gibt nichts zu verifizieren, und nichts würde bemerken, wenn etwas nicht stimmte. 1983 war das ein vernünftiger Entwurf, und seit Langem ist er keiner mehr.\nDNSSEC behebt genau das, und es ist weder neu noch teuer. Der Besitzer der Zone signiert seine Einträge. Die Zone darüber veröffentlicht einen Hash seines Schlüssels und signiert den, und so weiter nach oben, bis die Kette einen einzigen Root-Schlüssel erreicht, den dein Resolver von Geburt an kennt. Alles, was die Kette prüft, kann eine echte Antwort von einer gefälschten unterscheiden. Es ist seit 2005 ein Standard, die Root ist seit Juli 2010 signiert, und die Registries veröffentlichen die Einträge umsonst.1 2\nDie Spitze des Baums ist fertig. Ich habe für diesen Beitrag die Live-Root-Zone gezählt, und 1.351 von 1.438 Top-Level-Domains sind signiert, alle 1.038 generischen darunter. Dann geht es über die Klippe. Von den 2.390 gov.uk-Domains, die noch auflösen, sind neununddreißig signiert, und neun davon sind Gemeinderäte. Der MI6 hat es hinbekommen. Das National Cyber Security Centre nicht.\nDas hier ist, was eine gefälschte Antwort tatsächlich kostet und was Signieren dagegen tut, gezählt aus der Live-Root-Zone am 27. September 2026 und hinunter durch Behörden, Banken, die Distributionen, von denen du installierst, und die Zertifizierungsstellen. Ein Befehl pro Domain, niemandes Erlaubnis nötig, und jeder Name aufgelistet, damit du über meine Auswahl streiten kannst statt über meine Rechnung. Darunter liegt die Frage, die ich eigentlich beantwortet haben wollte. Zweiundvierzig Jahre nachdem Mockapetris DNS aufgeschrieben hat: Signiert fast niemand, weil fast niemand je verstanden hat, was DNS versprochen hat?\nWas DNSSEC ist und wofür es da ist In einem Satz: DNSSEC legt eine kryptografische Signatur auf DNS-Antworten, sodass ein Resolver beweisen kann, dass eine Antwort vom Besitzer der Zone kam und nicht von demjenigen, der es geschafft hat, als Erster zu antworten.\nEs ist keine Verschlüsselung, keine Firewall und kein Filter. Es ist eine Signatur und eine Schlüsselkette, die zu einem einzigen Schlüssel zurückführt, dem dein Resolver ohnehin vertraut. Das ist die ganze Idee.\nJetzt der Angriff, denn das Protokoll ergibt erst Sinn, wenn du gesehen hast, wofür es da ist.\nEin Resolver, der nach einem Namen fragt, schickt eine Anfrage und wartet. Die Antwort wird über eine Handvoll Felder zugeordnet: den abgefragten Namen, den Typ, Quell- und Zieladresse samt Ports, und eine 16-Bit-Transaktions-ID. Wer ein Paket erzeugen kann, das zu diesen Feldern passt, bevor die echte Antwort eintrifft, gewinnt. Der Resolver cacht die Fälschung und reicht sie an jeden Client weiter, der fragt, so lange der Angreifer es gesagt hat.\nDan Kaminskys Arbeit von 2008 ist die, an die sich alle halb erinnern.3 Entscheidend ist nicht, dass Cache Poisoning existierte, denn das war schon Jahre vorher bekannt. Entscheidend ist, dass er einen Weg fand, den Rateversuch beliebig oft zu wiederholen. Frag nach einem Namen, den es nicht gibt, und jeder Fehlversuch kostet nichts und lässt dich sofort erneut probieren, sodass der Angreifer nicht mehr einmal gegen einen zwischengespeicherten Eintrag antritt, der einen Tag hält. Die Antwort der Branche war mehr Zufall: zufällige Quellports zusätzlich zur zufälligen Transaktions-ID, was das Raten von eins zu 65.536 auf etwa eins zu zwei Milliarden brachte.\nDas ist eine größere Zahl. Es ist kein Beweis.\nDer Resolver ordnet über Felder zu, die ein Angreifer erraten kann OHNE SIGNIERUNG: DAS ERSTE PASSENDE PAKET GEWINNT Resolver fragt, dann wartet der echte Server antwortet, wann er mag Off-Path-Angreifer muss nur zuerst ankommen Sie wird akzeptiert, wenn fünf Felder passen, und jedes davon ist erratbar: Name · Typ · Adressen · Quellport · 16-Bit-Transaktions-ID MIT SIGNIERUNG: DIE ANTWORT TRÄGT DEN BEWEIS Eine Signatur, die zu dem einen Root-Schlüssel verkettet, den der Resolver schon hatte. Raten erzeugt keine. Der Resolver ordnet über Felder zu, die ein Angreifer erraten kann. Signieren ersetzt Raten durch Rechnen Und diese Abmilderung erodiert seitdem, denn jedes dieser Felder ist ein Rateversuch, den man erschwert hat, und keine Tatsache, die man prüfbar gemacht hat. Port-Zufall wird von einem NAT ausgehebelt, das Ports vorhersagbar umschreibt. Fragmentierungsangriffe umgehen die Zuordnung ganz. Off-Path-Angriffe kommen in immer neuen Formen wieder, und jeder bekommt seinen eigenen Patch.\nSignieren beendet die Diskussion. Eine signierte Antwort verifiziert entweder gegen einen Schlüssel, den der Resolver bis zur Root verketten kann, oder eben nicht, und kein noch so ausdauerndes Raten verschafft einem Angreifer eine gültige Signatur.\nWas ihnen der Sieg in diesem Rennen tatsächlich einbringt Werd konkret, denn „Cache Poisoning“ klingt abstrakt und die Folgen sind es nicht.\nWas sie fälschen Was sie bekommen Den A-Eintrag deiner Website Verkehr, und ein Anmeldeformular, das aussieht wie deins Deine MX-Einträge Jede eingehende E-Mail, Passwort-Rücksetzungen inklusive Den Namen, gegen den eine Zertifizierungsstelle prüft Ein gültiges Zertifikat für eine Domain, die ihnen nicht gehört Den Namen, von dem deine Maschinen Updates holen Es kommt nichts an, und niemand erfährt davon Deine NS-Delegierung Alles davon auf einmal, so lange die TTL es sagt Die dritte Zeile macht aus einem DNS-Problem ein Zertifikatsproblem. Domain-validierte Ausstellung funktioniert so, dass man dich bittet, einen Eintrag zu veröffentlichen, und ihn dann nachschlägt. Kann ein Angreifer die Antwort kontrollieren, die die Zertifizierungsstelle bei dieser Abfrage sieht, stellt sie ihm echtes Papier auf deinen Namen aus, und danach gehört das Schloss im Browser ihm. Alles, worauf Nutzer trainiert wurden zu achten, sagt, die Seite sei in Ordnung.\nDie vierte Zeile ist die leise. Eine gefälschte Antwort muss niemanden irgendwohin schicken. Einen Update-Dienst in ein schwarzes Loch zu zeigen genügt, und nichts im Stack ist dafür gebaut, wegen Updates Alarm zu schlagen, die nie ankamen.\nWas das Signieren dagegen tut Der Mechanismus ist einfacher als sein Ruf.\nJede signierte Zone hält ein Schlüsselpaar. Der Zonenbesitzer signiert jeden Eintragssatz mit der privaten Hälfte und veröffentlicht daneben ein RRSIG. Die öffentliche Hälfte steht als DNSKEY in der Zone. Bis hierhin beweist das nichts, denn ein Angreifer, der einen A-Eintrag fälschen kann, kann auch ein passendes DNSKEY fälschen.\nWas es schließt, ist der DS-Eintrag, und das DS liegt in der übergeordneten Zone, nicht in deiner. Es ist ein Hash deines Schlüssels, veröffentlicht und signiert von der Zone über dir. Also bürgt uk für deinen Schlüssel, die Root bürgt für uk, und dein Resolver kam mit genau einem Wissen zur Welt: dem Schlüssel der Root.2\nJeder Elternteil bürgt für sein Kind, und ein fehlendes DS zerreißt alles darunter DAS EINZIGE, WAS EIN RESOLVER VON GEBURT AN WEISS der Root-Schlüssel mit dem Resolver ausgeliefert Alles andere wird durch Fragen gelernt und von der Ebene darüber bewiesen. DS für uk uk signiert, und die Root bürgt dafür DS für deine Zone damiendye.uk signiert ihre Einträge mit RRSIG Ein DS ist ein Hash des Kindschlüssels, veröffentlicht und signiert vom Elternteil. Nur der Elternteil kann dich in die Kette setzen. Du selbst nicht. UND WENN EIN DS FEHLT Die Kette hört dort auf. Alles darunter ist nicht verifizierbar, wie sorgfältig die Zone darunter auch signiert wurde. Jeder Elternteil bürgt für sein Kind, und ein fehlendes DS zerreißt alles darunter Drei Eintragstypen erledigen die Arbeit, und du willst wissen, welcher welcher ist, denn nur einer davon ist die Aufgabe eines anderen:\nEintrag Liegt in Sagt DNSKEY deiner Zone hier ist mein öffentlicher Schlüssel RRSIG deiner Zone hier ist meine Signatur über diesen Eintragssatz DS der Zone deines Elternteils ich bürge für diesen Schlüssel Du kannst die ersten beiden einen ganzen Nachmittag lang allein veröffentlichen, und es ändert nichts. Bis der Elternteil ein DS veröffentlicht, bist du eine signierte Zone, die niemand verifizieren kann, was dasselbe ist wie eine unsignierte Zone mit zusätzlicher Arbeit darin.\n$ dig +short @127.0.0.53 uk DS 43876 8 2 A107ED2AC1BD14D924173BC7E827A1... $ dig +short @127.0.0.53 damiendye.uk DS 2371 13 2 A5B2825C57899A5A15EE9703832C8358E0D19EF29DC72DD83C691ED77C33BD7F $ dig +short @127.0.0.53 bbc.co.uk DS (nothing) Das in der Mitte ist die eigene Zone dieser Seite. uk bürgt für sie, Algorithmus 13 ist ECDSA P-256, und ein validierender Resolver kann darum jede Antwort über sie bis zur Root beweisen. bbc.co.uk liefert nichts zurück, also kann er es nicht.\nEin Befehl sagt dir, ob eine Zone in der Vertrauenskette hängt. Veröffentlicht der Elternteil kein DS für dich, bist du nicht signiert, was immer du sonst konfiguriert hast, und ein validierender Resolver behandelt jede Antwort über deine Domain als nicht verifizierbar.\nDieser eine Eintrag ist der ganze Test.\nWas es nicht tut Das gehört klar gesagt, denn das Überverkaufen ist die halbe Erklärung dafür, warum Leute misstrauisch sind.\nEs tut nicht Weil Irgendetwas verschlüsseln Jeder Name, den du nachschlägst, liegt weiterhin offen. Dafür ist DNS over TLS da, und die beiden ersetzen einander nicht Eine kompromittierte Zone sicher machen Ein Angreifer, dem deine DNS-Verwaltung gehört, signiert seine Fälschungen mit deinem Schlüssel, ganz munter Den letzten Hop schützen Zwischen einem validierenden Resolver und der Anwendung, es sei denn, dieser Hop ist ebenfalls vertrauenswürdig Verhindern, dass dir ein Name abgenommen wird Ein Registrar oder ein Gericht kann das immer noch, und die Signatur bleibt die ganze Zeit einwandfrei gültig Irgendetwas über den Inhalt aussagen Eine signierte Antwort ist echt, nicht ehrlich. Schadsoftware kann ihre Zone auch signieren, und tut es Über die letzte Zeile stolpern Leute. DNSSEC beweist, dass die Antwort von dem kam, der die Zone kontrolliert. Es hat nicht die geringste Meinung dazu, ob derjenige anständig ist.\nEs tut genau eine Sache. Es macht das Fälschen einer Antwort rechnerisch aussichtslos statt bloß unwahrscheinlich.\nWie du jede Zone prüfst, auch die von anderen Das hier ist der Teil, der den Rest dieses Beitrags möglich macht, und er braucht einen Befehl.\nEine Zone hängt in der Vertrauenskette, wenn ihr Elternteil ein DS für sie veröffentlicht. Das ist der ganze Test, und du kannst ihn gegen jeden laufen lassen, ohne Erlaubnis, von jeder Maschine aus:\ndig +short damiendye.uk DS Kommt etwas zurück, ist sie signiert. Kommt nichts zurück, ist sie es nicht, was die Zone sonst auch konfiguriert hat.\nWenn du mehr willst als Ja oder Nein, lohnen sich drei weitere:\nBefehl Sagt dir dig +short \u0026lt;zone\u0026gt; DS Bürgt der Elternteil überhaupt für diese Zone delv @1.1.1.1 \u0026lt;zone\u0026gt; A Validiert die Kette durchgängig, und wenn nicht, wo sie reißt resolvectl query \u0026lt;zone\u0026gt; Was ein validierender Resolver folgert, mit ausformuliertem Urteil dig +dnssec \u0026lt;zone\u0026gt; SOA Das RRSIG und sein Ablaufdatum, und genau das gehört überwacht Zwei Fallen, bevor du deinen eigenen Ergebnissen traust, denn beide haben mich beim Messen für diesen Beitrag erwischt.\ndig +short … DS gibt eine CNAME-Kette aus, wenn der Name ein Alias ist, und ein Hostname mit Ziffern darin sieht einem DS-Eintrag ähnlich genug, um ein naives Skript hereinzulegen. Ein echtes DS hat vier Felder: Key-Tag, Algorithmus, Digest-Typ, Hex-Digest. Prüf auf diese Form, sonst zählst du unsignierte Zonen als signiert.\nEin DS unter einem unsignierten Elternteil bedeutet nichts. Die Kette muss die Root erreichen. update.microsoft.com hat ein DS, microsoft.com nicht, also ist der Ast trotzdem nicht verifizierbar. Prüf immer den ganzen Pfad, nicht eine Ebene.\nAlles, was im Rest dieses Beitrags gezählt ist, wurde so gemessen. Kein Scanner, kein fremdes Dashboard, keine Ranglisten eines Anbieters. Frag den Elternteil, ob er für das Kind bürgt, und bestehe darauf, dass die Antwort als DS parst.\nDie Root-Zone ist fertig Hier ist die überlieferte Weisheit schlicht veraltet. Leute reden über DNSSEC immer noch so, als wäre die Infrastruktur das Problem.\nIch habe am 27. September 2026 die Live-Root-Zone geholt, Seriennummer 2026092701, und die Delegierungen gegen die DS-Einträge gezählt.4\nDelegierungen signiert Anteil gTLDs (.com, .org, .dev, das ganze Feld) 1.038 1.038 100 % IDN-TLDs 151 136 90,1 % ccTLDs 248 176 71,0 % arpa 1 1 100 % Gesamt 1.438 1.351 93,9 % Jede einzelne generische Top-Level-Domain ist signiert. Alle 1.038, ohne Ausnahme, weil ICANNs Registry Agreement es für alles verlangt, was unter dem neuen gTLD-Programm delegiert wurde. Die 87 unsignierten sind fast ausschließlich Ländercodes, und die Liste besteht überwiegend aus kleinen Territorien und einer Handvoll Staaten:\nae ao aq ba bb bo bs cd cf cg ck cu cv cw do eg fk gb gf gh gm gp gq gt gu hm im iq jm jo kh km kn kp mh mk mo mp mq mt mv mw mz ne ni np nr om pa pf pk pn ps qa sd sl sm so st sv sy sz td tg tj tk to va vg vi ye zw gb steht da drin, was eher eine Kuriosität als ein Problem ist, denn niemand benutzt es für irgendwas. Ebenso der Vatikan, Nordkorea, Kuba und Syrien. Ebenso tk, das jahrelang die größte Quelle kostenloser Domains im Internet war und eine verlässliche Quelle für Missbrauch gleich dazu.\nDie Spitze des Baums ist also erledigt. Die Registries haben den schweren Teil gemacht, den teuren Teil und den Teil, der internationale Abstimmung brauchte, und sie haben ihn zu Ende gebracht. Insofern kann nichts unterhalb dieses Punkts der Infrastruktur angelastet werden.\nVierundneunzig Prozent an der Spitze, anderthalb am Boden DIE KETTE IST GEBAUT die Root signiert seit 2010 1.351 von 1.438 TLDs jede gTLD, ohne Ausnahme der Name, den Leute tatsächlich tippen und hier hört es auf ANTEIL SIGNIERT, GEZÄHLT AM 27. SEPTEMBER 2026 TLDs in der Root 93,9 % Linux- und BSD-Distros 29 % Britische Banken 27 % Paket-Registries 18 % Microsoft-Zonen 15 % Zertifizierungsstellen 11 % jede gov.uk-Domain 1,63 % 39 signiert, von den 2.390 im amtlichen Register, die noch auflösen Gezählt, nicht geschätzt. Die Kette ist bis hinunter zur TLD gebaut, und dann benutzt sie niemand Und dann ist Schluss Unterhalb der TLD dreht sich das Bild vollständig um.\nIch habe für jede Gruppe darunter gleich gemessen: den Elternteil nach einem DS fragen, und nur einen Eintrag akzeptieren, der tatsächlich als solcher parst. Alles hier wurde am 27. September 2026 gezählt.\nWas Signiert Anteil TLDs in der Root-Zone 1.351 / 1.438 93,9 % Linux- und BSD-Distributionen 19 / 96 20 % Britische Banken und Bausparkassen 13 / 98 13 % Paket-Registries und Lieferkette 4 / 22 18 % Microsofts Zonen 4 / 26 15 % Zertifizierungsstellen 1 / 9 11 % Jede gov.uk-Domain, die noch auflöst 39 / 2.390 1,63 % Vierundneunzig Prozent an der Spitze. Anderthalb Prozent am Boden. Die Vertrauenskette ist eine Kette, deren eines Ende an der Wand verschraubt ist, während das andere auf dem Boden liegt.\nEine Anmerkung zur Methode, denn eine so schlechte Zahl verdient eine. Die gov.uk-Zeile ist eine Vollerhebung und keine Stichprobe: Sie umfasst jede Second-Level-Domain im amtlich veröffentlichten Register der Regierung, gefiltert auf die 2.390, die noch auflösen. Die anderen Zeilen sind kuratierte Listen der Organisationen, deren Fälschung tatsächlich wehtäte, und das ist eine Ermessensentscheidung, weshalb ich unten jeden Namen darin aufgeführt habe, damit du mit meiner Auswahl uneins sein kannst statt mit meiner Rechnung.\nDie Vollerhebung beim Staat: 39 von 2.390 Die amtliche Liste der gov.uk-Domains, die die Regierung veröffentlicht, umfasst 3.004 Second-Level-Namen. Davon lösen 2.390 noch auf. Neununddreißig sind signiert.\nVor dem Detail noch etwas zu diesem Register. Die aktuellste Fassung, die gov.uk veröffentlicht, ist auf den 1. Oktober 2016 datiert.5 Ein Jahrzehnt alt, für die maßgebliche Liste der Domains, unter denen der britische Staat antwortet. Das ist ein eigener kleiner Befund, und ich lasse ihn so stehen.\nJetzt schau dir an, welche neununddreißig.\nSigniert Nicht signiert mi6.gov.uk, sis.gov.uk gchq.gov.uk, mi5.gov.uk nationalcrimeagency.gov.uk ncsc.gov.uk, cyberessentials.ncsc.gov.uk cheltenham.gov.uk, cotswold.gov.uk, somerset.gov.uk, waverley.gov.uk, southribble.gov.uk, sedgemoor.gov.uk, fdean.gov.uk, westoxon.gov.uk birmingham.gov.uk, manchester.gov.uk, leeds.gov.uk, glasgow.gov.uk, sheffield.gov.uk, liverpool.gov.uk, bristol.gov.uk, cardiff.gov.uk, edinburgh.gov.uk, belfast.gov.uk peakdistrict.gov.uk, snowdonia-npa.gov.uk, eryri-npa.gov.uk hmrc.gov.uk, dvla.gov.uk, dwp.gov.uk, nhs.uk, homeoffice.gov.uk, mod.uk, parliament.uk neun Gemeinde- und Stadträte companieshouse.gov.uk, landregistry.gov.uk, police.uk, met.police.uk, tfl.gov.uk, ons.gov.uk Lies die erste Spalte noch einmal. Der britische Auslandsgeheimdienst hat seine Zone signiert. Das National Cyber Security Centre nicht.\nGCHQ auch nicht, und das ist die Mutterorganisation des NCSC. Das Programm Cyber Essentials auch nicht, das es gibt, um zu bescheinigen, dass die Sicherheit anderer Leute angemessen ist. Ich werde nicht so tun, als wäre das irgendetwas anderes als bemerkenswert.\nUnd neun der neununddreißig sind Gemeinde- und Stadträte. Abinger. Aldenham. Ashmansworth. Wheathampstead. Frampton on Severn. Orte mit einem Schriftführer, einer nebenher gepflegten Website und einem Budget, das keinen Beratertag in Whitehall decken würde. Die haben es hinbekommen. HMRC, die die Steuerakte jedes Erwachsenen im Land hält, nicht.\nDarf ich fragen, was im Prozess das zulässt. Nicht wer: was. Denn das NCSC veröffentlicht Leitlinien, die anderen Leuten sagen, sie sollen DNSSEC ausrollen, und die Abteilung, die die Leitlinien schreibt, hat nicht getan, was die Leitlinien sagen. Entweder ist es wichtig, dann hätte die Stelle, die das sagt, es vor Jahren tun müssen, oder es ist es nicht, dann sollten die Leitlinien genau das sagen.\nDie angebotene Ausrede werden Größe und Altlasten sein. Sie überlebt die erste Spalte nicht. somerset.gov.uk ist eine Einheitsgemeinde für 580.000 Menschen und ist signiert. birmingham.gov.uk ist eine Einheitsgemeinde für 1,1 Millionen und ist es nicht. Gleiches Land, gleiche Registry, gleiche Registrare, gleiches Geld für die gleichen Dienstleister. Eine hat es getan.\nDie Software, von der du Updates beziehst Das ist der Teil, der dir mehr Sorgen machen sollte als die Banken, und es ist der Teil, den fast niemand misst.\nJede Maschine, die du betreibst, holt sich nach Plan Code von irgendwoher, und sie findet dieses Irgendwo, indem sie DNS fragt.\nNeunundneunzig Distributionen und BSDs, sechsundneunzig davon lösen noch auf. Neunzehn sind signiert.\nSigniert (19) debian.org, fedoraproject.org, opensuse.org, gentoo.org, almalinux.org, artixlinux.org, cachyos.org, garudalinux.org, getsol.us, linuxmint.com, q4os.org, system76.com, tails.net, whonix.org, freebsd.org, netbsd.org, hardenedbsd.org, midnightbsd.org, opnsense.org Die großen kommerziellen ubuntu.com, canonical.com, redhat.com, suse.com, oracle.com, rockylinux.org, centos.org, eurolinux.com Ubuntu-Varianten kubuntu.org, xubuntu.org, lubuntu.me, ubuntustudio.com, ubuntukylin.com Arch-Familie archlinux.org, arcolinux.com, endeavouros.com, manjaro.org, blackarch.org Unabhängig und minimal alpinelinux.org, voidlinux.org, nixos.org, devuan.org, slackware.com, antixlinux.com, mxlinux.org, puppylinux.com, tinycorelinux.net, slitaz.org, porteus.org, funtoo.org, calculate-linux.org Desktop-orientiert zorin.com, elementary.io, deepin.org, uniontech.com, bodhilinux.com, peppermintos.com, sparkylinux.org, neon.kde.org, nobaraproject.org, ultramarine-linux.org, vanillaos.org, solus-project.com Sicherheit und Privatsphäre kali.org, parrotsec.org, qubes-os.org, backbox.org, pentoo.ch, trisquel.info, pureos.net, hyperbola.info, dragora.org Regional und staatlich altlinux.org, astralinux.ru, rosa.ru, openkylin.top, openeuler.org, opencloudos.org, openanolis.cn, mageia.org, openmandriva.org, pclinuxos.com Embedded, immutable, Appliance openwrt.org, dd-wrt.com, librecmc.org, raspberrypi.com, armbian.com, flatcar.org, talos.dev, bottlerocket.dev, truenas.com, pfsense.org BSD openbsd.org, dragonflybsd.org, ghostbsd.org Und die zwei, auf die es am meisten ankommt kernel.org, gnu.org Neunzehn von sechsundneunzig. Und die Namen in der unsignierten Liste sind nicht obskur: Ubuntu, Red Hat, SUSE, Oracle, Arch, Alpine, NixOS, Rocky, jede Ubuntu-Variante, und sowohl kernel.org als auch gnu.org.\nBei den Sicherheits- und Privatsphäre-Distributionen hatte ich erwartet, dass sie anders sind, und meist sind sie es nicht. Tails und Whonix haben signiert, was passt. Kali, Parrot, Qubes, Trisquel und PureOS nicht, was nicht passt. OpenBSD hat sich fünfundzwanzig Jahre lang einen Ruf darauf aufgebaut, genau diese Klasse von Dingen richtig zu machen, und hat openbsd.org nicht signiert, während FreeBSD, NetBSD, HardenedBSD und MidnightBSD es alle getan haben.\nDie Paket-Registries sind nahe an einem Durchmarsch in der falschen Spalte: npm, crates.io, RubyGems, Packagist, Docker Hub und Quay sind allesamt unsigniert. pypi.org ist die Ausnahme, und Ehre, wem Ehre gebührt, denn es gehört auch zu den meistangegriffenen.\nMicrosoft und der Update-Kanal Vier von sechsundzwanzig Microsoft-Zonen sind signiert, und sie liegen alle in einer Ecke des Bestands:\nSigniert Nicht signiert live.com, outlook.com, office.com, office365.com microsoft.com, windows.com, windowsupdate.com, update.microsoft.com azure.com, azurewebsites.net, microsoftonline.com, windows.net github.com, npmjs.com, linkedin.com, visualstudio.com, xbox.com, bing.com Die Outlook- und Office-Namen sind signiert und sonst nichts, was nach der Entscheidung eines Teams aussieht und nicht nach der eines Konzerns. Achte darauf, was in der rechten Spalte neben dem Update-Dienst steht: github.com und npmjs.com, zwei der größten Code-Verteilpunkte im Internet, beide Microsoft, beide unsigniert.\n$ dig +short @127.0.0.53 windowsupdate.com DS (nothing) $ dig +short @127.0.0.53 microsoft.com DS (nothing) $ dig +short @127.0.0.53 com DS 19718 13 2 8ACBB0CD28F41250A80A491389424... com ist signiert, also steht technisch nichts im Weg. Microsoft könnte heute Nachmittag ein DS veröffentlichen.\nDie Standardantwort darauf, warum das egal sei, lautet, DNS sei nur eine Schicht. Update-Pakete sind codesigniert, der Client prüft die Signatur, und der Verkehr läuft über TLS. Brich das DNS, und du bekommst trotzdem keinen Code zur Ausführung.\nDiese Antwort hängt vollständig davon ab, dass das Signieren solide ist. Das war es nicht.\nWann Was mit Microsofts Signaturvertrauen passierte 2012 Flame fälschte über eine MD5-Kollision im Lizenz-Enrolment-Pfad der Terminaldienste ein Zertifikat, das zur Microsoft Root Authority verkettete, und benutzte es dann auf einem gefälschten Update-Server6 2021 Netfilter war das erste gefundene Rootkit mit einer WHQL-Signatur, die direkt von Microsoft ausgestellt war, nachdem es das Windows Hardware Compatibility Program durchlaufen hatte, während es mit einem Command-and-Control-Server sprach7 2021 FiveSys, ein weiterer WHQL-zertifizierter Treiber, entpuppte sich als Rootkit, das sein eigenes Root-Zertifikat installierte und den HTTP- und HTTPS-Verkehr der Maschine über einen Proxy führte7 2022 Von Microsoft signierte bösartige Treiber tauchten in Ransomware-Angriffen auf, und Microsoft zog die Signaturen zurück und sperrte die Entwicklerkonten7 2023 Storm-0558 erlangte nach der Kompromittierung eines Mitarbeiterkontos einen Microsoft-Consumer-Signaturschlüssel aus einem Crash-Dump und fälschte Authentifizierungstoken, die bei rund 25 Organisationen samt Behörden für Unternehmens-E-Mail akzeptiert wurden8 Sei bei der letzten Zeile genau, denn Leute übertreiben sie. Der gestohlene Schlüssel signierte Identitätstoken, keine Binaries. Sie gehört aus einem anderen Grund in die Tabelle: Die Verwahrung von Microsofts Signaturmaterial versagte, zwei Jahre lang unentdeckt, über einen Crash-Dump und ein kompromittiertes Entwicklerkonto.\nDie Zeilen darüber sind die Versagen beim Codesignieren, und sie sind schlimmer. Zweimal in einem Jahr setzte Microsofts eigenes Hardware-Zertifizierungsprogramm eine Microsoft-Signatur auf ein funktionierendes Rootkit und lieferte es aus. Kein gefälschtes Zertifikat, kein gestohlener Schlüssel. Der legitime Prozess, der Schadsoftware signiert, genau wie entworfen.\nDie Verteidigung, die es erlaubt, DNS als optional zu behandeln, wurde also über elf Jahre hinweg durch Fälschung, durch Prozessmissbrauch und durch Schlüsseldiebstahl unterlaufen. Ein Angreifer mit einer Signatur, die die Maschine akzeptiert, ist kein Gedankenexperiment. Für einen staatlich gestützten Akteur ist das ein Beschaffungsproblem und kein Forschungsproblem.\nGib diesem Angreifer eine gefälschte DNS-Antwort, und das Bild ist vollständig: signierter Code, den er kontrolliert, geliefert von einem Server, den die Maschine für Microsofts hält, über eine Verbindung, die nichts im Stack hinterfragt. Das ist Flame, mit besserem Schlüsselmaterial.\nDNSSEC ist die einzige Schicht in dieser Kette, der es egal ist, wessen Signaturschlüssel der Angreifer hält. Es validiert nicht die Nutzlast, es validiert, wohin die Maschine geschickt wurde, und es versagt unabhängig von jedem Zertifikat und jeder Signatur im Spiel. Genau das willst du von einer zweiten Schicht, und genau deshalb sollte sie nicht die sein, die abgeschaltet ist.\nUnd es gibt einen billigeren Angriff, der gar keinen Schlüssel braucht. Fälsch die Antwort so, dass der Update-Dienst nirgendwohin Nützliches auflöst, und die Maschine patcht schlicht nie. Kein Fehler, auf den die Nutzerin reagieren würde, kein Alarm, nur eine Flotte, die still zurückfällt, während das Dashboard sagt, alles sei in Ordnung. Wollte ich einen Bestand, der in sechs Monaten ausbeutbar ist, würde ich ihm nichts ausspielen. Ich würde nur dafür sorgen, dass nichts ankommt.\nDie Banken, vollständig Diesmal keine Stichprobe. Achtundneunzig britische Banken und Bausparkassen, jede einzelne an dem Tag auflösend, von der Einkaufsstraße hinunter bis zu Kassen mit einer Filiale und einem viktorianischen Namen.\nDreizehn sind signiert.\nSigniert (13) lloydsbank.com, halifax.co.uk, bankofscotland.co.uk, tsb.co.uk, co-operativebank.co.uk, smile.co.uk, monzo.com, aldermore.co.uk, hampshiretrustbank.co.uk, investec.com, handelsbanken.co.uk, allica.bank, weatherbys.bank Filialbanken, unsigniert hsbc.co.uk, firstdirect.com, barclays.co.uk, natwest.com, rbs.co.uk, ulsterbank.co.uk, santander.co.uk, nationwide.co.uk, virginmoney.com, clydesdalebank.co.uk, metrobankonline.co.uk, bankofireland.co.uk, aibgb.co.uk, danskebank.co.uk Digital- und Challenger-Banken, unsigniert starlingbank.com, revolut.com, chase.co.uk, marcus.co.uk, atombank.co.uk, zopa.com, tandem.co.uk, kroo.com, monese.com, cashplus.com, anna.money, mettle.co.uk Handel, unsigniert tescobank.com, sainsburysbank.co.uk, marksandspencer.com, johnlewisfinance.com Mittelstand und Spezialisten, unsigniert shawbrook.co.uk, paragonbank.co.uk, oaknorth.co.uk, recognisebank.co.uk, redwoodbank.co.uk, ccbank.co.uk, closebrothers.com, unitedtrustbank.co.uk, gbbank.co.uk, cynergybank.co.uk, securetrustbank.com Privatbanken, unsigniert coutts.com, hoaresbank.co.uk, arbuthnotlatham.co.uk, rathbones.com, brownshipley.com, butterfieldgroup.com Bausparkassen, unsigniert jede einzelne getestete: coventrybuildingsociety.co.uk, ybs.co.uk, skipton.co.uk, leedsbuildingsociety.co.uk, principality.co.uk, westbrom.co.uk, newcastle.co.uk, thenottingham.com, cumberland.co.uk, progressivebs.co.uk, saffronbs.co.uk, newburybs.co.uk, monbs.com, furnessbs.co.uk, ipswichbuildingsociety.co.uk, leekbs.co.uk, theloughborough.co.uk, mansfieldbs.co.uk, marsdenbs.co.uk, themelton.co.uk, familybuildingsociety.co.uk, penrithbs.co.uk, scottishbs.co.uk, srbs.co.uk, swansea-bs.co.uk, teachersbs.co.uk, thetipton.co.uk, thevernon.co.uk, beverleybs.co.uk, chorleybs.co.uk, dudleybuildingsociety.co.uk, esbs.co.uk, ecology.co.uk, harpendenbs.co.uk, hrbs.co.uk, darlington.co.uk, hanley.co.uk, bathbuildingsociety.co.uk Achtunddreißig Bausparkassen. Keine einzige signiert. Das sind die Institute, die die Hypothek auf sehr viele Häuser halten.\nZwei Muster in der signierten Spalte stechen heraus. Die Lloyds Banking Group hat drei ihrer Marken signiert, lloydsbank.com, halifax.co.uk und bankofscotland.co.uk, und die Co-operative Bank hat beide ihrer Marken signiert. Die Entscheidung fällt also einmal, auf Organisationsebene, und wird dann angewandt. Keine Hürde pro Domain darin.\nUnd Monzo hat signiert, während Starling es nicht hat. Zwei Challenger-Banken, im Abstand von einem Jahr gegründet, auf vergleichbar moderner Infrastruktur, mit derselben Aufsicht und denselben verfügbaren Registraren. Eine hat es getan.\nDer eine Ort, an dem es alle tun Schau dir die letzten beiden Namen in der signierten Spalte an: allica.bank und weatherbys.bank.\n.bank ist eine beschränkte Top-Level-Domain, betrieben von fTLD Registry Services, und ihre Sicherheitsanforderungen machen DNSSEC verpflichtend, neben TLS und E-Mail-Authentifizierung, mit jährlicher Neuprüfung jedes Registranten.9\nDieselben Institute, zwei Regime Signiert Auf einer gewöhnlichen Domain, wo DNSSEC optional ist 13 von 98 Auf .bank, wo es Pflicht ist und jährlich nachgeprüft wird beide Zwei ist eine kleine Zahl, nimm es also als Demonstration und nicht als Statistik. Die Anforderung bleibt trotzdem das Einzige, was sich geändert hat.\nDas ist die Antwort auf jede Ausrede weiter unten in diesem Beitrag, und sie kommt vor den Ausreden. Dieselben Banken, dieselben Dienstleister, dieselben Budgets und dieselben Fähigkeiten bringen 13 % Erfüllung, wenn es optional ist, und 100 %, wenn jemand jährlich nachsieht. Technisch hat sich nichts bewegt. Jemand hat einfach gefragt.\nNiemand bewacht die Wächter Eine Zertifizierungsstelle von neun.\nSigniert Nicht signiert entrust.com letsencrypt.org, digicert.com, sectigo.com, globalsign.com, identrust.com, buypass.com, zerossl.com, certum.eu Das sind die Organisationen, deren gesamtes Geschäft darin besteht, zu beweisen, dass etwas das ist, was es zu sein behauptet. Es sind auch die Organisationen, die die Kontrolle über eine Domain über DNS prüfen, indem sie dich bitten, einen Eintrag zu veröffentlichen, und ihn dann nachschlagen. Die Abfrage, die darüber entscheidet, ob du ein Zertifikat für eine Domain bekommst, ist bei acht dieser neun eine Abfrage, die niemand verifizieren kann.\nNichts Hypothetisches daran. Es ist die dokumentierte Form: Fälsch die Prüfabfrage, lass dir das Zertifikat ausstellen, und jetzt hältst du gültiges Papier für einen Namen, der dir nicht gehört. DNSSEC gehört zu den wenigen Dingen, die das spürbar schwerer machen, und die Leute, die es am meisten schützen würde, haben es nicht ausgerollt.\nEins sage ich dir gratis. Wenn dein Geschäftsmodell Identität ist und du deine eigene Zone nicht signiert hast, steht dir das Argument, es sei schwer, nicht zur Verfügung.\nUnd wer prüft eigentlich? Signieren ist nur die halbe Sache. Eine signierte Zone schützt niemanden, solange nicht am anderen Ende etwas die Signatur verifiziert, und hier wird das Bild schlechter statt besser.\nEs gibt zwei Orte, an denen Validierung stattfinden kann, und sie sind nicht gleichwertig:\nValidierung am Resolver lässt einen unbeglaubigten Hop übrig. Validierung auf dem Gerät nicht ZWEI ORTE, AN DENEN DER BEWEIS GEPRÜFT WERDEN KANN, UND SIE SIND NICHT DASSELBE Validierung am Resolver deine Anwendung glaubt dem Bit ein AD-Bit unbeglaubigt der Resolver prüft die Signaturen Kette geprüft die signierte Zone RRSIG und DS Du bekommst das Urteil, nicht den Beweis, über genau den Hop, dem zu misstrauen diese ganze Übung da ist. Validierung auf dem Gerät deine Anwendung prüft sie selbst Kette durchgängig geprüft, dort wo die Antwort benutzt wird die signierte Zone RRSIG und DS Nichts dazwischen kann dich belügen, weil nichts dazwischen gefragt wird. Nahezu alle Validierung der Welt ist die obere. Windows kann die untere bei keiner Einstellung. Das eine reicht dir ein Urteil. Das andere reicht dir den Beweis Nahezu alle Validierung der Welt ist von der ersten Art. Google, Cloudflare und Quad9 validieren alle und decken zusammen eine enorme Zahl von Nutzern ab. Das zählt etwas. Aber es heißt, dass die Eigenschaft, die die meisten Leute haben, lautet: mein Resolver sagt, das war in Ordnung.\nWas die einzelnen Betriebssysteme können Validiert auf dem Gerät Voreinstellung Wie du es bekommst Linux mit systemd-resolved Ja, vollständig aus eine Zeile in einem Drop-in Linux mit lokalem unbound oder knot-resolver Ja, vollständig k. A. installieren, den Stub darauf zeigen lassen FreeBSD mit local_unbound Ja, vollständig aus service local_unbound onestart macOS Ventura und neuer, iOS 16 und neuer Ja aus pro App oder pro Anfrage, im Code macOS und iOS davor nur API aus kDNSServiceFlagsValidate, die App muss fragen Android von der Plattform nicht angeboten k. A. eine Drittbibliothek, in deiner eigenen App Fisher-Price OS (Windows) Nein. Kann es nicht k. A. um keinen Preis erhältlich Zwei davon verdienen mehr als eine Zeile.\nApple hat die Arbeit still gemacht. iOS 16 und macOS Ventura haben clientseitige DNSSEC-Validierung ergänzt, in Apples eigenen Worten auf der WWDC 2022: „iOS 16 and macOS Ventura now support client side DNSSEC validation.“10 Sie ist opt-in statt automatisch, und sie ist opt-in in der richtigen Granularität, sodass eine Anwendung, der es wichtig ist, sie pro Sitzung oder pro Anfrage anfordern kann:\nlet configuration = URLSessionConfiguration.default configuration.requiresDNSSECValidation = true Ein echter validierender Resolver auf einem Telefon, der Signaturen auf dem Gerät prüft, und fast niemand hat mitbekommen, dass er ausgeliefert wurde. Davor stellte mDNSResponder kDNSServiceFlagsValidate für jeden bereit, der bereit war, die C-API zu benutzen.\nAndroid bietet es nicht an. Der DNS-Resolver ist seit Android 10 ein aktualisierbares Modul und bekam in Android 9 DNS over TLS, die Plattform hat bei DNS also nicht stillgestanden. Aber weder die AOSP-Resolver-Dokumentation noch die öffentliche DnsResolver-API dokumentiert DNSSEC-Validierung, und der Grund, warum es Bibliotheken wie MiniDNS gibt, die damit werben, „DNSSEC close to your application“ zu bringen, ist, dass die Plattform es nicht mitbringt. Ich habe keine Primärquelle gefunden, die rundheraus sagt, es sei unmöglich, also sage ich es nicht stärker als: nicht angeboten, und du würdest es selbst schreiben.\nUnd selbst dort, wo es funktioniert, wird es weggeworfen Noch eine Sache von dieser Maschine, mit der ich nicht gerechnet hatte.\nDer Upstream-Resolver hier validiert und sagt das auch. systemd-resolved wirft das mit DNSSEC=no weg, bevor irgendeine Anwendung es sieht:\n# ---- before: stock Fedora, DNSSEC=no ---------------------------------- $ dig @192.0.2.53 damiendye.uk A | grep flags # the upstream ;; flags: qr rd ra ad $ dig @127.0.0.53 damiendye.uk A | grep flags # the local stub ;; flags: qr rd ra # ---- the fix: two lines in a drop-in ---------------------------------- $ sudo mkdir -p /etc/systemd/resolved.conf.d $ printf \u0026#39;[Resolve]\\nDNSSEC=allow-downgrade\\n\u0026#39; \\ | sudo tee /etc/systemd/resolved.conf.d/10-dnssec.conf $ sudo systemctl restart systemd-resolved # ---- after: same query, same stub, nothing else changed --------------- $ resolvectl status | grep -m1 DNSSEC= DNSSEC=allow-downgrade/supported $ dig @127.0.0.53 damiendye.uk A | grep flags ;; flags: qr rd ra ad Gleicher Name, gleiche Antwort, gleiche Sekunde. Vor dem Drop-in hat der Upstream die Arbeit gemacht, das AD-Bit gesetzt, und der lokale Daemon hat es fallen lassen, die Voreinstellung ist also nicht schlicht wir validieren hier nicht, sie ist wir validieren hier nicht, und wir geben auch das Urteil von niemandem weiter, der es getan hat. Danach ist das Bit zurück, und diesmal ist es unseres statt der Behauptung eines anderen.\nresolvectl formuliert das Urteil aus, und es trennt die beiden, auf die es ankommt:\n$ resolvectl query damiendye.uk | tail -2 -- Data is authenticated: yes; Data was acquired via local or encrypted transport: no $ resolvectl query ncsc.gov.uk | tail -2 -- Data is authenticated: no; Data was acquired via local or encrypted transport: no Achte darauf, was das zweite nicht ist. Es ist kein Fehler. Eine unsignierte Zone kommt unbeglaubigt zurück statt bogus, die Auflösung gelingt, und nirgendwo beschwert sich etwas. Das ist das ganze Problem mit 1,63 %, neu formuliert als Befehl: Validierung anzuschalten lässt unsignierte Zonen nicht scheitern, es macht sie sichtbar, und nur für den, der hinschaut.\nDas größte Client-Betriebssystem scheitert an der einfachsten Prüfung Jetzt das andere Ende der Skala, und es ist nicht knapp.\nDer Windows-DNS-Client ist, in Microsofts eigener Beschreibung, „security-aware“, aber „non-validating“. Er führt keine DNSSEC-Validierung durch. Man kann ihn nicht dazu bringen. Was er stattdessen tut, ist, seinen konfigurierten DNS-Server um Validierung zu bitten und dann in der Antwort nach dem AD-Bit zu suchen.11\nDrei Dinge dazu, und keines davon ist klein:\nEr prüft nie eine Signatur. Die stärkste Garantie, die dem größten Client-Betriebssystem der Welt zur Verfügung steht, ist ein einzelnes Bit, gesetzt von der Maschine, die zufällig geantwortet hat. Nicht einmal das tut er standardmäßig. Der Client setzt das DO-Bit und verlangt AD nur für Namensräume, die in der Name Resolution Policy Table stehen, einem Gruppenrichtlinienobjekt, das jemand bewusst konfigurieren muss. Steht keine Regel darin, trägt die Abfrage überhaupt keine DNSSEC-Erwartung. Microsoft sagt, das Bit braucht IPsec, um etwas zu bedeuten. Ihre Dokumentation ist ausdrücklich, dass, weil der Client nicht validiert und sich auf den Server stützt, „IPsec is used to establish this trust relationship“. Ein AD-Bit, das über eine nicht authentifizierte Strecke eintrifft, ist eine Behauptung von dem, der zuerst da war, und genau dieser Angriff ist der, den diese ganze Technik verhindern soll. Auf dem Desktop mit der größten installierten Basis also, ab Werk: keine Validierung, keine AD-Anforderung, und kein authentifizierter Kanal zum Resolver. Die einfachste Prüfung ist nicht bloß abgeschaltet. Sie wurde nie implementiert.\nUnd die übliche Verteidigung, Client-Betriebssysteme machten so etwas einfach nicht, starb 2022. Apple lieferte geräteseitige Validierung an jedes iPhone und jeden Mac, im selben Jahr, in dem Microsoft es nicht tat. Der Vergleich ist nicht mehr Desktop gegen Server oder mobil gegen fest. Es ist ein Hersteller, der es gebaut hat, gegen einen, der es nicht hat.\nDas wiegt schwerer als dieselbe Lücke unter Linux, wegen der Betroffenen. Ein Linux-Server wird meist von jemandem betrieben, der die Validierung heute Nachmittag anschalten könnte und weiß, was ein DS-Eintrag ist. Die Maschinen, die überhaupt nicht validieren können, bei keiner Einstellung, sind die, die in den Organisationen auf den Schreibtischen stehen, deren Zonen in den Tabellen oben unsigniert sind. systemd-resolved liefert die Fähigkeit abgeschaltet aus, und das ist eine Entscheidung, die du in einer Zeile umkehren kannst.12 Das Fisher-Price OS (Windows) bringt die Fähigkeit gar nicht erst mit.\nDer Dienst, den DNS zusammenhält Alles bisher waren Namen im öffentlichen Internet. Dasselbe Loch existiert im Gebäude, und drinnen ist es tragend.\nActive Directory hat für nichts eine feste Adresse. Eine in die Domäne eingebundene Maschine weiß nicht, wo ihr Domänencontroller wohnt, also fragt sie DNS. Der Locator-Prozess fragt _ldap._tcp.dc._msdcs.\u0026lt;domain\u0026gt; nach den Controllern und _kerberos._tcp nach dem KDC ab, und was zurückkommt, ist das, wogegen sie sich authentifiziert.13\ndig +short _ldap._tcp.dc._msdcs.corp.example SRV Fälsch diese Antwort, und die Maschine trägt ihren Authentifizierungsverkehr zu einem Host, den du ausgesucht hast. Sei ehrlich, was das ist und was nicht: Kerberos gibt einem Hochstapler ohne die Schlüssel kein Ticket, das ist für sich genommen also keine Domänenübernahme. Es ist eine Position im Pfad, und daraus werden die interessanten Angriffe gebaut. Erzwing den Rückfall auf NTLM und leite ihn weiter. Setz dich mitten in Verkehr, der zu einem Controller gehen sollte. Oder zeig den ganzen Bestand ins Leere und sieh zu, wie die Anmeldungen aufhören.\nEin gefälschter Locator-Eintrag übergibt nicht die Domäne, er setzt den Angreifer in den Pfad WO IST MEIN DOMÄNENCONTROLLER? DIE ANTWORT IST NUR EIN DNS-EINTRAG Unsignierte `_msdcs`-Zone Mitgliedsserver _ldap._tcp.dc SRV erste Antwort gewinnt ein Host ihrer Wahl jetzt im Pfad NTLM-Rückfall, Relay oder keine Logons Kerberos gibt einem Hochstapler keine Tickets, das ist also keine Domänenübernahme. Es ist eine Position. Signierte Zone, validierender Client Mitgliedsserver prüft die Signatur Fälschung verworfen dein Controller die signierte Antwort Abgewiesen, bevor überhaupt etwas zu authentifizieren versucht. Windows Server kann diese Zone seit 2012 signieren. Der Client, der sie liest, kann bis heute nicht validieren. Keine Domänenübernahme. Eine Position im Pfad, und darauf wird der Rest gebaut Gruppenrichtlinien, Anmeldeskripte, verbundene Laufwerke und jede Vertrauensstellung unterhalb der Anmeldung werden alle genauso gefunden. Es ist der wertvollste Satz von Namen, den die meisten Organisationen besitzen, und er sitzt da unsigniert.\nMicrosoft hat die Server-Hälfte der Lösung gebaut, und gut gebaut. Eine AD-integrierte Zone kann signiert werden, Online-Signierung dynamischer Zonen kam mit Windows Server 2012, und weil die Zone im Verzeichnis liegt, replizieren die privaten Signaturschlüssel über die AD-Replikation selbst zu den anderen DNS-Servern.14 Der wirklich unangenehme Teil von DNSSEC, nämlich Schlüssel zu den Maschinen zu bringen, die sie brauchen, wurde hier vor vierzehn Jahren von genau dem gelöst, worüber die Zone ohnehin schon replizierte.\nDann hört es an denselben zwei Stellen auf wie alles andere:\nDie zwei Hälften Was Microsoft ausgeliefert hat Was du ab Werk bekommst Die _msdcs-Zone signieren Online-Signierung AD-integrierter dynamischer Zonen, Schlüssel von AD selbst repliziert nichts, bis eine Administratorin sie signiert Die Signatur prüfen der nicht validierende Client aus dem letzten Abschnitt eine Regel in der Policy-Tabelle plus IPsec, oder das Bit bedeutet nichts Die interne Zone, die entscheidet, welche Maschine dein Domänencontroller sein darf, ist in den meisten Beständen also genauso unsigniert wie die öffentliche. Der Unterschied ist, dass kein Außenstehender sie zählen kann, weshalb es in diesem Beitrag keine Tabelle gibt, die jemanden bloßstellt. Geh und schau dir deine eigene an, bevor du etwas annimmst.\nDas Betriebssystem sollte das tun, und es sollte an sein Womit ich zu dem Teil komme, den ich argumentieren statt zählen will.\nEine DNS-Antwort zu validieren ist Betriebssystemarbeit. Sie gehört in dieselbe Klasse von Aufgaben wie die Uhr richtig zu halten, einen Speicher vertrauenswürdiger Zertifikate zu führen und einen TLS-Stack zu haben, und aus denselben Gründen: Jede Anwendung braucht es, fast keine sollte es selbst schreiben, und die Prüfung muss einmal passieren, an einer Stelle, wo sie ordentlich gemacht werden kann. Für Zertifikate haben wir diese Diskussion vor langer Zeit beigelegt. Niemand liefert ein Mailprogramm mit einer eigenen privaten Meinung über Root-CAs aus.\nDrei der vier Plattformen oben können es bereits. Keine einzige tut es ab Werk:\n$ grep DNSSEC= /usr/lib/systemd/resolved.conf # Fedora 44, systemd 259.9 #DNSSEC=no Das ist die einkompilierte Voreinstellung, auskommentiert hingeschrieben, damit eine Administratorin sieht, was sie ist. systemds eigenes Handbuch vertritt eine andere Ansicht und empfiehlt allgemein allow-downgrade und true überall dort, wo man sich auf den Upstream verlassen kann.15 Der Code wird ausgeliefert, der Root-Vertrauensanker wird ausgeliefert, und die Dokumentation wird ausgeliefert und empfiehlt, es anzuschalten. Die Voreinstellung sagt weiterhin nein.\nPlattform Wer handeln muss, bevor eine Signatur geprüft wird systemd-resolved eine Administratorin, einmal, in einer Drop-in-Datei macOS 13 und neuer, iOS 16 und neuer die Autorin jeder einzelnen Anwendung Android die Autorin jeder Anwendung, mit einer Drittbibliothek Windows niemand kann es Diese Spalte ist das ganze Problem. Eine Anforderung ist ein Hebel, und die .bank-Zahl weiter oben zeigt, was sie bewirkt. Eine Voreinstellung ist derselbe Hebel, ohne dass jemand etwas durchsetzen müsste, denn sie entscheidet den Ausgang für alle, die die Konfigurationsdatei nie öffnen, und das sind so ziemlich alle. Optional hat uns 1,63 % beim Staat und 13 % im Bankwesen gebracht. Menschen entscheiden sich nicht aktiv für Sicherheit, die sie nicht sehen können, und mit der Technik recht zu haben hat daran noch nie etwas geändert.\nDer redliche Einwand ist, dass Validieren ab Werk Nutzer lahmlegt, wenn der Upstream-Resolver kaputt ist und nicht die Zone. Dafür ist allow-downgrade da, und es ist ein echter Kompromiss und kein geschenkter, denn ein Downgrade ist etwas, das ein Angreifer bewusst provozieren kann. Trotzdem wäre es eine enorme Verbesserung, allow-downgrade statt eines glatten no auszuliefern, und es würde den Schaden dorthin legen, wo er hingehört: zu dem, der 2026 immer noch einen Resolver betreibt, der mit DNSSEC nicht umgehen kann.\nValidierung anschalten, und welcher Teil davon Fedoras ist Fast alles, was folgt, ist systemds und nicht Fedoras und läuft auf Debian, Ubuntu oder Arch genauso. Zwei Dinge hier sind wirklich die der Distribution:\nUpstream-systemd Fedora 44, wie installiert Einkompiliertes default-dnssec allow-downgrade no Haupt-Konfigurationsdatei /usr/lib/systemd/resolved.conf, jede Voreinstellung zur Referenz auskommentiert liefert zusätzlich /etc/systemd/resolved.conf mit Cache=yes, was sie ersetzt Upstream wählt in meson_options.txt allow-downgrade, also die Kompromisseinstellung und nicht die mutige.16 Fedora kompiliert es auf no und liefert dann eine zweite Haupt-Konfigurationsdatei, und da nur die erste gefundene Datei benutzt wird, ist die, die die Voreinstellungen dokumentiert, nicht mehr die, die gilt.15 Bearbeite also keine von beiden. Die Herstellerkopie gehört dem Paket, und ein Update gibt dir deine Änderung postwendend zurück; die /etc-Kopie ist eine Datei, deren übrige Zeilen stillschweigend fehlen.\nNimm stattdessen ein Drop-in, was der Block weiter oben tut. Es überschreibt, welche Hauptdatei auch gewonnen hat, es übersteht Paket-Updates, und es enthält nur das, was du geändert hast. Prüf das Ergebnis mit systemd-analyze cat-config systemd/resolved.conf, das jede Datei in der angewandten Reihenfolge ausgibt und klärt, was tatsächlich gewonnen hat.\nDrei Einstellungen, und die Wahl zwischen den letzten beiden ist eine echte:\nDNSSEC= Was es tut Was es dich kostet no validiert nichts und wirft auch das Urteil des Upstreams weg Fälschung kommt still an, wie heute allow-downgrade validiert und tritt zurück, wenn der Upstream nicht mitkommt ein Angreifer kann diesen Rückzug bewusst provozieren yes validiert, Punkt, kein Zurück deine Namen gehen mit dem Upstream, an dem Tag, an dem er kaputtgeht Fang mit allow-downgrade an, denn ein kaputter Resolver kostet dich dann nichts. Wechsle auf yes, sobald resolvectl status vierzehn Tage lang supported gesagt hat und du weißt, was dein Upstream tatsächlich ist. Die Details pro Distribution für alles außer Fedora stehen im Resolved-Beitrag.12\nWas hält die Leute also wirklich auf Also gut. Die Zahlen sind die Zahlen. Warum?\nVier Gründe werden genannt, und sie sind nicht alle Unsinn.\nDer Grund Wie viel davon stimmt Schlüsselverwaltung ist schwer War wahr. Heute vom DNS-Anbieter weitgehend automatisiert Es kann deine Domain aus dem Internet nehmen Wahr, und der eigentliche Grund Unterstützung bei Registraren und Anbietern ist lückenhaft Weitgehend gelöst, und vorab leicht zu prüfen Kein sichtbarer Nutzen, kein Druck durch Vorschriften Wahr, und vermutlich ausschlaggebend Schlüsselverwaltung war ein echtes Hindernis und ist es meistens nicht mehr. Signieren hieß früher, eigene Schlüsselzeremonien zu fahren, rechtzeitig vor Ablauf der Signaturen neu zu signieren und Schlüssel von Hand nach einem Plan zu rollen, den du selbst im Blick behalten musstest. Diese Arbeit macht auf den meisten verwalteten Plattformen heute der DNS-Anbieter, und Signieren ist ein Schalter. Es ist nicht nichts, aber es ist kein Projekt mehr.\nDer Fehlerfall ist der redliche Einwand, und er ist der einzige der vier, für den ich echtes Verständnis habe. Mach DNSSEC falsch, und deine Domain verschlechtert sich nicht, sie verschwindet. Jeder validierende Resolver weist deine Einträge zurück, was er auch soll, und die Leute, die dich nicht erreichen, können von dir nicht erfahren, warum, denn dafür bräuchte es DNS.\nDrei Dinge machen es schlimmer als einen gewöhnlichen Ausfall:\nEs scheitert an einer Uhr, nicht an einer Änderung. Signaturen haben ein Ablaufdatum. Eine Zone, die seit Dienstag niemand angefasst hat, kann am Sonntag weg sein, weil ein Nachsignierungsjob still aufgehört hat zu laufen. Es scheitert für die einen und nicht für die anderen. Nur validierende Resolver weisen dich zurück. Deine eigene Überwachung meldet die Seite, wenn sie nicht validiert, als kerngesund, während ein wachsender Teil des Internets dich nicht erreicht. Es scheitert auf der Schicht, mit der du Dinge reparierst. Fernzugriff, deine Statusseite und deine eigene E-Mail können alle unter dem Namen liegen, der gerade verschwunden ist. Diese Furcht ist rational, sie hat große Betreiber vom Netz genommen, und jede redliche Argumentation für DNSSEC muss sich mit ihr hinsetzen, statt sie wegzuwischen.\nAber achte auf ihre Form: Es ist die Furcht vor einer betrieblichen Disziplin, die du derzeit nicht hast, nicht die Furcht vor der Technik.\nUnsigniert scheitert leise bei deinen Nutzern. Fehlkonfiguriert scheitert laut bei dir ZWEI ARTEN, WIE DAS SCHIEFGEHT, UND NUR ÜBER EINE WIRD GEREDET Unsigniert Eine gefälschte Antwort wird geglaubt. Nichts loggt sie. Nichts alarmiert. Hält so lange wie die TTL des Angreifers. Deine Überwachung bleibt grün. Die Kosten landen bei dem, der der Antwort geglaubt hat. Nicht bei dir. Signiert, und kaputt Die Domain verschwindet schlicht. Scheitert an einer Uhr, nicht an einer Änderung. Nur für validierende Resolver, deine eigenen Prüfungen sehen gut aus. Die Kosten landen bei dir, laut, mit deinem Namen auf dem Vorfall. Deshalb bekommt der zweite Fall einen Business Case und der erste nicht. Für einen Angriff, der nie entdeckt wurde, wird niemandem je ein Vorwurf gemacht. Unsigniert scheitert leise, bei deinen Nutzern. Fehlkonfiguriert scheitert laut, bei dir Und achte darauf, wer in welcher Spalte zahlt. Eine unsignierte Zone, die gefälscht wird, kostet deine Kunden, lautlos, und niemand meldet je einen Vorfall, weil es nie jemand herausfindet. Eine signierte Zone, die abläuft, kostet dich, sofort, öffentlich, mit deinem Namen auf dem Post-mortem. Beides sind Fehler. Nur einer davon taucht in irgendjemandes Zielvereinbarung auf.\nZertifikate hatten dasselbe Problem und haben es gleich doppelt gelöst: Der Fehler wurde sichtbar gemacht, und dann wurde er automatisiert. Eine Browser-Warnung machte ein abgelaufenes Zertifikat zu jedermanns Problem, Überwachung folgte, und dann machte Let\u0026rsquo;s Encrypt die Erneuerung zu etwas, das ein Cron-Job um drei Uhr morgens erledigt. Nichts davon machte Zertifikate im Prinzip einfacher. Es machte das Vergessen schwerer.\nUnterstützung durch Anbieter ist zehn Minuten Prüfen wert statt einer Annahme. Manche Registrare machen aus der Veröffentlichung eines DS immer noch ein Support-Ticket. Viele nicht.\nUnd der letzte Punkt ist die eigentliche Antwort, was die .bank-Registry weiter oben in diesem Beitrag bereits bewiesen hat. Es gibt kein Browser-Schloss für DNSSEC. Kein Kunde hat je eine Bank gewählt, weil ihre Zone signiert war, kein Prüfer lässt dich deswegen durchfallen, und keine allgemeine Vorschrift im Vereinigten Königreich verlangt es. Der Nutzen ist vollständig unsichtbar, wenn es funktioniert, der Preis für einen Fehler ist ein Ausfall mit deinem Namen daran, und die Person, die diesen Ausfall trägt, ist nicht die Person, die die Anerkennung bekäme.\nStell denselben Instituten eine Anforderung und eine jährliche Prüfung vor die Nase, und die Erfüllung geht von 13 % auf jedes einzelne. An der Technik hat sich zwischen diesen beiden Zahlen nichts geändert. An den Budgets, den Dienstleistern oder den Fähigkeiten auch nicht. Die einzige Variable war, ob jemand nachsehen würde.\nAngesichts dieser Anreize ist das Überraschende nicht, dass 1,63 % der Behördendomains signiert sind. Überraschend ist, dass es neununddreißig sind.\nAnschalten, ohne dich selbst vom Netz zu nehmen Das ganze Risiko sitzt an einer Stelle, also steck die Mühe dorthin. Der Ablauf der Signatur ist der Fehler, der eintrifft, ohne dass jemand etwas angefasst hat, also alarmiere darauf:\ndig +dnssec damiendye.uk SOA | awk \u0026#39;/RRSIG/ {print \u0026#34;sig expires\u0026#34;, $9}\u0026#39; Behandle es wie ein Zertifikat. Behalt das Datum im Auge, alarmiere weit davor, und mach die Erneuerung automatisch, damit der Alarm eine Rückfallebene ist und kein Arbeitsablauf.\nDann schalt es zu einer ruhigen Zeit an, an etwas, das nicht deine Hauptdomain ist, und lass vierzehn Tage vergehen, bevor du die machst, auf die es ankommt. Liegt dein DNS auf einer verwalteten Plattform, ist das Signieren selbst sehr wahrscheinlich ein Schalter, und der einzige wirklich manuelle Schritt ist, das DS bei deinem Registrar zu hinterlegen.\nIst das dasselbe Versagen wie bei IPv6? Es ist der naheliegende Vergleich, also habe ich beide Standards in denselben Gruppen am selben Tag gemessen. Dieselben Organisationen, dieselben Leute, zwei Entscheidungen.\nn DNSSEC signiert über IPv6 erreichbar Britische Banken und Bausparkassen 98 13,3 % 36,7 % Linux- und BSD-Distributionen 96 19,8 % 67,7 % Jede aktive gov.uk-Domain 2.380 1,6 % 31,2 % Die schwere Umstellung schlägt die leichte, drei zu eins und neunzehn zu eins DIESELBEN ORGANISATIONEN, BEIDE STANDARDS, AM SELBEN TAG DNSSEC signiert über IPv6 erreichbar Britische Banken 98 getestet 13,3 % 36,7 % Linux und BSD 96 getestet 19,8 % 67,7 % Jede aktive gov.uk 2.380 Domains 1,6 % 31,2 % IPv6 berührt jeden Router und Host. DNSSEC ist ein Eintrag bei deinem Registrar. Dieselben Organisationen, beide Standards, am selben Tag gemessen Neunzehnmal weiter beim Staat, auf denselben Domains.\nUnd jetzt setz dich damit hin, was wovon ist. IPv6 berührt jeden Router, jeden Host und jede Anwendung und will jahrelang Dual-Stack parallel betrieben haben. DNSSEC-Signierung ist ein Schalter und ein Eintrag, den du bei deinem Registrar einfügst.\nDie weit schwerere Aufgabe schlägt die leichte überall, wo ich hingesehen habe. Womit die bequeme Erklärung ausfällt, dass Infrastrukturstandards eben so laufen, langsam und widerwillig. DNSSEC bewegt sich nicht langsam. Es bewegt sich nicht.\nEin Unterschied gehört DNSSEC allein. Roll IPv6 aus, und du bekommst etwas zurück: Erreichbarkeit, kein Carrier-Grade NAT, das du kaufen musst. Signier deine Zone, und du persönlich bekommst nichts. Der Schutz landet bei deinen Nutzern, und nur bei denen hinter einem validierenden Resolver. Du nimmst ein dauerhaftes Ausfallrisiko auf dich, zugunsten von Leuten, die du nie treffen wirst, und das ist schwerer vor einen Vorstand zu bringen als jedes technische Hindernis in diesem Beitrag.\nDie IPv6-Hälfte dieser Argumentation habe ich anderswo geschrieben und wiederhole sie hier nicht.17\nLiegt es daran, dass wir DNS immer noch nicht verstehen? Zweiundvierzig Jahre, seit Mockapetris es im November 1983 aufgeschrieben hat.18 Sechzehn, seit die Root signiert wurde.\nIch halte das Verständnisproblem für real, und ich halte es für spezifischer, als dass Leute nicht wüssten, wie DNS funktioniert. Eine Menge fähiger Ingenieurinnen und Ingenieure kann Rekursion, Delegierung und Caching bestens beschreiben. Was fehlt, ist einen Schritt weiter, und dieser Schritt ist der, auf den es ankommt.\nFast niemand hat verinnerlicht, dass DNS ein Autorisierungssystem ist.\nEs wird als Installation behandelt. Als Nachschlagetabelle. Als etwas, das Namen in Zahlen verwandelt und dem gehört, der das Netz betreibt, gedanklich neben DHCP abgelegt. Und dieser Rahmen ist auf eine Weise falsch, die still sehr viel entscheidet, denn in der Praxis ist die DNS-Antwort das, was entscheidet, zu welcher Maschine dein Verkehr geht, von welchem Server deine Updates kommen und welchen Host eine Zertifizierungsstelle für deinen hält. Wer die Antwort kontrolliert, kontrolliert alle drei.\nMan sieht das Missverständnis im Muster, wer signiert hat. Nicht Budget, und auch nicht Können, und wenn man es einmal nebeneinanderlegt, ist es schwer als etwas anderes zu lesen denn als Muster dessen, was DNS für jeden von ihnen ist:\nWer signiert hat Was DNS für sie ist Registries und TLD-Betreiber, 100 % der gTLDs das Produkt selbst Ein Nachrichtendienst eine Angriffsfläche, weil in ihrem Bedrohungsmodell Fälschung vorkommt Neun Gemeinderäte ein Schalter, den ihr Hoster angeboten hat und den jemand umgelegt hat Die Kunden eines DNS-Anbieters eine Voreinstellung, die sie geerbt haben Wer nicht Banken, Ministerien, Hersteller, Zertifizierungsstellen Installation, und eine Ebene unter den interessanten Problemen Die Leute, die DNS als Sache an sich am nächsten sind, haben alle signiert. Die Leute, die es als Versorgungsleistung konsumieren, haben es fast ausnahmslos nicht, wie gut ausgestattet und wie sicherheitsbewusst sie sich auch halten. GCHQ hat nicht signiert. Acht von neun Zertifizierungsstellen haben nicht signiert. Das sind keine Organisationen, denen es an klugen Köpfen oder an Bedrohungsmodellen fehlt.\nDas ist auch der Grund, warum die Antwort auf Kaminsky 2008 lautete, das Raten zu erschweren, statt den Ausbau dessen zu Ende zu bringen, was Raten irrelevant macht. Das Raten zu erschweren ist eine Installationsreparatur, und als Installation hatte die Branche DNS abgelegt.\nEine Generation hat DNS als Verzeichnis gelernt und den Eintrag nie überarbeitet, als es still zu dem wurde, was entscheidet, mit wem du redest.\nWir haben es gebaut und dann liegen lassen Die Registries, die Betreiber und die Standardisierer haben den schweren Teil gemacht. Sie haben ihn geschrieben, ihn ein Jahrzehnt lang durch die IETF gestritten, die Root in einer Zeremonie mit Zeugen signiert und 100 % der generischen Top-Level-Domains signiert bekommen. Das ist ein echtes Stück gemeinsamer Ingenieursarbeit, und es ist fertig.\nUnd dann haben wir übrigen unseren Teil nicht gemacht, weil unser Teil langweilig ist, unsichtbar, das ganze persönliche Risiko trägt und keine Anerkennung, und weil niemand nachsieht.\nDas ist die Form jedes Standards, den niemand durchsetzt: Die Kosten trägt man allein, und der Nutzen zeigt sich erst, wenn genug andere sie auch getragen haben. Also haben die Registries sie getragen, und die Leute, die die Leitlinien zum Tragen veröffentlichen, haben es nicht.\nNur war die Aufgabe hier kleiner als fast alle davon. Die Kette war schon gebaut und bezahlt, von jemand anderem. Übrig blieb ein einziger Eintrag.\nUnd wenn das der Teil ist, den wir sehen können Ein letzter Gedanke, und ich will klarstellen, dass er eine Schlussfolgerung ist und keine Messung, denn alles andere in diesem Beitrag ist gezählt und das hier nicht.\nDNSSEC ist ungefähr die am leichtesten zu beurteilende Sicherheitsmaßnahme, die es gibt. Sie kostet nichts, die Arbeit ist ein Nachmittag, der Standard ist seit zwanzig Jahren fertig, und jeder kann sie von außen mit einem Befehl prüfen, ohne zu fragen. Kein Audit, kein Fragebogen, keine Geheimhaltungsvereinbarung. Ein dig.\nWas sagt dir 1,6 % also über die Maßnahmen, die man von hier draußen nicht sehen kann?\nDie Maßnahme Kann ein Außenstehender sie prüfen Kostet Geld Sichtbar, wenn sie wirkt Ein DS-Eintrag bei deinem Registrar Ja, ein Befehl nein nein MFA auf den Konten, auf die es ankommt nein ja nein Backups, die dieses Jahr zurückgespielt wurden, nicht bloß gezogen nein ja nein Netzwerksegmentierung nein ja nein Jede Zeile unter der ersten ist schwerer als eine Zone zu signieren, kostet echtes Geld, braucht jemanden, der sie verantwortet, und teilt genau die Eigenschaft, die DNSSEC versenkt hat: unsichtbar, wenn sie wirkt, und niemand prüft von außen nach. Das Einzige, was die oberste Zeile vom Rest trennt, ist, dass du sie prüfen kannst, umsonst, über jeden, sofort.\nHat eine Organisation die kostenlose Sache nicht gemacht, die einen Nachmittag dauert und die eine Fremde mit einem Befehl verifizieren kann, neige ich nicht zu der Annahme, dass sie die teuren Sachen gemacht hat, die ein Programm brauchen und nur von jemandem verifiziert werden können, den sie hereinlässt.\nDer naheliegende Schritt ist nun, das gegen die Vorfallsakte zu testen, und ich habe es versucht. Von 23 britischen Organisationen mit dokumentierten schweren Vorfällen sind 22 unsigniert.\nDiese Zahl beweist nichts, und ich werde nicht so tun als ob. Bei einer Grundrate von 1,6 % ist eine signierte Organisation in einer Liste von 23 genau das, was der Zufall vorhersagt. Schlimmer noch: Die signierte Menge besteht aus neun Gemeinderäten und drei Nationalparks, während die unsignierte Menge jedes große Ministerium und jede große Stadt umfasst, also treibt die Größe sowohl, wer angegriffen wird, als auch, wer in den Nachrichten landet. Jeder Vergleich der Vorfallsraten zwischen den beiden Gruppen würde messen, wie groß eine Organisation ist, und nicht, ob sie signiert hat.\nAlso nein, ich kann dir nicht zeigen, dass signierte Organisationen seltener kompromittiert werden. Das kann niemand, nicht mit Daten, an die irgendjemand herankommt, und wer dir etwas anderes erzählt, macht sich etwas vor.\nDie getroffenen Organisationen haben aufgeschrieben, was versagt hat Du brauchst meine Schlussfolgerung nicht, denn sie haben es selbst veröffentlicht, und was versagt hat, ist die Liste oben.\nDie British Library ist die beste davon, weil sie es nach ihrem Ransomware-Angriff von 2023 freiwillig und ausführlich aufgeschrieben hat. Ihr eigener Bericht benennt die Ursachen: Einstieg höchstwahrscheinlich über ein Drittanbieterkonto auf einem Terminaldienste-Server ohne Mehrfaktor-Authentifizierung, dann Altinfrastruktur und begrenzte Netzwerksegmentierung, die den Angreifern erlaubten, sich über den Bestand zu bewegen, wobei die wachsende Komplexität des Drittanbieterzugangs intern schon 2022 als Risiko vermerkt war und ein Jahr später immer noch bestand.19 Die Datenschutzaufsicht ICO kam zu denselben Schlüssen.20\nDrei Zeilen der Tabelle oben also, von der Organisation selbst von innen bestätigt statt von mir hier draußen gefolgert.\nUnd bevor jemand daraus einen Stock macht: Die British Library verdient das Gegenteil, und ich werde deutlich sagen, warum.\nSie waren offen. Fast niemand sonst ist das. Es gab keinerlei Verpflichtung, auch nur ein Wort davon aufzuschreiben. Das übliche Drehbuch nach einem Vorfall lautet, so wenig zu sagen, wie das Gesetz erlaubt, es durch eine Kommunikationsabteilung zu geben, jede konkrete Bestätigung abzulehnen und zu warten, bis die Nachrichtenlage weiterzieht. Genau das haben die meisten Organisationen in den unsignierten Spalten oben getan, als sie an der Reihe waren, und darum hängt es an der Entscheidung einer einzigen Institution, sich anders zu verhalten, dass dieser Abschnitt überhaupt geschrieben werden kann.\nStattdessen haben sie einen achtzehnseitigen Bericht veröffentlicht, der ihre eigenen Versäumnisse benennt, öffentlich, damit andere Institutionen daraus lernen können. Das ist das Verhalten, das man sich von jeder Organisation in diesem Beitrag wünschen würde und von fast keiner bekommt. Der Grund, warum ich dir zeigen kann, was in einer kompromittierten Organisation tatsächlich versagt, ist, dass die British Library sich entschieden hat, es dir zu sagen.\nUnd es gibt einen zweiten Grund, warum die übrigen schweigen, und der ist schlimmer als eine Kommunikationsstrategie. Manche von ihnen gibt es nicht mehr.\nKNP Logistics bewegte seit 1865 als Knights of Old Fracht. Im Juni 2023 kam die Akira-Gruppe herein, verschlüsselte das Unternehmen und verlangte etwa fünf Millionen Pfund. Bis September war die Gruppe insolvent und 730 Menschen waren ihre Arbeit los.21 Hundertachtundfünfzig Jahre, weg in vierzehn Wochen, und dort schreibt niemand irgendwelche Lehren für dich auf.\nWenn die unsignierten Spalten oben also still wirken, besteht diese Stille aus drei verschiedenen Dingen: Organisationen, die noch nicht getroffen wurden, Organisationen, die getroffen wurden und so wenig sagten, wie das Gesetz erlaubt, und Organisationen, die getroffen wurden und weg sind. Nur die erste Gruppe hat noch Zeit zu handeln.\nWas das Nächste zur redlichen Prüfung meiner eigenen Argumentation macht und nicht zum billigen Seitenhieb. Ich habe ihre Zone geprüft:\n$ dig +short bl.uk DS (nothing) $ dig +short bl.uk DNSKEY (nothing) bl.uk ist unsigniert. britishlibrary.co.uk ebenfalls. Zwei Jahre nach einem Ransomware-Angriff, der die Institution monatelang lahmlegte, nach einem öffentlichen Bericht, nach einem ICO-Befund und nach der gründlichsten Runde sicherheitstechnischer Aufmerksamkeit, die eine Organisation je bekommt, ist die kostenlose Maßnahme, die einen Nachmittag dauert und die eine Fremde mit einem Befehl verifizieren kann, immer noch nicht erledigt.\nIch lese das nicht als Nachlässigkeit, und ich halte sie deswegen nicht für schlechter als die unsignierten Organisationen, die gar nichts veröffentlicht haben. Ich lese es als den stärksten Beleg in diesem Beitrag für das, worum es die ganze Zeit ging. Wenn DNSSEC nicht einmal hier gemacht wird, bei einer Organisation, die durchs Feuer gegangen ist, die Lehren aufgeschrieben hat und über die die Aufsicht gegangen ist, dann wird es nicht übersprungen, weil Leute nachlässig sind. Es wird übersprungen, weil es nichts und niemand je auf die Liste setzt.\nDas ist die redliche Fassung der Argumentation. Nicht unsignierte Zonen verursachen Einbrüche, was unbeweisbar und vermutlich falsch ist. Sondern: Die Maßnahmen, die von außen niemand sehen kann, sind nach dem veröffentlichten Zeugnis derer, die es durchgemacht haben, genauso vernachlässigt wie die eine Maßnahme, die von außen jeder sehen kann. DNSSEC ist nicht die Ursache. Es ist die Probe, die du ziehen darfst.\nUnd deshalb lohnt sich die Messung überhaupt. Nicht weil eine unsignierte Zone für sich genommen der Weltuntergang wäre, sondern weil sie eine der ganz wenigen Sicherheitseigenschaften ist, die eine Außenstehende ehrlich, umsonst und über jeden prüfen kann, ohne hereingelassen zu werden. Behandle sie als Rauchmelder und nicht als Urteil, und dann geh und stell die härteren Fragen an den, bei dem er losgeht.\nDer einzige Teil, den du kontrollierst Womit der einzige Teil bleibt, den irgendeine von uns tatsächlich kontrolliert. Deine eigene Zone. Nicht die des NCSC, nicht die von Microsoft, nicht die deiner Bank.\nGeh und frag deinen Elternteil, ob er für dich bürgt:\ndig +short yourdomain.uk DS Kommt das leer zurück, bist du nicht signiert, und auf den meisten verwalteten DNS-Plattformen ist die Lösung 2026 ein Schalter und ein DS-Eintrag bei deinem Registrar. Schalt es an, und behalt dann den Ablauf so im Auge, wie du deine Zertifikate ohnehin schon im Auge behältst, denn das ist die Disziplin, die die Sache tatsächlich braucht.\nDas ist die ganze Aufgabe. Ein Eintrag, und ein Datum in deiner Überwachung.\nAlso bitte, mach wenigstens diese eine Sache. Nicht weil eine Aufsichtsbehörde kommt, denn für die meisten von euch kommt keine, und nicht weil dir jemand danken wird, denn das wird niemand. Mach es, weil niemand kommt, und weil ein Standard, den du einhältst, wenn keiner nachsieht, der einzige ist, der je etwas wert war.\nNeununddreißig Gemeindeschreiber und ein Geheimdienst haben es hinbekommen. Reiß dich zusammen und bring es hinter dich.\nRFC 4033 — „DNS Security Introduction and Requirements“, Arends et al., März 2005. Die aktuelle DNSSEC-Spezifikation, zusammen mit RFC 4034 und RFC 4035.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nIANA root trust anchors — das XML, das die IANA veröffentlicht. Der erste Key-Digest trägt validFrom=\u0026quot;2010-07-15\u0026quot;, das Datum der Root-Signierung; der aktuelle KSK, Key-Tag 20326, trägt validFrom=\u0026quot;2017-02-02\u0026quot;.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCERT VU#800113 — „Multiple DNS implementations vulnerable to cache poisoning“, das Advisory von 2008 zur Kaminsky-Technik und die Quelle der koordinierten Antwort mit zufälligen Quellports.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nThe root zone file — geholt am 27. September 2026, SOA-Seriennummer 2026092701. Die Zahlen in diesem Beitrag stammen aus dem direkten Parsen der NS-Delegierungen und DS-Einträge in dieser Datei.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nList of gov.uk domain names — das eigene Register der Regierung. Die aktuellste veröffentlichte Datei ist auf den 1. Oktober 2016 datiert und listet 3.004 Second-Level-Domains.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMicrosoft Security Response Center — Flame malware collision attack explained — „An attacker took advantage of the Terminal Services licensing system\u0026rsquo;s enrollment process for certificates that chained up to the Microsoft Root Authority which did not require internal access to Microsoft PKI“; das gefälschte Zertifikat „could be used to sign code that chained up to the Microsoft Root Authority and worked on all versions of Windows“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nSentinelOne — Driving Through Defenses: targeted attacks leverage signed malicious Microsoft drivers und Bitdefender\u0026rsquo;s FiveSys analysis — bösartige Kerneltreiber mit Signaturen, die Microsoft direkt über das Windows Hardware Compatibility Program ausgestellt hat, darunter Treiber, die später in Ransomware-Angriffen eingesetzt wurden.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMicrosoft Security Response Center — Results of major technical investigations for Storm-0558 key acquisition — ein Consumer-Signaturschlüssel geriet über eine Race Condition in einen Crash-Dump, wurde nach der Kompromittierung des Firmenkontos eines Mitarbeiters entwendet und benutzt, um Token zu fälschen, die das Mailsystem fälschlich für Unternehmenskonten akzeptierte.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nfTLD Registry Services security requirements — die Registry für .bank und .insurance. „.BANK domain names must be signed with DNSSEC with strong cryptographic algorithms“, neben verpflichtendem TLS und E-Mail-Authentifizierung, mit jährlicher Neuprüfung jedes Registranten.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nApple, WWDC 2022 session 10079, „Improve DNS security for apps and servers“ — „iOS 16 and macOS Ventura now support client side DNSSEC validation“, aktivierbar pro Sitzung oder pro Anfrage über requiresDNSSECValidation an URLSessionConfiguration, URLRequest oder NWParameters.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMicrosoft Learn — Understanding DNSSEC in Windows — der Windows-DNS-Client „is non-validating, which means it does not perform DNSSEC validation and relies on its local DNS servers“; die AD-Bit-Erwartung wird von der Name Resolution Policy Table gesteuert, und „IPsec is used to establish this trust relationship“ mit dem DNS-Server.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nResolved: Der Resolver, den du schon betreibst — der gemessene Zustand von systemd-resolved, einschließlich der Frage, warum jede verbreitete Distribution DNSSEC=no zur Kompilierzeit ausliefert, und wie du das änderst.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMS-ADTS: DNS-Based Discovery — die Active-Directory-Protokollspezifikation zum Auffinden eines Domänencontrollers, einschließlich der _ldap._tcp.dc._msdcs-SRV-Abfrage, die ein Client stellt, um die Controller für einen Namenskontext zu finden.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMicrosoft Learn — Sign DNS zones with DNSSEC on Windows Server und What is DNSSEC on DNS Server in Windows Server? — Zonensignierung kam mit Windows Server 2008 R2, sperrte aber dynamische Updates, und Windows Server 2012 ergänzte die Online-Signierung dynamischer Zonen. Bei einer Active-Directory-integrierten Zone replizieren die privaten Signaturschlüssel über die Active-Directory-Replikation zu den anderen primären DNS-Servern.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nresolved.conf(5), systemd 259.9 wie in Fedora 44 ausgeliefert — das Handbuch empfiehlt allow-downgrade und true auf Systemen, auf denen man sich auf den Upstream-Resolver verlassen kann, während die paketierte Voreinstellung in /usr/lib/systemd/resolved.conf DNSSEC=no lautet.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nsystemd meson_options.txt — option('default-dnssec', type : 'combo', choices : ['yes', 'allow-downgrade', 'no'], value : 'allow-downgrade'). Upstreams gewählte Voreinstellung ist allow-downgrade; das #DNSSEC=no in Fedoras Herstellerdatei ist das, was dieser Build stattdessen gesetzt hat.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nUns sind nie die Adressen ausgegangen. Uns ist die Mühe ausgegangen. — die IPv6-Fassung dieser Argumentation, einschließlich der 463 britischen Organisationen mit IPv6-Zuteilungen, die überhaupt kein IPv6 ankündigen, und des Punkts, dass ein CGNAT eine Bestellnummer hat, während es richtig zu machen keine hat.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 882 — „Domain Names: Concepts and Facilities“, P. Mockapetris, November 1983. Die ursprüngliche Spezifikation, 1987 durch RFC 1034 und RFC 1035 abgelöst.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nBritish Library, „Learning Lessons from the Cyber-Attack“, 8. März 2024 — der eigene Bericht der Bibliothek zum Ransomware-Angriff vom Oktober 2023, der das Fehlen der Mehrfaktor-Authentifizierung auf dem für den Einstieg genutzten Konto, Altinfrastruktur, begrenzte Netzwerksegmentierung und die 2022 als Risiko vermerkte Komplexität des Drittanbieterzugangs benennt.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nICO statement on the British Library\u0026rsquo;s 2023 ransomware attack, April 2025.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nThe Record — UK logistics firm blames ransomware attack for insolvency, 730 redundancies — KNP Logistics Group, Muttergesellschaft des 158 Jahre alten Knights of Old, im Juni 2023 von Akira angegriffen, nachdem ein Mitarbeiterpasswort ohne jede Mehrfaktor-Authentifizierung per Brute Force geknackt worden war, und im September insolvent.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://blogs.damiendye.uk/de/dns/dnssec-the-root-is-signed-you-are-not/","summary":"Der schwere Teil von DNSSEC war vor Jahren fertig. Am 27. September 2026 aus der Live-Root-Zone gezählt, tragen 1.351 von 1.438 Top-Level-Domains einen DS-Eintrag, und alle 1.038 gTLDs sind signiert. Dann ist schlagartig Schluss. Eine Vollerhebung über jede gov.uk-Domain im amtlichen Register findet 39 signierte von 2.390, die noch auflösen, neun davon Gemeinderäte, während HMRC, der NHS, GCHQ und das National Cyber Security Centre nicht dabei sind. Eine von neun Zertifizierungsstellen hat signiert. Eine von drei Linux-Distributionen ebenfalls. windowsupdate.com hat gar kein DS. Das hier ist, was eine gefälschte Antwort tatsächlich kostet, was Signieren dagegen tut, warum die üblichen Ausreden den Zahlen nicht standhalten, und ob das eigentliche Problem zweiundvierzig Jahre nach Mockapetris darin besteht, dass fast niemand versteht, was DNS eigentlich verspricht.","title":"DNSSEC: Deinen Verkehr vor Fälschung schützen"},{"content":"Auf deiner Maschine läuft gerade jetzt ein DNS-Resolver. Du hast ihn nicht installiert, du hast ihn wahrscheinlich nie konfiguriert, und er beantwortet jede Namensabfrage, die die Kiste macht. Auf Fedora, Ubuntu und den meisten Desktop-Linuxen ist das systemd-resolved, und es sitzt dort still seit dem Tag, an dem das System installiert wurde.\nEs kann drei Dinge, die es wert sind. Es cacht, sodass dieselbe Abfrage nicht zweimal über das Netz geht. Es validiert DNSSEC, sodass eine gefälschte Antwort verworfen statt geglaubt wird. Und es spricht DNS over TLS, sodass das lokale Netz nicht jeden Namen mitlesen kann, nach dem du fragst.\nStandardmäßig tut es genau eines davon. Die anderen beiden sind abgeschaltet, und auf manchen Distributionen sind sie zur Kompilierzeit abgeschaltet, was heißt, dass die Einstellung, die du ändern würdest, gar nicht die Einstellung ist, die es entschieden hat. Ein Validator, der nie validiert, ist weder Nutzen noch Zierde.\nDas hier ist, was das Ding tatsächlich tut, gemessen auf einer laufenden Fedora-44-Kiste mit systemd 259, und was sich ändert, wenn du die anderen beiden anschaltest. Einschließlich dessen, was deine Distribution zur Kompilierzeit für dich entschieden hat, und wie viel davon du schlicht überstimmen kannst.\nWas deine Abfragen tatsächlich beantwortet Fang mit dem ehrlichen Bild an, denn „es benutzt /etc/resolv.conf“ ist auf diesen Systemen seit Jahren nicht mehr wahr.\nsystemd-resolved stellt sich auf vier verschiedene Arten bereit, und welche ein Programm benutzt, entscheidet, was es zurückbekommt.1 Der glibc-Weg ist nss-resolve, eingehängt über /etc/nsswitch.conf. Die nativen Wege sind D-Bus und Varlink, die das DNSSEC-Urteil und den Interface-Scope tragen, die getaddrinfo nicht ausdrücken kann. Dann der Stub-Listener, ein echter DNS-Server auf dem Loopback für alles, was rohes DNS spricht und von all dem oben nichts weiß.\nVier Türen, ein Daemon.\nAuf dieser Maschine sieht diese Verdrahtung so aus:\n$ ls -l /etc/resolv.conf lrwxrwxrwx. 1 root root 39 May 30 13:56 /etc/resolv.conf -\u0026gt; ../run/systemd/resolve/stub-resolv.conf $ cat /etc/resolv.conf nameserver 127.0.0.53 options edns0 trust-ad search damiendye.uk $ grep ^hosts: /etc/nsswitch.conf hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns resolve in dieser Zeile ist nss-resolve. dns dahinter ist das traditionelle nss-dns, das dort als Fallback sitzt und nur greift, wenn resolved überhaupt nicht läuft.\nVier Wege hinein, ein Daemon, und eine Routing-Entscheidung, bevor etwas die Kiste verlässt WIE EIN PROGRAMM FRAGT WAS DER DAEMON TUT WOHIN ES GEHT nss-resolve glibc, kein Urteil D-Bus, Varlink nativ, volles Urteil 127.0.0.53 der volle Stub 127.0.0.54 der Proxy-Stub systemd-resolved 1. hosts und synthetisch 2. Cache 3. DNSSEC-Validator 4. Routing 5. Transport der Proxy-Stub überspringt 2 und 3 LLMNR auf 5355 vorgelagertes DNS Vier Wege hinein, ein Daemon, und eine Routing-Entscheidung, bevor irgendetwas die Kiste verlässt Es gibt zwei Stub-Listener, nicht einen Jeder kennt 127.0.0.53. Weniger Leute wissen, dass es einen zweiten gibt.\n$ ss -lntup | grep \u0026#39;:53 \u0026#39; udp UNCONN 0 0 127.0.0.54:53 0.0.0.0:* udp UNCONN 0 0 127.0.0.53%lo:53 0.0.0.0:* tcp LISTEN 0 4096 127.0.0.54:53 0.0.0.0:* tcp LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:* Das sind nicht zwei Adressen für dieselbe Sache. Die zweite tut bewusst weniger:2\n127.0.0.53 127.0.0.54 Rolle Der volle lokale Resolver Nur Proxy-Modus Cache Ja Nein DNSSEC-Validierung Ja, wenn aktiviert Nie LLMNR und Multicast DNS Ja Nein Synthetische Namen (localhost, _gateway) Ja Nein Upgrade auf DNS over TLS Ja Ja Synthetischer Name dafür _localdnsstub _localdnsproxy Du bekommst zurück Was resolved entschieden hat Was der Vorgelagerte gesagt hat Die Dokumentation ist über die zweite Spalte unverblümt. Der Proxy-Stub werde „pass most DNS messages relatively unmodified to the current upstream DNS servers and back, but not try to process the messages locally, and hence does not validate DNSSEC, or offer up LLMNR/MulticastDNS“.2\nDas macht 127.0.0.54 zum richtigen Ziel für ein Programm, das seine eigene Validierung machen will, oder für eines, das die rohe Antwort des Vorgelagerten braucht statt resolveds Deutung davon.\nBeide Adressen haben synthetische Namen, _localdnsstub und _localdnsproxy, die ganz ohne Konfiguration auflösen.\nVier Modi für /etc/resolv.conf, nicht drei Der Modus wird automatisch daraus erkannt, was die Datei ist, und es gibt vier davon.1\n/etc/resolv.conf ist Was es heißt Clients, die NSS umgehen Symlink auf run/systemd/resolve/stub-resolv.conf Der empfohlene Modus. Listet 127.0.0.53 und die aktuellen Suchdomänen Gehen durch resolved Symlink auf /usr/lib/systemd/resolv.conf Statisch, listet 127.0.0.53, trägt keine Suchdomänen Gehen durch resolved Symlink auf run/systemd/resolve/resolv.conf Listet die echten vorgelagerten Server, aktuell gehalten Umgehen resolved vollständig eine echte Datei, die etwas anderes verwaltet resolved liest sie als Konsument, nicht als Lieferant Umgehen resolved vollständig Die dritte Zeile erwischt die Leute. Sie sieht nach der ordentlichen Option aus, sie wird aktuell gehalten, und sie heißt stillschweigend, dass jedes Programm, das resolv.conf direkt liest, mit dem Resolver deines Providers spricht, ohne Cache, ohne Validierung und ohne Verschlüsselung, egal was du in resolved.conf konfiguriert hast.\nDie trust-ad-Option in der Datei oben zählt auch. Ohne sie streift glibc das AD-Bit von der Antwort, bevor dein Programm sie sieht, aus dem vernünftigen Grund, dass die Behauptung eines beliebigen Resolvers, etwas validiert zu haben, nichts wert ist. Mit 127.0.0.53 als Nameserver kommt die Behauptung von deiner eigenen Maschine, also ist trust-ad hier richtig, und resolved schreibt es für dich hinein.\nZu den systemd-Verschwörungstheorien Vor allem Detail, denn das ist das Thema, bei dem es immer auftaucht.\nWenn dein Einwand gegen das Folgende eine Theorie über Lennart Poettering persönlich ist, oder über Red Hats Beweggründe, oder darüber, dass systemd ein Komplott sei, dir etwas wegzunehmen, dann zieh Leine, denn ich habe kein Interesse daran, deine Erfindungen zu hören.\nAlles in diesem Beitrag stammt von einer laufenden Maschine: der Quelltext, die Build-Flags, die ausgelieferte Binary, die Manpages und das gemessene Verhalten. Zu jeder Behauptung steht ein Befehl daneben, den du selbst ausführen und prüfen kannst. Die Build-Flags sind öffentlich. Der Quelltext ist öffentlich. Die eine Voreinstellung, die ich für wirklich falsch halte, wurde von Leuten gewählt, die ihre Begründung dort aufgeschrieben haben, wo jeder sie lesen und mit ihnen streiten kann, was genau das ist, was ich weiter unten tue.\nDas ist erheblich mehr Transparenz, als du von den meisten Programmen bekommst, die du ohne ein Wort der Klage betreibst.\nBring Belege oder lass es.\nDer Cache ist der Teil, der einfach funktioniert Das ist die eine Funktion, die überall standardmäßig an ist, und die einzige, die sich ganz ohne Konfiguration bezahlt macht.\nDie Messung, auf dieser Kiste, über 32 Domänen. Cache leeren, alle abfragen, noch einmal abfragen, und die Query-Zeit lesen, die dig meldet, statt den Prozess zu stoppen:\n$ resolvectl flush-caches $ for n in $NAMES; do dig +tries=1 @127.0.0.53 \u0026#34;$n\u0026#34; A | grep \u0026#39;Query time\u0026#39;; done Median Mittel p90 max gesamt für 32 Namen kalter Cache 103,5 ms 106,7 ms 184 ms 238 ms 3.414 ms warmer Cache 0,0 ms 0,5 ms 1 ms 3 ms 16 ms 3.414 Millisekunden gegen 16. Das ist das ganze Argument für einen lokalen Cache, und deshalb ist er die Voreinstellung.\nEs lohnt sich aber, ehrlich zu sein, was diese Zahl ist. Sie ist die Ersparnis über einen Durchlauf von zweiunddreißig Namen, die nie nachgeschlagen worden waren, gegen denselben Durchlauf wiederholt, und keine echte Last sieht wie eines von beiden aus. Die nützliche Zahl ist der Ausläufer statt des Medians: die schlechteste Abfrage in diesem Satz kostete 238 ms kalt und 3 ms warm. Eine Seite, die acht Hostnamen hereinzieht, schert sich nicht um deinen Median, sie wartet auf deinen langsamsten.\nDie Regler [Resolve] Cache=yes # yes | no-negative | no CacheFromLocalhost=no # default: do not cache answers from 127.0.0.1 StaleRetentionSec=0 # serve expired records when upstream is down Einstellung Voreinstellung Was sie tut Cache=yes an Positive und negative Antworten cachen Cache=no-negative Nur positive Antworten, für wenn du es leid bist, eine negative TTL abzuwarten CacheFromLocalhost=no an Überhaupt nicht cachen, wenn der Vorgelagerte auf 127.0.0.1 liegt StaleRetentionSec=0 aus Abgelaufene Einträge ausliefern, wenn der Vorgelagerte nicht mehr antwortet DNSCacheSize=4096 4096 Einträge pro Scope. Erst ab systemd 261 Die dritte Zeile ist die, die beißt. Wenn dein Vorgelagerter ein dnsmasq oder ein unbound auf dem Loopback ist, cacht resolved dessen Antworten überhaupt nicht, mit der Begründung, dass das Ding, mit dem es spricht, bereits ein Cache ist. Zeig resolved auf einen filternden Resolver auf einem anderen Host, und du bekommst zwei Cache-Ebenen. Zeig es auf einen auf dem Loopback, und du bekommst eine.\nStaleRetentionSec= ist die interessante Einstellung, und sie ist standardmäßig aus. Setz sie, und wenn der Vorgelagerte nicht mehr antwortet, liefert resolved Einträge über ihre TTL hinaus weiter aus, statt zu scheitern.2 Es versucht immer zuerst den Vorgelagerten. Es gilt nicht für NXDOMAIN, denn dass ein Name nicht existiert, ist eine völlig gültige Antwort, und daran ist nichts veraltet. Für einen Laptop, der in die Funkabdeckung hinein und wieder heraus fährt, oder eine Maschine, die durch einen DNS-Ausfall hindurch weiterarbeiten muss, ist das etwas wert:\n[Resolve] StaleRetentionSec=1d systemd 261 hat darauf aufbauend eine Cache-Dimensionierung pro Protokoll ergänzt, mit DNSCacheSize=, MulticastDNSCacheSize= und LLMNRCacheSize=, jeweils mit 4096 Einträgen voreingestellt und bei 2^24 gedeckelt.3 Nicht auf dieser Kiste, die 259 fährt, und auf keinem aktuellen stabilen Distributionsrelease. Wert zu wissen, dass es kommt, denn bis jetzt war die Cache-Größe überhaupt nicht einstellbar.\nDer Daemon leert außerdem alles bei Speicherdruck, was sinnvoll ist und gelegentlich überrascht, wenn du herauszufinden versuchst, warum eine Cache-Trefferquote mau aussieht.\nSplit DNS ist der Grund, es zu behalten Wenn du eine Sache hieraus mitnimmst, nimm diesen Abschnitt, denn das ist die Funktion, die wirklich etwas tut, das der alte Stub-Resolver nicht konnte.\nDie traditionelle resolv.conf hat eine Liste von Nameservern für die ganze Maschine. Eine Liste. Fahr ein VPN hoch, und irgendetwas muss sie überschreiben, was heißt: entweder funktionieren deine internen Namen und der Rest des DNS geht über den Firmen-Resolver, oder umgekehrt. Eine dritte Möglichkeit gibt es nicht. Die Datei kann sie nicht ausdrücken.\nresolved routet pro Abfrage, pro Interface.1 Jeder Link hat seine eigenen Server und seine eigenen Domänen, und eine Abfrage geht an den Link, dessen Domäne am besten zum Namen passt, nach Anzahl der Labels.\nKonfiguration Geschrieben als Wirkung Suchdomäne damiendye.uk Suffix für Namen mit einem Label, und routet passende Abfragen auf diesen Link Nur-Routing-Domäne ~internal.example Routet passende Abfragen auf diesen Link, nie als Suffix benutzt Auffangroute ~. Schickt alles, was nirgendwo sonst passt, auf diesen Link Standardroute DNSDefaultRoute=yes Nimmt Abfragen ohne Treffer, ohne ~. zu beanspruchen Ein Laptop mit hochgefahrenem Arbeits-VPN bekommt also das hier:\nresolvectl domain tun0 \u0026#39;~corp.example\u0026#39; \u0026#39;~10.in-addr.arpa\u0026#39; resolvectl dns tun0 10.0.0.53 Namen unter corp.example und Reverse-Lookups für 10.0.0.0/8 gehen durch den Tunnel. Alles andere geht weiter über den lokalen Link hinaus wie vorher. Niemandes resolv.conf wurde umgeschrieben, und wenn der Tunnel abfällt, gehen die Routen mit ihm.\nEine Abfrage, zwei Links, und eine Routing-Entscheidung nach Anzahl der Labels DIE ABFRAGE DIE ENTSCHEIDUNG DER LINK db01.corp.example 14.0.10.in-addr.arpa blogs.damiendye.uk Die meisten Labels gewinnen Jeder Link hat eigene Server und Domänen. tun0 ~corp.example wlp4s0 DefaultRoute Eine Tilde routet nur. Ohne Tilde dient sie auch als Suffix für Namen mit einem Label. Eine Abfrage, zwei Links, und eine Routing-Entscheidung nach Anzahl der Labels Eine Regel ist es wert, klar gesagt zu werden, denn sie ist die, nach der Leute greifen und die sie falsch verstehen. ~. auf einem Link heißt bevorzuge diesen Link für alles. Es hindert außerdem implizit jeden anderen Link daran, Standardroute zu sein. Du willst, dass ein Link die Reste nimmt, ohne den ganzen Namensraum zu beanspruchen? Setz DNSDefaultRoute=yes und lass ~. in Ruhe.\nPrüf, was es entschieden hat, statt es anzunehmen:\n$ resolvectl status Link 3 (wlp4s0) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 192.0.2.53 DNS Servers: 192.0.2.53 2001:db8:1::53 DNS Domain: damiendye.uk Default Route: yes Jede Adresse in diesem Beitrag stammt aus den Dokumentationsbereichen, 192.0.2.0/24 und 2001:db8::/32, also kopier sie nicht in eine Konfiguration und erwarte eine Antwort.4 5 Die Zahlen und das Verhalten sind echt, von einer laufenden Maschine. Die Adressen sind Platzhalter, denn eine globale IPv6-Adresse, die auf die übliche Art gebildet wird, trägt die MAC des Interfaces in ihrer unteren Hälfte, und eine zu veröffentlichen gibt ein Stück Hardware-Inventar mit heraus.\nDieses -DNSOverTLS und dieses DNSSEC=no sind die nächsten beiden Abschnitte.\nEs kann DNSSEC validieren Der Daemon wird von Upstream als „a caching and validating DNS/DNSSEC stub resolver“ beschrieben.1 Die validierende Hälfte ist echt, sie ist kein Wrapper um etwas anderes, und sie funktioniert. Sie ist nur nicht angeschaltet.\nSie pro Link anzuschalten braucht kein sudo, denn resolvectl geht über polkit, und eine aktive lokale Sitzung darf das:\n$ resolvectl dnssec wlp4s0 yes $ resolvectl status wlp4s0 | grep DNSSEC DNSSEC=yes/supported Dieses Suffix /supported ist resolved, das meldet, was es beim Abtasten des Vorgelagerten gefunden hat, getrennt davon, was du verlangt hast. yes/supported heißt, du hast Validierung verlangt und der Server kann sie tragen. no/unsupported auf einer Standardinstallation heißt, niemand hat gefragt, also hat niemand abgetastet.\nSobald sie an ist, kommt jede Abfrage mit einem Urteil zurück, und davon gibt es drei.\nSecure, insecure und bogus sind drei verschiedene Antworten VERÖFFENTLICHT DER ELTERNTEIL EIN DS, UND VERIFIZIEREN DIE SIGNATUREN? SECURE damiendye.uk Signiert, und die Kette stimmt. Daten geliefert. INSECURE systemd.io Kein DS. Nicht signiert, also nichts zu prüfen. Daten geliefert. BOGUS dnssec-failed.org Behauptet, signiert zu sein. Der Beweis scheitert. Abfrage verworfen. Zwei der drei liefern Daten. Validierung anzuschalten hindert unsignierte Sites nicht am Funktionieren. Secure, insecure und bogus sind drei verschiedene Antworten, und nur eine davon ist ein Fehlschlag Hier sind alle drei auf dieser Maschine, gegen echte Namen:\n$ resolvectl query damiendye.uk -- Data is authenticated: yes; Data was acquired via local or encrypted transport: no $ resolvectl query systemd.io -- Data is authenticated: no; Data was acquired via local or encrypted transport: no $ resolvectl query dnssec-failed.org dnssec-failed.org: resolve call failed: DNSSEC validation failed: missing-key (DNSKEY Missing: no SEP matching the DS found for dnssec-failed.org.) damiendye.uk ist signiert, also validiert die Kette von der Root aus und die Daten sind beglaubigt. systemd.io ist nicht signiert, also gibt es nichts zu prüfen, und resolved sagt das ehrlich, statt so zu tun. Das ist die eigene Domäne des systemd-Projekts, ein Punkt, auf den ich zurückkomme. dnssec-failed.org wird mit absichtlich kaputten Signaturen veröffentlicht. Die scheitert hart, mit einer Diagnose, die das genaue Problem benennt.\nHier ist die Unterscheidung, die verloren geht. Insecure ist kein Fehlschlag. Eine unsignierte Zone liefert Daten zurück und sagt dir, dass sie nicht verifiziert werden konnten. Nur eine Zone, die behauptet, signiert zu sein, und es dann nicht beweisen kann, wird verworfen.\nDie Kette selbst ist sichtbar, wenn du sie sehen willst:\n$ dig +short @127.0.0.53 uk DS 43876 8 2 A107ED2AC1BD14D924173BC7E827A1... $ dig +short @127.0.0.53 damiendye.uk DS 2371 13 2 A5B2825C57899A5A15EE9703832C8358E0D19EF29DC72DD83C691ED77C33BD7F $ dig +short @127.0.0.53 damiendye.uk DNSKEY 256 3 13 oJMRESz5E4gYzS/q6XDrvU1qMPYIjCWz... 257 3 13 mdsswUyr3DPW132mOi8V9xESWE8jTo0d... Die Root bürgt für uk, uk bürgt für damiendye.uk, und der 257-Schlüssel signiert den 256-Schlüssel, der die Einträge signiert. Algorithmus 13 dort ist ECDSA P-256, was du auf einer neuen Zone haben willst statt des RSA, das das uk-DS oben noch benutzt.\nÜber den einfachen Stub bekommt ein Programm, das nie von resolved gehört hat, dasselbe Urteil als AD-Flag:\n$ dig @127.0.0.53 ietf.org A | grep flags ;; flags: qr rd ra ad; $ dig @127.0.0.53 dnssec-failed.org A | grep status ;; -\u0026gt;\u0026gt;HEADER\u0026lt;\u0026lt;- status: SERVFAIL Und der Daemon führt eine laufende Strichliste, was der schnellste Weg ist, zu sehen, ob die Validierung überhaupt etwas tut:\n$ resolvectl statistics DNSSEC Verdicts Secure: 134 Insecure: 62 Bogus: 0 Indeterminate: 2 Was Validierung kostet Hier werde ich dich enttäuschen, denn ich habe versucht, das ordentlich zu messen, und konnte es nicht.\nWarm ist es sauber und es ist nichts. Dieselben 32 Namen gegen einen vollen Cache kosteten 16 ms ohne Validierung und 23 ms mit ihr. Nenn es einen Rundungsfehler.\nKalt ist da, wo die Kosten sich zeigen sollten, und ein einzelner Client kann sie nicht isolieren. Ich habe den Durchlauf in beide Richtungen gefahren und widersprüchliche Antworten bekommen: bei der einen Reihenfolge sah Validierung 74 % langsamer aus, bei der anderen sah sie schneller aus, was unmöglich ist und dir sagt, was hier wirklich gemessen wird. Welcher Durchlauf auch immer als zweiter fährt, profitiert davon, dass der vorgelagerte Resolver bereits alles geholt hat, wonach der erste gefragt hat. Die dominierende Variable ist nicht die Validierung, sondern wessen Cache warm war.\nIch gebe dir also keine Zahl, hinter der ich nicht stehen kann. Wahr ist der Mechanismus, und die Dokumentation sagt seine Form klar: Validierung „requires retrieval of additional DNS data, and thus results in a small DNS lookup time penalty“.2 Eine kalte validierte Abfrage läuft die Delegierungskette ab und holt auf jeder Ebene DS und DNSKEY, bevor sie antworten kann, also kostet sie zusätzliche Roundtrips auf Namen, nach denen noch niemand gefragt hat, und gar nichts auf Namen, nach denen irgendwer gefragt hat.\nWas auch der Grund ist, warum dieselbe Seite warnt, dass den Cache abzuschalten „comes at a performance penalty, which is particularly high when DNSSEC is used“.2 Die zwei Funktionen sind nicht unabhängig. Validierung ist genau deshalb erschwinglich, weil der Cache heißt, dass du einmal dafür zahlst.\nWenn du die echte Zahl für dein eigenes Netz willst, miss sie dort. Ein Client auf einer Leitung kann sie dir nicht sagen.\nWarum ist Validierung also abgeschaltet Weil deine Distribution sie beim Bauen des Pakets abgeschaltet hat, und das aus einem Grund tat, den sie aufgeschrieben hat.\nUpstream-systemd liefert Validierung an aus. Die Build-Option sagt es:\noption(\u0026#39;default-dnssec\u0026#39;, type : \u0026#39;combo\u0026#39;, choices : [\u0026#39;yes\u0026#39;, \u0026#39;allow-downgrade\u0026#39;, \u0026#39;no\u0026#39;], value : \u0026#39;allow-downgrade\u0026#39;) und das Upstream-Handbuch stimmt zu: DNSSEC= „Defaults to allow-downgrade“.6\nJetzt schau, was Fedora diesem Build übergibt:7\n-Ddefault-dnssec=no -Ddefault-dns-over-tls=no -Ddefault-mdns=no -Ddefault-llmnr=resolve Und was Debian und Ubuntu übergeben:8\n-Ddefault-dnssec=no -Ddefault-llmnr=no -Ddefault-mdns=no -Ddns-over-tls=openssl Die Datei unter /usr/lib/systemd/resolved.conf auf einer Fedora-Kiste, die mit „Entries in this file show the compile time defaults“ überschrieben ist, liest sich also #DNSSEC=no. Lies das noch einmal, denn es tut etwas Verschlagenes: die Zeile sieht aus, als sagte die Software dir ihre eigene Voreinstellung, und was sie dir tatsächlich zurückspiegelt, ist Fedoras Build-Flag, während Upstreams echte Voreinstellung nirgends auf der Seite steht.\nEinstellung Upstream-Voreinstellung Fedora-Build Debian/Ubuntu-Build Ergebnis auf dieser Kiste DNSSEC= allow-downgrade no no DNSSEC=no DNSOverTLS= no no no (mit OpenSSL kompiliert) -DNSOverTLS MulticastDNS= yes no no -mDNS LLMNR= yes resolve no LLMNR=resolve Jede einzelne davon passt zu dem, was resolvectl status auf dieser Maschine ausgibt. Quelltext, Build-Flag, laufendes System, alle drei stimmen überein.\nFedoras Begründung steht im Change Proposal und ist erfrischend unverblümt. Die Funktion „is known to cause compatibility problems with certain network access points“, und Fedora „is not prepared to handle an influx of DNSSEC-related bug reports“, also geht sie aus.9\nDarf ich fragen, warum die Antwort auf eine Funktion, die in schlechten Netzen bricht, ist, sie für alle abzuschalten, statt allow-downgrade auszuliefern, wie Upstream es tut, und sie sich dort selbst abschalten zu lassen, wo sie muss? Nicht wer entschieden hat. Was im Prozess dorthin geführt hat. Denn allow-downgrade existiert genau für den Fall des Captive Portals, es ist aus genau diesem Grund Upstreams Voreinstellung, und stattdessen no auszuliefern heißt, dass eine Maschine in einem völlig guten Netz ebenfalls keine Validierung bekommt.\nFairerweise: allow-downgrade hat sein eigenes Problem, und es ist ein echtes. Der Modus erkennt einen Resolver, der kein DNSSEC kann, und hört leise auf zu validieren. Ein Angreifer, der deine DNS-Antworten formen kann, kann diese Erkennung absichtlich auslösen, und die Dokumentation sagt es klar: er „makes DNSSEC validation vulnerable to \u0026lsquo;downgrade\u0026rsquo; attacks“.2 Eine Sicherheitsfunktion, die jeder Angreifer abschalten kann, tut weniger, als sie aussieht.\nAlso ist keine der beiden Voreinstellungen gut. no gibt dir nichts. allow-downgrade gibt dir etwas, das ein Angreifer dir wegnehmen kann, und yes gibt dir das echte Ding plus alles im nächsten Abschnitt.\nWie viel des Webs ist überhaupt signiert Bevor man viel Mühe in Validierung steckt, lohnt es sich zu wissen, welchen Anteil deiner Abfragen sie überhaupt schützen kann. Also habe ich resolved nach dem Urteil über den Apex von zweiunddreißig Domänen gefragt, die dieses Thema tatsächlich betreffen: die Gremien, die den Standard geschrieben haben, die Läden, die den Resolver ausliefern, und die Infrastruktur, die jeder auflöst, ob er will oder nicht.\nSechzehn von zweiunddreißig. Die Hälfte.\nSigniert Unsigniert Standards und Registries ietf.org, iana.org, icann.org, rfc-editor.org, ripe.net, isc.org, nlnetlabs.nl, nic.cz, afnic.fr, verisign.com keine Distributionen und Hersteller debian.org, fedoraproject.org, opensuse.org, almalinux.org redhat.com, ubuntu.com, canonical.com, suse.com, rockylinux.org, archlinux.org systemd selbst keine systemd.io, freedesktop.org Infrastruktur cloudflare.com, gov.uk github.com, kernel.org, google.com, wikipedia.org, mozilla.org, apache.org, gnu.org, quad9.net Lies die erste Spalte hinunter. Jedes einzelne Standardisierungsgremium und jede Registry hat signiert. Zehn von zehn, ohne Ausnahme: die Leute, die DNSSEC geschrieben haben, und die Leute, die die Registries betreiben, die die DS-Einträge für alle anderen veröffentlichen. Sie haben die Arbeit an ihren eigenen Zonen gemacht.\nJetzt lies die dritte Zeile quer. systemd.io hat kein DS. Das Projekt, das den validierenden Resolver geschrieben hat, um den es in diesem ganzen Beitrag geht, hat seine eigene Domäne nicht signiert, und freedesktop.org, wo seine Dokumentation liegt, auch nicht. Darunter ist quad9.net ebenfalls unsigniert, was einen Moment verdient: ein öffentlicher Resolver, dessen ganzes Verkaufsargument ist, dass er DNSSEC für dich validiert, auf einer Zone, die niemand validieren kann.\nUnd die Hersteller teilen sich sauber entlang einer Linie. Die Community-Distributionen haben signiert. debian.org, fedoraproject.org, opensuse.org, almalinux.org. Die Firmen nicht. redhat.com, ubuntu.com, canonical.com, suse.com. Das sind die vier Organisationen, die diesen Resolver für den größten Teil des Linux-Bestands paketieren und ausliefern.\nAn der Technik liegt es nicht. Das Protokoll ist seit über fünfzehn Jahren einsetzbar, die Werkzeuge sind kostenlos, und die Registries nehmen den DS-Eintrag entgegen, ohne dafür zu kassieren. Ich sag dir das umsonst: die Leute, die den Standard geschrieben haben, haben signiert, und die meisten Leute, die die Software ausliefern, nicht.\nEs gibt eine schärfere Fassung desselben Punktes in gov.uk, das signiert ist und dann das hier tut:\n$ dig +short @127.0.0.53 www.gov.uk CNAME www-cdn.production.govuk.service.gov.uk. $ dig +short @127.0.0.53 service.gov.uk DS (nothing) uk hat ein DS. gov.uk hat ein DS. service.gov.uk hat keines, also endet die Kette dort abrupt, und www.gov.uk löst insecure auf, obwohl der Apex darüber ordentlich signiert ist. Jemand hat die Arbeit an gov.uk gemacht und dann die eigentliche Website auf eine unsignierte Delegierung gezeigt. Halbe Arbeit.\nWenn du also eine Zone signierst, prüf die Namen, die Leute tatsächlich tippen. Ein signierter Apex, der per CNAME in eine unsignierte CDN-Zone zeigt, bringt dir nichts.\nDNS over TLS funktioniert, mit Bedingungen DNS over TLS ist implementiert, es ist in jeden verbreiteten Build einkompiliert, und es funktioniert. Es ist überall standardmäßig aus, auch bei Upstream, wo DNSOverTLS= „Defaults to no“.6\nDie Konfiguration sind zwei Zeilen, und die zweite ist die, die Leute übersehen:\n[Resolve] DNS=9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net DNSOverTLS=yes Dieses #dns.quad9.net ist keine Verzierung. Es setzt den Namen, der für SNI und für die Prüfung des Zertifikats benutzt wird. Lass ihn weg, und das Zertifikat wird stattdessen „checked against the server\u0026rsquo;s IP“.2 Das funktioniert bei den großen Anbietern, weil die IP-Adressen in die SANs ihrer Zertifikate schreiben, aber es ist die schwächere Prüfung, sie bricht in dem Moment, in dem ein Anbieter damit aufhört, und sie schützt dich nicht davor, auf eine andere Adresse umgeleitet zu werden, die zufällig ein gültiges Zertifikat für sich selbst hält. Fedoras eigener Magazin-Artikel dazu lässt den Hostnamen weg,10 was schade ist, denn die Syntax steht direkt in den Kommentaren der ausgelieferten Konfigurationsdatei.\nStrikt und opportunistisch sind sehr verschiedene Einstellungen Modus Auf einem Server, der DoT kann Auf einem Server, der es nicht kann Authentifiziert den Server yes Verschlüsselt Alle Abfragen scheitern Ja opportunistic Verschlüsselt Stillschweigend im Klartext Nein no Klartext Klartext entfällt opportunistic liest sich wie der vernünftige Mittelweg und ist es meistens nicht. Die Dokumentation sagt es geradeheraus: in diesem Modus „the resolver is not capable of authenticating the server, so it is vulnerable to \u0026lsquo;man-in-the-middle\u0026rsquo; attacks“,2 und jeder, der deinen Verkehr auf Port 853 verwerfen kann, kann das Downgrade erzwingen. Es schützt dich vor passiver Beobachtung in einem Netz, in dem niemand es versucht. Gegen jemanden, der es versucht, tut es nichts.\nyes ist die ehrliche Einstellung. Sie heißt auch, dass du, wenn es keine Verbindung bekommt, gar kein DNS bekommst, was es wert ist zu wissen, bevor du sie auf eine Maschine setzt, zu der du nicht hinlaufen kannst.\nIch habe striktes DoT zu Quad9 von dieser Kiste aus versucht, und die Abfrage hing. Kein Fehler, kein Timeout, nichts im Journal zwischen dem Leeren und meinem Zurücknehmen zwei Minuten später:\nSep 27 17:12:11 systemd-resolved[40105]: wlp4s0: Bus client set DNS server list to: 9.9.9.9#dns.quad9.net, ... Sep 27 17:12:14 systemd-resolved[40105]: wlp4s0: Bus client set DNSOverTLS setting: yes Sep 27 17:12:15 systemd-resolved[40105]: Flushed all caches. Sep 27 17:14:39 systemd-resolved[40105]: wlp4s0: Bus client set DNS server list to: 192.0.2.53, ... Ich kann dir von hier aus nicht sagen, ob Port 853 auf dieser Leitung erreichbar ist, denn die Shell, aus der ich den Test gefahren habe, erreichte auch Port 443 nicht und war offensichtlich selbst gefiltert. Was das Log zeigt, ist der Fehlermodus: striktes DoT, das keine Verbindung bekommt, meldet nichts Nützliches. Es wartet. Wenn du das anschaltest und dein DNS verstummt, prüf ss -tn dport = :853, bevor du bei resolved zu suchen anfängst.\nEs ordentlich testen # does the transport actually come up resolvectl flush-caches resolvectl query ietf.org # expect: acquired via ... encrypted transport: yes # is anything still going out in the clear sudo tcpdump -ni any \u0026#39;port 53 and not host 127.0.0.53\u0026#39; Der zweite Befehl ist der, der die Wahrheit sagt. Mit funktionierendem DoT sollte nichts die Maschine auf Port 53 verlassen, und alles, was es doch tut, ist ein Programm, das einen Weg um den Stub herum gefunden hat.\nDNS over HTTPS existiert hier nicht Klare Antwort auf die Frage: systemd-resolved unterstützt kein DNS over HTTPS. Nicht teilweise, nicht hinter einem Flag, nicht mit einer Build-Option, die niemand anschaltet. Es ist überhaupt kein DoH darin.\nUnd das ist nicht aus der Dokumentation abgelesen, die schlicht veraltet sein könnte. Es ist, was die Binary enthält:\n$ strings /usr/lib/systemd/systemd-resolved | grep -icE \u0026#39;application/dns-message|dns-query|:443\u0026#39; 0 $ grep -oE \u0026#39;name=\u0026#34;DNSOver[A-Za-z]*\u0026#34;\u0026#39; /usr/share/dbus-1/interfaces/org.freedesktop.resolve1.Manager.xml name=\u0026#34;DNSOverTLS\u0026#34; Kein DoH-Wire-Format, kein HTTP/2, eine Verschlüsselungs-Eigenschaft auf dem D-Bus-Interface, und die ist TLS. Die vollständige Liste der resolved.conf-Direktiven bei Upstream umfasst siebzehn Einstellungen, und keine davon erwähnt HTTPS.6\nEs ist gefordert worden. Issue #8639, „Add support for DNS-over-HTTPS to systemd-resolved“, wurde am 2. April 2018 eröffnet und ist immer noch offen, mit zwei angehängten Pull Requests und nichts gemergt.11 Acht Jahre und es läuft weiter.\nDieselbe Nutzlast, dieselbe Verschlüsselung, anderer Port BEIDE TRAGEN DIESELBE DNS-ABFRAGE, IN DERSELBEN TLS DNS over TLS DNS over HTTPS tcp/853 tcp/443 In systemd-resolved ja, seit v239 nein, gar nicht Ein Beobachter sieht die Namen nein nein Ein Netz kann es blockieren ja, eigener Port nicht ohne Mühe Du kannst dein eigenes prüfen ja nein Gefordert in systemd-Issue 8639, April 2018. Immer noch offen. Dieselbe Nutzlast, dieselbe Verschlüsselung. Der Unterschied ist, auf welchem Port sie liegt, und wer es erkennen kann Ist das die falsche Entscheidung? Nicht offensichtlich, und das Argument für DoT ist ordentlich. Beide tragen DNS innerhalb von TLS, und beide stoppen denselben passiven Beobachter. DoHs Vorteil ist, dass es sich mit allem anderen auf Port 443 versteckt, sodass ein Netz, das verschlüsseltes DNS blockieren will, sehr viel härter arbeiten muss. Das ist wirklich nützlich, wenn der Netzbetreiber der Gegner ist.\nEs schneidet auch in die andere Richtung. Wo der Betreiber du bist, heißt diese Ununterscheidbarkeit, dass du auch dein eigenes DNS nicht prüfen kannst, und jede Anwendung, die ihren eigenen DoH-Client mitbringt, hört auf, den Systemresolver zu benutzen, was der Weg ist, auf dem du einen Browser bekommst, der dein Split DNS, deinen Cache und deine internen Zonen ignoriert. Auf deiner eigenen Ausrüstung ist ein Resolver, der auf einem bekannten Port sichtbar ist, eine Funktion.\nAlso: wenn DoT deinen Resolver erreicht, benutz es und du verlierst nichts. Wenn Port 853 blockiert ist, hat resolved keine Antwort, und du willst einen DoH-Proxy davor, dnscrypt-proxy oder cloudflared auf dem Loopback mit resolved darauf gezeigt. Caching und Validierung bleiben resolveds Aufgabe. Nur der Transport zieht um.\nWas deine Distribution tatsächlich ausliefert Derselbe Daemon verhält sich sehr unterschiedlich, je nachdem, wer ihn paketiert hat. Den Dienst zu aktivieren ist die leichte Hälfte. Die Hälfte, die übersprungen wird, ist, ihn in die Netzwerkwerkzeuge einzustöpseln, die die Distribution tatsächlich benutzt, und auf einer dieser vier ist er wirklich nicht eingestöpselt, bis du es selbst tust.\nInstalliert Aktiviert nss-resolve eingehängt Konfiguration kommt über Unterstützt Fedora (33+) ja ja ja, in systemd-libs NetworkManager ja Ubuntu ja ja ja netplan, dann NM oder networkd ja Debian (12+) eigenes Paket nein nein, eigenes Paket du wählst und hängst es ein ja RHEL / Rocky / Alma (9, 10) ja nein ja NetworkManager, einmal gesagt Technology Preview Validierung und ein voller Cache: die Einstellungen selbst Das sind überall dieselben vier Zeilen, denn resolved.conf ist auf jeder Distribution resolved.conf. Was sich unterscheidet, ist nur, wie der Rest der Konfiguration den Daemon erreicht, und das sind die nächsten vier Abschnitte.\n# /etc/systemd/resolved.conf.d/60-local.conf [Resolve] DNSSEC=allow-downgrade Cache=yes CacheFromLocalhost=no StaleRetentionSec=1d Benutz ein Drop-in, statt /etc/systemd/resolved.conf zu editieren, denn die Hauptdatei hat niedrigere Priorität als jedes Drop-in, und ein Paketupdate kann sich mit dir darüber streiten. Die Nummerierung ist eine dokumentierte Konvention: Hersteller nehmen 10 bis 40 unter /usr/, du nimmst 60 bis 90 unter /etc/, damit deines gewinnt.6\nAuf systemd 261 und neuer gibt es eine fünfte Zeile, die es wert ist, ergänzt zu werden, denn bis dahin war die Cache-Größe überhaupt nicht einstellbar:\nDNSCacheSize=16384 # systemd 261+; default 4096, max 2^24 Wende es an und bestätige, dass der Daemon mit der Datei übereinstimmt, statt anzunehmen, dass er sie gelesen hat:\nsystemd-analyze cat-config systemd/resolved.conf # every fragment, in precedence order systemctl restart systemd-resolved resolvectl status | grep -E \u0026#39;DNSSEC|Protocols\u0026#39; resolvectl statistics # verdicts should start moving DNSSEC=allow-downgrade ist die Einstellung, die ich auf eine Maschine setzen würde, die ich nicht bewachen werde, aus den Gründen im Abschnitt oben. DNSSEC=yes ist die ehrliche, und sie scheitert geschlossen. Wähl bewusst.\nEs in den Netzwerkstapel einstöpseln Den Dienst anzuschalten ist ein Befehl. Die eigenen Netzwerkwerkzeuge deiner Distribution dazu zu bringen, ihm ihre DNS-Konfiguration zu übergeben, ist der Teil, der variiert, und es ist der Punkt, an dem „aktiviert“ und „funktioniert richtig“ auseinandergehen.\nWoher die DNS-Konfiguration kommt DNSSEC anschalten Cache dimensionieren Zusätzliche Verdrahtung nötig Fedora NetworkManager, automatisch Drop-in Drop-in keine Ubuntu netplan, dann NM oder networkd Drop-in, oder pro Link in .network Drop-in keine Debian der Stapel, den du gewählt hast Drop-in, oder pro Link in .network Drop-in libnss-resolve, plus der Stapel unten RHEL-Familie NetworkManager, einmal gesagt Drop-in Drop-in dns=systemd-resolved Fedora Die vollständigste Integration der vier, und die einzige, bei der schon alles eingestöpselt ist.\nNetworkManager besitzt das Netz und übergibt DNS an resolved, ohne dass man es ihm sagen muss. Auf dieser Kiste gibt es nirgends in /etc/NetworkManager/ eine dns=-Zeile, und es funktioniert trotzdem, weil NetworkManager den laufenden Daemon erkennt und ihn benutzt. /etc/resolv.conf ist der Stub-Symlink, und glibc ist eingehängt, weil libnss_resolve.so.2 in systemd-libs mitkommt, was nicht optional ist:\n$ rpm -qf /usr/lib64/libnss_resolve.so.2 systemd-libs-259.9-1.fc44.x86_64 $ grep ^hosts: /etc/nsswitch.conf hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns Auf Fedora ist das Drop-in oben also die ganze Arbeit. Sonst nichts zu verbinden.\nUbuntu Standardmäßig aktiviert, und nss-resolve ist auf dieselbe Art eingehängt. Der Unterschied ist, dass die Konfiguration meist über netplan ankommt:\nnetwork: version: 2 ethernets: enp1s0: dhcp4: true nameservers: addresses: [9.9.9.9, 149.112.112.112] search: [example.com] Netplan übergibt das an seinen Renderer, NetworkManager auf dem Desktop oder systemd-networkd auf dem Server, und der Renderer übergibt es an resolved. Beachte, was netplan nicht ausdrücken kann. Es gibt keinen netplan-Schlüssel für DNSSEC= und keinen für DNSOverTLS=. Die gehören in das Drop-in oben, wo sie ohnehin hingehören.\nWenn du auf systemd-networkd bist, sind die Einstellungen pro Link auch nativ in der .network-Datei verfügbar, und eine Einstellung pro Link schlägt die globale:\n# /etc/systemd/network/10-lan.network [Network] DNS=9.9.9.9#dns.quad9.net DNSSEC=yes DNSOverTLS=yes Domains=~. Debian muss von Hand eingehängt werden Das ist die eine, die wirklich nicht eingestöpselt ist, und der Grund, warum der Abschnitt oben existiert.\nSeit Debian 12 ist systemd-resolved ein eigenes Paket, und die Release Notes sind über das Upgrade ausdrücklich: „The new systemd-resolved package will not be installed automatically on upgrades“ und „until it has been installed, DNS resolution might no longer work since the service will not be present on the system.“12 Dieselben Notes klären die größere Frage: „systemd-resolved was not, and still is not, the default DNS resolver in Debian.“\nEs zu installieren sind drei Pakete, nicht eines, und das zweite ist das, das jeder übersieht:\napt install systemd-resolved libnss-resolve systemctl enable --now systemd-resolved libnss-resolve steht nur unter Suggests:, ist keine Abhängigkeit,13 und Suggests ist die eine Beziehung, auf die apt nicht reagiert. Also installiert es niemand.\nDer Grund, warum es niemandem auffällt, ist interessanter als der Grund, warum es niemand installiert. Lass es weg, und glibc erreicht resolved trotzdem, weil /etc/resolv.conf auf den Stub zeigt und das einfache nss-dns mit ihm spricht. Der größte Teil des Daemons funktioniert weiter:\nOhne libnss-resolve Mit ihm Cache Ja, über den Stub Ja DNSSEC-Validierung Ja, sie passiert im Daemon Ja DNS over TLS Ja Ja AD-Bit erreicht glibc Ja, resolv.conf trägt trust-ad Ja Secure gegen insecure gegen bogus Nein, nur ein Bit Ja Link-bezogene Adressen Nein Ja /etc/hosts vom Daemon gelesen Nein Ja Nichts in der linken Spalte sieht kaputt aus, also wird nichts repariert. Was du verlierst, ist das, was das DNS-Wire-Format nicht tragen kann, und der klarste Fall ist eine Adresse mit einem Scope daran:\n$ getent hosts _gateway # via nss-resolve fe80::5054:ff:fe12:3456 _gateway $ dig +short @127.0.0.53 _gateway # via the stub, as nss-dns would 192.0.2.1 Derselbe Name, derselbe Daemon, zwei verschiedene Antworten. Eine link-lokale IPv6-Adresse ist ohne das Interface, auf das sie bezogen ist, bedeutungslos, und in einer DNS-Antwort gibt es nirgends einen Platz dafür, also kann der Stub nur die IPv4 zurückgeben. Die native API hat einen Platz dafür und gibt dir die Adresse, die du tatsächlich wolltest.\nDie Urteilszeile ist dasselbe Problem. AD ist ein Bit, signiert oder nicht. Die native API trennt secure von insecure von bogus, was der Unterschied ist zwischen „das hat niemand signiert“ und „das hat jemand signiert, und jemand anderes war dran“. Eine Anwendung, die das interessiert, kann die beiden über die Leitung nicht auseinanderhalten.\nDas ist die Lücke zwischen dem Dienst, der läuft, und dem Dienst, der eingestöpselt ist, und sie bleibt unsichtbar, bis du danach suchst.\nPrüf, dass es angekommen ist:\ngrep ^hosts: /etc/nsswitch.conf # wants \u0026#39;resolve [!UNAVAIL=return] dns\u0026#39; Vier Wege hinein auf Debian, und der eine, der nicht für dich installiert wird WOHER DIE KONFIG KOMMT WIE SIE HINEINKOMMT DER DAEMON ifupdown, statisch ifupdown, DHCP systemd-networkd NetworkManager resolvconf-Shim = resolvectl resolved 127.0.0.53 UND DAS TEIL, DAS NIEMAND INSTALLIERT glibc getaddrinfo() libnss-resolve Nur Suggests:. Ohne es funktioniert glibc weiter, und das Urteil erreicht es nie. Vier Wege hinein auf Debian, und der eine, der nicht für dich installiert wird Wie der Rest deines Netzwerks ihn erreicht, hängt davon ab, auf welchem von Debians Stapeln du bist.\nDas Paket deklariert Provides: resolvconf und Conflicts: resolvconf, openresolv,13 übernimmt also die resolvconf-Schnittstelle vollständig. /usr/sbin/resolvconf wird ein Symlink auf resolvectl, das eine Multi-Call-Binary ist: unter diesem Namen aufgerufen spricht es das resolvconf(8)-Protokoll und schiebt alles, was ihm übergeben wird, direkt in resolved.14 Alles, was bereits resolvconf -a aufruft, funktioniert daher unverändert weiter, mit systemd-resolved als einzigem unterstütztem Backend.\nNicht die ganze Schnittstelle überlebt, und die Lücken scheitern laut statt leise:\nresolvconf-Option Unter systemd-resolved -a \u0026lt;iface\u0026gt; Registriert DNS pro Link, von stdin gelesen. Die, auf die es ankommt -d \u0026lt;iface\u0026gt; Meldet ab, dasselbe wie resolvectl revert -x Auf eine ~.-Routing-Domäne abgebildet -p Markiert den Link als keine Standardroute (systemd 257+) -f Sorgt dafür, dass -a und -d über ein nicht vorhandenes Interface schweigen -m Angenommen und stillschweigend ignoriert -u, -i, -I, -l, -r, -R, -v, -V Nicht unterstützt. Der Befehl scheitert Eine Falle ist es wert, bekannt zu sein, bevor du sie debuggst: der Shim schreibt /etc/resolv.conf nur dann, wenn diese Datei ein Symlink auf /run/systemd/resolve/resolv.conf ist, und nicht, wenn sie eine statische Datei ist.14\nifupdown, die Voreinstellung bei einer Debian-Serverinstallation. Die dns-nameservers-Anweisung in /etc/network/interfaces wurde immer von den Hooks des alten resolvconf-Pakets umgesetzt, und systemd-resolved steht mit diesem Paket im Konflikt und liefert keine eigenen /etc/network/if-up.d/-Hooks. Verlass dich bei einem statischen Interface nicht auf die Anweisung. Setz die Server ausdrücklich auf dem Link und lass resolved sie besitzen:\n# /etc/network/interfaces auto enp1s0 iface enp1s0 inet static address 192.0.2.10/24 gateway 192.0.2.1 up /usr/sbin/resolvconf -a $IFACE \u0026lt;\u0026lt;\u0026lt; \u0026#39;nameserver 192.0.2.53\u0026#39; down /usr/sbin/resolvconf -d $IFACE DHCP auf ifupdown ist bereits erledigt. isc-dhcp-client liefert Hooks, die nach dem Daemon benannt sind, /etc/dhcp/dhclient-enter-hooks.d/resolved-enter und /etc/dhcp/dhclient-exit-hooks.d/resolved,15 sodass die DNS-Server eines Lease ohne jede Konfiguration auf dem richtigen Link landen.\nsystemd-networkd ist die sauberste Option und braucht gar keinen Shim, denn die beiden Hälften sind dasselbe Projekt. DNS, DNSSEC und DoT pro Link sind native Schlüssel in der .network-Datei, genau wie im Ubuntu-Beispiel oben.\nNetworkManager, auf einem Debian-Desktop, muss es einmal gesagt bekommen:\n# /etc/NetworkManager/conf.d/10-resolved.conf [main] dns=systemd-resolved Wähl einen und wisse, welchen du gewählt hast. Der Fehlermodus hier ist kein Daemon, der den Start verweigert, es sind zwei Stapel, die beide glauben, /etc/resolv.conf zu besitzen, was sich als sporadisches DNS liest und einen Nachmittag kostet. resolvectl status sagt, auf welchem Link die Server gelandet sind. Wenn die Antwort keiner davon ist, füttert nichts den Daemon, und das ist der Fehler.\nRHEL, Rocky und Alma Und hier ist die, die es wert ist, zweimal gelesen zu werden. Das Paket ist da, nss-resolve ist verfügbar, NetworkManager kann es ansteuern, und Red Hats Dokumentation sagt das hier:\nsystemd-resolved is an unsupported Technology Preview.16\nDiese Formulierung steht seit 9.0 in den RHEL-9-Release-Notes und steht bei 9.8 immer noch da. Technology Preview heißt kein Produktions-SLA, und Red Hat empfiehlt es ausdrücklich nicht für den Produktionseinsatz.\nAktiviert ist es auch nicht. NetworkManager besitzt auf diesen Systemen resolv.conf, es anzuschalten ist also eine NetworkManager-Einstellung statt nur die Unit zu aktivieren:\n# /etc/NetworkManager/conf.d/10-resolved.conf [main] dns=systemd-resolved systemctl enable --now systemd-resolved systemctl reload NetworkManager resolvectl status # confirm NM actually handed the servers over Danach gilt das Drop-in oben unverändert, und Validierung und Cache verhalten sich genau wie auf Fedora.\nAuf RHEL hast du also eine Entscheidung, die es auf den anderen nicht gibt. Du willst einen validierenden, cachenden, Split-DNS-fähigen lokalen Resolver auf einer unterstützten RHEL-Kiste? Dann ist die unterstützte Antwort nicht diese. Sie heißt unbound, oder dnsmasq über NetworkManagers eigenes dns=dnsmasq, und hinter beide stellt Red Hat sich tatsächlich.\nDas Etikett ist keine Aussage über den Code. Es ist eine Aussage darüber, wofür Red Hat ein SLA geben will, und ein cachender validierender Resolver ist ein Ding, zu dem Kunden Tickets aufmachen. Fair genug. Aber wenn du RHEL wegen des Supports kaufst, ist die Namensauflösung auf einer nicht unterstützten Komponente zu betreiben eine Entscheidung, die man bewusst trifft und aufschreibt, und nicht eine, in die man hineinrutscht, weil es im Repo lag.\nNichts ist tatsächlich verstümmelt, und so beweist du es Die Prämisse ist es wert, geprüft zu werden, denn „meine Distro hat es abgeschaltet, ich werde neu bauen müssen“ ist der Reflex, und hier ist er falsch.\nsystemd hat zwei völlig verschiedene Arten von Build-Option, und über sie wird geredet, als wären sie eine:17\nBuild-Option Art Upstream Fedora Debian und Ubuntu Zur Laufzeit änderbar resolve Fähigkeit an gebaut true nein, und beide bauen es nss-resolve Fähigkeit aktiviert gebaut, liegt in systemd-libs enabled, liegt als libnss-resolve bei nein, und beide bauen es dns-over-tls Fähigkeit auto auto, löst auf OpenSSL auf openssl nein, und beide kompilieren es mit ein openssl Fähigkeit aktiviert enabled enabled nein, und beide aktivieren es default-dnssec nur Voreinstellung allow-downgrade no no ja, in einem Drop-in default-dns-over-tls nur Voreinstellung no no Upstream-Voreinstellung ja, in einem Drop-in default-mdns nur Voreinstellung yes no no ja, in einem Drop-in default-llmnr nur Voreinstellung yes resolve no ja, in einem Drop-in Lies die letzte Spalte. Jede Einstellung, über die sich dieser Beitrag beschwert hat, sitzt in der unteren Hälfte, und jede einzelne ist eine Voreinstellung, keine Fähigkeit. Der Code ist auf beiden einkompiliert. Niemand hat etwas entfernt.\nDer Beweis steht weiter oben in diesem Beitrag und brauchte keinen Compiler. Auf dem Standard-Fedora-Paket, mit eingebackenem DNSSEC=no, hat ein Befehl die Validierung angeschaltet, und sie funktionierte vollständig: eine signierte Zone beglaubigt, eine unsignierte ehrlich gemeldet, eine kaputte mit einer präzisen Diagnose verworfen. Wäre sie herauskompiliert worden, hätte resolvectl status nie yes/supported gesagt.\nPrüf also deinen eigenen Build, bevor du nach einer Toolchain greifst:\n# is the crypto there at all systemctl --version | tr \u0026#39; \u0026#39; \u0026#39;\\n\u0026#39; | grep -E \u0026#39;^[+-](OPENSSL|GNUTLS|GCRYPT)$\u0026#39; # ask for the feature and read back what the daemon says it can do resolvectl dnssec \u0026lt;link\u0026gt; yes resolvectl status \u0026lt;link\u0026gt; | grep DNSSEC # yes/supported means the code is there Auf dieser Fedora-Kiste ist das -GCRYPT +GNUTLS +OPENSSL, was reichlich ist: DNSSEC braucht eines davon, und DoT ist gegen OpenSSL gebaut.\nWas die Distributionen wirklich herausnehmen Es gibt eine Sache, die beide herausnehmen, und sie steht nicht auf der Liste, über die sich irgendwer beschwert.\nUpstream kompiliert eine Fallback-Liste von DNS-Servern in die Binary: Cloudflare, Google und Quad9.17 Sowohl Fedora als auch Debian bauen mit leerem -Ddns-servers=, und du kannst es an der ausgelieferten Binary bestätigen, statt mir zu glauben:\n$ strings /usr/lib/systemd/systemd-resolved | grep -ciE \u0026#39;quad9|one\\.one\\.one|dns\\.google\u0026#39; 0 Nichts. Kein Hyperscaler in die ausführbare Datei eingebacken.\nDas ist die eine Stelle, an der beide Distributionen Upstream verbessert haben, und das verdient es, klar gesagt zu werden, angesichts dessen, wie viel dieses Beitrags über Voreinstellungen ging, die ich für falsch halte. Eine Maschine, die ihre DNS-Konfiguration verliert, sollte laut scheitern und auf dich warten. Sie sollte nicht still jeden Namen, den du nachschlägst, an einen Resolver in einer anderen Rechtsordnung schicken, den du nie gewählt hast. Du willst einen Fallback? Setz FallbackDNS= und wähl, wer es ist.\nWenn du wirklich einen Neubau brauchst Ein echter Fall existiert: ein minimaler oder eingebetteter Build, bei dem jemand -Ddns-over-tls=false übergeben hat und der Transport tatsächlich fehlt. Prüf zuerst mit den Befehlen oben, denn es ist selten und sieht genauso aus, als wäre die Einstellung schlicht aus.\nWenn du es doch brauchst, bau das Paket neu, nie make install:\n# Fedora dnf download --source systemd rpmbuild --rebuild --define \u0026#39;_with_upstream 1\u0026#39; systemd-*.src.rpm # Debian and Ubuntu apt source systemd cd systemd-*/ \u0026amp;\u0026amp; editor debian/rules # change the -Ddefault-* flags dpkg-buildpackage -us -uc -b Ich habe keines von beiden auf dieser Maschine gefahren, also nimm sie als die Form der Arbeit, nicht als geprüftes Rezept. Das Prinzip ist, worauf es ankommt. systemd ist PID 1, und ein handgebautes make install über die Kopie deiner Distribution nimmt es aus der Paketverwaltung heraus: keine Sicherheitsupdates mehr, und das nächste Upgrade kämpft mit dir um die Dateien. Das Paket zu bauen behält beides. Für fast jeden ist die ehrliche Antwort, dass ein vierzeiliges Drop-in dieselbe Arbeit in zwanzig Sekunden erledigt, weshalb dieser Abschnitt vor allem existiert, um dich davon abzubringen.\nDrei Konfigurationen, die es wert sind Keine Speisekarte aller Optionen. Drei Positionen, von denen ich jede tatsächlich verteidigen würde.\nLaptop, feindliche Netze Server, dein eigenes Netz Strikt Wogegen du dich verteidigst Das Café und das Hotelportal Nichts Lokales; der Vorgelagerte validiert bereits Ein Resolver-Pfad, dem du nicht traust DNSSEC= allow-downgrade no yes DNSOverTLS= opportunistic no yes StaleRetentionSec= 1d 1d nicht gesetzt Überlebt ein Captive Portal Ja entfällt Nein Überlebt ein gefiltertes .arpa Ja Ja Nein Überlebt blockierten Port 853 Ja entfällt Nein Ein Angreifer kann es downgraden Ja, beide Einstellungen entfällt Nein Ein Laptop in Netzen, die du nicht kontrollierst. Verschlüssele den Transport, und nimm das Downgrade-Risiko dafür in Kauf, dass die Sache hinter einem Captive Portal noch funktioniert.\n# /etc/systemd/resolved.conf.d/60-local.conf [Resolve] DNS=9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net DNSOverTLS=opportunistic DNSSEC=allow-downgrade Cache=yes StaleRetentionSec=1d Ein Server in einem Netz, das du betreibst, mit validierendem Vorgelagerten. Es ist einen Hop entfernt bereits passiert. Tu es nicht zweimal, und nimm keine Abhängigkeit von einem öffentlichen Resolver auf.\n[Resolve] DNSSEC=no DNSOverTLS=no Cache=yes CacheFromLocalhost=no StaleRetentionSec=1d Eine Maschine, auf der du das echte Ding willst. Strikt in beiden Punkten, nichts, was ein Angreifer downgraden kann, und du hast geprüft, dass der Vorgelagerte es tragen kann.\n[Resolve] DNS=9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net DNSOverTLS=yes DNSSEC=yes Cache=yes Die dritte bricht Reverse DNS, wenn irgendetwas in deinem Pfad .arpa filtert, sie bricht vollständig, wenn Port 853 blockiert ist, und sie scheitert geschlossen statt still. Das sind die Bedingungen. Kenn sie, bevor du sie ausrollst, nicht danach, denn eine Kiste, die nichts auflösen kann, ist eine lange Fahrt, wenn sie nicht im Nebenraum steht.\nWas du auch wählst, wende es an und prüf dann, was der Daemon tatsächlich entschieden hat, statt dessen, was du geschrieben hast:\nsystemd-analyze cat-config systemd/resolved.conf # every file, in order systemctl restart systemd-resolved resolvectl status # the state it is really in resolvectl status ist hier das Orakel, so wie der Build das Orakel für eine Hugo-Site ist. Eine Einstellung in einer Datei ist eine Absicht. Was status ausgibt, ist, was passiert.\nDie übrigen Verben sind es wert, gekannt zu werden, denn zusammen beantworten sie fast jede Frage, die du zu diesem Daemon haben wirst, ohne ein Log zu lesen:\nBefehl Was er dir sagt resolvectl status Server, Domänen und Protokolle pro Link, und der aktuelle DNSSEC- und DoT-Zustand resolvectl query NAME Die Antwort, das benutzte Protokoll, das DNSSEC-Urteil, und ob sie aus dem Cache kam resolvectl statistics Cache-Treffer gegen Fehlschläge, und die laufende Strichliste secure/insecure/bogus resolvectl show-cache Alles, was gerade gecacht ist, pro Scope resolvectl flush-caches Den Cache leeren, ohne den Daemon neu zu starten resolvectl dns LINK ... Server auf einem Link zur Laufzeit setzen, ohne Konfigurationsdatei resolvectl dnssec LINK yes Validierung für einen Link anschalten, um vor dem Festschreiben zu testen resolvectl domain LINK ~x Routing- und Suchdomänen auf einem Link setzen resolvectl revert LINK Jede Laufzeitänderung auf diesem Link wegwerfen resolvectl show-server-state Feature-Abtastung pro Server: was bei jedem Vorgelagerten gefunden wurde resolvectl monitor Abfragen und Antworten live mitschauen, was besser ist als raten Alles in diesem mittleren Block gilt nur zur Laufzeit und überlebt nicht, dass ein Link wieder hochkommt, was es zur richtigen Art macht, eine Einstellung auszuprobieren, bevor du sie in ein Drop-in schreibst. Es heißt auch, dass nmcli device reapply dein Testen stillschweigend rückgängig macht, also prüf status danach, nicht davor.\nDie Voreinstellungen sind eine Position, kein Versehen Drei Funktionen in der Box. Eine angeschaltet.\nVerlockend, das als Faulheit zu lesen. Ist es nicht. Über jede dieser Voreinstellungen wurde von Leuten gestritten, die die Bug-Queue auf der anderen Seite der Entscheidung sehen konnten, und Fedora hat wenigstens ehrlich aufgeschrieben, dass es die Supportlast nicht tragen konnte. Das ist eine echte Einschränkung, und ich werde nicht so tun, als wäre es anders.\nAber eine Voreinstellung ist eine Position, und diese sagt, dass eine Abfrage, die niemand prüfen kann, etwas ist, worauf zu bauen in Ordnung geht. Wir haben den Standard seit 2005. Die Registries veröffentlichen die Einträge kostenlos, der Resolver auf deiner Maschine implementiert das Ganze, und der Grund, warum er brachliegt, ist, dass zu viel des Internets nie irgendetwas signiert hat, sodass ihn anzuschalten deine Maschine zu der macht, die kaputt aussieht. Das ist die Form jedes Standards, den niemand durchsetzt. Ihn ordentlich zu machen ist ein Aufwand, den du allein trägst, und der Nutzen taucht erst auf, wenn genug andere ihn ebenfalls getragen haben.\nWeshalb die Bestandsaufnahme der Teil davon ist, bei dem ich tatsächlich handeln würde. Nicht die Einstellungen. Die Einstellungen sind zwanzig Minuten. Die Bestandsaufnahme sagt, dass die Organisationen, die die Leitlinien veröffentlichen, den Resolver ausliefern und den Quelltext der Welt hosten, ihre eigenen Zonen größtenteils nicht signiert haben, und dass gov.uk den Apex signiert und dann die eine Website, an der niemand vorbeikommt, auf eine unsignierte Delegierung gezeigt hat. Jemand hat den schweren Teil gemacht und dann nie den Namen geprüft, den Leute tippen.\nDu kannst nur deins in Ordnung bringen. Wenn du eine Zone betreibst, signier sie, hinterleg das DS, und schlag dann den www-Namen so nach, wie ein Besucher es täte, und bestätige, dass die Kette bis zum Ende überlebt. Es ist ein Nachmittag. Tu das, und das Argument für Validierung hört auf, für jeden, der deinen Namen auflöst, theoretisch zu sein, was der einzige Teil davon ist, den irgendwer von uns tatsächlich reparieren kann.\nsystemd-resolved.service(8) — „implements a caching and validating DNS/DNSSEC stub resolver“; die vier Client-Schnittstellen, die zwei Stub-Listener, synthetische Einträge, die Routing-Regeln und die vier /etc/resolv.conf-Modi.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nresolved.conf(5), wie in systemd 259.9 auf Fedora 44 ausgeliefert — DNSSEC=, DNSOverTLS=, Cache=, CacheFromLocalhost=, StaleRetentionSec= und die Beschreibung des 127.0.0.54-Proxy-Stubs.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nresolved.conf(5) — DNSCacheSize=, MulticastDNSCacheSize= und LLMNRCacheSize=, „Each defaults to 4096“, ergänzt in systemd 261.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 5737 — „IPv4 Address Blocks Reserved for Documentation“: 192.0.2.0/24, 198.51.100.0/24 und 203.0.113.0/24.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 3849 — 2001:DB8::/32 für Dokumentation reserviert, „to reduce the likelihood of conflict and confusion when relating documented examples to deployed systems“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nresolved.conf(5), upstream latest — DNSSEC= „Defaults to allow-downgrade“, DNSOverTLS= „Defaults to no“, die Nummerierungskonvention für Drop-ins, und die vollständige Direktivenliste ohne eine Option für DNS over HTTPS.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nFedora systemd.spec, rawhide — die meson-Build-Flags -Ddefault-dnssec=no, -Ddefault-dns-over-tls=no, -Ddefault-mdns=no, -Ddefault-llmnr=resolve.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nDebian systemd packaging, debian/rules — -Ddefault-dnssec=no, -Ddefault-llmnr=no, -Ddefault-mdns=no, -Ddns-over-tls=openssl. Ubuntus systemd leitet sich von dieser Paketierung ab.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nFedora Change: systemd-resolved — Fedora 33 machte es zum Standard-Resolver; ändert die Voreinstellung „from the upstream default DNSSEC=allow-downgrade to DNSSEC=no“, weil die Funktion „is known to cause compatibility problems with certain network access points“ und Fedora „is not prepared to handle an influx of DNSSEC-related bug reports“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nFedora Magazine — Use DNS over TLS — die empfohlene DNSOverTLS=yes-Konfiguration, angegeben mit nackten IP-Adressen und ohne die #hostname-SNI-Form.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nsystemd issue #8639 — „Add support for DNS-over-HTTPS to systemd-resolved“, eröffnet am 2. April 2018, immer noch offen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nDebian 12 release notes, 5.2.3 — „The new systemd-resolved package will not be installed automatically on upgrades“; „until it has been installed, DNS resolution might no longer work“; „systemd-resolved was not, and still is not, the default DNS resolver in Debian.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nDebian systemd packaging, debian/control — die systemd-resolved-Stanza: Provides: resolvconf, Conflicts: resolvconf, openresolv, Replaces: resolvconf, und libnss-resolve nur unter Suggests: gelistet.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nresolvconf(1), the resolvectl compatibility mode — resolvectl „is a multi-call binary. When invoked as \u0026lsquo;resolvconf\u0026rsquo; \u0026hellip; it is run in a limited resolvconf(8) compatibility mode“; systemd-resolved „is the only supported backend“; welche Optionen unterstützt, ignoriert oder abgelehnt werden; und die Regel, dass /etc/resolv.conf nur geschrieben wird, wenn es ein Symlink auf /run/systemd/resolve/resolv.conf ist.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nDebian isc-dhcp-client file list — liefert /etc/dhcp/dhclient-enter-hooks.d/resolved-enter und /etc/dhcp/dhclient-exit-hooks.d/resolved.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRHEL 9.4 release notes, Technology Previews — „Note that systemd-resolved is an unsupported Technology Preview.“ Unverändert von RHEL 9.0 bis 9.8 übernommen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nsystemd meson_options.txt — die Trennung zwischen Fähigkeits-Optionen (resolve, nss-resolve, dns-over-tls, openssl) und Voreinstellungs-Optionen (default-dnssec, default-dns-over-tls, default-mdns, default-llmnr), und die einkompilierte dns-servers-Fallback-Liste.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://blogs.damiendye.uk/de/dns/resolved-the-resolver-you-are-already-running/","summary":"systemd-resolved läuft gerade jetzt auf den meisten Linux-Desktops, cacht jede Abfrage und validiert keine davon. Dieser Beitrag geht den Auflösungspfad von nss-resolve zu den zwei Stub-Listenern ab, misst auf einer echten Maschine, was der Cache wert ist, schaltet DNSSEC an und zeigt die drei Urteile, die es zurückgeben kann, und erklärt, warum Validierung standardmäßig aus ist, obwohl Upstream sie an ausliefert. Dann eine Bestandsaufnahme, wie wenig des Webs tatsächlich signiert ist, DNS over TLS und seine Falle zwischen strikt und opportunistisch, und die DNS-over-HTTPS-Unterstützung, die seit 2018 gefordert wird und immer noch nicht existiert. Am Ende, was Fedora, Ubuntu, Debian und die RHEL-Familie jeweils ausliefern, wie du es in jedes davon einhängst, und warum die Funktionen, die deine Distribution abgeschaltet hat, Voreinstellungen sind und kein fehlender Code.","title":"Resolved: Der Resolver, den du schon betreibst"},{"content":"Es gibt einen Weg, wie irgendetwas in deinem Netz einen Namen auflösen kann, ohne dass dein DNS-Server die Frage je hört. Keine Einstellung am Rechner geändert, keine Administratorrechte, nichts, was du in einem Log finden würdest. Die Anfrage verlässt den Rechner als ganz normale HTTPS-Anfrage über Port 443, geht an einen Resolver irgendwo im Internet und kommt mit einer Antwort zurück, die dein eigener Resolver verweigert hätte.\nDie Sperrliste greift nie. Der Threat-Feed bekommt die Anfrage nie. Die Logzeile, nach der du gesucht hättest, wurde nie geschrieben.\nDas Ganze heißt DNS over HTTPS, kurz DoH, und es wurde aus gutem Grund gebaut. Einfaches DNS reist im Klartext über Port 53, also können das Café, der Flughafen und dein Internetanbieter jeden Namen mitlesen, den du auflöst, und die Antworten ändern, wenn ihnen danach ist. DoH packt die Anfrage in dieselbe Verschlüsselung wie den Rest des Web und versteckt sie in der Masse. Als Privatsphäre-Maßnahme für jemanden in einem feindlichen Netz tut es genau das, was es verspricht.\nDas Problem ist: Das, was es aushebelt, und das, worauf du dich verlässt, sind ein und dasselbe.\nDein Resolver ist nicht bloß ein Auflösungsdienst. Er ist ein Kontrollpunkt: wo eine als bösartig bekannte Domain mit nichts beantwortet wird, wo eine Anfrage an einen Command-Server im Log auftaucht, wo Protective DNS die Malware-Domain ablehnt, bevor die Verbindung zustande kommt. DoH nimmt die Auflösung von deinem Resolver weg und übergibt sie einem, den du nie gewählt hast, und jede Kontrolle, die du an diesen Resolver gehängt hast, geht mit.\nGewöhnliches DNS geht durch deinen Resolver. DoH geht darum herum. Gleicher Laptop, gleiche Frage. Eine Antwort passiert deine Kontrollen, eine trifft sie nie. Gewöhnliches DNS, Port 53 DNS over HTTPS, Port 443 Laptop fragt nach einem Namen Dein Resolver Sperrliste und Threat-Feed geprüft Anfrage beim Client geloggt böser Name: NXDOMAIN Das Internet nur wenn sie bestand Laptop fragt nach einem Namen Dein Resolver nie gefragt nichts zu blocken nichts zu loggen HTTPS an einen Resolver nach eigener Wahl Fremder Resolver beantwortet alles Die Firewall sieht eine weitere verschlüsselte Web-Verbindung. Sie hat Tausende davon pro Minute, und auf der Leitung sieht diese aus wie der Rest. Derselbe Laptop stellt dieselbe Frage. Links geht sie durch deinen Resolver, der den Namen prüft, ihn loggt und erst dann das Internet fragt. Rechts geht sie direkt über HTTPS an einen Resolver nach Wahl des Clients. Dein Resolver hört sie nie, also gibt es nichts zu blocken und nichts zu loggen, und an der Grenze ist sie eine weitere verschlüsselte Web-Verbindung unter Tausenden. Das ist kein Argument gegen die Verschlüsselung von DNS. Verschlüsseltes DNS ist richtig, und der letzte Abschnitt dieses Beitrags zeigt, wie man es betreibt. Es ist ein Argument darüber, wer den Resolver wählen darf, denn diese Wahl ist das ganze Spiel, und DoH wurde entworfen, um sie dir wegzunehmen und dem Browser zu geben, der App und, wenn du nicht aufpasst, dem Angreifer.\nWas DoH wirklich ist Zieh das Marketing ab, und DoH ist eine ganz normale Web-Anfrage, die zufällig eine DNS-Frage trägt.\nGewöhnliches DNS ist eine kleine Binärnachricht, über UDP oder TCP an Port 53 geschickt. DoH steckt genau diese Nachricht, oder eine JSON-Version davon, in eine HTTPS-Anfrage an einen Webserver, der das Protokoll spricht; die Antwort ist eine HTTPS-Antwort1. Das ist die ganze Idee.\nRFC 8484 hat es im Oktober 2018 standardisiert, und die Absicht war nie versteckt. Der Zweck, sagt die eigene Einleitung, sei „allowing web applications to access DNS information via existing browser APIs“1.\nBestehende Browser-APIs. Eine Webseite. Das hat niemand Jahre später als unangenehmen Nebeneffekt entdeckt. Es steht im ersten Absatz des Standards, festgehalten als das Ziel.\nHier eine Auflösung auf die DoH-Art, von der Kommandozeile aus, gegen einen öffentlichen Resolver, die nach example.com fragt:\n$ curl -s -H \u0026#39;accept: application/dns-json\u0026#39; \\ \u0026#39;https://cloudflare-dns.com/dns-query?name=example.com\u0026amp;type=A\u0026#39; {\u0026#34;Status\u0026#34;:0,\u0026#34;TC\u0026#34;:false,\u0026#34;RD\u0026#34;:true,\u0026#34;RA\u0026#34;:true,\u0026#34;AD\u0026#34;:true,\u0026#34;CD\u0026#34;:false, \u0026#34;Question\u0026#34;:[{\u0026#34;name\u0026#34;:\u0026#34;example.com\u0026#34;,\u0026#34;type\u0026#34;:1}], \u0026#34;Answer\u0026#34;:[{\u0026#34;name\u0026#34;:\u0026#34;example.com\u0026#34;,\u0026#34;type\u0026#34;:1,\u0026#34;TTL\u0026#34;:146, \u0026#34;data\u0026#34;:\u0026#34;23.192.228.80\u0026#34;}]} Kein spezieller Client. Kein Port außer 443. Eine einzige HTTPS-Anfrage, dieselbe Form wie das Abrufen einer Webseite, und ein Name, aufgelöst von einer Maschine auf der anderen Seite der Welt, die von deinem Netz oder deinen Regeln nie gehört hat. Google betreibt denselben Endpunkt, Quad9 auch, und Dutzende weitere.\nSieh dir jetzt an, was deine Firewall sieht. Eine TLS-Verbindung zu einem Webserver auf 443, in die sie nicht hineinlesen kann, weil das der Sinn von TLS ist, und die sie nicht von den Hunderten anderen unterscheiden kann, die sich jede Sekunde zu Content Delivery Networks, Analytics und Werbung öffnen. Die DNS-Frage ist weg. Sie hat das Gebäude als Web-Verkehr verkleidet verlassen, und niemand an der Tür konnte ihr Gesicht sehen.\nAuf der Leitung ist eine DoH-Auflösung eine DNS-Frage, versiegelt in einer Web-Anfrage. Gleiche Frage. Eine steht auf dem Umschlag, eine ist drei Schichten tief versiegelt. Einfaches DNS, Port 53 DoH, Port 443 DNS-Anfrage name=badsite.example type=A Die Firewall liest das vollständig. Sie sieht den Namen, prüft ihn, blockt oder loggt ihn. TLS-Record (alles, was die Firewall sieht) HTTP-Anfrage an einen Webserver DNS-Anfrage (versiegelt) name=badsite.example type=A Auf Port 443 sieht die Firewall nur die äußere Schicht. Eine TLS-Verbindung zu einem Webserver, wie ein Seitenaufruf, eine Werbung oder ein Analytics-Beacon. Der Name taucht nie auf. Eine einfache DNS-Anfrage steht auf dem Umschlag: Die Firewall liest den Namen und handelt danach. Eine DoH-Anfrage ist dieselbe Frage, versiegelt in einer HTTP-Anfrage in einem TLS-Record, und die Firewall sieht nur die äußere Schicht, eine Verbindung zu einem Webserver auf 443, die aussieht wie jede andere. Der Name taucht nie dort auf, wo eine Kontrolle ihn erreichen könnte. Es gibt drei Wege, wie ein Client eine DNS-Anfrage bewegen kann, und es lohnt sich, sie nebeneinanderzulegen, denn der Unterschied ist der ganze Beitrag.\nTransport Port Dein Resolver sieht sie An der Grenze abweisbar Verschlüsselt Einfaches DNS 53 (UDP/TCP) Ja, wenn du es erzwingst Ja, 53 ausgehend sperren Nein DNS over TLS (DoT) 853 Nur wenn er auf deinen zeigt Ja, 853 ausgehend sperren Ja DNS over HTTPS (DoH) 443 Nur wenn er auf deinen zeigt Nein, 443 kannst du nicht sperren Ja Einfaches DNS ist lesbar und sperrbar, und genau deshalb war es leicht zu kontrollieren und leicht auszuspähen. DoT verschlüsselt die Anfrage, behält aber seinen eigenen Port, also kannst du sie an der Grenze weiter abweisen. DoH ist das eine ohne Griff: verschlüsselt wie DoT, aber auf demselben Port, den du nie schließen kannst, sodass der einzige verbleibende Hebel ist, welchen Resolver der Client gewählt hat, und um diesen Hebel geht es in diesem Beitrag.\nWer den Resolver auswählt Das ist deshalb wichtig, weil eine moderne Maschine fünf verschiedene Dinge hat, die jeweils entscheiden können, wohin DNS geht, und du steuerst standardmäßig genau eines davon.\nFünf Dinge auf einer Maschine können einen Resolver wählen. Du setzt eines davon. Wer entscheidet, wohin die Auflösung geht Schicht Wer den Resolver wählt Standardmäßig deiner? Betriebssystem Dein Netz, per DHCP oder Router Advertisements Ja Browser Standard des Herstellers, außer die Richtlinie sagt anders Nur wenn du die Richtlinie setzt Anwendung oder ihre Bibliothek Wer den Code schrieb, zur Build-Zeit Nein Skript auf einer Webseite Wer die Seite betreibt, oder jedes geladene Skript Nein Malware Der Betreiber, fest verdrahtet, oft per Adresse statt Name Nein Keine der unteren drei braucht Administratorrechte, eine geänderte Einstellung oder irgendetwas, das du im OS sehen würdest. Fünf Schichten auf einer Maschine, jede kann ihren eigenen Resolver wählen. Das Betriebssystem nutzt den, den dein Netz austeilt, und der gehört dir. Der Browser nutzt den Standard seines Herstellers, sofern deine Richtlinie nichts anderes sagt. Eine Anwendung, ein Skript auf einer Webseite und Malware wählen jeweils selbst und brauchen dafür nichts von dir. Das Betriebssystem fragt den Resolver, den dein Netz per DHCP oder Router Advertisements ausgeteilt hat. Der gehört dir, und es ist das Modell, von dem alles vor etwa 2019 ausging: ein Resolver, vom Netz ausgeteilt, weshalb DNS-Kontrollen auf Netzebene dreißig Jahre lang funktioniert haben.\nDer Browser hat es kaputt gemacht. Firefox und Chrome liefern beide die Maschinerie mit, ihr eigenes DoH zu betreiben, zu einem Resolver, den ihr Hersteller ausgewählt hat, über deinen Kopf hinweg, und ziehen sich nur zurück, wenn sie ein verwaltetes Netz erkennen. Und eine Anwendung kann ihren eigenen DoH-Client und einen fest verdrahteten Resolver im Code tragen, zur Build-Zeit festgelegt; sie liest dein DHCP nicht und fragt nicht. Reichlich legitime Software tut das bereits.\nEin Skript auf einer Webseite ist das, was dich stutzig machen sollte, weil es überhaupt nichts Installiertes braucht. Der curl-Befehl oben ist eine einzige HTTPS-Anfrage, und ein Browser macht HTTPS-Anfragen für sein Leben gern. Ein paar Zeilen JavaScript auf irgendeiner Seite, die ein Nutzer öffnet, können Auflösungen an einen öffentlichen DoH-Endpunkt schicken, weil die großen Anbieter Cross-Origin-Anfragen absichtlich erlauben, damit Web-Apps sie nutzen können, der erklärte Zweck in RFC 8484. Die Seite, die du gerade liest, könnte gerade jetzt Namen über einen Resolver in einem anderen Land auflösen, und du würdest eine weitere HTTPS-Verbindung sehen.\nUnd Malware wählt ihren eigenen Resolver aus dem naheliegenden Grund: Sie will nicht, dass du siehst, wohin sie ruft. Sie trägt den Resolver im Code, erreicht ihn oft über die Adresse, sodass es keine Bootstrap-Auflösung zum Abfangen gibt, und braucht für nichts davon deine Erlaubnis.\nLies diese Spalte noch einmal. Die unteren drei brauchen keine Administratorrechte, keine geänderte Einstellung und nichts, was im Betriebssystem sichtbar wird. Die Kontrolle, die du über Jahre aufgebaut hast, ein Resolver, eine Sperrliste, ein Log, ging davon aus, dass die oberste Zeile die einzige Zeile ist. Das ist sie seit Jahren nicht mehr.\nDerselbe Trick, den die Browser-Hersteller fürchteten Der Webseiten-Fall ist weder theoretisch noch neu. So werden Protokoll-Helper missbraucht: Eine Webseite sendet Bytes, etwas weiter unten handelt danach und kann nicht erkennen, ob sie von der Seite eines Angreifers statt von einem echten Client kamen, weil sie auf der Leitung identisch sind. Bei DoH ist das Stück weiter unten ein öffentlicher Resolver, der antwortet, ohne wissen zu können, dass das anfragende JavaScript von einer Phishing-Seite kam, und dein Resolver, der mit der Sperrliste und dem Log, war nie im Pfad, um eine Meinung zu haben. Kein Loch, das durch deine Kontrollen geschlagen wird, sondern eine Straße, die um sie herum gebaut ist, gepflastert mit derselben Verschlüsselung, zu der du allen rätst.\nEs ist bereits der Kanal der Malware-Autoren Du musst dir nicht ausmalen, wie das genutzt wird. Es ist seit Jahren dokumentiert, von namentlich genannten Forschern, an echten Samples, und die Richtung ist eindeutig: vom kriminellen Bot 2019 zum staatlichen Geheimdienstwerkzeug im Jahr darauf, und seither jedes Jahr geschäftiger, mit frischen Backdoors, die noch 2026 auftauchen.\nSample Gemeldet Akteur Was DoH trug Godlua 1. Juli 20192 Kriminelles Botnetz Die Auflösung des Namens seines Command-Servers PsiXBot 6. September 20193 Kriminell (Infostealer) Auflösung der Command-and-Control-Domain, über Googles DoH OilRig (APT34) Q2 20204 Iranisch, staatsnah Gestohlene Daten, per DoH zu Google und Cloudflare exfiltriert ChamelDoH 16. Juni 20235 ChamelGang (APT) Sein gesamter Command-Kanal, DNS TXT über DoH zu Google und Cloudflare BRICKSTORM 4. Dezember 20256 China-nahe Backdoor C2 vergraben unter HTTPS und verschachteltem TLS, DoH unter den Schichten Dohdoor 26. Februar 20267 Ungeklärt (UAT-10027) C2-Auflösungen an Cloudflares DoH auf 443 geschickt Godlua, der erste breit gemeldete Fall, war eine Linux- und Windows-Backdoor, deren Analyse festhält, sie „uses DNS over HTTPS to get the C2 name to ensure secure communication between the bots, the Web Server and the C2“2. In einem Netz, das Port 53 beobachtet, ist das Auflösen deines Command-Servers ein Geschenk an den Verteidiger. Über DoH gibt es nichts zu beobachten.\nProofpoints Satz zu PsiXBot ist der zitierenswerte, ein Threat-Intelligence-Anbieter, der das Stille laut ausspricht. DoH für Command and Control zu nutzen, schrieben sie, „should be a warning shot for the cybersecurity community as there are no simple solutions to help identify an infected host or the process of receiving instructions“3. Keine einfachen Lösungen, von den Leuten, deren Job es ist, sie zu finden.\nDann hob OilRig es eine Stufe höher. Kasperskys Beschreibung ist genau die Änderung, um die es in diesem Beitrag geht: „instead of plain text requests to port 53, they would use port 443 in encrypted packets“, mit einem Tool, das „allows DoH queries to Google and Cloudflare services“4. Eine nationale Geheimdienstoperation, die die öffentlichen DoH-Anbieter als Rohr nutzt, um gestohlene Daten an allem vorbeizuschleusen, was das DNS beobachtete.\nUnd dabei blieb es nicht. Es breitete sich aus. Bis 2023 hatte ChamelGang eine C++-Linux-Backdoor, ChamelDoH, die ihren gesamten Command-Kanal über DoH führte, DNS-TXT-Anfragen an ihre eigenen Nameserver über Google und Cloudflare schickte; der Forscher, der sie fand, merkte an, dass sowohl Erkennung als auch Abwehr „become difficult“ werden, weil der verschlüsselte Transport nicht abgefangen werden kann und eine bösartige Anfrage sich nicht von einer echten unterscheiden lässt5. Im Dezember 2025 zerlegte CISA BRICKSTORM, eine China-nahe Backdoor, die HTTPS, WebSockets und verschachteltes TLS stapelt und „also uses DNS-over-HTTPS (DoH)“, um ihr C2 im gewöhnlichen Web-Verkehr zu vergraben6. Bis Februar 2026 war es schlicht Handwerk: Cisco Talos fing Dohdoor ab, das „securely sends encrypted DNS requests to Cloudflare\u0026rsquo;s DNS server over HTTPS port 443“, um seinen Command-Server zu finden, und sich per Phishing in amerikanische Schulen und Krankenhäuser hackte7.\nSo sieht es aus. Keine Technik, die ihren Moment hatte und verblasste, sondern eine, die Jahr für Jahr von mehr Händen aufgegriffen wird. Das Problem wird schlimmer, nicht besser, und eine frische Familie taucht inzwischen planmäßig auf.\nEine Eigenschaft erledigte die Arbeit in jeder einzelnen: Die Auflösung verließ den Rechner als HTTPS auf 443, und der Resolver des Verteidigers sah sie nie. Keine Schwäche, die jemand eines Tages finden könnte. Eine Funktion, die Angreifer wieder und wieder ausgeliefert haben, mehrere davon Staaten.\nUnd sei dir klar darüber, warum sich diese Tabelle Jahr für Jahr füllt. Jede Familie darin geht durch eine Tür, von der die Autoren von DoH gewarnt wurden, dass sie sie offen ließen, im Text des Standards selbst, und die sie trotzdem offen ließen8. Das war kein Versehen. Es war Kurzsichtigkeit, mit Absicht gewählt, von Leuten, zu denen ICANNs eigener Technologe gehörte. Ich nenne es also, wie es ist: In dieser Sache ist ICANN ein Wegbereiter von Cyberkriminalität. Im Text des Standards selbst gewarnt, was kaputtgehen würde, setzten ihre Leute trotzdem ihren Namen darunter, und die Tabelle oben ist, was durch die Lücke kam. Das Verbrechen ist keine Überraschung. Es ist die Rechnung für eine Entscheidung, und wessen Entscheidung das war, ist der Rest dieses Beitrags.\nUnd bei alldem kauft DoH nicht einmal das, was man ihm unterstellt: Schutz vor einer gefälschten Antwort. Den Sprung zu einem Resolver zu verschlüsseln, authentifiziert nicht, was der Resolver zurückgibt, und ein DoH-Server kann trotzdem einen gefälschten Record liefern. Der Standard gibt es zu und sagt, die Regel gegen nicht konfigurierte Server „does not guarantee protection against invalid data“9.\nDer eine Mechanismus, der eine DNS-Antwort authentifiziert, ist DNSSEC, und DoH ist das nicht. Schlimmer noch, bei fast jedem Client wird DNSSEC am rekursiven Resolver validiert, nicht auf dem Gerät: Der Client vertraut einfach dem Wort des Resolvers, dass die Antwort geprüft wurde. DNSSEC hat dich also immer nur so weit geschützt, wie du dem prüfenden Resolver vertrautest, und DoHs eigentlicher Zug ist es, dieses Vertrauen einem entfernten Betreiber zu übergeben, den du nicht sehen oder prüfen kannst.\nInsofern kann DoH dich eher auf einer gefälschten Seite landen lassen, nicht seltener: Die lokalen Verteidigungen, die eine gekaperte Antwort abgefangen hätten, der Protective-DNS-Feed, die eigene Filterung des Betreibers, sind genau das, worum du herumgeleitet hast, und übrig bleibt nur das Wort eines entfernten Betreibers, auf Treu und Glauben genommen.\nDoH verschiebt, wem du für die Antwort vertraust. Es entfernt nicht die Notwendigkeit, jemandem zu vertrauen. Jemandem muss für die Antwort vertraut werden. DoH ändert nur wem, und zu einem, den du nicht prüfen kannst. Dein eigener Resolver Ein entfernter DoH-Resolver Dein Gerät Resolver, den du kontrollierst Validiert DNSSEC für dich Trägt deine Sperrliste und dein Log Du kannst ihn einsehen und prüfen Lügt er, gehört er dir und du kannst nachsehen Dein Gerät verschlüsseltes Rohr Resolver, den du nicht kontrollierst Validiert DNSSEC, und du glaubst seinem Wort Du kannst ihn nicht sehen oder prüfen Deine lokale Sperrliste ist aus dem Pfad Fälscht er, fängt ihn lokal nichts ab Verschlüsselung sichert das Rohr, nicht die Wahrheit der Antwort. DNSSEC wird am Resolver geprüft, also vertraust du dem Resolver so oder so. DoH macht ihn nur zu einem, den du nicht sehen kannst. DoH nimmt nicht die Notwendigkeit weg, einem Resolver für die Antwort zu vertrauen, es verschiebt sie nur. Dein eigener Resolver validiert DNSSEC, trägt deine Sperrliste und lässt sich prüfen; ein entfernter DoH-Resolver validiert an deiner Stelle, und du nimmst sein Wort, über ein verschlüsseltes Rohr, das den Sprung sichert und nichts darüber sagt, ob die Antwort wahr ist. Wovor DoH angeblich schützt Tut es das? Mithören auf dem Sprung zum Resolver Ja, die Anfrage ist verschlüsselt Manipulation auf diesem Sprung Ja Ein gefälschter Record vom Resolver selbst Nein, das ist DNSSECs Aufgabe, nicht DoHs Ein bösartiger, genötigter oder kompromittierter Resolver Nein, du vertraust ihm jetzt völlig Sperren von Malware, Trackern und per Gerichtsbeschluss Nein, es leitet um sie herum Und nichts davon ist eine neue Idee, über die DoH aus Versehen gestolpert wäre. Bösartige Domains am Resolver zu filtern, ist genau das, was OpenDNS seit gut zwanzig Jahren tut, indem es Phishing und Malware für Millionen Nutzer blockt, bevor die Antwort sie je erreicht, und das ist das Modell, für dessen Besitz Cisco 2015 gezahlt hat10. Zwei Jahrzehnte Sicherheit auf Resolver-Ebene, die Leute schützte, die nie etwas konfiguriert haben, und DoH hat das ganze Modell mit einem Schlag ausgehöhlt: Richte die App auf ihren eigenen Resolver, und OpenDNS, oder was dein Netz sonst gewählt hat, ist nicht mehr im Pfad.\nWarum die alte Antwort aufgehört hat zu funktionieren Solange DNS auf Port 53 lebte, war die Antwort im Netz einfach. Zwing jeden Client, deinen Resolver zu nutzen, und sperre an der Grenze Port 53 ausgehend überall sonst. Eine Maschine, die nach einem externen DNS-Server griff, wurde abgewiesen, also musste sie über deinen kommen, also galten deine Kontrollen für alles. Grob, und es funktionierte.\nDoH erledigt das mit einem Zug, indem es 443 nutzt. Ausgehendes 443 kannst du nicht sperren. Das ist das Web. Der Port, den du schließen würdest, um DNS durch deinen Resolver zu zwingen, ist also genau der, den du nie schließen kannst, und die Verschlüsselung, die deinen ISP am Schnüffeln hindert, hindert auch dich daran, eine DoH-Anfrage von einem Seitenaufruf zu unterscheiden.\nDie zwei Dinge, mit denen du die Kontrolle zurückholen würdest, den Port schließen und den Verkehr lesen, sind beide bauartbedingt weg. Genau diese zwei auszuhebeln, in den Händen eines feindlichen Netzes, ist das, wofür DoH gebaut wurde.\nUnd den Verkehr zu lesen ist nicht der Ausweg, nach dem es klingt, denn es gibt nur einen Weg dahin: alles aufbrechen und inspizieren. Um das DNS in einer 443-Verbindung zu sehen, musst du jede HTTPS-Verbindung im Netz per Man-in-the-Middle abfangen, dein eigenes Root-Zertifikat auf jedes Gerät bringen und das Ganze entschlüsseln und neu verschlüsseln. Darauf greift eine wachsende Zahl von Admins jetzt zurück, um die Sichtbarkeit zurückzukratzen, die ihnen eine einzige Firewall-Regel früher umsonst gab.\nUnd es ist ein weit schlechterer Tausch: Du hast TLS für alles geschwächt, eine Entschlüsselungsbox in den Pfad jedes Logins und jeder Banking-Sitzung gesetzt und ein Ziel gebaut, das alles davon kompromittiert, eine Haltung, vor der US-CERT unumwunden gewarnt hat11. Die verhältnismäßige Kontrolle war kaputt, also bleibt die unverhältnismäßige.\nDas ist die Zwickmühle. Der Mechanismus, der einen Journalisten im Flughafen-WLAN vor einem feindlichen Netz schützt, ist derselbe, der Malware in deinem Netz vor dir schützt, und das Protokoll kann die beiden nicht auseinanderhalten. Ein Resolver, der umgangen wird, weiß nicht, ob er ein Zensor oder ein Sicherheitsteam ist. Er weiß nur, dass er ausgeschlossen wurde.\nDie richtige Antwort war immer DNS over TLS Hier kommt der Teil, der alles verrät. Um DNS zu verschlüsseln, brauchte es nichts von alldem. Das war zwei Jahre vor DoH erledigt, und zwar so, dass die Person, die das Netz betreibt, ihre Arbeit weiter machen konnte.\nDNS over TLS, RFC 7858, ist von Mai 2016. Seine Kurzfassung sagt in der ersten Zeile, wofür es da ist: to „provide privacy for DNS“, eine Verschlüsselung, die „eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network“12. Das ist der ganze Privatsphäre-Fall, erledigt: Das Café und der ISP genauso ausgesperrt wie bei DoH, weil die Anfrage Ende zu Ende verschlüsselt ist.\nUnd mitverfasst wurde es von Paul Hoffman, der dann auch den DoH-Standard mitverfasst hat1. Also keine zwei rivalisierenden Lager. Dieselben Leute, die die Privatsphäre schon gelöst hatten, lösten sie noch einmal auf andere Weise.\nWer Hoffman ist, spielt eine Rolle, weil es sagt, woher das kam. Er ist kein Zuschauer im DNS: Sein Name steht auf mehr als achtzig RFCs, darunter der DNS-Terminologie-Standard, und er macht die Arbeit als Technologe bei ICANN13. Der Standard, der DNS auf 443 versteckte, wurde also aus dem Inneren von ICANN mitgeschrieben, der amerikanischen Instanz, die entscheidet, was in die Root kommt.\nUnd ICANN ist nicht der uneigennützige Verwalter, den das Wort nahelegt. Ich habe seine Bilanz getrennt dargelegt: in Kalifornien gegründet, Kalifornien verantwortlich, und bereit, seine Stellung über den Namensraum für die eigenen Zwecke zu nutzen. Das war keine Privatsphäre-Kampagne vom Rand. Es war das Establishment, das die Root hält, und traf einen Privatsphäre-Fall, den es 2016 bereits getroffen hatte, ein zweites Mal, auf eine Weise, die den Netzbetreiber entfernte.\nFrag also, was der zweite Weg hinzufügte, denn Privatsphäre war es nicht.\nStandard Jahr Port Verschlüsselt DNS Betreiber sieht noch, dass es DNS ist DNS over TLS (RFC 7858) 2016 853 Ja Ja DNS over HTTPS (RFC 8484) 2018 443 Ja Nein Die Privatsphäre war 2016 durch DoT gelöst. DoH kam zwei Jahre später und fügte nur Umgehung hinzu. Verschlüsseltes DNS: was zuerst kam, und was danach kam Mai 2016 DNS over TLS (RFC 7858), Port 853 Verschlüsselt DNS. Betreiber sieht noch, dass es DNS ist. Privatsphäre gelöst. Okt 2018 DNS over HTTPS (RFC 8484), Port 443 Selber Hauptautor. Selbe Verschlüsselung. Betreiber sieht es nicht mehr. Jul 2019 Godlua: erste Malware, die ihr C2 über DoH versteckt Jul 2019 ISPA nennt Mozilla „Internet Villain“ für DoH, zieht es dann zurück Sep 2019 PsiXBot löst seine C2-Domains über Googles DoH auf Feb 2020 Firefox schaltet DoH in den USA standardmäßig ein, Resolver Cloudflare Q2 2020 OilRig (APT34) exfiltriert Daten über DoH Die Privatsphäre war 2016 vollständig. Alles unterhalb des zweiten Punkts ist Umgehung und wofür Umgehung genutzt wurde. Nichts davon verlangte einen neuen Privatsphäre-Standard. Die Reihenfolge ist das Argument. DNS over TLS löste das Privatsphäre-Problem 2016, auf einem Port, den der Netzbetreiber weiter regeln kann. DNS over HTTPS kam zwei Jahre später vom selben Hauptautor, fügte der Privatsphäre nichts hinzu außer dem Wechsel auf Port 443, und alles unterhalb dieses zweiten Punkts ist Umgehung und wofür Umgehung genutzt wurde. Das einzige Kästchen, das sich geändert hat, ist das letzte. DoT läuft auf seinem eigenen Port, 853, also kann der Betreiber sehen, dass es DNS ist, und entscheiden, was damit passiert: es zum freigegebenen Resolver durchlassen, sonst abweisen. DoH legt dieselbe verschlüsselte Anfrage auf 443 und mischt sie ins Web, wo der Betreiber sie nicht herausgreifen kann.\nGleiche Privatsphäre, gleiche Verschlüsselung. Der einzige Unterschied zwischen den beiden Standards ist, ob die Person, die das Netz betreibt, ihr eigenes DNS noch sehen kann. Das ist keine Privatsphäre-Funktion. Privatsphäre kam 2016. Es ist eine Umgehungsfunktion, und es ist das Einzige, was DoH hinzufügt.\nUnd sie wussten es. Das ist dokumentiert, nicht gefolgert. RFC 8484s eigene Operational Considerations sagen es unverblümt: „Filtering or inspection systems that rely on unsecured transport of DNS will not function in a DNS over HTTPS environment due to the confidentiality and integrity protection provided by TLS“8.\nDiese Systeme sind die Sicherheitswerkzeuge, die Nutzer bereits schützen: das Blocken von Malware und Command-Servern, Protective-DNS-Feeds, Jugendschutzfilter, Enterprise-Inspection. Der Standard benennt sie in seinem eigenen Text als die Dinge, die aufhören zu funktionieren. Werkzeuge kaputt zu machen, die Menschen bereits schützten, war eine Entscheidung, mit offenen Augen getroffen und standardmäßig ausgeliefert. Die Wirkung zu kennen und sich trotzdem dafür zu entscheiden, ist eine Entscheidung, für die man Rechenschaft verlangen darf.\nDeshalb überlebt das Privatsphäre-Framing die Zeitleiste nicht. Sobald DoT existiert, kann Privatsphäre nicht der Grund für DoH sein, weil Privatsphäre schon erledigt war, vom selben Autor, zwei Jahre früher. Privatsphäre war also der Nebelvorhang.\nZieh ihn weg und sieh dir an, was der zweite Standard tatsächlich in Gang setzte: ein Wettrüsten. Es machte aus einer Kontrolle, die eine Firewall-Zeile war, eine dauerhafte Jagd, Resolver gegen Sperrlisten gegen frische Resolver, der Betreiber standardmäßig im Nachteil, und eine Handvoll US-Firmen mit dem Klartext am Ende davon.\nNenn das einen Nebeneffekt einer Privatsphäre-Funktion, wenn du magst. Nach der Beweislage, mit bereits ausgeliefertem DoT und dem Standard, der selbst zugibt, dass es die Filterung kaputt macht, ist es der Zweck, und Privatsphäre war das Wort, das auf die Schachtel gemalt war. Und es wurde unter diesem Wort hart vorangetrieben, von den Parteien, die profitierten.\nHat DoH vorangetrieben und ausgeliefert Was sie sonst noch sind Mozilla Hat RFC 8484 mitverfasst und dann DoH für US-Firefox standardmäßig aktiviert, Resolver Cloudflare Google Liefert DoH in Chrome aus, betreibt einen großen öffentlichen DoH-Resolver, und ist ein Werbeunternehmen Cloudflare Der Standard-Resolver für US-Firefox, also empfängt es diese Anfragen Die Leute, die es als Privatsphäre verkauften, waren die Browser-Hersteller, und die Nutznießer waren nicht nur die Nutzer.\nDarf ich fragen, warum, wenn das Ziel Privatsphäre war, die Antwort nicht der Standard für verschlüsseltes DNS war, den es schon gab und der den Betreiber im Bilde ließ, sondern ein zweiter, gebaut, damit der Betreiber es nicht sehen kann? Ich frage nicht, wer es abgezeichnet hat. Ich frage, welcher Teil von „Privatsphäre“ es verlangte, die eine Person auszuschließen, die für das Netz verantwortlich ist.\nDenn das ist das eigentliche Ziel, und es ist der Netzadministrator: der Profi, der für die Sicherheit und den Schutz des Netzes verantwortlich ist, standardmäßig als Gegner behandelt. DoH entfernt nicht einmal die Überwachung, über die der Privatsphäre-Pitch klagte. Wie Bert Hubert von PowerDNS darlegte, wurde DNS „typically provided by the operator of a network“, und es standardmäßig zu einem Dritten zu verschieben ist „a net-negative for privacy for everyone“, weil dieser Dritte „gets a complete log per device of all DNS queries, in a way that can even be tracked across IP addresses“14.\nDie Anfragen sind nicht versteckt. Sie werden einem US-Resolver-Betreiber statt dem Admin übergeben, und der Admin ist die einzige Partei, die entfernt wird. Die Hersteller wissen es auch. Die „detect a managed network and stand down“-Logik im nächsten Abschnitt existiert genau deshalb, weil die Voreinstellung den Admin übergeht, und sie haben den Ausschalter ausgeliefert, statt die Voreinstellung zu ändern.\nFrag jetzt, wer davon profitiert, DNS am Betreiber vorbeizuleiten. Das Aushängeschild ist der Journalist im feindlichen Flughafen-WLAN, und diese Person gibt es wirklich. Die Werbe- und Tracking-Industrie gibt es auch, deren Domains an der Sperrliste eines Netzes vorbeispazieren, sobald eine App oder ein Browser sie über DoH auflöst.\nSperren auf Netzebene, der Pi-hole, die Firmen-Sperrliste, der filternde Resolver, funktioniert, indem der Name eines Trackers mit nichts beantwortet wird. DoH ist der Weg, wie der Name trotzdem beantwortet wird. Und der größte Betreiber eines öffentlichen DoH-Resolvers ist Google15, ein Werbeunternehmen, das DoH auch in seinem eigenen Browser ausliefert16.\nEine Privatsphäre-Funktion, verkauft von der Firma, die das Tracking verkauft, deren Design das Werkzeug aushebelt, das die Leute betreiben, um es zu blocken. Mach daraus, was du willst. Ich habe mir meine Meinung gebildet.\nSogar die grobe Version dieses Einwands wurde geäußert. Im Juli 2019 nominierte der britische ISP-Verband Mozilla als „Internet Villain“ für DoH, das „bypass UK filtering obligations and parental controls, undermining internet safety standards in the UK“17. Sie wählten ein ungeschicktes Ziel und einen noch schlechteren Rahmen, wurden niedergeschrien und zogen es zurück.\nZieh aber die Politik ab, und die Beobachtung darunter war richtig, und sie gilt, egal ob die umgangene Kontrolle ein Jugendschutzfilter, eine Firmen-Sperrliste oder ein Pi-hole im Abstellzimmer ist. DoH ist dafür gebaut, DNS an dem vorbeizubringen, der das Netz betreibt.\nUnd das ist keine Kleinigkeit, denn DoH ist jetzt das am schwersten zu sperrende der drei. DoT sitzt auf 853, wo ein Netz es noch abweisen kann. DoH nicht, also ist es von allen Wegen, wie DNS ein Netz verlassen kann, der eine ohne Griff, was es zum größten Einzelrisiko von allen macht.\nDas reicht bis ins Recht, nicht nur in die Sicherheit. In Großbritannien läuft die Sperrung mit rechtlichem Gewicht beim ISP über DNS: die Liste der Internet Watch Foundation mit Material über sexuellen Kindesmissbrauch und die Urheberrechts-Verfügungen, die der High Court nach section 97A erlässt, werden über DNS- und IP-Filterung auf dem Resolver durchgesetzt, den ein Kunde erhält18.\nLeite die DNS-Hälfte davon über DoH herum, und die Sperre gilt für diesen Client nicht. Ein Gericht kann anordnen, eine Seite zu sperren, ein Netz kann angewiesen werden, es durchzusetzen, und ein Browser, der über DoH auflöst, findet die Adresse trotzdem, über einen Kanal, den das Netz nicht sehen und nicht schließen kann. Ein Cybergesetz oder einen Gerichtsbeschluss auf Netzebene durchzusetzen, wo es immer getan wurde, wird nahezu unmöglich.\nUnd hier landet die Rechnung bei allen, nicht nur beim Netz. Zerbrich die verhältnismäßige Kontrolle, die chirurgische, die per Gerichtsbeschluss eine benannte Domain am Resolver sperrte, und der Staat gibt nicht auf. Er greift zu einem gröberen Instrument. Der britische Online Safety Act ist dieses Instrument: umfassende Pflichten für Plattformen, vorgeschriebene Alterskontrollen und Ofcom dahinter mit den Bußgeldern, ein Regime, das jeden Nutzer und jeden Dienst im Land betrifft19.\nIch verteidige das Gesetz nicht. Ich zeige, woher der Druck dafür kam. Wenn das schmale Werkzeug, das das Recht am Netz durchsetzte, aufhört zu funktionieren, bekommst du nicht weniger Durchsetzung, du bekommst gröbere, breitere, aufdringlichere Durchsetzung, die auf alle zielt, weil die zielgenaue Version nicht mehr trägt. Das ist der Preis dafür, eine grundlegende Kontrolle zu zerbrechen, und die Leute, die sie zerbrachen, sind nicht die, die ihn zahlen.\nUnd ICANN ist das völlig gleichgültig, denn von Kalifornien aus ist es nicht ihr Problem. Wenn eine Sperre versagt oder eine Plattform ihre Pflichten verletzt, steht nicht ICANN vor Gericht, sondern der Betreiber, die Plattform, das Unternehmen, die sich Ofcom und den Bußgeldern stellen müssen. Die Folgen tragen alle stromabwärts einer Entscheidung, für die die Stelle, die sie traf, nie geradestehen muss.\nZerbrich die chirurgische Kontrolle, und der Staat greift zum Vorschlaghammer. Alle zahlen. Zerbrich die verhältnismäßige Kontrolle, und eine gröbere tritt an ihre Stelle Die chirurgische Kontrolle Eine benannte Domain sperren am Resolver, per Gerichtsbeschluss Präzise, verhältnismäßig, nur auf das Ziel gerichtet DoH zerbricht sie die Auflösung passiert den Resolver nicht mehr Das grobe Instrument Der Online Safety Act: Alterskontrollen für alle, Pflichten für jede Plattform, Ofcom mit Bußgeldern Auf das ganze Land gerichtet Zerbrich das schmale Werkzeug, und der Staat gibt nicht auf. Er greift zum breiten, gerichtet auf alle, weil die zielgenaue Version nicht mehr trägt. Und die, die das schmale Werkzeug zerbrachen, sind nicht die, die für das breite zahlen. Die chirurgische Kontrolle sperrte per Gerichtsbeschluss eine benannte Domain am Resolver. DoH zerbricht sie, also greift der Staat zum groben Instrument: dem Online Safety Act, gerichtet auf jeden Nutzer und jede Plattform im Land. Zerbrich das schmale Werkzeug, und du bekommst nicht weniger Durchsetzung, du bekommst eine breitere, die niemand zielen kann. Stell die Folgen nebeneinander, und sie haben alle dieselbe Form: etwas, das das Netz am Resolver durchsetzte und nicht mehr kann.\nWas das Netz durchsetzte Wie es getan wurde Unter DoH Malware- und Command-Server-Sperren Resolver-Sperrliste und Threat-Feed umgangen; Godlua, PsiXBot und OilRig taten genau das Werbe- und Tracker-Sperren Pi-hole oder ein filternder Resolver umgangen; der Name des Trackers löst trotzdem auf Gerichtsbeschlüsse und die IWF-Liste ISP-DNS-Filterung DNS-basierte Sperre gilt für diesen Client nicht DoT war die ehrliche Antwort. Es verschlüsselt dein DNS und lässt den Betreiber seine Arbeit machen. DoH behielt die Verschlüsselung und legte eine Sache obendrauf: Der Betreiber kann es nicht mehr sehen. Alles andere daran folgt aus dieser einen Entscheidung.\nIn den USA gebaut, überall sonst ausgefochten Nichts davon hört am Ärmelkanal auf, und es als britisches Problem zu lesen schrumpft es auf einen Bruchteil seiner Größe. Dieselbe Form läuft quer durch Europa und bis nach Australien. Ein rechtliches Instrument am einen Ende hinein, eine DNS-Sperre im Netz am anderen hinaus.\nAustralien lässt sein Bundesgericht den ISPs anordnen, den Zugang zu ausländischen rechtsverletzenden Seiten nach section 115A des Copyright Act zu sperren20. Portugal überspringt das Gericht ganz: ein Verwaltungsmemorandum, unter dem Rechteinhaber eine Stelle namens MAPINET benachrichtigen, und die ISPs sperren per DNS binnen fünfzehn Werktagen21. Verschiedene Gesetze, eine tragende Annahme, und es ist die Annahme, die DoH unter ihnen allen wegtritt. Dass der Client über den Resolver auflöst, den er zugeteilt bekam.\nSieh also, was ein Staat tut, wenn diese Annahme scheitert. Er hört auf, sich auf den ISP zu stützen, und beginnt, den öffentlichen Resolvern selbst anzuordnen, die falsche Antwort zurückzugeben. Das ist keine Prognose. Es ist ein Stapel von Urteilen, und er wird höher.\nLand Die Sperranordnung Der öffentliche Resolver Was geschah Italien AGCOMs Piracy Shield, Namen binnen 30 Minuten gesperrt zur Filterung angeordnet, 1.1.1.1 inbegriffen Cloudflare weigerte sich, wurde mit €14,247,698 belegt und legt Berufung ein22 Frankreich Canal+-Verfügung zu Sport-Streaming Google, Cloudflare und OpenDNS allesamt benannt Cloudflare liefert ein HTTP 451, Google lässt die Anfrage stillschweigend scheitern, OpenDNS schaltete sich für das Land ab23 Belgien über 100 Sport-Piraterie-Domains dieselben drei Resolver Cloudflare fügt sich mit einem 451, Google bleibt still, OpenDNS verließ auch Belgien23 Deutschland Universal Music v Cloudflare in erster Instanz angeordnet, 1.1.1.1 inbegriffen in der Berufung aufgehoben, Köln erklärte den Resolver für „passiv, automatisch und neutral“24 Niederlande BREINs dynamische Sperre ISP-Ebene, der Resolver noch nicht Ziggo, KPN und der Rest sperren per DNS und IP, auf Anfrage aktualisiert25 Lies das als eine Sache, nicht als fünf. Ein paar US-Konzerne schrieben DNS für den ganzen Planeten aus eigener Machtvollkommenheit um, brachen die verhältnismäßige Kontrolle, die jedes dieser Länder aufgebaut hatte, und überließen es den Gerichten, herauszufinden, was mit dem Trümmerhaufen zu tun sei. Die Antworten, die diese Firmen geben, alle paar Monate vor eine andere Kammer gezerrt, sagen dir genau, was der Rest der Welt bei ihnen wiegt. Eine legt Berufung ein und schreit Zensur. Eine lässt die Auflösung scheitern und sagt dem Nutzer nichts. Und OpenDNS, der Resolver, der zwanzig Jahre lang stillschweigend Malware filterte und den dieser Beitrag bereits als das nachzuahmende Vorbild hochgehalten hat, streitet gar nicht erst. Er schaltet sich für Frankreich und für Portugal ab, statt sie zu diesen Bedingungen zu bedienen26.\nBleib bei diesem Letzten. Es ist das gute Beispiel in diesem ganzen Stück, das den Raum verlässt. Der Dienst, der Menschen schützte, die nie etwas konfigurierten, findet inzwischen ein ganzes Land leichter aufzugeben als zu bedienen, und der Grund führt geradewegs zu einer Design-Entscheidung zurück, die in Kalifornien von Leuten getroffen wurde, die nie an ein französisches oder ein portugiesisches Gericht denken mussten.\nDas ist das Muster, und ich benenne es. Das ist, was US-Plattform-Engineering mit allem anstellt, das nicht die Vereinigten Staaten ist. Es baut für den eigenen Markt, liefert das Ergebnis als Standard an die Welt aus und behandelt jedes andere Landesrecht, jede Aufsichtsbehörde, jede Gemeinschaft stromabwärts der Änderung als den Schlamassel, den ein anderer aufräumen soll.\nUnd die Heimatregierung stützt die Firmen bis zum Anschlag. Im Februar 2025 setzte das Weiße Haus seinen Namen unter ein Memorandum, das die digitalen Gesetze anderer Länder als „Erpressung aus Übersee“ amerikanischer Unternehmen brandmarkt, das Vereinigte Königreich und die EU beim Namen nennt und den Handelsbeauftragten auf Zölle als Antwort ansetzt27. Sechs Monate später schrieb eine US-Behörde einem Dutzend amerikanischer Tech-Firmen und warnte, dass das Befolgen des britischen Online Safety Act oder des EU Digital Services Act selbst US-Recht brechen könnte28. Lies das zweimal. Das Land, dessen Firmen die Kontrollen brachen, sagt diesen Firmen nun, dass das Befolgen der Antwort einer anderen Demokratie auf den Bruch die Straftat sei.\nDas sagt alles. Ein Gesetz, das ein gewähltes Parlament in Westminster oder Brüssel verabschiedet hat, wird von Washington aus zu einem Angriff auf Amerika umgedeutet, und den Firmen wird gesagt, es zu ignorieren. Es ist nicht so, dass sie den Rest der Welt abgewogen und sich dagegen entschieden hätten. Der Rest der Welt stand nie auf der Waage.\nDie Lösung ist nicht, Verschlüsselung zu verbieten Der bequeme Schluss lautet also \u0026ldquo;DoH sperren\u0026rdquo;, und der ist falsch, genauso wie \u0026ldquo;ICMP sperren\u0026rdquo; bei der Firewall falsch ist. Du willst kein unverschlüsseltes DNS zurück. Klartext-Anfragen auf Port 53 sind ein echtes Risiko, und zu ihnen zurückzukehren, um Sichtbarkeit zurückzugewinnen, tauscht ein Loch gegen ein anderes.\nWas du tatsächlich verloren hast, war nicht die Verschlüsselung. Es war die Wahl des Resolvers. Also hol dir die zurück und lass die Verschlüsselung genau da, wo sie ist.\nBehalte die Verschlüsselung. Hol dir die Wahl des Resolvers zurück. Verschlüsselt den ganzen Weg. Eine Maschine darf DNS mit der Welt sprechen. Clients 53, DoT oder DoH, nur zu deinem Resolver DDR sagt ihnen, wohin Dein Resolver bedient DoH und DoT selbst Sperrliste, Threat-Feed, Log Canary: NXDOMAIN Grenze nur das Upstream oder die Roots Client direkt zu 53, 853 oder öffentlichem DoH-Resolver: abgewiesen Nichts hier schaltet die Verschlüsselung ab. Das Einzige, was dem Client genommen wird, ist das Recht, den Resolver eines anderen zu wählen. Das korrigierte Layout. Clients dürfen einfaches DNS, DNS over TLS oder DNS over HTTPS nutzen, aber nur zu deinem eigenen Resolver, der jetzt alle drei bedient. Dieser Resolver behält die Sperrliste und das Log und ist die einzige Maschine, die DNS jeglicher Art über die Grenze schicken darf. Port 53, Port 853 und bekannte öffentliche DoH-Resolver werden von allem anderen abgewiesen. Nichts hier schaltet die Verschlüsselung ab. Das Einzige, was dem Client genommen wird, ist das Recht, den Resolver eines anderen zu wählen. Die Form ist dieselbe, die das DNS in einer Active-Directory-Domäne in Ordnung bringt: Das Argument ist nie \u0026ldquo;schalt die Funktion ab\u0026rdquo;, es ist \u0026ldquo;entscheide, wer sie steuern darf\u0026rdquo;. Und so sieht das im Einzelnen aus.\nBetreibe verschlüsseltes DNS selbst. Stell einen Resolver auf, der DoH und DoT bedient, nicht nur Port 53, damit ein Client, der Verschlüsselung will, sie von dir bekommt. Du kannst Clients nicht „kein DoH“ sagen und es ernst meinen, während du keinen eigenen verschlüsselten Resolver anbietest. Gib ihnen einen und behalte die Sperrliste, den Threat-Feed und das Logging darauf wie zuvor.\nKündige ihn an, damit Clients ihn absichtlich finden. Discovery of Designated Resolvers (RFC 9462) lässt einen Client einen speziellen Namen abfragen, den eigenen verschlüsselten Resolver seines Netzes erfahren und automatisch auf DoH oder DoT dagegen umsteigen29. Ein DDR-fähiger Client verschlüsselt dann sein DNS und nutzt deinen: die Privatsphäre, die der Nutzer wollte, und die Kontrolle, die du brauchtest, in einem Zug.\nBeantworte den eingebauten Ausschalter des Browsers. Firefox prüft eine Canary-Domain, use-application-dns.net, bevor es DoH standardmäßig einschaltet: Beantworte sie mit NXDOMAIN oder SERVFAIL, und Firefox zieht sich auf den System-Resolver zurück30. Zwei ehrliche Grenzen, beide in Mozillas Worten. Die Canary „only applies to users who have DoH enabled as the default option. It does not apply for users who have made the choice to turn on DoH by themselves“30. Es ist also ein Standardmäßig-aus-Signal, keine Sperre, und es tut nichts gegen die App und die Malware, die den Browser nie etwas gefragt haben.\nSetze die Browser-Richtlinie, wo du die Maschine verwaltest. Auf einem Gerät, das dir gehört, verlass dich nicht auf die Canary. Chromes DnsOverHttpsMode nimmt off, automatic und secure, und Googles Doku sagt, dass, wo sie nicht gesetzt ist, „for managed devices DNS-over-HTTPS queries will not be sent“31; Chrome schaltet sein eigenes Auto-DoH ab, sobald es eine Enterprise-Richtlinie sieht16. Richte es auf deinen Resolver, oder setze es auf off und lass DDR die Verschlüsselung tragen. Firefox hat die passenden Schalter Enabled, ProviderURL und Locked32. Verwaltete Maschine, verwaltete Entscheidung, und die Zeile, die du tatsächlich schließen kannst.\nWeise die Alternativen an der Grenze ab. Die Regeln sind kurz, und sie sagen alle dasselbe: DNS jeglicher Art, nach draußen, nur von deinem Resolver.\nRegel Von Wirkung Ausgehenden Port 53 sperren Alles außer deinem Resolver Kein einfaches DNS nach draußen Ausgehenden Port 853 sperren Alles außer deinem Resolver Kein DoT zu einem externen Resolver HTTPS zu öffentlichen DoH-Resolver-Adressen sperren Alles außer deinem Resolver Schneidet die bekannten DoH-Anbieter ab Den Upstream deines Resolvers auf Protective DNS richten Dein Resolver Malware-Domains vor der Verbindung abgewiesen Du wirst nicht jeden DoH-Endpunkt über die Adresse erwischen, und du kannst es nicht, weil ein neuer nur ein Webserver ist und es kein Ende der Webserver gibt. Bleib also einen Moment bei dem, was diese Sperre jetzt kostet. Um für DoH das zu tun, was block 53 outbound umsonst tat, ziehst du eine Liste von DoH-Server-Adressen, die jemand anderes für dich weiter scannt: Die gepflegten Sperrlisten existieren, weil das der einzige verbliebene Weg ist, und eine davon löst jede bekannte öffentliche DoH-Domain jede Stunde per geplantem Job auf ihre aktuellen IPs neu auf und liefert die Änderungen aus33. Das ist der Tausch, den die Umgehung erzwungen hat.\nExternes DNS sperren Früher, auf Port 53 Heute, DoH auf 443 Die Regel eine Zeile: block 53 outbound eine DoH-Server-IP-Sperrliste abonnieren Vollständigkeit vollständig im Moment des Speicherns nie vollständig; neue Endpunkte tauchen ständig auf Pflege keine stündlich neu gescannt, geholt und neu angewandt Was es braucht die Firewall die Firewall plus den gepflegten Feed eines anderen Eine Kontrolle, die eine statische Zeile war, ist jetzt ein Abo auf ein bewegliches Ziel, eine Jagd auf Webserver, die jeder schneller aufstellen kann, als eine Liste sie benennen kann. Protective DNS schließt das andere Ende: Richte den Upstream deines Resolvers auf einen Filterdienst wie das PDNS des NCSC, das „was built to hamper the use of DNS for malware distribution and operation“34, und die bösen Domains werden vor der Verbindung abgewiesen, für jeden Client, der über deinen Resolver kommt, was, sobald diese Regeln stehen, alle sind.\nStell die den fünf Zeilen von vorhin gegenüber, und jede von ihnen hat eine Kontrolle, die sie schließt. Das ist der Test einer Lösung: nicht „haben wir DoH gesperrt“, sondern „was hindert jedes Ding, das einen Resolver wählen kann, daran, den falschen zu wählen“.\nWer den Resolver wählt Was es schließt Betriebssystem DDR richtet es auf deinen Resolver; halte es so Browser Richtlinie auf verwalteten Maschinen; die Canary beim Rest Anwendung / Bibliothek Grenzsperre auf 53, 853 und öffentliche DoH-Resolver Skript auf einer Webseite Dieselbe Grenzsperre; Protective DNS auf deinem Upstream Malware Dieselbe Grenzsperre, plus Protective DNS, das die Domain abweist Nichts davon schaltet auch nur ein Bit Verschlüsselung ab. Clients bekommen weiter DoH, sie bekommen es nur von dir, und die, die versuchen, es woanders zu bekommen, laufen gegen eine Wand. Die Privatsphäre ist intakt und die Kontrolle ist zurück. Insofern hat man einzig die Freiheit verloren, einen Resolver zu wählen, den du nie freigegeben hast, und die war in einem Netz, für das du verantwortlich bist, nie ihre.\nDarf ich fragen, was diesen Resolver gewählt hat Hier ist die Frage, die man jedem stellen sollte, der einem sagt, das Netz sei so, wie es ist, in Ordnung.\nWenn eine Maschine in deinem Netz einen Namen auflöst, was entschied, welcher Resolver antwortete? Wenn die ehrliche Antwort lautet „was auch immer das OS bekommen hat“, gut, aber nur, wenn du die anderen vier Zeilen dieser Tabelle geschlossen hast, denn sonst lautet sie „was auch immer das OS bekommen hat, es sei denn, der Browser, eine App, eine Webseite oder etwas Übleres hat anders gewählt, in welchem Fall ich keine Ahnung und keine Aufzeichnung habe“. Das ist kein DNS-Aufbau. Das ist eine Hoffnung, und Hoffnung fängt nichts.\nIch frage nicht, wer den Resolver betreibt. Ich frage, was auf jeder Maschine ihn wählen darf, und ob du den Resolver benennen könntest, zu dem gestern jede Auflösung ging. In einem Netz, in dem DoH nicht verwaltet ist, kannst du das nicht, und die Lücke ist jede App, die ihren eigenen Resolver mitbringt, jede Seite, die ein Nutzer öffnet, und jedes Stück Malware, das dieselbe Recherche gelesen hat, die ich gerade verlinkt habe. Drei namentlich genannte Bedrohungsakteure haben ihre Kanäle auf genau dieser Lücke gebaut, und einer ist einer Regierung unterstellt.\nEin Protokoll, das die Wahl des Resolvers dem Netz wegnimmt, war immer ein Geschenk an den, den das Netz zu beobachten versuchte, und so zu tun, als wäre es anders, weil das Marketing „Privatsphäre“ sagte, ist der Weg, wie eine Kontrolle, auf die es ankam, standardmäßig abgeschaltet wird und niemand den Tag protokolliert, an dem es geschah.\nVerschlüssle dein DNS. Betreibe den Resolver selbst. Kündige ihn an, beantworte die Canary, setze die Richtlinie, schließe die Grenze. Behalte die Verschlüsselung und behalte die Wahl. Du kannst beides haben, und wenn du beruflich Netze betreibst, ist beides zu haben die Aufgabe.\nPrivatsphäre war das Wort auf der Schachtel Also Ehre, wem Ehre gebührt. Danke an ICANN, die amerikanische Instanz, die die Root hält und das von innen mitgeschrieben hat, dafür, dass sie das US-Tech-Playbook noch einmal durchgezogen hat: Nimm ein Problem, das schon gelöst war, wickle die Lösung in ein tugendhaftes Wort und zentralisiere das Ergebnis auf eine Handvoll US-Firmen, die am Ende den Klartext halten.\nUnd es sind immer die USA. Die Instanz, die die Root hält, der Resolver, zu dem zwei Browser jetzt standardmäßig gehen, die Werbefirma, die den größten öffentlichen betreibt, das Land, in dem der Klartext landet: amerikanisch, jedes Mal. Es ist ein Muster, keine Pechsträhne.\nPrivatsphäre war der Nebelvorhang. DNS war 2016 verschlüsselt, privat und weiterhin regelbar auf Port 853, und jeder, auf den es ankam, wusste es. Was das Establishment obendrauf auslieferte, war ein Protokoll, gebaut, um die eine Person zu blenden, die für das Netz verantwortlich ist, ein dauerhaftes Wettrüsten aus stündlich neu gescannten Sperrlisten und Gerichtsbeschlüsse, die am Browser tot enden.\nOb das Unfähigkeit oder Gier war, überlasse ich dir, auch wenn die verlinkte Bilanz in eine Richtung zeigt. So oder so hat es den gesunden Menschenverstand geschlagen.\nUnd Entscheidungen wie diese sind der Grund, warum die Rufe, ICANN die Root wegzunehmen, immer wiederkommen, und warum sie sitzen: damit die internationale Gemeinschaft ein Mitspracherecht bekommt, statt dass die Institution eines einzigen Landes das DNS für alle anderen entscheidet und es Verwalterschaft nennt.\nFrüher haben wir das alles mit einer einzigen Zeile gemacht.\nRFC 8484 — DNS Queries over HTTPS (DoH), Oktober 2018. Die Einleitung nennt als Ziel „allowing web applications to access DNS information via existing browser APIs in a safe way consistent with Cross Origin Resource Sharing (CORS)“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n360 Netlab — An Analysis of Godlua Backdoor, 1. Juli 2019. Hält fest, dass das Sample „uses DNS over HTTPS to get the C2 name to ensure secure communication between the bots, the Web Server and the C2“ — die erste breit gemeldete Malware, die DoH missbraucht.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nProofpoint — PsiXBot Now Using Google DNS over HTTPS, 6. September 2019. Berichtet, dass die Malware fest verdrahtete C2-Domains über Googles DoH-Dienst auflöst, und warnt, es „should be a warning shot for the cybersecurity community as there are no simple solutions to help identify an infected host or the process of receiving instructions“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nKaspersky Securelist — APT trends report Q2 2020. Zu OilRig (APT34): Das DNSExfiltrator-Tool „allows the threat actor to use the DNS over HTTPS (DoH) protocol [\u0026hellip;] instead of plain text requests to port 53, they would use port 443 in encrypted packets [\u0026hellip;] which allows DoH queries to Google and Cloudflare services“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nThe Hacker News — ChamelDoH: New Linux Backdoor Utilizing DNS-over-HTTPS Tunneling for Covert CnC, 16. Juni 2023, über Stairwells Fund (Daniel Mayer). ChamelGangs C++-Linux-Implantat ist „a tool for communicating via DNS-over-HTTPS (DoH) tunneling“, das DNS-TXT-Anfragen über legitime DoH-Anbieter an gefälschte Nameserver schickt, sodass „both detection and prevention become difficult“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCISA — Malware Analysis Report: BRICKSTORM Backdoor, AR25-338a, 4. Dezember 2025. „For C2, BRICKSTORM uses multiple layers of encryption (HTTPS, WebSockets, nested Transport Layer Security [TLS]) to hide its communications with the cyber actors\u0026rsquo; C2 server. It also uses DNS-over-HTTPS (DoH)“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCisco Talos — New Dohdoor malware campaign, 26. Februar 2026. Die Backdoor, dem Akteur UAT-10027 zugeschrieben, „securely sends encrypted DNS requests to Cloudflare\u0026rsquo;s DNS server over HTTPS port 443“, um ihren Command-Server aufzulösen, und zielt per Phishing auf US-Bildungs- und Gesundheitseinrichtungen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 8484, Abschnitt 10, Operational Considerations: „Filtering or inspection systems that rely on unsecured transport of DNS will not function in a DNS over HTTPS environment due to the confidentiality and integrity protection provided by TLS.“ Die Wirkung auf die Netzfilterung steht im Standard selbst.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 8484, Abschnitt 9, Security Considerations: Ein DoH-Server „can give a client invalid data in response to a DNS query“, und obwohl der Standard Antworten von nicht konfigurierten Servern untersagt, „this prohibition does not guarantee protection against invalid data, but it does reduce the risk.“ DoH sichert den Transport, nicht die Echtheit des Records; das ist DNSSECs Aufgabe.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nOpenDNS — ein rekursiver DNS-Resolver, 2005/2006 von David Ulevitch gegründet, der Sicherheitsfilterung (Phishing- und Malware-Blocken) und Inhaltsfilterung am Resolver für Heim- und Unternehmensnutzer bietet; 2015 von Cisco übernommen und heute Teil von Cisco Umbrella. Sicherheit auf Resolver-Ebene ist weit älter als DoH.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nUS-CERT / CISA — HTTPS Interception Weakens TLS Security, Alert TA17-075A, 16. März 2017. Warnt, dass das Abfangen von HTTPS durch Vorlage eines lokal vertrauten Zertifikats und Entschlüsseln des Verkehrs die Sicherheit schwächt, weil viele Interception-Produkte Zertifikate nicht richtig prüfen und die Schutzmaßnahmen der Verbindung herabstufen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 7858 — Specification for DNS over Transport Layer Security (TLS), Mai 2016. Die Kurzfassung: „This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network.“ Mitverfasst von P. Hoffman (ICANN), der auch RFC 8484 mitverfasst hat. DoT nutzt den dedizierten Port 853.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nPaul Hoffman (engineer) — „the author or co-author of over 80 Requests for Comments (RFCs)“ und „currently a technologist at ICANN“; sein IETF-datatracker-Profil listet die Bilanz, darunter RFC 7858 (DoT), RFC 8484 (DoH) und RFC 8499 (DNS-Terminologie).\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nBert Hubert (PowerDNS) — Centralised DoH is bad for Privacy, in 2019 and beyond, RIPE Labs. DNS wurde „typically provided by the operator of a network“; zentralisiertes DoH „by default“ ist „a net-negative for privacy for everyone“, weil der Dritte „gets a complete log per device of all DNS queries, in a way that can even be tracked across IP addresses“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nGoogle — DNS-over-HTTPS (DoH) — JSON API. Google Public DNS, einer der größten öffentlichen Resolver, betreibt einen DoH-Endpunkt (dns.google) neben Chromes eigener DoH-Unterstützung.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nChromium Blog — A safer and more private browsing experience with Secure DNS, Mai 2020. „If you are an IT administrator, Chrome will disable Secure DNS if it detects a managed environment via the presence of one or more enterprise policies.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nTechCrunch — Internet group brands Mozilla \u0026lsquo;internet villain\u0026rsquo; for supporting DNS privacy feature, 5. Juli 2019 (Wayback-Snapshot). Die ISPA-Nominierung sagte, DoH würde „bypass UK filtering obligations and parental controls, undermining internet safety standards in the UK“; die Nominierung und die Kategorie Internet Villain wurden nach Gegenwind zurückgezogen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nWeb blocking in the United Kingdom — die Liste der Internet Watch Foundation mit Kindesmissbrauchsbildern und die Urheberrechts-Verfügungen nach section 97A des Copyright, Designs and Patents Act 1988 werden von ISPs umgesetzt; „The technical measures used to block sites include DNS hijacking, DNS blocking, IP address blocking, and Deep packet inspection.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nUK Government — Online Safety Act: explainer. „The Online Safety Act 2023 [\u0026hellip;] puts a range of new duties on social media companies and search services“, mit den „strongest protections [\u0026hellip;] designed for children“, darunter Anforderungen, Kinder vom Zugriff auf schädliche und altersunangemessene Inhalte abzuhalten; durchgesetzt von Ofcom.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCopyright Act 1968 (Australien), section 115A, „Injunctions relating to online locations outside Australia“ — das Bundesgericht kann einem Carriage Service Provider anordnen, „take reasonable steps to disable access to the online location“, die australische Form der Seitensperre auf ISP-Ebene per DNS und IP.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nEDRi — Portugal: \u0026ldquo;Voluntary\u0026rdquo; agreement against copyright infringements. Unter einem Memorandum of Understanding von 2015 benachrichtigen Rechteinhaber MAPINET, das an die Behörde IGAC weiterleitet, und „IGAC then contacts Internet Service Providers (ISPs) to restrict access to the websites through \u0026lsquo;Domain Name System (DNS) blocking\u0026rsquo;“ binnen 15 Werktagen, ohne Gerichtsbeschluss.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nTorrentFreak — Italy Fines Cloudflare €14 Million for Refusing to Filter Pirate Sites on Public 1.1.1.1 DNS. Unter Italiens Piracy Shield ordnete AGCOM (Anordnung 49/25/CONS) DNS-Anbietern einschließlich Cloudflares öffentlichem Resolver das Sperren an; Cloudflare, das es „unreasonable and disproportionate“ nannte, weigerte sich und wurde mit €14,247,698 belegt, wogegen es Berufung einlegt.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nTorrentFreak — DNS Piracy Blocking Orders: Google, Cloudflare, and OpenDNS Respond Differently, 11. Mai 2025. Unter Canal+-Verfügungen zu Sport-Streaming in Frankreich und Belgien wurde den öffentlichen Resolvern das Sperren angeordnet: Cloudflare gibt ein HTTP 451 zurück, Google verweigert die Anfrage stillschweigend, und OpenDNS „pulled the plug“ in beiden Ländern, statt sich zu fügen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nTorrentFreak — Cloudflare Applauds Court for Rejecting DNS Piracy Blocking Order. In Universal Music v Cloudflare (dem DDL-Music-Fall) hatte eine untere Instanz Cloudflare das Sperren auf seinem 1.1.1.1-Resolver angeordnet; das Oberlandesgericht Köln lehnte es ab, die Pflicht auf den Resolver auszuweiten, der „contributes to the connection of internet domains in a purely passive, automatic and neutral manner“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nTorrentFreak — Dutch ISPs Must Block Pirate Bay Proxies and Mirrors Again, Court Rules, 15. Oktober 2020. BREIN hält eine „dynamische“ Sperranordnung gegen Ziggo, KPN und andere; das Gericht behandelt DNS-Sperren als „clear and verifiable“ Maßnahme, und neue Domains und Proxys werden auf Anfrage zur ISP-Sperrliste hinzugefügt.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nComplete Music Update — OpenDNS pulls plug on France and Portugal after web-blocking injunctions. Ciscos OpenDNS: „Due to a court order in France issued under the French Sport code and a court order in Portugal issued under the Portuguese Copyright Code, the OpenDNS service is not currently available to users in France [\u0026hellip;] and in Portugal.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nThe American Presidency Project — White House Fact Sheet: Directive to Prevent the Unfair Exploitation of American Innovation, 21. Februar 2025. Das Memorandum weist den US-Handelsbeauftragten an, Zölle als Antwort auf digitale Dienststeuern und Regulierungen anderer Länder zu erwägen, die der EU und des Vereinigten Königreichs eingeschlossen, gerahmt als ausländische Regierungen, die sich „America\u0026rsquo;s tax base“ aneignen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nA\u0026amp;O Shearman — FTC chairman warns major tech companies of censorship in EU DSA and UK Online Safety Act, zu Schreiben vom 21. August 2025: „Compliance with the requirements of non-US laws, such as the requirements in the EU Digital Services Act (DSA) and UK Online Safety Act, may result in companies censoring content“, was laut der Behörde mit US-Recht in Konflikt geraten könnte.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 9462 — Discovery of Designated Resolvers (DDR), November 2023. Definiert, wie ein Client „a resolver\u0026rsquo;s encrypted DNS configuration“ entdeckt und darauf umsteigt, indem er _dns.resolver.arpa nach dem Designated Resolver des Netzes abfragt.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMozilla — Canary domain — use-application-dns.net. „The canary domain only applies to users who have DoH enabled as the default option. It does not apply for users who have made the choice to turn on DoH by themselves.“ Eine andere Antwort als NOERROR mit einem A/AAAA-Record, etwa NXDOMAIN oder SERVFAIL, signalisiert Firefox, application DoH abzuschalten.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nGoogle — DnsOverHttpsMode policy. Werte off, automatic und secure; „If this policy is unset, for managed devices DNS-over-HTTPS queries will not be sent.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMozilla — Policy templates: DNSOverHTTPS. Enabled schaltet DoH ein oder aus, ProviderURL setzt den Resolver, Locked „prevents the user from changing DNS over HTTPS preferences“, ExcludedDomains und Fallback justieren den Rest.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\ndibdot/DoH-IP-blocklists — eine gepflegte Liste der Domainnamen und aufgelösten IPv4/IPv6-Adressen öffentlicher DoH-Server, zum Sperren in der Firewall; das Lookup-Skript „runs automatically every hour via GitHub actions“ und aktualisiert die Adresslisten, wenn sie sich ändern. jameshas/Public-DoH-Lists ist ein zweites, automatisch erzeugtes Äquivalent. Dass diese existieren müssen und laufend neu gescannt werden, ist der Punkt.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNCSC — Protective Domain Name Service (PDNS). „PDNS was built to hamper the use of DNS for malware distribution and operation [\u0026hellip;] a recursive resolver which prevents access to domains known to be malicious.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://blogs.damiendye.uk/de/dns/dns-over-https-walks-past-your-controls/","summary":"DNS over HTTPS verschlüsselt deine Auflösungen, was gut ist, und schickt sie an einen Resolver nach Wahl des Clients über Port 443, was das Problem ist. Dein eigener Resolver sieht die Anfrage nie, also verschwinden die Sperrliste, an der sie gescheitert wäre, der Threat-Feed, den sie getroffen hätte, und die Logzeile, die sie geschrieben hätte. Dieser Beitrag geht den Mechanismus durch: warum eine verschlüsselte Web-Verbindung unter Tausenden an der Grenze unsichtbar ist, wer auf einer Maschine einen Resolver wählen kann, den du nie gewählt hast (das OS, der Browser, jede App, jedes Skript auf jeder Webseite, und Malware), und die dokumentierten Fälle, vom eigenen JavaScript einer Seite, das einen öffentlichen DoH-Endpunkt abfragt, über Godlua und PsiXBot, die ihren Command-Kanal in DoH verstecken, bis zur OilRig-APT, die Daten darüber exfiltriert. Dann der Nachweis, dass die Privatsphäre-Geschichte eine Tarnung ist: DNS over TLS verschlüsselte DNS bereits 2016, auf einem Port, den der Netzbetreiber weiter regeln kann, sodass das Einzige, was DoH darüber hinaus bringt, das Aushebeln des Admins ist, weshalb die Browser-Hersteller, die es schrieben und auslieferten, und die Werbefirma, die den größten öffentlichen DoH-Resolver betreibt, die Gewinner sind. Dann die Lösung, die nicht darin besteht, Verschlüsselung zu verbieten. Betreibe deinen eigenen DoH- und DoT-Resolver, kündige ihn mit Discovery of Designated Resolvers an, weise Port 53, Port 853 und bekannte öffentliche DoH-Resolver an der Grenze ab, und beantworte die Firefox-Canary, damit der Browser sich zurückzieht. Behalte die Verschlüsselung. Hol dir zurück, wer den Resolver wählt. Er schließt mit den Folgen: Dieselbe DNS-basierte Durchsetzung läuft quer durch Europa und in Australien, und Gerichte in Italien, Frankreich, Belgien und Deutschland ordnen inzwischen den öffentlichen Resolvern selbst das Sperren an, wobei Cloudflare mit einer Strafe belegt ist und Berufung einlegt, Google stillschweigend verweigert und OpenDNS sich für ganze Länder abschaltet. Das Muster darunter ist ein US-Design, das der Welt aufgezwungen wird, und eine US-Regierung, die die Gesetze anderer Länder als Erpressung amerikanischer Firmen brandmarkt und ihnen rät, nicht zu befolgen.","title":"DNS over HTTPS spaziert glatt an deinen Kontrollen vorbei"},{"content":"Du klickst auf einen Link zu einer Lokalzeitung, und die Überschrift lädt, dann das Bild, dann die ersten drei Absätze, und du hast schon angefangen zu lesen, bevor sonst irgendwas passiert. Dann wird die Seite leer. Oder sie verwandelt sich in einen Haufen ungestylter Links, das Logo über die ganze Bildschirmbreite gezogen. Oder ein Kasten schiebt sich hoch und will, dass du entweder Tracking akzeptierst oder 2,99 £ im Monat zahlst, ohne dritten Knopf.\nDer Artikel war auf deinem Rechner. Der Server des Verlags hatte ihn schon komplett geschickt, Text und Stylesheets, und dein Browser hatte ihn schon gezeichnet. Weggenommen hat ihn Code, den der Verlag danach laufen lassen wollte, auf deinem Computer, eingekauft bei einem kommerziellen Anbieter, dessen Produkt darin besteht, zurückzunehmen, was gerade geliefert wurde.\nIch betreibe zu Hause ein Pi-hole1, das Werbe- und Tracking-Hosts für jedes Gerät im Netz blockiert. Auf einer wachsenden Liste britischer Nachrichtenseiten reichte das, damit die Seite zerstört wurde. Also habe ich am 22. September 2026 eine Chrome-Erweiterung gebaut, die das verhindert, sie heißt Keep The Page. Der Code liegt auf GitHub unter damo2929/browserplugin, MIT-lizenziert, und hier steht, was sie tut, was ich beim Bauen in diesen Seiten gefunden habe und welche Fixes es schlimmer machten, bevor der richtige auftauchte.\nSie ist kein Paywall-Umgeher. Wenn der Server den Artikel nie geschickt hat, zaubert hier nichts ihn herbei. Die Times blieb zu, und das ist richtig so. Behalten wird, was dir schon geschickt wurde.\nDer Artikel kommt an, dann ist er weg Von außen funktionieren alle gleich. Das HTML kommt vollständig an, und dann entscheidet ein Script, meist von einem Host des Anbieters statt der Zeitung geladen, dass du es nicht wert bist, und entfernt es.\nWas es entfernt, und wie, hängt davon ab, welchen Anbieter der Verlag gekauft hat. Diese vier sind mir begegnet, jeder beim Bauen von einer echten Seite abgelesen:\nVerlag Was ankommt Was die Seite dann mit sich selbst macht Newsquest (269 Titel)2 der ganze Artikel baut eine Wand, führt eine eval-Payload aus, öffnet einen confirm()-Dialog notebookcheck.net der ganze Artikel löscht \u0026lt;body\u0026gt; nach etwa 7 Sekunden, dann Dialoge, dann eine Reload-Schleife National World (The Scotsman, Yorkshire Post)3 der Artikel plus etwa 68KB eigenes CSS löscht alle 100ms jedes \u0026lt;link\u0026gt; und \u0026lt;style\u0026gt;, für immer Reach plc (Mirror, Daily Record, Manchester Evening News, Liverpool Echo und andere)4 der ganze Artikel deckt ihn mit „Tracking akzeptieren oder 2,99 £/Monat zahlen“ zu Die 269 stammen nicht aus einer Pressemitteilung, die spricht von „mehr als 200 Marken“. Es ist die Zahl der Domains auf Newsquests eigenen TLS-Zertifikaten, die Liste, die die Erweiterung brauchte, um zu wissen, wo sie laufen soll.\nDer Fall National World sollte Verlage am meisten beunruhigen, weil er die Seite aus Gründen kaputt macht, die mit Werbung nichts zu tun haben. Der Stylesheet-Stripper hat einen Partner, der das CSS vom Host des Anbieters zurückholt. Mein Pi-hole blockiert diesen Host. Also lief das Entfernen, das Zurückholen kam nie, und das eigene Layout der Zeitung hing dauerhaft davon ab, dass ein Werbeanbieter erreichbar ist. Das ist keine Wand. Das ist ein Verlag, der das Aussehen seiner eigenen Website einem Dritten überlässt und es nicht merkt.\nDarf ich fragen, warum das Stylesheet einer Zeitung auf den Server einer Werbefirma warten muss, bevor es auf der Seite bleiben darf? Für den Leser gibt es dafür keinen Grund. Keinen.\nWarum ich es Malware nenne Ich benutze das Wort mit Absicht, als Beschreibung dessen, was der Code tut, und nicht als juristisches Urteil über irgendwen. Die Anti-Adblock-Payloads erfüllen die gewöhnliche Bedeutung in vier Punkten, und jeder wurde direkt beobachtet:\nKriterium Was ich gesehen habe Läuft ohne Einwilligung, gegen dein Interesse niemand hat darum gebeten, und seine Aufgabe ist, dir Inhalt wegzunehmen, den du schon hast Zerstört Daten, die dir schon geliefert wurden Artikel und CSS kommen intakt an, dann löscht Code in der Seite sie Verschleiert gegen das Lesen permutierte String-Tabellen wie o[293 * (r + 450) % e], ausgeführt über eval Umgeht Blockieren und bestraft Eingriffe CNAME-Cloaking gegen DNS-Blocklisten, Anti-Tamper-Prüfungen, die zu einem Dialog oder einer Reload-Schleife eskalieren Die Verschleierung ist keine Minifizierung. Minifizierter Code ist klein. Das hier ist Code, der so angeordnet ist, dass du nicht mit grep finden kannst, was er tut, und die Payload läuft dann durch eval, damit nichts auf der Platte zu dem passt, was ausgeführt wird.\nDas Cloaking ist eine bekannte Technik mit eigener Forschungsliteratur5. Der Loader wird von etwas geholt, das wie eine Subdomain der Zeitung aussieht, und dieser Name löst zum Anbieter auf:\na02342.\u0026lt;publisher-domain\u0026gt; -\u0026gt; cdn-52-x.privacy-mgmt.com (Sourcepoint) fb.html-load.com -\u0026gt; adshield-fallback-dev-wskxz.b-cdn.net Die Subdomain ist pro Titel zufällig. Eine Blockliste, die Hosts benennt, kommt da nicht hinterher, und genau darum geht es.\nUnd der Code behandelt jeden Eingriff als Schuldbeweis. Die entschlüsselten Fehlertexte in der Payload, die Pflegende von Filterlisten Ad-Shield zuschreiben6, lauten wörtlich Vital API blocked und Vital API blocked (eval). Sourcepoints Loader schreibt ein Attribut, liest es sofort zurück und wirft einen Fehler, wenn sich der Wert geändert hat:\nz.call(O,\u0026#39;src\u0026#39;,G), O[x](\u0026#39;src\u0026#39;) !== G \u0026amp;\u0026amp; throw E … catch (W) { try { await l(W) } catch (x) { o(W) } } // o() raises the dialog Sourcepoint hat das offen verkauft. In der eigenen Dokumentation stand „on average about 30% of messaged users will turn off their adblockers“7. Ich beschreibe also kein Schurken-Script, das jemand eingeschmuggelt hat. Es ist ein Produkt, vom Verlag gekauft und absichtlich eingesetzt.\nDie Consent-or-Pay-Wände sind eine andere Kategorie, und die nenne ich nicht Malware. Sie zerstören nicht, was geliefert wurde, und sie verstecken sich nicht vor Blocklisten. Sie üben auf andere Weise Zwang aus, und darum geht es im nächsten Abschnitt.\n1.467 Partner akzeptieren oder 2,99 £ zahlen Die Wand auf den Reach-Titeln ist Quantcast Choice, inzwischen von InMobi betrieben8 und von cmp.inmobi.com ausgeliefert. Sie bietet zwei Möglichkeiten. Akzeptieren oder 2,99 £ im Monat zahlen. Ein kostenloses „Nein“ gibt es nicht.\nWer akzeptiert, teilt seine Daten mit 1.467 aufgeführten Partnern und bekommt ein euconsent-v2-Cookie, das 13 Monate hält. Niemand liest eine Liste von 1.467 Firmen, niemand könnte abwägen, was jede davon mit den Daten machen würde, selbst wenn er sie läse, und die Zahl allein sagt dir, was für eine Einwilligung hier verlangt wird.\nDie britische DSGVO sagt, dass eine Einwilligung freiwillig sein muss, und dass man bei der Beurteilung darauf schaut, ob der Dienst von einer Einwilligung in Verarbeitung abhängig gemacht wurde, die er gar nicht braucht9. Das ICO hat Leitlinien veröffentlicht, nach denen Consent or Pay rechtmäßig sein kann10, Leitlinien, die es inzwischen als in Überprüfung bezeichnet, und der Europäische Datenschutzausschuss hat gesagt, dass es bei großen Plattformen, die nur diese zwei Optionen anbieten, in den meisten Fällen nicht rechtmäßig sein wird11. Ich werde nicht so tun, als hätte die Aufsicht es verboten. Hat sie nicht.\nAlso, hier lande ich, ganz offen. Ich habe mich entschieden, die Wand zu entfernen und die Einwilligung zu verweigern. Das heißt, ich lese den Artikel auf dem kostenlosen Zweig, ohne zu zahlen und ohne meine Daten an 1.467 Firmen zu geben. Das ist eine Entscheidung. Die Erweiterung sagt das auf ihrer eigenen Einstellungsseite, und ich verkleide es nicht als etwas Neutrales. Eine Einwilligung, die du nicht verweigern kannst, ist ein Preis, und ich zahle keinen Preis, der als Frage verkleidet ist.\nDen Kasten zu entfernen ist das leichte Drittel. Die anderen zwei Drittel stehen in Die Einwilligungsfrage richtig beantworten, denn ein Banner, das du löschst, ohne zu antworten, kommt jedes Mal wieder.\nEin Tag, acht Commits Das Ganze wurde an einem Tag gebaut. Erst ein paar Stunden Herumstochern in Seiten, bevor irgendwas committet wurde, dann acht Commits zwischen 20:32 und 22:50. Ich habe es mit Claude Code gebaut, und viel von der Knochenarbeit, verschleiertes Inline-Script Zeile für Zeile zu lesen, hat der Agent gemacht, während ich zugesehen habe, was die Seiten auf dem Bildschirm taten. Diese Arbeitsteilung hat gut funktioniert, und wo sie schiefging, steht weiter unten, weil sie auf eine Art schiefging, die man kennen sollte.\nUhrzeit Commit 20:32 erster Commit: Newsquest, notebookcheck, National World, Reach, Page Six 20:46 der Anbieter hinter jedem Mechanismus, ins README geschrieben 20:56 50 Links von der Google-News-Startseite, als nicht ausgesuchte Stichprobe 21:02 die Consent-API beantworten, jeder Zweck abgelehnt 21:11 Social-Links entschärft 22:50 abschaltbare Schutzfunktionen, MSN und Bing, Ablehnen per Klick, 77 Tests Es ist eine Manifest-V3-Erweiterung mit zwei Berechtigungen, declarativeNetRequest und storage, ohne Host-Berechtigungen und ohne eigenen Netzzugang, sie kann also nichts abrufen, keine Antwort umschreiben und mit keinem Server für dich reden. Diese Einschränkung hat das Design mehr geprägt als alles andere, weil die interessante Arbeit in der Seite passieren muss.\nZwei Welten, ein Attribut nach unten und ein Event nach oben Der Code der Seite und die Einstellungen der Erweiterung leben in verschiedenen Welten Erweiterungsspeicher chrome.storage.local Schutzfunktionen Tracing-Kanäle Social-Einstellungen letzte 50 Fehler gelesen und geschrieben von der Einstellungsseite Isolierte Welt bridge.js social.js portal.js kann chrome.storage lesen kann die Funktionen der Seite nicht anfassen Welt der Seite (MAIN) walls.js guard.js portal-early.js umhüllt setTimeout, cookie, __tcfapi, window.adLight gar kein chrome.* Nach unten: ein Attribut am html-Element, nur was aus ist \u0026lt;html data-ktp-off=\"cookies,dom\"\u0026gt; Standardinstallation: nichts geschrieben Nach oben: ein ktp-report-Event detail: ein JSON-String ein Objekt kommt nicht zuverlässig an Chrome führt Erweiterungs-Scripts in zwei Welten aus. Die Welt der Seite erreicht das JavaScript der Seite, hat aber keine Erweiterungs-APIs. Die isolierte Welt kann Einstellungen lesen, aber die Funktionen der Seite nicht anfassen. Alles wandert zwischen ihnen als Attribut nach unten und als Event nach oben. Chromes MAIN-Welt teilt sich die JavaScript-Umgebung der Seite12. Ein Script dort kann setTimeout ersetzen, document.cookie umhüllen oder window.adLight definieren, bevor die Seite es tut, und genau das braucht man gegen diese Wände. In der Praxis kann es chrome.storage nicht aufrufen. Die isolierte Welt kann das, sieht aber die Funktionen der Seite nicht. Also liest eine kleine Brücke die Einstellungen und schreibt sie auf \u0026lt;html\u0026gt;, und Fehler kommen als CustomEvent zurück, dessen Detail ein JSON-String ist, weil ein Objekt diese Grenze nicht zuverlässig überquert.\nDas Attribut nach unten listet nur, was du abgeschaltet hast. Eine Standardinstallation schreibt überhaupt nichts in die Seite. Das zählt, weil eine dauerhafte Markierung auf \u0026lt;html\u0026gt; genau das ist, wonach diese SDKs suchen, und weil ein Speicherfehler dadurch in Richtung Schutz der Seite ausfällt statt davon weg.\nFinde das Tor, bekämpfe nicht die Wand Der Newsquest-Fix sind zwei Zeilen Überlegung, und an ihm wurde alles andere gemessen.\nIhre ganze Wand hängt an einem Flag in der Seite:\nvar adLight = false; // line 1647 if (adLight !== true) { …} // line 2020: loader, eval payload, confirm() adLight ist das Abonnenten-Flag für „wenig Werbung“. Ist es wahr, entsteht die Wand nie. Also definiert die Erweiterung window.adLight bei document_start als true, bevor das eigene Script der Seite läuft, mit einem Setter, der ignoriert, was hineingeschrieben wird:\nObject.defineProperty(window, \u0026#39;adLight\u0026#39;, { configurable: false, enumerable: true, get() { return true; }, set() { /* ignore the page\u0026#39;s \u0026#34;false\u0026#34; */ } }); Ein var oben in einem Script definiert eine Eigenschaft, die das globale Objekt schon hat, nicht neu. Es weist ihr nur einen Wert zu13. Also läuft das var adLight = false der Seite, landet im Setter und bewirkt nichts. Der Loader der Wand startet nie, die eval-Payload kommt nie an, und es gibt keine Anti-Tamper-Prüfung, die anschlagen könnte, weil nichts manipuliert wurde. Das Flag hat einfach Ja gesagt.\nDas ist die einzige Eigenschaft in der ganzen Erweiterung, die nicht konfigurierbar ist. Sie muss es sein, um die Deklaration zu überleben. Alles andere ist configurable: true, damit keiner Seite je eine ihrer eigenen APIs für immer weggenommen wird.\nEs deckt 269 Titel ab und lässt sich in den Einstellungen nicht abschalten, und die sagen auch warum: Es läuft, bevor chrome.storage antworten kann, und einmal gesetzt lässt es sich nicht rückgängig machen. Eine Checkbox wäre Dekoration.\nJeder Fix, der es schlimmer machte Das ist der nützliche Abschnitt, weil jeder Fehler hier das Naheliegende ist, das man probiert.\nWas ich probiert habe Was passiert ist Den Host des Loaders blockieren der Host ist pro Titel ein zufälliger First-Party-CNAME, und ein fehlgeschlagener Abruf ist selbst das Erkennungssignal setAttribute bei eingefügten Scripts bewachen löste Sourcepoints Rücklese-Prüfung aus, die genau den Dialog öffnete, den es verhindern sollte Den confirm() mit Abbrechen beantworten in diesem SDK heißt Abbrechen neu laden, also eine endlose Reload-Schleife \u0026lt;body\u0026gt; bei DOMContentLoaded sichern, um es später wiederherzustellen die Wand leert schon beim Parsen, die Sicherung war also von einem leeren Body remove() und removeChild() bewachen die Wand räumt die Seite mit einem einzigen innerHTML = '' ab, nicht Knoten für Knoten Alles auf einmal bewachen, bei notebookcheck die Wand eskalierte zu einem Dialog, dann zu einer Reload-Schleife, klar schlimmer als gar nichts zu tun Den Anbieter-Host auf einen lokalen Stub umleiten eine redirect-Regel mit nur declarativeNetRequest machte das ganze Regelwerk ungültig und tötete still die Newsquest-Regel auf 269 Seiten Die Seiten-Wächter auf jeder Seite laufen lassen patchte globale Prototypen auf jeder Seite, die ich besuchte, auch bei meiner Bank Die Umleitung lohnt einen zweiten Blick. Chrome gibt einer block-Regel impliziten Zugriff und will für alles darüber hinaus eine Host-Berechtigung14. Laut Dokumentation werden ungültige statische Regeln ignoriert15. Was ich gesehen habe, war schlimmer: Die ganze Datei war weg, ohne Fehler auf der Seite, und Regel 1 existierte auf 269 Seiten einfach nicht mehr. Die zwei Regeln für MSN liegen deshalb jetzt in einem eigenen Regelwerk, damit eine schlechte Änderung an einem nicht das andere mitreißt.\nDie Reload-Schleife hat die andere harte Regel gelehrt. location.reload lässt sich nicht abfangen. Das Location-Objekt ist im HTML-Standard unfälschbar16, seine Methoden sind also weder beschreibbar noch konfigurierbar, und der Versuch liefert:\nObject.defineProperty(location,\u0026#39;reload\u0026#39;,...) -\u0026gt; TypeError: Cannot redefine property: reload Eine Wand, deren Fehlerpfad „Seite neu laden“ heißt, lässt sich nicht mehr aufhalten, sobald sie auf diesem Pfad ist. Durch nichts. Der einzige Fix ist, dafür zu sorgen, dass sie nie dort ankommt. Das ist dieselbe Lektion wie bei adLight, auf die schmerzhafte Art gelernt: Jeder Versuch, eine schon laufende Wand zu bekämpfen, machte es schlimmer, und jeder Fix, der funktionierte, hielt die Wand vom Starten ab.\nEin Timer richtete den Schaden an notebookcheck hat kein adLight. Die Wand läuft immer. Mit eingeschaltetem Tracing zeigte die Erweiterung, was sie einplante:\ndropped setTimeout(7005ms) scheduled from eval \u0026lt;- the body.remove() dropped setTimeout(1251ms) / 105ms / 0ms x8 dropped setInterval(15000ms) Einer dieser Timer richtet den ganzen Schaden an: der nach 7 Sekunden, der \u0026lt;body\u0026gt; entfernt. Alles danach ist Reaktion, denn die leere Seite wirft einen Fehler, die Ausnahme öffnet den Dialog, der Dialog lädt die Seite neu, und das Ganze fängt mit einem frischen Satz Timer wieder von vorn an.\nAlso ist der Fix eine einzige Regel. Verwirf einen Timer, wenn er aus eval-Code geplant wurde, die Seite die Signatur dieses SDK trägt und der Handler eine Funktion ist. Der Stack verrät, woher ein Aufruf kam, und eval hinterlässt darin seine Spur.\nbefore: 4 page loads, 3 confirms, reload loop after: 1 page load, 0 confirms, alive 40,378ms, content intact Ein Timer, und alles, was daraus folgt notebookcheck: ein Timer richtet den Schaden an, der Rest ist Reaktion Wie ausgeliefert Artikel und CSS da, gezeichnet Loader von html-load.com eval-Payload plant Timer 7,0s: Timer läuft body.remove() leere Seite wirft, confirm() geöffnet Seite lädt neu und beginnt neu 4 Seitenaufrufe, 3 Dialoge, Reload-Schleife Mit der Erweiterung Artikel und CSS da, gezeichnet Loader von html-load.com eval-Payload plant Timer jeder eval-Timer sofort verworfen 1 Aufruf, 0 Dialoge, nach 40 Sekunden am Leben notebookcheck ohne und mit der Erweiterung. Nichts hinter dem 7-Sekunden-Timer muss repariert werden, weil nichts davon passiert, sobald dieser Timer verworfen ist. Zu dem Zeitpunkt steckten noch zwei andere Mechanismen im Build, eine Umleitung des Loaders auf einen Stub und ein Köder-Element, das die Schreibzugriffe der Wand auffing. Beide funktionierten, und beide behandelten Symptome dieses einen Timers, was erst klar wurde, als die Timer-Regel allein getestet wurde und sich als ausreichend herausstellte. Also flogen beide raus, und mit ihnen verschwanden eine Berechtigung und jede Host-Berechtigung. Teste immer, ob die letzte Änderung allein reicht, bevor du das Gerüst drumherum behältst.\nDie Signatur ist das data-sdk-Attribut am Loader-Tag, und sie passt auf eine Form, l/\u0026lt;n\u0026gt;.\u0026lt;n\u0026gt;, statt auf eine Version. An einem Tag tauchten drei Versionen auf. Sie rastet ein und merkt sich nie ein Negativ, weil das Loader-Tag vielleicht noch nicht geparst ist, wenn die ersten Timer geplant werden, und ein gemerktes „Nein“ würde sie auf einer Seite, die die Wand trägt, für immer entschärfen.\nDie Messung sagte gut. Der Bildschirm nicht. The Scotsman und die Yorkshire Post galten als repariert, auf Grundlage einer Messung, die Text zählte. Die Seite hatte 8.808 Zeichen davon, 22 Elemente unter \u0026lt;body\u0026gt;, stabil nach 2, 8 und 16 Sekunden. Nach diesem Maßstab war sie intakt.\nWar sie nicht. Ich habe sie mir angesehen, und jedes Stylesheet war weg, die Links waren eine rohe Liste, das SVG-Logo füllte den Bildschirm, und es gab eine horizontale Scrollleiste. Alle Wörter waren da, und mehr konnte diese Messung nicht sehen. Ich musste auf den Bildschirm zeigen und es sagen.\nWas die Messung maß, und was auf dem Bildschirm war Yorkshire Post vor dem Fix: dieselbe Seite, auf zwei Arten gemessen Was die Messung maß innerText.length8.808 Kinder von body22 nach 2s, 8s, 16sunverändert Urteil: intakt Was auf dem Bildschirm war document.styleSheets.length0 Links als rohe Liste, Logo volle Breite, eine horizontale Scrollleiste Urteil: kaputt Nach dem Verwerfen des Strippers beim Einplanen: 2 Stylesheets, 532 Regeln, die Seite rendert Dieselbe Seite, auf zwei Arten gemessen. Die Textlänge sagte, die Seite sei gesund. Die Zahl der Stylesheets sagte, sie sei kaputt, und die Zahl der Stylesheets hatte recht. Die Ursache war der Stripper aus der ersten Tabelle, und er passte nicht auf die Timer-Regel, weil er ein gewöhnliches Inline-Script ist und kein eval. Also ist sein eigener Quelltext die Signatur: ein wiederholter Job, dessen Rumpf querySelectorAll('link,style') und dann remove() aufruft. Nichts Legitimes tut das. Er wird beim Einplanen verworfen, nichts wird je entfernt, und nichts muss wiederhergestellt werden. Die Yorkshire Post ging von 0 Stylesheets auf 2, mit 532 Regeln, und sie wurde gerendert.\nUm ihn zu finden, brauchte es einen Stacktrace, kein Raten. Patch Element.prototype.remove so, dass es den Stack protokolliert, sobald ein STYLE oder LINK entfernt wird, und es nannte das Inline-Script und das forEach beim ersten Versuch.\nDanach kam document.styleSheets.length in jede Prüfung. Eine Seite ohne Stylesheets ist kaputt, egal wie viel Text sie hat. Messen ist schwieriger, als man denkt, und das sind die Fallen, in die der Build an dem Tag getappt ist:\nFalle Was sie sagte Was stimmte Textlänge als Render-Prüfung „intakt“ ungestyltes Markup eine Stichprobe nach dem Laden Reach-Wände auf acht Titeln „nicht vorhanden“ die Wand lebt etwa 600ms und war schon weggeräumt leere Konsole nach der Navigation „der Wächter feuert nicht“ Meldungen beim Laden überleben die Navigation nicht Stichproben nach 1s und 4s notebookcheck gesund es leert nach 5 bis 8 Sekunden cssRules über Origins hinweg gezählt ESPN hatte 5 Regeln Cross-Origin-Sheets werfen Fehler, also zählen sie zu niedrig Der Fix für den 600ms-Fall ist, ab dem Laden der Seite alle 100ms abzufragen. Bei Wales Online erschien die Wand nach 425ms und war nach 1.129ms weg.\nDann wurden die Prüfungen ernsthaft durchgezogen. 52 Artikel auf 26 Domains, zwei pro Seite, so ausgesucht, dass jeder Mechanismus vorkommt: 52 von 52 mit Stylesheets, keine Wand auf dem Bildschirm übrig, keine Reload-Schleifen. Dann 50 Links direkt von der britischen Google-News-Startseite, nicht von mir ausgesucht: 45 normal gerendert, 2 waren Hosts, die mein Pi-hole absichtlich blockiert, 1 war die echte Paywall der Times, und 2 waren derselbe Artikel, zweimal gelandet, weil Google die Reihenfolge der Links bei jedem Laden neu aufbaut. Keine mit null Stylesheets. Drei National-World-Titel, die ich nie getestet hatte, tauchten in diesem Lauf mit demselben SDK auf, und alle drei wurden gerendert, und genau dafür passt man auf eine Form statt auf eine Liste von Seiten.\nEs gibt 77 Unit-Tests, im Repository mit allem anderen. Auf diesem Rechner gibt es kein Node, also laufen sie auf gjs und laden das echte walls.js gegen ein Ersatz-DOM, damit die Muster aus der Produktion getestet werden. Jeder wurde geprüft, indem das, was er bewacht, kaputt gemacht und zugesehen wurde, wie er rot wird. Sie testen nur Entscheidungen. Dass sie bestehen, heißt nicht, dass eine Seite rendert, und der Scotsman ist der Grund, warum dieser Satz im README steht.\nDie Einwilligungsfrage richtig beantworten Ein Consent-Banner zu löschen lässt die Frage unbeantwortet. Das hat zwei Folgen, und die erste ist, dass das Banner bei jedem Seitenaufruf neu gebaut wird. Und ein Verlag, der seinen Inhalt zurückhält, bis die Consent-API antwortet, hängt einfach fest, während ein Anbieter ohne Antwort die Frage als nie gestellt behandeln kann. Schweigen ist keine Ablehnung.\nAlso beantwortet die Erweiterung sie, in dieser Reihenfolge:\nAblehnen, Nein sagen, nichts speichern, erst dann entfernen Ein Consent-Banner wird beantwortet, nicht nur gelöscht Der Container eines Consent-Anbieters ist sichtbar #qc-cmp2-container #onetrust-consent-sdk sp_message_container 1. Ihre Ablehnung drücken Reject all, Decline, Only essential, Continue without accepting nur ganze Beschriftung, max. 40 Zeichen passt auf Accept: der Build scheitert 2. Der API antworten: Nein __tcfapi jeder Zweck, jede Funktion und jeder Anbieter abgelehnt tcString \"\" tcloaded 3. Datensatz nie speichern euconsent-v2 addtl_consent OptanonConsent didomi_token cookie und localStorage Schreibzugriffe verworfen Beim nächsten Tick noch sichtbar? ja: entfernen, Scrollen freigeben nein: die Ablehnung gilt Drei Antworten und ein Rückfall. Der Ablehnen-Knopf wird gedrückt, wenn es einen gibt, der Consent-API wird zu allem Nein gesagt, der Datensatz wird nie gespeichert, und nur ein Banner, das beim nächsten Tick noch steht, wird entfernt. Zuerst drückt sie deren Ablehnen-Knopf. Nur Knöpfe, deren ganze Beschriftung eine Ablehnung ist: „Reject all“, „Decline“, „Only essential“, „Continue without accepting“ und ein paar mehr, jeweils verankert, alles über 40 Zeichen wird ignoriert. Ein Unit-Test füttert sie mit „I Accept“, „Accept All“, „Agree and close“, „Allow all“, „Got it“, „Subscribe“ und „Pay £2.99/mo“ und lässt den Build scheitern, wenn eines davon passt. Den falschen Knopf zu drücken hieße, in deinem Namen einzuwilligen, und das ist das Einzige, was dieses Projekt nie tun darf. Auf msn.com hat „Reject All“ Microsofts Banner verschwinden lassen, und es kam nach dem Neuladen nicht wieder, weil Microsoft die Ablehnung auf den eigenen Servern speichert.\nSie beantwortet die Consent-API mit Nein. Das Framework des IAB gibt jeder einwilligenden Seite eine Funktion namens __tcfapi, um zu fragen, wozu du zugestimmt hast17. Wo es eine gibt, beantwortet die Erweiterung sie mit jedem Zweck, jeder besonderen Funktion und jedem Anbieter abgelehnt, einem leeren Consent-String und eventStatus: 'tcloaded', was heißt, die Antwort ist endgültig. Sie erscheint nur, wo schon ein Consent-Framework auf der Seite ist, eine Seite, die nie gefragt hat, sieht sie also nicht.\nSie speichert den Datensatz nie. document.cookie und localStorage verwerfen still euconsent-v2, addtl_consent, OptanonConsent, didomi_token und den Rest, sodass eine Einwilligung, die du nie gegeben hast, nie geschrieben und auf der nächsten Seite nie an 1.467 Partner weitergespielt wird. Britisches Recht verlangt dafür ohnehin eine Einwilligung, bevor etwas auf deinem Gerät gespeichert wird18. Die Erweiterung setzt das Nein durch.\nJeder Name auf dieser Liste ist an beiden Enden verankert, und dahinter steckt eine Geschichte. Sourcepoints Cookies beginnen mit _sp_. Ein schlampiges Muster sp_ trifft auch Spotifys sp_dc und sp_t, also die Login-Sitzung, und hätte mich auf jeder Seite bei Spotify abgemeldet. Auch das hält ein Test fest.\nEntfernen ist der Rückfall. Nur für ein Banner, das nach dem Klick noch auf dem Bildschirm ist, und nur für ein Banner, das tatsächlich angezeigt wird. Mehrere Anbieter lassen eine dauerhafte Hülle in der Seite, ob ein Banner da ist oder nicht. euronews hält einen Didomi-Host mit Höhe null bereit, und den herauszureißen macht die Seite ohne jeden Gewinn kaputt. Das Reach-Banner saß drei Ebenen unter \u0026lt;body\u0026gt; in zwei Hüllen, die selbst nicht fixiert sind, also muss die Prüfung bis zu dem Kasten hinuntergehen, der es ist.\nTeilen-Knöpfe und ein Portal, das seine eigenen Einstellungen ignoriert Zwei weitere Dinge auf diesen Seiten sind dazu da, jemand anderem als dem Leser zu dienen, und sie brauchten eine andere Behandlung als die Wände.\nTeilen- und Folgen-Knöpfe. Jeder Link zu Facebook, Instagram, X, TikTok oder LinkedIn wird auf http://localhost/removeme umgeschrieben, das Original in einem Attribut geparkt, damit nichts verloren geht. Dann löscht ein zweiter Durchgang, was eindeutig Mobiliar ist (ein Icon ohne Text, „Share on X“, alles in einem Container, der sich share oder social nennt), und versteckt den Rest. Die Markierung ist da, damit ein einziger Selektor alles zeigt, was gleich verschwindet, und ein Nur-Markieren-Modus hört nach dem ersten Durchgang auf, damit du nachsehen kannst, bevor du ihr auf einer Seite vertraust.\nDie naive Version macht Seiten auf drei Arten kaputt, und jede ist jetzt ein Test:\nNaive Version Was sie kaputt macht Was stattdessen passiert a[href*=\u0026quot;x.com\u0026quot;] trifft auch netflix.com, linux.com, phoenix.com den Host parsen und ganze Labels vergleichen jeden Social-Link entfernen „Continue with Facebook“ verschwindet, und Leute sind ausgesperrt Login-, OAuth-, Rechts- und Entwickler-Links bleiben in Ruhe einen Link in einem Satz entfernen die Wörter gehen mit standardmäßig verstecken, eine Option löst ihn auf und behält die Wörter Das Letzte ist ein Kompromiss, den ich bewusst eingegangen bin. Eine BBC-Schlusszeile liest sich damit als „follow BBC Manchester on , , and .“. Ich habe mir das angesehen und trotzdem das Verstecken gewählt. Die Option, die Wörter zu behalten, ist für alle da, die das anders sehen.\nMSN und Bing. Beide laufen auf denselben Web Components, etwa 160 Shadow Roots auf der Startseite. Eine einfache Abfrage des Dokuments fand 1 Link. Das Durchlaufen der Shadow Roots fand 73, darunter die Facebook- und X-Kacheln. Was sie nicht durchläuft, sieht fast nichts davon.\nMSN hat durchaus eigene Inhaltseinstellungen. Die liegen auf Microsofts Servern, an eine anonyme ID gebunden, nicht in einem Cookie, also sind sie nach dem Löschen der Cookies, in einem neuen Profil und im Inkognito-Modus weg. Bei Bing kommen sie überhaupt nicht an. Und mit allen abgeschaltet und nach 11.700 Pixeln Scrollen war das hier noch im Feed:\nMSNs eigener Schalter, aus Noch auf der Seite Casual Games die Spiele-Kachel Shopping Werbekacheln für Booking, Temu und eBay Comments 501 Kommentar-Links Weather, Finance, Sports weg, bis zum nächsten Cookie-Löschen Ein Schalter namens Comments, der 501 Kommentar-Links auf der Seite lässt, ist eine Behauptung gegenüber dem Nutzer, und eine falsche. Also nimmt die Erweiterung sie selbst heraus, anhand von MSNs stabilen Komponentennamen statt der Klassennamen, die sich mit jedem Build ändern.\nEine Sache, die ich dort gelernt habe und die weit über MSN hinaus gilt: Ein Bild aus der Seite zu entfernen, hält es nicht vom Laden ab. Chrome startet den Abruf, sobald src gesetzt wird, selbst bei einem Bild, das nie in die Seite eingefügt wird19. Bis ein Content-Script eine Karte sieht, ist ihr Vorschaubild schon unterwegs. Also werden die Feed-Daten an den zwei Endpunkten blockiert, die sie ausliefern, und nie die Bild-Hosts, weil th.bing.com auch die Bing-Bildersuche ausliefert.\nUnd der MSN-Feed blitzt immer noch kurz auf dem Bildschirm auf, bevor er verschwindet. Vier Versuche, ihn früher zu verstecken, maßen alle als funktionierend, und keiner stoppte das Aufblitzen, was heißt, dass das, was gezeichnet wird, nicht das ist, was die Erweiterung versteckt. Die Einstellungsseite sagt das offen. Lieber sagt sie das, als ein sauberes Laden anzudeuten, das sie nicht liefert.\nWas sie nicht tut Sie wird nicht Weil eine echte Paywall öffnen wenn der Server den Artikel zurückhält, bleibt er zurückgehalten bei einer Seite raten eine Domain kommt erst rein, wenn ihre Wand dort gesehen wurde; zwei News-Corp-Seiten, von denen angenommen wurde, sie glichen Page Six, taten es nicht und flogen wieder raus eine Seite ohne Signatur anfassen bei der BBC ist jeder Hook installiert und nichts wird protokolliert, kein Timer verworfen, kein Knoten angefasst nach Hause telefonieren keine Host-Berechtigungen, kein Netzzugang, keine Telemetrie; das Fehlerprotokoll bleibt in deinem Browser so tun als ob das MSN-Aufblitzen ist ungelöst, und eine Ad-Shield-Variante, wp-ls/…, passt noch nicht; ihre Seite rendert einwandfrei, also ist das aufgeschrieben statt auf Verdacht repariert Eine Seite, die dir geschickt wurde, gehört dir Sobald ein Server deinem Browser eine Seite geschickt hat, liegt diese Kopie auf deinem Rechner. Danach Code darauf laufen zu lassen, um sie wieder wegzunehmen, ist kein Geschäftsmodell, das ich anerkenne. Es ist der alte Trick, dir etwas zu verkaufen und die Hand darauf zu behalten.\nZeitungen waren früher etwas, das man kaufte und dann besaß: jemand an der Straßenecke hatte einen Stapel, du gabst das Geld, und sie ging mit dir nach Hause und gehörte dir, zum Lesen, Falten, Verleihen oder zum Feuermachen. Niemand kam eine Stunde später vorbei, um die zweite Seite herauszuschneiden, weil du die Anzeigen übersprungen hattest. Die Web-Version hat die Zeitung umsonst hergegeben und dann den Leser verkauft. Erst an die Werbekunden, dann an die 1.467 Partner, und jetzt an einen Anbieter, dessen ganzes Produkt darin besteht zu entscheiden, ob du dich gut genug benommen hast, um zu behalten, was dir gegeben wurde.\nWorüber ich nicht hinwegkomme, ist das Stylesheet. Eine Zeitung, die den Server einer Werbefirma entscheiden lässt, ob ihr eigenes Layout überlebt, hat ihre eigene Titelseite weggegeben. Sie wird es nicht gewusst haben, weil drinnen niemand den Host blockiert hat, also war der Erste, der es merkte, ein Leser mit einem Pi-hole, der auf eine Seite voller roher Links starrte und von einem Dialogfenster gesagt bekam, der Fehler liege bei ihm. Tat er nicht.\nJournalismus hat einen Preis, und den zahle ich ohne Weiteres. Was ich nicht tue, ist ein Script entscheiden zu lassen, was ich schon habe. Diese Linie wird in meinem Browser gezogen, nicht in ihrem.\nPi-hole documentation — „The Pi-hole® is a DNS sinkhole that protects your devices from unwanted content, without installing any client-side software.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNewsquest — About us — „We are the leading local news publisher in the UK with a portfolio of more than 200 brands.“ Marken sind keine Domains, daher die höhere Zahl von den Zertifikaten.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nDaily Business, 18. Dezember 2024 — „National World, owner of The Scotsman and Yorkshire Post, has reached agreement on a £65.1 million takeover by Irish publisher Media Concierge.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nReach plc — About us, archiviert am 5. September 2026 — „120+ brands, from household names like the Mirror, Express, Daily Record and Daily Star, to local titles like MyLondon, BelfastLive and the Manchester Evening News“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nDimova et al., „The CNAME of the Game: Large-scale Analysis of DNS-based Tracking Evasion“, PETS 2021 — CNAME-Cloaking „effectively bypasses antitracking measures that rely on fixed hostname-based block lists.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nuBlockOrigin/uAssets Issue #30988, von den Pflegenden unter dem Label „Ad-Shield“ geführt, mit der von error-report.com ausgelieferten Meldung: „Failed to load website properly since html-load.com is blocked.“ Siehe auch Jacob Desforges, „Ad-Shield ad reinsertion“, 12. April 2026. Die Zuordnung stammt aus der Filterlisten-Community; der Anbieter legt nichts offen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nSourcepoint — Anti-adblock FAQs, archiviert am 25. Mai 2022 — „Historical experience shows on average about 30% of messaged users will turn off their adblockers.“ Dieselbe Seite fragt, ob „a CNAME applied to a 1st-party subdomain“ das Blockieren des Erkennungs-Scripts verhindern würde.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nAdExchanger, 16. August 2023 — „InMobi acquired Quantcast’s consent management platform, called Quantcast Choice“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nUK GDPR, Article 7 — „utmost account shall be taken of whether, inter alia, the performance of a contract, including the provision of a service, is conditional on consent“. Erwägungsgrund 42: Einwilligung ist nicht freiwillig, „if the data subject has no genuine or free choice“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nICO — Consent or pay, veröffentlicht am 23. Januar 2025 — „“Consent or pay” models can be compliant with data protection law if you can demonstrate that people can freely give their consent“. Die Seite sagt inzwischen, dass die Leitlinien nach dem Data (Use and Access) Act überprüft werden.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nEDPB Opinion 08/2024, angenommen am 17. April 2024 — „In most cases, it will not be possible for large online platforms to comply with the requirements for valid consent if they confront users only with a binary choice“. Sie betrifft große Online-Plattformen, nicht Regionalzeitungen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nChrome for Developers — content_scripts manifest key — „Choosing the \u0026ldquo;MAIN\u0026rdquo; world means the script will share the execution environment with the host page\u0026rsquo;s JavaScript.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nECMAScript — CreateGlobalVarBinding — „If a binding already exists, it is reused and assumed to be initialized.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nChrome for Developers — declarativeNetRequest — „provides implicit access to allow , allowAllRequests and block rules“, und sonst „you must request host permissions before you can perform any action on a host.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nChrome for Developers — declarativeNetRequest — „Errors and warnings about invalid static rules are only displayed for unpacked extensions. Invalid static rules in packed extensions are ignored.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nHTML Standard — the Location interface kennzeichnet seine Member als [LegacyUnforgeable], was in Web IDL bedeutet: „the property will be non-configurable and will exist as an own property on the object itself“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nIAB Tech Lab — TCF v2 CMP API — „Every consent manager MUST provide the following API function: __tcfapi(command, version, callback, parameter)“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nPECR, regulation 6 — „a person must not store information, or gain access to information stored, in the terminal equipment of a subscriber or user“, mit der Einwilligung als Bedingung in Schedule A1, geändert durch den Data (Use and Access) Act 2025.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nHTML Standard — update the image data — läuft „whenever that element is created or has experienced relevant mutations“, auch wenn sein src gesetzt wird; im Dokument zu sein ist keine Bedingung.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://blogs.damiendye.uk/de/random/the-news-site-sent-me-the-article-then-deleted-it/","summary":"Newsquest, National World, Reach und andere schicken deinem Browser den vollständigen Artikel samt Stylesheets und lassen dann kommerziellen Anti-Adblock- und Consent-Code laufen, der die Seite leert, alle 100ms jedes Stylesheet löscht oder sie mit der Wahl zwischen 1.467 Tracking-Partnern und 2,99 £ im Monat zudeckt. Der Beitrag zeigt, was dieser Code tut, die vier Gründe, warum ich ihn Malware nenne, und die Chrome-Erweiterung, die ich an einem Tag gebaut habe, um die Seite zu behalten: Newsquests adLight-Flag festnageln, bevor die Wand entsteht, die aus eval geplanten Timer verwerfen, den Stylesheet-Stripper schon beim Einplanen töten und Einwilligung richtig verweigern, indem die TCF-API mit Nein beantwortet, der eigene Ablehnen-Knopf des Anbieters gedrückt und der Datensatz nie gespeichert wird. Dann die Fixes, die es schlimmer machten, die Messung, die eine kaputte Seite für gut erklärte, Teilen-Knöpfe und der MSN-Feed, und was die Erweiterung nicht tut.","title":"Die Nachrichtenseite schickte mir den Artikel und löschte ihn dann"},{"content":"Kohle auf null in vierzehn Jahren Im National-Grid-Dashboard von Kate Morley kannst du das Zeitfenster einstellen und den Zahlen beim Wandern zusehen.1 Der Datensatz beginnt 2012, was zufällig der Höhepunkt der Kohle war, also ist die Allzeit-Spalte die ganze Reinigung in einer Zahl.\nAllzeit (2012–) Letztes Jahr Letzte Woche Letzter Tag CO₂-Intensität 251 g/kWh 124 g/kWh 98 g/kWh 67 g/kWh Kohle 12,4 % 0,0 % 0,0 % 0,0 % Gas 33,5 % 27,0 % 21,2 % 15,9 % Wind 19,5 % 34,8 % 46,0 % 64,1 % Solar 3,7 % 7,4 % 8,3 % 11,1 % Kernkraft 18,3 % 12,0 % 12,0 % 12,9 % Fossil gesamt 45,8 % 27,0 % 21,2 % 15,9 % Erneuerbare gesamt 24,4 % 43,6 % 55,8 % 76,6 % Nachfrage 32,6 GW 30,9 GW 28,4 GW 25,8 GW Preis 70,13 £/MWh 92,77 £/MWh 125,01 £/MWh 27,18 £/MWh Wind ist heute die größte Einzelquelle für Strom in Großbritannien. 34,8 % über ein volles Jahr, gegen Gas mit 27 % und Kernkraft mit 12 %. Nicht an einem guten Tag. Zwölf Monate.\nKohle steht auf null. Nicht niedrig. Null, ein Jahr lang. Das letzte Kraftwerk ging am 30. September 2024 vom Netz, hundertzweiundvierzig Jahre nachdem das erste der Welt im Januar 1882 in London eröffnet hatte, was heißt, dass dieses Land die Kohleverstromung erfunden und dann den besseren Teil von anderthalb Jahrhunderten gebraucht hat, um sie wieder abzuschalten.1 Die CO₂-Intensität hat sich gegen den Vierzehnjahresschnitt halbiert, von 251 auf 124. Die Hälfte, in vierzehn Jahren.\nDie Nachfrage, die abhandenkam Sieh dir die Nachfragezeile noch einmal an. 32,6 GW im langen Mittel, 30,9 im letzten Jahr. Sie fällt seit zwanzig Jahren, rund 5 TWh pro Jahr seit 2005.\n2005 2023 Nachfrage der Haushalte 126 TWh 93 TWh Nachfrage der Industrie 117 TWh 86 TWh Durchschnittshaushalt 4.662 kWh (2007) 3.449 kWh Die Haushalte haben in dieser Zeit 33 TWh abgegeben, während das Land anderthalb Millionen Elektroautos und eine Viertelmillion Wärmepumpen angesteckt hat.2 Die Ökodesign-Regeln der EU haben einen großen Teil dieser Arbeit erledigt; allein die Beleuchtungsvorschriften haben 2020 EU-weit 81 TWh gespart.3 Die Effizienz hat die Elektroautos nicht nur aufgefangen, sie hat sie überrollt.\nZwei Einschränkungen, denn hier wird gern übertrieben. Auch die Nachfrage der Industrie ist gefallen, von 117 TWh auf 86, und das sind überwiegend schließende Fabriken und nicht schlauer werdende Fabriken. Und der Rückgang ist vorbei. 2024 war das erste Jahr seit fast zwei Jahrzehnten, in dem die Nachfrage wieder gestiegen ist.2\nDie Autos, die es kaputtmachen sollten Hier ist die Flotte, die das Netz aufgenommen hat, direkt aus den DVLA-Zulassungstabellen. In Großbritannien zum Jahresende zugelassene batterieelektrische Fahrzeuge.4\nJahr Pkw Transporter Busse Lkw Krafträder Gesamt 2015 20.472 4.786 194 314 917 26.756 2017 41.222 6.401 303 283 1.046 49.334 2019 89.581 10.479 504 269 2.790 103.724 2021 374.597 28.245 1.295 331 9.118 413.908 2023 916.576 64.988 3.188 732 14.142 1.000.092 2024 1.266.421 84.959 4.821 983 14.039 1.371.779 2025 1.708.499 111.837 7.450 1.472 13.460 1.843.395 Die Pkw sind in zehn Jahren um das Dreiundachtzigfache gestiegen, die ganze Flotte um das Neunundsechzigfache. Das millionste Elektrofahrzeug landete Ende 2023 bei 1.000.092, was so nah an der Nase ist, wie eine Statistik nur kommt. Das hat niemand geplant.\nDrei Dinge in dieser Tabelle, die in keiner Schlagzeile stehen.\nLkw haben kaum angefangen. 1.472 elektrische Lkw in ganz Großbritannien, und die Zahl ist zwischen 2015 und 2020 sogar gefallen, auf 253. Die Pkw waren immer der leichte Teil. Das hier ist der schwere Teil, und er hat noch nicht wirklich begonnen.\nElektrische Krafträder gehen rückwärts. 14.142 im Jahr 2023, dann 14.039, jetzt 13.460. Zwei Jahre Rückgang, die einzige Kategorie, die schrumpft, während alles andere sich potenziert.\nDie Prozente verlangsamen sich, das Blech nicht. Der Pkw-Zuwachs lag 2020 bei 114 % und 2025 bei 35 %. Aber 2025 kamen 442.000 Pkw auf die Straße, gegen 350.000 im Jahr 2024. Ein fallender Prozentsatz einer großen Zahl schlägt immer noch einen großen Prozentsatz einer kleinen.\nWohin das geht: die Future Energy Scenarios 2025 von NESO sehen Großbritannien bis 2050 bei 31 Millionen Elektrofahrzeugen unter Holistic Transition, 33,4 Millionen unter Electric Engagement und 36,1 Millionen unter Hydrogen Evolution.5 Die heutigen 1,84 Millionen sind etwa sechs Prozent des Wegs.\nEine Einzelheit aus diesen Szenarien ist erwähnenswert: die Flexibilität aus dem intelligenten Laden ist dieses Jahr gefallen, von 16 GW auf 10 GW. Größere Batterien heißt weniger, dafür längere Ladevorgänge, und weniger zum Verschieben.5\nDie Nachfrage, die nie aufgetaucht ist Es gibt allerdings noch etwas, das die Nachfrage drückt, und es ist nicht die Effizienz.\nEigenverbrauch Solar, ohne Batterie 30–40 % Solar plus Batterie 80–90 %6 Zwei Millionen Solaranlagen gibt es jetzt im Vereinigten Königreich, zusammen 22,3 GW, und über 30 % der neuen Anlagen gehen mit einer Batterie ans Netz, gegen 10 % vor fünf Jahren.6 Stell Speicher hinter die Module, und das meiste von dem, was das Dach macht, kommt nie über den Zähler.\nDiese Energie ist nicht gespart. Sie wird nur nicht mehr gezählt. Verändert hat sich allein der Zähler.\nJahr Zugebaute Solarleistung 2021 ~0,4 GW 2022 ~0,5 GW 2023 1,9 GW 2024 2,3 GW 2025 2,6 GW Das Sechsfache in fünf Jahren, und die Form sagt dir, warum. 2021 und 2022 waren flach. Dann kamen die Rechnungen, die Leute haben gerechnet, und Solar hörte auf, eine Umweltentscheidung zu sein, und wurde eine finanzielle.\nUnser Haus steht irgendwo in dieser Tabelle. Neun Kilowatt auf dem Dach, dreißig Kilowattstunden Batterie darunter, zwei Autos und die Klimaanlage, die die Tageserzeugung wegtrinken. Aus Sicht des National Grid schrumpft diese Adresse seit Jahren still vor sich hin. Aus Sicht der Physik nicht. Die Energie taucht nur auf niemandes Diagramm mehr auf.\nDer Krieg gegen das, was funktioniert hat Nichts davon ist zufällig passiert, und es gibt einen laufenden Versuch, den Rest zu stoppen.\nReform hat im Mai 2025 zehn englische Bezirksräte übernommen und angekündigt, sie würden „every lever“ nutzen, um neue Wind-, Solar- und Batterieprojekte zu blockieren. Carbon Brief beziffert das Gefährdete auf etwa 6 GW: 5.076 MW Batterieprojekte, 786 MW Solar und 56 MW Wind in diesen zehn Gebieten.7 Der Energiesprecher der Partei schrieb Entwicklern in Lincolnshire, „this is war“, und stellte den Vorstandsvorsitzenden von SSE Renewables, Octopus Energy, Centrica und Equinor förmlich in Aussicht, dass eine Reform-Regierung ihre Verträge zerreißen würde.7\nDie Behauptung mit dem Ackerland prüfen Als Begründung werden Ackerland und Ernährungssicherheit genannt. Diese Behauptung ist prüfbar, also prüfen wir sie.\nFlächennutzung Fläche Anteil am Vereinigten Königreich Freiflächensolar, September 2024 21.200 ha ~0,1 %8 Dasselbe, per Satellit gemessen 15.580–17.364 ha 0,06–0,07 %9 Golfplätze 125.000 ha ~0,5 %10 70 GW Solar bis 2035 k. A. unter 1 % der Agrarfläche10 Solar bedeckt etwa ein Zehntel eines Prozents dieses Landes. Golf bedeckt grob das Fünffache, und in all den Jahren, in denen sich irgendwer laut um die britische Ernährungssicherheit gesorgt hat, hat noch nie jemand einem Golfclub geschrieben, um ihm den Krieg zu erklären. Nicht ein Brief.\nUnter dem Lärm liegt ein echtes Argument, und das gehört klar gesagt. CPRE hat festgestellt, dass 59 % der größten Solarparks Englands auf produktivem Ackerland stehen, und 31 % dieser Fläche ist als beste und vielseitigste eingestuft.11 Die Qualität der Fläche ist ein fairer Punkt. Die Menge ist es nicht, und das Mengenargument ist das, was vorgebracht wird.\nUnd sieh dir noch einmal an, was in diesen 6 GW tatsächlich drinsteckt. Solar ist 786 MW davon. Batterien sind 5.076 MW, über vier Fünftel der Leistung, um die gestritten wird.7 Das Ackerland-Argument zielt auf die kleinere Zahl. Das eigentliche Ziel ist der Speicher, und ein Speicher baut nichts an.\nDie Behauptung mit dem Brand prüfen Batterieprojekte werden wegen Brandrisiko abgelehnt. Nicht nur dort, wo Reform regiert, um fair zu bleiben. Das hier ist breiter örtlicher Widerstand und nicht die Kampagne einer Partei, und er wirkt. Über 900 Einwendungen gegen ein Projekt bei Allerton Bywater in Leeds. Ein Grüngürtel-Standort bei Eaglesham nach 250 Einwendungen wegen Lithium-Brandängsten abgelehnt. Ein 49,9-MW-Projekt in Devon gegen die eigene Empfehlung des Planungsbeamten zurückgewiesen.12\nAlso stell die Brände neben die Einwendungen.\nAnzahl Netzbatteriebrände im Vereinigten Königreich, insgesamt 3 bekannte13 Südkorea, Häufung 2017–2019 2814 EPRI-Weltdatenbank der Vorfälle, seit 2011 ~95 Einträge14 Einwendungen gegen ein Projekt in Leeds 900+12 Ein einziger Bauantrag in Leeds hat mehr Einwendungen angezogen, als es seit 2011 irgendwo auf der Erde erfasste Netzbatteriebrände gegeben hat. Drei in diesem Land, überhaupt. Einer davon war ein Standort, der noch im Bau war.13\nUnd 27 der 30 weltweiten Vorfälle in den Jahren 2018 und 2019 waren in Südkorea. Eine nationale Häufung, schlimm genug, um deren Speichermarkt anzuhalten, und der Grund, warum die Datenbank überhaupt existiert.14 Rechne die heraus, und der weltweite Befund wird noch dünner.\nUnd die Rate ist eingebrochen. Die Ausfälle pro Jahr sind ungefähr gleich geblieben, während der Zubau von 11 GWh im Jahr 2018 auf über 300 GWh im Jahr 2024 gestiegen ist. Das ist ein Rückgang der Ausfallrate um 99 % je installierter Einheit, weil die Normen aufgeholt haben.14 2024 hatten 0,3 % der Projekte einen Ausfall, der zu einem Brand mit Sicherheitsbedenken führte.14 Das habe ich mir angesehen, zusammen mit dem Brand in Moss Landing, den alle zitieren, in dem Beitrag über Verlustenergie.\nUnd dann ist da noch das Warum sie ausfallen, und das ist der Teil, der den Streit beenden sollte.\nUrsache Anteil der Ausfälle Integration, Montage und Bau 36 %15 Betrieb 29 % Auslegung 21 % Herstellungsfehler 4 % 89 % der Vorfälle fangen überhaupt nicht bei der Batterie an.15 Nur drei in der gesamten Datenbank gehen auf einen Zell- oder Moduldefekt zurück. Schiefgeht tatsächlich das Drumherum: die Gleich- und Wechselstromverkabelung, die Lüftungstechnik, die Brandunterdrückung selbst. Und 72 % der Ausfälle passieren während des Baus, der Inbetriebnahme oder innerhalb der ersten zwei Jahre.15\nEs liegt also nicht an der Chemie. Es liegt am Einbau. Mangelhafte Montage, bei der Installation gesparte Ecken, eine Inbetriebnahme mit noch nicht scharfer Überwachung, sodass ein Leck oder ein Isolationsfehler Zeit hat, zu etwas anzuwachsen, für das es die Feuerwehr braucht, bevor irgendwo in Hörweite eines Menschen ein einziger Alarm gegangen ist. Schlechte Handwerksarbeit, mit anderen Worten.\nDas ist wichtig, weil es ändert, was die Antwort ist. Wäre Lithium von Natur aus anfällig dafür hochzugehen, hättest du recht damit, es aus dem Dorf herauszuhalten. Ist es nicht. Das ist ein Problem von Handwerksqualität und Prüfung, und so etwas können wir bereits beheben. Genau wie bei jeder anderen Elektroinstallation: ordentliche Normen, ordentliche Abnahme, jemand Kompetentes, der die Arbeit kontrolliert.\nWomit wir wieder bei den Planungsregeln sind, wo es eine echte Lücke gibt, die sich zu schließen lohnt. Die Bezirksräte sind gesetzlich nicht verpflichtet, die Feuerwehr zu einem BESS-Antrag zu hören, also verlangen manche einen kompletten Brandschutzplan und andere behandeln Sicherheit als gar nicht Teil der Planung.12\nDer Einwand lautet „diese Dinger fangen Feuer“. Die Daten sagen, schlecht eingebaute Dinger fangen Feuer. Das eine ist ein Argument, die Genehmigung zu verweigern. Das andere ist ein Argument, den Bau zu prüfen. Schließ die Lücke, und du nimmst das Argument weg. Lass sie offen, und sie funktioniert weiter als eines.\nErwähnenswert ist, dass bisher nichts davon besonders gut funktioniert hat. Ein Jahr später haben diese Bezirksräte festgestellt, dass sich große Solaranlagen in einer Pressemitteilung leichter blockieren lassen als in einem Planungsausschuss, und mehrere Projekte sind trotzdem durchgegangen.7\nFolge dem Geld Und woher das Skript kommt, ist bei der Finanzierung aktenkundig.\nGruppe Geld herein Von Heartland Institute 676.000 $+ (1998–2007) ExxonMobil16 Heartland Institute weitere, nicht offengelegte Summen Koch-nahe Stiftungen16 GWPF / Net Zero Watch 500.000 $+ ein Koch-naher Fonds17 GWPF / Net Zero Watch 210.525 $ Sarah Scaife Foundation, über ihren US-Arm17 Heartland ist eine amerikanische Klimaleugner-Organisation, die einen britischen Ableger eröffnet hat, mit Nigel Farage als Ehrengast bei der Eröffnung.16 Die Global Warming Policy Foundation tritt hier als Net Zero Watch auf, eine eingetragene Wohltätigkeitsorganisation, die ihre Kampagnen über eine private Firma laufen lässt.17\nAmerikanisches Geld aus fossilen Quellen, amerikanische Sprechzettel, eine britische Partei, die sie bei einer Technik nachspricht, in der dieses Land nachweislich gut ist. Die Punkte darfst du selbst verbinden.\nDie Sprechzettel kommen mit einem Präsidenten im Gepäck.\nDie Behauptung Was die Belege sagen Turbinenlärm verursacht Krebs Völlig unbegründet. Kein Beleg, dass der Schall der Gesundheit überhaupt schadet.18 Offshore-Wind tötet Wale NOAA und der National Marine Fisheries Service finden keinen wissenschaftlichen Beleg. Strandungen sind Schiffskollisionen, Fischereigerät und wärmeres Wasser.18 Ihre Herstellung erzeugt „tremendous fumes“ Eine Turbine holt die Energie für ihren Bau in 5 bis 8 Monaten wieder herein. Wind stößt 37-mal weniger CO₂ aus als Gas und 77-mal weniger als Kohle.19 Bei der letzten lohnt sich das Verweilen, denn sie kippt sauber um. Wind hat den kleinsten CO₂-Fußabdruck aller Erzeugungstechniken, die das US-Energieministerium misst.19 Die IPCC-Medianwerte setzen Wind an Land bei 11 g/kWh an und Kohle bei 820. Das habe ich in dem Beitrag über Verlustenergie ausgeführt. Das, was beschuldigt wird, Verschmutzung zu erzeugen, ist das, was am wenigsten davon erzeugt.\nDie Sache mit den Vögeln geht wenigstens von etwas Wahrem aus, also stell sie neben die anderen Dinge, die Vögel töten.\nUrsache von Vogeltoten in den USA Pro Jahr Windturbinen 140.000–330.00018 Gebäude ~600 Millionen18 Katzen 2 Milliarden+18 Auf Turbinen entfällt etwa ein Vogel von sechstausend. Wegen Katzen war noch nie jemand im Fernsehen. Katzen sind offenbar in Ordnung.\nUnd die Tierschutzlinie kam von niemandem, der Vögel beobachtet. Koordiniert wurde sie von einer konservativen Denkfabrik, finanziert von einem Branchenverband, hinter dem ExxonMobil, Chevron und Marathon Oil stehen.18 Dasselbe Geld wie in der Tabelle oben, andere Zustellung.\nWas der dritte Kanal ist. Denkfabriken schreiben es, Zeitungen drucken es, und online wird es in Masse bewegt. Eine Studie der Brown University fand Bot-Konten, die für knapp 40 % der Tweets verantwortlich waren, die Klimawissenschaft als Fälschung bezeichnen.20 Ich würde nicht behaupten zu wissen, wer sie betreibt, und diese Studie handelt von Klimaleugnung allgemein und nicht von britischem Solar im Besonderen. Aber das Muster hält, an welchem Ende du es auch aufhebst: die Behauptungen sind falsch, sie sind alt, und sie wurden bezahlt.\nDieselbe Sprache sprechen Hier ist der Teil, der meiner Meinung nach übersehen wird. Frag dich, warum Heartland einen Ableger in London eröffnet hat und nicht in Lyon oder Leipzig.\nWeil es hier funktioniert, wie es geschrieben ist. Keine Übersetzung, keine Lokalisierung, kein Anpassen des Arguments an ein Land, das metrisch misst und seine Wohnungen über ein Fernwärmenetz heizt. Die Pressemitteilung landet auf Englisch und läuft am selben Tag.\nDahinter steckt eine kartierte Struktur, nicht nur ein gemeinsames Vokabular.\nDie Brücke Atlas Network, Washington DC unterstützt 450+ Organisationen in 90+ Ländern21 Finanziert über Donors Trust und die Charles Koch Foundation21 55 Tufton Street, Westminster GWPF, das IEA, TaxPayers\u0026rsquo; Alliance, Centre for Policy Studies, Adam Smith Institute, Civitas21 Von DeSmog kartierte US-UK-Verbindungen ~2.00021 Klimaleugner tauchten im September 2025 in Zahl auf der Reform-Konferenz auf.21 Für nichts davon musste ein einziges Wort übersetzt werden.\nUnd der Verkehr läuft in beide Richtungen. Britische rechtsextreme Telegram-Kanäle sind dabei dokumentiert worden, wie sie Desinformation über die Integrität amerikanischer Wahlen verstärken. Dasselbe Rohr, in die andere Richtung gehalten.22 Forscher beschreiben, wie englischsprachige Publikationen Erzählungen setzen, die dann von Medien in anderen Sprachen aufgegriffen und wiederholt werden, was uns vorn in die Schlange stellt und nicht hinten.22\nEin französischer oder deutscher Leser bekommt eine Verzögerung und einen Übersetzer, und Übersetzung ist ein Filter. Irgendwer muss entscheiden, dass die Behauptung es wert ist, weitergetragen zu werden, und sie so weit prüfen, dass er seinen eigenen Namen daruntersetzt. Wir bekommen sie roh, im Tempo eines Retweets, aus einem Medienmarkt, der vierzigmal so groß ist wie unserer und den wir ohnehin zur Unterhaltung konsumieren.\nDas ist die eigentliche Verwundbarkeit. Nicht, dass Amerikaner über ihr eigenes Netz streiten. Damit können sie machen, was sie wollen. Sondern dass wir jedes Wort davon hören, in unserer eigenen Sprache, über unser Netz, von Leuten, die es nie gesehen haben.\nBilliger Kohlenstoff, teurer Strom Eines hat sich nicht verbessert. Strom lag im letzten Jahr im Mittel bei 92,77 £/MWh, gegen 70,13 £ über den gesamten Datensatz. Rund ein Drittel teurer, während sich der Kohlenstoff halbiert hat.1\nDu wirst gelesen haben, dass die Erneuerbaren daran schuld sind. Du wirst es oft gelesen haben.\nBritische überregionale Presse, 2025 Leitartikel gegen Erneuerbare 4223 Erstes Jahr, in dem Anti-Leitartikel die Pro-Leitartikel überwogen, seit 201423 Rechtsgerichtete Klima-Leitartikel, die Klimaschutz ablehnen 81 %23 Kritische Leitartikel, die mit den Kosten aufmachen 86 %23 Das Argument sind also die Kosten. Nicht Vögel, nicht Landschaft, nicht Schwankungen. Kosten, in sieben von acht.\nDas Dashboard klärt das, denn es veröffentlicht Preis und Mix halbstündlich zusammen. Hier ist der 20. September 2026, ab der Teezeit.1\nZeit Preis Gas Gasanteil Kohlenstoff Solar Wind 16:00 −19,03 £ 2,85 GW 11,3 % 71 g/kWh 6,33 11,30 16:30 38,19 £ 3,74 GW 15,1 % 88 g/kWh 5,19 10,84 17:00 103,70 £ 4,46 GW 18,3 % 109 g/kWh 4,06 10,21 17:30 134,16 £ 6,23 GW 25,6 % 133 g/kWh 2,64 9,68 18:00 175,57 £ 7,96 GW 32,2 % 150 g/kWh 1,53 8,96 19:30 195,65 £ 8,87 GW 39,9 % 162 g/kWh 0,02 6,99 Die Sonne ging unter. Gas verdreifachte sich, von 2,85 GW auf 8,87. Und der Preis ging in dreieinhalb Stunden von minus neunzehn Pfund auf fast zweihundert. Plus 57 £ in der halben Stunde bis halb fünf, weitere 65 £ bis fünf, weitere 41 £ bis sechs. Die CO₂-Intensität hat sich in der Zeit mehr als verdoppelt.\nNimm den ganzen Tag statt nur den interessanten Teil, und der Zusammenhang hält über alle achtundvierzig Abrechnungsperioden.\n20. September 2026, alle 48 halben Stunden Gasanteil reichte von 7,4 % bis 39,9 % Preis reichte von −19,03 £ bis 195,65 £ Gesamtspanne 214,68 £/MWh Korrelation, Gasanteil gegen Preis r = 0,933 Halbe Stunden mit negativem Preis 18, von 01:00 bis 16:00 Null Komma neun drei, an einem Tag, bei festen Gasverträgen. Und neun Stunden davon hat Großbritannien Leuten dafür gezahlt, ihm Strom abzunehmen. Gas unten bei 7,4 %, Solar Richtung 10 GW, Preis unter null.\nDann ging die Sonne unter und es kostete 195,65 £. Dieselben Leitungen. Dieselben Windparks. Dasselbe Land.\nDer Mechanismus heißt Grenzkostenpreis. Der Großhandelspreis wird von den laufenden Kosten des teuersten Kraftwerks gesetzt, das in dieser halben Stunde gebraucht wird, und das ist fast immer Gas. Während der Krise hat Gas den Preis in 98 % der Zeit gesetzt, bei rund 40 % des Stroms; 2021 in 97 % der Zeit bei 37 % der Erzeugung.24 Der höchste Anteil aller Länder Europas.\nAnteil an der Erzeugung Anteil an der Preissetzung Gas 27,0 % im letzten Jahr1 97–98 % der Perioden24 Wind, Solar, Kernkraft, Wasser, Biomasse 73,0 % der Rest Sei bei einer Sache in diesen Daten allerdings ehrlich, denn irgendwer wird sie bemerken. Der Allzeitschnitt liegt bei 70,13 £/MWh, auf einem schmutzigeren Mix als dem heutigen, billiger als die 92,77 £ des letzten Jahres. Das sind nicht die Windräder, die die Preise hochtreiben. Das sind die Jahre 2012 bis 2020 mit billigem Gas. Über Epochen hinweg dominiert der Gaspreis; innerhalb eines einzigen Tages das Wetter. Beides zeigt auf denselben Schuldigen.\nEin Viertel des Mixes bepreist also alles. Wind könnte an der Erzeugung kostenlos sein, und ein großer Teil davon ist es faktisch, und die Zahl auf deiner Rechnung würde sich nicht rühren, weil das letzte Gaskraftwerk im Stapel nach wie vor den Satz setzt.\nDas sind nicht die Erneuerbaren, die Strom teuer machen. Das ist ein Marktdesign aus den 1990ern, das auf ein Netz trifft, das nicht mehr wie die 1990er aussieht.\nDer Gegenentwurf besiegelt es. Nimm eine Gaspreisspitze, wie wir sie schon erlebt haben, und modelliere sie gegen zwei verschiedene Netze.24\nDieselbe Gasspitze trifft ein Netz mit… Haushaltsrechnungen steigen um erfüllten Erneuerbaren-Zielen für 2030 8 % gar keinen CfD-gestützten Erneuerbaren 45 % Dieselbe Spitze. Dasselbe Gas. Der einzige Unterschied ist, wie viel Wind und Solar dasitzt, ohne sich darum zu scheren, was Gas kostet. Mehr Erneuerbare, kleinerer Schlag. Um den Faktor fünfeinhalb.\nDie Windparks sind also der Grund, warum die letzte Krise zu überleben war, nicht der Grund, warum sie passiert ist. Drei getrennte Tests, eine Antwort: innerhalb eines Tages folgt der Preis dem Wind umgekehrt, über Epochen hinweg folgt er dem Gaspreis, und in der Modellrechnung sind die Erneuerbaren das, was die Spitze abstumpft. Gas ist die Ursache. Es ist nicht knapp, und es ist auch nicht wirklich strittig.\nDas, was diesen Abend gerettet hätte Jetzt halte das neben die achtzehn halben Stunden früher am selben Tag, in denen der Preis unter null lag. Das ist genau die Form von Problem, die eine Batterie löst. Lade sie, während das Netz Leuten dafür zahlt, ihm Strom abzunehmen, drück sie in die Abendspitze zurück, und das letzte Gaskraftwerk im Stapel wird nie gerufen. Die Spanne am 20. September betrug 214,68 £ je Megawattstunde. Batterien gibt es, um solche Spannen zu fressen.\nWomit wir wieder bei diesen 5.076 MW Batterieprojekten in zehn Bezirken sind, und bei der Partei, die jeden Hebel dagegen versprochen hat. Speicher zu blockieren schiebt nicht bloß etwas CO₂-Minderung auf. Es schützt die Gasmarge, halbe Stunde für halbe Stunde, genau an den Abenden, an denen Gas am meisten wert ist.\nOb das die Absicht ist: folge dem Geld. Die Wirkung ist es so oder so, und die Finanzierung hinter dem Argument gehört, wie die Tabelle weiter oben zeigt, genau der Branche, die die Differenz einstreicht.\nDie Umlagen, und wer die Zahlen geprüft hat Und die Umlagen, da sie als Beweisstück zitiert werden:\nRechnungsbestandteil, 2025 Betrag Anteil Politikkosten auf Strom 148,45 £ 17 % der Stromrechnung25 Politikkosten auf Gas 50,86 £ 6 % der Gasrechnung25 Siebzehn Prozent, und ab April 2026 hat die Regierung 75 % der Renewables Obligation von den Rechnungen in die allgemeine Steuerfinanzierung verschoben, rund 92 £ im Jahr von der durchschnittlichen Senkung um 150 £.25 Echtes Geld, worüber sich streiten lässt, und weit weg von der Hauptsache. Die Hauptsache sind die 27 % der Erzeugung, die die anderen 73 % bepreisen.\nIch werde dir nicht sagen, wie viele dieser 42 Leitartikel Lügen waren, denn Absicht zu beweisen ist nichts, was ich vom Schreibtisch aus kann. Zeigen lässt sich die Fehlerquote, und die ist schlecht. Eine Beschwerde gegen einen Artikel der Daily Mail hat fünfzehn sachliche Fehler benannt; die Aufsicht hat eine Korrektur verlangt.26 Die Mail on Sunday und die Times haben beide berichtet, NESO habe festgestellt, die Kosten von Netto-Null lägen bis 2050 bei 4,5 Billionen Pfund. NESO hat nichts dergleichen festgestellt, und es war das dritte Mal, dass Zeitungen genau diese Stelle falsch wiedergegeben haben.26\nBevor mir jemand die niedrige Zahl der stattgegebenen Beschwerden vorhält: im Beschwerdeausschuss der IPSO sitzen keine Berufswissenschaftler, er zieht bei fachlichen Themen keine Experten hinzu, und er behandelt eine falsche Zahl routinemäßig als Meinung.26 Eine stattgegebene Beschwerde bei fünfzehn Fehlern misst die Aufsicht, nicht den Artikel.\nZieh deinen eigenen Schluss. Meiner ist, dass das meistwiederholte Argument gegen Erneuerbare in der britischen Presse dasjenige ist, das am schnellsten zusammenfällt, wenn man es neben den eigenen Zähler des Netzes hält.\nUnd den Gaspreis machen nicht wir Hier ist, was mit Gas tatsächlich passiert ist, an der europäischen TTF-Referenz.27\nTTF-Gaspreis Schnitt vor 2021 ~20 €/MWh Dezember 2021 180 € März 2022 220 € Höhepunkt August 2022 ~340 € Anfang 2026 35–45 € Mitte September 2026 83,40 € Das Siebzehnfache des Normalsatzes auf dem Höhepunkt. Und sieh dir die letzte Zeile an. Gas ist diesen Monat wegen Sorgen um Versorgung und Speicher auf 83 € gegangen, und genau deshalb hat ein windstiller Sonntagabend im GB-Netz 179,70 £/MWh gekostet. Die Kette ist kurz: der europäische Gasmarkt bewegt sich, Gas setzt den britischen Preis, deine Rechnung folgt.\nUnd beachte, dass „zurück zur Normalität“ keine ist. Der heutige Boden von 35–45 € ist immer noch das Doppelte von vor der Krise, und er springt auf ein Gerücht hin.\nKeine dieser Entscheidungen wird hier getroffen, und unsere Abhängigkeit wächst.28\nBritische Gasversorgung Anteil der Nordsee an der Nachfrage, 2025 etwa die Hälfte Gasimporte, 2025 464 TWh davon norwegische Pipeline 69 % der Importe davon LNG 31 % der Importe LNG als Anteil der Gesamtversorgung heute 14 % LNG-Anteil bis 2030 über 25 % LNG-Anteil bis 2035 nahe 50 % Die Nordsee-Förderung fällt um 12–13 % im Jahr und soll bis 2035 um 78 % unter 2025 liegen.28 Die Lücke füllen Tanker aus Katar und den Vereinigten Staaten, gekauft auf einem globalen Spotmarkt gegen Käufer in Asien, die uns an jedem kalten Morgen überbieten können, an dem ihnen danach ist.\nDas Argument, wir sollten das Netz um der Rechnungen willen auf Gas halten, hat es also verkehrt herum. Gas ist der Teil, den wir nicht kontrollieren, bepreist von Ereignissen, auf die wir keinen Einfluss haben, aus Feldern, die zur Neige gehen. Wind und Sonne sind der Teil, der hier umsonst passiert, sobald die Technik steht.\nWas es kostet und was dafür verlangt wird Es gibt einen Unterschied zwischen dem, was eine Sache kostet, und dem, was dir dafür berechnet wird, und dieses ganze Geschäft sitzt in dieser Lücke.\nDie Kosten, dieses Netz zu betreiben, sind gefallen. Halber Kohlenstoff, keine Kohle, ein Drittel der Erzeugung kommt inzwischen aus Wetter, das umsonst ankommt und keine Rechnung schickt. Das sind die Kosten. Der Preis ging in die andere Richtung, weil wir eine Regel aus den 1990ern behalten haben, nach der das teuerste Kraftwerk im System den Satz für alles andere darin setzt, und weil wir dann den Brennstoff für dieses Kraftwerk aus einem Markt importiert haben, in dem ein Kälteeinbruch in Asien bewegt, was ein Rentner in Barnsley fürs Warmbleiben zahlt.\nNiemand verheimlicht das. Es steht geschrieben, in halbstündlichen Abrechnungsdaten, kostenlos, auf einer Website, die eine Frau pflegt.\nWorauf ich immer wieder zurückkomme, ist die Frage, wem die Verwirrung nützt. Denn die Leute, die dir erzählen, die Windparks hätten das getan, werden, wenn du dem Geld zurück folgst, von dem finanziert, was es tatsächlich getan hat. Das ist kein Zufall und es ist keine Unfähigkeit. Es ist der älteste Trick, den es gibt: mach die Öffentlichkeit wütend auf den billigsten Teil des Systems, damit niemand auf den teuersten schaut.\nUnd der Teil, der angegriffen wird, ist der einzige, der uns ganz gehört. Eine Gasturbine braucht einen Tanker aus Katar und einen Preis, der in Rotterdam gemacht wird. Ein Windpark vor dem Humber braucht Wartung. Das eine ist Souveränität und das andere ein Dauerauftrag, und wir sind offenbar dabei, uns aus dem Ersten herauszureden, um das Zweite zu schützen.\nWir haben das Ding gebaut. Es funktioniert. Irgendwer sollte es den Leuten sagen.\nQuellen Kate Morley — National Grid: Live — Erzeugungsmix, CO₂-Intensität, Nachfrage und Preis für Großbritannien, wählbar über den letzten Tag, die letzte Woche, das letzte Jahr und den gesamten Datensatz ab 2012; außerdem die Stilllegung des letzten Kohlekraftwerks am 30. September 2024.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nDrax — 2024, the year GB electricity demand turned a corner — zwei Jahrzehnte fallender Nachfrage, die von Elektrofahrzeugen und Wärmepumpen hinzugekommene Last, und die Umkehr im Jahr 2024.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nEuropean Commission — Light sources, energy label and ecodesign — die Ökodesign-Vorschriften für Beleuchtung und die 81 TWh Strom, die sie 2020 EU-weit gespart haben.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nDepartment for Transport — Vehicle licensing statistics data tables, VEH0141 — zugelassene Plug-in-Fahrzeuge zum Ende jedes Quartals nach Bauart und Kraftstoffart. Die Zahlen oben sind die Spalte der batterieelektrischen Fahrzeuge für Großbritannien zum vierten Quartal jedes Jahres.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNational Energy System Operator — Future Energy Scenarios — die Durchdringung mit Elektrofahrzeugen bis 2050 über die Pfade hinweg, die Vehicle-to-Grid-Kapazität, und die Korrektur der Flexibilität aus dem intelligenten Laden.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMCS — UK homes installing a small-scale renewable every 90 seconds — die Summen zertifizierter Installationen, die Zwei-Millionen-Marke und die installierte Leistung, und der Anteil neuer Solaranlagen mit Batteriespeicher.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCarbon Brief — Reform-led councils threaten 6GW of solar and battery schemes across England — die Leistung in den im Mai 2025 übernommenen zehn Bezirken, die Zusage „every lever“, die Briefe an Entwickler und Vorstandsvorsitzende von Energieunternehmen, und was mit den Projekten seither tatsächlich passiert ist.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nHouse of Commons Library — Planning for solar farms — Freiflächensolar bedeckte Ende September 2024 geschätzt 21.200 Hektar, rund 0,1 % der gesamten Landfläche des Vereinigten Königreichs.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nLancaster University — Researchers use satellite imagery to shed light on UK solar farm land use — die Satellitenmessung, die die Flächennutzung durch Solarparks auf 15.580 bis 17.364 Hektar beziffert, 0,06 % bis 0,07 % der Landfläche des Vereinigten Königreichs.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nFriends of the Earth — Fact check: British farming and renewables — die Fläche unter Golfplätzen gegen Solar, und der Anteil an der Agrarfläche, den das Ziel von 70 GW bis 2035 bedeutet.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCPRE — Two-thirds of mega solar farms built on productive farmland — 59 % der größten in Betrieb befindlichen Solarparks Englands auf produktivem Ackerland, 31 % dieser Fläche als beste und vielseitigste eingestuft.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nHouse of Commons Library — Battery energy storage systems — Einwendungen und Ablehnungen in der Planung, darunter die Projekte Allerton Bywater, Eaglesham und Devon, das thermische Durchgehen als Brandmechanismus, und das Fehlen jeder gesetzlichen Pflicht der Bezirksräte, die Feuerwehr zu einem BESS-Antrag zu hören.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nHouse of Commons Library — Battery energy storage systems — dokumentierte britische Brände an netzgroßen BESS, darunter Liverpool im September 2020 und ein im Bau befindlicher Standort in Essex im Februar 2025, und der Hinweis, dass es keine verlässliche öffentliche Zählung der Vorfälle gibt.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nEPRI — BESS Failure Incident Database — der weltweite Befund zu Ausfällen im Netzmaßstab seit 2011, die südkoreanische Häufung von 2017–2019, der Rückgang der Ausfallrate je installierter Einheit gegenüber dem Zubau, und die Einschränkung, dass die Datenbank nur öffentlich gemeldete Vorfälle erfasst.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nUtility Dive — Cells and modules not responsible for most battery energy storage system failures — die Ursachenanalyse von EPRI: Integration, Montage und Bau bei 36 % der Ausfälle, Betrieb 29 %, Auslegung 21 %, Herstellungsfehler 4 %; 89 % der Vorfälle entstehen nicht in der Batterie; und die Häufung der Ausfälle in Bau, Inbetriebnahme und den ersten zwei Betriebsjahren.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nLeft Foot Forward — What is the Heartland Institute? — die Eröffnung des britischen Ablegers, die Teilnahme, und Heartlands Finanzierung durch ExxonMobil und Koch-nahe Stiftungen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nopenDemocracy — Net Zero Watch: how dark oil money is funding influential UK climate sceptics — die Finanzierung von GWPF und Net Zero Watch über American Friends of the GWPF, einschließlich der Zahlungen der Sarah Scaife Foundation.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nClimate Power — Fact check: Trump\u0026rsquo;s wind turbine claims — die Behauptungen zu Krebs und Walen gegen die Position von NOAA und National Marine Fisheries Service, die Schätzungen des US Fish and Wildlife Service zu Vogelkollisionen mit Turbinen im Vergleich zu Gebäuden und Katzen, und der Ursprung des Tierschutzarguments in fossil finanzierter Denkfabrik-Arbeit.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCNN — Fact check: five things Trump got wrong about wind turbines — die Behauptung zu „tremendous fumes“ und zum CO₂-Fußabdruck gegen die Position des Energieministeriums, die energetische Amortisation einer durchschnittlichen Turbine in fünf bis acht Monaten, und die Emissionen von Wind im Vergleich zu Gas und Kohle.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nInstitute at Brown for Environment and Society — Shadowy Twitter bots spread climate disinformation — der Anteil der Tweets, die Klimawissenschaft als Fälschung bezeichnen und sich auf Bot-Konten zurückführen ließen. Hinweis: das ist eine Studie von 2021 zur Klimaleugnung allgemein, nicht zu britischen Erneuerbaren im Besonderen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nDeSmog — 55 Tufton Street und Mapped: how a US-UK network pushes climate science denial — das Westminster-Cluster und seine Mitglieder, die Reichweite des Atlas Network und seine Finanzierung über Donors Trust und die Charles Koch Foundation, die rund zweitausend kartierten transatlantischen Verbindungen, und die Teilnahme von Klimaleugner-Gruppen an der Reform-Konferenz 2025.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nDFRLab — UK-based far-right Telegram channels amplified disinformation targeting US election integrity — die dokumentierte transatlantische Verstärkung in beide Richtungen, und die Rolle englischsprachiger Publikationen beim Setzen von Erzählungen, die anschließend von Medien in anderen Sprachen wiederholt werden.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nPress Gazette — Record opposition to climate action in UK national newspapers in 2025 — die Zahl der Leitartikel gegen erneuerbare Energien, das erste Jahr seit 2014, in dem sie die zustimmenden überwogen, der Anteil rechtsgerichteter Klima-Leitartikel, die Klimaschutz ablehnen, und die Kosten als dominante Angriffslinie.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCarbon Brief — Q\u0026amp;A: Why does gas set the price of electricity, and is there an alternative? — die Grenzkostenpreisbildung in Großbritannien, der Anteil der Abrechnungsperioden, in denen Gas den Preis setzt, gegen seinen Anteil an der Erzeugung, und die modellierte Wirkung einer Gaspreisspitze mit und ohne CfD-gestützte Erneuerbare im System.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nHouse of Commons Library — What costs make up an electricity bill? — die Politikkosten auf Strom- und Gasrechnungen in Geld und als Anteil, die Renewables Obligation als größter einzelner Politikkostenposten, und die Verlagerung von 75 % ihrer Kosten in die allgemeine Steuerfinanzierung ab April 2026.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCarbon Commentary — Climate misinformation and press regulation — die fünfzehn in einem einzigen Daily-Mail-Artikel festgestellten Ungenauigkeiten gegen eine verlangte Korrektur, die wiederholte Falschwiedergabe der NESO-Befunde zu den Kosten von Netto-Null, und die Zusammensetzung und Arbeitsweise des IPSO-Beschwerdeausschusses bei fachlichen Themen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nTrading Economics — EU natural gas (TTF) price history — die niederländische TTF-Referenz von der Basislinie vor 2021 über die Spitze 2021/22 bis zum Höhepunkt im August 2022 und den heutigen Ständen, einschließlich der Bewegung im September 2026 wegen Sorgen um Versorgung und Speicher.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nICIS — Ebbing North Sea gas production to raise UK gas prices and exposure to LNG imports — die Nordsee, die 2025 etwa die Hälfte der Nachfrage deckt, Menge und Aufteilung der Importe, das Tempo des UKCS-Rückgangs, und die prognostizierte LNG-Abhängigkeit bis 2030 und 2035.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://blogs.damiendye.uk/de/energy/the-grid-we-did-fix/","summary":"Großbritannien hat die CO₂-Intensität seines Stroms in vierzehn Jahren halbiert, ein volles Jahr ohne Kohle gefahren und Wind zur größten Einzelquelle gemacht. Gleichzeitig ist die Nachfrage zwei Jahrzehnte lang gefallen, während das Land 1,8 Millionen Elektrofahrzeuge angesteckt hat. Das hier zeigen die Zahlen, samt der Teile, die die Geschichte verderben.","title":"Das Netz, das wir in Ordnung gebracht haben"},{"content":"Die Zahl, die alle zitieren und niemand liest Lawrence Livermore hat neulich sein Energieflussdiagramm für 2024 herausgegeben. Danach hat Amerika 94,61 Quads Energie verbraucht und 62,27 davon weggeworfen.1\nGut. Ein Quad ist eine Billiarde British Thermal Units, also 10¹⁵ BTU. Kein Geldbetrag: im englischen Original klingt quad wie quid, das britische Wort für ein Pfund, und in diesem Artikel geht es nirgends um Geld. Die Amerikaner führen ihre nationale Energiebilanz in Quads, der Rest von uns rechnet in Wattstunden, also hier die Umrechnung, die das Ganze greifbar macht: ein Quad sind etwa 293 TWh, eine Spur mehr, als das gesamte britische Netz in einem Jahr liefert.\nVerlustenergie ist der höfliche Name für diese 62,27. Der Teil, der keine nützliche Arbeit geleistet hat. Wärme den Schornstein hoch, Wärme vom Heizkörper weg, Wärme aus dem Auspuff. Fast alles davon ist Abwärme aus dem Verbrennen von irgendwas.\nUnd jetzt Vorsicht mit den Einheiten, denn ich hatte das zuerst falsch und das halbe Internet hat es immer noch falsch. 62,27 sind Quads, keine Prozent. Stell sie den 32,34 Quads gegenüber, die etwas Nützliches getan haben, und der Anteil liegt bei 65,8 %. Zwei Drittel von allem, was gebohrt, gegraben, durch Rohre und über See geschafft wurde, weg als warme Luft.\n2024 In britischen Netzen Energie hinein 94,61 Quads 27.726 TWh 102 Jahre davon Verlust 62,27 Quads 18.249 TWh 67 Jahre davon Nutzenergie 32,34 Quads 9.477 TWh 35 Jahre davon Die letzte Spalte ist die, die bei mir hängen geblieben ist. Das Netz Großbritanniens liefert etwa 271 TWh im Jahr.2 Die Verlustenergie Amerikas allein für 2024 entspricht also siebenundsechzig Jahren des kompletten britischen Netzes, als Wärme weggeworfen, in zwölf Monaten.\nAnders gesagt: lass den Strom dieses Landes von heute an bis 2093 laufen, und du hättest immer noch nicht erzeugt, was die Vereinigten Staaten letztes Jahr verschwendet haben.\nDiese Zahl wird überall zitiert. Wie das Diagramm zählt, wird so gut wie nie zitiert. Das ist der interessante Teil.\nEine Anmerkung vorweg, weil hier ein Yorkshireman über Amerika schreibt. Im Original stehen britische Wörter, wo Amerika andere hat: petrol für Benzin, forecourt für die Tankstelle, aircon für die Klimaanlage. Und wenn ich nowt oder summat sage, heißt das nichts und etwas.\nWind und Solar werden mit 100 % angesetzt Hier ist der Punkt, an dem es die Leute erwischt. Livermore folgt der Konvention der Energy Information Administration, und danach gehen vier Quellen ganz ohne Umwandlungsverluste ins Diagramm ein.3\nQuelle Wie sie ins Diagramm kommt Wohin die Verluste gehen Kohle, Gas, Öl Brennstoffenergie hinein ~60–70 % in den Verlust Kernkraft thermische Energie hinein ~67 % in den Verlust Wind an Land Strom heraus kein Verlust Solar, Freifläche und Dach Strom heraus kein Verlust Wasserkraft Strom heraus kein Verlust Ein Gaskraftwerk wird über die Energie im Gas gezählt, also landen die zwei Drittel, die es als Wärme wegwirft, im Verlustblock. Eine Turbine wird über den Strom gezählt, den sie liefert. Es gibt keine Zeile „Energie im Wind“, gegen die sich etwas verlieren ließe.\nIn diesem Diagramm erledigt also jede Terawattstunde, die von einem thermischen Kraftwerk zu einem Windpark wandert, zwei Aufgaben auf einmal. Sie kommt zur Nutzenergie hinzu und nimmt vom Verlust weg. Sie zählt doppelt.\nWomit das Argument, das Abschaffen von Wind und Solar würde den Verlust senken, rückwärts durch genau das Diagramm läuft, über das es aufgestellt wird. Mir ist das von Leuten ernsthaft vorgetragen worden, die es besser wissen müssten. Das ist keine knappe Sache. Das ist das umgedrehte Vorzeichen.\nWo der Verlust tatsächlich sitzt Teile das Diagramm nach Sektoren auf, und es hört auf, eine Abstraktion zu sein.1\nSektor Energie hinein Verlust Nutzen Wirkungsgrad Wohnen 11,23 3,93 7,30 65 % Gewerbe 9,49 3,32 6,17 65 % Industrie 26,39 13,46 12,93 49 % Verkehr 28,29 22,35 5,94 21 % Die Kraftwerke verlieren weitere 19,21 Quads über die Kühltürme, bevor irgendetwas davon diese vier erreicht.\nDer Verkehr ist mit Abstand der schlimmste. Er nimmt den größten Anteil der Energie und macht 21 % davon zu Bewegung. Diese 22,35 verlorenen Quads sind 36 % von allem, was Amerika wegwirft. Mehr als ein Drittel des nationalen Verlusts, in einem einzigen Sektor.\nEin Benzinmotor macht vielleicht 16–25 % des Kraftstoffs zu Bewegung. Der Rest ist Wärme und Lärm.4\nNutzbar an den Rädern Als Wärme verloren Benzinmotor 16–25 % 75–84 % Elektrischer Antriebsstrang (Batterie bis Rad) 87–91 % 9–13 % Das ist kein Randgewinn. Das ist der Unterschied zwischen einer Maschine, die überwiegend den Himmel wärmt, und einer, die überwiegend das Auto bewegt. Dieselbe Fahrt, andere Physik.\nUnd es zieht sich durch die ganze Kette, nicht nur durch das Fahrzeug. Flüssigen Kraftstoff bis zur Tankstelle zu bringen kostet Energie, bevor ein Tropfen davon verbrannt ist.\nSchritt Energie, die der Weg dorthin kostet Rohöl raffinieren 7–15 % des Einsatzes5 Tanker, Pipeline, Tanklastzug obendrauf Übertragung und Verteilung im Netz ~5 %6 Öltanker als Anteil der Weltflotte ~28 % nach Tragfähigkeit7 Rohöl und Produkte per Schiff, jährlich ~4,4 Milliarden Tonnen7 Der Straßenverkehr ist rund die Hälfte der weltweiten Ölnachfrage. Elektrifiziere den, und ein ordentliches Stück der Tankerflotte hat nichts mehr zu fahren.\nHier gehört Ehrlichkeit hin, denn Übertreiben ist die Art, wie man ein Argument verliert, das man gerade gewinnt. Netzverluste sind real, und sie sind ohmsche Wärme. Ein E-Auto zahlt im Winter für die Innenraumwärme, die ein Verbrenner umsonst bekommt. Aber diese Wärme ist nur deshalb umsonst, weil der Motor drei Viertel des Kraftstoffs schon vorher in die Tonne getreten hat. Sie ist umsonst wie die Wärme eines Hausbrands.\nDas Größte, was Amerika tun könnte Leichte Fahrzeuge sind 58,5 % der Verkehrsenergie, und genau der Teil, der sich ohne neue Technik elektrifizieren lässt.8 Rechne durch, was der Tausch des Antriebsstrangs bringt, wenn sonst alles bleibt, wie es ist.\nLeichter Straßenverkehr Quads Energie hinein, heute 16,55 Nutzarbeit, die tatsächlich herauskommt 3,47 Dieselbe Arbeit über einen E-Antrieb 4,09 Strom …erzeugt aus Gas, mit GuD-Wirkungsgrad 9,08 Primärenergie …erzeugt aus Wind, Solar oder Wasser 4,09 Primärenergie Eingesparte Energie 7,5 bis 12,5 Quads Selbst wenn du jedes einzelne davon an Gasturbinen lädst, sparst du rund siebeneinhalb Quads. An Wind und Solar sind es zwölfeinhalb. Acht bis dreizehn Prozent von allem, was die Vereinigten Staaten verbrennen, aus einem einzigen Tausch.\nDas ist der größte Effizienzgewinn, der irgendwo auf dem Diagramm zu haben ist, er braucht keine Erfindung, keinen Durchbruch, kein Pilotprojekt und keine neue Physik, denn jedes einzelne Fahrzeug, das dafür nötig ist, wird heute schon in Stückzahlen gebaut und verkauft. Die Autos gibt es. Das ist der ganze Trick.\nNur behebt ein besserer Motor die Bebauung nicht Ein E-Auto muss die Strecke trotzdem zurücklegen, und hier sitzt die andere Hälfte des Problems.\nVereinigte Staaten Europa Automeilen pro Person und Jahr ~12.400 ~6.2009 Anteil der täglichen Wege mit dem Auto 85 % 50–65 %9 Wege unter einer Meile mit dem Auto ~70 % ~30 %9 Parkplätze pro Auto ~8 nicht erfasst9 Sieh dir die dritte Zeile an, denn sie nimmt die Ausrede mit der Geografie weg. Etwa 30 % der täglichen Wege sind auf beiden Seiten des Atlantiks kürzer als eine Meile. Dieselben Besorgungen, dieselben Entfernungen. Amerikaner fahren sieben von zehn davon mit dem Auto. Europäer gehen, radeln oder nehmen etwas für sieben von zehn davon.\nDas hat nicht die Geografie gemacht. Das Wetter auch nicht. Das hat die Bebauungsplanung gemacht, die die Häuser hierhin und die Läden drei Meilen dorthin gesetzt hat, gestützt auf Stellplatzpflichten, die am Ende fast acht Parkplätze für jedes Auto im Land gebaut haben.9 Zwischen den 1920ern und den 1960ern wurden amerikanische Städte um das Auto herum neu gebaut, und weite Teile Westeuropas haben das kopiert. Ab den späten 1960ern hat Europa aufgehört und angefangen, es rückgängig zu machen.9\nDie zwölfeinhalb Quads sind also die Obergrenze für Elektrifizierung allein. Halbiere zusätzlich die Kilometer, und du halbierst, was übrig ist. Das eine ist eine Ingenieursaufgabe und das andere eine Planungsaufgabe, und aus der Planungsaufgabe kann sich niemand mit einem einzigen Kauf herauskaufen.\nUnd der billigste Personenkilometer ist ein geteilter Es gibt einen dritten Hebel, und Amerika hat mehr oder weniger aufgehört, daran zu ziehen.\nVerkehrsmittel Energie je Personenkilometer Benzinauto 1,9 bis 3,5 MJ10 Städtische Elektrobahn, gut besetzt 0,3 bis 0,6 MJ10 Vier- bis sechsmal besser, bevor überhaupt jemand einen Antriebsstrang anfasst. Ein Auto mit einer Person darin stößt je Personenkilometer das 7,7-Fache an CO₂ aus wie ein voller Reisebus.10\nUnd jetzt der Stand der Dinge.\nVereinigte Staaten Europa Anteil der Personenkilometer im öffentlichen Verkehr 0,40 %11 ein Vielfaches davon Wege mit dem Auto 95 %11 50 bis 65 % Elektrifizierte Bahnstrecke 1,7 % (Amerika)11 ~57 % in der EU11 Null Komma vier Prozent. Das ist kein Verkehrssystem mit einem Nahverkehrsanteil. Das ist ein Land, das fährt, mit ein paar Bussen darin.\nUnd 1,7 % Elektrifizierung heißt, dass die amerikanische Bahn nach wie vor ganz überwiegend Diesel fährt. Jedes Argument dafür, Güter und Menschen auf die Schiene zu holen, wird also über ein Netz gemacht, das immer noch mit Öl läuft. Elektrifiziere die Strecke, und du bekommst den Verkehrsmittelwechsel und den Brennstoffwechsel aus derselben Arbeit.\nHier ist der ehrliche Teil, denn er geht in die andere Richtung und jemand wird ihn aufbringen. Öffentlicher Verkehr ist nur effizient, wenn er voll ist. Die Besetzung der Busse in den Staaten sinkt seit Jahrzehnten, und die Energie je Personenkilometer im Bus ist seit 1970 um 63 % gestiegen.10 Ein fast leerer Bus auf einer Fünfzig-Minuten-Schleife durch eine Siedlung ist schlechter als das Auto, das er ersetzen sollte. Das ist eine echte Zahl und eine große.\nAber sieh dir an, was einen Bus leer macht. Niemand in Gehweite der Haltestelle, nichts, wohin zu gehen sich am anderen Ende lohnt, und eine Bebauung, die acht Parkplätze an jede Tür stellt. Leere Busse sind keine Tatsache über Busse. Sie sind eine Tatsache darüber, was rund um die Haltestelle gebaut wurde.\nWomit du bei dem Ding bist, das Menschen tatsächlich aus dem Auto holt, und die Lücke ist dort größer, als die Zahl zum Verkehrsmittelanteil vermuten lässt.\nVereinigte Staaten Europa Städte mit einer Metro 13 6012 Städte mit einem Straßenbahnnetz 30 weit mehr12 Zuwachs an Metro-Streckenlänge seit 2000 Basis dreimal so schnell12 Dreizehn. In einem Land mit dreihundertvierzig Millionen Menschen. Europa hat sechzig und legt seit der Jahrtausendwende dreimal so schnell neue Strecke, die Lücke wird also größer statt kleiner.\nAuch das Verkehrsmittel zählt. Eine Arbeit über europäische Städte hat gefunden, dass Metros Menschen aus dem Auto holen, Straßenbahnnetze weitgehend aber nicht, was zu dem passt, was man erwarten würde: eine Metro ist in der Hauptverkehrszeit schneller als das Auto, eine Straßenbahn meistens nicht.12 Geschwindigkeit ist das ganze Produkt. Bau etwas Langsameres als das Auto, und du hast eine Subvention für Leute gebaut, die keine Wahl haben, keine Alternative für Leute, die eine haben.\nDas ist der eine wirklich teure Posten auf der Liste. Eine Reform der Bebauungspläne kostet politischen Willen und eine Neufassung. Tunnel kosten Milliarden. Aber sie kaufen, was die anderen beiden nicht können. Du bewegst Menschen quer durch eine dichte Stadt mit Strom, mit 0,3 bis 0,6 MJ je Personenkilometer, und schneller, als sie es hätten fahren können. Ab da hört es auf, ein Verzicht zu sein, das Auto stehen zu lassen, und fängt an, das Naheliegende zu sein. Dann tun die Leute es auch.\nWas heißt, dass die Antworten dieselbe Antwort mit verschiedenen Hüten sind. Elektrifizierung nimmt 7,5 bis 12,5 Quads vom Antriebsstrang. Bebauungsplanung nimmt die Kilometer herunter. Dichte ist das, was den Nahverkehr überhaupt lohnend macht, und der Nahverkehr ist das, was die Dichte lebenswert macht. Zieh an einem Hebel, und du bekommst einen Hebel. Zieh an allen dreien, und sie multiplizieren sich.\nAmerika streitet derzeit über den ersten.\nNichts davon fängt allerdings an ohne den billigsten Schritt von allen, der gleichzeitig der schwerste aussieht. Irgendwer muss laut sagen, dass es ein Problem gibt.\nDie Diagnose fehlt nicht. Sie wird jedes Jahr von einem staatlichen Labor veröffentlicht, kostenlos, auf einer öffentlichen Website, in einem Diagramm, das klar genug ist, um es in einer Minute zu lesen. Fünfundsechzig Komma acht Prozent verloren. Der Verkehr ein Drittel davon. Einundzwanzig Prozent Wirkungsgrad auf dem größten Block der Seite. Niemand muss eine Studie in Auftrag geben oder auf die Wissenschaft warten. Die Wissenschaft kam im August heraus. Die Leute haben die Schlagzeilenzahl gelesen, falsch verstanden und sind weitergegangen.\nDas ist der Teil, der wehtun sollte. Kein Land gibt Milliarden dafür aus, unter seinen Städten zu graben, um etwas zu beheben, das es für in Ordnung hält, und Amerika hat 22,35 verlorene Quads im Jahr still unter „in Ordnung“ abgelegt. Nicht bestritten und verworfen. Nur nie auf den Tisch gelegt.\nDie Reste müssen irgendwo hin Wärme ist nur dann Verlust, wenn es nirgends hingeht. Das ist eine Planungsentscheidung, keine Technologielücke, und getroffen wurde sie größtenteils vor Jahrzehnten.\nAnteil der Fernwärme am Wärmebedarf Dänemark ~66 %13 Schweden, Finnland, Polen, das Baltikum über 50 % EU-Durchschnitt ~13 % Vereinigtes Königreich ~3 %14 Vereinigte Staaten nur Campus-, Krankenhaus- und Innenstadtprojekte Europa betreibt Stand 2025 rund 111.650 gewerbliche und industrielle Standorte mit transkritischem CO₂, etwa ein Drittel des gesamten Lebensmitteleinzelhandels.15 Metas Rechenzentrum in Odense schiebt seit 2019 rund 100.000 MWh im Jahr ins örtliche Netz. Das ist Wärme, die sonst über einen Trockenkühler weggegangen wäre. Stattdessen heizt sie 12.000 Wohnungen.13\nWir haben rund 14.000 Wärmenetze im Vereinigten Königreich, und sie decken trotzdem nur 3 % des Wärmebedarfs.14 Vierzehntausend Stück und fast nichts vorzuweisen, weil sie klein und zersplittert sind und meistens an den sozialen Wohnungsbau angeflanscht. Ofgem hat im Januar die Regulierung übernommen, und die Gebietsausweisung fängt dieses Jahr an. Ziel 7 % bis 2035, etwa ein Fünftel der Gebäudewärme bis 2050.16\nDänemark macht nichts Cleveres, das wir nicht könnten. Dänemark hat Rohre unter die Straßen gelegt. Wir nicht. Das war\u0026rsquo;s. Das ist der Unterschied.\nWärmepumpen, und das Kältemittel, mit dem niemand rechnet Dieselbe Logik am kleinen Ende. Ein elektrischer Widerstandsheizer kommt nicht über eine Leistungszahl (COP) von 1,0 hinaus. Das ist die Definition des Dings. Eine Wärmepumpe verschiebt Wärme, statt sie zu machen, also schafft sie mehr.\nSystem COP Bedingungen Widerstandselement (PTC) maximal 1,0 beliebig Wärmepumpe im Auto 2,0–3,2 0 bis 15 °C Hyundai/Kia R290, Propan angegeben 3,8 −15 °C VW R-744 (CO₂) 3,1 −20 °C17 Der ADAC hat 28 E-Autos durch einen Wintertest bei −7 °C geschickt. Die Modelle mit Wärmepumpe hatten im Schnitt 22 % weniger Reichweitenverlust als die nur mit Widerstandsheizung.18\nDie R-744-Zeile ist einen zweiten Blick wert. Das ist Kohlendioxid selbst, als Kältemittel, im VW ID.3 und ID.4. Die höhere Sauggasdichte hält die Leistung oben, während es kälter wird, also genau dann, wenn du sie brauchst.17\nUnd CO₂ in Kältemittelqualität ist ein Nebenprodukt der Ammoniak-, Ethanol- und Düngemittelherstellung, aufgefangen und gereinigt statt abgeblasen.19 Ein Abfallstrom, der heizt und kühlt, mit einem Treibhauspotenzial von 1 gegen die 1.430 von R-134a. Wenn das hier austritt, passiert nichts.\nDas ist keine CO₂-Abscheidung und ich tue nicht so, als wäre es das; die Füllung liegt unter einem Kilo. Der Punkt ist enger und besser. Das Arbeitsmittel ist etwas, wovon wir ohnehin zu viel hatten.\nWas bei mir tatsächlich läuft Technik Auslegung Warum Solaranlage 9 kW das Dach zeigt richtig, also nutze es Batterie 30 kWh schiebt die Erzeugung des Tages in den Abend E-Autos MG4, Xpeng G6 geladen an der Anlage, nicht an der Tankstelle Klimaanlage selbst versorgt läuft mit dem, was die Module machen Steuerung Home Assistant legt die großen Lasten ins günstige Fenster Nichts Exotisches auf der Liste und nichts Neues. Dasselbe Prinzip wie das Zuordnen von Speichermedien zu einem IO-Muster. Steck die Energie dorthin, wo sie sich rechnet, miss, was du tatsächlich bekommst, und hör auf, dem Schild auf der Kiste zu glauben.\nWas mich überrascht hat, war, wie viel von der Ersparnis daraus kam, keinen Kraftstoff herumzufahren. Kein Tanker, keine Tankstelle, keine Raffinerie, die sich unterwegs ihren Anteil nimmt. Die Module sind zehn Meter vom Auto weg.\nDas Diagramm ist ein Spiegel Livermore veröffentlicht diese Charts seit Jahren, und sie sind gut. Ehrlich gebaut, wirklich nützlich, kostenlos. Eine Stunde von jedermanns Zeit wert.1\nAber ein Sankey-Diagramm hat keine Meinung. Es zeigt dir maßstabsgetreu, was ein Land mit seiner Energie zu tun beschlossen hat. Die 65,8 % sind kein Naturgesetz. Sie sind ein Bild von Entscheidungen über Motoren, Rohre und Planung, einzeln getroffen über rund siebzig Jahre, und es sähe anders aus, wenn die Entscheidungen andere gewesen wären.\nDänemarks Diagramm sieht anders aus, weil Dänemark gegraben hat.\nQuellen Lawrence Livermore National Laboratory — Energy Flow Charts — die jährlichen Sankey-Diagramme zur US-Energie, einschließlich des Diagramms für 2024 und seiner Gesamtsumme von 94,6 Billiarden BTU.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nKate Morley — National Grid: Live — die Stromnachfrage Großbritanniens, im Mittel 30,9 GW über das vergangene Jahr, was etwa 271 TWh jährlich ergibt. Was dieses Dashboard zeigt, habe ich in Das Netz, das wir in Ordnung gebracht haben beschrieben.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nHawai\u0026rsquo;i State Energy Office — Statewide Energy Flowchart — legt die EIA-Methodik dar, der Livermore folgt und nach der dezentrale Solarenergie, Wasserkraft, Wind an Land und Solarkraftwerke mit 100 % Erzeugungswirkungsgrad und ohne dargestellte thermische Verluste eingehen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nEVreporter — Understanding the complete efficiency picture of electric vehicles — Wirkungsgrade von Tank bis Rad und von Batterie bis Rad für Verbrenner- und Elektroantriebe.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nConcawe — EU refinery energy systems and efficiency — der Eigenverbrauch einer Raffinerie als Anteil des Rohöleinsatzes, von 3–4 % bei einfacher Destillation bis 7–10 % und mehr bei Anlagen mit voller Konversion.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nUS Energy Information Administration — How much electricity is lost in transmission and distribution? — die jährlichen US-Verluste in Übertragung und Verteilung lagen von 2018 bis 2022 im Mittel bei etwa 5 % des übertragenen Stroms.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nUNCTAD — World seaborne trade — der Tankeranteil an der Weltflotte nach Tragfähigkeit, und die per Schiff bewegten Mengen an Rohöl und Fertigprodukten.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nUS Energy Information Administration — Light-duty vehicles\u0026rsquo; share of transportation energy use — leichte Fahrzeuge bei 58,5 % der US-Verkehrsenergie, mittlere und schwere Lkw und Busse bei 23,9 %, und der Flugverkehr als einziges weiteres Verkehrsmittel über 5 %.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCar dependency — Wikipedia und CNN — This little-known rule shapes parking in America — Automeilen je Kopf in den USA gegen Europa, der Anteil der täglichen Wege und der Wege unter einer Meile, die auf beiden Seiten des Atlantiks mit dem Auto zurückgelegt werden, die rund acht Parkplätze pro Auto, die aus den Stellplatzpflichten folgen, und das Auseinanderdriften der Stadtpolitik ab den späten 1960ern.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nBureau of Transportation Statistics — Energy intensity of passenger modes und Public transport versus private cars: a passenger-kilometre energy comparison — Energie je Personenkilometer für Benzinautos gegen gut besetzte städtische Elektrobahnen, das Emissionsverhältnis zwischen einem Auto mit einer Person und einem vollen Reisebus, und der Anstieg der Busenergie je Personenkilometer bei sinkender Besetzung.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nTransportation in the United States — Wikipedia und Statista — Share of the rail network which is electrified in Europe — der US-Anteil der Personenkilometer im öffentlichen Verkehr und im privaten Fahrzeug, und die elektrifizierte Strecke als Anteil am Netz in der EU gegen Amerika.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nStreetsblog USA — Other countries are building transit while the US falls behind und Metros reduce car use in European cities but trams do not — die Zahl der amerikanischen und europäischen Städte mit Metro- und Straßenbahnnetzen, das Tempo, in dem die Metro-Streckenlänge seit 2000 auf beiden Seiten gewachsen ist, und der Befund, dass Metrosysteme Autofahrten verdrängen, Straßenbahnnetze weitgehend aber nicht.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nState of Green — Utilising excess heat to warm up Danish homes — der dänische Fernwärmeanteil am häuslichen Wärmebedarf, und die Abwärmenutzung aus Rechenzentren einschließlich der Zahlen zur Einspeisung in Odense.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nGreater London Authority — Heat networks data report, February 2026 — der zersplitterte britische Bestand an Wärmenetzen und sein heutiger Anteil am Wärmebedarf.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nATMOsphere — European transcritical CO₂ installations — 111.650 europäische gewerbliche und industrielle Standorte mit transkritischem CO₂ im Jahr 2025, was etwa ein Drittel der Lebensmitteleinzelhandelsstandorte abdeckt.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nDepartment for Energy Security and Net Zero — Heat Network Zoning: government response — der Rahmen für die Gebietsausweisung, die Regulierung durch Ofgem ab Januar 2026, und die Ziele für 2035 und 2050.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNaturalRefrigerants.com — CO₂ heat pumps found to offer high efficiency at low ambient temperature in electric vehicles — die Leistung einer R-744-Wärmepumpe im Auto bei niedriger Außentemperatur, und die Umsetzungen im VW ID.3 und ID.4.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nInsideEVs — For maximum winter EV driving range, you want a car with this feature — der ADAC-Wintertest über 28 Elektrofahrzeuge und der Unterschied im Reichweitenverlust bei −7 °C.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNaturalRefrigerants.com — FAQs — CO₂ in Kältemittelqualität als zurückgewonnenes Nebenprodukt der Ammoniak-, Alkohol- und Düngemittelherstellung, und sein Treibhauspotenzial von 1.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://blogs.damiendye.uk/de/energy/rejected-energy-what-the-livermore-chart-shows/","summary":"Lawrence Livermore veröffentlicht jedes Jahr ein Sankey-Diagramm, das zeigt, wohin die Energie der USA geht. 2024 haben 62,27 von 94,61 Quads überhaupt keine nützliche Arbeit geleistet. Was Verlustenergie bedeutet und was ein Quad ist, warum die Methode des Diagramms erneuerbare Energien den Verlustblock schrumpfen lässt statt ihn zu füllen, warum allein der Verkehr mehr als ein Drittel des nationalen Verlusts ausmacht, und die drei Dinge, die das tatsächlich beheben würden.","title":"Verlustenergie: Was das Livermore-Diagramm wirklich zeigt"},{"content":"Webex legt ein gelbes Banner über den oberen Rand des Fensters. Offline - No internet connection. Die Telefondienste stehen auf getrennt, nichts synchronisiert, und du kommst nicht in die Besprechung, die vor neunzig Sekunden angefangen hat.\nDas ist keine Unannehmlichkeit, wenn das Ding dein Diensttelefon ist. Über Webex kommen meine Anrufe herein, und meine VoIP-Leitung läuft darüber, also ist ein Client, der sich nicht anmeldet, ein Tischtelefon, das nicht klingelt, eine Besprechung, in der ich nicht bin, und ein Kollege, der auf der Mailbox landet. Es hat mich an der Arbeit gehindert. Nicht verlangsamt, nicht eingeschränkt. Gestoppt.\nUnd nichts davon lag an mir, weder es zu verursachen noch es zu verhindern. Ein Arbeitstag ging schief wegen einer Qualitätskontrolle, die nicht stattgefunden hat, bei einem Lieferanten, der bezahlt wird, an einem Produkt, das mit Supportvertrag verkauft wird, auf einer Plattform, die dessen eigene Anforderungsseite als unterstützt nennt. Ich habe nichts falsch konfiguriert. Ich habe das Paket des Herstellers installiert, aus dem Repository des Herstellers, auf einer Plattform, die der Hersteller aufführt, und es konnte keine TLS-Verbindung aufbauen. Dann habe ich einen Abend meiner eigenen Zeit damit verbracht herauszufinden, warum, und das ist Zeit, die die Leute, die das Paket signiert haben, nicht aufgewendet haben.\nDie Maschine ist nicht offline. Der Browser daneben lädt Seiten. Deine Mail kommt an, dein Terminal zieht von einem Remote, und wenn du das Betriebssystem fragst, ob es ins Internet kommt, sagt es ja. Webex selbst stimmt dem zu, im eigenen Log, elf Sekunden bevor es dir das Gegenteil erzählt.\nWas tatsächlich passiert ist: die Kopie von OpenSSL, die Cisco in Webex mitliefert, findet keine einzige Zertifizierungsstelle, weil sie so kompiliert wurde, dass sie in /workspace/.conan2/p/b/cisco8ee8b59cf93de/p/ssl danach sucht. Das ist ein Verzeichnis auf einem Cisco-Build-Container. Es hat auf deinem Rechner nie existiert und wird es nie. Jede TLS-Verbindung der Anwendung scheitert an der Zertifikatsprüfung, das Anmelde-Token kann nicht erneuert werden, ein Fünfzehn-Sekunden-Timer läuft ab, und die Oberfläche greift zur einzigen Erklärung, für die sie eine Zeichenkette hat.\nDas Banner ist also auf eine ganz bestimmte und wenig hilfreiche Weise falsch. Es benennt dein Netz. Der Fehler ist ein Pfad in ihrem Build.\nDas ist Version 46.8.0.35631, auf Fedora 44, Kernel 7.2.4. Es ist eine unterstützte Plattform. Cisco veröffentlicht Linux-Systemanforderungen und liefert ein signiertes .rpm, webex-46.8.0.35631-1.x86_641. Was folgt, ist, wie du es in etwa zehn Minuten beweist, warum keine der naheliegenden Lösungen greift, die eine, die es tut, und dann der Teil, der wichtiger ist als alles davor: das ist kein subtiler Fehler. Das ist ein Build, den nie jemand auf einer Maschine ausgeführt hat, die ihn nicht gebaut hatte.\nWas das Banner dir tatsächlich sagt Webex betreibt seine Verbindungsanzeige über einen zusammengesetzten Automaten, sieben Teilautomaten mit je eigenen Timern. Beim Start initialisieren sie so:\nConnectivityStateMachine::ConnectivityBanner - Initializing with state: Connected ConnectivityStateMachine::Network - Initializing with state: NoNetwork ConnectivityStateMachine::Services - Initializing with state: Connected ConnectivityStateMachine::Mercury - Initializing with state: Disconnected ConnectivityStateMachine::Authentication - Initializing with state: UserNotAuthenticated ConnectivityStateMachine::Syncing - Initializing with state: Synced ConnectivityStateMachine::Survivability - Initializing with state: SurvivabilityHide Vierzig Millisekunden später meldet das Betriebssystem zurück, und die Anwendung schreibt es auf:\nNetworkManagerPowerNetworkWatcher.cpp:93 onConnectivityCheckSuccess:: The host is connected to a network, that appears to be able to reach the full Internet. Diese Zeile steht in derselben Datei, in derselben Sitzung, wie das Banner, das behauptet, es gebe keine Internetverbindung. Die Anwendung wusste es. Sie hatte die Antwort um 08:25:12.131 in der Hand und zeigte um 08:25:27.132 das Gegenteil.\nZwischen diesen beiden Momenten passiert das:\nZeit Was passiert ist 08:25:12.131 Betriebssystem bestätigt volle Internet-Erreichbarkeit 08:25:12.218 Proxy-Erkennung: keiner konfiguriert, direkte Verbindung 08:25:12.241 Erste HTTPS-Anfrage scheitert, errorCode: 167772294 Error in SSL handshake 08:25:12.569 Erneuerung des CloudApps-Zugriffstokens scheitert, gleicher Code 08:25:12.571 Erneuerung des Kms-Zugriffstokens scheitert, gleicher Code 08:25:15.684 Wiederholung, beide scheitern 08:25:21.745 Wiederholung, beide scheitern 08:25:27.132 Fünfzehn-Sekunden-Timer läuft ab, Banner schaltet auf NoInternet 08:26:12.091 Sechzig-Sekunden-Timer laufen ab, Dienste fallen auf DisconnectedShortTerm Der Authentifizierungs-Teilautomat verlässt UserNotAuthenticated nie, also leitet sich Services als getrennt ab, also feuert das Banner. Jede Stufe davon ist bei dieser Eingabe korrektes Verhalten. Die Eingabe ist falsch, und die Eingabe ist eine Zahl: 167772294, bei jeder gescheiterten Anfrage, von der ersten bis zur letzten.\nDiese Zahl ist der ganze Beitrag. Halt sie fest.\nDrei Pfade, von denen keiner existiert Webex benutzt nicht das OpenSSL des Systems. Es bringt sein eigenes mit, samt eigenem libcurl, und dieses libcurl linkt gegen das mitgelieferte und nicht gegen deins:\n$ ldd /opt/Webex/bin/libcurl.so | grep -E \u0026#39;ssl|crypto\u0026#39; libssl.so.3 =\u0026gt; /opt/Webex/bin/../lib/libssl.so.3 libcrypto.so.3 =\u0026gt; /opt/Webex/bin/../lib/libcrypto.so.3 So weit in Ordnung. Eine TLS-Bibliothek mitzuliefern ist eine vertretbare Entscheidung und viele Hersteller tun das. Es kommt darauf an, was hineingebacken wurde, und OpenSSL sagt es dir, wenn du fragst:\n$ strings /opt/Webex/lib/libcrypto.so.3 | grep -E \u0026#39;OPENSSLDIR|ENGINESDIR|MODULESDIR\u0026#39; OPENSSLDIR: \u0026#34;/workspace/.conan2/p/b/cisco8ee8b59cf93de/p/ssl\u0026#34; ENGINESDIR: \u0026#34;/workspace/.conan2/p/b/cisco8ee8b59cf93de/p/lib/engines-3\u0026#34; MODULESDIR: \u0026#34;/workspace/.conan2/p/b/cisco8ee8b59cf93de/p/lib/ossl-modules\u0026#34; Drei Stück. Nicht eine verrutschte Einstellung. Das komplette Installationspräfix, durchgeschleppt von der Maschine, die es kompiliert hat, in einer Bibliothek, die den Kunden als signiertes Paket auf einer unterstützten Plattform erreicht.\nOPENSSLDIR wird einmal gesetzt, zur Konfigurationszeit, mit --openssldir, und OpenSSLs eigene Build-Dokumentation ist deutlich, wofür es da ist: „Directory for OpenSSL configuration files, and also the default certificate and key store.“2 Alles, was unterhalb von Vertrauen hängt, hängt daran. Die Standard-CA-Datei ist cert.pem darin und das Standard-CA-Verzeichnis ist certs darin3. /workspace ist ein Conan-Build-Cache. Conan ist der C++-Paketmanager, mit dem Cisco baut, und er legt jedes Paket unter einem Hash seiner Build-Eingaben ab4. Der Hash cisco8ee8b59cf93de ist eine Tatsache über einen Container, der vermutlich Minuten nach dem Ende des Builds gelöscht wurde.\nFrag die Bibliothek, was sie ist, und es ist nicht einmal Standard-OpenSSL:\nVERSION CiscoSSL 3.5.5.8.5.4 27 Jan 2026 BUILT_ON built on: Wed Feb 25 06:29:18 2026 UTC PLATFORM platform: conan-Release-Linux-x86_64-gcc-13 DIR OPENSSLDIR: \u0026#34;/workspace/.conan2/p/b/cisco8ee8b59cf93de/p/ssl\u0026#34; Ein gepflegter hauseigener Fork, mit einem eigenen Versionsschema, im Februar gebaut, im August ausgeliefert, und immer noch mit dem Arbeitsverzeichnis darin, in dem er entstanden ist.\nWo jede Kopie von OpenSSL auf der Maschine ihre Vertrauensanker sucht Eine Maschine, zwei Kopien von OpenSSL, und nur eine weiß, wo die Zertifikate liegen Keiner Kopie wird das zur Laufzeit gesagt. Jede trägt die Antwort einkompiliert, und diese Zeichenkette setzt, wer den Build ausführt. Die System-Kopie: OpenSSL 3.5.8, Fedora 44 einkompiliertes OPENSSLDIR /etc/pki/tls das Verzeichnis ist da cert.pem \u0026#8594; tls-ca-bundle.pem certs/ \u0026#8594; gehashte Anker die Kette wird gegen echte Anker geprüft Handshake gelingt. Jedes andere Programm läuft. Genau deshalb ist der Benutzer sicher, dass das Netz geht. Die Kopie von Webex: CiscoSSL 3.5.5.8.5.4 einkompiliertes OPENSSLDIR /workspace/.conan2/p/b/cisco8ee8b59cf93de/p/ssl kein solches Verzeichnis auf Kundenmaschinen cert.pem \u0026#8594; fehlt certs/ \u0026#8594; fehlt der Store lädt null Vertrauensanker Handshake scheitert: Fehler 0x0A000086, dezimal 167772294. Das Banner sagt dem Benutzer, das Netz sei weg. Zwei Kopien von OpenSSL auf einer Maschine. Keiner von beiden wird zur Laufzeit gesagt, wo das Vertrauen liegt. Jede trägt eine einkompilierte Zeichenkette, und eine davon benennt ein Verzeichnis, das nur je auf dem Build-Host eines anderen existierte. Nimm strings nicht als Antwort. Frag die Bibliothek strings findet Text in einer Datei. Es beweist nicht, dass die Bibliothek ihn benutzt. Also lade die mitgelieferte Bibliothek und frag sie direkt, was etwa zwölf Zeilen Python braucht und kein root:\nimport ctypes c = ctypes.CDLL(\u0026#34;/opt/Webex/lib/libcrypto.so.3\u0026#34;) for f in (\u0026#34;X509_get_default_cert_file\u0026#34;, \u0026#34;X509_get_default_cert_dir\u0026#34;, \u0026#34;X509_get_default_cert_file_env\u0026#34;, \u0026#34;X509_get_default_cert_dir_env\u0026#34;): getattr(c, f).restype = ctypes.c_char_p print(f\u0026#34;{f:34} {getattr(c, f)().decode()}\u0026#34;) X509_get_default_cert_file /workspace/.conan2/p/b/cisco8ee8b59cf93de/p/ssl/cert.pem X509_get_default_cert_dir /workspace/.conan2/p/b/cisco8ee8b59cf93de/p/ssl/certs X509_get_default_cert_file_env SSL_CERT_FILE X509_get_default_cert_dir_env SSL_CERT_DIR Da steht es aus dem Mund der Bibliothek selbst. Wenn irgendetwas in Webex diese Kopie von OpenSSL nach dem Standard-Trust-Store fragt, bekommt es eine Datei und ein Verzeichnis, die es nicht gibt. Genau das tut SSL_CTX_set_default_verify_paths, und genau das tut fast jeder Client, sofern ihm nichts anderes gesagt wurde.\nDie letzten beiden Zeilen sind erwähnenswert, denn sie sind die Notausgänge: die Bibliothek lässt SSL_CERT_FILE und SSL_CERT_DIR beides überschreiben5. Merk dir auch das. Es wird wichtig, und nicht so, wie du erwarten würdest.\nDen exakten Fehlercode reproduzieren Beweis durch Hinsehen ist kein Beweis. Nimm die mitgelieferte libssl.so.3 und libcrypto.so.3, mach einen echten Handshake zu einem echten Host mit nichts als den Standardwerten der Bibliothek, und sieh, was zurückkommt.\nDer interessante Lauf ist der, in dem die Standardwerte auf nichts zeigen. SSL_CERT_FILE und SSL_CERT_DIR überschreiben genau die zwei Werte, die ein fehlendes OPENSSLDIR in der Luft hängen lässt, also reproduziert es den ausgelieferten Zustand exakt, wenn man sie auf einen nicht existierenden Pfad richtet:\n$ SSL_CERT_FILE=/nonexistent/cert.pem SSL_CERT_DIR=/nonexistent/certs python3 tls.py set_default_verify_paths -\u0026gt; 1 set_fd -\u0026gt; 1 SNI -\u0026gt; 1 SSL_connect -\u0026gt; -1 SSL_get_error -\u0026gt; 1 verify result 20: unable to get local issuer certificate err: 0xa000086 error:0A000086:SSL routines::certificate verify failed 0x0A000086 ist dezimal 167772294.\nDas ist die Zahl in jeder gescheiterten Zeile des Webex-Logs, und sie kam nicht von Webex. Sie kam aus Ciscos eigener TLS-Bibliothek, laufend außerhalb ihrer Anwendung, gescheitert aus genau einem Grund: sie hatte keine Vertrauensanker, gegen die sie die Kette prüfen konnte. Gleiche Bibliothek, gleicher Fehler, keine Anwendung dazwischen.\nRichte dieselben zwei Variablen auf das echte Fedora-Bündel, und derselbe Codepfad läuft durch:\n$ SSL_CERT_FILE=/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem python3 tls.py SSL_connect -\u0026gt; 1 SSL_get_error -\u0026gt; 0 verify result 0: ok Am Netz hat sich zwischen diesen beiden Läufen nichts geändert. Ein Dateipfad schon.\nJeder Netzschritt gelingt. Der Schritt, der scheitert, öffnet eine lokale Datei. Vier Schritte gehen über das Netz und gelingen. Der fünfte liest eine Datei und gelingt nicht. Ausgeführt gegen die gelieferten libssl.so.3 und libcrypto.so.3, außerhalb von Webex, nur mit den Standardwerten der Bibliothek. TCP connect :443 ok ClientHello, SNI ok ServerHello, Kette ok, Kette empfangen Kette gegen Vertrauen prüfen keine Anker geladen was die Bibliothek zurückmeldet SSL_connect -\u0026#62; -1 verify result 20: unable to get local issuer certificate err: 0xa000086 error:0A000086:SSL routines::certificate verify failed 0x0A000086 ist dezimal 167772294, die Zahl in jeder gescheiterten Zeile des Webex-Logs. Die Anwendung schrieb das Wort „Zertifikat“ nirgends. Sie loggte „Error in SSL handshake“ und eine Dezimalzahl, und die Oberfläche machte daraus „Offline - No internet connection“, und genau das war die Maschine nachweislich nicht. Nichts davon ist ein Netzfehler. Gefehlt hat nur ein Verzeichnis. Vier Schritte gehen über das Netz und gelingen, einschließlich des Empfangs der vollständigen Zertifikatskette des Servers. Der Schritt, der scheitert, öffnet eine lokale Datei. Dem Benutzer wird eine Meldung über seine Internetverbindung gezeigt. Warum dich nichts gewarnt hat Zwei Dinge wirken zusammen, damit das lautlos bleibt, und nur eines davon ist Ciscos Schuld.\nWas nie ein Wort sagt Wessen Entwurf Warum es still bleibt Einen Trust Store laden, den es nicht gibt OpenSSLs, absichtlich SSL_CTX_set_default_verify_paths gibt 1 zurück, ob die Pfade echt sind oder nicht. „A missing default location is still treated as a success“3 Nichts haben, worauf man zurückfällt Ciscos, und richtig Zertifikate werden geprüft, selbstsignierte abgelehnt, SSL-Wiederholung aus, es gibt also keinen eingeschränkten Modus, der einen Fehler verdecken könnte Das Erste ist vernünftig. Ein Programm, das seine Anker separat mitbringt, sollte nicht gezwungen sein, sich darum zu kümmern, also gelingt der Aufruf, der Store ist leer, und nirgends im Stapel sagt irgendetwas ich habe null Zertifizierungsstellen geladen. Das Erste, was es merkt, ist ein Prüffehler eine halbe Sekunde später. Ich habe diesen Aufruf gegen die mitgelieferte Bibliothek laufen lassen, mit den Pfaden auf /nonexistent, und er gab 1 zurück. Es steht in der Ausgabe oben.\nDas Zweite ist eine Richtlinie, die vom Dienst kommt, und das Log hält sie fest:\nWdm.cpp:1162 parseDeviceJson: Adding policy \u0026lt;\u0026lt; allowSelfSignedCertificate with value: false NetworkManager.cpp:1738 onConfigReady: ...httpRequestSSLRetryEnabled: 0 HttpRequestManager.cpp:1883 rawHttpRequest: {\u0026#34;validateCertificates\u0026#34;:\u0026#34;true\u0026#34;,\u0026#34;useClientCertificate\u0026#34;:\u0026#34;false\u0026#34;} Diese drei Schalter sind der einzige Grund, warum dieser Fehler ein Ausfall ist und nicht etwas weit Schlimmeres, und dabei lohnt es sich zu verweilen, statt daran vorbeizuhasten.\nDenk es durch. Die mitgelieferte Bibliothek lädt null Vertrauensanker, und unterhalb der Richtlinienebene hätte das nie etwas bemerkt, weil der Fehler über den ganzen Weg nach unten absichtlich still ist. Was daraus ein Banner gemacht hat, waren drei Schalter. Dreh einen davon so, wie ihn reichlich Clients ausliefern, und derselbe Build scheitert überhaupt nicht. Er verbindet sich, mit allem, was irgendein Zertifikat vorhält, weil er nichts hat, wogegen er eines prüfen könnte.\nDerselbe kaputte Trust Store, einen Richtlinienschalter von einem ganz anderen Fehler entfernt Der Vertrauenspfad ist in beiden Spalten gleich kaputt. Nur die Richtlinie entscheidet, wie du es erfährst. Beiden gemeinsam: das einkompilierte OPENSSLDIR existiert nicht, also lädt der Store null Zertifizierungsstellen Wie Webex es ausliefert validateCertificates: true allowSelfSignedCertificate: false httpRequestSSLRetryEnabled: 0 Nichts zum Prüfen da, also verweigert er. Handshake scheitert. Banner. Du verlierst einen Tag. Laut und harmlos. Einer davon andersherum gesetzt validateCertificates: false oder selbstsignierte erlaubt oder Wiederholung ohne Prüfung Nichts zum Prüfen da, also macht er weiter. Handshake gelingt. Gegen alles. Leise und nicht harmlos. Die beiden Ergebnisse trennte ein Richtlinienwert, gesetzt von einem anderen Team, unterhalb des Defekts, aus unabhängigen Gründen. Der Vertrauenspfad hat nie jemanden geschützt. Er war durchgängig kaputt, offen war nur, in welche Richtung er scheitert. Der Unterschied zwischen „Webex ist heute offline“ und „Webex hat vertraut, was auch immer geantwortet hat“ ist ein Richtlinienwert, gesetzt von einem anderen Team, unterhalb des Defekts, aus Gründen, die nichts damit zu tun haben. Wie es an die Oberfläche kommt, ist das Problem. Der Benutzer bekommt „Offline - No internet connection“. Das Log bekommt „Error in SSL handshake“ und eine Dezimalzahl. Das Wort Zertifikat taucht nirgends auf, wo ein Benutzer oder ein Supportmitarbeiter der ersten Ebene je hinsehen wird, und die eine diagnostische Brotkrume ist eine Zahl, die du erst nach hex umrechnen musst, damit sie etwas bedeutet.\nDie Lösungen, die nicht funktioniert haben Beide naheliegenden scheitern, und die Gründe sind verschieden und beide wissenswert.\nDie mitgelieferte openssl.cnf bearbeiten Webex liefert eine Konfigurationsdatei unter /opt/Webex/lib/openssl.cnf mit, und im Auslieferungszustand aktiviert sie einen Provider:\n[provider_sect] fips = fips_sect Nur FIPS. Nicht den default-Provider, in dem die gewöhnlichen TLS-Algorithmen wohnen6. Ihn wieder hinzuzufügen ist eine einzeilige Änderung und ändert überhaupt nichts, weil das mitgelieferte OpenSSL diese Datei nie liest. Es sucht openssl.cnf innerhalb von OPENSSLDIR7, und OPENSSLDIR ist der Pfad, den es nicht gibt. Die Datei liegt im Installationsverzeichnis und sieht maßgeblich aus. Nichts liest sie.\nEs ist ein zweiter Defekt, der sich hinter dem ersten versteckt. Selbst wenn das Pfadproblem morgen behoben würde, indem man OPENSSLDIR auf /opt/Webex/lib richtet, würde diese Konfiguration dann geladen und aktivierte nur FIPS. Und das FIPS-Modul selbst wird aus MODULESDIR geladen, dem dritten toten Pfad aus demselben Baum, also kann auch die in /opt/Webex/lib mitgelieferte fips.so nicht gefunden werden. Drei Pfade, ein falsches Präfix, und jeder einzelne so kaputt, dass er den nächsten verdeckt.\nDie Umgebungsvariablen setzen Die Bibliothek beachtet SSL_CERT_FILE und SSL_CERT_DIR. Das habe ich oben bewiesen. Der erfolgreiche Lauf steht genau da. Der naheliegende Schritt ist also, sie im Desktop-Eintrag zu setzen, und das wurde versucht:\nExec=env OPENSSL_CONF=/opt/Webex/lib/openssl.cnf \\ SSL_CERT_FILE=/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem \\ SSL_CERT_DIR=/etc/pki/tls/certs/ /opt/Webex/bin/CiscoCollabHost %U Keine Änderung. Und der Grund ist nicht, dass Webex die Variablen ignoriert. Der Grund ist, dass der Prozess sie nie bekommen hat:\n$ tr \u0026#39;\\0\u0026#39; \u0026#39;\\n\u0026#39; \u0026lt; /proc/20293/environ | grep -E \u0026#39;SSL|OPENSSL|CURL\u0026#39; $ tr \u0026#39;\\0\u0026#39; \u0026#39;\\n\u0026#39; \u0026lt; /proc/20293/environ | wc -l 99 Neunundneunzig Variablen im laufenden Webex-Prozess, und keine einzige davon eine der drei gesetzten. Weil es auf dieser Maschine zwei Desktop-Einträge mit demselben Namen gibt:\nDatei Was ihre Exec-Zeile ausführt Geschrieben von /usr/share/applications/webex.desktop die dreifache env-Zeile von oben, vollständig dem .rpm, danach von Hand bearbeitet ~/.local/share/applications/webex.desktop /opt/Webex/bin/CiscoCollabHost %U, und gar keine Umgebung Webex\u0026rsquo; eigenem Launcher Und die Spezifikation ist nicht mehrdeutig darin, welche gewinnt: „The base directory defined by $XDG_DATA_HOME is considered more important than any of the base directories defined by $XDG_DATA_DIRS.“8 $XDG_DATA_HOME ist ~/.local/share. Die Benutzerkopie überdeckt die paketierte, jedes Mal, auf jedem Desktop, der sich an die Spezifikation hält9.\nWebex installiert also eine zweite Kopie seines eigenen Launchers in dein Heimatverzeichnis, und diese Kopie ist die, die dein Desktop ausführt. Ändere die paketierte Datei so viel du willst. Du bearbeitest ein Dokument, das nichts liest.\nZwei Desktop-Einträge gleichen Namens, und es gewinnt der, den Webex sich selbst schreibt Die Umgebung wurde in der Datei gesetzt, die der Desktop nie liest Zwei Einträge, ein Name. Die Suchreihenfolge steht geschrieben, und sie bevorzugt die paketierte Kopie nicht. Von Hand bearbeitet, und überstimmt /usr/share/applications/webex.desktop Exec=env OPENSSL_CONF=... SSL_CERT_FILE=... wird nie gelesen, solange die andere Datei existiert Von Webex geschrieben, und sie gewinnt ~/.local/share/applications/webex.desktop Exec=/opt/Webex/bin/CiscoCollabHost %U gar keine Umgebung gesetzt verworfen gestartet XDG-Basisverzeichnis-Spezifikation: das durch $XDG_DATA_HOME definierte Basisverzeichnis gilt als wichtiger als jedes durch $XDG_DATA_DIRS definierte Basisverzeichnis. Beweis, aus dem laufenden Prozess statt aus Überlegung: tr '\\0' '\\n' \u0026#60; /proc/20293/environ | grep -E 'SSL|OPENSSL' \u0026#8594; keine Ausgabe, 99 Variablen, keine davon Die Lösung war echt, die Datei war echt, und der Prozess, für den sie gedacht war, kam von ganz woanders. Die Umgebung wurde in der Datei gesetzt, die der Desktop nie liest. Webex schreibt seinen eigenen Eintrag unter das Datenverzeichnis des Benutzers, die Spezifikation sagt, dass dieser den paketierten übertrifft, und der Beweis ist der laufende Prozess: neunundneunzig Umgebungsvariablen und keine der drei. Die Lösung, die funktioniert Wenn die Bibliothek auf einem Pfad besteht, gib ihr den Pfad. Erzeuge das Verzeichnis, nach dem sie zu suchen kompiliert wurde, und füll es mit Symlinks auf das Echte:\n#!/bin/bash # Point the bundled CiscoSSL at the system trust store by building the # directory it was compiled to look for. Tested: Fedora 44, Webex 46.8.0.35631. set -euo pipefail OPENSSLDIR=$(strings /opt/Webex/lib/libcrypto.so.3 \\ | grep -oP \u0026#39;(?\u0026lt;=OPENSSLDIR: \u0026#34;)[^\u0026#34;]+\u0026#39;) [ -n \u0026#34;$OPENSSLDIR\u0026#34; ] || { echo \u0026#34;no OPENSSLDIR found in the shipped library\u0026#34;; exit 1; } for p in /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem \\ /etc/ssl/certs/ca-certificates.crt \\ /etc/pki/tls/certs/ca-bundle.crt \\ /etc/ssl/cert.pem; do [ -f \u0026#34;$p\u0026#34; ] \u0026amp;\u0026amp; { CA_BUNDLE=\u0026#34;$p\u0026#34;; break; } done [ -n \u0026#34;${CA_BUNDLE:-}\u0026#34; ] || { echo \u0026#34;no system CA bundle found\u0026#34;; exit 1; } echo \u0026#34;OPENSSLDIR: $OPENSSLDIR\u0026#34; echo \u0026#34;CA bundle: $CA_BUNDLE\u0026#34; sudo mkdir -p \u0026#34;$OPENSSLDIR\u0026#34; sudo ln -sf \u0026#34;$CA_BUNDLE\u0026#34; \u0026#34;$OPENSSLDIR/cert.pem\u0026#34; sudo ln -sf \u0026#34;$(dirname \u0026#34;$CA_BUNDLE\u0026#34;)\u0026#34; \u0026#34;$OPENSSLDIR/certs\u0026#34; sudo tee \u0026#34;$OPENSSLDIR/openssl.cnf\u0026#34; \u0026gt; /dev/null \u0026lt;\u0026lt;\u0026#39;CONF\u0026#39; openssl_conf = openssl_init [openssl_init] providers = provider_sect [provider_sect] default = default_sect fips = fips_sect [default_sect] activate = 1 CONF echo \u0026#34;done. now restart Webex\u0026#34; Starte es neu, und dieselbe Startsequenz erzeugt das gegenteilige Ergebnis. Gleiche Binärdatei. Gleiche Log-Zeilen. Die Token-Erneuerung, die vorher innerhalb von sechzig Millisekunden scheiterte, ist jetzt nach dreihundertdreißig fertig:\nAuthTokenRequester.cpp:579 Managed to fetch a new Kms access token. AuthTokenRequester.cpp:579 Managed to fetch a new CloudApps access token. AuthTokenSupervisor.cpp:310 Auth tokens refreshed. Expires in [64799 secs]. AuthenticationManager.cpp:1860 onUserAuthenticated: User authenticated. ConnectivityStateMachine::Authentication - UserNotAuthenticated -\u0026gt; UserAuthenticated Nach etwa 750 ms authentifiziert, der Fünfzehn-Sekunden-Timer feuert also nie und das Banner erscheint nie. Die Telefondienste gehen von Disconnected auf Connecting, einen Zustand, den die kaputte Sitzung in einer Minute Versuchen nie erreicht hat.\nVorher Nachher Netzprüfung besteht besteht Erste HTTPS-Anfrage 167772294 Error in SSL handshake HTTP 200 CloudApps-Token gescheitert geholt Kms-Token gescheitert geholt Authentifizierung hängt bei UserNotAuthenticated UserAuthenticated Banner nach 15 s „Offline - No internet connection“ keins Telefondienste nie versucht verbindet Zeit bis zur Authentifizierung nie ~750 ms Beachte, was die Lösung mit deinem Dateisystem macht, denn das sollte dich stören. Sie erzeugt auf deiner Maschine ein Verzeichnis /workspace auf oberster Ebene, einen Namen, für den der Filesystem Hierarchy Standard keinen Platz hat10, und darin einen Conan-Cache-Pfad und einen Build-Hash, die einer Firma gehören, von der du Software gekauft hast. Das ist die Form der Abhilfe, die Cisco dir hinterlassen hat: häng die Build-Umgebung eines anderen in die Wurzel deiner eigenen.\nSie wird auch kaputtgehen. Auf drei Arten:\nWann sie kaputtgeht Warum Was du tust Ein Webex-Update cisco8ee8b59cf93de leitet sich aus den Build-Eingaben ab, eine neu gebaute Abhängigkeit bedeutet also ein neues Verzeichnis Das Skript erneut laufen lassen; es liest den Pfad aus der neuen Binärdatei, statt die alte anzunehmen Eine Distributionsänderung Das Ziel des Symlinks ist eine Entscheidung der Distribution, kein Standard11 Neu ausrichten; das Skript probiert vier bekannte Orte Eine Neuinstallation /workspace wird von nichts gesichert, paketiert oder besessen Führ es wieder aus, jedes Mal, für immer Nichts davon ist Wartung. Das bist du, wie du für einen Schritt in der Build-Pipeline eines anderen einspringst, auf unbestimmte Zeit, unbezahlt. Einen Defekt zur Laufzeit flicken, auf jeder Maschine, die du besitzt, weil der Hersteller ihn nicht einmal zur Build-Zeit flicken wollte.\nSie kannten die Regel und haben sie auf die Hälfte des Builds angewendet Hier ist, was das von einem Fehlerbericht zu einem Argument macht.\nLies den dynamischen Abschnitt der ausgelieferten Binärdateien:\n$ readelf -d /opt/Webex/bin/libcurl.so | grep RUNPATH 0x1d (RUNPATH) Library runpath: [$ORIGIN:$ORIGIN/../lib] $ readelf -d /opt/Webex/bin/CiscoCollabHost | grep RUNPATH 0x1d (RUNPATH) Library runpath: [$ORIGIN/../lib] $ORIGIN wird zur Ladezeit zu dem Verzeichnis aufgelöst, in dem das Objekt selbst liegt12. Es ist das richtige Werkzeug für ein verschiebbares Bündel, und sie haben es richtig benutzt. Sie mussten: Webex liefert denselben Baum zweimal aus, einmal nach /opt/Webex und einmal nach ~/.local/share/WebexLauncher/46.8.0.35631_9e6196c9-…/, und ein Launcher wählt beim Start zwischen beiden. Zwei Präfixe, ein Build, und der Linker findet seine Bibliotheken in beiden.\nDie Leute, die dieses Paket gemacht haben, haben das Problem also genau verstanden. Absolute Pfade überleben das Ausliefern nicht. Für den Code haben sie es gelöst.\nDann haben sie die Datenpfade als absolute Zeichenketten stehen lassen, die den Container benennen, der sie kompiliert hat. Gleicher Build. Gleicher Nachmittag.\nEin Pfad im Bündel verschiebt sich selbst. Der andere benennt eine Maschine in irgendeinem Rechenzentrum. Sie wussten, dass das Bündel umziehen muss. Angewendet haben sie es nur auf den Code. Beide Werte werden zur Build-Zeit von denselben Leuten am selben Tag gesetzt. Einer löst sich zur Ladezeit auf, der andere nie. Woher der Code kommt: als relativer Ausdruck hinterlegt RUNPATH in libcurl.so $ORIGIN:$ORIGIN/../lib /opt/Webex/lib aufgelöst ~/.local/share/WebexLauncher/46.8.0.35631_.../lib auch aufgelöst Richtig, und mit Absicht. Derselbe Baum geht zweimal an zwei Präfixe, und der Linker findet ihn in beiden. Woher das Vertrauen kommt: als jemandes Arbeitsverzeichnis hinterlegt OPENSSLDIR in libcrypto.so.3 /workspace/.conan2/p/b/cisco8ee.../p/ssl kein solcher Pfad nicht aufgelöst ENGINESDIR und MODULESDIR: derselbe Baum, dasselbe Ergebnis Drei absolute Pfade in einen Build-Container, an jeden Kunden geliefert, bei einem Produkt mit Supportvertrag. Zwischen den beiden Hälften dieses Bildes liegt eine Person, die das Paket auf einer Maschine ausführt, die es nicht gebaut hat. Das ist der ganze Defekt. Kein schwerer Fehler. Ein ungetesteter. Derselbe Build, derselbe Tag, dieselben Ingenieure. Der Suchpfad für Bibliotheken ist als Ausdruck hinterlegt, der sich dort auflöst, wo der Baum landet. Der Vertrauenspfad ist als jemandes Arbeitsverzeichnis hinterlegt. Das lässt sich also nicht unter die wussten es nicht ablegen. In $ORIGIN stolpert man nicht hinein. Man greift danach, weil man verstanden hat, dass ein absoluter Pfad, der in ein ausgeliefertes Artefakt gebacken ist, ein Defekt ist, und es gut genug verstanden hat, um es im Linker zu beheben. Dann schreibt derselbe Build drei absolute Pfade in dieselben Bibliotheken und liefert sie aus.\nDie Regel zu kennen und sie auf die Hälfte des Builds anzuwenden, ist schlimmer, als sie nicht zu kennen. Nicht zu wissen ist ein Schulungsproblem, und für Schulung gibt es eine Lösung. Das hier ist ein Paket, in dem die richtige Idee steckte, schriftlich, im ELF-Header, wo sie jeder hätte lesen können, und es ging trotzdem kaputt zur Tür hinaus. Was dir sagt, dass nichts unterhalb des Compilers auf das Ergebnis geschaut hat. Nichts hat es.\nDer Container war schon da Woher /workspace kommt, ist kein Rätsel, und raten musst du auch nicht. Es steht im Paket-Header:\n$ rpm -qi webex | grep -E \u0026#39;Build Host|Build Date|Vendor\u0026#39; Build Date : Sat 08 Aug 2026 20:47:43 BST Build Host : c964ea9239ae Vendor : Cisco c964ea9239ae ist kein Hostname, den jemand getippt hat. Es sind zwölf hexadezimale Zeichen, und genau das meldet ein Container als Hostnamen, wenn niemand einen setzt. Das Paket wurde also in einem Container gebaut, von einer Firma, die offenkundig die Images, die Registry und die Orchestrierung dafür hat, und drei getrennte Artefakte auf dieser Maschine sagen das unabhängig voneinander:\nBelege, abgelesen am installierten Paket Wert Was es beweist Build Host im RPM-Header c964ea9239ae eine Container-ID, keine Build-Maschine OPENSSLDIR in libcrypto.so.3 /workspace/.conan2/… ein Pfad, den es nur in diesem Container gibt PLATFORM in derselben Bibliothek conan-Release-Linux-x86_64-gcc-13 eine containerisierte Conan-Toolchain Requires im RPM glibc \u0026gt;= 2.28 eine bewusst gewählte, sehr alte ABI-Untergrenze Dann haben sie es signiert. Der Build war um 20:47:43 fertig und die Signatur ist auf 21:02:07 desselben Abends datiert, Schlüssel-ID 9995e5bbb5ccde3c. Fünfzehn Minuten. Es gibt also ein Freigabetor, jemand oder etwas bedient es, und was es bezeugt, ist wer das Paket gemacht hat, nicht ob das Paket funktioniert. Eine Signatur ist eine Aussage über die Herkunft. Sie war nie eine Aussage über die Tauglichkeit, und ein Prozess, der das eine hat und das andere nicht, hat seine Prioritäten in der falschen Reihenfolge.\nDenn der fehlende Schritt ist der billige. Der Container ist schon in der Pipeline. Nimm das Artefakt, das gerade herauskam, starte ein sauberes Image jeder Distribution, die du zu unterstützen behauptest, installiere es, starte es und lies die ersten hundert Zeilen des Logs:\ndocker run --rm fedora:44 sh -c \u0026#39; dnf -y install ./webex-46.8.0.35631-1.x86_64.rpm \u0026amp;\u0026amp; timeout 25 /opt/Webex/bin/CiscoCollabHost \u0026amp; sleep 20 grep -c \u0026#34;Error in SSL handshake\u0026#34; ~/.local/share/Webex/current_log.txt\u0026#39; Ungleich null, jedes Mal, bei diesem Build. Die Installation ist 1,1 GB groß, rechne also mit einer Minute je Ziel bei warmem Cache. Sechs Distributionen sind sechs Minuten auf einer Maschine, die ohnehin läuft, auf Hardware, die Cisco ohnehin besitzt, in einer Pipeline, die es ohnehin gibt. Es wurde nicht ausgeführt. Kein einziges Mal.\nUnd das ist die Antwort auf das, was Leute über Linux immer noch sagen, dass mehrere Distributionen zu unterstützen schwer sei. Es hat an dem Tag aufgehört schwer zu sein, an dem dieses Werkzeug kam, und das Werkzeug ist dasselbe, mit dem sie kompilieren. Ein Basis-Image je Ziel. Dasselbe Artefakt in jedes. Die Matrix ist eine Schleife.\nEine Pipeline, die in einem Container baut und das Ergebnis nie in einem ausführt, ist keine Pipeline. Sie ist ein Compiler mit einem Cronjob davor und einem Signaturschlüssel dahinter, und was immer dabei herauskommt, ist geraten.\nSie bauen in einem Container und führen das Ergebnis nie in einem aus Der Container ist schon in der Pipeline. Benutzt wird er nur für die Hälfte, die dem Hersteller passt. Jeder Wert unten ist aus dem installierten Paket abgelesen, nicht erschlossen. Build, in einem Container Build Host: c964ea9239ae /workspace/.conan2/p/b/... conan-Release-Linux-x86_64-gcc-13 drei getrennte Belege für einen Container Signieren und veröffentlichen gebaut 20:47:43 signiert 21:02:07 fünfzehn Minuten, und ein Freigabetor das bezeugt wer, nie ob Kunde dnf install webex öffnet es \"Offline - No internet\" Der Schritt, der nirgends in der Pipeline steht docker run --rm fedora:44 sh -c 'dnf -y install ./webex.rpm \u0026amp;\u0026amp; CiscoCollabHost \u0026amp; sleep 20; grep -c \"Error in SSL handshake\" ~/.local/share/Webex/current_log.txt' Dieselbe Infrastruktur. Ein Image je Zieldistribution. Unter einer Minute pro Stück, und bei diesem Build scheitert es laut. Für mehrere Distributionen zu bauen hörte an dem Tag auf schwer zu sein, an dem dieses Werkzeug kam, und es ist dasselbe Werkzeug, mit dem sie kompilieren. Eine Pipeline, die in einem Container baut und das Ergebnis nie in einem ausführt, ist ein Compiler mit einem Cronjob davor und einem Signaturschlüssel dahinter. Drei unabhängige Belege im ausgelieferten Paket dafür, dass der Build in einem Container lief, eine Signatur fünfzehn Minuten nach dem Build, und der eine Schritt, der nirgends auftaucht: das fertige Paket in einem sauberen Image jeder Plattform auszuführen, für die es als unterstützt verkauft wird. Warum wird ein Release von 2026 gegen eine Libc von 2018 gebaut? Das Paket erklärt, was es braucht, und die interessante Zeile ist die erste:\n$ rpm -q --requires webex | grep glibc glibc \u0026gt;= 2.28 glibc 2.28 erschien am 1. August 201813. Es ist die Version in Red Hat Enterprise Linux 814, einem Release, dessen voller Support 2024 endete. Das hier ist ein Produkt von 2026, 2026 kompiliert, das auf die C-Bibliothek von 2018 zielt. Und dann liefert es seine eigene 2,5 MB große Kopie von libstdc++.so.6 ins Heimatverzeichnis des Benutzers, weil die C++-Laufzeit, die zu einer so alten Basis gehört, den Code nicht tragen kann.\nWarum macht das überhaupt noch jemand? Weil sie nicht statisch linken wollen.\nDas ist die ganze Geschichte. In dem Moment, in dem du dynamisch gegen die C-Bibliothek des Hosts linkst, wird die älteste Distribution, die du unterstützen willst, zu einer Einschränkung für die Maschine, auf der du kompilierst. Du kannst kein Symbol benutzen, von dem das älteste Ziel nie gehört hat, also nagelst du den Build auf ein uraltes Basis-Image und bleibst dort. Jedes Jahr wird die Lücke größer. Jede neue Sprach- oder Bibliotheksfunktion kommt mit einer Diskussion darüber, ob die Untergrenze steigen darf. Liefere dein eigenes libstdc++ mit, um das Schlimmste zu übertünchen, und du pflegst jetzt auch noch eine private Laufzeitumgebung.\nDieser Handel ergab Sinn, als ein Build-Host eine physische Maschine im Rack war, die jemand neu aufsetzen musste. Seit einem Jahrzehnt ergibt er keinen Sinn mehr. Wenn du gegen die libc des Hosts linken musst, gibt dir ein Container je Ziel einen echten Build auf einer echten Version jeder Plattform, und keine davon schränkt die anderen ein.\nAber sieh dir an, was die Disziplin mit dem alten Ziel hier tatsächlich gebracht hat. Es ist ABI-Konservatismus zu erheblichen Kosten: eine acht Jahre alte Untergrenze, eine mitgelieferte C++-Laufzeit, eine darum eingefrorene Supportmatrix. Und der Client startet trotzdem nicht. Weil das, was kaputtging, ein Dateipfad war, und keine noch so große Sorgfalt bei Symbolversionen schützt einen Dateipfad. Sie haben die Kompatibilitätssteuer und die Bündelsteuer bezahlt und die eine Prüfung ausgelassen, die nichts kostet. Beide Rechnungen. Kein Produkt.\nSie haben für ein eigenständiges Bündel bezahlt und keins bekommen Der althergebrachte Weg, kommerzielle Software unter Linux auszuliefern, ist, von so wenig vom Host abzuhängen wie möglich. Statisch, wo es geht, ein eigenständiger Baum, wo es nicht geht, und keine Annahmen über die Distribution darunter. Es ist nicht elegant und niemand behauptet das. Es gibt das wegen der Alternative. Eine Binärdatei, die eine bestimmte Version einer bestimmten Bibliothek an einer bestimmten Stelle braucht, macht aus der Maschine jedes Kunden einen Supportfall.\nCisco ist den zweiten Weg gegangen und hat gebündelt. Hier ist die Rechnung:\nWas das Bündel enthält Größe oder Anzahl Shared Objects in /opt/Webex/lib 150 Ihr eigenes libcurl, CiscoSSL, zlib-ng, ICU, Kerberos, CUPS-Client, hunspell und Inferenz-Engine alle davon Installiert unter /opt/Webex 1,1 GB Eine zweite Kopie unter ~/.local/share/WebexLauncher, je Benutzer 1,1 GB Auf der Platte für einen Chat- und Telefonie-Client 2,2 GB Zwei Gigabyte Abhängigkeiten. Das ist der volle Preis des Bündelns: der Download, die Platte, die Doppelung, die Sicherheitslast, die einzige Partei zu sein, die irgendetwas davon patchen kann, alles zusammen. Zahl das, und was du bekommst, ist ein Programm, dem es egal ist, was auf dem Host installiert ist, das sich auf Fedora und Debian und Arch und was immer ein Kunde dieses Jahr standardisiert hat gleich verhält, und das kein Distributions-Upgrade kaputtmachen kann, von dem es nie gehört hat.\nNur tut es das eben doch. Es kümmert sich sehr um ein Verzeichnis, und das ist ein Verzeichnis auf einem Build-Server.\nSie haben ihr eigenes Kerberos und ihr eigenes ICU und ihre eigene Rechtschreibprüfung mitgeliefert, und einen funktionierenden Pfad zu den Zertifikaten konnten sie nicht mitliefern. Der ganze Zweck des Bündels ist, eigenständig zu sein, und in dem einen Punkt, der es zum Laufen bringt, ist es nicht eigenständig. Jedes einzelne dieser 1,1 GB wird über $ORIGIN korrekt gefunden. Die gut vierzig Bytes, auf die es am meisten ankommt, nicht.\nUnd das ist der Teil, der mich packt. Bündeln ist die teure Option. Sie haben die Kosten getragen, sie haben die schwere Ingenieursarbeit gemacht, sie haben die Verschiebbarkeit für hundertfünfzig Bibliotheken über zwei Installationspräfixe hinbekommen. Und dann den einen Teil, der entscheidet, ob irgendetwas davon funktioniert, auf eine Maschine gerichtet, die nie ein Kunde besessen hat.\nDokumentiert hat es auch niemand Neben dem ersten Fehler sitzt ein zweiter, und es ist der, der den ersten gefunden hätte.\nFrag das Paket, welche Dokumentation es mitbringt:\n$ rpm -qd webex | wc -l 0 $ rpm -qc webex | wc -l 0 Keine Dokumentationsdateien. Und keine Konfigurationsdateien. Null Einträge mit %config in einem Paket, das eine openssl.cnf ausliefert. Das ist nicht kosmetisch. Ein RPM markiert eine Datei als %config, damit der Paketmanager bewahrt, was der Administrator geändert hat, und eine .rpmsave anlegt, statt sie zu überschreiben1516. /opt/Webex/lib/openssl.cnf wird als gewöhnliche Datei ausgeliefert, das nächste Update überschreibt also jede Änderung, die du daran gemacht hast, und sagt dir nichts. Die eine Datei, die ein Kunde berechtigterweise anpassen müsste, ist die, die die Paketierung als Wegwerfware behandelt.\nNichts Veröffentlichtes sagt, welchen Trust Store der Client benutzt, welche Umgebungsvariablen er beachtet oder woher er seine TLS-Konfiguration liest. Es gibt keine Seite zum Nachsehen. Es wurde keine geschrieben. Der einzige Weg, irgendetwas davon festzustellen, waren strings, readelf, ldd und ctypes gegen die ausgelieferten Binärdateien. Ein unterstütztes Produkt zurückentwickeln, um eine Frage zu beantworten, die seine Dokumentation in einem Satz hätte beantworten müssen.\nUnd hier ist, warum das mehr zählt, als es klingt. Diese Dokumentation zu schreiben ist selbst ein Test. Setz irgendwen beim Hersteller vor ein leeres Blatt mit der Überschrift woher Webex für Linux seine CA-Zertifikate liest, und das Erste, was er tun muss, ist nachsehen. In dem Moment, in dem er nachsieht, findet er /workspace/.conan2/p/b/cisco8ee8b59cf93de/p/ssl, und das Nächste, was aus ihm herauskommt, ist eine Frage. Dokumentierte Konfigurationspfade sind kein Papierkram zugunsten des Kunden. Sie sind die billigste Prüfung, die ein Hersteller an seinem eigenen Build vornehmen kann, und sie auszulassen ist der Weg, auf dem so ein Pfad bis in ein Release überlebt.\nNichts davon ist viel verlangt. Sag, wo deine Konfiguration liegt. Sag, welche Umgebungsvariablen du beachtest. Markiere deine Konfigurationsdateien als Konfiguration, damit ein Update sie nicht auffrisst. Dann hat der Kunde, der auf einen Fehler stößt, einen Ort zum Nachsehen, der kein Hex-Editor ist.\nNiemand hat es ausgeführt Der fehlende Schritt ist oben oft genug benannt worden. Wert zu fragen ist, warum er auf dieser Plattform fehlte und auf den anderen nicht.\nAuf Fedora jedenfalls nicht. Auf macOS und dem Fisher-Price OS (Windows) kann diese Fehlerklasse nicht auf dieselbe Weise auftauchen, weil diese Plattformen einen System-TLS-Stapel mit einem Trust Store haben, den das Betriebssystem verwaltet. Linux hat so etwas nicht. OpenSSL ist der Trust Store, und entsprechend gehört dem, der es ausliefert, auch die Frage, wo es sucht. Die eine Plattform also, auf der die mitgelieferte Bibliothek tragend ist, ist die Plattform, die ungetestet ausgeliefert wurde, was eine Entscheidung darüber ist, welche Kunden einen Rauchtest wert sind.\nDie ganze Untersuchung hat einen Abend gedauert: das Log lesen, bemerken, dass die Netzerkennung bestand, bevor das Banner das Gegenteil behauptete, den kompilierten Pfad aus der Binärdatei ziehen, den exakten Fehlercode gegen die ausgelieferte Bibliothek reproduzieren. Das alles mit einem KI-Agenten, der die Log-Korrelation und das ctypes-Gerüst gemacht hat, während ich mir überlegt habe, was ich ihn fragen soll. Ich erwähne das aus einem Grund: die Diagnose, die ein Hersteller nie gestellt hat, bevor er dieses Paket signiert und in sein eigenes Repository gelegt hat, liegt jetzt für jeden Kunden mit der Geduld nachzusehen in Reichweite eines Abends. Ciscos Ingenieuren steht Claude genauso zur Verfügung wie allen anderen, und es hätte das ordentlich gebaut. Du kannst es nicht bitten, /workspace/.conan2 in ein auszulieferndes Artefakt zu backen, ohne dass es dir sagt, was passiert, wenn das Artefakt den Workspace verlässt. Das Werkzeug, das das findet, ist nicht mehr knapp, und das Wissen auch nicht. Was fehlt, ist jemand beim Hersteller, dessen Aufgabe es war hinzusehen.\nUnterdessen ist der Supportweg für den, der darauf stößt, ein Banner, das sagt, sein Internet sei weg. Er wird den Router neu starten. Er wird seinen Anbieter anrufen. Er wird ein Ticket aufmachen, das ins Leere läuft, weil das Symptom, das Cisco anzuzeigen beschlossen hat, von Cisco wegzeigt.\nDas ist die vollständige Liste dessen, was schiefgelaufen ist. Es lohnt sich zu sagen, wie richtig ausgesehen hätte, denn zu jedem Punkt darauf gibt es eine feststehende Antwort, die älter ist als dieses Produkt.\nWie es hätte gebaut werden müssen Genug davon, was schiefgelaufen ist. Hier ist der Maßstab, und nichts davon ist neu. Es ist das, was das Ausliefern einer Binärdatei an den Rechner eines anderen seit zwanzig Jahren von dir verlangt.\nFang mit der Entscheidung an, die Cisco im Grundsatz richtig und in der Ausführung falsch getroffen hat: wie viel vom Host du bereit bist vorauszusetzen. Statisch zu linken ist die stärkste Antwort, und es lohnt sich, dabei konkret zu werden, denn „link es doch einfach statisch“ wird von Leuten herumgeschwenkt, die es nie mussten, und von Leuten abgetan, die es nie versucht haben.\nWas es beseitigt Was es kostet RUNPATH und jede Art, es falsch zu machen, weil es zur Ladezeit keine Suche gibt glibc linkt nicht sauber statisch: Namens- und Benutzerauflösung laufen über dlopen, die Binärdatei greift also weiterhin nach den NSS-Modulen des Hosts17 Die glibc-Untergrenze, sodass die älteste Distribution nicht mehr diktiert, worauf du kompilieren darfst LGPL-Teile bringen eine Relink-Pflicht mit, sie bleiben also dynamisch, oder du lieferst mit, was zum Relinken nötig ist Kaputtes durch ein Distributions-Upgrade, eine umbenannte Bibliothek oder einen veralteten ldconfig-Cache Du besitzt jeden Patch: kein Sicherheitsupdate einer Distribution erreicht deine Kunden dlopen einer versionierten .so aus einem Verzeichnis, das es vielleicht nicht gibt Ein größerer Download, und kein Teilen von Speicherseiten zwischen Prozessen Und eine Zeile in der linken Spalte, die die anderen nur stützen: das Artefakt, das deine Pipeline erzeugt hat, ist das Artefakt, das der Kunde ausführt, Byte für Byte. Teste es, und du hast das getestet, was du ausgeliefert hast. Genau um das Fehlen dieser Eigenschaft geht es in diesem ganzen Beitrag.\nÜber die rechte Spalte gehört Ehrlichkeit. Echte Kosten, und der Grund, warum Leute zu musl greifen oder eine Mischform akzeptieren. Aber sieh dir die dritte Zeile an. Jeden Patch zu besitzen gilt genauso für das, was Cisco bereits getan hat: ein gebündelter Baum aus 150 Bibliotheken ist dieselbe Verpflichtung ohne jede der Garantien zur Ladezeit. Sie haben sich so oder so verpflichtet, jeden Patch zu besitzen, und nichts dafür bekommen.\nDie Regel ist also einfach, und es ist die Regel, die sie gebrochen haben: was du nicht hineinlinken kannst, musst du über einen Pfad relativ zur Binärdatei finden. $ORIGIN für den Code, und dieselbe Disziplin, bewusst, für jeden Datenpfad, nach dem die Bibliothek suchen wird. In diesem Fall sind es vier, und für jeden gibt es einen dokumentierten Griff:\nWonach die Bibliothek sucht Was ausgeliefert wurde Was es hätte sein müssen Vertrauensanker OPENSSLDIR/cert.pem, zur Build-Zeit festgelegt im Baum mitgeliefert, oder SSL_CERT_FILE beim Start gesetzt5 Konfiguration OPENSSLDIR/openssl.cnf, gleicher Pfad, nie gefunden OPENSSL_CONF, auf die Kopie im Paket gerichtet5 Provider, einschließlich FIPS MODULESDIR, absolut, fips.so also unerreichbar OPENSSL_MODULES, „the directory from which cryptographic providers are loaded“5 Engines ENGINESDIR, absolut OPENSSL_ENGINES, oder gar nichts, da OpenSSL 4.0 die Engine-Unterstützung ganz entfernt hat5 Vier Pfade, vier Umgebungsvariablen, alle in einer einzigen Handbuchseite, die ihre eigene Bibliothek mitliefert. Wenn irgendeine Zeichenkette in deinem Artefakt mit einem / beginnt und zur Build-Zeit festgelegt wurde, ist sie ein Defekt, der auf einen Kunden wartet, der ihn findet. Es gibt keine dritte Möglichkeit, in der ein absoluter Build-Pfad in Ordnung ist.\nDie Lösungen für diesen Fall, und die Prüfung, die ihn findet Herunter vom Grundsatz zu diesem konkreten Defekt. Sechs Änderungen, keine einzige davon Forschung:\nLösung Aufwand Warum sie richtig ist --openssldir=/opt/Webex/lib/ssl setzen und den Baum mitliefern ein Konfigurationsschalter Der Pfad existiert dann im Paket, und genau dafür ist der Schalter da2 SSL_CERT_FILE/SSL_CERT_DIR beim Start in CiscoSSLUtils setzen und die bekannten Distributionspfade abklopfen ein Dutzend Zeilen Standard, dokumentiert, von ihrer eigenen Bibliothek bereits unterstützt5 Das CA-Bündel selbst im Paket mitliefern nur Paketierung Volle Kontrolle über das Vertrauen, zum Preis, für dessen Aktualität zuständig zu sein Die openssl.cnf so korrigieren, dass sie den default-Provider aktiviert eine Zeile Ohnehin nötig, und derzeit vom Pfadfehler verdeckt6 openssl.cnf als %config markieren eine Zeile in der Spec Verhindert, dass ein Update die Änderung eines Administrators still auffrisst15 Die Pfade und die beachteten Variablen veröffentlichen eine Seite Die billigste Prüfung, die es gibt, und sie findet diesen Fehler, während sie geschrieben wird Die erste ist die Ein-Schalter-Lösung, und sie hätte das Produkt funktionsfähig ausgeliefert. Es ist ein einziger Wert in einem Build-Skript, einmal gesetzt, den sie falsch hatten, weil ihn unterhalb nie etwas geprüft hat.\nDie Prüfung ist kleiner als die Lösung:\n# in CI, on the packaged artefact, in a clean container test -d \u0026#34;$(strings lib/libcrypto.so.3 | grep -oP \u0026#39;(?\u0026lt;=OPENSSLDIR: \u0026#34;)[^\u0026#34;]+\u0026#39;)\u0026#34; \\ || { echo \u0026#34;shipping a trust store path that does not exist\u0026#34;; exit 1; } Eine Zeile. Sie hätte dieses Release laut scheitern lassen, im Februar, auf der Maschine, die es gemacht hat, in dem Container, der es gemacht hat, bevor das Paket signiert wurde. Der Grund, warum sie nicht da ist, ist weder Schwierigkeit noch Kosten. Es ist, dass niemand gebeten wurde, sie zu schreiben, und damit war die Frage, ob sich das paketierte Artefakt wie Software verhält, niemandes Aufgabe.\nWas ein schlampiger Build-Prozess alle anderen kostet Alles bisher ist der Build-Prozess eines Produkts von innen gesehen, und ich werde dich nicht noch einmal hindurchführen. Die Frage, die sich lohnt, ist, ob dieser Sorgfaltsmaßstab wahrscheinlich bei einem Team aufhört.\nAlso stell den Befund von außen daneben. Die CISA führt einen Katalog von Schwachstellen, die bekanntermaßen in freier Wildbahn ausgenutzt werden. Nicht theoretisch, nicht bewertet. Beobachtet, wie sie gegen Menschen eingesetzt werden. Stand 14. September 2026 enthält er 1.710 Einträge18:\nHersteller Einträge im KEV-Katalog Microsoft 388 Cisco 98 Apple 94 Adobe 81 Google 74 Oracle 46 Fortinet 30 VMware 26 Zweiter, hinter einem Betriebssystemmonopol und vor allen anderen. Der jüngste Cisco-Eintrag kam am 14. September 2026 dazu, dem Tag, bevor dies geschrieben wurde.\nDieselbe Datei habe ich drei Wochen vorher für /de/random/is-your-msp-lying-to-you-part2/ gezählt: Version 2026.08.27, 1.685 Einträge, Cisco bei 96. Zwei mehr seither, in einundzwanzig Tagen.\nSei fair damit, was diese Tabelle für sich genommen beweist und was nicht. Eine große installierte Basis an hochwertigen Stellen zieht Aufmerksamkeit an, und Aufmerksamkeit findet Fehler, also wird jeder Hersteller dieser Größe eine lange Liste tragen. Die Zahl ist ein Vorzeichen, kein Urteil.\nDie Zusammensetzung lässt sich schwerer wegwischen als die Gesamtzahl. Fünfundzwanzig von Ciscos achtundneunzig sitzen auf den Sicherheitslinien: den Firewalls, den Appliances, den VPN-Konzentratoren, den Mail- und Web-Gateways, den Identitätsdiensten. Und die vier jüngsten Einträge gegen sie, hintereinander, sind Secure Firewall Management Center zweimal, Secure Firewall ASA und Secure Email Gateway, letzteres am 14. September 202618. Nicht die Switches. Nicht die Kollaborationstechnik. Die Produkte, die eigens dafür verkauft werden, das zu sein, was alle anderen schützt.\nUnd das ist der Satz, auf den dieser ganze Beitrag zuläuft, also hier ist er im Klartext. Das ist eine Firma, deren Geschäft der Verkauf von Sicherheits-Appliances ist, und sie bekommt es nicht hin, dass ein Desktop-Client ein Zertifikat prüft. Kein schwerer Fall. Kein neuartiger Angriff. Die allerroutinemäßigste Sicherheitsoperation der Informatik, die jeder Browser bei jedem Seitenaufruf ausführt, in einer Bibliothek, die sie selbst geforkt haben, und sie haben sie auf ein Verzeichnis gerichtet ausgeliefert, das auf keiner Kundenmaschine je existiert hat. Und dann signiert.\nWas dieser Beitrag hinzufügt, ist eine Stichprobe des Prozesses dahinter. Keine Schwachstelle. Ein schlichter Paketierungsdefekt, die am wenigsten subtile Fehlerklasse, die es gibt, auf einer unterstützten Plattform, von jedem Rauchtest gefunden, den irgendwer hätte laufen lassen wollen, und trotzdem ausgeliefert. Wenn eine Build-Pipeline das einem zahlenden Kunden vorsetzt, ist nicht offensichtlich, was sie aufhalten würde. Nichts hat es.\nDarf ich fragen, warum das signiert wurde? Darf ich fragen, warum ein Paket, das keinen TLS-Handshake abschließen kann, signiert und gegen eine Plattform veröffentlicht wurde, die eure eigene Anforderungsseite als unterstützt aufführt? Nicht, wer es signiert hat. An einem Namen habe ich kein Interesse, und darum geht es auch nicht. Was hat es zugelassen, denn irgendetwas hat es, fünfzehn Minuten nach dem Ende des Builds, und was immer es ist, es läuft heute noch.\nJetzt die deutliche Fassung. Das ist kein Projekt, das ich mir von einer Plattform gezogen und auf gut Glück ausprobiert habe. Es ist bezahlt. Dahinter stehen ein Vertrag, eine Supportleitung, eine Anforderungsseite, die eine Behauptung über Linux aufstellt, und ein Signaturschlüssel, der versichert, das Paket komme von Cisco und sei zur Installation geeignet. Jedes davon ist eine Aussage an einen Kunden, und bei diesem Release war jede davon nichts wert, weil das Ergebnis nie geöffnet wurde.\nUnd der Maßstab, der hier verfehlt wird, ist nicht meiner. Es ist ihrer. Die vier Variablen, die diese Pfade getragen hätten, sind in einer Handbuchseite dokumentiert, die ihr im Bündel mitliefert. Euer eigenes Paketformat hat eine %config-Markierung, die ihr nicht benutzt habt, und einen Dokumentationsabschnitt, den ihr leer gelassen habt. Euer eigener Build lief in einem Container, den ihr nie benutzt habt, um die Ausgabe auszuführen. Ich bitte kein Netzwerk- und Kollaborationsunternehmen darum, irgendetwas zu erfinden. Ich frage, warum es seine eigenen Handbücher nicht gelesen hat.\nEntsprechend ist die Ausrede, die ich nicht gelten lasse, dass das schwer sei. Es ist für niemanden schwer, und für eine Firma, die das täglich macht, in dieser Größe, für dieses Geld, schon gar nicht. Fachleute, die das jeden Tag tun, haben keine Entschuldigung, und groß zu sein ist keine.\nUnd darf ich noch eine stellen, denn das ist die, auf die es wirklich ankommt. Ihr verkauft Firewalls. Ihr verkauft ein E-Mail-Gateway, einen VPN-Konzentrator, einen Identitätsdienst, ein Management Center für das alles, und der Verkaufsspruch bei allen ist, dass ihr das besser versteht als euer Kunde. Wie also liefert eine Firma, die sich als Autorität für Netzwerksicherheit positioniert, einen Client aus, der ein Zertifikat nicht prüfen kann? Nicht: ihn nicht raffiniert genug prüft. Ihn nicht nachschlagen kann, weil das Verzeichnis nie da war.\nEs gibt keine Fassung dieser Antwort, die ich hören will und die damit anfängt, dass das Desktop-Team vom Appliance-Team getrennt sei. Es ist dieselbe Signatur, dieselbe Pipeline, dieselbe veröffentlichte Behauptung über eine unterstützte Plattform und derselbe fehlende Schritt am Ende, nämlich die Schachtel zu öffnen. Wenn die Zertifikatsprüfung vor der Auslieferung in dem Produkt nicht geprüft wird, in dem ein Defekt laut und harmlos ist, habe ich keinen Grund zu glauben, dass sie in dem Produkt geprüft wird, in dem ein Defekt leise und teuer ist.\nUnd der ehrliche Teil, im Klartext. Nichts davon hat mich überrascht. Ich habe mir angewöhnt, diesen Maßstab von diesem Hersteller zu erwarten, weshalb ich, wo die Wahl bei mir liegt, seine Technik nicht kaufe und nicht darauf baue. Das ist keine Vorliebe für Logos. Es ist dasselbe Urteil, das ich über jeden Lieferanten fällen würde: ich habe seine Arbeit gemessen, mehr als einmal, und sie kommt immer wieder gleich zurück. Der Katalog oben ist eine Messung. Was die erste Hälfte dieses Beitrags gekostet hat, ist eine zweite.\nDer Grund, warum ich überhaupt auf Webex war, ist, dass die Wahl nicht bei mir lag, und das gehört benannt, denn es ist die Lage, in der die meisten sind, die das hier lesen. Du kommst selten darum herum, einen Hersteller zu benutzen, dessen Qualität du schon abgemessen hast. Jemand anders unterschreibt den Vertrag, die Technik kommt an, und der Erste, der herausfindet, was im Build ausgelassen wurde, bist du, an deinem Schreibtisch, mit einer Besprechung, die gerade anfängt.\nEtwas ausliefern, das man nie ausgeführt hat Es wird eine interne Erklärung geben. Ein voller Sprint, eine Pipeline, die den Besitzer gewechselt hat, eine Plattform ohne Zuständigen. Nichts davon ist es wert, gehört zu werden, denn jede beschreibt dasselbe: die Arbeit wurde nicht gemacht, und nichts im Prozess hat sie verlangt.\nEs gibt einen alten Maßstab im Handwerk, der es nie in die Software geschafft hat: du gehst nicht von der Baustelle, bevor du das Ding in Betrieb genommen hast. Du füllst die Anlage und prüfst jede Verbindung. Du legst Spannung auf den Verteiler und misst jeden Stromkreis. Nicht, weil du an deiner Arbeit zweifelst. Weil der Kunde sie benutzen wird, und es vor seinen Augen herauszufinden ist kein professionelles Ergebnis. Niemand sieht dir dabei zu. Du machst es trotzdem. Das ist die ganze Bedeutung des Wortes.\nSoftware streitet seit dreißig Jahren dafür, dass sie anders sei, dass der Build das Lieferbare sei und die Installation das Problem eines anderen, dass eine grüne Pipeline dasselbe sei wie ein funktionierendes Produkt, und das ist sie nicht. Ein Build, der nie außerhalb des Containers ausgeführt wurde, der ihn erzeugt hat, ist nicht fertiggestellt, sondern an der Stelle liegen gelassen worden, an der das Fertigstellen langweilig wird. Alles danach ist eine Behauptung über Arbeit, die nicht gemacht wurde.\nDie Lösung ist ein Konfigurationsschalter. Die Prüfung ist eine Zeile Shell. Die Kosten von beidem sind nicht das Interessante; die interessante Zahl ist, wie viele Leute ihre Zugangsdaten in ein Webex-Fenster getippt haben, zugesehen haben, wie es sagte, ihr Internet sei weg, und es geglaubt haben, weil Cisco es ihnen so gesagt hat und Cisco eine Netzwerkfirma ist. Das hat der fehlende Test tatsächlich eingekauft: keinen Fehler, sondern eine Lüge, die das Produkt selbstbewusst erzählt, bei jedem Start, Leuten, die keine Möglichkeit haben, es besser zu wissen.\nUnd das ist die Linie, die es vor dem Schließen des Tabs zu ziehen lohnt, denn die beiden Hälften dieses Beitrags sind nicht zwei Themen. Ein Vertrauenspfad, der auf einen Build-Container zeigt, und eine Authentifizierungsumgehung auf einer Edge-Appliance sind derselbe Fehler bei unterschiedlichem Einsatz. Beides ist ein Wert, den niemand geprüft hat, in einem Artefakt, das niemand ausgeführt hat, signiert von einem Prozess, der Herkunft bezeugt und nicht Tauglichkeit. Der vor mir war die harmlose Sorte. Er ging laut kaputt, auf meinem eigenen Schreibtisch, und ich war der Erste, der es wusste. Die andere Sorte tut dir das nicht.\nDieselbe fehlende Prüfung bei zweierlei Einsatz, und nur eine sagt es dir Eine fehlende Prüfung, zwei Einsätze. Nur einer sagt dir, dass er da ist. Derselbe Fehler: ein Wert, den niemand prüfte, in einem Artefakt, das niemand ausführte, signiert für Herkunft, nicht Tauglichkeit Die Sorte, die laut kaputtgeht was es war ein Trust-Store-Pfad, den es nicht gibt wer es fand der Kunde, beim ersten Start was es kostete einen Abend, einen Schreibtisch wer es erfuhr ich, sofort Endet öffentlich aufgeschrieben. Die Sorte, die nichts kaputtmacht was es war eine Länge, die niemand geprüft hat wer es fand wer danach suchte was es kostete ein Vorfall wer es erfuhr der Kunde, aus dem Bericht Endet als 1 von Ciscos 98 im Katalog. Ein Prozess, der die linke Spalte nicht findet, hätte die rechte nie gefunden. Der Unterschied ist Glück, nicht Sorgfalt. Der Defekt in diesem Beitrag und die Einträge in jenem Katalog sind derselbe Fehler in anderen Kleidern. Der eine hat sich beim ersten Start auf meinem Schreibtisch gemeldet. Die andere Sorte meldet sich zuerst bei jemand anderem. Niemand bei Cisco hat beschlossen, eine ausnutzbare Firewall auszuliefern, genauso wenig, wie jemand beschlossen hat, einen Client auszuliefern, der nicht ins Internet kommt. Das ist keine Verteidigung. Das ist der Vorwurf. Keines von beidem muss beschlossen werden, und genau das ist das Problem: beides ist das, was hinten herauskommt, wenn eine Pipeline kompiliert, signiert und veröffentlicht, ohne dass irgendwer dafür zuständig gemacht wird, das Ergebnis zu öffnen. Ein Prozess, der ein nicht existierendes Verzeichnis nicht findet, hätte eine nicht geprüfte Länge nie gefunden, und ein Hersteller, der dir die Appliance verkauft, die deinen Perimeter bewacht, hat auf so einen Prozess keinen Anspruch.\nWenn also der Name eines Herstellers immer wieder auf dieser Liste auftaucht, widersteh der bequemen Erklärung, er sei eben groß und stark im Visier. Die Größe erklärt die Menge. Sie erklärt nicht die Art. Sieh dir stattdessen an, was sein Build-Prozess mit den langweiligen Dingen macht, denn die langweiligen Dinge sind von außen messbar, von dir, heute, an Technik, die du schon besitzt.\nPrüf deine eigenen Bündel. strings und readelf und zwanzig Minuten sagen dir, welche deiner Hersteller einen Pfad zu einer Maschine ausliefern, die du nie sehen wirst. Was du in Wahrheit misst, ist nicht der Pfad. Es ist, ob dort irgendwer hingesehen hat, und wenn die Antwort bei etwas so billig Auffindbarem nein lautet, weißt du bereits, wie sie bei den Dingen lautet, die es nicht sind.\nCisco — Webex App system requirements — die Liste unterstützter Plattformen, Linux eingeschlossen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nOpenSSL — INSTALL.md, --openssldir — „Directory for OpenSSL configuration files, and also the default certificate and key store.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nOpenSSL — SSL_CTX_load_verify_locations(3) — die Standard-CA-Datei ist cert.pem und das Standard-CA-Verzeichnis certs, beide innerhalb des Standard-OpenSSL-Verzeichnisses; und zu den Rückgabewerten: „A missing default location is still treated as a success.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nConan 2 — conan cache — Paketbinärdateien liegen unter einem gehashten Pfad im lokalen Cache, und daher kommt /workspace/.conan2/p/b/\u0026lt;hash\u0026gt;/p.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nOpenSSL — openssl-env(7) — SSL_CERT_DIR und SSL_CERT_FILE „specify the default directory or file containing CA certificates“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nOpenSSL — provider(7) — der Standard-Provider und was eine Konfiguration, die ihn weglässt, unverfügbar macht.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nOpenSSL — config(5) — die Konfigurationsdatei, die OpenSSL bei der Initialisierung lädt, und wo danach gesucht wird.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nfreedesktop.org — XDG Base Directory Specification — „The base directory defined by $XDG_DATA_HOME is considered more important than any of the base directories defined by $XDG_DATA_DIRS.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nfreedesktop.org — Desktop Entry Specification — wo nach .desktop-Dateien gesucht wird und wie eine eine andere gleichen Namens überdeckt.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nFilesystem Hierarchy Standard 3.0 — die Verzeichnisse, die ein Wurzeldateisystem enthalten soll, /workspace nicht darunter.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nupdate-ca-trust(8) — wie das konsolidierte Bündel unter /etc/pki/ca-trust/extracted auf Fedora und Verwandten erzeugt wird.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nld.so(8) — $ORIGIN wird zu dem Verzeichnis aufgelöst, das das Programm oder Shared Object enthält, und genau das macht einen gebündelten Baum verschiebbar.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nglibc timeline — „2018-08-01 GLIBC 2.28 — The GNU C Library version 2.28 is now available“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nglibc — Release wiki — die Tabelle Version zu Distribution; Red Hat Enterprise Linux 8 ist glibc 2.28.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRPM — spec file reference — %config und was der Paketmanager mit einer als Konfiguration markierten Datei macht.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nFedora packaging guidelines — configuration files — wann eine mitgelieferte Datei als %config markiert sein muss.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nglibc FAQ — warum eine statisch gelinkte glibc-Binärdatei zur Laufzeit trotzdem die NSS-Module des Hosts braucht.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCISA — Known Exploited Vulnerabilities Catalog — gezählt aus dem veröffentlichten JSON-Feed, Katalogversion 2026.09.14, 1.710 Einträge.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://blogs.damiendye.uk/de/certificates/webex-certificates-on-a-build-server/","summary":"Webex 46.8.0.35631 auf Fedora 44 sitzt hinter einem gelben Banner mit der Aufschrift „Offline - No internet connection“, während jedes andere Programm auf der Maschine ohne Murren ins Internet kommt. Es hat die VoIP-Leitung totgelegt. Das Netz war nie das Problem: Cisco liefert einen eigenen Fork von OpenSSL mit und hat ihn mit OPENSSLDIR auf /workspace/.conan2/p/b/cisco8ee8b59cf93de/p/ssl gebaut, einem Verzeichnis, das es auf einem Build-Container gibt und sonst nirgends, also lädt es keine Vertrauensanker und jeder Handshake scheitert. Der Beitrag geht der Reihe nach vor: was der kaputte Zustand tatsächlich ist, die mitgelieferte Bibliothek fragen, wo sie ihre Zertifikate vermutet, den exakten Fehlercode außerhalb von Webex reproduzieren, warum nichts warnt, die zwei Lösungen, die nicht funktionieren, und warum, und die eine, die funktioniert. Dann der Build-Prozess: sie haben $ORIGIN für den Code benutzt und drei Datenpfade absolut gelassen, der RPM-Header nennt eine Container-ID, der Container war also schon in der Pipeline und wurde nie benutzt, um das Ergebnis auszuführen, das Paket verlangt eine glibc von 2018, weil sie nicht statisch linken wollen, 2,2 GB werden zweimal ausgeliefert, und es bringt keine Dokumentation und keine als Konfiguration markierte Datei mit. Dann, wie es hätte gebaut werden müssen, die sechs Korrekturen und die einzeilige Prüfung, die das findet. Und zum Schluss der Gegencheck: Cisco hält 98 Einträge im Katalog bekannter ausgenutzter Schwachstellen der CISA, nur Microsoft liegt davor, und ein ungeprüfter Vertrauenspfad und eine ungeprüfte Umgehung sind derselbe Fehler bei unterschiedlichem Einsatz.","title":"Webex sucht deine Zertifikate auf einem Cisco-Build-Server"},{"content":"Ein VPN ist kein Produkt. Es sind zwei Aufgaben zusammengeschraubt, und deine Maschine hat für jede davon bereits ein Programm.\nDie erste Aufgabe ist, einen virtuellen Link zu bauen — eine Schnittstelle, die aussieht wie eine Netzwerkkarte, IP-Pakete nimmt und sie weitergibt. Die zweite ist, die Bytes dieses Links von einem Ende zum anderen zu tragen. Kauf eine VPN-Appliance und du kaufst beide Aufgaben mit einer aufgetackerten Lizenz; mach es selbst und jede ist ein Programm, das schon installiert ist. Es gibt unter Linux zwei Wege für die erste Aufgabe, und dieser Beitrag baut beide: pppd, das ein ganzes Link-Protokoll mitbringt — ausgehandelte Adressen, eine Lebendprüfung, Framing — und ein Tap-Device, das nichts mitbringt und ein Loch im Kernel ist, in das du Frames schiebst. Verschiedene Kompromisse, keine Konkurrenten, und die zweite Hälfte stellt sie nebeneinander.\nDieses Protokoll ist PPP, und der Grund, warum das funktioniert, steht in seinem ersten Absatz: PPP ist ein Link-Protokoll für Punkt-zu-Punkt-Verbindungen1, und es legt nicht fest, woraus der Link besteht. Ein Modem und eine Telefonleitung waren die ursprüngliche Antwort. Sie waren nie die einzige. PPTP steckte PPP in GRE2. L2TP steckte es in UDP3. PPPoE steckte es in Ethernet-Frames. Jedes davon ist dasselbe Protokoll mit einem anderen Boten, und keines davon musste PPP dafür ändern.\nDie Frage ist also nicht, ob du PPP über einen TCP- oder UDP-Socket fahren kannst, sondern über welchen, und was es kostet. Die kurze Antwort, mit gezeigter Rechnung: Nimm UDP. Ein Stream-Protokoll in einem zuverlässigen Stream zu fahren ist der eine Fehler hier, der auf deinem Schreibtisch gut aussieht und auf einer echten Leitung auseinanderfällt.\nEin VPN Sind Zwei Aufgaben. Du Hast Beide Schon. Zieh jedem Tunnel das Marketing ab und drei Dinge passieren: Etwas präsentiert eine virtuelle Schnittstelle und macht aus Paketen einen Byte-Stream, etwas trägt diesen Stream über ein Netzwerk, das bereits funktioniert, und etwas verschlüsselt ihn, oder nichts tut es.\nJeder Tunnel ist eine Link-Hälfte, ein Träger und etwas Krypto Jedes Mal dieselben drei Teile. Nur der Träger und die Krypto ändern sich. TUNNEL LINK-HÄLFTE TRÄGER KRYPTO Wähl-PPP, 1994 PPP Modem und Telefonleitung keine PPPoE PPP Ethernet-Frames keine PPTP PPP GRE MPPE — gebrochen, lass es L2TP über IPsec PPP UDP IPsec Dieser Beitrag, Bau eins PPP über ein pty UDP-Socket, über Netcat DTLS Dieser Beitrag, Bau zwei tun- oder tap-Device UDP-Socket, über socat DTLS WireGuard Kernel-Schnittstelle UDP Noise, und nichts auszuhandeln Jeder Tunnel auf dieser Liste hat dieselbe Form. Die Unterschiede sind, in welchen Träger die Bytes gehen und ob überhaupt etwas verschlüsselt. PPP erledigt die Link-Hälfte seit 1994, weshalb es unter dreien davon auftaucht, ohne für eines davon umgebaut worden zu sein. Ein tun- oder tap-Device erledigt dieselbe Hälfte ganz ohne Protokoll, und das ist der zweite Bau in diesem Beitrag. PPP erledigt die Link-Hälfte ordentlich — Adressaushandlung, eine Lebendprüfung, Header-Kompression, mehrere Netzwerkschicht-Protokolle über einen Link, ein Authentifizierungsschritt, wenn du willst — eine Menge fertige Arbeit, die in /usr/sbin liegt und nichts tut. Was es nicht tut, ist sich um den Träger zu kümmern: Gib ihm einen Dateideskriptor, der Bytes in beide Richtungen bewegt, und es läuft darüber. Netcat ist ein Programm, dessen ganzer Zweck es ist, dieser Dateideskriptor zu sein.\nDie Verschlüsselung ist der Teil, den dir niemand in die Hand drückt, und der Teil, den sich der Großteil dieses Beitrags verdient, denn Netcat hat keine Antwort darauf, und so zu tun als ob ist der Weg, wie Leute Dinge bauen, die sie nicht bauen sollten.\nDie Stufen, Und Warum Sie In Dieser Reihenfolge Kommen Alles unten wird in Stufen gebaut, jede fügt der vorigen eine Sache hinzu. Das ist kein Lehrmittel. So solltest du es bauen, denn wenn Stufe sechs kaputtgeht, musst du wissen, ob Stufe zwei noch funktioniert, und das weißt du nur, wenn Stufe zwei je etwas war, das du für sich laufen lassen hast.\nSechs Stufen, jede fügt eine Sache hinzu, die du einzeln testen kannst Bau es in dieser Reihenfolge und du kannst immer wieder herunterlaufen 1 Roh, über TCP pppd mit einem pty, oder ein Tap-Device, und ein schlichter Netcat-Listener. Geht auf der Werkbank. Bricht auf echtem Pfad zusammen — zwei streitende Neuübertragungs-Timer. 2 Roh, über UDP Derselbe Link, Datagramm-Träger. Ein verlorenes Datagramm ist ein verlorenes Paket, mehr nicht. Das ist das Fundament. Alles darüber ist optional; das hier nicht. 3 TLS, über TCP ncat, stunnel oder openssl wickeln den Träger ein. Prüf das Zertifikat an beiden Enden, sonst hast du Verschlüsselung ohne Identität und gar keine Zugangskontrolle. 4 DTLS, über UDP socat oder openssl, und die Form, auf die man zielt: verschlüsselt, authentifiziert, immer noch Datagramme. Ein verlorenes Paket bleibt ein verlorenes Paket, statt dass zwei Stacks darüber streiten. 5 Komprimiert zstd zwischen Schnittstelle und Träger. Halt das Fenster über Frames hinweg, wo der Träger in Reihenfolge zustellt; ein eigenständiger Frame pro Datagramm plus Wörterbuch, wo nicht. 6 Beides, in dieser Folge Komprimieren, dann verschlüsseln. Nie andersherum — Geheimtext komprimiert nicht. Und kenn den Handel: Komprimieren vor dem Verschlüsseln verrät die Klartextlänge. Auf eigenem Verkehr in Ordnung. Sechs Stufen, jede fügt der darunter eine Sache hinzu. Roh über TCP ist, wo jeder anfängt, und die einzige Sprosse, die eine Sackgasse ist: Sie läuft auf der Werkbank und schmilzt auf einer echten Leitung. Roh über UDP ist das Fundament, auf dem alles andere sitzt. Dann Verschlüsselung, dann Kompression, dann beides zusammen. Jede Stufe ist ein Link, den du hochfahren, über den du pingen und den du laufen lassen kannst, sodass du, wenn die Spitze der Leiter zickt, sie Sprosse für Sprosse wieder hinuntergehen kannst. Der Link selbst wird genauso gebaut — die Begründung hinter der Ein-Sekunden-Rampe weiter unten: Ein Tunnel kommt roh hoch, beweist, dass er einen Frame tragen kann, und wird erst dann clever. Ein Bau, der alles auf einmal einschaltet, fällt als ein Klumpen aus, und du verbringst den Abend damit, zu raten, welche Schicht es war.\nWas pppd Eigentlich Will, Ist Ein Dateideskriptor pppd wurde für serielle Ports geschrieben, also ist die naive Lesart, dass es einen serellen Port braucht. Tut es nicht. Es braucht ein Terminal-Device, und es macht sich selbst eines:\npty script — Specifies that the command script is to be used to communicate rather than a specific terminal device. Pppd will allocate itself a pseudo-tty master/slave pair and use the slave as its terminal device. The script will be run in a child process with the pseudo-tty master as its standard input and output.4\nLies das noch mal — der ganze Bau steckt darin. pppd macht ein Pseudo-Terminal, behält den Slave und übergibt den Master einem Befehl als stdin und stdout. Was dieser Befehl mit den Bytes tut, ist nicht die Sache von pppd. Lass nc dort laufen, und sie gehen einen Socket hinunter.\npppd, ein Pseudo-Terminal, Netcat und ein Socket Ein Paket, von ppp0 zu ppp0, und jede Hand, durch die es geht HOST A HOST B ppp0 Kernel-Schnittstelle pppd HDLC-Framing pty-Paar Slave an pppd Master an das Kind ncat stdin und stdout pty-Paar Master an das Kind Slave an pppd ncat stdin und stdout pppd HDLC-Framing ppp0 Kernel-Schnittstelle der Socket — TCP oder UDP Die zwei Kästen in der Mitte sind der einzige Teil, den du wählst. Alles zu beiden Seiten bleibt gleich, ob der Träger eine Telefonleitung, eine serielle Konsole, ein TCP-Stream, ein UDP-Datagrammfluss oder eine TLS-Sitzung ist — deshalb kostet der Trägertausch später ein Wort. Ein Pseudo-Terminal hat keinen Carrier-Detect-Pin, also wartet pppd auf einen Träger, der nie kommt. Die Option `local` ist, was das stoppt. pppd spricht asynchrones HDLC in die Slave-Seite eines Pseudo-Terminals, das es sich selbst zugeteilt hat. Der von pty benannte Befehl erbt die Master-Seite als stdin und stdout. Netcat kopiert stdin in einen Socket und den Socket nach stdout, sodass die beiden pppd-Instanzen durch das pty-Paar und das Netzwerk miteinander sprechen, ohne dass eine von ihnen weiß, dass ein Socket existiert. Es gibt einen zweiten Weg, notty, der stattdessen pppds eigenes stdin und stdout benutzt. Aber er startet einen Character-Shunt-Prozess, durch den jedes Byte läuft, sodass er „increases the latency and CPU overhead“4. Nimm pty, es sei denn, du hast einen Grund, es nicht zu tun.\nDrei praktische Fakten vor dem ersten Befehl, alle auf der Kiste geprüft, auf der das geschrieben wurde — Fedora 44, ppp-2.5.1-7.fc44:\n$ pppd --version pppd version 2.5.1 $ ls -l /usr/bin/pppd /dev/ppp -rwxr-xr-x. 1 root root 393784 Jan 17 2026 /usr/bin/pppd crw-------. 1 root root 108, 0 Sep 14 08:34 /dev/ppp $ pppd noauth nodetach pty \u0026#39;true\u0026#39; pppd: using the noauth option requires root privilege Es braucht Root. Da führt kein Weg dran vorbei. Die Binary ist unter Fedora nicht setuid, /dev/ppp ist Modus 0600 und Root gehörig, und die Optionen, die du brauchst, sind ohnehin privilegiert. Das ist etwas, das du als Root oder unter einer Unit-Datei laufen lässt, nicht etwas, das ein Benutzer nebenbei tut. Das ist später wichtig, wenn wir dazu kommen, was es für deine Egress-Policy bedeutet.\nDie Kernel-Seite ist modular. ppp_generic macht die Schnittstelle, ppp_async das byte-gestopfte Framing, das ein pty braucht, und ppp_deflate/bsd_comp/ppp_mppe Kompression und Verschlüsselung; sie laden bei Bedarf. Fehlt ppp_async in einem abgespeckten Container-Image, kommt der Link hoch und trägt nichts — eine elende halbe Stunde, wenn du nicht weißt, wo du hinschauen musst.\nModem-Steuerleitungen existieren auf einem pty nicht. Ohne Carrier-Detect-Pin wartet pppd auf einen Träger, der nie kommt. Die Lösung ist ein Wort, local, das ihm sagt, die Modem-Steuerleitungen zu ignorieren4. Lass es weg und nichts passiert, ohne eine lesenswerte Fehlermeldung.\nNetcat Ist Nicht Ein Programm Vor dem Bau die Falle, die die meiste Zeit frisst: „Netcat“ sind mindestens vier Programme mit inkompatiblen Flags, und welches du bekommst, hängt von deiner Distribution ab. Auf dieser Maschine ist /usr/bin/nc ein Symlink auf /usr/bin/ncat, Nmaps Neufassung. Ein Befehl, den man von einer fünfzehn Jahre alten Wiki-Seite kopiert, scheitert also aus Gründen, die mit PPP nichts zu tun haben.\nImplementierung An einem Port lauschen UDP Bleibt nach Trennung eines Peers oben Ncat (Nmap) ncat -l 443 -u -k / --keep-open OpenBSD netcat nc -l 443 -u -k Traditional netcat nc -l -p 443 -u nein GNU netcat nc -l -p 443 -u nein Prüf also, welches du hast, bevor du pppd die Schuld gibst:\nreadlink -f \u0026#34;$(command -v nc)\u0026#34; nc --version 2\u0026gt;\u0026amp;1 | head -1 || nc -h 2\u0026gt;\u0026amp;1 | head -1 Ich benutze unten ausdrücklich ncat. Es ist das mit eingebautem TLS, was später wichtig ist, und ausdrücklich zu sein heißt, dass die Befehle auf deiner Kiste nicht stillschweigend etwas anderes bedeuten.\nStufe Eins: Der TCP-Bau, Weil Das Jeder Zuerst Probiert Ein Ende lauscht, ein Ende verbindet. Die Adressen hier stammen aus dem Dokumentationsbereich, du kannst sie also direkt in ein Labor kopieren, und nichts Routbares kommt zu Schaden. Der Port ist durchgehend 443, und das mit Absicht: Ausgehendes 443 ist auf fast jedem Netzwerk standardmäßig offen. Wickle den Träger ein paar Stufen weiter unten in TLS, und der Verkehr darauf ist von jeder HTTPS-Sitzung nicht zu unterscheiden. Einen Listener dort zu binden braucht Root, das das ferne Ende — die eigene Kiste des Angreifers oder ein Relay — hat. Das ist das ganze Egress-Argument in einer Portnummer, und ich komme darauf zurück.\nAm lauschenden Ende:\npppd nodetach noauth local passive \\ nodefaultroute noipdefault \\ 192.0.2.1:192.0.2.2 \\ lcp-echo-interval 10 lcp-echo-failure 3 \\ mtu 1400 mru 1400 \\ pty \u0026#39;ncat --listen --keep-open 443\u0026#39; Am verbindenden Ende:\npppd nodetach noauth local \\ nodefaultroute noipdefault \\ 192.0.2.2:192.0.2.1 \\ lcp-echo-interval 10 lcp-echo-failure 3 \\ mtu 1400 mru 1400 \\ pty \u0026#39;ncat 198.51.100.10 443\u0026#39; Jedes Wort dort erledigt eine Aufgabe, und eines davon, noauth, richtet leisen Schaden an. Der Tunnel hat keine Zugangskontrolle, ein eigener Abschnitt später.\nJedes Wort auf der pppd-Zeile, und was es tut Die Kommandozeile des UDP-Baus, Wort für Wort nodetach Vordergrund, damit du die Ausgabe siehst und es unter einen Supervisor stellen kannst noauth keine Peer-Authentifizierung — das ist das Loch; der Tunnel hat keine Zugangskontrolle local ignoriere die Modem-Steuerleitungen, die ein pty nicht hat. Ohne das kommt nichts hoch passive warte auf ein gültiges LCP-Paket, statt sich zu beenden — Server-Socket-Verhalten nodefaultroute greif die Default-Route nicht, wenn IPCP fertig ist. Setz die Route, die du willst, selbst noipdefault biete nicht die eigene Adresse der Maschine als lokales Ende an 192.0.2.1:192.0.2.2 lokal:fern, festgenagelt — pppd lehnt während IPCP jede andere Antwort ab lcp-echo-interval / -failure die Lebendprüfung — eigener Abschnitt weiter unten mtu / mru 1400 lass Platz für alles, was der Träger um jeden Frame wickelt pty '...' der Befehl, dessen stdin und stdout der Link werden — hier ein Netcat-Socket Das verbindende Ende ist dieselbe Zeile ohne `passive`: Es initiiert, statt zu warten. Jede Option auf der Zeile und was sie tut. Die eine, die man im Auge behalten muss, ist noauth: Sie lässt die Peer-Authentifizierung fallen, sodass der Listener annimmt, wer auch immer ankommt. nodefaultroute und noipdefault halten den Link davon ab, dein Routing still umzuschreiben, local bringt ihn überhaupt erst auf einem pty hoch, und das gepinnte Paar local:remote hindert pppd daran, während IPCP eine andere Antwort zu nehmen. Das verbindende Ende ist dieselbe Zeile ohne passive. Fahr beide Enden hoch und du bekommst auf jedem ein ppp0, eine Punkt-zu-Punkt-Route zur fernen Adresse und eine Schnittstelle, über die du pingen, routen und tcpdumpen kannst. Das ist ein VPN — kein Paket installiert, kein Daemon konfiguriert, kein Schlüssel getauscht, was das Problem ist, und ich komme darauf zurück.\nWas Es Ausgehandelt Hat, Und Wie Man Zusieht Füg debug hinzu und pppd protokolliert den Austausch der Kontrollprotokolle, was einmal lesenswert ist, auch wenn du es nie wieder liest. Der Link kommt in Stufen hoch, und jede Stufe kann für sich scheitern.\nLCP, dann Authentifizierung, dann ein Steuerprotokoll pro Adressfamilie Drei Stufen, und jede scheitert aus eigenem Grund 1 LCP — der Link selbst Maximum Receive Unit, die Steuerzeichen-Map, eine magische Zahl gegen eine Leitungsschleife, und ob ein Ende Authentifizierung verlangt. Scheitert es hier, reicht der Träger Bytes nicht sauber in beide Richtungen durch. Prüf den Socket, nicht die PPP-Optionen. 2 Authentifizierung — optional PAP schickt ein Passwort im Klartext. CHAP macht eine Challenge und eine MD5-Antwort. Entfällt. Beide beweisen, wer der Peer ist. Keines verschlüsselt ein Byte von dem, was folgt. 3a IPCP Die IPv4-Adresse an jedem Ende. 3b IPV6CP Die 64-Bit-Interface- Identifier. Diese zwei sind unabhängig. IPv6 kann hochkommen, während IPv4 noch streitet, und ein Fehler im einen reißt das andere nicht mit. Die Schnittstelle trägt Verkehr für eine Familie, sobald deren Steuerprotokoll fertig ist. LCP klärt den Link selbst — wie groß ein Frame sein darf, welche Steuerzeichen escapt werden müssen, und eine magische Zahl, die eine zurückgeschleifte Leitung erkennt. Authentifizierung ist optional und hier übersprungen. Dann ein Kontrollprotokoll pro Netzwerkschicht: IPCP für IPv4, IPV6CP für IPv6. Sie sind unabhängig, sodass ein Link IPv6 tragen kann, während IPv4 noch streitet, und ein Fehler in einem nimmt das andere nicht mit runter. Die zwei nützlichen Debugging-Werkzeuge sind bereits installiert und keiner benutzt sie:\n# log every frame in both directions to a file pppd ... debug record /tmp/ppp-trace # then read it back in a human-readable form pppdump -h /tmp/ppp-trace | less record schreibt eine mit Zeitstempeln versehene Aufzeichnung jedes Bytes, pppdump macht daraus etwas Lesbares4, und mit tcpdump -ni ppp0 siehst du beide Seiten — das Framing darunter und die Pakete darüber.\nDer Frame Auf Der Leitung, Und Warum 0x7E Überall Ist PPP über eine serielle Leitung — und ein pty ist eine, soweit es pppd angeht — benutzt asynchrones HDLC-Framing, und es zu verstehen ist der Unterschied zwischen dieses Ding einstellen und raten. Jeder Frame beginnt und endet mit demselben Byte: „Each frame begins and ends with a Flag Sequence, which is the binary sequence 01111110 (hexadecimal 0x7e)“5. Wenn 0x7e eine Grenze markiert, kann es nicht innerhalb eines Frames auftauchen, also wird es escapt. So auch das Escape-Byte 0x7d, und alles andere, worum eines der Enden gebeten hat.\nDer Frame, das Flag-Byte, und was Escapen kostet Ein Frame, und die zwei Bytes, die darin nie vorkommen dürfen 0x7E Flag 0xFF Adresse 0x03 Control Protokoll 1 oder 2 Bytes Nutzlast — dein IP-Paket bis zur vereinbarten Maximum Receive Unit FCS 16-Bit-CRC 0x7E Flag ESCAPEN, DIE EINZIGE REGEL, DIE ES GIBT Jedes Byte, das für eine Grenze gehalten werden könnte, wird durch 0x7D ersetzt, gefolgt vom ursprünglichen Byte XOR 0x20. Nutzlast 0x7E übertragen als 0x7D 0x5E Nutzlast 0x7D übertragen als 0x7D 0x5D Diese zwei sind Pflicht. Alles andere entscheidet die Async-Control-Character-Map — 32 Bit, eines pro Steuerzeichen. Map auf null — der Default von pppd, und richtig auf einem Socket Zwei von 256 Bytes escapt. Overhead, den du nie messen wirst. Ein Socket ist ein sauberer 8-Bit-Pfad und braucht nichts weiter. Alle 32 gesetzt — die konservative Modem-Einstellung Bei komprimierten oder verschlüsselten Nutzlasten liegt etwa jedes achte Byte unter 0x20, verdoppelt sich also. Rund 12 % der Leitung, für nichts. Der Frame ist Flag, Adresse, Kontrolle, Protokoll, Nutzlast, Frame-Prüfsequenz, Flag. Jedes Byte darin, das mit einer Grenze verwechselt werden könnte, wird durch 0x7D ersetzt, gefolgt vom Originalbyte XOR 0x20. Die ACCM entscheidet, wie viele andere Bytes dieselbe Behandlung bekommen: null davon auf einem sauberen 8-Bit-Pfad, zweiunddreißig davon, wenn eines der Enden nach dem konservativen Default fragt, der ein Modem annimmt, das Steuerzeichen frisst. Die Escape-Regel ist exakt: „Each Flag Sequence, Control Escape octet, and any octet which is flagged in the sending Async-Control-Character-Map (ACCM), is replaced by a two octet sequence consisting of the Control Escape octet followed by the original octet exclusive-or\u0026rsquo;d with hexadecimal 0x20“5.\nDieser letzte Teil ist der Einstellknopf. Die ACCM ist 32 Bit, eines pro Steuerzeichen, und eine 1 heißt „escape das“. Frag nach allen und, bei verschlüsselten Nutzlasten, wo die Bytes praktisch zufällig sind, ist etwa jedes achte Byte unter 0x20 — rund 12 % Overhead für nichts.\nModernes pppd macht hier bereits das Richtige. Lies die Manpage statt der Folklore:\nIf no asyncmap option is given, the default is zero, so pppd will ask the peer not to escape any control characters.4\nasyncmap 0 ist also der Default, kein Trick, und ein Socket ist ein sauberer 8-Bit-Pfad, der außer den zwei Pflichtbytes kein Escapen braucht. Lass es in Ruhe; setz Bits nur, wenn etwas in der Mitte wirklich Steuerzeichen frisst — ein Terminalserver, ein serieller Konzentrator, ein schlechter Konsolen-Proxy. Die Frame-Prüfsequenz am Ende ist ein 16-Bit-CRC, und sie ist das, was den UDP-Bau funktionieren lässt — was als Nächstes kommt.\nTCP Über TCP Ist Der Falsche Träger Der Bau oben funktioniert. Auf einer Laborwerkbank, über Loopback oder ein ruhiges LAN, funktioniert er wunderbar, genau deshalb liefern ihn Leute aus.\nDann trifft er auf eine echte Leitung mit echtem Verlust. Er fällt auf eine Weise um, die nach allem aussieht außer dem, was es ist.\nDas Problem sind zwei unabhängige Neuübertragungs-Timer, aufeinander gestapelt, wobei der äußere den Verlust vor dem inneren versteckt. Olaf Titz schrieb die maßgebliche Erklärung, die genau mit diesem Bau eröffnet:\nA frequently occurring idea for IP tunneling applications is to run a protocol like PPP, which encapsulates IP packets in a format suited for a stream transport (like a modem line), over a TCP-based connection. […] Unfortunately, it doesn\u0026rsquo;t work well. Long delays and frequent connection aborts are to be expected.6\nEin verlorenes Paket, zwei Träger, zwei sehr verschiedene Ausgänge Ein Paket geht verloren. Was jeder Träger als Nächstes tut. TCP-TRÄGER — der Tunnel verbirgt den Verlust 1 Der Träger verliert ein Segment. 2 Der Träger überträgt es neu. Die Bytes kommen spät, nicht gar nicht — und das ist das ganze Problem. 3 Das getunnelte TCP sieht den Träger nicht. Es liest die Verzögerung als Überlastung, verdoppelt den Timer und überträgt Daten neu, die darunter schon fliegen. 4 Nun schuldet der Träger das Original und ein Duplikat, über eine Leitung, die gerade Paketverlust bewies. Die Warteschlange wächst schneller, als beide sie leeren. Der Durchsatz bricht lange vor der Leitung zusammen. UDP-TRÄGER — der Verlust erreicht die Schicht, der er gehört 1 Der Träger verwirft das Paket und sagt nichts. 2 Der PPP-Frame darin scheitert an seiner Prüfsumme und wird verworfen. Das nächste Flag-Byte synchronisiert neu. 3 Das getunnelte TCP sieht einen echten Verlust, weil ihm einmal die Wahrheit über den Pfad gesagt wurde. 4 Es halbiert sein Fenster und überträgt einmal neu. Die Überlastkontrolle macht genau das, wofür sie entworfen wurde. Ein verlorenes Paket kostet ein Paket. Das Träger-TCP garantiert die Zustellung, also wird ein verlorenes Segment neu übertragen und die Bytes kommen spät statt gar nicht an. Das getunnelte TCP darin sieht nur die Verzögerung, entscheidet, das Netz sei überlastet, macht einen Rückzieher und überträgt dieselben Daten neu — die der Träger nun ebenfalls zustellen muss. Der Timer jeder Schicht versucht ein Problem zu beheben, das die andere Schicht bereits besitzt, und die Warteschlange wächst schneller, als eine von beiden sie leeren kann. Ein UDP-Träger verwirft das Paket, das innere TCP sieht einen echten Verlust, und seine Überlastkontrolle tut die Aufgabe, für die sie gebaut wurde. Hier ist die Form. Beide TCPs setzen einen Neuübertragungs-Timer aus ihrer Umlaufzeit. Wenn der Träger ein Segment verliert, überträgt er neu, sodass die Daten der inneren Verbindung spät ankommen. Und das innere TCP, das den Träger nicht sehen kann, liest „spät“ als Überlastung und überträgt auch neu. Nun hat der Träger das Original und ein Duplikat über eine Leitung zuzustellen, die bereits Pakete verliert. Der innere Timer verdoppelt sich, die äußere Warteschlange wächst, und der Durchsatz bricht lange vor der Leitung zusammen. Nichts in den Logs sagt, warum.\nDas ist kein feiner Effizienzpunkt. Es ist der Unterschied zwischen einem Tunnel, der elegant degradiert, und einem, der bei vielleicht 2 % Verlust aufhört, Verkehr durchzulassen, während ping über dieselbe Leitung noch gut aussieht — der Grund, UDP zu nehmen, und TCP nur für eine Leitung in Reserve zu halten, die nichts anderes durchlässt.\nAlso nimm UDP — als Standard, nicht als Vorliebe.\nStufe Zwei: Der UDP-Bau, Das Fundament Dasselbe pppd, ein anderer Träger. Die einzige Änderung ist im pty-Befehl.\nLauschendes Ende:\npppd nodetach noauth local passive \\ nodefaultroute noipdefault \\ 192.0.2.1:192.0.2.2 \\ lcp-echo-interval 10 lcp-echo-failure 3 \\ mtu 1400 mru 1400 \\ pty \u0026#39;ncat --udp --listen 198.51.100.10 443\u0026#39; Verbindendes Ende:\npppd nodetach noauth local \\ nodefaultroute noipdefault \\ 192.0.2.2:192.0.2.1 \\ lcp-echo-interval 10 lcp-echo-failure 3 \\ mtu 1400 mru 1400 \\ pty \u0026#39;ncat --udp 198.51.100.10 443\u0026#39; Zwei Dinge an einem UDP-Listener, die dich erwischen werden, und keines ist ein PPP-Problem.\nDer Listener kann nicht antworten, bis man ihn anspricht. Ein UDP-Socket hat keine Verbindung anzunehmen, also kann Netcat nicht wissen, wohin es Antworten schicken soll, bis ein Datagramm ankommt. Es klinkt sich auf die erste Quelladresse und den ersten Port ein, von dem es hört, und spricht damit. Das heißt, das verbindende Ende muss zuerst senden — was pppd von selbst tut, weil das nicht-passive Ende sofort LCP-Configure-Requests abfeuert. Es heißt auch, dass, wenn sich der Quellport des Clients ändert, der Träger still mit dem falschen Ort spricht. Hinter NAT mit kurzem UDP-Timeout ist das ein Tunnel, der ohne sichtbaren Grund alle paar Minuten stirbt.\n--keep-open tut auf UDP nicht, was du willst. Ncats -k hält einen TCP-Listener am Annehmen, nachdem ein Peer weg ist. Auf UDP gibt es nichts anzunehmen, also heißt Wiederherstellung, den Träger neu zu starten — wofür persist und holdoff da sind, weiter unten.\nBeide sind Argumente für socat, das UDP-Peers sorgfältiger behandelt, und für einen Supervisor, statt darauf zu vertrauen, dass es oben bleibt.\nWarum PPP Ein Verlorenes Datagramm Übersteht Der offensichtliche Einwand gegen einen UDP-Träger ist, dass PPP einen Byte-Stream erwartet und UDP keiner ist: Datagramme kommen ganz oder gar nicht an und können außer der Reihe ankommen. Es funktioniert trotzdem, wegen zweier Bytes, die das Framing die ganze Zeit getragen hat.\nEin verlorenes Datagramm kostet einen Frame, das nächste Flag-Byte holt den Link zurück Die Grenzen passen nicht zusammen, und das ist egal PPP-FRAMES, WIE pppd SIE SCHRIEB 7E Frame A + FCS 7E Frame B + FCS 7E Frame C + FCS 7E Frame D + FCS WAS DER TRÄGER WIRKLICH SCHICKTE — Netcat liest einen Puffer, keinen Frame Datagramm 1 Datagramm 2 — verloren Datagramm 3 Datagramm 4 Frame B verliert seine Mitte, also scheitert die Prüfsumme und er wird verworfen. Frame C verliert seine ersten Bytes und geht denselben Weg. Zwei verlorene Frames sind zwei verlorene IP-Pakete. Die Schicht darüber überträgt sie neu, und zwar im Wissen, dass der Pfad etwas verlor — genau das Signal, das ein TCP-Träger verborgen hätte, indem er sie stattdessen spät zugestellt hätte. Netcat liest, was auch immer im Puffer ist, und schreibt es in ein Datagramm, sodass Frame-Grenzen und Datagramm-Grenzen nichts miteinander zu tun haben. Verlier ein Datagramm und der Empfänger sieht einen Frame, dem Bytes fehlen: Die Frame-Prüfsequenz scheitert und der Frame wird verworfen, genau wie auf einer verrauschten seriellen Leitung. Das nächste 0x7E synchronisiert den Stream neu. Ein verworfener Frame kostet ein Paket, und die Schicht darüber überträgt es neu — was das Verlustsignal ist, das das innere TCP brauchte und über einen TCP-Träger nie bekam. PPP über asynchrones HDLC wurde für eine Leitung entworfen, die Bytes verfälscht. Jeder Frame trägt eine 16-Bit-Frame-Prüfsequenz; ein Frame, der sie nicht besteht, wird verworfen, und das nächste Flag-Byte synchronisiert den Empfänger neu. Umsortierung ist seltener als Verlust und ergibt dasselbe Ergebnis: eine schlechte FCS, ein verworfener Frame, ein Neusynchronisieren.\nEin verlorenes Datagramm kostet also einen PPP-Frame — ein IP-Paket, den Normalzustand jedes je gebauten Netzwerks. Der Besitzer des Pakets überträgt neu, und die Überlastkontrolle sieht einen echten Verlust und reagiert richtig. Das ist das ganze Argument für UDP: Es lässt den Verkehr im Tunnel die Wahrheit über die Leitung herausfinden.\nLass die Frames aber nicht groß genug werden, dass der Träger sie fragmentieren muss. Ein verlorenes Fragment tötet dann das ganze Datagramm und deine effektive Verlustrate vervielfacht sich. Halt die PPP-MTU deutlich unter der Pfad-MTU.\nAdressen, Routen Und IPv6 Richtig Machen ppp0 ist eine Punkt-zu-Punkt-Schnittstelle — kein Subnetz, kein ARP — also ist local:remote die ganze Adressierung, und du routest ausdrücklich darüber. Für einen einzelnen Host, der ein Netz hinter dem fernen Ende erreicht:\n# on the client, after the link is up ip route add 203.0.113.0/24 via 192.0.2.1 dev ppp0 Damit das ferne Ende im Auftrag des Clients weiterleitet, die üblichen zwei Schritte:\nsysctl -w net.ipv4.ip_forward=1 nft add rule inet nat postrouting oifname \u0026#34;eth0\u0026#34; ip saddr 192.0.2.2/32 masquerade proxyarp lässt den Server ARP für den Client auf seinem eigenen Segment beantworten4, was hübsch ist, bis ein zweiter Client dasselbe will. Dann mach den Teil, den die meisten überspringen. Fahr IPv6 darüber — ein Punkt-zu-Punkt-Link ohne NAT, ohne Broadcast-Domäne und ohne Adressknappheit ist der einfachste Ort in deinem Netzwerk, um IPv6 richtig zu machen:\npppd nodetach noauth local \\ +ipv6 ipv6 ::1,::2 \\ nodefaultroute noipdefault \\ 192.0.2.2:192.0.2.1 \\ pty \u0026#39;ncat --udp 198.51.100.10 443\u0026#39; +ipv6 schaltet IPV6CP ein; ipv6 \u0026lt;local\u0026gt;,\u0026lt;remote\u0026gt; setzt die zwei 64-Bit-Interface-Identifier4, der Link kommt link-local hoch, und du legst ein globales /64 oben drauf7. IPV6CP ist unabhängig von IPCP, also trägt noip nichts als IPv6 — eine vernünftige Sache, die man 2026 bauen kann, in einem Wort.\nIhn Oben Halten, Wenn Der Träger Still Stirbt Das ist der Fehler, der einen Nachmittag verschwendet, also bekommt er einen eigenen Abschnitt.\nEin TCP-Träger, der schlecht stirbt — das ferne Ende ausgeschaltet, ein NAT-Tabelleneintrag abgelaufen, eine Middlebox, die aufgehört hat weiterzuleiten — schließt nicht. Es gibt kein FIN, kein RST, nichts. Netcat sitzt da und hält einen Socket, der nie ein weiteres Byte liefert, pppd sitzt da und hält ein pty, das nie einen weiteren Frame sieht, und ip link meldet fröhlich ppp0 als UP. Ein UDP-Träger hat überhaupt keinen Verbindungszustand, also bemerkt er nie etwas.\nPPP hat die Antwort eingebaut, und sie ist standardmäßig aus:\nlcp-echo-interval 10 lcp-echo-failure 3 Das sendet alle zehn Sekunden ein LCP-Echo und reißt den Link nach drei unbeantworteten ab4 — dreißig Sekunden, um einen toten Träger zu erwischen, genau in dem Fall, den die Manpage nennt, „no hardware modem control lines“4, also jedes je gemachte pty. Dann entscheide, was danach passiert:\npersist maxfail 0 holdoff 5 Einen toten Träger in dreißig Sekunden erkennen und neu aufbauen Ein Träger kann sterben, ohne zu schließen. So merkt PPP es und erholt sich. Träger stirbt still fernes Ende aus · NAT-Eintrag weg · Middlebox leitet nicht mehr weiter Nichts meldet es kein FIN, kein RST · ip link sagt weiter ppp0 UP · UDP hat keinen Zustand Der Detektor lcp-echo-interval 10 lcp-echo-failure 3 Echo alle 10s, aus nach 3 verpassten — 30s Der Neuaufbau persist maxfail 0 holdoff 5 neu starten, nie aufgeben, 5s Pause je Versuch Ein Supervisor systemd-Unit, Restart=always, pppd führt den pty-Befehl erneut aus — frischer Netcat und Socket dazu Setz das Echo an beiden Enden. Ein Echo beweist nur den Pfad, auf dem die Antwort zurückkam. Leg `ip route` in /etc/ppp/ip-up.d/ und die IPv6-Routen in /etc/ppp/ipv6-up.d/, damit das Routing bei jeder Rückkehr des Links neu gesetzt wird — nicht einmal von Hand gesetzt und beim ersten Reconnect verloren. lcp-echo-interval 10 lcp-echo-failure 3 ist der Detektor: Echo alle zehn Sekunden, Link runter nach drei verpassten. persist maxfail 0 holdoff 5 ist der Wiederaufbau: neu starten, nie aufgeben, fünf Sekunden warten, damit eine flatternde Leitung keine Fork-Bombe wird — und pppd fährt den pty-Befehl neu, sodass ein frisches netcat und ein frischer Socket mitkommen. Setz das Echo auf beiden Enden; ein Supervisor, eine systemd-Unit mit Restart=always, schlägt zwei streitende Prozesse. Leg ip route in /etc/ppp/ip-up.d/, damit das Routing mit dem Link zurückkommt. Es Hat Keine Verschlüsselung Und Keine Authentifizierung Alles oben ist ein funktionierender Tunnel. Es ist kein sicherer, und die Lücke ist kein Detail.\nEs gibt keine Verschlüsselung. Keine schwache Verschlüsselung. Keine. Jedes Paket, das du hier durchschickst, ist im Klartext auf der Leitung, in einen HDLC-Frame gewickelt, den jedes Aufzeichnungswerkzeug auf den ersten Blick dekodiert. tcpdump zeigt dir den Inhalt des Tunnels eines anderen so bereitwillig wie deinen eigenen.\nEs gibt keine Authentifizierung des Peers. noauth sagt es. Ein Netcat-Listener nimmt an, was auch immer am Port ankommt: die erste Verbindung oder das erste Datagramm von irgendwo. Wer zuerst dort ist, bekommt einen gerouteten Link in dein Netzwerk. PPP hat durchaus Authentifizierung (PAP im Klartext, CHAP als Challenge-Response8), und beide beweisen, wer der Peer ist, während sie kein einziges Byte des Folgenden verschlüsseln: CHAP hier gibt dir einen Tunnel, der weiß, mit wem er spricht, und den Inhalt trotzdem an jeden auf der Leitung veröffentlicht.\nEs gibt eine Verschlüsselungsoption in der PPP-Familie — MPPE9, das Modul liegt in ppp_mppe.ko. Greif nicht danach: Es ist RC4, geschlüsselt aus dem MS-CHAPv2-Austausch, seit über einem Jahrzehnt öffentlich gebrochen, und der Grund, warum PPTP tot ist. 2026 einen neuen Tunnel darauf zu bauen wählt eine bekannt gebrochene Chiffre über eine funktionierende, die nichts kostet.\nAlso die ehrliche Zusammenfassung bisher: ein gerouteter Link ohne Vertraulichkeit und ohne Zugangskontrolle. Gut fürs Labor, gut innerhalb eines Links, der bereits verschlüsselt ist, nirgendwo sonst gut. Die Lösung ist, den Träger zu verschlüsseln — die nächsten zwei Abschnitte, und der Grund, ncat zu nehmen statt des Netcat, das deine Distribution ausgeliefert hat.\nStufe Drei: Den Träger In TLS Wickeln Die saubere Antwort lässt pppd genau so, wie es ist, und ersetzt den Träger durch einen, der TLS macht. pppd erfährt nie, dass sich etwas geändert hat.\nZuerst das Zertifikat. Ein selbstsigniertes reicht, solange der Client es prüft. Eine ungeprüfte TLS-Sitzung ist ein verschlüsseltes Gespräch mit jemandem, den du nicht identifiziert hast, was niemanden aufhält:\nopenssl req -x509 -newkey rsa:4096 -days 825 -nodes \\ -keyout tunnel.key -out tunnel.crt \\ -subj \u0026#34;/CN=tunnel.example.net\u0026#34; \\ -addext \u0026#34;subjectAltName=DNS:tunnel.example.net\u0026#34; Ncat Ncat hat TLS eingebaut. Es kettet auch durch einen Proxy, --proxy host:port --proxy-type http|socks4|socks510, sodass der Träger an einem Relay enden kann statt am fernen Ende des Tunnels. Das ist der Punkt, um den sich der Egress-Abschnitt dreht. Lauschendes Ende:\npppd nodetach noauth local passive \\ nodefaultroute noipdefault 192.0.2.1:192.0.2.2 \\ lcp-echo-interval 10 lcp-echo-failure 3 mtu 1400 mru 1400 \\ pty \u0026#39;ncat --listen --keep-open --ssl --ssl-cert tunnel.crt --ssl-key tunnel.key 443\u0026#39; Verbindendes Ende:\npppd nodetach noauth local \\ nodefaultroute noipdefault 192.0.2.2:192.0.2.1 \\ lcp-echo-interval 10 lcp-echo-failure 3 mtu 1400 mru 1400 \\ pty \u0026#39;ncat --ssl --ssl-verify --ssl-trustfile tunnel.crt tunnel.example.net 443\u0026#39; --ssl-verify ist das Wort, auf das es ankommt. Ohne es gibt dir --ssl Verschlüsselung gegen einen passiven Listener und nichts gegen den, der zuerst am Port antwortet; mit ihm prüft Ncat Vertrauen und Domainnamen gegen die Trust-Datei11. Ncat hat aber keine serverseitige Client-Zertifikatsprüfung, der Server kann den Client also nicht identifizieren. Kombinier es mit CHAP, oder nimm eines der nächsten zwei.\nStunnel Der traditionelle Wrapper, und der eine, der gegenseitige Authentifizierung richtig macht:\n[ppp] accept = 443 connect = 127.0.0.1:6001 cert = /etc/stunnel/tunnel.crt key = /etc/stunnel/tunnel.key CAfile = /etc/stunnel/clients.crt verify = 2 verify = 2 verlangt ein Client-Zertifikat, das von einer CA in CAfile signiert ist — die Zugangskontrolle, die der Netcat-Bau nie hatte. Der Client fährt stunnel im Client-Modus, und pppds pty-Befehl verbindet sich mit der lokalen Klartext-Seite.\nSocat socat macht das Ganze in einem Prozess pro Ende, mit standardmäßig eingeschalteter Prüfung:\n# listening end pppd ... pty \u0026#39;socat - OPENSSL-LISTEN:443,reuseaddr,cert=tunnel.pem,cafile=clients.crt,verify=1\u0026#39; # connecting end pppd ... pty \u0026#39;socat - OPENSSL:tunnel.example.net:443,cafile=tunnel.crt,verify=1\u0026#39; socat ist auf der Maschine, auf der das geschrieben wurde, nicht installiert, das stammt also aus seiner Dokumentation — prüf deine eigenen Flags. Es lohnt sich zu haben: Es ist das einzige Werkzeug in diesem Beitrag, das tun, tap, TLS und DTLS in einem Prozess macht.\nOpenssl, Wenn Es Nichts Anderes Gibt openssl ist auf jeder Kiste, die überhaupt TLS hat, und s_server/s_client tragen eine Pipe:\n# listening end pppd ... pty \u0026#39;openssl s_server -quiet -accept 443 -cert tunnel.crt -key tunnel.key\u0026#39; # connecting end pppd ... pty \u0026#39;openssl s_client -quiet -verify_return_error -CAfile tunnel.crt -connect tunnel.example.net:443\u0026#39; -quiet unterdrückt das Banner, das sonst in deinem PPP-Stream landen würde, und -verify_return_error lässt einen Prüffehler die Verbindung schließen, statt zu warnen und weiterzumachen. Das sind Debugging-Werkzeuge, die sich auch so verhalten, aber auf einer Kiste, wo du nichts installieren kannst, bringen sie einen Link hoch.\nSchlicht, TLS über TCP, oder DTLS über UDP Dieselbe Link-Hälfte an beiden Enden. Nur die Mitte ändert sich. pppd oder tap0 schlichtes Netcat, UDP ncat --udp --listen 6000 pppd oder tap0 Im Klartext auf der Leitung, und der Listener nimmt, wer zuerst am Port ist. Keine Vertraulichkeit, keine Zugangskontrolle. pppd oder tap0 TLS über TCP — ncat, stunnel oder openssl ncat --ssl --ssl-verify --ssl-trustfile tunnel.crt host 6000 pppd oder tap0 Geschützt, und das Zertifikat sagt, wer das ferne Ende ist. Aber der Träger ist wieder TCP — und es ist die einzige Form, die stream-komprimieren kann. pppd oder tap0 DTLS über UDP — socat oder openssl socat - OPENSSL-DTLS-CLIENT:host:6000,cafile=tunnel.crt,verify=1 pppd oder tap0 Verschlüsselt, authentifiziert und immer noch Datagramme. Ein verlorenes Paket bleibt verloren, statt dass zwei Stacks streiten. Ziel hierauf. Durchgehend dasselbe pppd an beiden Enden — nur der pty-Befehl ändert sich. Reines Netcat gibt dir einen Link, den nichts schützt. TLS über TCP schützt die Bytes und führt das Träger-TCP-Problem wieder ein. DTLS über UDP ist die Form, die man anstreben sollte: verschlüsselt, authentifiziert und immer noch ein Datagramm-Träger, sodass ein verlorenes Paket ein verlorenes Paket bleibt, statt zu einem Neuübertragungs-Kampf zwischen zwei Stacks zu werden. Stufe Vier: DTLS, Weil Der Träger Immer Noch UDP Sein Sollte Hier ist der heikle Teil, und der Grund, warum dieser Abschnitt getrennt ist. Jede TLS-Option oben läuft über TCP, sodass das Wickeln des Trägers in TLS das Argument für UDP zunichtemacht und dir den Zusammenbruch zurückgibt. Verschlüsselung und der richtige Transport sollten kein Tauschgeschäft sein. DTLS ist TLS über Datagramme, und es ist, was du willst: Es behält den Schutz der Record-Schicht, lässt die Reihenfolgen- und Neuübertragungsgarantien fallen und lässt verlorene Pakete verloren, was genau das ist, was PPPs Frame-Prüfsequenz aufzufangen gebaut ist.\nNcat kann es nicht. socat und openssl können:\n# listening end pppd ... pty \u0026#39;socat - OPENSSL-DTLS-LISTEN:443,cert=tunnel.pem,cafile=clients.crt,verify=1\u0026#39; # connecting end pppd ... pty \u0026#39;socat - OPENSSL-DTLS-CLIENT:tunnel.example.net:443,cafile=tunnel.crt,verify=1\u0026#39; Und mit openssl allein, wo -dtls irgendeine DTLS-Version wählt:\n# listening end pppd ... pty \u0026#39;openssl s_server -quiet -dtls -accept 443 -cert tunnel.crt -key tunnel.key\u0026#39; # connecting end pppd ... pty \u0026#39;openssl s_client -quiet -dtls -verify_return_error -CAfile tunnel.crt -connect tunnel.example.net:443\u0026#39; Achte auf die Frame-Größe. Ein DTLS-Record kann nicht so fragmentiert werden, wie sich ein TLS-Record über einen TCP-Stream verteilt, also muss alles auf einmal in die Pfad-MTU passen.\nDer Overhead-Stapel, und die innere MTU, die übrig bleibt Rechne von der Pfad-MTU herunter und nimm, was übrig bleibt IP-Header20 (v4) / 40 (v6) UDP-Header8 DTLS-Record + Tag≈ 30 PPP-/Ethernet-Framingein paar innere MTU — was der Tunnel tragen kann: ziel 1400, Untergrenze 1280 Ein DTLS-Record kann nicht so fragmentiert werden, wie sich ein TLS-Record über einen TCP-Stream verteilt, also muss das alles auf einmal in die Pfad-MTU passen. Dieselbe Form wie OpenVPN seit 2001 — ein Datagramm-Träger, DTLS, eine virtuelle Schnittstelle obendrauf. Nicht exzentrisch; nur entbündelt. Rechne von 1500 herunter: 20 Byte IPv4-Header oder 40 von IPv6, 8 von UDP, etwa 30 für den DTLS-Record und sein Tag, ein paar fürs Framing, und der Rest ist die innere MTU, die der Tunnel tragen kann. Ziel 1400 auf einem gewöhnlichen Pfad; 1280 ist die sichere Untergrenze, wenn irgendetwas in der Mitte selbst ein Tunnel ist. Diese Form — ein Datagramm-Träger, DTLS, eine virtuelle Schnittstelle obendrauf — ist nahe genug an dem, was OpenVPN seit 2001 macht. Nicht exzentrisch; nur ausgepackt. Den PPP-Bau Einstellen: MTU, Kompression Und Was Wirklich Hilft Vier Knöpfe, alles pppd-Optionen — der Tap-Bau im nächsten Abschnitt hat keinen davon, weil er keine der Maschinerie hat, die sie einstellen.\nVier pppd-Knöpfe: einer zu setzen, einer zu lassen, zwei auszuschalten Einer zu setzen, einer zu lassen, zwei auszuschalten SETZ IHN MTU und MRU Beide Enden, mit Luft: 1400 schlicht, 1280 unter einem Tunnel. Ein fragmentierter Frame verliert ein ganzes Paket. LASS IHN ACCM Standardmäßig schon null, und das ist richtig auf einem sauberen Socket. Fass sie nur an, wenn etwas Steuerzeichen frisst. SCHALT AUS novj Van-Jacobson-Headerkompression Spart einen Rundungsfehler auf schneller Leitung, kostet CPU pro Paket und bricht unter Verlust. Aus über Modemtempo. SCHALT AUS nodeflate nobsdcomp Die Nutzlast ist schon TLS/DTLS — Geheimtext zu komprimieren ist pure Arbeit, und über eine Sicherheitsgrenze hinweg ein Angriff. Keiner davon macht den Tunnel schneller. PPP ist nicht der Engpass — PPPoE macht 2 Gbit auf demselben Daemon, weil sein Datenpfad im Kernel bleibt. Die Kosten hier sind das pty: Jedes Byte geht in den Userspace und zurück. Das gehört zum Pseudo-Terminal, nicht zu PPP. MTU und MRU ist der eine, auf den es ankommt: Setz beide auf beiden Enden mit Spielraum, denn ein Frame, den der Träger fragmentieren muss, verliert bei jedem Verlust ein ganzes Paket. Die ACCM ist schon null und auf einem sauberen Socket richtig. Schalte die Van-Jacobson-Header-Kompression mit novj über Modemgeschwindigkeit aus. Sie spart einen Rundungsfehler, kostet CPU pro Paket und bricht unter Verlust. Schalte deflate/bsdcomp aus: Die Nutzlast ist bereits verschlüsselt, und über eine Sicherheitsgrenze zu komprimieren ist ein Angriff, kein Feature. Nichts davon macht den Tunnel schneller, und der Grund ist wichtig, weil PPP dafür die Schuld bekommt und nicht sollte. PPP ist nicht der Flaschenhals. PPPoE trägt 2 Gbit auf demselben Daemon, weil sein Datenpfad nie den Kernel verlässt — ppp_generic und pppoe machen das Framing und die Weiterleitung, und pppd erledigt nur die Kontrollebene. Was dich hier kostet, ist das pty: Jedes Byte kreuzt in den Userspace, durch netcat, in einen Socket und zurück, ein Hin und Her, das PPPoE nie macht. Das gehört zum Pseudo-Terminal, nicht zu PPP.\nWas ein guter Moment ist, sich die andere Art anzusehen, das zu tun, bei der es überhaupt kein pty gibt.\nDer Andere Weg: Ein Tap-Device, Und Ganz Ohne PPP Alles bisher hat PPP für die Link-Hälfte benutzt. Es gibt einen zweiten Weg, eine virtuelle Schnittstelle zu machen, und er braucht überhaupt kein Protokoll.\nDer TUN/TAP-Treiber des Kernels gibt dir eine Schnittstelle und einen Dateideskriptor, aneinander gebunden: Schreib ein Paket in den Deskriptor und es erscheint auf der Schnittstelle, als käme es von einer Leitung; lies, und du bekommst ein Paket, das der Kernel senden wollte. Das ist die ganze Schnittstelle12, und sie ist seit 1999 in Linux.\nip tuntap add dev tap0 mode tap user damien group damien ip link set tap0 mtu 1400 up ip addr add 192.0.2.1/30 dev tap0 Ein Tap-Device ist an einem Ende eine Schnittstelle und am anderen ein Dateideskriptor Kein Daemon, kein Protokoll, kein Pseudo-Terminal. Ein Dateideskriptor. KERNEL tap0 gewöhnliche Schnittstelle, mit Adresse und Route /dev/net/tun TUNSETIFF benennt das benannte Device dein Prozess socat, oder fünfzig Zeilen Python, die den fd halten UDP-Socket ein Frame pro Datagramm das Netzwerk und das ferne Ende ein read = ein Frame Was gegenüber dem PPP-Bau fehlt: keine ausgehandelte Framegröße, keine Lebendprüfung, keine ausgetauschten Adressen, keine Authentifizierung. Du stellst beide Enden von Hand ein und sie reden über nichts davon. Nichts beobachtet den Link, also sagt dir nichts, dass er gestorben ist. Kein Daemon und kein Protokoll. Der Kernel präsentiert tap0 als gewöhnliche Schnittstelle und übergibt die andere Seite davon dem Prozess, der /dev/net/tun geöffnet hat. Ein Lesevorgang liefert genau einen Ethernet-Frame; ein Schreibvorgang injiziert genau einen. Alles, was pppd aushandelte — Adressen, Frame-Größen, Lebendigkeit — konfigurierst du jetzt von Hand an beiden Enden, und die zwei Enden besprechen nichts davon miteinander. Zwei Details in diesem ersten Befehl sind mehr wert, als sie aussehen.\nuser damien macht das Device dauerhaft und unprivilegiert. So erstellt überlebt es den Prozess, der es benutzt, und ein benannter Benutzer kann es öffnen, ohne Root zu sein. Root erstellt das Device einmal; das Ding, das Frames schaufelt, braucht überhaupt kein Root. Behalt diesen Gedanken für den Egress-Abschnitt.\nmode tun ist die andere Hälfte desselben Treibers, und es ist die, die die meisten eigentlich wollen. Tun trägt IP-Pakete. Tap trägt Ethernet-Frames. Der Unterschied ist wichtig genug für einen eigenen Abschnitt weiter unten.\nWas du gegenüber PPP aufgibst, ist alles, was PPP aushandelt: kein LCP, also keine ausgehandelte Frame-Größe und keine Lebendprüfung, kein IPCP/IPV6CP, also beide Enden von Hand konfiguriert, keine Authentifizierung, keine Header-Kompression. Ein Tap-Device ist ein Loch im Kernel, und das Protokoll hindurch ist, was auch immer du hineinlegst. Was du gewinnst, ist überhaupt kein Framing-Overhead, kein Escapen, kein Kontrollkanal und eine Schnittstelle, die gebridgt werden kann.\nTap Über UDP, Wo Ein Datagramm Ein Frame Ist Das ist die sauberste Abbildung im ganzen Beitrag, und sie fällt aus dem Design. Ein Tap-Device ist ein Datagramm-Device — ein read() liefert genau einen Frame — und ein UDP-Socket ist ein Datagramm-Socket, ein sendto() pro Datagramm. Ein Frame geht also in ein Datagramm, kommt als Frame an, und es gibt nichts zu begrenzen, zu puffern oder neu zu synchronisieren. Verlier ein Datagramm und du hast einen Frame verloren, was ein verworfenes Paket ohnehin so aussieht.\nMit socat ist jedes Ende je ein Befehl:\n# listening end socat TUN:192.0.2.1/30,tun-type=tap,tun-name=tap0,iff-up UDP-LISTEN:443 # connecting end socat TUN:192.0.2.2/30,tun-type=tap,tun-name=tap0,iff-up UDP:198.51.100.10:443 socat ist auf der Maschine, auf der das geschrieben wurde, nicht installiert, diese zwei stammen also aus seiner Dokumentation statt aus einem Lauf hier — prüf die Adressnamen deines eigenen Builds, bevor du ihnen traust. Es lohnt sich zu haben: Es ist das einzige Werkzeug in diesem Beitrag, das tun, tap, TLS und DTLS in einem Prozess macht.\nWo du nichts installieren kannst, ist die ganze Aufgabe rund fünfzig Zeilen ohne Abhängigkeiten jenseits der Standardbibliothek. Das Herzstück, IFF_NO_PI schaltet den Vier-Byte-Header aus, den der Treiber sonst voranstellen würde:\nTUNSETIFF, IFF_TAP, IFF_NO_PI = 0x400454CA, 0x0002, 0x1000 # IFF_TUN is 0x0001 def open_tap(name): fd = os.open(\u0026#34;/dev/net/tun\u0026#34;, os.O_RDWR) fcntl.ioctl(fd, TUNSETIFF, struct.pack(\u0026#34;16sH\u0026#34;, name.encode(), IFF_TAP | IFF_NO_PI)) return fd # ... learn the peer from the first datagram (UDP has no accept), then shovel: while True: ready, _, _ = select.select([tap, sock], [], []) if tap in ready and peer: sock.sendto(os.read(tap, MTU), peer) # one read = one frame = one datagram if sock in ready: frame, src = sock.recvfrom(MTU) peer = src # last speaker wins — see the note below if frame: os.write(tap, frame) Die ganze Datei — Argument-Parsing, IPv6 über getaddrinfo, das Null-Längen-Datagramm, das einem UDP-Listener sagt, wo er antworten soll, und die Kompression, die der nächste Abschnitt hinzufügt — ist im Bundle:\n\u0026#8615; tapcat.py — das Ganze, etwa hundert Zeilen tapcat.py · 6 kB peer = src bei jedem Datagramm ist der Teil, den man zweimal lesen sollte. Wer zuletzt einen Frame gesendet hat, wird zum Peer. Praktisch hinter NAT, dessen Quellport ständig wandert, und eine offene Tür in einem nicht vertrauenswürdigen Netzwerk, wo jeder, der ein Datagramm an den Port senden kann, den Tunnel übernimmt. Gut innerhalb einer DTLS-Sitzung, wohin das führt; für sich nicht gut. Die Socket-Hälfte des Skripts wurde hier über IPv6-Loopback geprüft: Der Opener kommt an, der Listener lernt den Peer, ein Frame kreuzt und die Antwort kommt zurück; die Tap-Hälfte braucht Root, der eine Teil, den ich nicht laufen lassen konnte.\nÜber TCP Musst Du Das Framing Selbst Erfinden Tausch nun den Träger gegen TCP und sieh ein ganzes Problem auftauchen, das PPP 1994 still gelöst hat.\nTCP ist ein Byte-Stream ohne Record-Grenzen und ohne Versprechen, wie Bytes bei der Ankunft gruppiert sind: Zwei Frames hintereinander geschrieben können in einem Lesevorgang ankommen, ein Frame in dreien. Der Empfänger hält einen Haufen Bytes ohne Ahnung, wo ein Frame endet, und ein Tap-Device nimmt nur ganze Frames an.\nEin Datagramm pro Frame, oder ein Längenpräfix, das du erfinden musst Ein read von einem Tap-Device ist ein Frame. Das so zu halten ist Aufgabe des Trägers. ÜBER UDP — die Grenze ist gratis Datagramm = Frame A Datagramm = Frame B Datagramm = Frame C Datagramm = Frame D Ein read, ein Datagramm, ein write am fernen Ende. Nichts abzugrenzen, nichts zu puffern, nichts nach einem Verlust neu zu synchronisieren. ÜBER TCP — die Grenzen sind weg und du musst sie zurückbringen ein Byte-Stream — zwei Frames können in einem read ankommen, ein Frame in dreien len Frame A len Frame B len Frame C len Frame D Zwei Bytes Big-Endian-Länge vor jedem Frame, und ein Empfänger, der die Länge liest und dann genau so viele Bytes. Es funktioniert, und es kann sich nicht erholen. HDLC synchronisiert sich am nächsten 0x7E neu, weil ein Flag eindeutig ist; ein längenpräfigierter Stream, der seinen Platz verliert, liest jede Länge danach aus der Mitte eines Frames. Füg eine Marke und eine Prüfsumme dagegen hinzu und du hast HDLC nachgebaut. Über UDP ist ein Frame ein Datagramm und die Grenze kommt gratis. Über TCP sind die Grenzen weg, also muss der Sender jedem Frame ein Längenpräfix voranstellen und der Empfänger daraus wieder zusammensetzen. PPP hat dieses Problem nicht, weil es sein eigenes Framing mitbringt — ein Flag-Byte an jedem Ende und eine Prüfsumme — was auch das ist, was es sich nach Beschädigung neu synchronisieren lässt. Ein längenpräfixierter Stream kann das nicht: Gerät ein Byte aus dem Tritt, ist jeder Frame danach falsch. Über TCP schreibst du also dein eigenes Framing. Zwei Byte Big-Endian-Länge vor jedem Frame ist die übliche Antwort:\n# sending sock.sendall(struct.pack(\u0026#34;!H\u0026#34;, len(frame)) + frame) # receiving def recv_exactly(sock, n): buf = b\u0026#34;\u0026#34; while len(buf) \u0026lt; n: chunk = sock.recv(n - len(buf)) if not chunk: raise ConnectionError(\u0026#34;carrier closed\u0026#34;) buf += chunk return buf length = struct.unpack(\u0026#34;!H\u0026#34;, recv_exactly(sock, 2))[0] frame = recv_exactly(sock, length) Das funktioniert, und es ist strikt schlechter als die UDP-Variante. Es ist wieder das TCP-über-TCP-Problem; es fügt jedem Frame zwei Byte und eine Reassemblierungsschleife hinzu; und es hat keinen Weg zurück aus einem Fehler, weil ein längenpräfixierter Stream, der seinen Platz verliert, jede folgende Länge aus der Mitte eines Frames liest. HDLC synchronisiert sich am nächsten 0x7E neu; das hier kann es nicht, außer HDLC schlechter neu zu erfinden. Drittes Argument für UDP, und das stärkste: Über einen Datagramm-Träger gibt es kein Framing-Problem, weil der Träger das eine Feature, das du brauchtest, bereits hat.\nTun Oder Tap: Schicht 3, Es Sei Denn, Du Brauchst Wirklich Schicht 2 Derselbe Treiber gibt dir zwei Devices, und Leute wählen ständig das falsche, weil ein Tutorial tap sagte.\ntun tap Was hindurchgeht IP-Pakete Ethernet-Frames Overhead pro Paket keiner 14-Byte-Ethernet-Header ARP, DHCP, Broadcast nein ja, alles davon, über den Tunnel Nicht-IP-Protokolle nein ja Kann einer Bridge beitreten nein ja Entspricht einem Punkt-zu-Punkt-Link, wie ppp0 einem Netzwerkkabel Tun ist ein gerouteter Link — wie die PPP-Schnittstelle aus der ersten Hälfte: zwei Adressen, eine Route, Pakete rein und raus. Tap ist ein virtuelles Ethernet-Kabel, sodass jeder Broadcast, jede ARP-Anfrage und jedes bisschen Multicast-Rauschen auf dem Segment nun deinen Tunnel kreuzt und Bandbreite verbrennt.\nÄndere eine Zeile im Skript zum Umschalten:\nIFF_TUN = 0x0001 # instead of IFF_TAP Nimm tap, wenn du wirklich Schicht 2 brauchst. Es gibt echte Gründe: ein Protokoll, das nicht IP ist, ein Cluster-Heartbeat, der Broadcasts sehen erwartet, ein DHCP-Server, der Clients über den Tunnel erreichen muss, oder zwei Segmente in eines zu bridgen.\nDas Letzte ist der häufige Fall und der, mit dem man vorsichtig sein muss:\nip link add br0 type bridge ip link set tap0 master br0 ip link set eth1 master br0 ip link set br0 up Nun ist das ferne Segment Teil deines lokalen — seine Broadcasts, sein Spanning Tree, sein MAC-Gewirbel und, wenn jemand unvorsichtig war, sein DHCP-Server. Zwei Standorte zu bridgen, die beide 192.168.1.0/24 fahren, ist ein schlechter Nachmittag; einer, der über einen anderen Pfad auf dasselbe Segment zurückschleift, ist eine schlechte Woche. Standardmäßig tun, greif zu tap, wenn du das Schicht-2-Ding benennen kannst, das du brauchst, und bridge erst, nachdem du geprüft hast, was auf beiden Seiten broadcastet.\nDieselben Wrapper, Ein Prozess Pro Ende Der Tap-Bau hat dieselbe Lücke wie der PPP-Bau: Der Träger ist im Klartext und der Listener nimmt an, wer zuerst dort ist. Die Lösung ist dieselbe, und mit socat fällt sie zu einem Befehl pro Ende zusammen, weil es das Device macht und die DTLS-Sitzung in einem einzigen Prozess beendet:\n# listening end socat TUN:192.0.2.1/30,tun-type=tap,tun-name=tap0,iff-up \\ OPENSSL-DTLS-LISTEN:443,cert=tunnel.pem,cafile=clients.crt,verify=1 # connecting end socat TUN:192.0.2.2/30,tun-type=tap,tun-name=tap0,iff-up \\ OPENSSL-DTLS-CLIENT:tunnel.example.net:443,cafile=tunnel.crt,verify=1 Das ist der kürzeste korrekte Bau in diesem Beitrag. Eine virtuelle Schnittstelle, ein Datagramm-Träger, gegenseitige Zertifikatsauthentifizierung und Verschlüsselung. Zwei Befehle. Kein Daemon, keine Protokollaushandlung.\nverify=1 ist nicht optional — derselbe Punkt wie --ssl-verify, und mit dem peer = src-Verhalten oben ist eine nicht identifizierte Partei ein Datagramm davon entfernt, deinen Tunnel zu besitzen. Wenn du beim Python-Skript festsitzt, schraub kein TLS hinein: Richt es auf einen Loopback-Port und stell den Wrapper davor, oder nimm socat. Ein selbstgebauter TLS-Wrapper um einen selbstgebauten Tunnel sind zwei Chancen, den interessanten Teil falsch zu machen.\nStufe Fünf: Den Stream Mit zstd Komprimieren Es gibt noch eine Sache, die es wert ist, ins Backend zu setzen, und anders als die Kompressionsoptionen von pppd kann sie sich wirklich lohnen: Komprimier die Frames mit zstd, bevor sie in den Träger gehen.\nDas wichtige Wort dort ist Frames, Plural. Komprimier den Stream, nicht jedes Paket für sich. Es ist der größte gemessene Effekt in diesem Beitrag.\nNetzwerkverkehr ist auf eine Art wiederholend, die sich nur über Pakete hinweg zeigt — dieselben Header, Hostnamen und JSON-Schlüssel, immer wieder. Ein Kompressor, der bei jedem 1.400-Byte-Frame frisch anfängt, sieht nichts davon; einer, der sein Fenster über Frames behält, sieht alles davon.\nErst komprimieren, dann verschlüsseln — und das Fenster halten, wenn der Träger es zulässt Die Reihenfolge steht fest. Der Modus ist die Entscheidung. tap0ein read, ein Frame komprimierenzstd, Level 1 verschlüsselnDTLS oder TLS TrägerUDP oder TCP Nie anders- herum. FLUSH_BLOCK — das Fenster halten Gibt alles bisherige aus, behält die Historie. Jeder Frame wird gegen jeden Frame davor kodiert. Keine zusätzliche Latenz: ein Frame rein, ein Frame raus. 5.0% auf repetitivem Verkehr · 7,5 % auf Log-Zeilen Braucht jeden Frame zugestellt, in Reihenfolge. Also: TCP oder TLS über TCP. Nicht UDP, nicht DTLS. FLUSH_FRAME — bei jedem Paket wegwerfen Jedes Datagramm ist ein vollständiger zstd-Frame und dekodiert für sich, also geht Datagramm N noch, wenn 1 bis N-1 verloren sind. Der einzige Modus, den ein Datagramm-Träger nutzen kann. 14.8% auf demselben Verkehr · 24,2 % auf Log-Zeilen Ein trainiertes Wörterbuch holt das meiste zurück: 5,3 % und 15,1 %, und es bleibt verlusttolerant. Die Kompression geht zwischen das Tap-Device und den Träger, und vor die Verschlüsselung, weil Chiffretext sich nicht komprimieren lässt. FLUSH_BLOCK ist der Modus, auf den es ankommt: Er gibt alles Bisherige aus, sodass ein Frame rein einen Frame raus ohne zusätzliche Latenz gibt, während er die Kompressionshistorie für den nächsten Frame behält. FLUSH_FRAME wirft diese Historie bei jedem Paket weg, was ihn über einen verlustbehafteten Träger sicher macht und ihn auf der Leitung dreimal schlechter. Auf einem aktuellen Fedora braucht das nichts installiert — Python 3.14 brachte zstd in die Standardbibliothek13; diese Kiste hat 3.14.7 gegen zstd 1.5.7:\nfrom compression.zstd import ZstdCompressor, ZstdDecompressor # Python 3.14+ _c, _d = ZstdCompressor(level=1), ZstdDecompressor() # FLUSH_BLOCK: emit everything so far, keep the window for the next frame. out = _c.compress(frame, mode=ZstdCompressor.FLUSH_BLOCK) frame = _d.decompress(out) Ein Kompressor pro Richtung, lebendig für die Lebensdauer des Links. Ein FLUSH_BLOCK pro Frame, sodass ein Frame in dem Moment rausgeht, in dem er ankommt, ohne dass etwas gepuffert wird, und das ferne Ende einen Frame pro Block zurückgibt.\nWas Das Fenster Wert Ist, Gemessen Zahlen von dieser Maschine. Dieselben 1.400-Byte-Frames, dasselbe Level 1, der einzige Unterschied ist, ob der Kompressor seine Historie behält:\nVerkehr im Tunnel Stream, FLUSH_BLOCK pro Paket, FLUSH_FRAME pro Paket mit trainiertem Wörterbuch Wiederholende API-Aufrufe und Telemetrie 5,0 % 14,8 % 5,3 % Log-Zeilen 7,5 % 24,2 % 15,1 % Klartext und Konfigurationsdateien 37,8 % 51,3 % 45,3 % Zufällige Bytes, stellvertretend für TLS 100 %+ 100,7 % — Der Durchsatz bei Level 1 lief 205 MB/s auf Text und über 1 GB/s auf dem wiederholenden Verkehr — je komprimierbarer, desto schneller, weil es weniger zu kodieren gibt.\nLog-Verkehr geht auf 7,5 % seiner Originalgröße, gegen 24,2 % pro Paket — dreifach, dieselben Daten, dasselbe Level, aus einem Flag. Und Level 1 ist das Level: Level 3 brachte etwa ein Prozent, Level 9 ein weiteres, während es den Durchsatz von 211 MB/s auf 61 fallen ließ.\nDer Haken, Und Es Ist Derselbe Haken Wie Bei Allem Anderen Hier Ein geteiltes Fenster heißt, jeder Frame hängt von den vorigen ab: Verlier einen und die Historie des Dekompressors passt nicht mehr, und nichts danach dekodiert. Also braucht die Stream-Kompression einen Träger, der alles der Reihe nach zustellt — TCP, oder TLS über TCP, nicht UDP oder DTLS. Das ist das eine ehrliche Argument für den TCP-Träger im ganzen Beitrag. Wenn das, was durch deinen Tunnel geht, wirklich komprimierbar ist — Syslog, Datenbankreplikation im Klartext, Telemetrie, eine geschwätzige API — bewegt eine stream-komprimierte TLS-Sitzung ein Drittel der Bytes, die ein Datagramm-Träger würde, was auf einem anständigen Pfad die Neuübertragungsstrafe schlagen kann. Miss es an deinem eigenen Verkehr.\nÜber UDP, Wo Ein Wörterbuch Die Aufgabe Des Fensters Macht Wo der Träger UDP oder DTLS ist, und das sollte er standardmäßig sein, kannst du kein Fenster behalten: Jedes Datagramm steht für sich, was FLUSH_FRAME und die schwächere Spalte oben heißt. Ein trainiertes Wörterbuch gibt dem Kompressor den paketübergreifenden Kontext, den ein Fenster hätte, ohne irgendeine Abhängigkeit zwischen Datagrammen:\n# capture a few thousand real frames off the link first, one per file zstd --train frames/* -o tunnel.dict --maxdict=110000 ```[^zstddict] ```python from compression.zstd import ZstdCompressor, ZstdDecompressor, ZstdDict d = ZstdDict(open(\u0026#34;tunnel.dict\u0026#34;, \u0026#34;rb\u0026#34;).read()) _c = ZstdCompressor(level=1, zstd_dict=d) # load it ONCE, not per frame out = _c.compress(frame, mode=ZstdCompressor.FLUSH_FRAME) Auf dem wiederholenden Verkehr, der die Kompression pro Paket von 14,8 % auf 5,3 % brachte, 96 % der Lücke zur vollen Stream-Kompression zurückgewonnen, während es verlusttolerant blieb; bei Log-Zeilen 55 % der Lücke, bei allgemeinem Text 44 %.\nDrei Regeln kommen damit. Beide Enden müssen dasselbe Wörterbuch laden, sonst dekodiert nichts — hier geprüft, ein wörterbuchkomprimierter Frame wirft ZstdError ohne es. Trainier auf einer Aufzeichnung des echten Verkehrs, denn ein Wörterbuch ist eine Vorannahme und eine falsche kostet dich: Das Text-Wörterbuch machte anderen Text leicht schlechter. Und lad es einmal in einen langlebigen Kompressor; es pro Aufruf zu übergeben maß 5 MB/s, was kein Tippfehler ist.\nDas Header-Byte Und Die Ein-Sekunden-Rampe Zwei kleine Dinge, die verhindern, dass das brüchig ist.\nJedes Datagramm trägt ein Ein-Byte-Header, und es benennt den Modus, statt nur „komprimiert“ zu sagen: 0x00 der Frame, wie er ist, 0x01 ein eigenständiger zstd-Frame, 0x02 ein Block aus einem fortlaufenden Stream. Ein Empfänger kann dann dekodieren, was auch immer das ferne Ende wählte, ohne dafür konfiguriert zu sein, was das Byte allein wert ist.\nIm Frame-Modus sendet der Sender die komprimierte Form nur, wenn sie tatsächlich kleiner ist, denn Kompression ist nicht immer ein Gewinn: Zufällige Bytes kamen auf 100,7 % heraus, und ein 64-Byte-TCP-ACK komprimiert auf 73 — das Zehn-Byte-zstd-Header auf einem Paket, an dem nichts zu quetschen ist. Paketzahlen auf einer echten Leitung werden von kleinen Paketen dominiert, also würdest du ohne diese Prüfung die Mehrheit deines Verkehrs aufblähen, um die Minderheit zu schrumpfen. Im Stream-Modus sendet er immer die komprimierte Form, denn eine zu überspringen brächte die zwei Fenster aus dem Tritt.\nUnd der Link startet roh: In der ersten Sekunde geht jeder Frame unkomprimiert raus, egal was die Einstellungen sagen, und jede Richtung rampt für sich hoch:\nRAMP = 1.0 # seconds of raw frames before compression starts def pack(self, frame): if self.c is None or time.monotonic() - self.started \u0026lt; RAMP: return RAW + frame out = self.c.compress(frame, mode=ZstdCompressor.FLUSH_BLOCK) return ZSTD + out if len(out) \u0026lt; len(frame) else RAW + frame Das ist die Stufen-Idee vom Anfang des Beitrags, angewandt auf einen einzelnen Link. Der Tunnel kommt auf dem einfachsten Pfad hoch, den er hat, beweist, dass er einen Frame tragen kann, und fängt erst dann an, etwas Cleveres zu tun. Wenn er kaputtgeht, weißt du, in welcher Sekunde er kaputtging.\nStufe Sechs: Komprimiert Und Verschlüsselt, Und Was Die Reihenfolge Kostet Die Reihenfolge ist wichtig, und nur eine funktioniert: erst komprimieren, dann verschlüsseln. Chiffretext lässt sich nicht komprimieren, wie die 100,7-%-Zeile zeigt — weshalb auch TLS 1.3 seine eigene Kompression entfernte und deine Schicht als den einzigen Ort ließ, es zu tun. Diese Reihenfolge hat ein bekanntes Problem, dasselbe, das ich gegen deflate anführte: Vor dem Verschlüsseln zu komprimieren leckt Klartext über die Länge des Chiffretexts, und wo ein Angreifer gewählte Daten neben ein Geheimnis einschleusen und die Größen beobachten kann, ist dieses Leck mehr als einmal zu einem funktionierenden Angriff geworden — CRIME und BREACH gegen TLS14, und VORACLE gegen genau diese Form15.\nDas ist kein Grund, nie zu komprimieren. Es ist ein Grund zu wissen, in welchem Fall du bist:\nEin Link, der deinen eigenen Verkehr zwischen zwei Kisten trägt, die dir gehören — Replikation, Backups, Logs, Telemetrie — hat keinen vom Angreifer gewählten Klartext, der mit Geheimnissen reist. Komprimier ihn, und komprimier den Stream. Ein Link, der beliebiges Nutzer-Browsing trägt, wo der Web-Inhalt eines anderen und deine Zugangsdaten zusammen gehen, ist der Fall, über den VORACLE geschrieben wurde. Lass es aus. Der Grund, warum es mir wohl ist, das in den Tap-Bau zu setzen und nicht in den PPP-Bau, ist kein Prinzip: Hier wählst du bewusst einen modernen Algorithmus, für Verkehr, den du dir angesehen hast, während pppds deflate standardmäßig alles mit einem von 1996 komprimiert, ob der Fall passt oder nicht.\nWas Der Tap-Bau Gewinnt Und Was Er Aufgibt Stell die zwei Hälften nebeneinander, denn sie konkurrieren nicht. Es sind verschiedene Kompromisse.\npppd über einen Socket tap oder tun über einen Socket Framing eingebaut (HDLC, synchronisiert sich nach Beschädigung neu) keins über UDP, weil keins nötig ist; erfinde es über TCP Adress-Setup von IPCP und IPV6CP ausgehandelt von Hand an beiden Enden konfiguriert Lebendigkeit LCP-Echo, eingebaut keine; du fügst sie hinzu oder der Link stirbt still Authentifizierung PAP oder CHAP verfügbar, beide schwach überhaupt keine Schicht nur 3 3 mit tun, 2 mit tap Bridging nein ja, mit tap Overhead Flag, Header und FCS pro Frame, plus Escapen nichts, oder 14 Byte mit tap Kompression deflate und BSD, standardmäßig an, von 1996 keine, oder zstd pro Frame, das du hinzufügst und kontrollierst Root nötig ja, durchgehend um das Device zu erstellen; nicht um es zu benutzen Zeilen an beweglichen Teilen ein Daemon, dreißig Jahre alt ein Dateideskriptor PPP gibt dir einen ausgehandelten, selbstüberwachenden Link und berechnet dafür ein Protokoll. Ein Tap-Device gibt dir ein rohes Loch für nichts, und du lieferst die fehlenden Teile oder kommst ohne aus. Für einen Tunnel, der läuft, ist die fehlende Lebendprüfung die, die beißt: pppd bemerkt einen toten Träger in dreißig Sekunden und baut ihn neu auf, der Tap-Bau bemerkt nichts, weil nichts darin zusah. Füg ein Keepalive hinzu, lass es unter etwas laufen, das es neu startet, oder nimm den Bau, der schon eines hat.\nWann Das Das Richtige Werkzeug Ist Und Wann Nicht Es ist nie wirklich das richtige Werkzeug, und ich tue nicht so, als wäre es das. Alles oben funktioniert, und nichts davon ist, was du in Produktion fahren solltest. Die ehrliche Version einer Anleitung enthält den Teil, wo du das Werkzeug weglegst, und das ist dieser Teil.\nWofür es wirklich gut ist, ist dir zu zeigen, wie eine Sache funktioniert. Ein VPN in seine Teile zerlegt und, im nächsten Abschnitt, wie sich Egress tatsächlich verhält, sobald jemand mit Root in deinem Netzwerk ist. Das sind die Gründe, das gelesen zu haben. Die engen Fälle unten sind echt, aber sie sind nicht, warum der Beitrag existiert.\nGreif zum PPP-Bau, wenn:\nDer Träger überhaupt nicht IP ist — eine serielle Konsole, ein USB-Gadget, eine Funkstrecke, eine benannte Pipe, ein SSH-Kanal. pppd ist es egal, worüber die Bytes reisen, und ein Tap-Device kann dir hier nicht helfen. Du etwas rettest: eine Maschine mit einer seriellen Konsole, ohne Netzwerk, und eine Aufgabe, die heute Abend fertig werden muss. PPP über diese Konsole ist ein gerouteter Link, an beiden Enden installiert, ohne dass etwas hinüberkopiert werden muss. Du willst, dass der Link auf sich selbst aufpasst. LCP-Echo, Adressaushandlung und Neustart sind gratis; sie selbst zu schreiben ist der Weg, wie der Tap-Bau zu einem kleinen unzuverlässigen Produkt wird. Greif zum Tap-Bau, wenn:\nDu Schicht 2 brauchst — ein Nicht-IP-Protokoll, ein Cluster-Heartbeat, der Broadcasts will, DHCP über den Tunnel, oder zwei Segmente, die eines sein müssen. Du die wenigsten beweglichen Teile willst: Über UDP mit DTLS sind es zwei Befehle, kein Daemon, keine Aushandlung, nichts zu escapen. Root knapp ist. Erstell das Device einmal mit user, und der Prozess, der Frames bewegt, braucht nie wieder Privilegien. Beide sind das richtige Werkzeug, wenn du lernst. Jede Schicht ist sichtbar und einzeln austauschbar, und es gibt keinen besseren Weg zu verstehen, was ein VPN-Produkt tut, als eines aus den Teilen zu bauen und jedem beim Hochkommen zuzusehen.\nKeines ist das richtige Werkzeug, wenn du ein VPN willst. Dafür nimm WireGuard. Es ist im Kernel, ein Bruchteil des Codes, es macht die Krypto ordentlich, ohne etwas auszuhandeln und ohne etwas, das man falsch machen kann, und es ist von Grund auf ein Datagramm-Protokoll. ssh -w gibt dir ein tun-Device über eine bestehende SSH-Sitzung in einem Befehl, und OpenVPN ist die reife, auditierte Version der DTLS-über-tap-Form oben. Alle drei sind darin besser als alles hier Gebaute.\nBau das, weil du wissen willst, was in der Kiste steckt, die du kaufst. Nicht, weil es clever war.\nWas Das Wirklich Zeigt: Egress Von Der Angreiferseite Das ist der Grund, einen Bau-Beitrag zu lesen, den man dir gerade zu meiden gesagt hat. Dreh ihn um und sieh von innerhalb deines eigenen Netzwerks, als der, der gerade mit Root dort gelandet ist. Jeder echte Einbruch endet dort, durch einen gestohlenen Schlüssel, einen Container-Ausbruch, einen ungepatchten Dienst, einen Insider. Die Frage, die dann entscheidet, wie schlimm der Tag wird, ist nicht „was können sie ausführen“, denn sie können alles ausführen. Es ist „was kann raus, und hattest du das entschieden, bevor sie ankamen.“\nWenn ausgehend standardmäßig offen ist, ist die Antwort: alles, und du kannst nun wenig tun. Nichts hier war exotisch. pppd, ncat, socat und ip sind signierte Distributionspakete, schon auf der Kiste; der Tap-Shim ist fünfzig Zeilen Standardbibliothek. Ein erlaubter ausgehender Port — und es ist 443, der eine, den jedes Netzwerk standardmäßig öffnet — und es gibt einen gerouteten Link von deinem Netzwerk zu dem eines anderen, verschlüsselt, authentifiziert, Neustarts überlebend, IPv4 und IPv6 tragend, und an deiner Grenze nicht zu unterscheiden von jeder HTTPS-Sitzung, die deine Nutzer zehntausendmal am Tag machen. Mach es tap und bridge es, und was das Gebäude verließ, ist keine Route. Es ist das Segment.\nEs gibt nichts, das ein Scanner erwischen könnte: keine Malware-Signatur, weil es keine Malware gibt, kein seltsames Protokoll, weil es ein normaler TLS-Handshake auf 443 ist, keine ungewöhnliche Binary, weil dein eigener Paketmanager jede installierte. Der Proxy protokolliert eine Verbindung und einen Byte-Zähler, und beide sehen aus wie Arbeit.\nUnd das Ziel steht nicht einmal fest. Ein Socket muss nicht dort enden, wo die Pakete landen, weil der Träger durch einen Proxy gelenkt werden kann — ein Relay, das nichts weiter ist als zwei Verbindungen und eine Pipe, was der nächste Abschnitt in einer Zeile Shell baut. ncat nimmt --proxy mit --proxy-type http, socks4 oder socks5, sodass die TLS-Sitzung, die deine Grenze sieht, an dem endet, wozu der Angreifer ihr sagte, sich zu verbinden durch — ein interner Sprunghost, ein erlaubter SaaS-Endpunkt, der zufällig CONNECT weiterleitet, ein Cloud-Relay — und der Tunnel reitet von dort weiter zu einem Ort, den du nie siehst. HTTP CONNECT und SOCKS tun das beide von Entwurf her, denn dafür ist ein Proxy da. Ein Allow-List-Eintrag für ein Ziel, dem du traust, ist also immer nur Vertrauen in das Ziel und in alles, wohin es weiterleitet, was du nicht kontrollierst und nicht aufzählen kannst. Der Endpunkt in deinem Firewall-Log ist der Proxy. Er war nie das ferne Ende.\nAlso die unbequeme Wahrheit: Sobald jemand mit Root drin ist und ausgehend freizügig ist, ist der Tunnel nicht das, was du verhindern kannst. Die Teile sind installiert, der Ausgang ist offen, und er führt nicht einmal dorthin, wo er hinzuführen scheint. Deine eine Chance, das schwer zu machen, war bevor der Angreifer ankam, an der Grenze, indem du entschiedest, was raus darf.\nDas ist Default-Deny-Egress, und es ist die ganze Lektion. Ausgehend standardmäßig blockiert; eine kurze, benannte Allow-List, wo ein Mensch jedes Ziel und jeden Port begründet hat; alles andere abgelehnt, protokolliert und alarmiert. Nicht, weil es einen entschlossenen Angreifer kalt stoppt — ein erlaubtes Ziel ist ein erlaubter Tunnel — sondern weil die Alternative ist, überhaupt keine Entscheidung zu haben, die man durchsetzt. Eine Egress-Policy, geschrieben als Liste erlaubter Ports, ist eine Policy über Portnummern. Sie war nie eine Policy darüber, was rausgeht, und sobald jemand Root hat, sind Portnummern alles, was sie schützt.\nDas ist dasselbe Ergebnis wie der Ping-Beitrag, der den Tunnel aus ICMP-Echo baut, und der Protokoll-Helfer-Beitrag, wo deine Firewall die Löcher selbst öffnet. Drei Wege hinein, eine Schlussfolgerung: Die Kontrolle, die du zu haben glaubtest, war über Protokolle, und nicht eines dieser Protokolle ist, was es vorgibt. Die Grenze, im Voraus entschieden und Default-Deny, ist die einzige Kontrolle, die je real war.\nEin Proxy Sind Zwei Verbindungen Und Eine Pipe Es lohnt sich zu sehen, wie wenig ein Relay ist, denn es erklärt, warum du vom nahen Ende nicht auf das ferne schließen kannst. Ein Proxy ist keine besondere Software. Es ist eine Verbindung, mit einer anderen durch eine Pipe verbunden. Die älteste Form benutzt eine benannte Pipe, eine FIFO, um die Rückrichtung zu tragen: Ein ncat lauscht, ein anderes verbindet weiter, und die FIFO verdrahtet den Antwortpfad zwischen ihnen.\nmkfifo backpipe ncat -l 7000 0\u0026lt;backpipe | ncat farend.example.net 7100 1\u0026gt;backpipe Lies es als Klempnerei: Die Ausgabe des Listeners läuft in das zweite ncat und weiter zum fernen Ende, und die Antworten kommen durch die FIFO zurück zum Client. Zwei Sockets, eine Pipe, beide Richtungen, und die Verbindung des Clients endet hier, am Relay, während die Pakete zu farend und zurück weiterreisen. Ich habe genau das auf Loopback mit einem dritten ncat laufen lassen, das am fernen Ende zurückwarf, und eine hineingeschickte Zeile kam zurück, nachdem sie die ganze Reise gemacht hatte.\nEin Relay sind zwei Sockets, verbunden durch eine Pipe — und der Endpunkt wandert Eine Verbindung rein, eine raus, eine Pipe dazwischen. Das ist ein Proxy. Client öffnet eine TLS-Sitzung RELAY — das Ziel, das deine Grenze protokolliert ncat -l 7000 beendet den Client ncat farend beginnt einen neuen Hop fernes Ende die echte Gegenseite stdout backpipe (FIFO) trägt die Antworten zurück Client → Relay Relay → fernes Ende Die Verbindung des Clients endet am Relay. Die Pakete nicht. Deine Firewall hat eine Verbindung zu dieser Maschine protokolliert. Wohin sie weiterleitet, wird in der Maschine entschieden, und drei davon verkettet legen das echte ferne Ende drei Pipes weit weg — jedes Hop-Log zeigt nur eine saubere lokale Verbindung zum nächsten, und nichts dahinter. Ein Relay sind zwei Sockets und eine Pipe. Der Listener beendet die Verbindung des Clients. Ein zweites netcat startet eine frische Verbindung weiter, und die FIFO trägt die Rückrichtung zwischen ihnen. Die TLS-Sitzung des Clients endet hier, am Relay, und ein neuer Sprung beginnt — sodass das Ziel, das deine Grenze protokollierte, diese Kiste ist, und die Pakete weiterreisen, wohin auch immer sie weiterleitet. Kette drei und das ferne Ende ist drei Pipes entfernt, wobei die Firewall jedes Sprungs nur eine saubere lokale Verbindung zur nächsten sieht. Ncat macht dasselbe in einem Prozess, indem es die Weiterverbindung für jeden ankommenden Client exect:\nncat -l 7000 --keep-open --sh-exec \u0026#39;ncat farend.example.net 7100\u0026#39; Dieselbe Form, weniger Teile: Der Socket des Listeners ist mit dem des exec\u0026rsquo;ten ncat durch die Pipe verbunden, die die Shell dazwischensetzt. Kette drei und der Tunnel kreuzt drei Netzwerke, endet und startet an jedem neu, wobei die Firewall jedes Sprungs eine saubere lokale Verbindung zur nächsten protokolliert und nichts darüber hinaus.\nDas ist der ganze Trick, und deshalb ist das Grenz-Log kein Beweis für ein Ziel. Jedes Relay ist das ferne Ende, soweit die Kiste davor es erkennen kann, und das echte andere Ende ist so viele Pipes entfernt, wie niemand zusah.\nSetz nun diese Relays auf Maschinen, die nicht dem Angreifer gehören.\nVerkettete Relays über kompromittierte Hosts waschen den Endpunkt Jeder Hop ist die Maschine eines anderen, und jeder Eigentümer sieht nur Mitte Angreifer seine einzige Maschine Relay 1 Netz einer anderen Firma Relay 2 ein gekaperter VPS Relay 3 ein Heimrouter Ziel wohin es ging sieht: 1←→2 sieht: 2←→3 sieht: 3←→Ziel Kein Hop sieht über seine eigenen zwei Nachbarn hinaus. Kein Ursprung, kein Ziel, nur Mitte. Der Verkehr wird durch eine Reihe fremder Systeme gewaschen, jedes fährt dasselbe Zwei-Sockets-und-eine-Pipe-Relay unter der Kontrolle des Angreifers. Deshalb führt der Ausgang eines kompromittierten Hosts so oft zum nächsten Opfer, nicht zum Angreifer — zwanzig Jahre C2. Jeder Sprung ist ein kompromittierter Host — die Kiste einer anderen Firma, ein gekaperter VPS, ein Heimrouter — der dasselbe Zwei-Sockets-und-eine-Pipe-Relay unter der Steuerung des Angreifers fährt. Kein Sprung kann über seine eigenen zwei Nachbarn hinaussehen: Der Besitzer von Relay 2 sieht eine Verbindung von Relay 1 und eine zu Relay 3, und sonst nichts. Der Verkehr wird durch eine Kette fremder Systeme gewaschen, weshalb das Ausgehende eines kompromittierten Hosts so oft zu einem weiteren Opfer führt statt zum Angreifer. Jeder Besitzer entlang dieser Kette sieht nur eine Verbindung vom Sprung davor zum Sprung danach: kein Ursprung, kein Ziel, nur Mitte. Das ist keine neue Idee, die ich jemandem in die Hand gebe. So haben Pivot-Ketten und C2-Netze seit zwanzig Jahren funktioniert, und warum das Ausgehende eines kompromittierten Hosts so oft zu einem weiteren Opfer führt statt zum Angreifer. Deine Logs zeigen, dass du mit einer Kiste in irgendeinem Rechenzentrum gesprochen hast. Wessen, und wohin sie weiterleitet, stand nie darin.\nDas defensive Gewicht ist eine Zeile: Du kannst einem Ziel, das du nicht im Voraus eingeschränkt hast, weder zuschreiben noch trauen. Wenn der Verkehr geht, sagt dir die Adresse, zu der er geht, fast nichts, denn es ist ein Relay auf der Maschine eines anderen, und der echte Endpunkt ist dahinter gewaschen.\nDer Link War Nie Das Produkt Was mir auffällt, nachdem ich das auseinandergenommen habe, ist, wie wenig davon neu ist und wie viel davon verkauft wird.\nRFC 1661 ist von 1994. pppd ist seit dreißig Jahren in jeder Linux-Distribution, die Kernel-Module sind acht Dateien in einem Verzeichnis, und das Ganze, was ein VPN zu einem VPN macht — eine virtuelle Schnittstelle, ein ausgehandelter Link, ein verschlüsselter Träger, eine Route — sind vier Programme und ein Zertifikat. Nichts davon ist schwer oder geheim. Sie haben jedes Byte dokumentiert und es verschenkt, und eine Industrie wuchs zwischen dir und ihm, die dieselben vier Teile in einer Kiste mit einer Lizenz pro Platz und einem Supportvertrag verkauft, der abläuft. Die Teile wurden nicht besser. Sie wurden eingewickelt.\nDas ist kein Argument, das in Produktion zu fahren. Ich habe dir gerade gesagt, es nicht zu tun. Es ist ein Argument zu wissen, was in der Kiste steckt, die du kaufst, denn an dem Tag, an dem der Hersteller die Lizenzierung ändert, aufgekauft wird oder dein Modell beendet, ist der Unterschied zwischen einem schlechten Quartal und einem schlechten Jahr, ob irgendwer bei dir weiß, woraus das Ding gemacht war.\nNimm dir einen Abend und bau den Tunnel aus den Teilen. Sieh LCP aushandeln, brich den Link und sieh ihn zurückkommen, zieh das Zertifikat und sieh, was aufhört zu funktionieren. Dann lies das Datenblatt deines VPN-Herstellers noch mal, und sieh, wie viel davon du wiedererkennst.\nDerselbe Abend kauft die andere Hälfte. Wenn ein gerouteter Link aus deinem Netzwerk vier installierte Programme und ein Zertifikat ist, wird der, der gerade auf einer deiner Kisten Root bekam, nicht davon aufgehalten, wie schwer der Tunnel zu bauen ist. Er ist nicht schwer. Sie werden nur davon aufgehalten, was du entschieden hast, bevor sie ankamen, dass es raus durfte. Bau es einmal und du hörst auf, Egress als etwas zu denken, das ein Produkt durchsetzt, und fängst an, es als eine Entscheidung zu denken, die du entweder getroffen hast oder nicht.\nNicht viel davon ist Magie. Das meiste davon ist 1994 mit einem Anstrich, und an 1994 ist nichts falsch. Es funktionierte, es war dokumentiert, und es läuft noch.\nRFC 1661 — The Point-to-Point Protocol (PPP), 1994. Definiert den Link, LCP und die Familie der Netzwerk-Kontrollprotokolle, die darauf sitzen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 2637 — Point-to-Point Tunneling Protocol (PPTP), das PPP in GRE trägt.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 3931 — Layer Two Tunneling Protocol version 3, der Standards-Track-Nachfahre des Protokolls, das PPP in UDP trägt.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\npppd(8) — die Manpage des PPP-Daemons. Quelle für pty, notty, local, passive, noipdefault, proxyarp, record, receive-all, die LCP-Echo-Optionen und den asyncmap-Default: „If no asyncmap option is given, the default is zero, so pppd will ask the peer not to escape any control characters.“ Die Zitate hier wurden aus man pppd auf ppp 2.5.1 gelesen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 1662 — PPP in HDLC-like Framing. Die Flag-Sequenz, die Octet-Stuffing-Regel und die Async-Control-Character-Map: „Each frame begins and ends with a Flag Sequence, which is the binary sequence 01111110 (hexadecimal 0x7e).“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nOlaf Titz, Why TCP Over TCP Is A Bad Idea — die Standarderklärung des Neuübertragungs-Stapelns, die genau mit diesem Bau eröffnet. Die ursprüngliche URL liefert den Artikel nicht mehr; das ist eine Momentaufnahme des Internet Archive.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 5072 — IP Version 6 over PPP. IPV6CP und die 64-Bit-Interface-Identifier, unabhängig von IPCP.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 1994 — PPP Challenge Handshake Authentication Protocol (CHAP). Beweist die Identität des Peers; verschlüsselt nichts.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 3079 — Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE). Die RC4-Konstruktion, geschlüsselt aus dem MS-CHAP-Austausch, und der Grund, warum PPTP keine lebende Option ist.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNcat Users\u0026rsquo; Guide — connecting through a proxy — --proxy und --proxy-type für HTTP CONNECT und SOCKS 4/5, sodass der TLS-Träger am Proxy endet, nicht am fernen Ende des Tunnels.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNcat Users\u0026rsquo; Guide — die Optionen --ssl, --ssl-verify und --ssl-trustfile sowie die Listen- und UDP-Modi. Hier getestete Version: Ncat 7.92.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nUniversal TUN/TAP device driver — die eigene Dokumentation des Kernels für /dev/net/tun, TUNSETIFF und den Unterschied zwischen tun und tap.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nPEP 784 — Adding Zstandard to the standard library, weshalb compression.zstd unter Python 3.14 kein Paket braucht. Hier gegen Python 3.14.7 und zstd 1.5.7 gemessen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 7457 — Summarizing Known Attacks on TLS and DTLS, das CRIME und die allgemeine Form eines Kompression-vor-Verschlüsselung-Längenlecks abdeckt.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nOpenVPN — the VORACLE attack — dasselbe Leck gegen ein VPN, das vor dem Verschlüsseln komprimiert, und der Grund, warum OpenVPN jetzt von Kompression abrät.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://blogs.damiendye.uk/de/networking/a-vpn-out-of-parts-and-what-egress-really-is/","summary":"Ein VPN sind zwei Aufgaben: etwas, das einen virtuellen Link macht, und etwas, das die Bytes trägt. PPP erledigt die erste seit 1994 und ist es egal, was die zweite ist — deshalb sind PPTP, L2TP und jede Wählleitung, die du je benutzt hast, dasselbe Protokoll über verschiedene Träger. Netcat ist ein Träger. Dieser Beitrag baut es auf beide Arten. Zuerst pppd: die pty-Option und was sie mit einem Pseudo-Terminal macht, die TCP-Variante, die jeder zuerst probiert, warum ein Stream-Protokoll in TCP unter Verlust zusammenbricht, die UDP-Variante, die man nehmen sollte, das asynchrone HDLC-Framing und die ACCM, die entscheidet, wie viel Bandbreite auf das Escapen von Steuerzeichen geht, Adressierung und Routing und IPV6CP, und den Link am Leben halten, wenn der Träger stirbt, ohne es zu sagen. Dann derselbe Tunnel ganz ohne PPP — ein Tap-Device, ein Datagramm pro Frame über UDP, das Längenpräfix, das man über TCP selbst erfinden muss, tun gegen tap, und Bridging. Dann der Teil, für den Netcat keine Antwort hat: den Träger in TLS wickeln mit ncat, stunnel und openssl, und in DTLS mit socat, was die Form ist, die man eigentlich will. Es ist nie wirklich das richtige Werkzeug, und das ist der Punkt: Es zeigt, wie sich Egress verhält, sobald ein Angreifer in deinem Netzwerk Root hat und der ausgehende Zugang nicht standardmäßig blockiert war, und warum Default-Deny an der Grenze die einzige Kontrolle ist, die je real war.","title":"Ein VPN aus Einzelteilen: PPP, Tap-Devices und Netcat"},{"content":"Auf deiner Firewall gibt es eine Funktion, die in deine Pakete hineinliest, dort eine IP-Adresse und eine Portnummer im Text findet und ein eingehendes Loch dafür öffnet. Keine Regel. Kein Change Request. Kein Logeintrag, den du je anschauen würdest. Auf den meisten Geräten, die sie haben, ist sie standardmäßig an, das ist seit gut fünfundzwanzig Jahren so, und die Branche, die sie dort hingebaut hat, ist in den letzten zwanzig davon still zu dem Schluss gekommen, dass sie abgeschaltet gehört — in Standarddokumenten, in Kernel-Defaults und in vier getrennten Runden von Notfall-Patches für Browser.\nSie heißt Protokoll-Helper, oder Application Level Gateway, ALG, Session-Helper, Fixup, Inspection Engine, conntrack-Helper. Dasselbe Ding. Es gibt sie, weil NAT eine Handvoll Protokolle kaputt gemacht hat, die Adressen in ihre eigene Nutzlast schreiben, und weil jemand entschieden hat, die am wenigsten schlechte Lösung sei, dem Übersetzer beizubringen, diese Nutzlast im Vorbeigehen zu lesen und umzuschreiben.\nHier kommt der Teil, der dich stutzig machen sollte.\nDer Helper kann nicht erkennen, wer den Text geschrieben hat. Er liest Bytes von einer Verbindung und handelt danach, sofort, ohne irgendwen oder irgendwas zu fragen. Er hat keine Möglichkeit zu wissen, ob die Zeichenkette PORT 192,168,1,29,4,0 von einem echten FTP-Client bei einer echten Übertragung stammt oder von einem versteckten Formular auf einer Webseite, die dein Nutzer aus Versehen geöffnet hat. Beides sieht auf der Leitung identisch aus, weil es auf der Leitung identisch ist. Ein Fremder im Internet, der irgendetwas in deinem Netz dazu bringt, die richtigen Bytes zu senden — einen Browser, einen Chat-Client, alles, was schickt, was man ihm sagt — darf sich also aussuchen, welchen eingehenden Port deine Firewall öffnet und wohin.\nDas ist kein Bug im Parser eines Herstellers. Das ist, was die Funktion tut. Die Bugreports und die CVEs sind das interessante Detail obendrauf; die Form darunter ist, dass ein Sicherheitsgerät Konfigurationsanweisungen aus nicht vertrauenswürdigen Daten entgegennimmt und sie sofort umsetzt.\nSamy Kamkar hat die Browser-Variante im Januar 2010 vorgeführt1, eine deutlich bessere im Oktober 20202, und drei Monate später hat Armis sie so erweitert, dass der geöffnete Port nicht einmal auf dem Rechner liegen muss, der geklickt hat — er kann auf deinem Drucker sein, deiner Kamera oder einer speicherprogrammierbaren Steuerung zwei VLANs weiter3. Dazwischen hat die IETF festgehalten, dass diese Dinger standardmäßig aus sein sollten4, Linux hat sie im Kernel abgeschaltet5, und die Browser-Hersteller haben eine Liste gesperrter Ports ausgeliefert, die sich fast Zeile für Zeile liest wie ein Verzeichnis der Linux-conntrack-Module6. Jede einzelne dieser Korrekturen wurde woanders angebracht, weil das, was tatsächlich repariert gehört, in einer Kiste sitzt, die niemand patchen wird.\nIch bin zu dem Schluss gekommen, dass Protokoll-Helper überall standardmäßig aus gehören und in jedem Netz, für das du verantwortlich bist, tatsächlich aus sein sollten. Nicht getunt. Nicht als erste Maßnahme auf vertrauenswürdige Subnetze eingeschränkt. Aus, mit den zwei oder drei echten Ausnahmen aufgeschrieben und datiert, genau so, wie du jede andere eingehende Regel dokumentieren würdest — denn genau das sind sie.\nWas folgt, ist der Mechanismus, dann die Angriffe in der Reihenfolge ihrer Entdeckung, dann die Compliance-Lage, denn im Vereinigten Königreich ist das nicht bloß unklug, sondern ein glattes Versagen einer Zertifizierungsanforderung, die du womöglich schon hältst, und schließlich die Befehle, um es in Ordnung zu bringen.\nWas ein Fremder davon hat Fang beim Ergebnis an, denn der Mechanismus interessiert einen leichter, wenn man die Rechnung gesehen hat. Jemand öffnet einen Link. Das ist sein ganzer Beitrag. Die Seite führt JavaScript aus, das mit dem Server des Angreifers spricht, und dieser Server formt das Gespräch — füllt es auf, misst es aus, bestätigt Teile davon und andere nicht — bis ein Segment bei deiner Firewall ankommt, das exakt aussieht wie die Eröffnungsnachricht eines VoIP-Anrufs. Deine Firewall glaubt es, denn das Glauben ist die Funktion. Sie legt ein eingehendes Mapping an, und der Angreifer verbindet sich direkt hindurch zurück.\nIn der Fassung von 2020 öffnet sich der Port auf dem Rechner, der geklickt hat, also jeder Dienst, der auf diesem Host lauscht, erreichbar aus dem Internet, solange das Mapping lebt2. Dateifreigabe. Der Remote-Desktop, den niemand lauschen lassen wollte. Zum Fisher-Price OS (Windows) hat Armis das Naheliegende angemerkt: Erreiche den Port der Dateifreigabe, und du bist einen ungepatchten Host von dem Weg entfernt, den WannaCry genommen hat3.\nDie Fassung von 2021 ist schlimmer, und das ist der Teil, der es für dich entscheiden sollte. Weil der H.323-Helper Rufumleitung beherrscht, kann eine einzige Nachricht eine dritte Adresse benennen statt eines der beiden Enden der Verbindung. Der Angreifer ist damit nicht mehr auf den Rechner beschränkt, der geklickt hat, sondern kann deinen internen Adressbereich durchgehen, auf jeder Adresse einen Port öffnen und zurücklesen, was antwortet. Armis hat genau das vorgeführt: Port 80 über einen ganzen Bereich, Banner eingesammelt, ein Ziel ausgesucht, dann den Rohdruck-Port des Druckers geöffnet und einen Druckauftrag geschickt. Ihre zweite Vorführung erreichte eine Steuerung über deren unauthentifizierten Management-Port und änderte ihr Programm3.\nAuf keinem dieser Geräte wurde eine Schwachstelle ausgenutzt. Der Drucker war ein funktionierender Drucker, die Kamera eine funktionierende Kamera, die Steuerung eine funktionierende Steuerung, und das Einzige, was versagt hat, war die Grenze — und die hat versagt, indem sie genau das tat, wozu sie konfiguriert war. Überleg auch, wer sich innerhalb dieser Grenze befindet. Nicht nur deine Belegschaft: ein Besucher im Gästenetz, das Notebook eines Dienstleisters, jeder mit einem Browser. Der Angriff braucht keine Zugangsdaten, keinen Fuß in der Tür und keine Schadsoftware, denn der Browser ist das Transportmittel, und der ist bereits installiert und bereits vertrauenswürdig.\nHalte das jetzt gegen das, wofür eine Firewall da ist: sicherzustellen, dass von außen niemand ein Gespräch mit irgendetwas drinnen anfängt, außer du hast es erlaubt. Der Helper ist die Ausnahme, und die Ausnahme wird auf Basis einer Zeichenkette in einem Paket gewährt.\nWas ein Protokoll-Helper tatsächlich ist Ein reines NAT ist ein dummes, ehrliches Ding. Ein Paket kommt an, es schreibt Quelladresse und Port im Header um, notiert eine Zeile, damit die Antwort wieder zurückgedreht werden kann, und leitet weiter. Es schaut nie unter den Transport-Header, und es weiß nicht und kümmert sich nicht darum, ob die Bytes darin eine Webanfrage, eine Datenbankabfrage oder das Foto eines Hundes sind.\nDas funktioniert, bis ein Protokoll eine Adresse in seine eigene Nutzlast schreibt. FTP tut das, im Klartext im Kommandostrom: verbinde dich zurück zu mir, an diese Adresse, auf diesen Port. SIP tut es in den Feldern Via, Contact und SDP, H.323 tut es, und IRC tut es für Direktübertragungen. Alle wurden entworfen, als die Adresse eines Hosts die Adresse dieses Hosts war und jede Maschine jede andere erreichen konnte, und unter dieser Annahme ist es eine völlig vernünftige Sache. Stell einen Übersetzer in den Pfad, und die Adresse in der Nutzlast wird zur Lüge.\nEin einfacher Übersetzer liest den Header. Ein Helper liest die Nutzlast und öffnet danach ein Loch. Dieselbe Stelle im Pfad. Einer von beiden liest neben dem Umschlag auch den Brief. Ein einfacher Übersetzer Ein Protokoll-Helper Das ankommende Paket [IP-Hdr 192.168.1.29:51000] [ Nutzlast ] Das ankommende Paket [IP-Hdr 192.168.1.29:51000] [ PORT 192,168,1,29,4,0 ] Was es tut Schreibt Quelladresse und Quellport im Header um Korrigiert die Prüfsummen Legt eine Zeile an, damit die Antwort zurückgeht Leitet es weiter Was es tut Alles davon, und dann liest die Nutzlast und findet darin Adresse und Port schreibt auch die um und verschiebt die Sequenznummern schreibt eine zweite Zeile: diese Verbindung erlauben Tabellen, die es führt Nur die Übersetzungstabelle. Eine Zeile, ein Fluss, umkehrbar. Nichts in der Nutzlast kann eine Zeile anlegen. Tabellen, die es führt Übersetzungstabelle und eine Expectation-Tabelle. Eine Zeile in der zweiten ist eine eingehende Firewallregel. Die zweite Tabelle ist das ganze Thema. Sie sagt: Kommt von außen eine Verbindung, die zu diesem Muster passt, lass sie durch. Niemand hat sie geschrieben oder genehmigt. Zwei Geräte an derselben Stelle im Pfad. Der reine Übersetzer schreibt den Header um und leitet das Paket weiter, ohne die Nutzlast je zu lesen. Der Helper liest die Nutzlast, schreibt die Adresse darin um und fügt einer zweiten Tabelle eine Zeile hinzu, die später eine eingehende Verbindung erlaubt. Diese zweite Tabelle ist das Thema dieses Beitrags. Also wurde der Helper erfunden. Er liest die Nutzlast, findet die Adresse, schreibt sie auf die öffentliche um und tut dann das, worüber alle hinweglesen: Er legt eine Regel an, die genau die eingehende Verbindung erlaubt, die die Nutzlast eben beschrieben hat. Netfilter nennt diese Regel Expectation. Cisco nennt sie Pinhole oder NAT-Tür7. Palo Alto nennt sie dynamisches NAT-Pinhole8. Juniper nennt sie Gate. Anderes Wort, identisches Objekt: ein Loch in der Grenze, geschlagen auf Basis von etwas, das aus einem Paket gelesen wurde.\nDie IETF hat das Muster benannt, bevor die meisten dieser Produkte existierten. Ein ALG, sagt RFC 2663, ist ein „application specific translation agent“, der „may interact with NAT to set up state, use NAT state information, modify application specific payload and perform whatever else is necessary to get the application running across disparate address realms“9. Lies das noch einmal mit einem Angreifer im Kopf: whatever else is necessary, gesteuert von application specific payload. Und im Februar 2002 nannte die Middlebox-Taxonomie der IETF den Mechanismus schon beim Namen und merkte an, dass manche ALGs Fragmentierungsprobleme erzeugen, „although in this case the problem is arguably the result of a deliberate layer violation (e.g., mucking with the application data stream of an FTP control connection by twiddling TCP segments on the fly)“10.\nEin absichtlicher Schichtbruch. An TCP-Segmenten im Flug herumfummeln. Das ist der Mechanismus, beschrieben von den Leuten, die ihn vor vierundzwanzig Jahren katalogisiert haben, und es ist derselbe Mechanismus, durch den jeder Angriff in diesem Beitrag geradewegs hindurchmarschiert.\nDie Expectation ist das ganze Problem Alles Weitere in diesem Beitrag folgt aus einem einzigen Objekt, also lohnt es sich, das richtig zu verstehen.\nEine Expectation ist eine vorab genehmigte Verbindung: ein Tupel aus Quelladresse, Quellport, Zieladresse, Zielport und Protokoll, einige Felder gefüllt, andere als Platzhalter offen gelassen, dazu ein Timer. Kommt ein passendes Paket an, behandelt die Firewall es als verwandt mit einem bestehenden erlaubten Fluss statt als neue eingehende Verbindung, lässt es durch und verbraucht die Expectation. Unter Linux liest du sie direkt aus /proc/net/nf_conntrack_expect oder mit conntrack -L expect. Auf einem gesunden System ist diese Liste leer, und genau das ist der Punkt — Expectations sollen selten sein, kurzlebig und von etwas ausgelöst, das ein Host von innen wirklich angefordert hat.\nEine Expectation ist eine eingehende Regel mit Lücken, und die Lücken sind das Sicherheitsmodell Ein Objekt, fünf Felder, ein Timer. Welche Felder leer sind, ist das ganze Sicherheitsmodell. expect proto=tcp src=\u0026lt;wer verbinden darf\u0026gt; sport=\u0026lt;beliebig\u0026gt; dst=\u0026lt;wohin\u0026gt; dport=\u0026lt;welcher Port\u0026gt; timeout=300 Helper Wer verbinden darf Wohin es zeigt Welcher Port Schlimmster Fall FTP der Server, festgelegt der Client, festgelegt aus der Nutzlast jeder Port auf einem Host IRC jede beliebige Adresse der Client, festgelegt aus der Nutzlast jeder Port, von jedem H.323 jede beliebige Adresse aus der Nutzlast aus der Nutzlast jeder Port auf jedem Host Blau: von der Firewall aus der sichtbaren Verbindung gesetzt.\u0026#160;\u0026#160;Gold: aus der Nutzlast.\u0026#160;\u0026#160;Pink: offen gelassen, mit Absicht. 1. Welche Felder sind Platzhalter? Eine offene Quelle heißt, das Loch ist nicht für das ferne Ende des Gesprächs reserviert, das es erzeugt hat. Wer zuerst an deine Außenschnittstelle kommt, nimmt es. Der IRC-Helper muss das tun, weil das Protokoll wirklich nicht wissen kann, wer verbindet – eine gute Beschreibung eines Protokolls, dem man nicht helfen sollte. 2. Wer hat die Werte geliefert? Nicht die Firewall. Die Nutzlast, und die hat das Ende des Gesprächs geschrieben, das der Helper gerade las. In diesem Satz kommt nirgends eine Authentisierung vor. 3. Worauf kann das Loch zeigen? Bei den meisten Helpern auf den Host, der es erzeugt hat. Bei H.323 auf alles, was die Nutzlast sagt, wegen der Umleitung. Eine Expectation ist eine Firewall-Regel mit ein paar leer gelassenen Feldern und einem Timer darauf. Drei Fragen entscheiden, ob sie sicher ist, und es sind die richtigen drei Fragen für jeden Helper auf jeder Plattform. Zwei dieser Antworten sind schlechter, als man erwartet. Die Werte kommen aus der Nutzlast statt von der Firewall, also von demjenigen Ende des Gesprächs, das der Helper gerade gelesen hat. Und beim IRC-Helper ist die Quelladresse konstruktionsbedingt ein Platzhalter, weil das Protokoll nicht wissen kann, wer sich verbinden wird: er „creates expectations whose destination address is the client address and source address is any address“11.\nHier ist der Satz zum Mitnehmen. Eine Expectation ist eine eingehende Firewall-Regel, angelegt in Leitungsgeschwindigkeit, von einer nicht vertrauenswürdigen Partei, ohne jeden Nachweis, wer sie angefordert hat oder warum. Behalte ihn bis zum Abschnitt über Cyber Essentials, denn dort ist er das ganze Argument.\nWie vorgesehen: FTP sagt PORT, und die Firewall glaubt es Nimm den einfachsten Helper und sieh ihm beim korrekten Arbeiten zu, denn der Angriff ist dieselbe Abfolge mit einem ausgetauschten Beteiligten. Aktives FTP benutzt zwei Verbindungen. Der Client öffnet eine Steuerverbindung zum Server auf Port 21 und gibt ihm Befehle in reinem ASCII, und wenn eine Übertragung ansteht, öffnet er einen lauschenden Socket und schickt ein PORT-Kommando, das Adresse und Port für den Rückruf nennt, woraufhin der Server sich eingehend verbindet. Das ist das Protokoll wie spezifiziert, und so läuft es seit 1985. Auf der Leitung sind es sechs Zahlen, vier für die Adresse und zwei für den Port, höherwertiges Byte zuerst:\nPORT 192,168,1,29,4,0 Das ist 192.168.1.29, Port 1024, denn 4 × 256 + 0 = 1024.\nAktives FTP durch einen Helper: vier Schritte, alle korrekt, und nur zwei Dinge je geprüft Aktives FTP genau nach Spezifikation, und was geprüft wurde, bevor das Loch aufging FTP-Client 192.168.1.29 Firewall + Helper 203.0.113.10 FTP-Server 198.51.100.7 1\u0026#160;\u0026#160;Steuerverbindung ausgehend zu Port 21 \u0026#8212; erlaubt, sie begann innen 2\u0026#160;\u0026#160;der Client lauscht und schreibt seine eigene Adresse in den Strom PORT 192,168,1,29,4,0 3\u0026#160;\u0026#160;der Helper handelt schreibt die Adresse um, legt die Expectation an PORT 203,0,113,10,4,0 expect src=198.51.100.7 dst=192.168.1.29 dport=1024 4\u0026#160;\u0026#160;der Server verbindet eingehend, die Expectation passt, die Daten fließen Sieh dir an, was die Firewall prüfte, bevor Schritt vier möglich wurde. Dass die Bytes auf einer Verbindung zu Port 21 lagen. Dass sie mit den vier Zeichen PORT begannen. Das ist alles, denn mehr gibt es nicht zu prüfen. FTP führt keine Signatur, keinen Sitzungsschlüssel und sonst nichts Prüfbares. Aktives FTP durch einen Helper, das genau das tut, wofür es entworfen wurde, in jedem Schritt korrekt. Achte darauf, was die Firewall geprüft hat, bevor sie das Loch öffnete: dass die Bytes auf Port 21 lagen und mit PORT begannen. Sonst nichts, weil es sonst nichts zu prüfen gibt. Der Helper beobachtet diesen Strom, erkennt PORT, schreibt die Adresse von der privaten auf die öffentliche um und passt dabei die Sequenznummern an, weil die Zeichenkette ihre Länge geändert hat, und legt eine Expectation an, die die eingehende Verbindung des Servers auf dem genannten Port erlaubt. Wirklich nützlich, unter den Zwängen von 1994 völlig vernünftig und in jedem Schritt korrekt.\nSieh genau hin, was geprüft wurde, bevor sich das Loch öffnete. Die Bytes lagen auf einer Verbindung zu Port 21. Sie begannen mit PORT. Das war es. Sonst nichts, weil es sonst nichts zu prüfen gibt — FTP hat keine Signatur anzubieten, keinen Sitzungsschlüssel und keinerlei Authentifizierung, und der Helper liest einen Strom, an dem er nicht beteiligt ist.\nNoch eine Sache steckt in diesem Code, und sie ist eine Warnung, die sich die Autoren selbst hineingeschrieben haben. Ist die Adresse im PORT-Kommando nicht die eigene des Clients — bittet der Client den Server also, sich ganz woanders hin zu verbinden — verweigert der Linux-Helper das standardmäßig, und der Kommentar im Quelltext sagt warum: „DMZ machines opening holes to internal networks, or the packet filter itself“12. Setz den Modulparameter loose, und diese Verweigerung ist weg. Die Leute, die den Helper geschrieben haben, wussten genau, wozu man ihn bringen kann. Sie lieferten den sicheren Standard und einen Schalter aus, und fünfundzwanzig Jahre später ist der Schalter immer noch da.\nNicht wie vorgesehen: dieselben Bytes, von einer Webseite Ein Helper liest einen Bytestrom und gleicht ein Muster ab. Er prüft nicht — und kann konstruktionsbedingt nicht prüfen — ob das Ding am anderen Ende der Client ist, für den es sich ausgibt. Samy Kamkar hat die Konsequenz im Januar 2010 veröffentlicht und sie NAT Pinning genannt1. Der Trick ist peinlich klein: Leg ein Formular auf eine Webseite, richte es auf den Server des Angreifers auf Port 6667, und ordne den Rumpf so an, dass er eine Direktchat-Anfrage enthält.\nPRIVMSG samy :^ADCC CHAT samy 3325256705 22^A Der Browser schickt es ab, in der Annahme, ein HTTP-POST zu machen. Der IRC-Helper des Routers, der eine Verbindung auf Port 6667 beobachtet, sieht DCC CHAT mit einer Adresse und einem Port vorbeiziehen und tut, wozu er gebaut ist. Die Adresse dort ist 198.51.100.1, geschrieben als eine einzelne Dezimalzahl, denn so kodiert das Protokoll sie, und der Port ist 22; nichts in dieser Zeichenkette hat das Opfer gewählt. Die FTP-Variante ist dieselbe Idee auf Port 21, mit einer Antwortzeile im Passiv-Modus statt dessen1.\nKein Cross-Site-Scripting. Keine Request Forgery im üblichen Sinn. Keine Schwachstelle im Browser. Der Browser tat, was Browser tun, die Firewall tat, wozu sie konfiguriert war, und das Ergebnis ist eine Portweiterleitung zum Angreifer.\nZwei Spalten, die der Helper nicht unterscheiden kann, weil es auf der Leitung nichts zu unterscheiden gibt Das Protokoll wie vorgesehen, und eine Webseite. Der Helper sieht ein Bild. Ein echter Client Ein verstecktes Formular Was es auslöst Jemand öffnet einen FTP- oder IRC-Client und verbindet Der Client öffnet einen Socket und nennt ihn im Strom PORT 192,168,1,29,4,0 Was es auslöst Jemand öffnet eine Seite. Das ist sein ganzer Beitrag. Ein Formular sendet an den Angreiferserver, gleicher Port PORT 192,168,1,29,4,0 Was der Helper prüft Zielport passt\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;ja Schlüsselwort am Datenanfang\u0026#160;\u0026#160;\u0026#160;ja Syntax lesbar\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;ja Adresse und Port da\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;ja Was der Helper prüft Zielport passt\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;ja Schlüsselwort am Datenanfang\u0026#160;\u0026#160;\u0026#160;ja Syntax lesbar\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;ja Adresse und Port da\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;ja ein eingehender Port geht auf, identisch, in beiden Spalten Unterschiedlich sind die drei Dinge, die der Helper nicht sieht. Ob ein Client beteiligt war. Ob die Person es wollte. Wer Adresse und Port wählte. Nichts davon hinterlässt eine Spur auf der Leitung, kein noch so sorgfältiger Parser holt es zurück. Beide Spalten sind tadellos geformt. Derselbe Helper, derselbe Musterabgleich, dieselbe Expectation — und nirgends im Bild ein FTP- oder IRC-Client. Jede Prüfung, die der Helper durchführt, ist in beiden Spalten identisch erfüllt, denn auf der Leitung gibt es keinen Unterschied zu finden. Das war 2010. Vor sechzehn Jahren. Die Browser-Hersteller haben die IRC-Ports auf ihre Sperrliste gesetzt, was genau diese Tür schloss und den Raum dahinter ließ, wie er war.\nSag den Punkt deutlich, denn er geht zwischen Herstellernamen und CVE-Nummern verloren. Die Angriffe nutzen keinen Fehler in den Helpern aus. Sie benutzen die Helper korrekt. Jedes Paket ist wohlgeformt, und jede Prüfung besteht ehrlich. Die Funktion tut ihren Job, und ihr Job ist das Problem.\nDie Bytes dorthin schieben, wo der Helper liest Zwischen NAT Pinning und etwas sehr viel Schlimmerem lag ein echtes Hindernis, und der Weg darum herum ist das Cleverste am ganzen Thema. Die meisten Helper gleichen ein Muster nicht irgendwo im Strom ab: Sie prüfen, dass das Schlüsselwort am Anfang des Datenteils eines Pakets steht, was bei einer echten Protokollnachricht so ist und bei einem HTTP-Rumpf nie, weil ein Rumpf nach einem Stapel Header ankommt, den der Angreifer nicht kontrolliert. Samy zitiert das Verhalten des Kernels selbst — der Handler bricht ab, wenn die Methode nicht am Anfang der Daten steht2.\nDer Angreifer braucht also einen Browser, der ein TCP-Segment ausgibt, dessen allererstes Byte das Schlüsselwort ist. Die Header kann er nicht schreiben, aber den Rumpf schon, und den so lang machen, wie er will — womit das Problem zur Rechenaufgabe wird.\nDie Segmentgrenze verschieben, bis das Schlüsselwort dort liegt, wo der Helper liest Der Helper liest das erste Byte eines Segments. Also verschiebt der Angreifer die Bruchstellen. So würde der Browser es senden Segment 1 POST / HTTP/1.1 Host: ... Segment 2 ...Header... PORT 192,168,... Segment 3 ...1,29,4,0 Füllung Füllung Das Schlüsselwort steht mitten in Segment zwei, also liest der Helper darüber hinweg und tut nichts. Nachdem der Angreifer die Segmentgröße setzt oder nur einen Teil des Stroms bestätigt Segment 1 POST / HTTP/1.1 Host: ... Segment 2 ...Header und Füllung... Segment 3 PORT 192,168,1,29,4,0 Das Schlüsselwort ist nun das erste Byte eines Segments. Der Helper liest es und öffnet den Port. Die beiden Hebel, und keiner ist ein Angriff auf TCP. Der Server des Angreifers ist ein Ende der Verbindung, also kündigt er die maximale Segmentgröße an, die der Stack des Opfers nutzt, und entscheidet, wie viel vom Strom er bestätigt. Bestätigt er nur einen Teil, sendet das Opfer ab dem gewählten Versatz erneut. Beides ist ganz normales, standardkonformes TCP, mit voller Absicht eingesetzt. Warum die Füllbytes wichtig sind. Der Helper liest ein Protokoll-Schlüsselwort nur, wenn es das erste Byte eines Segments ist, also muss ein Angreifer, der nur den Rumpf einer Anfrage kontrolliert, die Segmentgrenze so lange verschieben, bis sie dort landet. Beide Hebel sind ganz gewöhnliches TCP, absichtlich eingesetzt. Der Browser schickt eine große Anfrage mit einem erkennbaren Trennzeichen im Rumpf; der Server des Angreifers schnüffelt sie mit, misst, wie viele Header-Bytes davor kamen, und kennt damit den Offset. Dann kündigt er entweder eine Segmentgröße an, die das gewünschte Byte auf eine Grenze legt, oder er bestätigt den Strom nur teilweise, sodass das Opfer genau ab dort erneut sendet — und Armis ergänzt, dass sich auch das TCP-Fenster in diesen Bestätigungen präparieren lässt, „in order to fully control how the TCP stream is to be segmented“3. Das ist der ganze Trick, und er benutzt nichts weiter als das ferne Ende einer Verbindung, die der Browser des Opfers selbst geöffnet hat.\nHat man das, ist der Browser ein Allzweck-Paketgenerator, der auf das Innere deiner Firewall zeigt. Kein perfekter, denn er kann keine beliebigen Header setzen und keine beliebigen Protokolle wählen, aber das musste er nie sein. Er muss nur die richtigen dreißig Bytes an den Anfang eines Segments legen.\nDie Arbeit von 2021 hat sich die Rechnerei größtenteils gespart. Eine Browser-Relay-Verbindung über TCP trägt ein vom Angreifer kontrolliertes Benutzernamenfeld, früh gesendet, das Zeilenumbrüche und Nullbytes akzeptiert, solange das Ergebnis gültiger Text ist — Armis zeigte einen Mitschnitt, in dem dieses Feld die Zeichenkette \\r\\nPORT 192,168,1,29,4,0\\r\\n ist, mit einer Teilbestätigung, die das Opfer genau ab dem PORT erneut senden lässt3. Schlimmer noch: Dieser Weg fragte die Sperrliste des Browsers überhaupt nicht ab, womit die eine Gegenmaßnahme, die die Branche zweimal ausgeliefert hatte, schlicht umgangen war.\nNAT Slipstreaming, von Anfang bis Ende Setz die Teile zusammen, und das ist der ganze Angriff, der Reihe nach.\nVom Klick zur eingehenden Verbindung in sechs Schritten, keiner davon eine Schwachstelle Sechs Schritte. Vier sind normales Web und TCP. Einer ist deine Firewall. Einer ist der Angreifer. 1 Das Opfer öffnet eine Seite Eine Anzeige, ein Link in einer Nachricht, egal. Das ist der ganze Beitrag der Person. normales Web 2 Die Seite erfährt die Innenadresse Von der Medienschnittstelle des Browsers geliefert oder über Laufzeiten gängiger Gateways eingegrenzt. normales Web 3 Der Angreifer vermisst den Pfad Eine übergroße Anfrage mit Markierung und eine Aufzeichnung am fernen Ende, um die Bruchstellen zu sehen. normales TCP 4 Die Seite sendet die echte Nutzlast So aufgefüllt, dass das Schlüsselwort auf eine Segmentgrenze fällt, genau wie im vorigen Diagramm. normales TCP 5 Deine Firewall öffnet den Port Der Helper erkennt die Nachricht, schreibt die Adresse darin um und legt die Expectation an. deine Firewall 6 Der Angreifer verbindet eingehend Auf deine öffentliche Adresse, auf dem abgebildeten Port. Die Expectation passt, die Firewall leitet hinein. deine Firewall Zähl die auf der Maschine des Opfers ausgenutzten Schwachstellen. Es sind keine. Der Browser war gepatcht. Das Betriebssystem war gepatcht. Nichts wurde installiert, keine Zugangsdaten benutzt. Sekunden, ein Klick, und das einzige Bauteil, das hätte ablehnen können, war das dafür gebaute. Die vollständige Kette, vom Klick bis zur eingehenden Verbindung. Die Schritte eins bis vier sind ganz gewöhnliches Web- und TCP-Verhalten. Schritt fünf ist die Firewall-Funktion, die genau wie dokumentiert arbeitet. Die einzige Komponente, die hätte ablehnen können, ist die, deren ganzer Zweck das Ablehnen ist. Verstrichene Zeit insgesamt: Sekunden. Nutzerinteraktion insgesamt: ein Klick. Auf dem Rechner des Opfers ausgenutzte Schwachstellen insgesamt: keine.\nDer Ablauf der Offenlegung ist für sich genommen ein Beweisstück. Samy veröffentlichte am 31. Oktober 2020, Armis meldete sich drei Tage später, und die koordinierte Offenlegung bei den Browser-Herstellern begann am 11. November. Chrome lieferte am 6. Januar 2021 eine Gegenmaßnahme aus, Edge am Tag darauf, Safari am 14. als Beta und am 1. Februar stabil, Firefox am 26.3 — geführt als CVE-2020-16043, CVE-2021-23961 und CVE-2021-1799.\nVier Browser-Hersteller lieferten Notfall-Patches für eine Firewall-Funktion aus. Armis erklärt in eigenen Worten, warum: „While the underlying issue of this attack is the way NATs are implemented (in various ways in routers and firewalls, throughout numerous vendors and applications), the easiest and fastest way to mitigate was through a patch to browsers“3.\nDas ist keine Lösung. Das sind vier fremde Branchen, die Sandsäcke vor die Haustür von jemand anderem stapeln, weil die Tür selbst nie ersetzt werden würde.\nH.323-Rufumleitung zeigt auf alles in deinem Netz Die meisten Helper begrenzen den Schaden, ohne es zu wollen. Der FTP-Helper heftet das Ziel der Expectation an den Client, der sie erzeugt hat, sodass ein Angreifer schlimmstenfalls einen Port auf dem Rechner bekommt, der geklickt hat — schlimm, aber überlebbar.\nH.323 ist katastrophal, und der Grund ist eine Telefoniefunktion.\nEine Telefonanlage muss Rufumleitung beherrschen, und ein umgeleiteter Anruf ist per Definition ein Anruf bei jemandem, der nicht in der Leitung ist. Die Signalisierung muss also einen dritten Endpunkt benennen, und der Helper muss einen Pfad dorthin öffnen, sonst funktioniert Umleitung durch NAT überhaupt nicht. Jede ernsthafte Implementierung kann das, und der netfilter-Helper dokumentiert das Verhalten ausdrücklich, mit Diagramm, auf der netfilter-Seite13. Armis hat den Code gelesen und die Konsequenz in einem Satz festgehalten: „a single H.323 packet sent over TCP port 1720 that initiates call forwarding can open a pinhole (named an expectation in the conntrack subsystem) to any TCP port of any internal IP on the network“3.\nAuf einen Host festgenagelt oder auf alles im Netz gerichtet Die meisten Helper erreichen nur die Maschine, die klickte. Einer lässt sich gar nicht begrenzen. FTP, SIP, IRC H.323, mit Rufumleitung Die Expectation sagt dst = der Host, dessen Verbindung sie erzeugte Die Expectation sagt dst = welche Adresse die Nutzlast nannte die Maschine, die klickte 192.168.1.29 der Drucker Port 9100 die Kamera Standardpasswort die Steuerung keine Authentisierung Schadensradius Eine Maschine. Jeder Port darauf, solange die Regel lebt, was schlimm genug und überlebbar ist. Das Gerät wird verwaltet, gepatcht und führt etwas, das protokolliert. Schadensradius Jede Adresse im Netz, je eine Nachricht. Bereich abgehen, Banner lesen, Ziel wählen. Keines dieser Geräte stellte je eine Anfrage oder lief im Browser. Die Rufumleitung ist der ganze Unterschied, und sie ist eine Funktion, kein Fehler. Ein umgeleiteter Ruf gilt jemandem, der nicht dran ist, also nennt die Signalisierung einen Dritten und der Helper folgt. Warum ein Helper in einer anderen Kategorie spielt als der Rest. Heftest du die Expectation an den Host, der sie erzeugt hat, erreicht der Angreifer eine Maschine. Lässt du die Rufumleitung einen Dritten benennen, wie das Protokoll es verlangt, geht der Angreifer stattdessen deinen ganzen Adressbereich durch. Jeder TCP-Port. Jede interne Adresse. Aus einem Paket, das der Angreifer einen Browser hat senden lassen.\nDer Angriff geht damit nicht mehr um den Rechner des Opfers, sondern wird zu einem Portscan deines internen Netzes, durchgeführt aus dem Internet, mit Ergebnissen, die über Verbindungen zurückgelesen werden, die deine eigene Firewall genehmigt. Die Geräte, die er findet, sind der Punkt, denn sie sind nicht gepatcht, oft gar nicht patchbar, und das ganze Sicherheitsmodell der meisten lautet es steht ja drinnen. Armis hat diese Annahme mit einer Zahl versehen: Ein Jahr nach Veröffentlichung waren 97 % der für eine Serie kritischer Lücken anfälligen Industriesteuerungen noch ungepatcht3. Niemand behauptet, diese Zahl sei gut. Sie ist die Wirklichkeit, die „es steht ja drinnen“ trägt.\nAlso ist H.323 auf jeder Plattform das Erste, worum du dich kümmerst, weil es das Einzige ist, das über das Opfer hinausreicht — und weil es zugleich das ist, das fast niemand mehr benutzt, ist es die billigste Sicherheitsverbesserung in diesem Beitrag. Schalte es ab. Es wird dich niemand deswegen anrufen.\nDer Helper lässt sich von einer Nachricht auslösen, die du nie geschickt hast Eine Variante verdient einen eigenen Abschnitt, weil sie die Annahme kippt, nach der Leute greifen, wenn sie einen Grund zum Nichtstun suchen: Gut, aber der Auslöser muss ja von innen kommen, also kontrolliere die Browser und du kontrollierst das Problem.\nNein.\nIm Juli 2022 fand David Leadbeater zwei Fehler im Linux-IRC-Helper14. Das Modul sucht die Zeichenkette \\1DCC irgendwo im Strom, statt zu prüfen, ob sie an der richtigen Stelle in einer korrekt gerahmten Nachricht steht, und seine Adressprüfung vergleicht mit der Adresse des Chat-Servers statt mit der des Hosts hinter dem Übersetzer, sodass die öffentlich bekannte Adresse eines öffentlichen Servers genügt. Zusammen bedeutet das: Ein Angreifer schickt dem Client des Opfers einen Client-zu-Client-Ping — etwas völlig Normales, das man von jedem anderen Nutzer bekommt — mit einer Direktübertragungsanfrage darin:\nPRIVMSG ExampleUser :^APING ^ADCC CHAT x 3325256705 22^A Nach den Regeln des Protokolls beantwortet der Client einen Ping, indem er die Nutzlast zurückspiegelt, also schickt der Client des Opfers diese Zeichenkette pflichtschuldig nach außen, und der Helper, der den ausgehenden Strom beobachtet, findet DCC darin und öffnet den Port.\nEin Port, geöffnet durch eine Nachricht, die das Opfer nie verfasst hat Niemand drinnen hat geklickt. Der Client des Opfers sandte den Auslöser selbst, auf Anfrage. Der Client des Opfers 192.168.1.29 Firewall + IRC-Helper liest den Strom Ein Fremder jeder andere Nutzer, jedes Netz 1\u0026#160;\u0026#160;ein gewöhnlicher Ping, mit Direktchat-Anfrage in der Nutzlast versteckt PRIVMSG ExampleUser :^APING ^ADCC CHAT x 3325256705 22^A 2\u0026#160;\u0026#160;das Protokoll verlangt, den Ping durch Zurückspiegeln zu beantworten, also tut er es 3\u0026#160;\u0026#160;beide Prüfungen des Helpers bestehen, und keine hätte es dürfen er sucht das Schlüsselwort irgendwo im Strom, nicht am Anfang einer gerahmten Nachricht er prüft die Adresse gegen den Chatserver, nicht gegen den Host hinter dem Übersetzer 4\u0026#160;\u0026#160;die Expectation existiert, und Port 22 steht eingehend zum Opfer offen Alles in dieser Abfolge hielt sich an seine Spezifikation. Der Fremde sandte eine zulässige Nachricht. Der Client antwortete, wie das Protokoll es verlangt. Der Helper fand das Muster, für das er geschrieben wurde. Niemand entschied etwas, und kein Protokoll sieht im Mindesten auffällig aus. Der Auslöser muss nicht von jemandem kommen, dem du vertraust, nicht von einem Browser und nicht von etwas, das ein Nutzer absichtlich getan hat. Jedes Stück Software in diesem Bild hat seine Spezifikation exakt befolgt, und das Ergebnis ist ein offener Port und nichts Auffälliges in irgendeinem Log. Niemand drinnen hat etwas falsch gemacht, und niemand hat geklickt. Der Client folgte der Spezifikation, und Spezifikation und Helper zusammen erzeugten ein eingehendes Loch auf Port 22 zu einer Maschine im Netz. Daraus wurde CVE-2022-2663, und die Beschreibung in der nationalen Schwachstellendatenbank ist erfreulich klar: „A firewall may be able to be bypassed when users are using unencrypted IRC with nf_conntrack_irc configured“15.\nAchte auf das Wort unencrypted. Merk dir auch das.\nDie Empfehlung des Autors ist genau das, wo der Rest dieses Beitrags aus einer anderen Richtung ankommt: „Potentially entirely deprecate and remove nf_conntrack_irc, it\u0026rsquo;s unclear it has much use anymore“14.\nDie Parser sind die andere Hälfte Bisher ging es darum, dass Helper korrekt arbeiten. Es gibt ein zweites, davon getrenntes Problem: Sie sind Protokoll-Parser in C, die im schnellen Pfad eines Sicherheitsgeräts laufen, auf Daten, die Fremde liefern — mit der Fehlerquote, die man nach dieser Beschreibung erwarten würde. Und das ist kein Linux-Problem und kein Billigrouter-Problem, es taucht bei jedem Hersteller auf, im Code, für den sie am meisten verlangen.\nCVE Komponente Was ein präpariertes Paket bewirkt CVE-2018-0051 Junos SIP ALG Bringt den Flow-Daemon auf SRX und MX zum Absturz; hält außerdem fest, dass SIP ALG außer auf High-End-Modellen standardmäßig an ist CVE-2018-15454 Cisco ASA / FTD SIP-Inspection Startet das Gerät neu oder nagelt die CPU fest CVE-2022-2663 Linux nf_conntrack_irc Öffnet Ports durch die Firewall, wie oben CVE-2023-22412 Junos SIP ALG „Specific SIP messages“ bringen den Flow-Daemon reproduzierbar zum Absturz CVE-2023-22415 Junos H.323 ALG Schreibzugriff außerhalb der Grenzen durch „specific H.323 packets“ CVE-2024-21616 Junos SIP ALG Ein SIP-Paket erschöpft den NAT-Pool, echter Verkehr wird nicht mehr übersetzt CVE-2024-26851 Linux nf_conntrack_h323 Bitverschiebung außerhalb des gültigen Bereichs beim Dekodieren der H.323-Bitmap CVE-2024-39551 Junos H.323 ALG Speicher wird durch „specific packets“ erschöpft, bis der Verkehr steht Jede davon ist ohne Authentifizierung aus dem Netz erreichbar, von jedem, der ein Paket an die Außenschnittstelle bekommt, also von allen. Und lies die Formulierungen: specific SIP messages, specific H.323 packets, a specific SIP packet. Das ist kein Protokoll, das unter Last versagt. Das ist jemand, der absichtlich ein Paket baut.\nBleib einen Moment beim Cisco-Fall. CVE-2018-15454 wurde am 31. Oktober 2018 mit Schweregrad 8.6 veröffentlicht, wurde aktiv ausgenutzt, und das Advisory sagte, das Software-Update sei noch nicht verfügbar16. Ciscos Gegenmaßnahme lautet im eigenen Advisory no inspect sip. Die Antwort des Herstellers auf eine aktiv ausgenutzte Lücke in der Funktion war also, die Funktion abzuschalten — womit die Frage auf dem Tisch liegt, auf der der Rest dieses Beitrags aufbaut. Wenn Abschalten während eines Vorfalls eine akzeptable Antwort ist, mit welcher Begründung ist es die restliche Zeit an?\nEin Helper funktioniert nur, wenn du nicht verschlüsselst Das ist der Teil, der die Diskussion allein beenden sollte, und es ist der Teil, der am wenigsten Beachtung bekommt. Ein Protokoll-Helper liest deine Nutzlast und kann eine verschlüsselte nicht lesen. Ein Helper tut also überhaupt nur etwas auf Verkehr, den du im Klartext gelassen hast, und den Helper funktionsfähig zu halten heißt, diesen Verkehr im Klartext zu halten.\nJedes Protokoll auf dieser Liste hat seit weit über einem Jahrzehnt einen verschlüsselten Modus. FTP hat TLS seit 200517; schalte es ein, und die PORT- und PASV-Wechsel sind unsichtbar, der Helper tut nichts. SIP hat TLS seit der Basisspezifikation, samt verschlüsselter Medien. H.323 hat seinen eigenen Sicherheitsanhang. Chat hat seit sehr langer Zeit TLS, und die offizielle Empfehlung zu CVE-2022-2663 lautete mit genau diesen Worten, es zu benutzen, damit der Helper deine Übertragungsanfragen nicht sehen kann15.\nDer Helper braucht Klartext, also heißt den Helper behalten den Klartext behalten Du kannst die Verschlüsselung haben oder den Helper. Eine dritte Spalte gibt es nicht. Steuerkanal verschlüsselt Helper funktioniert Was der Helper sieht 17 03 03 01 a4 9c 2f e1 8b 44 d0 ... Chiffrat Kein Schlüsselwort. Keine Adresse. Kein Port. Nichts zum Abgleichen. Was der Helper sieht REGISTER sip:example ... Contact: 192.168.1.29:5060 Und jedes andere Gerät zwischen euch beiden auch. Was dich das kostet Der Helper tut gar nichts, also müssen die Endpunkte ihr Übersetzungsproblem selbst lösen \u0026#8212; was jedes dieser Protokolle seit einem Jahrzehnt beherrscht. Was dich das kostet Registrierungsdaten, wer wen anrief und jede interne Adresse, im Klartext, über jedes Netz zwischen den beiden Enden. Und keines davon kontrollierst du. So lange gibt es den verschlüsselten Modus schon FTP über TLS seit 2005\u0026#160;\u0026#160;\u0026#183;\u0026#160;\u0026#160;SIP über TLS mit verschlüsselten Medien\u0026#160;\u0026#160;\u0026#183;\u0026#160;\u0026#160;Chat über TLS seit Jahrzehnten\u0026#160;\u0026#160;\u0026#183;\u0026#160;\u0026#160;H.323 mit eigenem Sicherheitsanhang Die ehrliche Fassung von „wir brauchen den SIP-Helper“ ist ein Satz, den niemand laut ausspricht. Sie lautet: Unsere Gesprächssignalisierung muss im Klartext über fremde Netze, damit eine fremde Box sie umschreiben kann. Der Handel, den niemand aufschreibt. Ein Helper arbeitet nur an Nutzlast, die er lesen kann, also schließen sich die beiden Spalten gegenseitig aus. Die rechte ist das, wozu ein funktionierendes SIP ALG dich tatsächlich auffordert. Die ehrliche Fassung von „wir brauchen das SIP ALG“ lautet also: wir brauchen unsere Anrufsignalisierung im Klartext über nicht vertrauenswürdige Netze, damit eine Middlebox, die wir nicht kontrollieren, sie umschreiben kann. Sag es so in einem Design-Review und schau, wie weit du kommst.\nEs gibt eine schärfere Fassung, und deshalb ist das kein knapper Fall. Einen Helper aktiv zu lassen, ist ein dauerhafter Anreiz gegen Verschlüsselung: An dem Tag, an dem jemand SIP über TLS einschaltet, brechen die Gespräche, und der Helper ist der Grund, also wird die Änderung zurückgenommen und der Klartext bleibt noch ein Jahr. Frag jemanden, der das hinter einer Consumer-Firewall versucht hat, wie es gelaufen ist.\nJedes andere Protokoll im Internet ist den umgekehrten Weg gegangen: Webverkehr standardmäßig verschlüsselt, DNS verschlüsselt, Mailtransport verschlüsselt, QUIC verschlüsselt sogar den Transport-Header selbst, genau damit Middleboxen ihn weder lesen noch verändern können. Die Middlebox-Ära ist im offenen Internet vor Jahren zu Ende gegangen, und die letzten Stellen, die sich noch auf ein Gerät im Pfad verlassen, das die Nutzlast liest, sind die, an denen jemand einen Helper angelassen hat.\nIPsec ist der Fall, in dem der Helper gar nichts lesen kann Damit stellt sich die naheliegende Frage nach dem Protokoll, das nichts als Verschlüsselung ist. Die Antwort ist schlimmer, als du vermuten würdest.\nESP hat keine Portnummern, weil es ein eigenständiges IP-Protokoll ist und nicht etwas, das über UDP läuft, und ein Übersetzer demultiplext Rückverkehr über Ports. Bei zwei Clients hinter einer öffentlichen Adresse, die zum selben Gateway wollen, gibt es also nichts, woran man ihre eingehenden Pakete unterscheiden könnte. RFC 3715 hat das im März 2004 festgehalten: Ein NAT kann die Zuordnung nicht durch Hinsehen lernen, und „it is possible that the NAT will deliver the incoming IPsec packets to the wrong destination“18.\nAlso bauten die Hersteller einen Helper. Er beobachtet den IKE-Austausch auf UDP 500, dessen erste Pakete im Klartext liegen, sammelt die Cookies und den Security Parameter Index ein und öffnet ein Gate, damit eingehendes ESP mit diesem Wert beim richtigen Host drinnen ankommt. Juniper beschreibt es am klarsten: „When ESP traffic hits the IKE ALG gates, sessions are created to capture subsequent ESP traffic“19. Ciscos inspect ipsec-pass-thru macht dasselbe für ESP und AH „associated with an IKE UDP port 500 connection“, mit einer Vorgabe-Map, die überhaupt kein Limit für ESP-Verbindungen pro Client setzt20.\nDasselbe Objekt, dieselbe Autorität, nur passt der Helper hier nicht einmal ein Schlüsselwort ab. Er kann ESP nicht parsen, denn ESP ist der verschlüsselte Teil; er steuert Pakete anhand einer 32-Bit-Zahl, die er im Klartext vorbeiziehen sah. Der Abschnitt von RFC 3715, der das behandelt, heißt ohne jede Ironie „Helper Incompatibilities“ und hält fest, dass Cookie-Demultiplexing „results in problems with re-keying“ und dass Geräte, die ISAKMP-Payloads parsen, „may not handle all payload ordering combinations“18. Eine Vermutung anstelle einer Regel, und ein selbstgebauter Parser im Paketpfad, aufgeschrieben vor zweiundzwanzig Jahren.\nDie Lösung kam zehn Monate später, im Protokoll, wo sie hingehört: RFC 3947 lässt die beiden Enden während des Schlüsselaustauschs einen Übersetzer erkennen, und RFC 3948 verpackt ESP in UDP auf Port 4500, damit es wieder Ports gibt21. Juniper spricht es dann offen aus: „IKE NAT-T traffic on floating port 4500 is not processed in an IKE ALG“19. Macht man es richtig, wird der Helper komplett umgangen — derselbe Satz wie beim passiven FTP und bei ICE.\nDer Mainline-Linux-Kernel hat diesen hier nie übernommen. Unter den Conntrack-Protokollen gibt es kein ESP-Modul, und ein Patch von 2021, der SPI-basiertes Tracking hinzufügen sollte, durchlief das Review auf der Netfilter-Liste und wurde nie gemergt22. Die Hersteller, die ihn ausliefern, liefern ihn out of tree aus, auf den Geräten, die am wenigsten wahrscheinlich je aktualisiert werden.\nEs reißt Cyber Essentials, Zeile für Zeile Bis hierher war das ein Sicherheitsargument. Für jeden, der im Vereinigten Königreich zertifiziert, ist es auch ein Compliance-Argument, und dabei ist keinerlei kluge Auslegung im Spiel — es sind drei Stichpunkte gegen drei Stichpunkte. Cyber Essentials ist das von der britischen Regierung getragene Programm, umgesetzt über IASME, seine erste technische Anforderung sind Firewalls, und das aktuelle Anforderungsdokument ist Version 3.3 vom April 2026. Das hier verlangt es von dir, wörtlich23:\nblock unauthenticated inbound connections by default ensure inbound firewall rules are approved and documented by an authorised person, and include the business need in the documentation remove or disable unnecessary firewall rules, when they are no longer needed Jetzt stell einen Protokoll-Helper daneben.\nDrei Firewall-Anforderungen, und was ein Helper mit jeder davon macht Cyber Essentials, Maßnahme eins, Firewalls. Drei Pflichten, und die Antwort eines Helpers auf jede. Was das Anforderungsdokument sagt Was ein Protokoll-Helper tut Ergebnis \"block unauthenticated inbound connections by default\" Die erste Pflicht, und der Grund, warum es die Maßnahme gibt. Erlaubt eine, auf die Stärke einer Zeichen- kette in einem Paket hin. Wer die Kette lieferte, hat sich gegen gar nichts authentisiert. durchgefallen \"ensure inbound firewall rules are approved and documented by an authorised person, and include the business need\" In Leitungsgeschwindigkeit vom Kernelmodul geschrieben. Niemand genehmigte sie, niemand sah sie, kein Dokument, keine Notwendigkeit festgehalten. durchgefallen \"remove or disable unnecessary firewall rules, when they are no longer needed\" Was voraussetzt, dass jemand entschied, sie seien nötig. Von einem Timer entfernt. Ein Timer ist keine Prüfung, und niemand hat je beurteilt, ob die Regel überhaupt nötig war. durchgefallen Das ist die erste der fünf technischen Maßnahmen, kein Sonderfall in der fünften. Sie gilt, in den Worten des Programms, für Grenz-Firewalls, Desktop-Rechner, Laptops, Router und Server. Die drei Firewall-Anforderungen aus den technischen Kontrollen von Cyber Essentials und was ein Protokoll-Helper damit macht. Drei Anforderungen, drei Fehlschläge, bei der ersten von fünf Kontrollen. Eine Expectation existiert genau dazu, eine eingehende Verbindung zu erlauben, die sonst blockiert würde, und die Partei, deren Daten sie ausgelöst haben, hat sich gegenüber nichts authentifiziert — der erste Stichpunkt fällt also glatt durch. Die Regel wurde in Leitungsgeschwindigkeit von einem Kernelmodul geschrieben, es gibt also kein Dokument, keinen erfassten geschäftlichen Bedarf und keine autorisierte Person irgendwo in der Kette — frag einen Prüfer nach dem Genehmigungsnachweis für die Regel, die eine Verbindung an Port 9100 deines Druckers durchgelassen hat, und du hast keinen und kannst keinen anfertigen, weil sie vor achtzehn Monaten neunzig Sekunden lang bestand. Und die Regeln eines Helpers werden von einem Timer entfernt, und ein Timer ist keine Überprüfung.\nDrei Anforderungen, drei Fehlschläge, bei der ersten Kontrolle von fünf, die in den Worten des Programms für „boundary firewalls, desktop computers, laptops, routers, servers“23 gilt, also für alles, was du besitzt.\nSei fair damit, denn ich bin nicht die Zertifizierungsstelle. Ein Prüfer arbeitet mit dem Fragenkatalog und den Nachweisen, die du ihm gibst, und dieser Katalog fragt, ob du unauthentifizierte eingehende Verbindungen standardmäßig blockierst und ob deine eingehenden Regeln dokumentiert und genehmigt sind. Antworte mit Ja, während auf deiner Grenze ein Helper läuft, und die Antwort stimmt nicht. Bestehen wirst du wahrscheinlich trotzdem. Bestehen und Einhalten sind nicht dasselbe, und die Lücke dazwischen zeigt sich nach einem Vorfall statt davor.\nCyber Essentials ist mit dem, was es verlangt, auch nicht ungewöhnlich, nur ungewöhnlich klar formuliert. Ein Kartenbranchen-Standard, ein staatliches Prüfprogramm, der Fragebogen eines Kunden und das Antragsformular deines Versicherers fragen in anderer Sprache dasselbe: Weißt du, was deine Firewall eingehend erlaubt, und hat das jemand entschieden? Das ist also der Abschnitt für die Person, die das Zertifikat unterschreibt. Nicht die Angriffe und nicht die CVEs. Drei Stichpunkte und die ehrliche Antwort auf jeden.\nDie Branche hat das vor zwanzig Jahren entschieden Nichts davon ist neu, und nichts davon ist umstritten. Bemerkenswert ist, wie lange die Entscheidung schon steht, während die Standardeinstellungen unbeirrt weiterliefen.\nFünfundzwanzig Jahre desselben Befunds, und die eine Zeile, die nie auftaucht Die Schlussfolgerung stand 2007. Die Vorgaben bewegten sich nicht. Wann Was passierte Wer handeln konnte Jan. 2001 RFC 3027 katalogisiert jedes Protokoll, das NAT kaputtmacht, und was ein ALG dagegen tun muss Standardisierungsgremium Feb. 2002 RFC 3234 nennt den Mechanismus „a deliberate layer violation“ und warnt vor zusätzlichen Angriffspunkten Standardisierungsgremium Jan. 2007 RFC 4787, eine Best Current Practice: NAT-ALGs für UDP-Protokolle SOLLEN abgeschaltet werden Standardisierungsgremium Jan. 2010 NAT Pinning: Ein verstecktes Formular öffnet einen eingehenden Port auf der Maschine des Besuchers ein Forscher 2012 netfilter bekommt einen expliziten Anhänge-Mechanismus und einen Schalter gegen automatische Zuweisung der Kernel Apr. 2016 Linux ändert die Vorgabe: Helper tun ohne explizite Regel nichts. Ausgeliefert in 4.7 der Kernel Okt. 2020 NAT Slipstreaming, dann die Variante vom Januar 2021, die jedes Gerät im Netz erreicht Forscher Nov. 2020 Vier Browserhersteller liefern Gegenmaßnahmen; der Webplattform-Standard bekommt eine Portsperrliste die Browser Aug. 2022 Der IRC-Helper feuert auf eine Nachricht, die das Opfer nie verfasst hat ein Forscher 2023\u0026#8211;24 Vier weitere ALG-Schwachstellen in der Flaggschiff-Firewallreihe eines Herstellers Forscher Lies jetzt die Spalte „Wer handeln konnte“ und merke, wer nie darin steht. In fünfundzwanzig Jahren ist keine Zeile davon ein Firewallhersteller, der ein Update ausrollt, das die Funktion auf bereits ausgeliefertem Gerät abschaltet. Das Gremium bat darum, der Kernel tat es, und keiner erreichte die Boxen. Fünfundzwanzig Jahre derselbe Schluss, immer wieder gezogen von Leuten, die das, was repariert gehörte, nicht reparieren konnten. Die eine Zeile, die nie auftaucht, ist ein Firewall-Hersteller, der die Funktion auf bereits ausgeliefertem Gerät abschaltet. RFC 3027 hat im Januar 2001 jedes Protokoll katalogisiert, das NAT kaputt macht24. RFC 3234 hat ALGs ein Jahr später in die Middlebox-Taxonomie eingeordnet, den Mechanismus „a deliberate layer violation“ genannt und die Kosten zusätzlicher Kisten im Pfad klar benannt: das „creates extra points of attack, reduces or eliminates the ability to perform end to end encryption, and complicates trust models“10. Dann legte im Januar 2007 RFC 4787 — eine Best Current Practice, kein Vorschlag — fest, wie NAT sich zu verhalten hat, und Anforderung zehn sagte dies:\nREQ-10: To eliminate interference with UNSAF NAT traversal mechanisms and allow integrity protection of UDP communications, NAT ALGs for UDP-based protocols SHOULD be turned off.4\nAus. Vor neunzehn Jahren, mit Begründung: Helper stehen den Mechanismen im Weg, die tatsächlich funktionieren, und sie hindern dich daran, die Integrität deines eigenen Verkehrs zu schützen. Derselbe Abschnitt hält resigniert fest, dass manche Produkte ALGs „turned on permanently“ haben4.\nDrei Jahre später zeigte NAT Pinning eine Webseite, die einen Port öffnet1. Netfilter antwortete 2012 mit einem Mechanismus, das absichtlich statt automatisch zu tun — dem CT-Ziel, das einen Helper per ausdrücklicher Regel an einen benannten Fluss hängt, und einem Schalter, der die automatische Zuweisung ganz abstellt11. Dann änderte der Kernel am 25. April 2016 seinen Standard, in einer Commit-Nachricht, die man ganz lesen sollte, so müde klingt sie:\nFour years ago we introduced a new sysctl knob to disable automatic helper assignment [\u0026hellip;] This knob kept this behaviour enabled by default to remain conservative. This measure was introduced to provide a secure way to configure iptables and connection tracking helpers through explicit rules. Give the time we have waited for this, let\u0026rsquo;s turn off this by default now, worse case users still have a chance to recover the former behaviour by explicitly enabling this back through sysctl.5\nDas kam mit Linux 4.7, und seither tut eine Kiste mit geladenen Modulen nichts damit, bis du eine Regel schreibst, die einen an einen Fluss hängt — mit einer Logzeile, die es dir sagt. Alles danach steht im Diagramm oben: Slipstreaming und seine Variante für jedes Gerät, vier Browser-Hersteller mit Gegenmaßnahmen, während der Web-Plattform-Standard selbst die Portliste bekam25, der IRC-Helper, der auf eine Nachricht anspringt, die niemand verfasst hat, und vier weitere ALG-Lücken in der Flaggschiff-Firewall-Linie eines Herstellers.\nSchau jetzt auf die Liste und sieh, was fehlt. In fünfundzwanzig Jahren ist keine einzige Zeile davon ein Firewall-Hersteller, der ein Firmware-Update ausrollt, das diese Dinger auf bereits ausgeliefertem Gerät abschaltet. Das Standardisierungsgremium hat es verlangt. Der Kernel hat es upstream getan. Die Forscher haben es viermal getrennt bewiesen. Die Browser haben dafür bezahlt. Die Kisten liefen weiter.\nUnd die Sperrliste der Ports ist das Indiz. Die Ports 69, 137, 161, 554, 1719, 1720, 1723, 5060, 5061, 6566 und 10080 stehen alle darauf6 — TFTP, NetBIOS, SNMP, RTSP, H.323 zweimal, PPTP, SIP zweimal, das Scanner-Protokoll und das Amanda-Backup-Protokoll. Lass dir die Helper-Module in einem Linux-Kernelbaum auflisten, und du wirst merken, dass du dieselbe Liste zweimal gelesen hast. Kein Zufall, und keine Sicherheitsmaßnahme. Es ist eine Branche, die dauerhaft eine wachsende Sperrliste von Ports pflegt, weil eine andere Branche einen Standardwert nicht ändern will.\nUnter den meisten Abzeichen steckt Linux Das netfilter-Detail ist der wichtige Teil und kein Linux-förmiger Exkurs, und es lohnt sich, vor der Herstellerliste zu sagen, warum. Ein sehr großer Anteil der Kisten, die auf diesem Planeten NAT machen, ist Linux mit netfilter unter einer Herstelleroberfläche: jede OpenWrt-Ableitung, also der Großteil des Consumer- und Kleinunternehmens-Routermarkts, die meisten vom Provider gestellten Heimrouter, ein guter Teil der Carrier-Grade-NAT-Technik und reichlich kommerzielle Appliances, deren Weboberfläche nicht andeutet, was darunter liegt. Der Helper, der dein SIP parst, ist in sehr vielen Fällen dasselbe nf_conntrack_sip.c, das im Mainline-Kernel ausgeliefert wird, von jemand anderem übersetzt und über ein Menü gesteuert.\nDer Beleg steckt in der Forschung selbst. Als Samy in einem Netgear-Router nach dem SIP ALG suchte, extrahierte er die Firmware und fand ein Kernelmodul mit ftp_decode und sip_decode2. Die Testliste von Armis enthielt OpenWrt und VyOS sowie eine Kategorie, die sie schlicht „various consumer grade Linux routers, with likely older kernel versions“ nannten, und die H.323-Analyse, aus der der Befund „jeder interne Host“ stammt, entstand beim Lesen des netfilter-Quelltexts und wurde danach an kommerziellen Firewalls von drei Herstellern bestätigt3.\nDaraus folgen zwei praktische Konsequenzen.\nDer Kernel-Standard erreicht dich nicht. Linux 4.7 hat die automatische Helper-Zuweisung 2016 abgeschaltet, aber nur, wenn der Kernel neu genug ist und niemand sie wieder eingeschaltet hat. Armis fand VyOS, das nf_conntrack_helper ausdrücklich wieder auf 1 setzt, und hielt fest, dass reichlich Linux-basierte Produkte sie wieder aktivieren, „as it is still useful for many users“3. Ein Kernel von 2014 in einem Produkt von 2026 bekommt das Verhalten von 2014, und ein aktueller Kernel mit umgelegtem Schalter bekommt dasselbe. Keines von beidem steht auf einem Datenblatt.\nWer das netfilter-Modell kennt, weiß, was er jede andere Kiste fragen muss. Die drei Fragen aus dem Abschnitt über Expectations sind keine Linux-Fragen. Es sind die Fragen. Jeder Hersteller hat dasselbe Objekt unter anderem Namen, die Dokumentation liefert die Antworten fast nie, und zu wissen, was die Referenzimplementierung tut, ist der Weg herauszufinden, was du testen musst.\nMach die Linux-Arbeit ordentlich, und lies dann jeden anderen Hersteller dagegen.\nDie Linux-Helper, richtig gemacht Fang damit an, was tatsächlich geladen ist:\nlsmod | grep -E \u0026#39;nf_conntrack|nf_nat\u0026#39; Die Helper-Module sind die nach Protokollen benannten — nf_conntrack_ftp, _sip, _h323, _irc, _tftp, _pptp, _snmp, _amanda, _sane, _netbios_ns und _talk — jeweils mit einem passenden nf_nat_*, wo Adressen umgeschrieben werden. Dann prüfe, ob die automatische Zuweisung an ist, denn das ist der Schalter, der entscheidet, ob ein geladenes Modul von sich aus etwas tut:\nsysctl net.netfilter.nf_conntrack_helper Null ist, was du willst, und Null ist der Standard ab Linux 4.75. Eins heißt, dass jeder geladene Helper auf jedem Fluss aktiv ist, der zu seinem Port passt, von jeder Adresse — das Verhalten von 2015 und das Verhalten, das die Angriffe in diesem Beitrag voraussetzen.\nBeobachte dann conntrack -L expect auf einer laufenden Firewall. Mit abgeschalteten Helpern bleibt es leer; mit eingeschalteten stell einen Mitschnitt daneben und sieh zu, wie Zeilen auftauchen, während Leute das Netz benutzen. Diese Übung lohnt sich einmal im Leben, denn nichts macht den Punkt schneller, als eine eingehende Erlaubnis, die du nicht geschrieben hast, vor deinen Augen auftauchen und verschwinden zu sehen.\nIst die automatische Zuweisung aus und du willst trotzdem einen bestimmten Helper auf einem bestimmten Fluss, ist der vorgesehene Weg eine ausdrückliche Regel, die ihn wenigstens auf ein Ziel und einen Port begrenzt:\niptables -t raw -A PREROUTING -p tcp --dport 21 -d 192.0.2.10 -j CT --helper ftp Das nftables-Gegenstück deklariert ein ct helper-Objekt und hängt es in der Prerouting-Kette mit ct helper set an, dieselbe Disziplin mit besserer Syntax.\nUnd jetzt schau, was diese Regel ist: eine dokumentierte, genehmigte, geschäftlich begründete eingehende Ausnahme, von einem Menschen geschrieben, im Regelwerk, wo ein Prüfer sie lesen kann. Also genau das, was die automatische Variante nie sein konnte.\nWenn du sie ganz los sein willst statt nur schlafend — und auf einer Firewall solltest du das — verhindere das Laden der Module überhaupt:\nfor m in ftp sip h323 irc tftp pptp snmp amanda sane netbios_ns talk; do echo \u0026#34;install nf_conntrack_$m /bin/false\u0026#34; done \u0026gt; /etc/modprobe.d/no-conntrack-helpers.conf install ... /bin/false statt blacklist ist Absicht: blacklist verhindert nur das automatische Laden über Aliase, und wer das Modul beim Namen anfordert, bekommt es trotzdem. Und wenn die Firewall-Schicht deiner Distribution sie für dich lädt — firewalld tut das, wenn eine Zone den FTP- oder TFTP-Dienst aktiviert hat — dann ist das die Schicht, die du anfassen musst, denn sie legt sie hilfsbereit wieder hin.\nJedes andere Abzeichen und wie man es abschaltet Prüfe deine eigene Version, statt irgendetwas im Internet zu glauben, meins eingeschlossen, denn diese Standardwerte verschieben sich zwischen Releases und zwischen Modellen derselben Reihe.\npfSense und OPNsense sind der Beweis, dass die Diskussion vorbei ist. Es gibt kein SIP ALG zum Abschalten, weil es nie eines zum Einschalten gab. Sie gehören zu den am weitesten verbreiteten Firewall-Distributionen überhaupt, sie betreiben Telefonie für sehr viele Organisationen, und wäre ein Helper wirklich nötig, damit modernes VoIP funktioniert, wäre das nicht möglich. Es ist offensichtlich möglich. Dem FTP-Proxy erging es genauso: Netgate hat ihn im Januar 2015 aus dem Basissystem genommen und zu einem Zusatzpaket degradiert, das die meisten nie installiert haben.\nOpenBSDs Entwurf ist der, den alle anderen hätten kopieren sollen. pf schreibt im Weiterleitungspfad überhaupt keine Nutzlast um. Willst du FTP geholfen haben, startest du ftp-proxy, einen eigenen Userspace-Dienst, und schreibst eine ausdrückliche divert-to-Regel, die die Steuerverbindung dorthin schickt; der Proxy verbindet sich dann im Auftrag des Clients zum Server26. Daraus fallen sofort drei Eigenschaften: Er ist aus, außer du schaltest ihn absichtlich ein, er sieht nur Verkehr, den du in einer Regel benannt hast, und ein Fehler darin bringt einen Userspace-Prozess zum Absturz statt den Paketpfad. So sieht Opt-in aus, wenn jemand es entwirft statt nachträglich anzuflanschen.\nOpenWrt liefert die ALG-Module nicht mit, und die automatische Zuweisung bleibt aus, selbst wenn du sie nachinstallierst.\nCisco ASA und FTD tragen Inspection Engines in der Standard-Global-Policy, und no inspect sip ist Ciscos eigener Rat im Ernstfall:\npolicy-map global_policy class inspection_default no inspect sip no inspect h323 h225 no inspect h323 ras no inspect skinny Auf FTD lautet es configure inspection sip disable auf der Geräte-CLI16. IPsec-Pass-through ist das eine, das Cisco richtig gemacht hat: inspect ipsec-pass-thru steht gar nicht erst in der Standardrichtlinie, es gibt also nichts zu entfernen, sofern es niemand absichtlich hinzugefügt hat20.\nCisco IOS und IOS XE haben es ebenfalls standardmäßig an — „NAT support for SIP is enabled by default on port 5060“, in Ciscos eigenen Worten7, und dasselbe für H.323:\nno ip nat service sip tcp port 5060 no ip nat service sip udp port 5060 no ip nat service h225 Juniper SRX aktiviert SIP und H.323 auf den Branch-Modellen und nicht auf den High-End-Geräten, was für sich genommen schon verrät, was Junipers Entwickler davon halten. Finde mit show security alg status heraus, wo du stehst, dann:\nset security alg h323 disable set security alg sip disable set security alg ftp disable set security alg ike-esp-nat disable FortiGate inspiziert VoIP standardmäßig über das VoIP-Profil, mit einem Kernel-Session-Helper darunter. Fortinets dokumentierte Reihenfolge entfernt zuerst den Helper27:\nconfig system session-helper show delete \u0026lt;der SIP-Eintrag\u0026gt; end config system settings set default-voip-alg-mode kernel-helper-based end Lies die Eintragsnummer aus deiner eigenen show-Ausgabe, statt eine abzuschreiben, denn sie verschiebt sich zwischen Modellen und Releases. Fortinet weist darauf hin, dass oft ein Neustart nötig ist.\nCheck Point ist der unangenehme Fall für ein Audit, weil es keinen einzelnen Schalter gibt. Der Helper ist eine Eigenschaft des Service-Objekts in der Regel, der vordefinierte SIP-Dienst bringt dir also den Protokoll-Handler und alles, was er tut. Ihn zu vermeiden heißt, einen eigenen einfachen UDP- oder TCP-Dienst auf Port 5060 zu definieren, den Protokolltyp auf „none“ zu setzen, das Matching zu aktivieren und diese Regel über alles zu legen, was noch die eingebauten benutzt. „Ist das ALG an?“ ist also keine Frage, die eine Einstellungsseite beantworten kann. Sei daher vorsichtig, bevor du jemandes Wort akzeptierst, es sei abgeschaltet.\nPalo Alto gibt dir einen Schalter je Anwendung, und die eigene Dokumentation sagt, das SIP ALG „creates dynamic NAT pinholes“8. Objects, Applications, sip suchen, die ALG-Option anpassen, Disable ALG anhaken, committen.\nMikroTik liefert zehn Helper unter /ip firewall service-port aus — SIP, H.323, FTP, IRC, TFTP, PPTP, RTSP und mehr — jeweils in einer Zeile dokumentiert, ohne irgendeinen Sicherheitshinweis auf der Seite. Erst auflisten, dann abschalten, was du findest:\n/ip firewall service-port print /ip firewall service-port set [find name=sip] disabled=yes /ip firewall service-port set [find name=h323] disabled=yes /ip firewall service-port set [find name=ftp] disabled=yes Consumer- und Provider-Router. Such nach „SIP ALG“, „SIP Helper“, „VoIP Passthrough“ oder „Application Layer Gateway“, meist unter einer Seite für erweitertes NAT. Bei vielen, besonders bei Providergeräten, gibt es gar keine Einstellung — was dir sagt, ob diese Kiste in ein Netz gehört, für das du verantwortlich bist.\nEgal auf welcher Plattform, beende es gleich: Beweise es. Setz einen Mitschnitt auf die Außenschnittstelle, schick von außen eine präparierte PORT- oder REGISTER-Zeile an den passenden Port und stelle sicher, dass sich nichts öffnet. Eine Einstellung, die du nicht getestet hast, ist ein Glaube.\nDas meiste, was kaputtgeht, ist ohnehin tot Ehrlich über die Kosten zu sein, ist die ganze Grundlage dafür, das von jemandem zu verlangen, also hier sind sie. Den SIP-Helper in einem Netz mit schlecht konfigurierten Telefonen abzuschalten, kann Gespräche zerschießen, meist einseitiges Audio oder abreißende Registrierungen. Den FTP-Helper abzuschalten, zerschießt aktives FTP nach außen. Den H.323-Helper abzuschalten, zerschießt H.323, falls du noch welches hast. Das ist real, und du solltest mit mindestens einem davon rechnen, wenn du das in einem einzigen Change auf einem Netz machst, das seit Jahren niemand angeschaut hat.\nLies dir jetzt die Liste noch einmal durch und merke, dass fast jedes Protokoll, dem ein Helper dient, eines ist, das der Rest der Branche längst begraben hat. H.323 hat vor zwanzig Jahren gegen SIP verloren. PPTP ist seit 1998 nicht mehr zu verteidigen, und diesen Fall habe ich in IPsec war eine gute Idee ausführlich gemacht. IRC-Direktübertragungen gehören in ein Jahrzehnt, dem niemand nachtrauert. NetBIOS-Namensdienst, die Community-String-Versionen von SNMP, das Scanner-Erkennungsprotokoll und das alte Backup-Protokoll sind Relikte für lokale Netze, die nie eine Grenze überschreiten sollten. Reines FTP ist aus den Browsern ganz verschwunden — Firefox hat es in Version 88 deaktiviert und in 90 im Juli 2021 entfernt, Chrome hat den Code im Oktober darauf in Version 95 gelöscht, beide mit der Begründung, die Nutzung sei vernachlässigbar und die Sicherheit den Pflegeaufwand nicht wert28.\n„Wir können den Helper nicht abschalten, sonst geht etwas kaputt“ ist also meist ein Argument dafür, ein totes Protokoll am Leben zu erhalten, um eine Funktion zu rechtfertigen, die Fremden Ports öffnet. Abschalten macht dein Netz nicht kaputt. Es legt das eine Ding darin offen, das vor Jahren hätte ausgemustert gehört — eine Information, die du ohnehin haben wolltest.\nSIP ist die echte Ausnahme, und es ist die einzige. Alles andere auf dieser Liste ist ein Argument, das zu verlieren du froh sein solltest — und nichts davon ist unlösbar, denn jedes beteiligte Protokoll hat sein Übersetzungsproblem vor Jahren selbst gelöst, im Protokoll, wo es hingehört.\nWas du stattdessen tun solltest Die Middlebox-Antwort und die Endpunkt-Antwort, nebeneinander Dasselbe Problem, zweimal beantwortet. Eine Antwort legte die Entscheidung in die Mitte. Eine Box im Pfad entscheidet Die beiden Enden entscheiden Wie es funktioniert Ein Gerät liest die Nutzlast im Vorbeigehen Es schreibt die dort gefundene Adresse um Es öffnet ein Loch für die beschriebene Verbindung Niemand an beiden Enden weiß davon Wie es funktioniert Jedes Ende fragt einen Server, wie es von außen aussieht Jedes bietet jeden Pfad: lokal, übersetzt, über Relay Die beiden Enden testen die Pfade gegeneinander Sie halten den funktionierenden mit eigenem Verkehr offen Was es von dir braucht Lesbare Nutzlast, also keine Verschlüsselung auf dem Steuerkanal. Genau dieses Gerät in genau diesem Pfad. Nur einen Übersetzer, ein Carrier-Grade-NAT dahinter bricht es. Und Vertrauen in den Verfasser des Textes, woran bis 2010 niemand gedacht hat. Was es von dir braucht Ausgehenden Zugang, sonst gar nichts. Es funktioniert durch Übersetzer, die dir nicht gehören und die du nicht siehst, durch zwei gestapelte, durch ein Mobilfunknetz, und mit Ende-zu-Ende verschlüsseltem Steuerkanal, weil nichts in der Mitte ihn liest. Beim Dateitransfer ist es noch einfacher: passiver Modus, der Client öffnet beide Verbindungen nach außen, und für einen Helper bleibt nichts. Die rechte Spalte ist kein Vorschlag. Sie ist das, was dein Browser längst tut. Jeder Videoanruf im Browser wird so ausgehandelt, durch jede Art von Übersetzer, ohne ALG im Pfad. Dasselbe Problem, zweimal gelöst. Die eine Antwort legte die Entscheidung in eine Kiste in der Mitte. Die andere ließ die beiden Enden es unter sich ausmachen, und genau das tut jeder Browser der Welt bereits bei jedem Videoanruf. FTP. Passiv-Modus, seit 1985 in der Spezifikation und seit zwanzig Jahren Standard in jedem Client: Beide Verbindungen gehen nach außen, und für einen Helper bleibt nichts zu tun. Und wenn du 2026 Dateien zwischen Organisationen bewegst, ist FTP nicht das Protokoll dafür — SFTP und FTPS sind verschlüsselt, und ein Helper kommt an keines von beiden heran.\nSIP und alles andere in Echtzeit. Der Endpunkt fragt einen Server im Internet, wie seine öffentliche Adresse und sein Port von außen aussehen, bietet jeden Pfad an, den er hat, und die beiden Enden testen die Pfade gegeneinander und behalten einen, der funktioniert — mit einem Relay, wo kein direkter Pfad existiert. Das ist STUN, TURN und ICE, und genau das tut jeder Browser der Welt bei jedem Videoanruf, durch jede Art von Übersetzer, ohne ein einziges ALG im Pfad. Wenn deine Telefonanlage das 2026 nicht kann, liegt das Problem bei der Telefonanlage.\nIPsec. NAT-Traversal, also RFC 3947 und RFC 3948: Die beiden Enden bemerken den Übersetzer während des Schlüsselaustauschs und verpacken ESP für den Rest der Sitzung in UDP 450021, ohne Gate auf irgendeiner Box dazwischen.\nH.323. Ausmustern. SIP hat diese Diskussion um 2005 gewonnen, es gibt also keine Migration zu planen, nur ein Löschen. Direktübertragungen, TFTP, SNMP, NetBIOS, Scanner-Erkennung und das Backup-Protokoll gehen denselben Weg: Keines davon hat an einer Grenze etwas verloren.\nIPv6. Dort existiert nichts davon, denn es gibt keine Übersetzung und damit nichts, was ein Helper umschreiben könnte. Ein Host hat seine eigene Adresse, die Adresse in der Nutzlast stimmt, und eine zustandsbehaftete Firewall erlaubt, was du ihr gesagt hast, und sonst nichts. Jedes Problem in diesem Beitrag stammt von Adressübersetzung ab, und Adressübersetzung stammt davon ab, IPv6 nicht ausgerollt zu haben — ein Argument, das ich an anderer Stelle ausführlich gemacht habe und hier nicht wiederhole.\nJetzt der Teil, bei dem ich nicht diplomatisch sein werde.\nWenn dir jemand sagt, du sollst die einschalten — ein Lieferant, ein Telefonie-Installateur, ein Managed-Service, ein Integrator auf einem Rahmenvertrag — dann ist das kein Netzwerkingenieur und kein Sicherheitsspezialist. Er mag sehr gut in dem sein, was er tatsächlich tut, und das hier wird es nicht sein. Die richtige Antwort auf eine Telefonanlage, die eine Firewall braucht, um ihre Signalisierung umzuschreiben, ist, die Telefonanlage zu reparieren, und wer dir stattdessen sagt, du sollst deine Grenze einem Textmuster-Parser öffnen, sagt dir damit, dass er entweder nicht weiß, was eine Expectation ist, oder dass es ihm egal ist. Wir sind hier nicht bei den Amateuren. Seit 2007 steht in Standards-Track-Dokumenten, wie man es richtig macht, und „schalt halt den SIP-Helper ein“ ist das Geräusch von jemandem, der nach dem greift, was das Ticket heute schließt.\nFrag ihn im Raum, worauf der Platzhalter für die Quelladresse der Expectation gesetzt ist. Wenn die Frage überrascht, hast du deine Antwort, und um das Protokoll ging es nie.\nWenn du sie noch betreibst — kannst du dich Profi nennen? Das ist eine ernst gemeinte Frage, und sie verdient eine ernst gemeinte Antwort, also hier sind drei, denn es gibt drei Fälle. Es hängt davon ab, ob du es weißt — und Wissen ist nichts, was einem passiert. Dafür zu sorgen, dass man es weiß, ist die Arbeit.\nWenn auf einer Grenze, für die du verantwortlich bist, ein SIP-, H.323- oder FTP-Helper aktiv ist und du nicht ohne Nachschlagen sagen kannst, was eine Expectation ist, welche ihrer Felder Platzhalter sind, wer die Werte liefert und was deine Zertifizierungsangabe über eingehende Regeln behauptet — dann nein. Hierbei nicht. Du hast keine Konfiguration gewählt, du hast einen Standardwert geerbt und nie nachgelesen. Das Versäumnis ist nicht die Lücke; Lücken hat jeder, und diese hatte ich auch. Es ist, eine Grenze über eine Lücke zu bauen, die du nie geschlossen hast, und dann etwas zu unterschreiben, das sagt, die Grenze sei dicht.\nWenn du genau weißt, was es tut, und es an ist, weil ein Regulierer das Protokoll benennt, weil die Technik eines Partners nichts anderes terminiert oder weil die Telefonanlage im März ersetzt wird und das bis dahin laufen muss — dann ja, offensichtlich, und du machst deine Arbeit richtig. Das sind echte Zwänge, und ich habe mich um Schlimmeres herumgearbeitet. Professionell statt fahrlässig wird es dadurch, dass du aufgeschrieben hast, welcher Helper, auf welcher Schnittstelle, für welchen Fluss, warum, und zu welchem Datum er wieder abgeht. Also genau die Papierarbeit, nach der die Firewall-Anforderung ohnehin gefragt hat.\nDer unhaltbare Fall ist der mittlere. Genug zu wissen, um unruhig zu sein, und es trotzdem laufen zu lassen, weil dich nie jemand zur Rechtfertigung gezwungen hat. Das ist keine Ingenieursarbeit. Das ist Gewohnheit mit einer Change-Nummer daran, und so ist eine Funktion, die dir eine Best Current Practice im Januar 2007 abzuschalten geheißen hat, 2026 noch an.\nAm meisten zählt das, wenn du jemanden für sein Urteilsvermögen bezahlst, denn Urteilsvermögen lässt sich bei der Lieferung nicht prüfen. Prüfe es also vorher. Frag, was ihr Standardaufbau mit Protokoll-Helpern macht und warum, frag, was passiert, wenn jemand im Gästenetz einen Link öffnet, und frag, welche internen Geräte mit aktivem H.323-Helper erreichbar wären — und achte darauf, ob sie „nur der Rechner, der geklickt hat“ sagen, denn das ist falsch, und es ist die falsche Antwort, die eine kompetent klingende Person gibt. Du weißt innerhalb von zwei Minuten, ob dir etwas erzählt oder etwas vorgelesen wird, und zwei Minuten sind ein viel billigerer Test als ein Vorfall.\nKommt als Antwort ein Schulterzucken und du unterschreibst trotzdem, ist auch das eine Entscheidung. Sie hat nur aufgehört, ihre zu sein, und ist deine geworden.\nNiemand musste es je rechtfertigen Ich möchte den Leuten gegenüber fair sein, die diese Dinge gebaut haben, denn das haben sie verdient.\n1994 war der Helper eine vernünftige Antwort auf ein echtes Problem. Adressen wurden knapp, NAT war die pragmatische Lösung, eine Handvoll wichtiger Protokolle überlebte sie nicht, und die Wahl bestand darin, jeden FTP-Client der Welt zu ändern oder der Kiste das Lesen beizubringen. Sie brachten der Kiste das Lesen bei, lieferten die sichersten Standardwerte aus, die ihnen einfielen, und schrieben Warnungen in den Quelltext, wozu man das Ding bringen kann. Diese Warnungen stehen immer noch da. Eine davon habe ich zitiert.\nWas danach schieflief, ist kein technisches Versagen. Es ist, dass in dieser Branche nie irgendjemand gezwungen war, es noch einmal anzuschauen. Die IETF sagte, schaltet sie ab, und hatte keine Macht, irgendjemanden dazu zu bringen. Der Kernel änderte seinen Standard und konnte die bereits ausgelieferten Geräte nicht erreichen. Forscher haben es in sechzehn Jahren viermal bewiesen, und jedes Mal landete die Korrektur woanders als in der Firewall.\nWährenddessen blieb der Standardwert an. Nicht, weil ihn jemand verteidigt hätte. Sondern weil ein Standardwert, über den niemand streitet, unbegrenzt überlebt, und weil es nirgends eine Abteilung gibt, deren Aufgabe es wäre, Dinge zu beenden.\nDas ist das Muster, und es ist größer als eine Firewall-Funktion. Dieses Gewerbe ist hervorragend im Erhalten und hoffnungslos im Aufhören. Wartung ist budgetiert, besetzt, abrechenbar und sicher, während Stilllegung eine Person braucht, die ihren Namen unter eine Änderung setzt, die keinen Vorteil bringt, wenn sie gutgeht, und überall ihren Namen trägt, wenn nicht. Also bleibt das Ding, und es bleibt, und eines Tages stellt jemand fest, dass es Ports zu deinem Drucker öffnet.\nDas Indiz ist für mich diese Formulierung in Ciscos eigener Dokumentation: Das ALG erzeugt eine NAT-Tür. Kein Filter. Keine Kontrolle. Eine Tür, in der Wand, für die du bezahlt hast, geöffnet von jedem, der ein Paket mit den richtigen Wörtern vorne dran hindurchbekommt — und die eingespielte Antwort der Branche war, die Vorbeigehenden zu bitten, bitte nicht an der Klinke zu ziehen.\nDu kannst deine heute Nachmittag schließen, und das ist der Teil, auf dem es sich zu enden lohnt. Nicht die Angriffe; die Angriffe sind nur das, was passiert, wenn es niemand tut. Geh nachsehen, was deine Grenze eingehend erlaubt, das du nie aufgeschrieben hast, entscheide, ob du es so wolltest, und nimm die heraus, die du nicht wolltest — mit einem Datum neben dem, was du behältst.\nMehr war eine Grenze nie: eine Liste von Dingen, die jemand zu erlauben gewählt hat und begründen konnte. Was darauf steht, ohne dass es jemand gewählt hat, ist keine Sicherheit. Das ist Mobiliar.\nSamy Kamkar — NAT Pinning, 5. Januar 2010. Der ursprüngliche Angriff vom Browser auf das ALG, mit einem versteckten Formular, das einen Browser ein IRC-DCC CHAT oder eine FTP-227-Antwortzeile senden lässt, sodass der Helper des Routers einen eingehenden Port öffnet. „No XSS or CSRF required.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nSamy Kamkar — NAT Slipstreaming, 31. Oktober 2020, aktualisiert im Januar 2021. Vom Autor zusammengefasst als „an attacker to remotely access any TCP/UDP service bound to a victim machine, bypassing the victim\u0026rsquo;s NAT/firewall (arbitrary firewall pinhole control), just by the victim visiting a website“. Enthält die Technik mit den Segmentgrenzen, den Hinweis, dass der SIP-Handler „will bail unless the method (eg, REGISTER) occurs at the start of the data portion of the packet“, und die Firmware-Analyse eines Netgear-Geräts, die ftp_decode und sip_decode in einem Kernelmodul fand.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nBen Seri und Gregory Vishnepolsky, Armis — NAT Slipstreaming v2.0, 26. Januar 2021. Das H.323-Rufumleitungs-Primitiv, die Umgehung der Browser-Sperrliste über das Relay, die Liste der getesteten Produkte (OpenWrt, VyOS, Consumer-Linux-Router, FortiGate, Cisco ASAv und csr1000v, HPE vsr1000, SonicWall TZ300), der Ablauf der Offenlegung und der Schluss, dass „resolving the issue will require a fundamental change of their implementations by various router/firewall vendors“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 4787 — Network Address Translation (NAT) Behavioral Requirements for Unicast UDP, Januar 2007, BCP 127. Abschnitt 7 trägt REQ-10 und die Beobachtung, dass „Certain NATs have these ALGs turned on permanently, others have them turned on by default but allow them to be turned off“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nPablo Neira Ayuso — netfilter: nf_ct_helper: disable automatic helper assignment, Commit 3bb398d9, 25. April 2016, ausgeliefert mit Linux 4.7. Ändert den Standard von nf_conntrack_helper von aktiviert auf deaktiviert.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nChromium-Quelltext — net/base/port_util.cc, dessen kRestrictedPorts-Array 69, 137, 139, 161, 554, 1719, 1720, 1723, 5060, 5061, 6566 und 10080 enthält. Adam Rices Ankündigung der SIP-Ports, 5. November 2020: „a carefully-crafted HTTP request to port 5060 on an attacker\u0026rsquo;s server can fool some NAT devices into treating it as a SIP packet and setting up port forwarding to an attacker-controlled port number.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCisco — SIP ALG Hardening for NAT and Firewall, IP Addressing Configuration Guide, Cisco IOS XE 17.x. „SIP ALG creates a firewall pinhole or a Network Address Translation (NAT) door based on the first value in the Via header field for each SIP request received.“ NAT-Unterstützung für SIP ist „enabled by default on port 5060“. Siehe auch Using Application-Level Gateways with NAT, wo steht, dass SIP und H.323 standardmäßig aktiviert sind.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nPalo Alto Networks — Disable the SIP Application-level Gateway (ALG). „SIP ALG creates dynamic NAT pinholes but may interfere with VoIP applications that have NAT traversal capabilities, causing communication failures.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 2663 — IP Network Address Translator (NAT) Terminology and Considerations, August 1999. In Abschnitt 2.9 wird das Application Level Gateway definiert.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 3234 — Middleboxes: Taxonomy and Issues, Februar 2002. Die Zeile zum Schichtbruch steht in Abschnitt 2.11; die Kosten zusätzlicher Kisten im Pfad in Abschnitt 5, der ergänzt, das „creates extra points of attack, reduces or eliminates the ability to perform end to end encryption, and complicates trust models and key distribution models“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nEric Leblond, Pablo Neira Ayuso, Patrick McHardy, Jan Engelhardt und Mr Dash Four — Secure use of iptables and connection tracking helpers. „This system relies on parsing of data coming either from the user or the server. It is therefore vulnerable to attack and great care must be taken when using connection tracking helpers.“ Quelle des Zitats zum IRC-Platzhalter, und Dokumentation des nf_conntrack_helper-sysctl und des CT --helper-Ziels.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nLinux-Kernelquelltext — net/netfilter/nf_conntrack_ftp.c. Der Modulparameter loose steht standardmäßig auf false und schützt den Fall, in dem die Adresse im PORT-Kommando nicht die des Clients ist; der Kommentar benennt das Risiko als „DMZ machines opening holes to internal networks, or the packet filter itself“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nnetfilter — H.323 conntrack/NAT helper, vom Autor des Moduls. Enthält das Rufumleitungsszenario, in dem eine Sitzung auf eine dritte Adresse verweisen darf.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nDavid Leadbeater — NAT-Again: IRC NAT helper flaws, August 2022. Zeigt den Auslöser über das Ping-Echo, merkt an, dass sich damit auch scannen, die echten Adressen verschleierter Nutzer aufdecken und Nutzer durch Angabe von Port 0 trennen lassen, und empfiehlt: „Potentially entirely deprecate and remove nf_conntrack_irc, it\u0026rsquo;s unclear it has much use anymore.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCVE-2022-2663 — „An issue was found in the Linux kernel in nf_conntrack_irc where the message handling can be confused and incorrectly matches the message. A firewall may be able to be bypassed when users are using unencrypted IRC with nf_conntrack_irc configured.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCisco — Advisory zu CVE-2018-15454, erstveröffentlicht am 31. Oktober 2018. Als Gegenmaßnahme wird no inspect sip auf der ASA und configure inspection sip disable auf FTD genannt; der NVD-Eintrag hält fest, dass zum Zeitpunkt der Veröffentlichung galt: „Software updates that address this vulnerability are not yet available.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 4217 — Securing FTP with TLS, Oktober 2005.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 3715 — IPsec-Network Address Translation (NAT) Compatibility Requirements, März 2004. Abschnitt 2.1 Punkt (f) behandelt die SPI-Wahl gegenüber NAT; Abschnitt 2.3 trägt den Titel Helper Incompatibilities und enthält die zitierten Zeilen zum IKE-Cookie-Demultiplexing und zum Parsen von ISAKMP-Payloads.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nJuniper — IKE and ESP ALG, Application Layer Gateways User Guide. Quelle der Gate-Beschreibung, des Hinweises, dass NAT-T-Verkehr auf Port 4500 vom ALG nicht verarbeitet wird, und der Warnung, dass das Gerät bei zwei Clients hinter derselben übersetzten Adresse „will be unable to distinguish and route return traffic properly“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCisco — IPsec Pass Through Inspection, ASA Firewall CLI Configuration Guide 9.20. „IPsec Pass Through application inspection provides convenient traversal of ESP (IP protocol 50) and AH (IP protocol 51) traffic associated with an IKE UDP port 500 connection.“ Nicht in der Standardrichtlinie; die mitgelieferte _default_ipsec_passthru_map „sets no maximum limit on ESP connections per client“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 3947 — Negotiation of NAT-Traversal in the IKE, und RFC 3948 — UDP Encapsulation of IPsec ESP Packets, beide Januar 2005.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCole Dishington — netfilter: nf_conntrack: Add conntrack helper for ESP/IPsec, Mai 2021, dritte Fassung. Auf netfilter-devel reviewt und nicht gemergt; net/netfilter im Mainline-Kernel enthält weiterhin keine nf_conntrack_proto_esp.c.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNCSC und IASME — Cyber Essentials: Requirements for IT Infrastructure v3.3, April 2026. Kontrolle 1, Firewalls, gilt für „boundary firewalls, desktop computers, laptops, routers, servers, IaaS, PaaS, SaaS“, und die drei im Text zitierten Anforderungen sind ihre eigenen Worte.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 3027 — Protocol Complications with the IP Network Address Translator, Januar 2001. „The purpose of this document is to identify the protocols and applications that break with NAT enroute.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nWHATWG Fetch — Pull Request 1109, die Standardänderung, die die Bad-Port-Einträge über alle Browser hinweg ergänzt hat.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nOpenBSD — ftp-proxy(8). „ftp-proxy is a proxy for the Internet File Transfer Protocol.“ Steuerverbindungen erreichen ihn nur, weil du sie dorthin schickst: „FTP control connections should be redirected into the proxy using the pf(4) divert-to command, after which the proxy connects to the server on behalf of the client.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nFortinet — Technical Tip: Disabling VoIP Inspection. Dokumentiert das Entfernen des SIP-Eintrags aus config system session-helper, set default-voip-alg-mode kernel-helper-based, und den Hinweis, dass ein erneutes Aktivieren einen Neustart erfordert.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMozilla — Stopping FTP support in Firefox 90, 20. Juli 2021, und Google — Deprecations and removals in Chrome 95, Oktober 2021: „Use of FTP in the browser is sufficiently low that it is no longer viable to invest in improving the existing FTP client.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://blogs.damiendye.uk/de/networking/protocol-helpers-turn-them-off/","summary":"Ein Protokoll-Helper — SIP ALG, FTP-Helper, H.323 ALG, conntrack-Helper, nenn ihn, wie dein Hersteller ihn nennt — liest die Nutzlast einer Verbindung, findet dort eine Adresse und einen Port und öffnet dafür ein eingehendes Loch. Er kann nicht erkennen, ob dieser Text von einem echten FTP-Client stammt oder von einem versteckten Formular auf einer Webseite, weil nichts darin das verrät. Samy Kamkar hat den Browser-Fall 2010 gezeigt, NAT Slipstreaming 2020 erneut, und Armis hat ihn 2021 so erweitert, dass jedes Gerät im Netz erreichbar wird, nicht nur der Rechner, der geklickt hat. Die IETF hat 2007 verlangt, dass diese Dinger standardmäßig aus sind, Linux hat sie 2016 abgeschaltet, und die Browser-Hersteller liefern am Ende eine Sperrliste von Ports aus, die sich liest wie ein Verzeichnis der conntrack-Module. Dieser Beitrag geht den Mechanismus Diagramm für Diagramm durch — die Expectation-Tabelle, den Segmentgrenzen-Trick, die H.323-Rufumleitung, den IRC-Helper, der auf die Nachricht eines Fremden anspringt —, nimmt den IPsec-Pass-through-Helper dazu, der ESP überhaupt nicht lesen kann und eingehende Pakete anhand eines SPI steuert, den er im Klartext vorbeiziehen sah, stellt das Ganze der Firewall-Anforderung von Cyber Essentials gegenüber, die er klar reißt, und gibt die Befehle, mit denen du das Ganze auf Linux, Cisco, Juniper, FortiGate und MikroTik abschaltest.","title":"Deine Firewall nimmt Anweisungen von Fremden entgegen. Schalte die Protokoll-Helper ab."},{"content":"IPsec war eine gute Idee. Leg die Verschlüsselung auf die Netzwerkschicht, unter alles andere, und jedes Protokoll, das über IP läuft, erbt Vertraulichkeit und Integrität, ohne davon zu wissen. Keine Bibliothek einzubinden. Kein Zertifikat pro Anwendung. Kein Umschreiben dessen, was du längst ausgeliefert hast. Das Paket verlässt den Rechner geschützt und kommt geschützt an, und die Router dazwischen tragen es, ohne zu wissen oder wissen zu wollen, was drinsteckt.\nDieser Entwurf ruht auf einer Annahme, und sie steht im Standard, statt nur mitgemeint zu sein: die Adresse eines Pakets bezeichnet die Maschine, von der es kam. Eine Security Association wird über die Zieladresse, die Protokollnummer und den SPI nachgeschlagen1. Der Authentication Header geht noch weiter und signiert den IP-Header selbst, Quelle und Ziel eingeschlossen2. Die Adresse ist für IPsec keine Routing-Metadaten. Sie ist Teil der Identität und Teil der Integritätsprüfung.\nDann hat diese Branche dreißig Jahre lang die Adresse weggenommen.\nZuerst NAT, damit ein Büro hinter eine Leitung passt. Dann Carrier-Grade NAT, damit mehrere hundert Haushalte hinter eine Adresse passen, weil IPv6 einzuschalten Arbeit war und eine Box zu kaufen Beschaffung — was das ganze Thema von Uns sind nie die Adressen ausgegangen. Uns ist die Mühe ausgegangen. ist, und das gehe ich hier nicht noch einmal durch. Was für diesen Beitrag zählt, ist die Folge. Genau das eine, worauf IPsec gebaut wurde, liefert das moderne Zugangsnetz nicht mehr.\nAlso wurde IPsec geflickt. Pack das verschlüsselte Paket in UDP, damit ein Übersetzer einen Port zum Umschreiben hat. Setz die Prüfsumme auf null, damit sie niemand nachrechnet. Schick alle zwanzig Sekunden ein Ein-Byte-Paket, für immer, damit eine Tabelle in fremder Hardware nicht vergisst, dass es dich gibt. Nimm die Identität von der Adresse weg und häng sie an einen Namen. Gib den Authentication Header auf, weil er einen umgeschriebenen Header konstruktionsbedingt nicht überleben kann. Und wenn ein Hotel UDP blockiert, pack das Ganze zusätzlich in TCP3.\nJede einzelne davon ist eine echte, standardisierte, herstellerunterstützte Lösung. Zusammen sind sie ein Protokoll, das von seinem eigenen Gerüst gehalten wird. Und das Gerüst ist das Argument: man stützt nichts ein Vierteljahrhundert lang ab, weil es im Kern gesund ist.\nIch bin zu dem Schluss gekommen, dass IPsec vollständig stillgelegt gehört. Nicht nachjustiert, nicht mit besseren Chiffren neu aufgelegt, nicht für Site-to-Site behalten, weil der Teil ja noch geht. Stillgelegt, mit Terminen, so wie PPTP ein Jahrzehnt früher hätte stillgelegt werden sollen, als sich endlich jemand darum gekümmert hat. Was folgt, sind die Belege, die Diagramme, die Herstellerdokumentation, die all das in den Worten der Hersteller selbst sagt, und — weil die meisten, die das lesen, die Dinger montags trotzdem am Laufen halten müssen — eine brauchbare Methode, IPsec-Fehler in der Zwischenzeit zu diagnostizieren.\nWas es dich tatsächlich kostet, in Tickets Vor den Standards hier die Rechnung, in der Reihenfolge, in der sie dir begegnet.\nDer Tunnel fällt im Takt aus. Jede Stunde, oder alle acht, oder nach zwanzig Minuten ohne Verkehr. Er kommt zurück, sobald jemand eine Datei öffnet, also meldet ihn die Hälfte der Leute nie und die andere Hälfte meldet „das VPN ist langsam“. Geändert hat niemand etwas.\nZwei Leute im selben Haus können nicht beide verbinden. Der zweite kommt hoch, der erste geht runter. Sie rufen getrennt beim Service Desk an, also treffen sich die Tickets nie und vierzehn Tage lang fällt das Muster niemandem auf.\nKleines geht, Großes hängt. Anmelden geht. Teams geht. Ping geht. Eine Datei zu kopieren bleibt jedes Mal an derselben Stelle stehen, und eine große Seite in einer internen Anwendung hängt, bis sie in den Timeout läuft.\nDer Tunnel steht und es fließt nichts. Beide Seiten sagen „established“. Beide Seiten sind zufrieden mit sich. Es bewegt sich nichts.\nVon außen kommt nichts herein. Site-to-Site zur Filiale, die auf einen Glasfaser-Altnet gewechselt ist, baut sich nicht mehr in der Richtung auf, in der es früher ging, und niemand kann sagen warum, nur dass „deren IP sich geändert hat“.\nQoS einzuschalten hat die Verschlüsselung kaputtgemacht. Jemand hat Sprache priorisiert, und jetzt verwirft die Gegenstelle Pakete als Replays.\nNichts davon ist eine Fehlkonfiguration im gewöhnlichen Sinn. Jeder einzelne Punkt ist IPsec, das auf das Netz trifft, wie es heute ist. Der Rest dieses Beitrags ist das Warum, der Reihe nach, und wie du nachweist, welchen Fall du hast.\nIPsec wird nicht vom Netz getragen. Es ist das Netz. Fang damit an, was es war, denn der Entwurf ist wirklich gut und die Fehler ergeben nur vor diesem Hintergrund Sinn.\nESP ist kein Protokoll, das über TCP oder UDP läuft. Es ist ein Transportprotokoll, IP-Protokollnummer 50, direkt auf IP, in genau dem Steckplatz, in dem auch TCP und UDP sitzen. AH ist Protokoll 51. Keines hat ein Portfeld, weil keines eines braucht: in dem Internet, für das IPsec entworfen wurde, bezeichnet die Zieladresse bereits genau eine Maschine, und der SPI im ESP-Header bezeichnet, welche Security Association auf dieser Maschine gemeint ist. Adresse plus Protokoll plus SPI. Dieses Tripel ist der Nachschlagevorgang1.\nDer Entwurf wie spezifiziert: die Adresse benennt die Maschine, also braucht es keine Ports und jedes Ende kann anfangen IPsec wie spezifiziert: die Adresse ist die Identität Host A 203.0.113.10 Router nur weiterleiten Host B 198.51.100.7 jedes Ende kann anfangen Was die Maschine verlässt äußerer IP-Header src 203.0.113.10 an 198.51.100.7 Protokoll 50 = ESP SPI 4 B Sequenz 4 B verschlüsselte Nutzlast dein Paket, unterwegs nicht lesbar ICV 16 B Association = Zieladresse + Protokoll + SPI. Nirgends ein Portfeld, weil keines gebraucht wird. Drei Annahmen dieses Entwurfs, 1995 alle zutreffend: Die Adresse auf dem Paket ist die Maschine. Nichts im Pfad schreibt einen Header um. Jedes Ende ist anwählbar. Der Authentication Header geht weiter und signiert den äußeren Header selbst, Quelle und Ziel eingeschlossen, sodass ein Empfänger beweisen kann, dass die Adressen unterwegs unberührt blieben. Nicht maßstabsgetreu. Der ESP-Overhead hängt von der Chiffre ab; hier AES-GCM im Tunnelmodus über IPv4. Der Entwurf, wie er spezifiziert ist. ESP sitzt als Protokoll 50 direkt auf IP, ohne Ports, weil es keine braucht — die Zieladresse benennt den Host und der SPI benennt die Association darauf. AH signiert den IP-Header selbst. Beide Enden halten eine echte, erreichbare Adresse, jedes Ende kann das Gespräch beginnen, und nichts in der Mitte muss die Nutzlast verstehen. Schau, was das einbringt. Es gibt keinen Handshake-Port, den man exponieren müsste, keine Sitzungsschicht, die man falsch machen kann, keine Anwendung, die mitmachen muss. Jedes Ende kann anfangen. Die Mitte des Netzes ist dumm, und genau das soll die Mitte eines Netzes sein. Ein Router leitet Protokoll 50 genauso weiter wie Protokoll 6, und dass er die Nutzlast nicht lesen kann, ist der Sinn der Sache und keine Einschränkung.\nEin sauberer Entwurf. Und zugleich, im Jahr 2026, die Beschreibung eines Internets, das die meisten, die das lesen, gar nicht kaufen können.\nDann hat jemand in jeden Pfad einen Übersetzer gestellt Ein NAT schreibt die Quelladresse um, oft auch den Quellport, damit sich mehrere Maschinen eine Adresse teilen. Mehr macht es nicht. Gegen IPsec ist das beinahe ein vollständiger Abriss, und die IETF war ehrlich genug, dazu ein ganzes Dokument zu veröffentlichen, das die Einzelteile auflistet: RFC 3715, IPsec-Network Address Translation (NAT) Compatibility Requirements4. Sechzehn getrennte Unverträglichkeiten. Hier die, auf die es ankommt.\nAH ist erledigt, konstruktionsbedingt. In den Worten von RFC 3715: „Since the AH header incorporates the IP source and destination addresses in the keyed message integrity check, NAT or reverse NAT devices making changes to address fields will invalidate the message integrity check.“4 — der AH-Header nimmt Quell- und Zieladresse in die Integritätsprüfung auf, also macht jede Adressänderung die Prüfung ungültig. Dafür gibt es keine Lösung, und es sollte auch nie eine geben. Ein Protokoll, das den Header signiert, kommt nicht durch eine Box, deren ganze Aufgabe das Umschreiben des Headers ist. AH wurde nicht umgangen. Es wurde aufgegeben.\nEs gibt keine Ports zum Übersetzen. Ein NAT, das Portübersetzung macht, braucht einen Port. ESP hat keinen. Cisco schreibt es im Catalyst-Konfigurationshandbuch unverblümt hin: „If PAT found a legislative IP address and port, it would drop the Encapsulating Security Payload (ESP) packet.“5 Das Paket wird nicht aus Richtliniengründen abgewiesen. Es wird verworfen, weil die Box nichts hat, wohin sie schreiben könnte, was sie schreiben muss.\nDie Identität passt nicht mehr zum Paket. Wieder aus RFC 3715: „Where IP addresses are used as identifiers in Internet Key Exchange Protocol (IKE) Phase 1 or Phase 2, modification of the IP source or destination addresses by NATs or reverse NATs will result in a mismatch between the identifiers and the addresses in the IP header.“4 — werden Adressen als Bezeichner verwendet, passt nach der Übersetzung der Bezeichner nicht mehr zum Header. Ein Identitätsschema, das Maschinen über Adressen benennt, überlebt kein Gerät, das Maschinen beruflich umbenennt.\nZwei Maschinen können denselben SPI wählen. Der SPI wird vom Empfänger gewählt und muss nur bei ihm eindeutig sein. Setz zwei Hosts hinter eine Adresse, und der Übersetzer hat zwei Associations, die er nicht auseinanderhalten kann.\nVon außen kann nichts anfangen. Ein NAT baut seine Tabelle aus ausgehenden Paketen auf. Es gibt kein ausgehendes Paket, bevor jemand anfängt, und auf einer NAT-Leitung kann nur die Innenseite anfangen. Die halbe Symmetrie des Protokolls ist weg.\nEin Übersetzer im Pfad bricht fünf Dinge auf einmal, und jede Lösung dafür kostet etwas Ein Übersetzer im Pfad, und fünf Dinge brechen auf einmal Host 192.0.2.20 Übersetzer Quelle wird 203.0.113.5 Gateway 198.51.100.7 von dieser Seite kann nichts anfangen Was das Umschreiben zerstört 1 Der signierte Header passt nicht mehr. AH deckt Quell- und Zieladresse ab, also scheitert die Integritätsprüfung konstruktionsbedingt. Es gibt keine Lösung. AH ist über einen Übersetzer nicht nutzbar. 2 Es gibt keinen Port zum Umschreiben. ESP ist IP-Protokoll 50 und hat kein Portfeld, also hat ein Übersetzer mit Portübersetzung nichts in der Hand und verwirft das Paket. 3 Die Identität passt nicht mehr zum Paket. Der Schlüsselaustausch benannte den Peer per Adresse. Die Adresse im Header gehört jetzt jemand anderem. 4 Zwei Hosts können denselben SPI wählen. Der Empfänger wählt ihn und garantiert nur, dass er bei ihm eindeutig ist, also hat der Übersetzer zwei nicht unterscheidbare Associations. 5 Die halbe Symmetrie ist weg. Die Tabelle entsteht aus ausgehenden Paketen, also kann nur die Innenseite anfangen. Der Kompromiss, und was jeder Teil davon kostet Pack das ganze ESP-Paket in UDP auf Port 4500, damit der Übersetzer etwas versteht. Gib den Authentication Header ganz auf, weil ihn nichts retten kann. Setz die UDP-Prüfsumme auf null, weil sie über umgeschriebene Adressen nur scheitern würde. Nimm die Identität von der Adresse und häng sie an einen Namen, den der Peer behauptet. Schick alle zwanzig Sekunden ein Byte, für immer, damit fremde Hardware dich nicht vergisst. Es funktioniert. Das bestreitet niemand. Das Argument ist: nichts Gesundes braucht fünf Zugeständnisse für eine Box. Derselbe Tunnel mit einem Übersetzer im Pfad. Fünf Dinge brechen auf einmal: der signierte Header passt nicht mehr, es gibt keinen Port, den der Übersetzer umschreiben könnte, die Identität passt nicht mehr zur Quelladresse, zwei Hosts können denselben SPI wählen, und von außen kann niemand ein Gespräch beginnen. Die Zeile darunter ist, was die Branche dagegen unternommen hat — und jede Lösung ist etwas, das aufgegeben wurde. Die Lösung war echt, und jeder Teil davon hat etwas gekostet NAT-Traversal funktioniert. Das bestreite ich nicht, und ich tue auch nicht so. Ich habe reichlich Tunnel durch reichlich NATs betrieben. Was ich festhalten will, ist die Rechnung, denn sie wird täglich von allen bezahlt und fast niemand listet sie auf.\nDer Mechanismus ist RFC 3948: erkenne beim Schlüsselaustausch einen Übersetzer, und steck dann das ganze ESP-Paket in ein UDP-Datagramm auf Port 4500, damit der Übersetzer etwas hat, das er versteht6. Ciscos Beschreibung des Wire-Formats ist präzise: nach der Verschlüsselung werden „a UDP header and a non-IKE marker (which is 8 bytes in length) are inserted between the original IP header and ESP header“5 — ein UDP-Header und eine acht Byte lange Nicht-IKE-Markierung zwischen ursprünglichem IP-Header und ESP-Header eingefügt. Junipers Fassung ist kürzer und sagt dasselbe: „NAT-T encapsulates both IKE and ESP traffic within UDP with port 4500 used as both the source and destination port.“7\nJetzt die aufgeschlüsselte Rechnung.\nDer Authentication Header ist weg. Nicht höflich abgekündigt. Unbrauchbar. RFC 8221 sagt inzwischen klar, dass ESP zusammen mit AH NOT RECOMMENDED ist8, und der ehrliche Grund ist: das eine, was AH konnte und ESP nicht kann, ist genau das eine, was NAT zerstört.\nDie UDP-Prüfsumme wird absichtlich auf null gesetzt. RFC 3948 verlangt es: bei umgeschriebenen Adressen würde eine darüber berechnete Prüfsumme scheitern, also lautet die Antwort des Standards, sie gar nicht erst zu berechnen. „If the protocol header after the ESP header is a UDP header, set the checksum field to zero in the UDP header.“6 Eine Schicht Fehlererkennung entfernt, damit eine Schicht Adressumschreibung weiter funktioniert.\nDu schickst jetzt Pakete, nur um eine Tabelle warm zu halten. RFC 3948 definiert einen Keepalive als ein Byte, 0xFF, gesendet, wenn sonst nichts innerhalb eines konfigurierbaren Intervalls hinausgegangen ist, dessen Vorgabe zwanzig Sekunden beträgt6. Juniper nennt den Grund ohne Schnörkel: „Because NAT devices age out stale UDP translations, keepalive messages are required between the peers.“7 Ein Laptop im Zug, der gar nichts tut, sendet also alle zwanzig Sekunden, für immer, weil eine Tabelle in einer Box, die keinem der beiden Enden gehört, sonst vergisst, dass es ihn gibt. Multipliziere das mit einer Flotte. Das ist der Funk, der aufwacht, der Akku, der leerer wird, und das Mobilfunknetz, das Verkehr trägt, dessen einziger Zweck es ist, Vergessen zu verhindern.\nDu firewallst jetzt zwei Ports statt eines Protokolls, und Ciscos eigene Einschränkungsliste verlangt statische Übersetzungsregeln für 500 und 4500, bevor überhaupt irgendetwas davon funktioniert5.\nUnd lies den Rest dieser Einschränkungsliste, denn da erklärt dir der Hersteller die Form der Sache. Dynamische NAT-Richtlinien: nicht unterstützt. IPv6-Verkehr: mit dem Feature unverträglich. IPsec und NAT auf demselben Gerät: beides zusammen geht nicht5. Das ist kein Konfigurationshandbuch. Das ist eine Liste der Stellen, an die das Gerüst nicht reicht.\nElegant ist daran nichts, und schuld ist auch niemand im Besonderen. Es ist, was passiert, wenn man ein Layer-3-Protokoll auf einem Netz am Leben hält, das aufgehört hat, Layer 3 zu achten.\nCarrier-Grade NAT hat den Rest weggenommen Gewöhnliches NAT hat die Adresse von der Maschine genommen und dem Standort gegeben. Der Übersetzer gehörte immer noch dir, du konntest also einen Port weiterleiten, ein Mapping festnageln, einen Timer verlängern oder den Konzentrator davorstellen.\nCarrier-Grade NAT nimmt die Adresse dem Standort weg und gibt sie mehreren hundert Fremden, und der Übersetzer gehört deinem Provider. Alles, was du früher dagegen tun konntest, kannst du jetzt nicht mehr.\nUnd sei dir klar, was tatsächlich im Pfad steht, denn genau das verstehen die Leute falsch. Der Router im Haus macht weiterhin NAT. Er wurde nicht abgeschaltet. Er übersetzt deinen Laptop auf 192.168.1.20 weiterhin auf die Adresse, die die Leitung hält — nur hält die Leitung jetzt 100.64.12.7, geteilten Adressraum, keine öffentliche Adresse. Der Carrier übersetzt das dann noch einmal. Das Paket durchquert also zwei Übersetzer, bevor es das Internet erreicht, und das ist der Normalfall, nicht die Ausnahme.\nCarrier-Grade NAT heißt zwei Übersetzungen, zwei Timer und an keiner davon eine erreichbare Adresse Carrier-Grade NAT sind zwei Übersetzungen, nicht eine Laptop 192.168.1.20 Router im Haus Übersetzung eins Die Leitung 100.64.12.7 Carrier-Übersetzer Übersetzung zwei, auf 203.0.113.9 deine, und die einzige Tabelle, die du siehst ihre, geteilt mit mehreren hundert Haushalten, für dich unsichtbar nichts aus dem Internet erreicht eine dieser beiden Adressen Zwei Tabellen, zwei Timer, und der kürzere gewinnt. Dein Keepalive muss den schlagen, der von beiden zuerst abläuft, und lesen kannst du nur einen. Der entscheidende ist der, den du nicht siehst. Portweiterleitung funktioniert und bewirkt nichts. Der Router leitet bereitwillig einen Port von einer Adresse weiter, die das Internet nicht erreicht. UPnP und PCP melden Erfolg und öffnen eine Tür auf einen Flur. Deshalb ist „ich habe 500 und 4500 weitergeleitet und es kommt trotzdem nicht hoch“ ein so häufiges und irreführendes Ticket. Die Responder-Rolle ist weg. Zwei Filialen an Consumer-Glasfaser können einander gar nicht anwählen. Etwas in der Mitte muss sie vorstellen, und du hängst an einer Firma, die du nie gewählt hast. Die Identität kann nicht die Adresse sein. Mehrere Anschlüsse kommen als eine Adresse an, also ist das Unterscheidungsmerkmal nicht das Feld, das IPsec nutzen sollte. Und es gibt eine veröffentlichte Obergrenze: auf den größeren SRX-Plattformen nennt Juniper höchstens 1.000 Tunnel je übersetzter Adresse. Die schnellste Bestätigung kostet nichts: lies die WAN-Adresse im Router. Beginnt sie mit 100.64, ist das der in RFC 6598 reservierte geteilte Adressraum, du sitzt hinter CGNAT, und die halbe Einstellungsseite ist Dekoration. Eine Geschäftsleitung mit echter statischer Adresse hat eine Übersetzung und einen erreichbaren Endpunkt. Genau das verkauft dir der monatliche Aufpreis: das, was früher jede Maschine umsonst hatte. Das Paket wird zweimal übersetzt: einmal vom Router im Haus, einmal vom Carrier. Keine der beiden Adressen, die es hält, ist von außen erreichbar. Das bedeutet zwei Mapping-Tabellen mit zwei unabhängigen Timern, von denen du nur einen siehst, Portweiterleitung, die gelingt und nichts bewirkt, überhaupt keine Responder-Rolle mehr, und eine Peer-Identität, die keine Adresse mehr sein kann. Du bist doppelt genattet, und nur eine der Tabellen gehört dir. Zwei Übersetzungen heißen zwei Mapping-Tabellen, zwei Alterungstimer und zwei Gelegenheiten, dass das Mapping verschwindet. Dein Keepalive muss den schlagen, der zuerst abläuft, und lesen kannst du genau einen davon. Schlimmer noch, die beiden greifen ineinander: der Router im Haus hat womöglich eigene Vorstellungen von IPsec und versucht mit einem Application Gateway zu helfen, sodass der Quellport, den dein Client zu benutzen glaubt, weder der ist, der das Haus verlässt, noch der, der den Carrier verlässt.\nPortweiterleitung funktioniert weiterhin und bewirkt überhaupt nichts. Das ist das Ticket, das am meisten Zeit frisst. Jemand leitet UDP 500 und 4500 am Heimrouter weiter, der Router nimmt es an, die Einstellungsseite sagt, die Regel sei aktiv — und nichts kann sie nutzen, weil sie von einer Adresse weiterleitet, die das Internet nicht erreicht. UPnP und PCP verhalten sich genauso: der Client bittet um ein Mapping, der Router gewährt es, und der Port öffnet sich auf einen Flur. Alles meldet Erfolg und nichts geht. Die Box erzählt dir, was du hören willst.\nAm schnellsten klärst du es umsonst. Lies die WAN-Adresse im Router. Fängt sie mit 100.64 an, ist das der in RFC 6598 reservierte geteilte Adressraum, du sitzt hinter Carrier-Grade NAT, und die halbe Einstellungsseite ist Dekoration.\nDie Responder-Rolle gibt es nicht mehr. Ein Gerät hinter CGNAT kann nicht das Ende sein, das jemand anwählt. Site-to-Site zwischen zwei Filialen an Consumer-Glasfaser — normal, günstig und genau das, was ein kleines Unternehmen will — verlangt, dass mindestens ein Ende eine echte Adresse hält, oder einen Dritten in der Mitte, der sie einander vorstellt. Dieser Dritte ist eine Firma, von der du jetzt abhängst, weil dein Provider dir keine Adresse geben wollte.\nDer Timer gehört jemand anderem. RFC 4787 sagt NAT-Betreibern, ein UDP-Mapping „MUST NOT expire in less than two minutes“, und empfiehlt fünf oder mehr9. Das ist die Untergrenze und die Empfehlung, kein Versprechen, und was dein Carrier tatsächlich macht, kannst du nicht nachsehen. Als solches hört der Keepalive auf, eine Stellschraube zu sein. Er ist tragend, auf einem Timer, den du rätst.\nDie Identität deines Peers kann nicht seine Adresse sein. Mehrere Anschlüsse erreichen die Gegenstelle als eine Adresse. Was der Konzentrator auch benutzt, um sie auseinanderzuhalten, es ist nicht der IP-Header — und genau den sollte IPsec benutzen.\nEs gibt eine harte Obergrenze, und die Hersteller veröffentlichen sie. Juniper hält für SRX5400, SRX5600 und SRX5800 fest: „the total number of tunnels from a given public translated IP cannot exceed 1000 tunnels“7. Lies das als Betreiber und nicht als Spezifikationszeile. Dein VPN-Konzentrator hat ein Limit je geteilter Adresse, das Teilen erledigt ein Carrier, mit dem du keinen Vertrag hast, und wie nah du an diesem Limit bist, hängt davon ab, wie viele deiner Nutzer zufällig hinter demselben sitzen. Es gibt keinen Zähler, in den du schauen kannst. Es gibt nur den Tag, an dem es für einige Leute anfängt zu scheitern und für andere nicht.\nAlles in diesem Abschnitt ist Folge einer Entscheidung, die dieses Land getroffen und immer wieder getroffen hat. Ich habe das anderswo vollständig ausgeführt und wiederhole es nicht. Der Punkt hier ist enger: die Kernannahme von IPsec wurde vom Zugangsnetz gelöscht, und IPsec lebt seitdem von Behelfslösungen.\nUnd das IPv6-only-Netz rettet es auch nicht Hier muss ich gegen mein eigenes Argument ehrlich sein, denn die naheliegende Antwort auf alles oben lautet: gut, dann gib jeder Maschine eine echte IPv6-Adresse und IPsec funktioniert wieder wie spezifiziert.\nTut es, zwischen zwei Enden, die beide eine haben. Das ist nicht das Netz, in dem die meisten sitzen.\nDie IPv6-only-Zugangsnetze, die es wirklich gibt, allen voran Mobilfunk, erreichen das IPv4-Internet über NAT64, und das ist im gewöhnlichen Sinn gar kein NAT. Es ist ein Protokollübersetzer, der ein IPv6-Paket in ein IPv4-Paket umschreibt. Und RFC 6146 benennt, was es trägt, und benennt, was es nicht trägt, ganz ohne Mehrdeutigkeit:\n„The current specification only defines how stateful NAT64 translates unicast packets carrying TCP, UDP, and ICMP traffic. Multicast packets and other protocols, including the Stream Control Transmission Protocol (SCTP), the Datagram Congestion Control Protocol (DCCP), and IPsec, are out of the scope of this specification.“10\nIPsec, namentlich, außerhalb des Geltungsbereichs. Und Pakete, die irgendetwas außerhalb dieser Liste tragen, „SHOULD be discarded“10.\nAuf einem IPv6-only-Telefon oder -Laptop, das einen IPv4-Konzentrator erreichen will — und das sind die meisten Konzentratoren —, wird natives ESP also nicht von einer Firewall verworfen oder von einem Übersetzer verstümmelt. Es wird von vornherein nicht transportiert. Der Übersetzer tut genau das, was sein Standard ihm vorschreibt.\nDie Antwort der Branche darauf ist zwangsläufig eine weitere Schicht: 464XLAT, das dem Gerät einen lokalen IPv4-Stack gibt und zweimal übersetzt, aus IPv4 heraus und wieder hinein, damit das, was NAT64 nicht tragen kann, trotzdem läuft11. Es steht schon auf der Liste der Anbauten im IPv6-Beitrag und ich argumentiere das nicht neu. Erwähnenswert ist hier die Form: ein Protokoll, das 2004 an NAT zerbrach, zerbricht auch an der Übersetzung, die 2011 für den IPv6-Übergang gebaut wurde, und beides wird damit beantwortet, es in etwas anderes einzupacken.\nDas ist die Prüfung, die ein Protokoll bestehen muss, um 2026 hierher zu gehören. Funktioniert es in dem Netz, das die Leute wirklich haben — hinter der geteilten Adresse eines Carriers, in einem IPv6-only-Mobilfunknetz, durch ein Hotel, das nur TCP 443 durchlässt? Alles, was auf einem UDP-Port aufsetzt, besteht alle drei, ohne dass man es ihm sagen müsste. IPsec braucht für jede eine andere Behelfslösung, und für die dritte zusätzlich TCP-Kapselung3.\nKeine Ports heißt auch keine zweite Leitung Hier ein Fehler, der mit NAT nichts zu tun hat, rein modern ist und fast keine Aufmerksamkeit bekommt.\nRouter und Switches verteilen Verkehr über parallele Pfade. Link Aggregation, Equal-Cost Multipath: beide funktionieren gleich, über einen Hash des Fünf-Tupels. Quelladresse, Zieladresse, Protokoll, Quellport, Zielport. ESP hat keine Ports. Also hasht jedes Paket eines Tunnels zwischen denselben zwei Adressen identisch, und der ganze Tunnel landet auf einer Mitgliedsleitung, egal wie viele du gekauft hast.\nZwei 10G-Leitungen und ein IPsec-Tunnel geben dir 10G. Vier geben dir 10G. Die Hardware arbeitet genau wie entworfen.\nDie Behelfslösung hat die gewohnte Form. Manche Silizium kann stattdessen über den SPI hashen, denn jeder SPI benennt eine Association und damit einen Fluss, aber das ist ein Feature, das man gekauft haben muss, und nichts, was man von einem Pfad annehmen kann, der einem nicht gehört. Es gibt einen aktiven IETF-Entwurf, dessen einziger Zweck es ist, ESP in noch einen UDP-Header zu packen, damit gewöhnliche Router es hashen können, und er sagt in einem Satz warum: „Although the ESP SPI field within the IPsec packets can be used as the load-balancing key, but it cannot be used by legacy switches and routers.“12 Seine Problembeschreibung ist genauso unverblümt darüber, was die Leute stattdessen tun: „Many cloud service providers allow customers to establish multiple IPsec VPN tunnels in parallel to enable ECMP and increase aggregate bandwidth. However, this approach is not ideal, as each tunnel typically requires its own public IP address, leading to higher public IP consumption and increased operational overhead.“12\nLass das kurz wirken. Der empfohlene Weg, eine verschlüsselte Strecke schneller zu machen, ist, mehrere davon zu bauen, jede mit einer verbrannten öffentlichen IPv4-Adresse — während einer Adressknappheit —, weil das Protokoll keine Portnummer zum Hashen hat. Ein UDP-basierter Tunnel bekommt Multipath derweil geschenkt, von Hardware, die vor fünfzehn Jahren ausgeliefert wurde, weil er einen Port hat wie alles andere im modernen Internet.\nDas ist kein Altlastproblem, das von selbst ausläuft. Das ist eine reale Grenze für Neubauten, heute, bei genau den Geschwindigkeiten, die gerade gekauft werden.\nDie MTU-Steuer, und wer sie zahlt Jeder Tunnel kostet Bytes. IPsec kostet mehr als die meisten, und die Art, wie es scheitert, wenn es knapp wird, ist die schlimmste Sorte Fehler: sporadisch, größenabhängig und unsichtbar für jeden Test, den man zuerst laufen lässt.\nWas jeder Tunnel pro Paket ausgibt, bevor deine Daten hineingehen Bytes weg, bevor deine Daten anfangen, maßstabsgetreu Header, pro Paket gesamt Natives ESP Tunnel, AES-GCM IP 20 ESP 8 IV 8 Trailer + Tag 18 54 B ESP in UDP Port 4500, für NAT IP 20 UDP 8 ESP 8 IV 8 Trailer + Tag 18 62 B L2TP/IPsec AES-CBC, NAT-T IP 20 UDP 8 ESP 8 IV 16 UDP 8 L2TP 6 PPP 4 Trailer + Tag 18 88 B PPTP GRE, Protokoll 47 IP 20 GRE 16 PPP 4 gar kein Integritäts-Tag 40 B WireGuard ein UDP-Port IP 20 UDP 8 Header 16 Tag 16 60 B Die schattierten Blöcke sind der Preis für fremde Übersetzer. In der L2TP-Zeile sitzen drei davon innerhalb der Verschlüsselung: ein zweiter UDP-Header, eine Sitzungsschicht und das Framing eines Einwahlmodems. PPTP ist am billigsten, weil es nichts schützt. Die 40 Byte kaufen keine Integritätsprüfung, und MS-CHAPv2 wurde 2012 auf eine einzige DES-Operation reduziert. Billig ist nicht der Maßstab. Was die Bytes kaufen, ist der Maßstab. Je eine durchgerechnete Konfiguration, über IPv4. Die genauen Zahlen hängen von Chiffre, Modus und Adressfamilie ab. Bytes, die auf jedem Paket draufgehen, bevor irgendetwas von deinen Daten hineinkommt, je eine durchgerechnete Konfiguration. Natives ESP ist schlank. Es für NAT einzupacken kostet acht weitere. L2TP/IPsec trägt innerhalb der Verschlüsselung einen UDP-Header, einen L2TP-Header und einen PPP-Header — Einwahl-Framing, verschlüsselt, im Jahr 2026. PPTP sieht billig aus, weil es überhaupt keine Integritätsprüfung trägt, und genau das ist das Problem daran. Rechne es für eine Konfiguration durch, statt zu wedeln. ESP im Tunnelmodus über IPv4 mit AES-GCM: 20 Byte äußerer IP-Header, 8 ESP-Header, 8 Nonce, mindestens 2 Trailer, 16 Integritätsprüfwert. 54 Byte, bevor irgendetwas von deinem Paket hineingeht. Pack es für NAT-Traversal ein, und der UDP-Header macht 62 daraus. Auf einem 1500-Byte-Pfad bleiben 1438, und sobald irgendwo davor PPPoE mit 1492 läuft, bist du wieder darunter.\nUnd dann der Teil, der daraus einen Fehler statt einer Rechenaufgabe macht. Ein Sender erfährt nur dadurch, dass ein Paket zu groß war, dass ein ICMP-Fehler zurückkommt — Fragmentation Needed bei IPv4, Packet Too Big bei IPv6. Verwirft irgendetwas im Pfad diese Fehler, erfährt es der Sender nie und schickt weiter Pakete, die weiter sterben. Das ist das klassische schwarze Loch: der Handshake geht durch, weil Handshakes klein sind, und die Übertragung hängt, weil Übertragungen es nicht sind.\nCisco pflegt dazu seit der GRE-und-IPsec-Zeit ein ganzes Dokument, und es ist immer noch eine der besseren Erklärungen dieses Zusammenspiels in irgendjemandes Bibliothek13. Es muss gepflegt werden, weil die Leute weiter pauschal ICMP blockieren und sich dann wundern, warum Tunnel sich seltsam benehmen.\nDie zwei Hälften dieses Arguments habe ich schon ausgeschrieben und sie gelten hier ohne Wiederholung: welche ICMP-Nachrichten tragend sind und welche nicht, in Ping: das Diagnosewerkzeug, das viel mehr öffnet, und wie du den genauen Hop findest, der deinen Verkehr frisst, in Die Firewall ist elf Hops entfernt. Die Kurzfassung für diesen Beitrag: die Fehler sind der Mechanismus, Echo ist es nicht, und eine Grenzrichtlinie, die ganz ICMP verwirft, hat dein VPN auf eine Weise kaputtgemacht, die dem VPN angelastet wird.\nUnd deine eigene Dienstgüte kann es kaputtmachen Noch einer, denn der erwischt gute Ingenieure, die das Richtige tun.\nESP trägt eine Sequenznummer, und der Empfänger führt ein Replay-Fenster von auf Cisco-Plattformen standardmäßig 64 Paketen14. Priorisiere jetzt Sprache auf dem sendenden Router. Low Latency Queueing tut, worum du gebeten hast, und ordnet Pakete gegenüber der Reihenfolge um, in der sie verschlüsselt wurden. Fällt ein Paket bei der Ankunft aus dem Fenster, verwirft die Gegenstelle es als Replay, und der Zähler, der hochgeht, ist ein Sicherheitszähler.\nCiscos eigene Worte: „Certain QoS features, such as Low Latency Queueing (LLQ), could cause IPsec packet delivery to become out-of-order and dropped by the receiving endpoint due to a replay check failure.“14 Ihre Antwort lautet, das Fenster auf 1024 zu verbreitern, wo die Plattform das hergibt, oder eine Erweiterung mit mehreren Sequenznummernräumen einzusetzen, die QoS-Klassen auf getrennte Sequenzräume innerhalb einer Association abbildet14.\nAlso: ein Standardfeature deines eigenen Netzes einzuschalten macht deinen eigenen Tunnel kaputt, und das Gegenmittel ist noch eine Protokollerweiterung. Dieselbe Form wie alles oben.\nL2TP: Einwahl-Framing, verschlüsselt, im Jahr 2026 L2TP ist kein Sicherheitsprotokoll und hat das nie behauptet. RFC 2661 ist ein Tunnelprotokoll zum Transport von PPP-Sitzungen, veröffentlicht 1999, ohne eigene Vertraulichkeit — sein eigener Sicherheitsabschnitt verweist dich für Schutz auf Paketebene auf IPsec15. Diese Paarung ist RFC 3193, und das Ergebnis ist der Stapel aus dem Diagramm oben: ein äußerer IP-Header, ein UDP-Header für NAT-Traversal, ESP, dann innerhalb der Verschlüsselung noch ein UDP-Header auf Port 1701, ein L2TP-Header und ein PPP-Header.\nPPP. Das Framing von Einwahlmodems, getragen in einem verschlüsselten Tunnel, über das Internet, im Jahr 2026, weil L2TP genau dafür geschrieben wurde.\nRechne durch, was das an einem Beispiel kostet — äußeres IP 20, UDP 8, ESP-Header und IV 24, inneres UDP 8, L2TP 6, PPP 4, Trailer und Prüfwert 18 — und du gibst rund 88 Byte pro Paket aus, um Daten zu bewegen, die natives ESP für 54 bewegt. Vierunddreißig Byte, auf jedem Paket, für eine Sitzungsschicht, die nichts hinzufügt, was du wolltest, und eine Verbindungsschicht, die für eine Telefonleitung entworfen wurde.\nDer Overhead ist noch das Geringste.\nEs multipliziert das NAT-Problem, statt es zu teilen. L2TP/IPsec nutzt üblicherweise ESP im Transportmodus, also den Modus, dem NAT am meisten zusetzt, und das bekannte Ergebnis ist, dass viele Implementierungen zwei Clients hinter einer Adresse überhaupt nicht unterstützen. Zwei Leute in einem Haus, oder vierzig in einem Büro, oder mehrere hundert hinter der geteilten Adresse eines Carriers. Die Gegenstelle sieht eine Adresse und kann die Sitzungen nicht auseinanderhalten, also ersetzt die zweite Verbindung die erste. Das ist das Ticket vom Anfang dieses Beitrags, und es ist kein Fehler in irgendjemandes Produkt — es ist das Identität-über-Adresse-Problem, das genau dort ankommt, wo die meisten Leute ihm begegnen.\nUnd im Feld wird es meist mit einem gemeinsamen Geheimnis für alle ausgerollt. Weil das Geheimnis im Client-Profil konfiguriert und mit der Einrichtungsanleitung verteilt wird, steht der Pre-Shared Key im Onboarding-Dokument, auf der Wiki-Seite, in der E-Mail an neue Kollegen und auf jedem Laptop, der je das Haus verlassen hat. Das ist kein zweiter Faktor. Das ist ein Passwort, das das Gateway gegenüber niemandem im Besonderen authentifiziert und noch nie gewechselt wurde.\nL2TP ist kein Protokoll, das schlecht gealtert ist. Es ist ein Protokoll, das vom ersten Tag an das Falsche transportiert hat und an IPsec geschraubt wurde, um wettzumachen, was es überhaupt nicht konnte.\nPPTP war nie sicher und wird immer noch verkauft PPTP verdient zwei Absätze und keinen Abschnitt, und es bekommt sie nur, weil Leute es immer noch ausliefern.\nEs war nie ein Standard. RFC 2637 ist Informational. Ein aufgeschriebenes Herstellerprotokoll, nichts, was die IETF je empfohlen hätte. Es trägt PPP in GRE, IP-Protokoll 47, das wie ESP keine Ports hat, also braucht es in jedem NAT auf dem Weg eine eigene Sonderbehandlung — das Häkchen „PPTP passthrough“, das auf sehr vielen Heimroutern genau eine Sitzung gleichzeitig unterstützt.\nDie Sicherheit endete öffentlich 2012. Marlinspike und Hulton zeigten, dass sich die Sicherheit von MS-CHAPv2 unabhängig von der Passwortlänge auf eine einzige DES-Operation reduziert, bauten chapcrack, um den Handshake zu extrahieren, und hängten das an einen Cracking-Dienst, der den Schlüssel binnen eines Tages für zwanzig Dollar zurücklieferte — eine Erfolgsquote von 100 %, keine Wahrscheinlichkeit16. Ihr Schluss war, PPTP-Verkehr als unverschlüsselt zu betrachten. Apple stimmte mit den Füßen zu und entfernte PPTP 2016 aus dem eingebauten Client in macOS Sierra und iOS 10, und veröffentlicht die Warnung bis heute17.\nZehn Jahre danach ist PPTP immer noch ein Menüpunkt auf Routern, die dieses Jahr verkauft werden, immer noch in Hersteller-Anleitungen, immer noch das, was jemand einschaltet, weil es auf Anhieb funktioniert. Es funktioniert auf Anhieb, weil es die Aufgabe nicht erledigt.\nAlles, was sich IPsec-VPN nennt „IPsec-VPN“ ist kein Protokoll. Es ist eine Familie, und die Länge der Liste unten ist das Argument, denn keine zwei Produkte implementieren dieselbe Teilmenge davon, und in den Lücken zwischen diesen Teilmengen wohnt jede Interop-Arbeit, die du je gehasst hast.\nBestandteil Was er beiträgt Wo er steht ESP, IP-Protokoll 50 Die Verschlüsselung und Integrität selbst RFC 4303 — aktuell18 AH, IP-Protokoll 51 Integrität auch über den IP-Header RFC 4302 — durch NAT unbrauchbar2 IKEv1 Der ursprüngliche Schlüsselaustausch Abgekündigt, RFCs auf Historic gesetzt19 IKEv2 Der aktuelle Schlüsselaustausch RFC 729620 IPComp, IP-Protokoll 108 Komprimiert vor dem Verschlüsseln, mit eigenen Associations RFC 317321 PF_KEY v2 Eine Kernel-API, damit ein Daemon die Schlüssel laden kann RFC 236722 NAT-Traversal Packt ESP in UDP 4500, damit ein Übersetzer zurechtkommt RFC 3947 / 39486 TCP-Kapselung Für Netze, die auch UDP blockieren RFC 9329, ersetzt RFC 82293 IKEv2-Fragmentierung Weil der Schlüsselaustausch selbst der MTU entwachsen ist RFC 738323 MOBIKE Damit der Tunnel einen Adresswechsel überlebt RFC 455524 Dead Peer Detection Ein Herzschlag, weil es sonst nichts sagt RFC 370625 XAUTH Benutzeranmeldung — Passwort, Token, RADIUS Nie ein RFC. Abgelaufener Entwurf, 200126 Mode-Config Gibt dem Client Adresse, DNS und Routen Auch nie ein RFC26 L2TP/IPsec Trägt PPP im Tunnel RFC 2661 + RFC 319327 GRE oder VTI über IPsec Gibt dir ein routbares Interface, auf dem ein Protokoll laufen kann Herstellerarchitektur auf ESP DMVPN mGRE plus NHRP plus IPsec, damit Spokes sich finden Herstellerarchitektur, NHRP RFC 233228 GETVPN Gruppenschlüssel ganz ohne paarweisen Tunnel GDOI, RFC 640729 PPTP Das, was IPsec ersetzen sollte RFC 2637 — Informational, nie ein Standard30 Jetzt schau auf die zwei fett gesetzten Zeilen, denn die sollten dich aufhalten.\nFast zwei Jahrzehnte lang war der übliche Weg, einen Benutzer an einem Firmen-IPsec-VPN anzumelden, XAUTH — Benutzername und Passwort, dein Token, dein RADIUS-Server — mit Mode-Config, das dem Client Adresse, DNS-Server und Routen gibt. Zusammen sind sie das gesamte Fernzugriffserlebnis. Jeder „Cisco IPsec“-Client, jedes VPN-Symbol in einer Taskleiste, jede Beitrittsanleitung.\nKeines von beiden ist ein Standard. XAUTH war ein individueller Internet-Draft, der 2001 ablief und archiviert wurde, ohne je ein RFC zu werden26. Die angegebene Begründung lohnt das Lesen, denn da erklärt ein Gremium, warum es seine Arbeit nicht machen wollte: der Entwurf hält fest, dass die IPSRA-Arbeitsgruppe kein Protokoll akzeptieren würde, das ISAKMP oder IKE erweitert, und die IPsec-Arbeitsgruppe alles ablehnte, was mit Fernzugriff zu tun hatte26. Der am weitesten verbreitete Teil des am weitesten verbreiteten VPN-Protokolls blieb also heimatlos, wurde trotzdem von jedem Hersteller nach eigener Lesart eines abgelaufenen Entwurfs implementiert und an Millionen Nutzer ausgeliefert.\nIKEv2 hat am Ende beides in Ordnung gebracht, und das gehört gesagt: die Authentifizierung wanderte zu EAP und die Client-Konfigurationsnutzlasten in die Kernspezifikation20. Aber lies die Jahreszahlen. Das meistgenutzte Feature des meistgenutzten VPN-Protokolls lief rund ein Jahrzehnt auf einem abgelaufenen Entwurf, bevor es überhaupt einen Standard hatte, und die installierte Basis lief danach noch jahrelang auf der Entwurfsfassung weiter. Eine Protokollfamilie bekommt keinen Bonus dafür, den Teil irgendwann zu standardisieren, den ohnehin alle benutzten.\nDas ist die Familie, die du betreibst. Ein Teil davon ist Standards Track und aktuell. Ein Teil ist Historic. Ein Teil hat es nie zu irgendetwas gebracht. Und ein Produkt, auf dessen Datenblatt „IPsec-VPN“ steht, hat dir ungefähr nichts darüber gesagt, welche dieser achtzehn Dinge es kann — weshalb zwei davon zu verbinden vierzehn Tage, eine Tabelle voller Proposals und einen Anruf bei jemandem bedeutet, der das schon mal gemacht hat.\nDas Fisher-Price OS (Windows) hat nie wirklich zusammengearbeitet Das ist der Teil, an dem jemand sagt, das Problem sei eigentlich Linux, also machen wir es mit Quellen.\nStandardmäßig verbindet sich der Windows-Client überhaupt nicht mit einem IPsec-Server hinter NAT. Nicht „hat Mühe“. Verweigert. Die Lösung ist ein Registry-Wert namens AssumeUDPEncapsulationContextOnSendRule unter HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\PolicyAgent, auf 1 gesetzt, wenn der Server hinter einem Übersetzer sitzt, oder auf 2, wenn beide Enden dahinter sitzen, auf jedem Client und auf dem Server, gefolgt von einem Neustart31. Microsofts eigene Worte: „By default, Windows Vista and Windows Server 2008 don\u0026rsquo;t support Internet Protocol security (IPsec) network address translation (NAT) Traversal (NAT-T) security associations to servers that are located behind a NAT device.“31\nZwei Dinge dazu. Erstens hat Microsoft den NAT-Traversal-Standard, den es hier verweigert, mitverfasst. Ihr Name steht auf RFC 3947 und RFC 39486. Zweitens wurde die Seite, die dir sagt, du sollst die Registry bearbeiten, zuletzt im Februar 2026 überarbeitet31. Zwanzig Jahre später ist ein Registry-Eingriff auf jedem Endgerät immer noch die Antwort, und sie wird immer noch als Antwort gepflegt.\nUnd lies den Satz, den Microsoft direkt darüber setzt: „If you must use IPsec for communication, use public IP addresses for all servers that you can connect to from the Internet.“31\nDas ist dieser ganze Beitrag, in der Dokumentation des Herstellers. Setz IPsec nicht hinter NAT. Gib jeder Maschine eine echte Adresse. Sie haben es aufgeschrieben, und dann hat die Branche zwei Jahrzehnte das Gegenteil getan und die Differenz in Rechnung gestellt.\nBei NAT hört es nicht auf. Lies nach, was ein Open-Source-Gateway dokumentieren muss, um einen Windows-Client anzunehmen.\nDas Gateway-Zertifikat braucht eine Extended Key Usage, die es dafür und für sonst nichts gibt. serverAuth, OID 1.3.6.1.5.5.7.3.1, plus IP Security IKE Intermediate, OID 1.3.6.1.5.5.8.2.232. Deiner CA muss beigebracht werden, eine OID auszustellen, von der die meisten Werkzeuge nie gehört haben, sonst scheitert die Verbindung mit einem Richtlinienfehler und ohne brauchbare Meldung. Ein zweiter Registry-Wert ist nötig, bevor der Client anständige Kryptografie anbietet. strongSwan dokumentiert, NegotiateDH2048_AES256 unter Rasman\\Parameters hinzuzufügen, um AES-256-CBC und eine 2048-Bit-Gruppe zu bekommen33. Lies das andersherum, denn so zählt es: ohne Registry-Eingriff ist das Standardangebot schwächer als das. Vom Server angestoßenes Rekeying wird von Clients hinter NAT abgelehnt, und die dokumentierte Behelfslösung ist, Rekeying auf dem Gateway abzuschalten und den Client anfangen zu lassen33. Standard-IKEv2-Erweiterungen fehlen schlicht — keine IKE-Umleitung, keine mehrfachen Authentifizierungsrunden33. Nichts davon ist ein Linux-Fehler. Jeder einzelne Punkt ist ein Open-Source-Projekt, das aufschreibt, was es tun muss, um der Lesart eines Herstellers von einem Standard entgegenzukommen, den dieser Hersteller mitgeschrieben hat.\nDas ist das Muster, und es ist dreißig Jahre alt. PPTP war Microsofts Protokoll, als Informational aufgeschrieben und nie standardisiert30. MS-CHAPv2 und MPPE waren Microsofts Authentifizierung und Verschlüsselung, und beide wurden öffentlich gebrochen16. SSTP ist ein Microsoft-Tunnel, den sonst niemand terminiert. DirectAccess war IPsec und war konstruktionsbedingt an beiden Enden Windows — und ist inzwischen abgekündigt und wird entfernt, die Kunden werden auf Always On VPN geschoben34. Keines davon war je ein Protokoll, bei dem der Rest von uns sich in der Mitte hätte treffen können. Es war ein Protokoll, dem man beitrat, und wenn du an beiden Enden nicht das richtige Betriebssystem betrieben hast, bekamst du den Registry-Eingriff, die seltsame OID und die Behelfsseite.\nAlso sage ich es klar, es ist schließlich mein Blog. Das Fisher-Price OS (Windows) war in einem offenen Protokollstapel nie ein echter Partner auf Augenhöhe, weil es nie dafür gedacht war. Es versteckt die Maschine vor der Person, die sie benutzt, und zwar als Entwurfsziel, und einen Stapel, den man nicht sehen kann, kann man nicht interoperabel machen. Wenn das das einzige Betriebssystem ist, das du je administriert hast, werden die Abschnitte oben über Kernel-Zähler und das Mitlesen auf der Leitung wie eine Fremdsprache geklungen haben, und genau das ist die Lücke — keine Vorliebe, eine Lücke.\nNichts davon muss den Leser etwas kosten. Jede Diagnose in diesem Beitrag läuft von jedem Unix im Netz aus, gerichtet auf das, was kaputt ist, und es ist ihr völlig gleich, was am anderen Ende läuft. Und wenn dieses Betriebssystem das einzige ist, das du hast, dann trägt der Diagnoseteil weiter unten auch die Werkzeuge dafür — die Aufzeichnung, die zwei Cmdlets und die Fehlercodes mit dem, was jeder davon wirklich sagt. Ein kaputter Tunnel muss am Montag trotzdem repariert werden. Und der Ersatz, für den ich am Ende argumentiere, hat dann einen Client, der sich auf jeder Plattform gleich verhält, diese eingeschlossen — zum ersten Mal seit dreißig Jahren gilt das für ein VPN.\nDie Abkündigungsbilanz liest sich wie ein Nachruf Leg die Behelfslösungen beiseite und lies einfach, was die Standardisierungsgremien dieser Familie über die Jahre angetan haben. Keine Meinung. Anforderungsstufen, in veröffentlichten RFCs.\nWas Wo es heute steht Quelle IKEv1 Abgekündigt; RFC 2407, 2408 und 2409 auf Historic gesetzt RFC 9395, 202319 DES in ESP MUST NOT RFC 82218 3DES in ESP SHOULD NOT RFC 82218 HMAC-MD5-96 MUST NOT RFC 82218 ESP zusammen mit AH NOT RECOMMENDED RFC 82218 ESP nur mit Verschlüsselung Als unsicher gezeigt und 2007 praktisch gebrochen Degabriele und Paterson35 IPsec auf einem IPv6-Knoten Von MUST auf SHOULD herabgestuft RFC 6434, 201136 PPTP Nie ein Standard; nur Informational RFC 263730 Die vorletzte Zeile ist die, die ich jedem vorlegen würde, der mir erzählt, IPsec sei in Ordnung und das Netz sei das Problem. IPv6 hat IPsec ursprünglich vorgeschrieben — es war die Sicherheitsgeschichte, festgeschrieben in den Node Requirements. 2011 hat die IETF es sich anders überlegt: „Previously, IPv6 mandated implementation of IPsec and recommended the key management approach of IKE. This document updates that recommendation by making support of the IPsec Architecture a SHOULD for all IPv6 nodes.“36\nSogar die Adressfamilie, die IPsec alles zurückgegeben hätte, was NAT ihm genommen hat, hat vor fünfzehn Jahren aufgehört, es zu verlangen. Das ist nicht das Netz, das IPsec im Stich lässt. Das sind die Leute, die das Netz entworfen haben, und die entschieden haben, dass es sich das Gebot nicht verdient hat.\nDie Komplexität wurde 1999 angemerkt, schriftlich Nichts davon ist Nachsicht im Rückblick, und genau das macht es aufschreibenswert.\n1999 wurden Niels Ferguson und Bruce Schneier beauftragt, IPsec zu bewerten. Ihr Bericht ist kurz, klar und lohnt sich ganz. Er beginnt mit „IPsec was a great disappointment to us. Given the quality of the people that worked on it and the time that was spent on it, we expected a much better result.“37 Er benennt die Ursache: „Our main criticism of IPsec is its complexity. IPsec contains too many options and too much flexibility; there are often several ways of doing the same or similar things. This is a typical committee effect.“37\nUnd er machte drei Empfehlungen, die sich heute wie eine Liste von Dingen lesen, die ohnehin passiert sind, zwanzig Jahre zu spät und auf die harte Tour:\nTransportmodus abschaffen. „We therefore recommend that transport mode be eliminated.“37 Der Transportmodus ist der Modus, den L2TP/IPsec benutzt, und der Modus, dem NAT am schlimmsten zusetzt. AH abschaffen. „We conclude that eliminating transport mode allows the elimination of the AH protocol as well, without loss of functionality.“37 Abgeschafft hat es stattdessen NAT, aus einem schlechteren Grund. Niemals Verschlüsselung ohne Authentifizierung zulassen. Sie warnten, Administratoren würden „will be quite likely to configure ESP for only encryption, believing that it provides security“ — ESP sehr wahrscheinlich nur auf Verschlüsselung stellen, im Glauben, das biete Sicherheit37. Acht Jahre später hörte der letzte Punkt auf, eine Warnung zu sein. Degabriele und Paterson veröffentlichten Angriffe, die „break any RFC-compliant implementation of IPsec making use of encryption-only ESP“ — jede RFC-konforme Implementierung brechen, die ESP nur mit Verschlüsselung nutzt, allein aus dem Chiffretext, und es braucht nicht mehr, als Verkehr mitzulesen und Pakete einzuspeisen35. Die Vorhersage stand acht Jahre lang öffentlich im Raum, und der Standard erlaubte die Konfiguration weiterhin.\nDas Urteil aus jenem Bericht von 1999 ist der Satz, zu dem ich immer wieder zurückkomme: „We have found serious security weaknesses in all major components of IPsec. As always in security, there is no prize for getting 90% right; you have to get everything right.“37\nNoch zwei Datenpunkte, dann lasse ich es gut sein.\nLogjam, 2015. Das Team dahinter scannte eine 1-%-Stichprobe von IPv4 nach IKE und fand, dass 86,1 % der IKEv1- und 91,0 % der IKEv2-Server die 1024-Bit-Oakley-Gruppe 2 unterstützten und dass 66,1 % der profilierten IKEv1-Server sie bevorzugten. Ihr Schluss: eine Vorberechnung gegen eine zweite 1024-Bit-Gruppe „would allow decryption of traffic to 66% of IPsec VPNs“, und die veröffentlichten Geheimdienstunterlagen zur VPN-Ausnutzung seien „consistent with having achieved such a break“38. Kryptografische Agilität, wovon IPsec am meisten hat, ist der Grund, warum fast alle fünfzehn Jahre lang auf derselben schwachen Gruppe saßen.\nCVE-2016-1287. Ein Pufferüberlauf im IKEv1- und IKEv2-Code auf Cisco ASA, erreichbar durch das Senden präparierter UDP-Pakete, mit Codeausführung aus der Ferne vor der Authentifizierung39. Denk daran, wo diese Box steht. Es ist das Gerät, das du absichtlich dem ganzen Internet ausgesetzt hast, auf dem das optionsreichste Protokoll im Bestand läuft, mit einem Fragment-Reassembler vor dem Parser, und das die Schlüssel zu allem dahinter hält. Die Komplexität, vor der Ferguson und Schneier gewarnt haben, ist keine Abstraktion. Sie ist Angriffsfläche, auf der einen Maschine, die du hinter nichts stellen kannst.\nDiagnose, solange du es noch betreibst Du kannst das alles nicht heute Nachmittag abschalten, also hier, wie man daran arbeitet. Das ist die Methode, in der Reihenfolge, die am wenigsten kostet, mit dem, was jedes Ergebnis tatsächlich bedeutet.\nSechs Arten aufzugeben, jeweils an der Stelle im Pfad, an der sie passieren Wo jeder Fehler wirklich sitzt Client Policy und Routen Heimrouter Übersetzung eins Carrier Übersetzung zwei Das Internet Filter und MTU Gateway Selectors und Identität 1 2 3 4 5 6 1 Gar nichts auf der Leitung. Der Verkehr hat IPsec nie erreicht. Such nicht bei der Krypto. ip xfrm policy und die Route, und was die Host-Firewall tut. 2 Port 500 beidseitig, 4500 nie. NAT-Traversal wurde nicht ausgehandelt. tcpdump -ni eth0 'udp port 500 or udp port 4500 or ip proto 50' Nacktes ESP überlebt das nicht. 3 Stirbt nach Leerlauf, lebt bei Nutzung auf. Ein Mapping ist bei einem der zwei Übersetzer abgelaufen. Dein Keepalive verliert gegen einen Timer, den du nicht liest. Kürze es und trau der Vorgabe nicht. 4 Ausgangszähler steigt, Eingang flach. ESP stirbt unterwegs in einer Richtung. ip -s xfrm state an beiden Enden, dann finde den Hop, der es frisst. 5 Anmelden geht, große Übertragungen hängen. Pfad-MTU, und die ICMP-Fehler kommen nicht zurück. ping -M do -s 1400 schrittweise kleiner, dann Segmentgröße klemmen und die ICMP-Regel richten. 6 Beide Enden sagen up, nichts geht durch. Traffic Selectors, Policy oder Routing \u0026#8212; nicht die Schlüssel. Und hat ein zweiter Nutzer den ersten rausgeworfen, ist es die Peer-Identität, nicht die Kapazität. Eine Aufzeichnung an der Grenze, dreißig Sekunden, beantwortet die ersten drei. Das zuerst, nicht die Konsolen. Die sechs Fehler in der Reihenfolge, in der man auf sie prüft, mit Symptom, Prüfung und Bedeutung der Antwort. Jede Zeile ist eine andere Schicht des Stapels, die aufgibt, und die ersten drei beantwortet ein dreißig Sekunden langer Blick auf die Leitung — deshalb ist das das Erste, was man tut, und nicht das Letzte. Schau zuerst auf die Leitung, nicht auf die Konsole Beide Konsolen sagen dir, was sie glauben. Die Leitung sagt dir, was passiert ist. Eine Aufzeichnung an der Grenze, dreißig Sekunden, beantwortet die ersten drei Fragen auf einmal:\ntcpdump -ni eth0 \u0026#39;udp port 500 or udp port 4500 or ip proto 50 or ip6 proto 50\u0026#39; Überhaupt nichts ausgehend — das Problem liegt vor IPsec: Routing, Policy oder eine Host-Firewall. Hör auf, bei der Kryptografie zu suchen. Nur ausgehend, nichts zurück — deine Pakete gehen raus und ihre Antworten kommen nicht an. Filterung unterwegs, ein toter Peer, oder die Gegenstelle weist stillschweigend ab. UDP 500 in beide Richtungen, 4500 taucht nie auf — NAT-Traversal wurde nicht ausgehandelt. Entweder hat es ein Ende abgeschaltet oder die Erkennung ist fehlgeschlagen. Protokoll 50 auf der Leitung, während ein Ende hinter NAT sitzt — die Aushandlung hat entschieden, es gäbe keinen Übersetzer, obwohl es einen gibt. Das kommt nie zurück. Den Fehler beim Schlüsselaustausch lesen IKEv2 sagt dir, warum es abgelehnt hat, und die Notify-Namen sind spezifisch genug, um allein daraus zu diagnostizieren. Es hilft, vorher die Form des ganzen Austauschs vor Augen zu haben, denn jede Notify unten gehört zu einer bestimmten Sprosse davon.\nDer IKEv2-Austausch Schritt für Schritt, und welcher Fehler auf welchem Schritt sitzt Jeder Schritt des Austauschs, und der Fehler, der darauf sitzt Client hinter einem Übersetzer Gateway echte Adresse Was hier scheitert IKE_SA_INIT-Anfrage \u0026#8212; UDP 500 keine Antwort \u0026#8212; 809 ERROR_VPN_TIMEOUT IKE_SA_INIT-Antwort \u0026#8212; UDP 500 NO_PROPOSAL_CHOSEN, INVALID_KE_PAYLOAD NAT erkannt, beide Enden wechseln auf 4500 kein Wechsel \u0026#8212; Proto 50 stirbt am Übersetzer IKE_AUTH \u0026#8212; UDP 4500, verschlüsselt zu groß, Fragment weg, Neusendung, Timeout IKE_AUTH-Antwort \u0026#8212; CHILD_SA angelegt AUTHENTICATION_FAILED \u0026#8212; 13801, 13806 ESP in UDP 4500 \u0026#8212; dein Verkehr TS_UNACCEPTABLE \u0026#8212; up, und nichts bewegt sich Keepalive \u0026#8212; 1 Byte alle 20 s, für immer kein Keepalive \u0026#8212; Eintrag läuft im Leerlauf ab Der Portwechsel ist der Angelpunkt. Darüber ist alles UDP 500. Darunter ist alles UDP 4500. Findet der Wechsel nie statt, schickst du Protokoll 50 in einen Übersetzer, der nichts umzuschreiben hat, und es kommt nie zurück. Der Größenfehler sitzt auf genau einer Sprosse. IKE_AUTH trägt die Zertifikatskette und ist damit die einzige große Nachricht hier. Ein Pre-Shared Key, der sich verbindet, wo ein Zertifikat es nicht tut, ist ein verlorenes Fragment, kein schlechtes Zertifikat. Angelegt ist nicht dasselbe wie funktionierend. Die Child-Association kann bestehen und trotzdem nichts tragen, wenn die Enden uneins sind, welchen Verkehr sie deckt. Jeder Fehler in der rechten Spalte wird am Client als Timeout gemeldet, was immer es wirklich war. Der Austausch vom ersten Paket bis zum eingeschwungenen Zustand, mit dem Fehler, der auf jedem Schritt sitzt. Der Wechsel von 500 auf 4500 ist der Angelpunkt: darüber ist alles ein Port, darunter ein anderer, und findet der Wechsel nie statt, steckst du Protokoll 50 in einen Übersetzer, der es nicht tragen kann. IKE_AUTH ist hier die einzige große Nachricht, und genau darum kann ein Pre-Shared Key sich verbinden, wo ein Zertifikat es nicht tut — das ist ein verlorenes Fragment, kein schlechtes Zertifikat. Notify Was es tatsächlich heißt Wo du nachsiehst NO_PROPOSAL_CHOSEN Keine der angebotenen Kombinationen aus Chiffre/Integrität/DH/PRF ist der Gegenstelle genehm Beide Proposal-Listen; erwarte auf einer Seite einen abgekündigten Algorithmus INVALID_KE_PAYLOAD Diffie-Hellman-Gruppe passt nicht — du hast eine Gruppe angeboten, sie will eine andere Die DH-Gruppe, das Erste im Proposal AUTHENTICATION_FAILED Schlüssel, Zertifikat oder Identität falsch — ein abweichender Pre-Shared Key, ein abgelaufenes Zertifikat oder eine ID, die der Peer nicht erwartet Die Identität, nicht nur das Geheimnis TS_UNACCEPTABLE Die Traffic Selectors überschneiden sich nicht — du wolltest Subnetze schützen, die der Peer nicht schützt Die Selector-Konfiguration beider Enden INVALID_SPI Ein Paket kam für eine Association an, die es nicht mehr gibt, meist nach einem einseitigen Neustart Ob ein Ende neu geschlüsselt hat oder neu gestartet ist Junipers Phase-2-Anleitung sagt zum häufigsten davon dasselbe: „no proposal chosen“ heißt „the device did not accept any of the IKE Phase 2 proposals that the peer sent“, und die Lösung ist ein beiderseits akzeptables Proposal und kein wiederholter Neustart40.\nAuf strongSwan der Zustand von allem in einem Befehl:\nswanctl --list-sas # what is established, and what it negotiated swanctl --log # the negotiation as it happens Auf Cisco show crypto ikev2 sa und show crypto ipsec sa, mit debug crypto ikev2, wenn es nicht hochkommt41. Auf Junos show security ike security-associations und show security ipsec security-associations, mit der Aushandlung in show log kmd-logs42.\nWurde NAT-Traversal überhaupt ausgehandelt? Das ist die Prüfung, die die Leute überspringen, und sie erklärt einen großen Teil von „aus dem Büro geht es, von zu Hause nicht“.\nJedes Ende schickt Hashes der Adressen und Ports, die es für beteiligt hält. Passt der Hash, den die Gegenstelle aus dem empfangenen Paket berechnet, nicht zu dem, den du geschickt hast, liegt ein Übersetzer dazwischen, und beide Enden wechseln auf UDP 4500. Scheitert die Erkennung — eine Seite hat Traversal abgeschaltet, oder etwas in der Mitte verstümmelt den Austausch —, machen beide Enden mit nacktem ESP weiter, das den Übersetzer nicht überlebt.\nAlso: sieh Port 4500 in der Aufzeichnung, aus beiden Richtungen, oder es findet kein Traversal statt. Verlass dich nicht auf das Wort der Konsole.\nPrüf dann, ob der Keepalive tatsächlich läuft und sein Intervall unter dem liegt, bei dem dein Carrier Mappings altern lässt. Die Vorgabe sind zwanzig Sekunden6; die Untergrenze des Standards für NAT-Betreiber sind zwei Minuten9; was dein konkreter Carrier macht, siehst du nicht. Stirbt der Tunnel nach Leerlauf und lebt bei Verkehr wieder auf, ist das jedes Mal dein Fall.\nDie Kernel-Zähler, die fast niemand liest Unter Linux führt die Transform-Schicht eine vollständige Fehleraufschlüsselung, und das ist der schnellste Weg, aus „es geht nicht“ eine konkrete Ursache zu machen. Die Zähler sind vom Kernel selbst dokumentiert43.\ncat /proc/net/xfrm_stat # error counters, by cause ip -s xfrm state # per-SA packet and byte counters ip xfrm policy # what should be protected, and in which direction Als Weg liest es sich besser denn als Liste. Das Paket durchläuft fünf Stufen, und jede hat ihren eigenen Zähler:\nFünf Stufen, und der Zähler, der die nennt, auf der dein Paket gestorben ist Folge einem Paket, und lass den Zähler die Stufe nennen, auf der es starb Deine Policy wird dieser Verkehr geschützt? XfrmOutPolBlock du verwirfst es selbst, absichtlich, in der Policy Deine Association verschlüsseln, versiegeln, nummerieren XfrmOutNoStates Policy hat gegriffen, keine Association trägt es Der Pfad Übersetzer, MTU, Filter nichts zählt hoch, an keinem Ende hier leben NAT, MTU und Filterung, und kein Zähler sieht irgendetwas davon Ihre Association Ziel + Protokoll + SPI XfrmInNoStates \u0026#183; XfrmInStateProtoError \u0026#183; XfrmInStateSeqError es kam an und die Kryptografie ging nicht auf: falscher SPI, falscher Schlüssel, außer Fenster Ihre Policy sollte das geschützt sein? XfrmInTmplMismatch \u0026#183; XfrmInNoPols die Kryptografie war gut, die Policy war anderer Meinung, ob sie es sein sollte Stufe drei ist die ohne Zähler. Alles, was ein Vierteljahrhundert Übersetzung diesem Protokoll angetan hat, passiert dort, und die Transform-Schicht sieht an keinem Ende ein einziges Paket davon. Genau darum kommt die Aufzeichnung vor der Konsole. Stufe vier und fünf sind gegensätzliche Fehler. Vier heißt, die Kryptografie ging nicht auf. Fünf heißt, sie ging auf, und etwas war anderer Meinung, ob sie es sollte. Fast jedes Mal wird in der falschen Reihenfolge geschaut, weil fünf wie ein Kryptofehler aussieht und keiner ist. Die Zählernamen sind Linux. Unter Junos liest man dieselben Stufen aus show security ipsec statistics; auf dem Fisher-Price OS (Windows) aus Get-NetIPsecQuickModeSA und dem Protokoll der Windows-Firewall mit erweiterter Sicherheit. Fünf Stufen, und der Zähler, der die nennt, auf der dein Paket gestorben ist. Stufe drei ist die einzige ganz ohne Zähler — dort leben der Übersetzer, die MTU und jeder Filter dazwischen, und die Transform-Schicht sieht an keinem Ende ein einziges Paket davon. Das ist das ganze Argument dafür, zuerst zur Aufzeichnung und dann zur Konsole zu greifen. Stufe vier und fünf sind gegensätzliche Fehler und werden fast jedes Mal in der falschen Reihenfolge betrachtet. Beobachte, welcher sich bewegt, während der Fehler auftritt:\nZähler Beschreibung des Kernels Was es am Tag bedeutet XfrmInNoStates „No state is found i.e. Either inbound SPI, address, or IPsec protocol at SA is wrong“ Ihre Pakete kommen für eine Association an, die du nicht hast — meist ein einseitiges Rekeying oder ein Neustart XfrmInStateSeqError „Sequence error i.e. Sequence number is out of window“ Umordnung oder Ärger mit dem Replay-Fenster; siehe das QoS-Zusammenspiel oben XfrmInStateProtoError „Transformation protocol specific error e.g. SA key is wrong“ Die Schlüssel weichen ab — die Association hat ein Rekeying nur auf einer Seite überlebt XfrmInTmplMismatch „No matching template for states e.g. Inbound SAs are correct but SP rule is wrong“ Die Association stimmt und die Policy nicht XfrmInNoPols „No policy is found for states e.g. Inbound SAs are correct but no SP is found“ Geschützter Verkehr kommt an, um dessen Schutz niemand gebeten hat XfrmOutPolBlock „Policy discards“ Du verwirfst es selbst, absichtlich, in der Policy XfrmOutNoStates „No state is found“ Verkehr traf auf eine Policy ohne Association, die ihn tragen könnte — der Tunnel kam nie hoch XfrmInTmplMismatch und XfrmInNoPols sind die zwei, die man vom Sehen kennen sollte, denn beide heißen, dass die Kryptografie stimmt und die Policy nicht — also das Gegenteil von dem, wo alle zuerst suchen.\nEs sagt „up“ und nichts bewegt sich Beide Enden aufgebaut, kein Verkehr. Lies die Zähler je Association in beide Richtungen:\nip -s xfrm state Ausgehende Bytes steigen, eingehende flach — du verschlüsselst und sendest, und es kommt nichts zurück. Entweder erreicht dein ESP sie nicht oder ihres erreicht dich nicht. Frag die Gegenstelle nach ihrem Ausgangszähler; steigt der auch, sterben die Pakete unterwegs, und die nächste Frage lautet wo, und das ist eine TTL-Frage und keine Krypto-Frage. Beide flach — dem Tunnel wird nichts angeboten. Routing oder Policy, nicht IPsec. Bei route-based prüf, ob die Route wirklich auf das Tunnelinterface zeigt; bei policy-based prüf die Selectors. Beide steigen, Anwendungen weiter kaputt — es ist nicht der Tunnel. Geh und schau, was auf der anderen Seite steht. Junipers Hinweis für diesen Fall folgt demselben Instinkt in ihrer Sprache: steigt nur der ausgehende Paketzähler der Sitzung, kläre mit dem Peer, ob der Verkehr überhaupt ankommt44.\nKleines geht, Großes hängt MTU. Es ist immer die MTU. Der Test dauert zehn Sekunden:\nping -M do -s 1400 10.0.0.1 # inside the tunnel, do-not-fragment set ping -M do -s 1300 10.0.0.1 # step down until it succeeds Wo es anfängt zu klappen, sagt dir die tatsächlich nutzbare Größe. Lass TCP es dann selbst herausfinden, indem du die angekündigte Segmentgröße auf den Pfad klemmst, statt zu hoffen, dass jeder ICMP-Fehler die Reise übersteht:\nnft add rule inet filter forward tcp flags syn tcp option maxseg size set rt mtu Und beheb auch die Ursache, und das ist fast immer eine zu breite ICMP-Regel an irgendeiner Grenze. Verwirf Echo, wenn du willst. Ich habe anderswo dafür argumentiert, dass es das verdient. Aber behalte Fragmentation Needed und Packet Too Big. Sie sind der Mechanismus, keine Nettigkeit.\nEs fällt im Takt aus Nimm die Zeit zwischen den Ausfällen. Das Intervall benennt die Ursache von allein.\nEin fester Zeitraum, der zu einer konfigurierten Lifetime passt — Rekeying. Die Association läuft ab und die Ersatzaushandlung scheitert oder läuft in ein Rennen. Prüf die Lifetimes beider Enden; abweichende Werte sind normal und in Ordnung, aber eine harte Lifetime auf einem Ende, die kürzer ist als die weiche des anderen, erzeugt genau das. Nach einer Weile ohne Verkehr, zurück bei der ersten Nutzung — ein NAT-Mapping ist abgelaufen. Keepalive-Intervall, oder das Fehlen eines solchen. Dead Peer Detection reißt ihn ab, während die Strecke in Ordnung ist — die Proben gehen verloren, statt dass der Peer tot wäre, oft weil die Proben der einzige Verkehr sind und das Mapping längst weg ist. Der zweite Benutzer wirft den ersten raus Zwei Peers erreichen den Konzentrator von einer Adresse und authentifizieren sich als dieselbe Identität. Das Gateway hat die Wahl zwischen der alten Association festhalten und ersetzen, und eine verbreitete Vorgabe ist ersetzen. Also gewinnt die zweite Verbindung und die erste stirbt stillschweigend.\nGib jedem Peer eine wirklich eindeutige Identität statt einer Adresse oder eines gemeinsamen Namens, und stell das Gateway so ein, dass es mehrere Associations von einer Adresse behält, statt eine je Peer anzunehmen. Und dann teste es auf die einzige Weise, die zählt: zwei Clients, eine Adresse, gleichzeitig. Wenn in deinem Abnahmetest nie zwei Nutzer hinter einem NAT saßen, hast du genau den Fall nicht getestet, in dem die meisten deiner Nutzer sind.\nDieselben Fehler, auf dem Fisher-Price OS (Windows) Jede Prüfung oben läuft von einer Unix-Kiste aus, und wenn du eine in dem Netz hast, dann nimm sie, weil sie dir die Wahrheit schneller sagt und es ihr egal ist, was am anderen Ende läuft. Aber viele Leser haben einen Client, der sich nicht verbindet, ein Betriebssystem, das ihnen die Maschine absichtlich verbirgt, und sonst nichts zum Hinschauen. Also hier dieselbe Methode noch einmal, in derselben Reihenfolge, mit den Werkzeugen, die dieses Betriebssystem tatsächlich mitbringt.\nSchau auf die Leitung. Es gibt kein tcpdump, aber es gibt eine Aufzeichnung. Erhöht starten, den Fehler nachstellen, stoppen:\nnetsh wfp capture start cab=on file=ipsec netsh wfp capture stop Das schreibt eine .cab. Darin steckt die Spur davon, was die Filterplattform und der Schlüsselaustausch währenddessen wirklich getan haben, und das ist mehr, als dir beide Konsolen zugeben. Für den Blick in Echtzeit statt eines Archivs schreibt dieselbe Befehlsfamilie mit file=- auf die Konsole: netsh wfp show state „Displays the current state of WFP and IPsec“, und netsh wfp show ikeevents „Displays recent Internet Key Exchange (IKE) epoch events matching the specified parameters“, gefiltert auf einen Peer45.\nnetsh wfp show state file=- netsh wfp show ikeevents remoteaddr=203.0.113.5 file=- show ikeevents ist hier das Nächste an dem Austauschprotokoll, das jeder andere Stack ungefragt schreibt. Gut zu wissen, dass es das gibt. Sonst reicht dir die Oberfläche eine dreistellige Zahl und sonst nichts, und du diagnostizierst einen Schlüsselaustausch durch Raten.\nLies die Associations, und zwar beide. Die Entsprechungen von ip -s xfrm state und swanctl --list-sas sind zwei Cmdlets, und die Trennung dazwischen ist die ganze Diagnose:\nGet-NetIPsecMainModeSA Get-NetIPsecQuickModeSA Main Mode ist der Schlüsselaustausch. Quick Mode trägt die Pakete. Microsoft sagt das Verhältnis deutlich: „There is only one main mode SA between a pair of computers, but there can be many quick mode SAs“46. Main Mode vorhanden und Quick Mode leer ist also derselbe Fehler wie eine stehende IKE_SA ohne CHILD_SA darunter, und er bedeutet dasselbe: Die beiden Enden haben sich geeinigt, wie geredet wird, und sich dann nicht geeinigt, was geschützt wird. Schau auf die Traffic Selectors, nicht auf die Verfahren.\nLies die Protokolle, an den zwei Stellen, wo sie sich verstecken. Verbindungsfehler landen im Anwendungsprotokoll unter der Quelle RasClient, und Microsofts eigener Hinweis dazu ist der nützliche Teil: „All error messages return the error code at the end of the message“47. Diese Zahl ist die Diagnose, und der nächste Abschnitt sagt dir, was die Zahlen bedeuten. Richtlinien- und Filterentscheidungen landen ganz woanders, unter Anwendungs- und Dienstprotokolle, in den Kanälen von Windows-Firewall mit erweiterter Sicherheit. Zwei Protokolle, zwei Teams, ein Fehler.\nSammle es richtig, wenn du eskalieren musst. Das unterstützte Bündel ist TSS — TSS.ps1 -Scenario NET_VPN auf dem Client, TSS.ps1 -Scenario NET_RAS auf dem Server, gestartet bevor du den Fehler nachstellst, und danach gestoppt48. Lern es, bevor jemand danach fragt.\nWenn es auf Verbinden stehen bleibt und dann abläuft Das ist der Fehler, der die Tickets füllt, und das Wort in der Meldung ist gelogen. Fang mit dem Code an. Der Code ist genau, auch wenn die Meldung nichts taugt.\nEin Verbindungs-Timeout ist eines von drei Dingen, und keines davon ist eine Uhr Was der Client Timeout nennt, und was es wirklich war Der Client sagt: Zeit abgelaufen 809, 718, 828, 930, 638 \u0026#8212; fünf Codes, ein Wort, und keiner davon ist eine Uhr Es ist eines von drei Dingen, und ein Test sagt dir, welches Es kam nichts an der Fall Stille Test: am Client aufzeichnen \u0026#8212; geht UDP 500 raus und kommt nichts zurück? Filterung im Pfad, oder NAT-Traversal nie ausgehandelt, also wurde 4500 nie gesendet. Kam an, zu groß der Fall Fragment Test: verbindet ein Pre-Shared Key, wo ein Zertifikat es nicht tut? IKE_AUTH trägt die Kette, fragmentiert deshalb, und das Fragment wird im Pfad verworfen. Nie der Tunnel der Fall falsche Schicht Test: protokolliert das Gateway in derselben Sekunde einen Authentifizierungsfehler? 930 ist RADIUS. 812 ist das Authentifizierungsverfahren. 13801 und 13806 sind Zertifikate. Keines der drei ist ein Timer. Den Timeout zu verlängern ist das Einzige, wozu die Oberfläche dich einlädt, und das Einzige, was noch nie eines davon behoben hat. Das Wort steht da, weil die meldende Schicht nicht weit genug sieht, um mehr zu sagen. Teste in dieser Reihenfolge. Der erste kostet dreißig Sekunden Aufzeichnung, der zweite einen Verbindungsversuch, der dritte ein Protokoll. Fünf Fehlercodes tragen das Wort Timeout, und keiner davon ist eine Uhr. Es ist eines von drei Dingen, und ein einziger Test trennt sie: eine Aufzeichnung sagt, ob überhaupt etwas zurückkam, ein Verbindungsversuch mit Pre-Shared Key sagt, ob der Zertifikatsaustausch schlicht zu groß zum Ankommen war, und das Protokoll des Gateways sagt, ob der Tunnel je das Problem war. Teste in dieser Reihenfolge, denn das ist auch die Reihenfolge der Kosten. Code Name in raserror.h Was wirklich passiert ist 809 ERROR_VPN_TIMEOUT Es kam überhaupt nichts zurück. Microsofts angegebene Ursache: „the UDP 500 or 4500 ports on the VPN server or firewall are blocked“47 — aber blocked deckt drei verschiedene Dinge ab, und nur eines davon ist eine Verbotsregel. Meistens wurde 4500 nie gesendet, weil NAT-Traversal nie ausgehandelt wurde, oder der Helfer, der es früher getragen hat, ist abgeschaltet. Lies weiter, bevor du eine Firewall-Änderung beantragst 789 ERROR_OAKLEY_GENERAL_PROCESSING „The L2TP connection attempt failed because the security layer encountered a processing error during initial negotiations“ — Anmeldedaten oder Zertifikate, nicht das Netz 718 ERROR_PPP_TIMEOUT Der IPsec-Teil hat funktioniert. PPP im L2TP-Tunnel bekam keine Antwort 828 ERROR_IDLE_TIMEOUT „The connection was terminated because of idle timeout“ — eine Einstellung auf der Serverseite, absichtlich 930 ERROR_AUTH_SERVER_TIMEOUT RADIUS hat nicht rechtzeitig geantwortet. Hat mit IPsec nicht das Geringste zu tun 638 ERROR_REQUEST_TIMEOUT Der allgemeine. Behandle ihn als keine Information und geh auf die Leitung Jeder davon stammt aus Microsofts eigener Fehlerliste49. Jetzt lies 809 noch einmal. Er heißt ERROR_VPN_TIMEOUT, und die dokumentierte Ursache ist ein blockierter Port. Der Client läuft nicht ab, weil die Gegenstelle langsam ist. Er läuft ab, weil die Gegenstelle stumm ist, und Stille ist die einzige Fehlerart, die ein Protokoll ohne Ports und ohne sichtbaren Handshake melden kann.\nSei mit dem Wort blocked aber vorsichtig, denn es trägt mehr, als es kann. Drei verschiedene Dinge tragen es, und nur eines davon ist eine Verbotsregel.\nEs hat nie jemand 4500 gesendet. NAT-Traversal wurde nicht ausgehandelt, also hat der Client weiter ESP gesprochen, und ESP gibt einem Übersetzer nichts zum Umschreiben. Die Voreinstellung auf dieser Plattform reicht dafür schon allein: Ohne den Registry-Wert bildet sie überhaupt keine NAT-T-Association zu einem Server hinter einem Übersetzer31. 4500 ist also nicht blockiert. Es wurde nie versucht.\nDer Helfer, der das früher übertüncht hat, ist abgeschaltet. Firewalls und Heimrouter tragen protokollweise Helfer — IPsec-Passthrough auf Endkundengeräten und die ganze Familie der Application-Layer-Gateways dahinter —, die ein Protokoll lesen, das NAT nicht behandeln kann, und den Rückweg dafür öffnen. Unter Linux wurde die automatische Form davon ab Kernel 4.7 standardmäßig „for security reasons“ abgeschaltet, und die Empfehlung seither lautet, einen Helfer bewusst per Regel anzuhängen oder gar nicht; zu den abgedeckten Helfern gehört der für PPTP50.\nUnd sie abzuschalten war richtig. Ein Helfer ist ein Stück deiner Firewall, das eine Nutzlast liest und dann anhand des Gelesenen ein Loch schlägt. NAT Slipstreaming ist die Rechnung dafür: ein Browser, der eine Seite aufruft, Verkehr so geformt, dass der SIP- oder H.323-Helfer des Routers ihn als Anruf liest, und ein Loch durch das NAT — in der Fassung von 2021 auf jede interne Adresse, nicht nur auf die Maschine, die die Seite geladen hat51. Helfer abzuschalten schließt das. Es bringt auch dein IPsec zum Erliegen. Beides stimmt gleichzeitig, und das Zweite ist kein Argument dafür, das Erste rückgängig zu machen.\nUnd das ist wieder dieser Beitrag im Kleinen. Das Protokoll hat nur funktioniert, weil Kästen in der Mitte Verkehr gelesen haben, der sie nichts anging, und in seinem Namen Löcher geöffnet haben, und die Branche hat im letzten Jahrzehnt völlig zu Recht beschlossen, damit aufzuhören.\nArbeite die Ursachen also in dieser Reihenfolge ab, das Billigste zuerst.\nErstens: Es kommt nichts zurück. Zeichne am Client auf, oder frag das Gateway. Wenn UDP 500 rausgeht und nichts zurückkommt, ist es Filterung oder Erreichbarkeit, und kein Timer der Welt behebt das. Wenn 500 in beide Richtungen durchgeht und 4500 nie auftaucht, wurde NAT-Traversal nicht ausgehandelt. Und wenn eines der beiden Enden hinter einem Übersetzer sitzt, bist du wieder bei dem Registry-Wert von weiter oben: AssumeUDPEncapsulationContextOnSendRule, 1 oder 2, auf beiden Maschinen, dann ein Neustart31. Ohne ihn verweigert der Client planmäßig und meldet es als Timeout.\nZweitens: Die Antwort ist zu groß, um anzukommen. Das hier kostet ganze Nachmittage. Zertifikatsanmeldung macht den zweiten Austausch groß, weil er eine Kette trägt, und ein großer Austausch fragmentiert. Die Fragmente werden von denselben Mittelkästen verworfen wie alles andere in diesem Beitrag, der Client sendet in dasselbe Loch nach, und dann gibt er auf und sagt Timeout. Das Anzeichen ist für sich genommen schon die Diagnose: ein Pre-Shared Key verbindet sich und ein Zertifikat nicht. Das ist kein Zertifikatsfehler. Das ist ein Größenfehler, weil der Austausch mit Pre-Shared Key klein genug ist, um zu passen. Genau dafür gibt es die standardisierte IKEv2-Fragmentierung23, und strongSwan hält fest, wann diese Plattform sie bekommen hat: „IKEv2 fragmentation is supported since the v1803 release of Windows 10 and Windows Server“33. Alles Ältere, oder ein Gateway mit abgeschalteter Fragmentierung, und du verlässt dich auf einen Pfad, der ein fragmentiertes UDP-Datagramm trägt. Viele tun das nicht.\nDrittens: Es verbindet sich und fällt dann im Takt aus. Nimm die Zeit. Stirbt es nach einer festen Leerlaufzeit, ist das 828 und es ist Konfiguration, kein Fehler — -IdleDisconnectSeconds auf dem Server, dazu -SALifeTimeSeconds, -MMSALifeTimeSeconds und -SADataSizeForRenegotiationKilobytes als die drei weiteren Uhren, die eine Sitzung beenden können52. Die letzte beendet sie nach Menge statt nach Zeit, und deshalb kann eine Sitzung bei einer großen Dateikopie zuverlässig sterben und an einem ganzen Tag E-Mail nie. Und stirbt sie beim Rekeying mit dem Client hinter NAT, ist das der dokumentierte Interop-Fehler von weiter oben: Der Client lehnt ein vom Server begonnenes Rekeying mit dem Microsoft-Fehler 13863 ab, und die Antwort auf der Gateway-Seite ist, es nicht mehr selbst zu beginnen und den Client machen zu lassen33.\nViertens: Es ist gar nicht der Tunnel. 930 ist RADIUS. 812 ist ein Authentifizierungsverfahren, das der Server nicht akzeptiert hat47. 13801 und 13806 sind Zertifikate — falsche erweiterte Schlüsselverwendung, abgelaufen, fehlende Wurzel, oder ein Servername, der nicht zum Antragsteller des Zertifikats passt47. Die Tunnelaushandlung war in allen vier Fällen in Ordnung, und wenn du den Nachmittag mit Verfahren verbringst, findest du keinen davon.\nUnd das ist das Mitnehmbare an dieser Tabelle. Sechs Fehlercodes, fünf davon mit dem Wort timeout im Namen, und kein einziger ist tatsächlich ein Timeout. Es sind ein blockierter Port, ein verlorenes Fragment, eine Richtlinienentscheidung und ein RADIUS-Server, die alle dasselbe Wort tragen, weil die Schicht, die den Fehler meldet, zu wenig von dem sieht, was passiert ist, um etwas Nützlicheres zu sagen. Den Timer zu verlängern behebt keinen davon, und den Timer zu verlängern ist das, wozu die Oberfläche dich einlädt.\nWas du stattdessen betreiben solltest Ich tue nicht so, als wäre der Ersatz exotisch. Er steckt im Kernel und tut das seit Jahren.\nWireGuard ist ein UDP-Port, ein Schlüssel je Peer, keine Chiffrenaushandlung und überhaupt keine Protokollagilität. Die Haltung des Autors dazu ist bewusst und ausgesprochen: „It intentionally lacks cipher and protocol agility. If holes are found in the underlying primitives, all endpoints will be required to update. As shown by the continuing torrent of SSL/TLS vulnerabilities, cipher agility increases complexity monumentally.“53 Diese eine Entscheidung löscht NO_PROPOSAL_CHOSEN, INVALID_KE_PAYLOAD, Downgrade-Angriffe und den Logjam-Befund in einem Zug, weil es nichts auszuhandeln und nichts herabzustufen gibt.\nEs ist auch ehrlich zum Preis, und ich bin es auch: keine Agilität heißt, dass du beim Fall eines Primitivs die ganze Flotte aktualisierst, statt eine Konfigurationszeile umzulegen. Das ist ein echter Betriebsaufwand und der richtige, den man zahlt.\nDer Rest passt fast Punkt für Punkt auf die Liste oben. Einen UDP-Port zu haben heißt, dass NAT und CGNAT ihn wie jeden anderen Fluss behandeln und ECMP und LAG ihn wie jeden anderen Fluss hashen. Roaming ist eingebaut statt angeschraubt — ein authentifiziertes Paket von einer neuen Adresse verschiebt den Endpunkt des Peers, ein Telefon, das von WLAN auf Mobilfunk wechselt, handelt also nichts neu aus. Auf ein nicht authentifiziertes Paket antwortet es gar nicht, ein Scanner findet also einen geschlossenen Port, wo er bei IPsec einen Konzentrator zum Reden fände. Und es sind unter 4.000 Zeilen Code53, gegen einen Stapel, für dessen sechzehn Unverträglichkeiten mit einer einzigen Middlebox es ein eigenes Dokument braucht.\nBei der Leistung war es in den Messungen schlicht schneller als beide IPsec-Konfigurationen, gegen die es getestet wurde: 1.011 Mbit/s gegen 881 und 825, bei geringerer Latenz53. Ich würde ein Protokoll nicht wegen eines Benchmarks stilllegen. Ich erwähne es, weil das letzte verbliebene Argument für IPsec meist die Leistung ist, und das stimmt auch nicht.\nUm eine Person an eine Anwendung zu bringen — und nicht ein Netz an ein Netz — ist die Antwort gar kein Tunnel. Identität an der Haustür, die Anwendung darüber veröffentlicht, nichts geroutet. Das habe ich mit Proxmox und Cloudflare Access in Zero-Trust-VDI ohne Cloud-Rechnung ausgebaut, und der für diesen Beitrag relevante Punkt ist: wer drei interne Anwendungen braucht, braucht keine Route in deinen gesamten Bestand.\nUnd sag den stillen Teil laut, was Hardware angeht. Ja, es gibt NICs und ASICs mit ESP-Offload, und das ist ein echtes Argument für IPsec auf bestimmter Hardware bei bestimmten Geschwindigkeiten. Es ist ein Argument über Silizium, das dir jemand schon verkauft hat, und keines darüber, dass das Protokoll richtig wäre. Als solches altert es, und zwar schnell. PPTP hat genau so überlebt, genau so lange, wie es das Häkchen gab.\nEs richtig stilllegen Stilllegung ist ein Plan mit Terminen, kein Gefühl. Hier der, für den ich meinen Namen hergeben würde.\nKeine neuen IPsec-Ausrollungen mehr, ab jetzt. Nicht „Alternativen bevorzugen“. Schluss. Jeder neue Tunnel ist ein Tunnel, den später jemand migrieren muss, und die, die heute gebaut werden, laufen 2035 immer noch, wenn nicht diese Woche jemand Nein sagt.\nFernzugriff zuerst, denn dort schlägt jeder Fehler aus diesem Beitrag am härtesten ein: das CGNAT, die geteilte Adresse, die Keepalives, der zweite Nutzer im selben Haus, das MTU-Loch in irgendeinem Hotelnetz. Er ist außerdem am leichtesten zu bewegen, weil die Endgeräte verwaltet werden und die Änderung ein Client ist.\nDann Site-to-Site über das öffentliche Internet, dieselben Probleme mit weniger Endpunkten und einem Wartungsfenster.\nZum Schluss die Tunnel, bei denen dir nicht beide Enden gehören: ein Partner, eine Aufsichtsbehörde, der Managed Service eines Carriers. Die bewegen sich, wenn der Vertrag sich bewegt, und wie man sie in Bewegung bringt, steht im nächsten Punkt.\nKauf keine Hardware mehr, deren einziger Tunnel IPsec ist. Schreib es in die Ausschreibung. Eine Zeile, die einen modernen, portbasierten, roamingfähigen Tunnel verlangt, ist eine Zeile, die ein Hersteller beantwortet oder eben nicht, und so verliert das Argument der installierten Basis am Ende. Dieses Argument hält das alles als Einziges am Leben, und geschlagen wird es nur durch Einkauf.\nSchreib auf, welche Tunnel übrig sind und warum, und setz auf jeden ein Datum. Ein Protokoll, für das sich zehn Jahre niemand zuständig fühlte, ist der Weg, auf dem PPTP bis 2026 gekommen ist. Eine Inventur mit Terminen ist der Unterschied zwischen etwas stilllegen und es bloß nicht mögen.\nWenn du es immer noch ausrollst, darfst du dich dann IT-Profi nennen? Das ist eine echte Frage, und ich werde sie ehrlich beantworten, weil der Rest dieses Beitrags darauf zuläuft.\nEs hängt davon ab, ob du es weißt. Und Wissen passiert dir nicht einfach. Dafür zu sorgen, dass du es weißt, ist die Arbeit.\nWenn du dieses Jahr einen neuen IPsec-Fernzugriff aufbaust und nicht aus dem Kopf sagen kannst, warum ESP keine Ports hat, was eine Hausanschlussleitung hinter Carrier-Grade NAT damit macht, warum ein NAT64-Netz es überhaupt nicht trägt, oder wofür dieses eine Byte alle zwanzig Sekunden eigentlich da ist — dann nein. Hierbei nicht, noch nicht. Du wählst kein Protokoll. Du wiederholst eine Form, weil die letzte so aussah und niemand im Raum gefragt hat, warum — du eingeschlossen. Das Versagen ist nicht die Lücke. Lücken hat jeder. Das Versagen ist, über eine zu bauen, die du nie geschlossen hast. Als solches bekommt die Person, die das 2035 erbt, ein Jahrzehnt Tickets, die alle vermeidbar waren an dem Tag, an dem du es gezeichnet hast.\nUnd ich gebe dem den richtigen Namen, denn die höfliche Fassung ist seit zwanzig Jahren im Umlauf und hat nichts geändert. Wer ein Protokoll ausrollt, das er nicht erklären kann, ist kein Ingenieur. Er ist ein Mitläufer. Er liest Karteikarten vor — die Referenzarchitektur des Herstellers, den letzten Change-Antrag, eine Zeichnung, die jemand 2014 gemacht und seither niemand mehr geöffnet hat —, und er liest sie mit echter Überzeugung vor, und hinter der Vorstellung steckt kein Verständnis. Von außen sieht das genau wie Kompetenz aus. Es sieht auch weiter genau wie Kompetenz aus, bis zum ersten Fehler, den die Karten nicht abdecken, und ab dem Moment ist es das Einzige im Raum, worauf es ankommt.\nDie Karteikarten sind auch der Grund, warum dieses Protokoll noch da ist. Niemand hat 2026 am Whiteboard gestanden und IPsec sachlich verteidigt. Es wurde wieder ausgerollt, weil es auf der Karte stand, und die Karte hat ein Hersteller geschrieben, dessen Interesse darin besteht, dass du weiter die Kiste kaufst, die es terminiert. So überlebt etwas seinen eigenen Nachruf um zwanzig Jahre — nicht indem es verteidigt wird, sondern indem es kein einziges Mal in einem Raum Rechenschaft ablegen musste, in dem jemand den Unterschied bemerkt hätte.\nUnd das wird angesprochen. Laut, im Raum, in dem Moment — nicht hinterher auf dem Flur gemurmelt. Wer das Wort Profi neben seinen Namen stellt, bekommt mit dem Wort die Einladung, gefragt zu werden, und Fragen ist nicht unhöflich. Gefragt zu werden und eine Antwort zu haben ist der ganze Unterschied zwischen dem Wort und einer Visitenkarte.\nAm meisten zählt das, wenn du dafür bezahlst. Eine Beratung, ein MSP, die Professional-Services-Abteilung eines Herstellers, der Integrator im Rahmenvertrag — was du kaufst, ist Urteilsvermögen, und Urteilsvermögen ist das Einzige, was du bei der Lieferung nicht prüfen kannst. Also prüfe es vorher. Frag, warum dieses Protokoll und nicht ein anderes. Frag, was mit ihm auf einer Leitung hinter Carrier-Grade NAT passiert, in einem reinen IPv6-Mobilfunknetz, auf einem Pfad, der stillschweigend Fragmente verwirft. Frag, welches davon sie selbst erlebt haben und was sie dann getan haben. Du weißt binnen zwei Minuten, ob dir etwas gesagt oder etwas vorgelesen wird, und zwei Minuten sind ein deutlich billigerer Test als vier Jahre Tickets. Und wenn die Antwort aus Karteikarten besteht und du trotzdem unterschreibst, ist das auch eine Entscheidung — sie ist nur gerade deine geworden und nicht mehr ihre.\nWenn du das alles sagen kannst und es trotzdem ausrollst, weil eine Aufsicht es namentlich vorschreibt, weil die Kiste des Partners nichts anderes terminiert, oder weil der Ersatz im Budget des nächsten Jahres steht und das hier im März laufen muss — dann ja, selbstverständlich, und du machst deine Arbeit richtig. Zwänge sind real, und ich habe um Schlimmeres herumgebaut. Was die beiden trennt, ist nicht das Protokoll auf der Zeichnung. Es ist, ob du aufgeschrieben hast, warum, und ob ein Datum daneben steht.\nNicht zu verteidigen ist die Mitte. Genug zu wissen, um ein ungutes Gefühl zu haben, und es trotzdem zu bauen, weil niemand dich zur Begründung gezwungen hat. Keine Ingenieurarbeit. Gewohnheit mit einer Änderungsnummer dran — und genau so ist L2TP auf ein Datenblatt geraten, das dieses Jahr gedruckt wurde.\nStell dir die Frage also vor der Ausschreibung und nicht danach. Profi ist kein Wort darüber, welche Protokolle du kennst. Es ist ein Wort darüber, ob du das gewählte laut verteidigen kannst, vor jemandem, der die Fehlerarten kennt. Wenn du das kannst, roll aus, was die Zwänge verlangen, und schlaf gut. Wenn nicht, hast du gerade gefunden, was du heute Abend lesen solltest, und das ist keine Beleidigung. Jeder war mal Mitläufer, ausnahmslos, ich eingeschlossen. Nicht zu verteidigen ist, es freiwillig zu bleiben und das eine Laufbahn zu nennen.\nEine gute Idee darf auch vorbei sein Ich will IPsec gerecht werden, denn das hat es verdient.\nEs war der richtige Instinkt. Sicherheit gehört tief in den Stapel, wo alles sie erbt und keiner Anwendung zugetraut werden muss, sie richtig zu machen. Die Association an die Adresse zu binden war 1995 kein Fehler — die Adresse war die Maschine, und darauf zu bauen war richtig. Die Leute, die es geschrieben haben, waren ernsthafte Leute mit einem echten Problem, und ausgerechnet das WireGuard-Papier bringt es am besten auf den Punkt: die Schichtung von IPsec ist stimmig, alles sitzt an seinem Platz, bis zur akademischen Perfektion53.\nUnd dann hat sich der Boden bewegt. Nicht weil IPsec etwas falsch gemacht hätte, sondern weil diese Branche entschieden hat, Adressen seien ein zu verwaltender Kostenpunkt und nicht etwas, das jede Maschine bekommt, und fünfundzwanzig Jahre Übersetzung gebaut hat, um der Alternative auszuweichen. IPsec wurde still das Fundament entzogen, und statt das zuzugeben, haben wir unterlegt. UDP-Kapselung. Dann Keepalives. Dann TCP-Kapselung für die Netze, die UDP blockieren. Dann noch ein UDP-Header, damit ein Router etwas zum Hashen findet. Jede Lösung für sich vernünftig; der Stapel daraus ist ein Protokoll, das von Leuten aufrecht gehalten wird, die dafür bezahlt werden, es aufrecht zu halten.\nDas ist der Teil, über den es sich zu ärgern lohnt, und er handelt eigentlich gar nicht von IPsec. Unsere Branche ist sehr gut darin, Dinge zu warten, und sehr schlecht darin, sie zu beenden. Wartung ist abrechenbar, budgetiert, besetzt und sicher. Stilllegung ist eine Entscheidung, die jemand unterschreiben muss, mit seinem Namen darunter, und ohne unmittelbaren Lohn. Also lebte PPTP vierzehn Jahre über den Beweis seiner Wertlosigkeit hinaus, L2TP wird immer noch auf Geräten ausgeliefert, die dieses Jahr verkauft werden, und IKEv1 handelte noch ein Jahrzehnt nach seiner Historic-Einstufung Tunnel aus. Nicht weil sie jemand verteidigt hätte. Sondern weil nie jemand verpflichtet war, sie zu beenden.\nEs gibt keinen Preis dafür, 90 % richtig zu machen. Ferguson und Schneier schrieben das 1999 über IPsec, und was seitdem passiert ist, sind dreißig Jahre, in denen die Branche die letzten 10 % jedes Mal auf neue Weise falsch gemacht und das Pflaster eine Lösung genannt hat.\nEine gute Idee darf auch vorbei sein. Zu wissen, wann man aufhört, etwas zu warten, ist eine Fähigkeit, und es ist die, in der dieses Gewerbe am schlechtesten ist. Irgendjemand muss derjenige sein, der sagt, ein Protokoll hat sein Leben gehabt, der das Datum aufschreibt und die Folgen dafür trägt, derjenige gewesen zu sein, der es gesagt hat. Sonst schicken wir 2040 immer noch alle zwanzig Sekunden ein Ein-Byte-Paket, um eine Tabelle in einer Box warm zu halten, die uns nicht gehört, in einem Netz, das uns unsere Adressen weggenommen und uns dafür zur Kasse gebeten hat.\nRFC 4301 — Security Architecture for the Internet Protocol, Dezember 2005. Definiert die Security Association und das Tripel, über das sie nachgeschlagen wird: Zieladresse, Sicherheitsprotokoll und SPI.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 4302 — IP Authentication Header, Dezember 2005. Die Integritätsprüfung von AH deckt die unveränderlichen Felder des IP-Headers ab, Quell- und Zieladresse eingeschlossen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 9329 — TCP Encapsulation of Internet Key Exchange Protocol (IKE) and IPsec Packets, November 2022, ersetzt RFC 8229. Existiert, weil Middleboxes in öffentlichen Netzen UDP blockieren.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 3715 — IPsec-Network Address Translation (NAT) Compatibility Requirements, März 2004. Sechzehn aufgezählte Unverträglichkeiten, darunter: „Since the AH header incorporates the IP source and destination addresses in the keyed message integrity check, NAT or reverse NAT devices making changes to address fields will invalidate the message integrity check.“ und „Where IP addresses are used as identifiers in Internet Key Exchange Protocol (IKE) Phase 1 or Phase 2, modification of the IP source or destination addresses by NATs or reverse NATs will result in a mismatch between the identifiers and the addresses in the IP header.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCisco — Configuring IPsec NAT-Traversal, Security Configuration Guide, Cisco IOS XE 17.15.x (Catalyst 9300 Switches). „If PAT found a legislative IP address and port, it would drop the Encapsulating Security Payload (ESP) packet“; der UDP-Header und eine acht Byte lange Nicht-IKE-Markierung werden zwischen äußeren IP-Header und ESP-Header eingefügt; die Einschränkungsliste nennt statische Regeln für Port 500 und 4500, keine Unterstützung dynamischer NAT-Richtlinien, kein IPv6, und dass IPsec und NAT nicht beide auf demselben Gerät laufen können.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 3948 — UDP Encapsulation of IPsec ESP Packets, Januar 2005, mit der Aushandlung in RFC 3947. Definiert den Keepalive als „a one-octet-long payload with the value 0xFF“, gesendet „if no other packet to the peer has been sent in M seconds. M is a locally configurable parameter with a default value of 20 seconds.“, und verlangt die Nullsetzung der UDP-Prüfsumme: „If the protocol header after the ESP header is a UDP header, set the checksum field to zero in the UDP header.“ Microsoft, Cisco, F-Secure, Nortel und SafeNet stehen alle auf den Autorenlisten von RFC 3947 und RFC 3948.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nJuniper — Route-Based and Policy-Based VPNs with NAT-T, Junos OS IPsec VPN User Guide. „NAT-T encapsulates both IKE and ESP traffic within UDP with port 4500 used as both the source and destination port“; „Because NAT devices age out stale UDP translations, keepalive messages are required between the peers“; und auf SRX5400, SRX5600 und SRX5800: „the total number of tunnels from a given public translated IP cannot exceed 1000 tunnels.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 8221 — Cryptographic Algorithm Implementation Requirements and Usage Guidance for ESP and AH, Oktober 2017. ENCR_DES MUST NOT, ENCR_3DES SHOULD NOT, AUTH_HMAC_MD5_96 MUST NOT; ESP zusammen mit AH ist NOT RECOMMENDED.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 4787 — Network Address Translation (NAT) Behavioral Requirements for Unicast UDP, Januar 2007. REQ-5: „A NAT UDP mapping timer MUST NOT expire in less than two minutes“, mit „a default value of five minutes or more for the NAT UDP mapping timer is RECOMMENDED“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 6146 — Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers, April 2011. „The current specification only defines how stateful NAT64 translates unicast packets carrying TCP, UDP, and ICMP traffic. Multicast packets and other protocols, including the Stream Control Transmission Protocol (SCTP), the Datagram Congestion Control Protocol (DCCP), and IPsec, are out of the scope of this specification.“ Pakete mit allem anderen „SHOULD be discarded“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 6877 — 464XLAT: Combination of Stateful and Stateless Translation, April 2013. Gibt einem IPv6-only-Gerät einen lokalen IPv4-Stack, damit Verkehr läuft, den NAT64 nicht tragen kann.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nIETF — draft-xu-ipsecme-esp-in-udp-lb, Encapsulating IPsec ESP in UDP for Load-balancing. „Although the ESP SPI field within the IPsec packets can be used as the load-balancing key, but it cannot be used by legacy switches and routers“; „Many cloud service providers allow customers to establish multiple IPsec VPN tunnels in parallel to enable ECMP and increase aggregate bandwidth. However, this approach is not ideal, as each tunnel typically requires its own public IP address, leading to higher public IP consumption and increased operational overhead.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCisco — Resolve IPv4 Fragmentation, MTU, MSS, and PMTUD Issues with GRE and IPsec. Die seit Langem gepflegte Referenz zu Tunnel-Overhead, Path MTU Discovery und dem, was kaputtgeht, wenn die ICMP-Fehler nicht zurückkommen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCisco — Troubleshoot IPsec Anti-Replay Check Failures. „Certain QoS features, such as Low Latency Queueing (LLQ), could cause IPsec packet delivery to become out-of-order and dropped by the receiving endpoint due to a replay check failure.“ Standardfenster 64 Pakete; 1024 auf neueren Plattformen; die andere Abhilfe sind mehrere Sequenznummernräume je Association.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 2661 — Layer Two Tunneling Protocol „L2TP“, August 1999. Ein Tunnelprotokoll für PPP ohne eigene Vertraulichkeit auf Paketebene; sein Sicherheitsabschnitt verweist auf IPsec.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMoxie Marlinspike und David Hulton — Divide and Conquer: Cracking MS-CHAPv2 with a 100% Success Rate, 2012; Werkzeug unter github.com/moxie0/chapcrack. Die Sicherheit von MS-CHAPv2 reduziert sich unabhängig von der Passwortlänge auf eine einzige DES-Operation; zeitgenössischer Bericht im Register. Ihr Schluss war, PPTP-Verkehr als unverschlüsselt zu betrachten.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nApple — If you see a „VPN Using PPTP May Not Be Secure“ alert. PPTP wurde 2016 aus dem eingebauten Client in macOS Sierra und iOS 10 entfernt.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 4303 — IP Encapsulating Security Payload (ESP), Dezember 2005. IP-Protokoll 50; der ESP-Header trägt SPI und Sequenznummer und hat kein Portfeld.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 9395 — Deprecation of the Internet Key Exchange Version 1 (IKEv1) Protocol and Obsolete Cryptographic Algorithms, April 2023. „Internet Key Exchange Version 1 (IKEv1) has been deprecated, and RFCs 2407, 2408, and 2409 have been moved to Historic status.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 7296 — Internet Key Exchange Protocol Version 2 (IKEv2), Oktober 2014. Der aktuelle Schlüsselaustausch und die Quelle der Notify-Namen in der Diagnosetabelle.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 3173 — IP Payload Compression Protocol (IPComp), September 2001. Eigene IP-Protokollnummer und eigene Associations, ausgehandelt neben ESP.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 2367 — PF_KEY Key Management API, Version 2, Juli 1998. Die Kernel-Schnittstelle, über die ein Schlüsseldaemon Associations installiert.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 7383 — IKEv2 Message Fragmentation, November 2014. „This document describes a way to avoid IP fragmentation of large Internet Key Exchange Protocol version 2 (IKEv2) messages.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 4555 — IKEv2 Mobility and Multihoming Protocol (MOBIKE), Juni 2006. Lässt einen aufgebauten Tunnel einen Adresswechsel überleben.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 3706 — A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers, Februar 2004.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\ndraft-beaulieu-ike-xauth — Extended Authentication within IKE (XAUTH). Letzte Fassung 02, Oktober 2001, Status Expired, „Expired \u0026amp; archived“, nie als RFC veröffentlicht. Der Entwurf hält fest, dass er als Informational angeboten wurde, weil „the IPSRA working group will not accept any protocol which extends ISAKMP or IKE, and the IPsec working group refuses to accept any protocols that deal with remote access.“ Mode-Config teilte dasselbe Schicksal.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 3193 — Securing L2TP using IPsec, November 2001. Mitverfasst bei Microsoft.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 2332 — NBMA Next Hop Resolution Protocol (NHRP), April 1998. Das Stück, mit dem DMVPN-Spokes sich finden.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 6407 — The Group Domain of Interpretation, Oktober 2011. Gruppenschlüssel, wie von GETVPN genutzt.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 2637 — Point-to-Point Tunneling Protocol (PPTP), Juli 1999. Kategorie: Informational. Ein aufgeschriebenes Herstellerprotokoll, nie ein Standard.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMicrosoft — Configure L2TP/IPsec server behind NAT-T device, KB 926179, zuletzt überarbeitet am 12. Februar 2026. „By default, Windows Vista and Windows Server 2008 don\u0026rsquo;t support Internet Protocol security (IPsec) network address translation (NAT) Traversal (NAT-T) security associations to servers that are located behind a NAT device“; der DWORD-Wert AssumeUDPEncapsulationContextOnSendRule unter HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\PolicyAgent nimmt 0 (Vorgabe, geht nicht), 1 (Server hinter NAT) oder 2 (beide Enden hinter NAT), und der Rechner muss neu gestartet werden. Außerdem: „If you must use IPsec for communication, use public IP addresses for all servers that you can connect to from the Internet.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nstrongSwan — Windows Certificate Requirements. Das Gateway-Zertifikat braucht die EKU serverAuth, OID 1.3.6.1.5.5.7.3.1, und die EKU IP Security IKE Intermediate, OID 1.3.6.1.5.5.8.2.2.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nstrongSwan — Windows Clients. Dokumentiert das Hinzufügen des DWORD NegotiateDH2048_AES256 unter Rasman\\Parameters für AES-256-CBC und MODP-2048; die Rekeying-Behelfslösung für Clients hinter NAT (rekey_time = 0 auf dem Gateway, der Client beginnt); und dass der Windows-Client „does not currently support IKE redirection (RFC 5685) and multiple authentication rounds (RFC 4739)“. Außerdem: „IKEv2 fragmentation is supported since the v1803 release of Windows 10 and Windows Server“, und Clients hinter NAT lehnen ein vom Server begonnenes CHILD_SA-Rekeying mit dem Microsoft-Fehler 13863 ab.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMicrosoft — DirectAccess und Remote Access Always On VPN migration overview. DirectAccess ist abgekündigt und wird in einer künftigen Windows-Server-Version entfernt; Kunden werden auf Always On VPN verwiesen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nJean Paul Degabriele und Kenneth G. Paterson — Attacking the IPsec Standards in Encryption-only Configurations, IEEE Symposium on Security and Privacy, 2007. Angriffe, die „break any RFC-compliant implementation of IPsec making use of encryption-only ESP“, allein aus dem Chiffretext, und die nur verlangen, Verkehr mitzulesen und Pakete einzuspeisen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 6434 — IPv6 Node Requirements, Dezember 2011. „Previously, IPv6 mandated implementation of IPsec and recommended the key management approach of IKE. This document updates that recommendation by making support of the IPsec Architecture [RFC4301] a SHOULD for all IPv6 nodes.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNiels Ferguson und Bruce Schneier — A Cryptographic Evaluation of IPsec, Counterpane Internet Security, 1999. „IPsec was a great disappointment to us“; „Our main criticism of IPsec is its complexity“; „We therefore recommend that transport mode be eliminated“; „We conclude that eliminating transport mode allows the elimination of the AH protocol as well, without loss of functionality“; und „We have found serious security weaknesses in all major components of IPsec. As always in security, there is no prize for getting 90% right; you have to get everything right.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nDavid Adrian u. a. — Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice, ACM CCS 2015. Vorberechnung für eine zweite 1024-Bit-Gruppe „would allow decryption of traffic to 66% of IPsec VPNs“; 86,1 % der gescannten IKEv1- und 91,0 % der IKEv2-Server unterstützten Oakley-Gruppe 2, und 66,1 % der profilierten IKEv1-Server bevorzugten sie.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCVE-2016-1287 und Ciscos Advisory, Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow Vulnerability. Codeausführung aus der Ferne vor der Authentifizierung, erreicht über präparierte UDP-Pakete an den IKE-Dienst.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nJuniper — How to Analyze IKE Phase 2 VPN Status Messages. „No proposal chosen“ heißt, das Gerät „did not accept any of the IKE Phase 2 proposals that the peer sent“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCisco — Understand and Use Debug Commands to Troubleshoot IPsec und Troubleshoot Common L2L and Remote Access IPsec VPN Issues.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nJuniper — Troubleshoot a VPN Tunnel That is Down.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nLinux-Kernel — XFRM proc counters. Die Beschreibungen in der Tabelle stammen aus der Kernel-Dokumentation selbst.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nJuniper — Troubleshoot a VPN That Is Up But Not Passing Traffic. „If only the pkts counter in the out direction of the session is incrementing, then validate with the VPN peer that the traffic is being received.“\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMicrosoft — netsh wfp, Windows Commands. netsh wfp capture start „Starts a capture session for network events processed by WFP“ und schreibt standardmäßig wfpdiag.cab; netsh wfp show state „Displays the current state of WFP and IPsec“; netsh wfp show ikeevents „Displays recent Internet Key Exchange (IKE) epoch events matching the specified parameters“ und nimmt einen Filter remoteaddr=. Mit file=- schreibt jedes show auf die Konsole statt XML.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMicrosoft — Get-NetIPsecQuickModeSA, Modul NetSecurity. „There is only one main mode SA between a pair of computers, but there can be many quick mode SAs“, und ihre Überwachung „can provide information about which peers are currently connected to this computer, and which protection suite is protecting the data exchanged between them“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMicrosoft — Troubleshoot Always On VPN, zuletzt überarbeitet am 12. Februar 2026. Zum Lesen der Client-Protokolle: „look for events labeled RasClient. All error messages return the error code at the end of the message.“ Ursache von Fehler 809: „You can encounter this issue when the UDP 500 or 4500 ports on the VPN server or firewall are blocked.“ Fehler 812 ist ein Verfahrensunterschied zwischen der Richtlinie des Servers und dem Profil des Clients. Die vier genannten Ursachen von Fehler 13801 sind ein Maschinenzertifikat ohne Server Authentication in der erweiterten Schlüsselverwendung, ein abgelaufenes RAS-Maschinenzertifikat, ein Client ohne das Wurzelzertifikat, und ein Client, dessen „VPN server name doesn\u0026rsquo;t match the subjectName value on the server certificate“; 13806 ist „IKE can\u0026rsquo;t find a valid machine certificate“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMicrosoft — Guidance for troubleshooting Remote Access (VPN and AOVPN). Das unterstützte Sammelpaket ist TSS, erhöht ausgeführt: TSS.ps1 -Scenario NET_VPN auf dem Client und TSS.ps1 -Scenario NET_RAS auf dem Server, den Fehler zwischen Start und Stopp nachstellen, die Spuren landen in C:\\MS_DATA.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMicrosoft — Routing and Remote Access Error Codes, die in raserror.h definierten Codes. 638 ERROR_REQUEST_TIMEOUT; 718 ERROR_PPP_TIMEOUT; 789 ERROR_OAKLEY_GENERAL_PROCESSING, „The L2TP connection attempt failed because the security layer encountered a processing error during initial negotiations with the remote computer“; 809 ERROR_VPN_TIMEOUT, „The network connection between your computer and the VPN server could not be established because the remote server is not responding“; 828 ERROR_IDLE_TIMEOUT, „The connection was terminated because of idle timeout“; 930 ERROR_AUTH_SERVER_TIMEOUT, „The authentication server did not respond to authentication requests in a timely fashion“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nfirewalld — Automatic Helper Assignment. „With kernel 4.7 and up the automatic helper assignment in kernel has been turned off by default“, gesteuert über den Sysctl-Wert unter /proc/sys/net/netfilter/nf_conntrack_helper, und „for the secure use of iptables and connection tracking helpers it is recommended to turn AutomaticHelpers off“. Die Kernel-Meldung zur Änderung nennt Grund und Ersatz: Die automatische Zuordnung „has been turned off for security reasons“, stattdessen das CT-Target benutzen. Zu den abgedeckten Helfern gehören ftp, irc, sip, h323, tftp, snmp und pptp.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nSamy Kamkar — NAT Slipstreaming, v1 vom 31. Oktober 2020, v2 vom 26. Januar 2021 mit Ben Seri und Gregory Vishnipolsky von Armis. Der Angriff missbraucht „the Application Level Gateway (ALG) connection tracking mechanism built into NATs, routers, and firewalls“, um „bypass victim NAT and connect directly back to any port on any machine on the network, exposing previously protected/hidden services and systems“. v1 nutzte das SIP-Gateway auf Port 5060, v2 H.323 auf 1720, womit sich das Loch auf jeden internen Host richten ließ statt nur auf die Maschine, die die Seite geladen hat.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMicrosoft — Set-VpnServerConfiguration, Modul RemoteAccess. -IdleDisconnectSeconds „Specifies the time, in seconds, after which an idle connection is terminated“; -SALifeTimeSeconds und -MMSALifeTimeSeconds setzen die Lebensdauern von Quick Mode und Main Mode; -SADataSizeForRenegotiationKilobytes „Specifies the number of kilobytes that are allowed to transfer using a security association (SA), after which the SA will be renegotiated“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nJason A. Donenfeld — WireGuard: Next Generation Kernel Network Tunnel, NDSS 2017. „It intentionally lacks cipher and protocol agility. If holes are found in the underlying primitives, all endpoints will be required to update. As shown by the continuing torrent of SSL/TLS vulnerabilities, cipher agility increases complexity monumentally“; „implemented for Linux in less than 4,000 lines of code“; „it is important to stress, however, that the layering of IPsec is correct and sound; everything is in the right place with IPsec, to academic perfection“. Messwerte: 1.011 Mbit/s gegen 881 und 825 für zwei IPsec-Chiffrensuiten, und 0,403 ms Ping gegen 0,501 und 0,508.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://blogs.damiendye.uk/de/networking/ipsec-was-a-good-idea-turn-it-off/","summary":"IPsec lag 1995 richtig: unterhalb der Anwendung verschlüsseln, die Security Association an die IP-Adresse binden, jedes Protokoll erbt sie. Dann kam NAT, Carrier-Grade NAT hat den Rest erledigt, und die Lösung bestand darin, das Ganze in UDP zu verpacken und einen Timer laufen zu lassen, damit eine Übersetzungstabelle dich nicht vergisst. Dieser Beitrag zeigt Diagramm für Diagramm, wie es zusammenbricht — die Security Association, die einen umgeschriebenen Header nicht überlebt, die zwei Übersetzer, die heute an jedem CGNAT-Anschluss hängen, der NAT64-Standard, der IPsec ausdrücklich ausschließt, der Tunnel, der keine zweite Leitung nutzen kann, weil ESP keine Ports hat, die MTU, für die sich niemand zuständig fühlt, und L2TP und PPTP als die zwei Protokolle, die hier nie hingehört haben. Dazu die Herstellerdokumentation von Cisco, Juniper und Microsoft, die all das einräumt, die achtzehn Bestandteile, die sich IPsec-VPN nennen, darunter zwei, die nie ein Standard waren, warum das Fisher-Price OS nie wirklich mit einem offenen Stack zusammengearbeitet hat, eine funktionierende Diagnosemethode für die Zeit, in der du IPsec noch betreibst, und die Begründung, das Ganze mit festen Terminen stillzulegen.","title":"IPsec war eine gute Idee. Es ist Zeit, es abzuschalten."},{"content":"Was Azure Virtual Desktop wirklich kostet Azure Virtual Desktop liefert einen Windows-Desktop im Browser. Das tut es tatsächlich, und es funktioniert. Die Frage ist, was es kostet, es am Laufen zu halten.\nDer Listenpreis ist nicht der Preis. Microsofts Lizenzstapel für AVD läuft etwa so1:\nEine Microsoft-365-Lizenz, die das Windows-Enterprise-Recht enthält — E3 oder E5, oder das entsprechende Business Premium Azure-Rechenleistung unter dem Desktop — eine VM nach Stunden abgerechnet, oder eine reservierte Instanz nach Monaten Azure-Speicher für die Systemplatte und das Benutzerprofil Azure-Netz für den Verkehr zwischen dem Desktop und allem anderen Wahlweise Microsoft Entra ID P1 oder P2 für Richtlinien zum bedingten Zugriff Windows 365 Cloud PC vereinfacht die Abrechnung auf eine glatte Zahl pro Nutzer und Monat, aber die Zahl ist nicht klein. Eine Konfiguration mit 2 vCPUs, 8 GB und 128 GB — ein bescheidener Büro-Desktop — kostet 35,60 £ pro Nutzer und Monat2. Nimm eine GPU dazu, und es springt auf 269,40 £ für die Stufe GPU Standard. Multipliziere mit der Kopfzahl, und es ist ein echter Posten, jeden Monat, für immer.\nDas ist das Produkt, das dieser Beitrag ersetzt.\nBrowser beliebiges Gerät kein RDP-Client kein VPN HTTPS Cloudflare Access\u0026#160;+\u0026#160;IdP meldet den Nutzer an rendert RDP im Browser frei bis\u0026#160;50 Nutzer keine Ports offen kein VPN nötig Zero-Trust-Richtlinie Tunnel LXC cloudflared eigenes VLAN Firewall lässt nur RDP-Ziele durch RDP Windows\u0026#160;VM GPU VF\u0026#160;0\u0026#160;·\u0026#160;RDP Windows\u0026#160;VM GPU VF\u0026#160;1\u0026#160;·\u0026#160;RDP Windows\u0026#160;VM GPU VF\u0026#160;2\u0026#160;·\u0026#160;RDP Proxmox-Host\u0026#160;·\u0026#160;Intel Arc Pro SR-IOV Arc Pro B-Reihe PF → Host VF 0 → VM VF 1 → VM VF 2 → VM Ein Browser, ein Identitätsanbieter und ein Tunnel — kein VPN, keine offenen Ports, keine Rechnung pro Platz Der ganze Weg: ein Browser, Cloudflare Access für die Identität, ein Tunnel in einen per Firewall eingehegten LXC, und RDP zu Windows-VMs mit virtuellen Funktionen einer Intel Arc Pro. Kein VPN, keine offenen Ports, keine Rechnung pro Platz. Wie der Ersatzstapel aussieht Drei Schichten, jede eigenständig, keine davon pro Platz abgerechnet:\nDie GPU-Schicht ist der Intel-Arc-Pro-SR-IOV-Aufbau aus dem vorigen Beitrag. Eine einzelne Arc-Pro-Karte teilt sich über normales PCIe-SR-IOV in virtuelle Funktionen in Hardware — keine vGPU-Lizenz, kein NVIDIA-Abo. Jede Windows-VM bekommt ihre eigene VF und ihren eigenen GPU-beschleunigten Desktop. Die Karte setzt die Platzzahl, nicht ein Lizenzserver.\nDie Zugriffsschicht ist Cloudflare Access mit RDP, im Browser gerendert. Der Nutzer öffnet eine URL in einem beliebigen Browser, meldet sich an deinem Identitätsanbieter an, und Cloudflare rendert die RDP-Sitzung direkt im Browser-Tab. Kein installierter RDP-Client. Kein VPN. Keine Ports zum Internet hin offen. Access föderiert zu jedem OAuth- oder OIDC-Anbieter — dazu gehören Anbieter auf eigener Hardware wie Keycloak oder Authentik, aufgesetzt auf dein vorhandenes Active Directory, ob das nun Samba 4 AD oder ein Windows-Domänencontroller ist. Das Verzeichnis macht weiter, was es schon macht: Benutzerkonten, Gruppenrichtlinien, in die Domäne aufgenommene VMs. Keycloak oder Authentik föderiert dagegen und legt die OAuth-/OIDC- und MFA-Schicht darauf, die Cloudflare Access braucht. Die Identitätsebene bleibt auf deiner eigenen Hardware. Kein Entra-ID-Abo nötig. Cloudflare Access kümmert sich um alles danach: es steuert, was der angemeldete Nutzer in deinem Netz erreichen kann — welche Anwendungen, welche Protokolle, welche Hosts. Der Desktop sitzt hinter einem Cloudflare-Tunnel und ist von nirgends erreichbar außer durch die Access-Richtlinie, und die Richtlinie entscheidet über Identität und Reichweite zugleich.\nDie Tunnelschicht ist ein cloudflared-Prozess in einem LXC-Container auf Proxmox, auf eigenem VLAN — ein /30 für IPv4 mit eigenem IPv6-Präfix, nichts anderes in der Broadcast-Domäne. Die Proxmox-Firewall steuert, was der LXC erreichen darf, und die Antwort ist kurz: TCP 3389 zu den Desktop-VMs und sonst nichts. Wird der Tunnelendpunkt übernommen, ist die Wirkungsweite ein Container auf einem ansonsten leeren VLAN, und das Einzige, mit dem er sprechen kann, ist das, was die Firewall schon erlaubt. Das ist eine weit kleinere Fläche als ein VPN-Konzentrator, der ein geroutetes Subnetz herausgibt.\nCloudflare Zero Trust ist bis 50 Nutzer kostenlos3. Du zahlst ab Nutzer 51. Azure Virtual Desktop berechnet ab dem ersten Platz.\nDie Architektur Nutzer beliebiges Gerät beliebiger Browser HTTPS Cloudflare Access OAuth-IdP macht Identität\u0026#160;+\u0026#160;MFA Access steuert Netz-Reichweite rendert RDP Tunnel Bei dir vor Ort LXC cloudflared eigenes\u0026#160;VLAN /30\u0026#160;IPv4 Firewall Proxmox nur\u0026#160;TCP\u0026#160;3389 RDP Windows VMs Virtuelle GPU- Funktionen Arc\u0026#160;Pro\u0026#160;SR-IOV Der Weg einer Sitzung: der Nutzer meldet sich an Cloudflares Rand an, der Tunnel landet in einem per Firewall eingehegten LXC auf eigenem VLAN, und die Firewall erlaubt nur RDP zu den Desktop-VMs. Der Weg, den eine Desktop-Sitzung nimmt:\nDer Nutzer öffnet https://vdi.example.com in einem beliebigen Browser, auf einem beliebigen Gerät Cloudflare Access fängt die Anfrage ab und leitet zu deinem Identitätsanbieter — Keycloak oder Authentik, föderiert gegen dein Active Directory Der OAuth-Anbieter prüft die Identität des Nutzers gegen AD und erledigt MFA Access wertet die Richtlinie aus — der Anbieter hat bestätigt, wer er ist, Access entscheidet, was er in deinem Netz erreichen darf Cloudflare baut eine RDP-Sitzung durch den Tunnel zur Ziel-VM auf Die RDP-Sitzung wird im Browser gerendert — kein Client, kein Plug-in, kein Download Der Tunnel endet in einem LXC-Container auf dem Proxmox-Host, auf einem zugesperrten VLAN Der LXC gibt RDP an die Windows-VM weiter, die eine virtuelle GPU-Funktion der Arc-Pro-Karte hat An keiner Stelle hat die Windows-VM eine öffentliche IP. An keiner Stelle ist Port 3389 zum Internet offen. Das Einzige, was im öffentlichen Internet lauscht, ist Cloudflare, und das Einzige, was an Cloudflare vorbeikommt, ist ein Nutzer, der die Access-Richtlinie bestanden hat.\nDer Tunnelendpunkt: ein LXC auf eigenem VLAN Der cloudflared-Prozess muss irgendwo laufen, und wohin du ihn stellst, ist eine Sicherheitsentscheidung.\nIhn direkt auf dem Proxmox-Host zu betreiben ist die einfachste Möglichkeit und die schlechteste. Ein Tunnelendpunkt, der den Netz-Namensraum des Hosts teilt, kann alles erreichen, was der Host erreichen kann, und auf einem Hypervisor ist das alles. Ein übernommener Tunnel wird zum Sprungbrett in die Verwaltungsebene.\nIhn in einer vollen VM zu betreiben ist sauber, aber schwer. Ein Tunnel-Relais ist eine einzelne Go-Binärdatei, die fast keine CPU und ein paar hundert Megabyte RAM braucht. Ihr einen ganzen Kernel und eine virtuelle Platte zu geben ist überdimensioniert.\nEin LXC-Container hat die richtige Form. Er bekommt seinen eigenen Netz-Namensraum, sein eigenes VLAN — ein /30 in IPv4 und ein eigenes IPv6-Präfix, nichts anderes teilt die Broadcast-Domäne — und seine eigenen Regeln in der Proxmox-Firewall. Er teilt den Kernel des Hosts, aber nicht dessen Netzstapel. Die Firewall erlaubt TCP 3389 zu den Desktop-VMs, DNS, um sie aufzulösen, und HTTPS nach außen zu Cloudflares Rand. Damit kann selbst ein übernommener Tunnelendpunkt nur mit den Dingen sprechen, mit denen er ohnehin sprechen sollte — und das VLAN, auf dem er sitzt, hat keine anderen Bewohner zu erreichen.\nDie LXC-Konfiguration, die Proxmox-Firewall-Regeln für das VLAN und das Aufsetzen des cloudflared-Tunnels stehen alle im nächsten Beitrag.\nWie Cloudflare Access zusammenpasst Das hat zwei Hälften. Der OAuth-Anbieter — Keycloak oder Authentik, föderiert gegen dein Active Directory (Samba 4 oder Windows) — erledigt die Identitätsprüfung und MFA. Er belegt, dass der Nutzer der ist, für den er sich ausgibt, und zwar über dasselbe Verzeichnis, in dessen Domäne die VMs sind. Cloudflare Access erledigt alles danach: was der angemeldete Nutzer erreichen darf, über welches Protokoll, und wie die Sitzung gerendert wird.\nCloudflare Access rendert die RDP-Sitzung direkt im Browser. Das ist kein Download und kein Plug-in — Cloudflares Rand betreibt einen kopflosen RDP-Client und streamt das Ergebnis als Canvas in den Browser-Tab. Der Nutzer sieht einen Windows-Desktop. Der Browser sieht HTTPS zu Cloudflare. Die Windows-VM sieht eine RDP-Verbindung aus dem cloudflared-Tunnel.\nDie Access-Anwendung ist eine selbst betriebene App, die auf den RDP-Eingang des Tunnels zeigt. Die Access-Richtlinie ist die Stelle, an der die zwei Hälften zusammentreffen. Der OAuth-Anbieter hat die Identität bereits bestätigt und die MFA-Abfrage abgeschlossen. Access nimmt dieses Token und entscheidet, was damit geschieht — welche Anwendung der Nutzer erreichen darf, ob die Lage seines Geräts besteht, ob sein Standort erlaubt ist. Der Anbieter sagt wer. Access sagt was.\nDas Anlegen des Tunnels, die Eingangsregeln, die LXC-Konfiguration, die Proxmox-Firewall-Regeln und die Access-Richtlinie selbst stehen alle im nächsten Beitrag — dieser legt dar, was der Stapel ist und warum er existiert. Der nächste baut ihn.\nWas der Nutzer sieht Cloudflare Access bringt einen App Launcher mit — ein Portal, das jede Anwendung auflistet, die der angemeldete Nutzer erreichen darf. Nachdem er sich über den OAuth-Anbieter angemeldet hat, zeigt ihm das Portal seine verfügbaren Desktops, internen Webanwendungen und alle anderen getunnelten Ressourcen an einer Stelle. Eine URL, eine Anmeldung, und eine Kachel für jedes Ding, auf das er Zugriff hat. Es ist die Startseite für den ganzen Stapel, nicht nur für RDP.\nDer Nutzer klickt eine Desktop-Kachel an und bekommt einen Windows-Desktop in einem Browser-Tab. Kein Client, kein Plug-in, kein Download. Es läuft auf dem Gerät, das er schon besitzt — ein Firmen-Laptop, ein privater Rechner, ein Chromebook, ein Tablet. Das ist der Sinn. Das System ist für Betriebe gebaut, die Leute ihr eigenes Gerät nutzen lassen.\nZwischenablage, Ton und mehrere Bildschirme werden über die im Browser gerenderte Sitzung nicht unterstützt. Das ist Absicht und kein Versehen. Jeder dieser Kanäle ist ein Weg, Daten hinauszutragen. Eine Zwischenablage, die die Grenze überschreitet, schafft Dateien hinaus. Tonaufnahme schafft Gespräche hinaus. Mehrere Bildschirme mit dem lokalen Desktop neben dem entfernten machen Ziehen und Ablegen trivial. Diese Kanäle zu kappen heißt, dass ein Nutzer im Desktop arbeiten kann, aber die Arbeit nicht über einen Nebenkanal herausziehen kann. Die Access-Richtlinie steuert, wer hereinkommt. Das Rendern im Browser steuert, was hinausgeht.\nBraucht der Betrieb Zwischenablage oder Ton für einen bestimmten Arbeitsablauf, unterstützt Cloudflare Access auch einen nativen RDP-Client durch den Tunnel — derselbe Tunnel, dieselbe Richtlinie, dieselbe Identitätsprüfung. Der native Weg gibt den ganzen RDP-Funktionsumfang an die Nutzer, die ihn brauchen, und hält den Browser-Weg für alle anderen zugesperrt. Zwei Zugriffswege, ein Richtlinienwerk, ein Tunnel.\nDer Kostenvergleich Ein greifbares Beispiel. Ein Server, 42 GPU-beschleunigte Desktops:\nEine CPU mit 64 Kernen und Hyperthreading gibt dir 128 Threads. Jede VM bekommt 8 vCPUs — eine richtige Desktop-Zuteilung, kein Thin Client. 42 × 8 = 336 vCPUs, und das ist auf dem Papier weit über 128 Threads. Aber das ist VDI. Büro-Desktops sind die meiste Zeit untätig. Ein Nutzer, der ein Dokument liest oder eine E-Mail schreibt, belastet keine 8 Kerne. Überbuchung ist hier kein Risiko, sie ist der Entwurf. Proxmox lässt dich mehr vCPUs zuteilen als es physische Threads gibt, weil der Scheduler weiß, dass die meisten schlafen. Die CPU ist auf die Spitze bemessen, und die Spitze sind eine Handvoll Nutzer, die gleichzeitig kompilieren oder rendern, nicht alle 42. Das ist keine Abkürzung — die Hyperscaler in der Cloud überbuchen genauso. Jede Azure-VM, die du mietest, teilt physische Kerne mit anderen Mietern auf demselben Host. Das Leistungsmodell ist dasselbe. Der Unterschied ist, wem der Host gehört. 12 GB RAM pro VM sind ein solider Büro-Desktop. 42 × 12 GB = 504 GB, plus 4 GB für Proxmox selbst = 508 GB auf dem Papier. In der Praxis fasst KSM die gleichen Seiten über diese 42 Windows-Abbilder zusammen, der physisch nötige RAM ist also deutlich weniger — aber rechne mit 512 GB DIMMs und lass KSM dir den Spielraum geben. Drei doppelte Intel Arc Pro B60 in einem Board wie dem Supermicro H13SSL-NT. Jede physische Karte zeigt dem Betriebssystem zwei GPUs, drei Karten geben also 6 GPUs. Jede GPU trägt 7 virtuelle SR-IOV-Funktionen4. Das sind 42 GPU-beschleunigte Desktops aus drei PCIe-Steckplätzen. Die B60 liegt bei etwa 599 bis 799 Dollar pro Karte. Die B70 ist die größere Wahl mit 949 Dollar zum Start für 32 GB und 4 virtuelle Funktionen pro GPU5 — weniger Plätze, aber mehr VRAM je Platz. Windows 365 Cloud PC für 42 Nutzer2:\nSelbst ohne GPU sind die Zahlen nicht klein. Die Stufe Basic — 2 vCPUs, 4 GB, 128 GB — kostet 26,90 £ pro Nutzer und Monat. Die Stufe Standard — 2 vCPUs, 8 GB, 128 GB, ein bescheidener Büro-Desktop — kostet 35,60 £ pro Nutzer und Monat. Für 42 Nutzer auf Standard sind das 1.495,20 £ im Monat, 17.942,40 £ im Jahr, vor allem Weiteren unten.\nMit GPU wird es schlimmer. Die Stufe GPU Standard kostet 269,40 £ pro Nutzer und Monat. Für 42 Nutzer sind das 11.314,80 £ im Monat, 135.777,60 £ im Jahr.\nBeide Stufen legen dann noch dazu:\nMicrosoft-365-Lizenzen, falls du sie nicht schon hast Azure-Netz — eingehend und ausgehend werden getrennt berechnet, und ein Desktop, der in einen Browser streamt, ist nicht sparsam beim Ausgehenden Azure Backup oder eine Sicherungslösung von Dritten — die VM-Momentaufnahmen und der Profilspeicher werden nicht kostenlos gesichert Öffentliche IPv4-Adressen — Azure berechnet jede öffentliche IP an einer Ressource, und der Preis ist nur gestiegen Azures zugrunde liegende Preise sind in Dollar, die Kosten in Pfund bewegen sich also mit dem Kurs — ein schwaches Pfund macht jeden Posten teurer, und du hast auf keine der beiden Seiten Einfluss Die Rechnung hört nie auf. Jahr fünf kostet so viel wie Jahr eins. Dieser Stapel für 42 Nutzer — die Baukosten:\nMainboard Supermicro H13SSL-NT: etwa 700 £ AMD EPYC mit 64 Kernen: etwa 1.500 £ 512 GB DDR5 ECC RDIMM (8 × 64 GB): etwa 5.200 £ Drei doppelte B60: etwa 1.800 £ Gehäuse, Netzteil, Boot-SSDs: etwa 800 £ Hardware zusammen: etwa 10.000 £ Über fünf Jahre Lebensdauer verteilt sind das 2.000 £ Kapitalkosten im Jahr. Dazu:\nCloudflare Zero Trust: bis 50 Nutzer kostenlos VDI-Rechte für Windows 11 Enterprise — Software Assurance auf Pro macht daraus Enterprise, was VDI-Zugriff für bis zu vier VMs pro Nutzer enthält, oder Lizenzierung über Microsoft 365 E3/E56 Strom — und dafür lohnt sich eine Zahl Das Leistungsbudget bei Spitzenlast: ein EPYC mit 64 Kernen bei 360 W TDP, drei doppelte B60 mit je 400 W (1.200 W), 512 GB RAM mit etwa 80 W, plus Speicher, Lüfter und Netzteilverluste mit rund 150 W. Das sind etwa 1.800 W an der Wand unter Volllast. VDI-Desktops laufen nicht unter Volllast — Bürobetrieb heißt meist untätige CPU und leichte GPU, ein realistischer Mittelwert liegt also näher an 1.000 bis 1.200 W. Nennen wir es 1.100 W.\nBei 35 Pence je kWh sind 1,1 kW rund um die Uhr:\n1,1 × 24 × 365 = 9.636 kWh im Jahr 9.636 × 0,35 £ = 3.373 £ Strom im Jahr Die Gesamtkosten dieses Stapels sind also etwa 5.400 £ im Jahr — 2.000 £ verteilte Hardware und 3.400 £ Strom, vor Windows-Lizenzen und Internet. Stell das neben die Azure-Rechnung: 5.400 £ gegen 135.778 £ für die GPU-Stufe, oder 17.942 £ für einfache Desktops ohne GPU. Selbst auf der billigsten Azure-Stufe kostet dieser Stapel weniger als ein Drittel. Auf der GPU-Stufe sind es 4 % der Azure-Rechnung.\nWarum VDI zu Proxmox passt VDI ist eine der Lasten, in denen Proxmox still sehr gut ist, aus zwei Gründen, die mit dem Hypervisor selbst nichts zu tun haben.\nKSM. Proxmox schaltet KSMd — den Kernel-Dienst zum Zusammenfassen gleicher Seiten — von Haus aus ein. Zwanzig Windows-VMs aus demselben Abbild teilen riesige Mengen gleicher Speicherseiten: das Betriebssystem, die Basisbibliotheken, die unveränderten Teile des Benutzerprofils. KSMd findet diese Doppelten und fasst sie zu einer physischen Seite zusammen, Kopie beim Schreiben. Das Ergebnis ist, dass zwanzig Desktops in den Speicher passen, den du sonst für acht oder zehn brauchtest. Auf einem VDI-Host, auf dem jede VM dasselbe Abbild fährt, ist KSM keine nebensächliche Verbesserung. Es ist das, was die Dichte bezahlbar macht.\nbcache. Ist dein Speicher HDD-gestütztes Ceph mit Optane-bcache, ist VDI der beste Fall dafür. Start- und Anmeldestöße sind lese-lastig und wiederholen sich — genau das Muster, das ein Cache aufnimmt. Sobald der Arbeitssatz warm ist, lesen die Desktops mit NVMe-Latenz von der Optane, und die Spindeln bewegen sich kaum. Die Schreibvorgänge sind Änderungen am Benutzerprofil und temporäre Dateien, und die sind klein und sequentiell genug, dass bcaches Writeback sie erledigt, ohne die HDD je zum Engpass zu machen.\nProfile — zwei Möglichkeiten, beide auf Ceph. Benutzerprofile sind die andere Hälfte des VDI-Speichers, und es gibt zwei saubere Wege, sie zu behandeln, ohne den Cluster zu verlassen.\nFSLogix-Profilcontainer sind der übliche Weg, ein Windows-Desktop-Profil wandern zu lassen, und sie laufen auf S3-kompatiblem Objektspeicher. Proxmox-Ceph stellt über das RADOS Gateway einen S3-Zugang bereit, der Profilspeicher liegt also auf demselben Cluster wie die VM-Platten. Kein eigener Dateiserver, keine Rechnung für Azure Files, keine Abhängigkeit nach außen.\nDie andere Möglichkeit ist, FSLogix ganz zu überspringen und die Windows-Ordnerumleitung auf SMB-Freigaben zu nutzen, die von geclustertem Samba auf CephFS bedient werden. Die Desktops leiten Dokumente, Desktop, AppData und den Rest auf eine Samba-Freigabe um, die auf CephFS liegt, und der Samba-Cluster erledigt die Übernahme im Fehlerfall. Überhaupt kein Profilcontainer — die Dateien liegen als einfache Dateien im Dateisystem, und CephFS erledigt die Replikation. Das ist einfacher zu verwalten, einfacher zu sichern und umgeht die FSLogix-Lizenzierung ganz — nützlich, wenn die Lizenzkosten ein Thema sind oder du einfach weniger bewegliche Teile willst. So oder so sitzen die Profile auf deinem eigenen Speicher, gestützt auf denselben Ceph-Pool, und die Kosten sind die Platten, die du schon gekauft hast.\nZwischen KSM, das Speicher zurückholt, bcache, das Speicherlatenz zurückholt, und Profilen, die auf Ceph landen — ob über FSLogix auf S3 oder Ordnerumleitung auf CephFS — bedient ein einzelner Proxmox-Host mit HDDs und bescheidenem RAM mehr Desktops, als das Datenblatt vermuten lässt. Azure berechnet jedes Gigabyte von allen drei. Hier macht die Infrastruktur die Arbeit umsonst.\nSicherung, Belastbarkeit und Nachweispflichten Alles im VDI zu halten ist nicht bloß eine Kostenentscheidung. Es ist eine Entscheidung über Nachweispflichten und Belastbarkeit.\nWenn der Desktop auf dem Server wohnt, wohnen die Daten auf dem Server. Nichts landet auf dem Gerät des Nutzers. Ein gestohlener Laptop ist ein verlorener Bildschirm, kein verlorener Datenbestand. Es gibt keine lokale Platte zu verschlüsseln, keine lokale Kopie hinauszutragen, keinen Endpunkt nach einem Einbruch forensisch zu sichern. Die Daten haben die Infrastruktur, die du beherrschst, nie verlassen.\nDas macht das Sichern schlicht. Die VM-Platten und die Profilspeicher liegen auf Ceph, und Ceph-Momentaufnahmen sind atomar und sofort. Eine Sicherungsregel deckt jeden Desktop und jedes Profil. Einen Desktop auf den Stand von gestern zurückzusetzen ist ein Rückrollen der Momentaufnahme, kein Neubau. Ein Profil zurückzuholen ist derselbe Vorgang auf einem anderen Pool. Das Sicherungsziel ist der Cluster, nicht zwanzig verstreute Endpunkte.\nEs macht auch die Nachweispflichten einfacher. Wo die Daten liegen ist leicht zu belegen, wenn sie auf Hardware liegen, die dir gehört, in einem Rack, auf das du zeigen kannst, in einer Rechtsordnung, die du gewählt hast. Prüfspuren liegen in deinen eigenen Protokollen. Der Zugriff ist durch Cloudflare-Richtlinien geregelt, die du geschrieben hast, angemeldet an einem IdP, den du betreibst, und aufgezeichnet von Systemen, die du beherrschst. Zwischen dir und dem Beleg, nach dem ein Prüfer fragt, steht kein fremder Cloud-Anbieter.\nBelastbarkeit folgt derselben Linie. Eine tote Desktop-VM ist eine neue VM aus dem Goldabbild, mit dem Profil wieder angehängt. Der Nutzer meldet sich neu an, und der Desktop ist zurück. Es gibt keinen Endpunkt neu zu bauen, kein Betriebssystem neu aufzuspielen, keine Hardware zu verschicken. Die Einheit der Wiederherstellung ist die VM, und eine hochzufahren dauert Minuten.\nWas du aufgibst Das ist nicht in jedem Sinn kostenlos. Was Azure Virtual Desktop erledigt und dieser Stapel nicht:\nMicrosoft kümmert sich um Patches und Aktualisierungen. Hier tust du das. Intune und Endpoint Manager binden sich nativ an AVD an. Hier verwaltest du die Windows-VMs selbst oder über die Werkzeuge, die du wählst. Azures Netz ist Azures Problem. Hier ist deine Internetverbindung der Weg zum Desktop. Fällt sie aus, sind die Desktops unerreichbar, bis sie zurück ist. Bei Azure ist Skalieren eine Kreditkarte weit weg. Hier heißt Skalieren, eine weitere Karte oder einen weiteren Host zu kaufen. AVD gibt dem Nutzer den ganzen RDP-Funktionsumfang von Haus aus. Hier kappt der im Browser gerenderte Weg Zwischenablage, Ton und mehrere Bildschirme mit Absicht. Nutzer, die diese Funktionen brauchen, bekommen einen nativen RDP-Client durch denselben Tunnel und dieselbe Richtlinie — aber die Voreinstellung ist der zugesperrte Browser, und das ist die richtige Voreinstellung für eine Belegschaft mit eigenen Geräten. Nichts davon ist nichts. Ob es zählt, hängt davon ab, was du hast: fährst du schon Proxmox, verwaltest du schon Windows und hast du schon jemanden, der einen Hypervisor betreuen kann, dann sind das alles Dinge, die du schon tust. Wenn nicht, verkauft Azure dir das Personal, das du nicht hast, und das ist tatsächlich etwas wert.\nDie Frage ist, ob es 18.000 £ im Jahr für 42 einfache Desktops wert ist — oder 136.000 £ für welche mit GPU — jedes Jahr, plus Netz, Sicherung, IPv4 und Lizenzen obendrauf, mit einem Preis, den jemand anders setzt, Hardware, die jemand anders gehört, und einer Rechnung in einer Währung, die du nicht beherrschst. Oder ob du 5.400 £ im Jahr für Hardware und Strom ausgibst und den Rest behältst.\nDas legt dieser Beitrag dar. Der nächste baut es — den cloudflared-Tunnel, den LXC, die Proxmox-Firewall-Regeln, die Cloudflare-Access-Richtlinie und den laufenden Desktop im Browser-Tab.\nQuellen Preise für Azure Virtual Desktop — Rechenleistung, Speicher und Netz werden getrennt und zusätzlich zum Microsoft-365-Recht berechnet.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nPläne und Preise für Windows 365 — glatt pro Nutzer und Monat, GPU-Konfigurationen in der Enterprise-Stufe.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nPreise für Cloudflare Zero Trust — bis 50 Nutzer kostenlos, ab Nutzer 51 nach Verbrauch.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nDaten der Intel Arc Pro B60 — 24 GB GDDR6, 20 Xe2-Kerne, PCIe 5.0 x8, SR-IOV mit bis zu 7 virtuellen Funktionen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nDaten der Intel Arc Pro B70 — 32 GB GDDR6, 32 Xe2-Kerne, PCIe 5.0 x16, SR-IOV mit bis zu 4 virtuellen Funktionen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nLizenzierung von Windows 11 für virtuelle Desktops — Software Assurance auf einem berechtigenden Betriebssystem (etwa Pro) macht daraus Enterprise und gewährt VDI-Rechte für bis zu vier VMs pro Nutzer auf deinem eigenen Server vor Ort.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://blogs.damiendye.uk/de/networking/zero-trust-vdi-cloudflare-access/","summary":"Teil eins: die Architektur und das Kostenargument dafür, Azure Virtual Desktop durch Proxmox, Intel Arc Pro SR-IOV und Cloudflare Access zu ersetzen. OAuth auf eigener Hardware für die Identität, RDP im Browser gerendert, ein per Firewall eingehegter LXC-Tunnel auf eigenem VLAN, KSM für Speicherdichte und Profile auf Ceph. Der nächste Beitrag baut es.","title":"Zero-Trust-VDI ohne Cloud-Rechnung — Proxmox, Intel Arc Pro und Cloudflare Access"},{"content":"Ping ist keine Diagnose. Es ist ein Tunnel. ICMP Echo (die Anfrage, die eine Maschine sendet, und die Antwort, die sie zurückbekommt) trägt jedes Byte, das du hineinlegst, in beide Richtungen, über ein Protokoll, das die meisten Firewalls durchlassen, ohne hineinzusehen, und das die meiste Protokollierung zählt statt liest. Ein Netz, das „nur Ping erlaubt“, hat schon ein volles, verschlüsselbares VPN nach draußen, und jeder, der dieses Netz erreichen kann, kann eines fahren.\nDas ist alt, und es ist dokumentiert. Loki1 hat die Technik 1996 in Phrack 49 veröffentlicht. Ptunnel2 trägt seit zwanzig Jahren ganze TCP-Sitzungen in Ping und ist auf jeder Linux-Kiste ein Paket entfernt. Kein Zero-Day. Das Protokoll verhält sich genau wie festgelegt.\nDas ist die Ursache: der Standard, kein Fehler in irgendjemandes Produkt. Jeder Host auf der Welt ist verpflichtet, die Daten in einer Echo-Anfrage zu nehmen und sie unverändert direkt zurückzugeben. Beliebige Daten hinein, dieselben Daten heraus: das ist das Ganze, was ein Tunnel braucht, und es ist seit 1981 vorgeschrieben.\nDie Behebung ist eine einzige enge Änderung. Verwirf ICMP Echo, Anfrage und Antwort, auf IPv4 und IPv6, an der Grenze, und behalte jede andere ICMP-Nachricht. Die Fehler — Time Exceeded, Packet Too Big, Destination Unreachable — tragen Last; blockiere die, und du zerstörst Path MTU Discovery und Traceroute für nichts. Das ist also nicht „ICMP blockieren“. Es ist, die eine Nachricht zu verwerfen, die eine Haftung ist, und die zu behalten, die die Wahrheit tragen.\nWas deine Ausgangsregel tatsächlich erlaubt hat Betreibst du ein Netz, in dem ausgehender Verkehr gefiltert wird (und wenn nicht, ist das ein eigenes Gespräch), dann ist das hier die Rechnung für eine Zeile darin. Die Regel, die sagt „blockiere alles ausgehende, erlaube ICMP, weil wir Dinge pingen müssen“, ist keine Ausgangsregel. Es ist ein voller Tunnel, dessen Unterlagen unter Diagnose abgelegt sind. Alles auf der Innenseite, das eine Echo-Anfrage senden und die Antwort lesen kann, kann Daten überallhin auf der Außenseite bewegen, die eine beantwortet, mit der Rate, die die Verbindung hergibt, und an jeder Inhaltskontrolle vorbei, die du gekauft hast. In den Protokollen ist es jemand, der prüft, ob das Internet läuft, und nichts weiter. Schadsoftware liefert das seit Jahren, aus genau diesem Grund. Leise, standardmäßig, und meist schon erlaubt.\nDeshalb ist es ein Kanal erster Wahl für jeden, der schon drinnen ist und nicht drinnen sein sollte. Es ist das Wohnen, nicht der Einbruch mit Aufbruch. Wer einen Weg hinein und heraus sucht, der hält, meidet den Port, der einen Alarm auslöst. Er stellt einen Tunnel auf Echo und lässt ihn monatelang laufen. Ein Host, der viel pingt, ist ein Host, den niemand beobachtet. Zwei-Wege-Vernetzung in den Bestand: Befehl hinein, Daten heraus, über das eine Protokoll, das niemand drosselt, alarmiert oder liest. Und er ist verschlüsselt, wie jedes echte Werkzeug es verschlüsselt, auf dem Draht ist die Nutzlast also die zufällig aussehenden Byte, die ein Ping sowieso trägt, und die Inhaltsprüfung hat nichts zu lesen. Größe und Zeitverlauf können ihn noch verraten, an jemanden, der tatsächlich hinsieht. Ein Blick in das Paket kann es nicht.\nUnd die Maschine, die ihn fährt, muss niemandem gehören, der dort arbeitet. Alles, was es braucht, ist etwas, das dein Netz erreichen und einen Ping auf das Internet legen kann, und dein Netz zu erreichen ist leichter, als irgendwer zugeben mag. Das WLAN trägt über die Wände hinaus, in den Flur, den Parkplatz, die Wohnung darüber. Die Ethernet-Buchse in der Wand des Besprechungsraums, oder an der Rezeption, oder am leeren Schreibtisch am Fenster, ist sehr oft live und spricht mit allem, was du einsteckst, ohne ein 802.1X, das fragt, wer du bist. Ein Signal in Reichweite, oder eine Buchse, die niemand zugesperrt hat. Das ist die Eintrittsgebühr. Kein Ausweis, kein Konto, keine Einladung.\nStell dir den Besucher vor, den du eingeladen hast. Er ist in der Besprechung, freundlich, macht Notizen, trägt bei. Sein Laptop nicht. In dem Moment, in dem er dein Netz erreicht hat, über die Luft oder durch die Buchse unter dem Tisch, war er innerhalb der Wand, und wenn dieses Netz eine Echo-Anfrage abgeben kann, hat er einen Weg hinaus. Nichts wurde auf deinem Bestand abgelegt. Kein Konto, kein Recht auf irgendetwas, das dir gehört, nichts, das deine Endpunkt-Agenten fangen könnten, denn deine Agenten sind nicht auf seiner Maschine. Die Person ist am anderen Ende des Tisches. Der Verkehr verlässt das Haus durch deine Vordertür, verschlüsselt, nicht zu unterscheiden von einem Laptop, der mehr pingt, als er sollte.\nEin Besucher in Signalreichweite oder an einer offenen Buchse bekommt einen Tunnel hinaus, durch eine Firewall, die nur Pings sieht Ein Besucher in Reichweite, oder an einer offenen Buchse, bekommt einen Weg hinaus innerhalb der Wand — dein Netz WLAN reicht in den Flur, Parkplatz, Wohnung darüber Laptop des Besuchers kein Ausweis, kein Konto eine live Wandbuchse kein 802.1X fragt, wer du bist Grenz-Firewall sieht nur Pings Server im Internet Echo-Anfrage\u0026#160;\u0026#8594; \u0026#8592;\u0026#160;Echo-Antwort beliebiger IP-Verkehr, verschlüsselt, in den Pings reitend Die Eintrittsgebühr ist Zugang zum Netz — ein WLAN-Signal in Reichweite, oder eine live Wandbuchse ohne 802.1X —, und der Ausgang ist Echo durch die Grenze. Für die Firewall ist es ein Host, der pingt; in diesen Pings ist beliebiger IP-Verkehr, verschlüsselt, gebunden an einen Server im Internet. Die zwei Dinge, nach denen du greifen wirst, helfen nicht. NAT ist eine Übersetzungstabelle, kein Filter: eine Echo-Anfrage von einem Host innen öffnet eine Abbildung, geschlüsselt auf die ICMP-id, die NAT genau wie einen Port behandelt, und die Antwort kommt darüber zurück wie jeder andere Fluss. Ich habe einen Client hinter meinem eigenen Heim-NAT gefahren, und es hat nie bemerkt, dass das NAT da war. Ein eigenes Gast-VLAN ist nicht besser. Trennung hält den Besucher von deinen Servern fern, aber sie tut nichts, um ihn vom Internet fernzuhalten, und das Internet, mit einem Ping erreicht, ist die ganze Anforderung. Eine Kontrolle berührt das: lässt dieses Netz Echo hinaus?\nDu prüfst das nicht weg, und du trennst es nicht weg. Du schließt die Tür. Alles danach ist, warum der Standard sie offen lässt, drei Wege, den Tunnel zu bauen, damit die Behauptung auf mehr als meinem Wort steht, und die eine Änderung, die ihn schließt.\nDer Teil von ICMP, der dir nichts Nützliches schuldet Fang mit dem an, was der Standard tatsächlich sagt, denn das ganze Argument ruht auf einem Satz, und Leute wischen ihn weg, ohne ihn zu lesen.\nEine Echo-Anfrage trägt ein Datenfeld. In IPv4 stellt RFC 7923 schlicht fest, dass „the data received in the echo message must be returned in the echo reply message“. IPv6 hat die Formulierung verschärft statt gelockert: RFC 44434 definiert das Feld als „zero or more octets of arbitrary data“ und verlangt dann, dass es „MUST be returned entirely and unmodified in the ICMPv6 Echo Reply message“.\nLies das als Betreiber, und es ist ein Keepalive. Lies es als jemand, der Daten bewegt, und es ist ein Geschenk. Der Standard verpflichtet jeden erreichbaren Host, einen Block Byte anzunehmen, den du wählst, und sie dir unverändert direkt zurückzuschicken, auf Verlangen. Beliebige Länge. Beliebiger Inhalt. Kein Handshake, kein Port, keine Anwendung am anderen Ende, die irgendetwas zustimmen muss. Der Kernel tut es, bevor irgendein Userland-Prozess einen Blick hineinbekommt.\nUnd es sind beide Familien. Der Wechsel zu IPv6 räumt das nicht weg. Es öffnet es weiter. RFC 792 sagte, die Daten „must be returned“; RFC 4443 sagt, sie „MUST be returned entirely and unmodified“, und das ist dieselbe Tür mit einem stärkeren Schloss, das sie offen hält. Der Kanal existiert also auf ICMP Echo und auf ICMPv6 Echo gleichermaßen, und eine Regel, die ihn auf einer Familie schließt und nicht auf der anderen, hat nichts geschlossen. Der Tunnel zieht bloß auf die Familie um, die du offen gelassen hast. Was du auch dagegen tust, tu es auf ip und ip6 zusammen.\nNichts sonst im Protokoll tut das. Ein Time Exceeded trägt den Header des Pakets, das gestorben ist, und nicht mehr. Ein Destination Unreachable ist ein Bericht über etwas, das schon passiert ist. Diese Nachrichten sagen dir Tatsachen über das Netz. Echo trägt, was immer du hineinlegst, in beide Richtungen, und nennt es eine Diagnose.\nFehler tragen Last. Echo nicht. Das ist die Unterscheidung, die die „einfach ICMP blockieren“-Fraktion nie macht, und sie ist der ganze Punkt, ich mache sie also einmal und richtig.\nICMP-Fehler zu blockieren zerstört das Netz leise. Filtere Packet Too Big, und du tötest Path MTU Discovery: der Handshake läuft durch, kleine Übertragungen funktionieren, und alles, was ein Paket voller Größe trägt, hängt für immer, ohne etwas in den Protokollen. Auf IPv6 ist das nicht einmal Geschmackssache. Router fragmentieren nicht, RFC 48905 führt Packet Too Big also unter den Nachrichten auf, die eine Firewall „must not drop“, und warnt, dass ohne es „parts of the Internet will become inaccessible“. Filtere Time Exceeded, und du zerstörst Traceroute, das RFC 18126 als den Grund nennt, warum die Nachricht überhaupt Pflicht ist. Diese sind nicht wahlfrei. Sie sind die Rückmeldung, die das Netz selbstkorrigierend macht, und ich habe die Kosten, sie zu verlieren, letztes Mal ausführlich behandelt.\nVerwirf jetzt Echo und geh suchen, was kaputtging. ping über die Grenze hört auf zu funktionieren. Das ist die Liste. Die ganze Liste.\nPath MTU Discovery ist es egal, denn es läuft auf Packet Too Big, und das ist ein Fehler. Traceroute ist es egal, denn traceroute -T und -U laufen über TCP und UDP und lesen die Fehler, die zurückkommen. Nicht eines davon sendet ein Echo. Neighbour Discovery auf IPv6 ist es egal, denn das sind die Typen 133 bis 137, und die behältst du, oder das Segment stirbt. Der Trick mit der Rück-TTL aus dem letzten Beitrag funktioniert auf jeder Antwort, und ein TCP-Handshake gibt dir eine. Alles, was die Diagnosen des letzten Beitrags funktionieren ließ, funktioniert weiter, denn nicht eine Messung darin hat eine Echo-Anfrage gesendet.\nDie zwei Hälften des Protokolls könnten sich also nicht unähnlicher sein. Die eine Hälfte ist das Netz, das dir die Wahrheit über sich selbst sagt, und du zerstörst sie auf eigene Gefahr. Die andere Hälfte ist ein vorgeschriebener Nutzlast-Rückgabedienst, der zufällig Diagnose heißt, und das Stärkste, was irgendwer dafür sagen kann, ihn offen zu halten, ist, dass ping praktisch ist. Es ist praktisch. Es ist auch der einzige Teil von ICMP, den ein Angreifer fahren kann, und ich kann dir genau zeigen, womit sie ihn fahren.\nBehalte die ICMP-Fehler, ratenbegrenzt; verwirf nur Echo, beide Richtungen und beide Familien Zwei Hälften eines Protokolls, und nur eine davon ist eine Haftung BEHALTEN ratenbegrenzen, nie blockieren Destination Unreachable trägt, warum ein Paket nicht zugestellt werden konnte Packet Too Big Path MTU Discovery hängt daran Time Exceeded Traceroute hängt daran Parameter Problem meldet einen fehlerhaften Header Neighbour Discovery 133\u0026#8211;137 IPv6: das lokale Segment hängt daran Zerstöre diese, und das Netz zerbricht leise. VERWERFEN beide Richtungen, beide Familien Echo-Anfrage Typ 8 (IPv4) · Typ 128 (IPv6) Echo-Antwort Typ 0 (IPv4) · Typ 129 (IPv6) Nichts braucht diese außer dem ping -Befehl. Alles, was ein Angreifer durch ICMP fährt, läuft durch sie. Ein Tunnel, auf einer Familie offen gelassen, ist nicht geschlossen. Die ICMP-Fehler tragen Last: Path MTU Discovery, Traceroute und IPv6 Neighbour Discovery hängen alle an ihnen, und sie zu blockieren zerstört das Netz leise. Echo ist der einzige Teil, an dem nichts hängt außer ping, und der einzige Teil, den ein Angreifer fahren kann. Verwirf den, behalte den Rest, auf beiden Familien. Der Beweis: ein VPN aus Ping Das Werkzeug ist Hans7, geschrieben von Friedrich Schöller. Seine eigene Beschreibung ist eine Zeile: es „makes it possible to tunnel IPv4 through ICMP echo packets, so you could call it a ping tunnel.“ Es bringt an jedem Ende ein tun-Interface hoch, gibt ihnen Adressen und bewegt jedes Paket zwischen ihnen innerhalb von ICMP Echo. Für das Netz dazwischen ist es jemand, der einen Server pingt, und der Server, der antwortet. Für mich ist es eine Route.\nEin ganzes IP-Paket reist im Datenfeld eines einzelnen Pings Ein ganzes Paket reitet in einem Ping Das Paket, das deine SSH-Sitzung sendet IP-Header Quelle / Ziel TCP-Header Port 22 Anwendungsdaten deine Tastenanschläge, deine Datei Hans kopiert das ganze Paket in das Echo-Datenfeld Das Paket, das auf dem Draht das Haus verlässt IP-Header du zum Server ICMP-Echo-Anfrage Typ 8 · id · seq Echo-Datenfeld das ganze Paket oben, unverändert Für die Grenz-Firewall ist das eine Echo-Anfrage, und das Protokoll erfasst einen Ping. Im Datenfeld ist ein Paket, gebunden überallhin, wohin das ferne Ende reichen kann. Der Standard verlangt vom fernen Ende, diese Daten direkt zurückzuschicken, die Antwort ist also auch ein Paket. Jedes Paket, das der Tunnel trägt, wird in das Datenfeld einer ICMP-Echo-Anfrage kopiert. Der Standard verpflichtet das ferne Ende, diese Daten unverändert zurückzugeben, die Antwort trägt also auch ein Paket. Die Firewall zählt einen Ping; die Nutzlast geht überallhin, wohin das ferne Ende routen kann. Ich habe es über meine eigene Leitung gefahren, ein Server auf einer öffentlichen Adresse und ein Client hinter meinem Heim-NAT, und echten Verkehr hindurchgeschoben. Keine künstlichen Pings mit gesetztem Flag. Eine SSH-Anmeldung und ein Dateiabruf, in Echo reitend.\nEs ist ein Paket entfernt, wo ich den Server gefahren habe, und es baut sich aus Schöllers Quellcode überall sonst. Der Server muss Linux sein und braucht root, denn ein tun-Gerät zu öffnen und ein rohes ICMP-Socket brauchen es beide. Die Syntax ist bewusst klein:\n# on the server (public IP), pick the tunnel network and a password hans -s 10.8.0.0 -p \u0026#39;\u0026lt;password\u0026gt;\u0026#39; # server takes 10.8.0.1; clients are handed 10.8.0.2 and up # on the client, point it at the server\u0026#39;s public address hans -c \u0026lt;server-public-ip\u0026gt; -p \u0026#39;\u0026lt;password\u0026gt;\u0026#39; Sind beide Enden oben, gibt es an jeder Seite ein neues Interface mit einer Adresse auf dem Tunnelnetz, und es verhält sich wie jede andere Punkt-zu-Punkt-Verbindung:\nNichts an dieser Sitzung weiß, dass sie in Ping steckt. SSH öffnet eine TCP-Verbindung zu 10.8.0.1, der Kernel routet sie hinaus über tun0, Hans wickelt jedes Paket als Nutzlast einer Echo-Anfrage ein, und das ferne Ende wickelt es aus und gibt es an sein eigenes tun0. Die Antwort kommt als Nutzlast einer Echo-Antwort zurück. Soweit es SSH angeht, spricht es über eine gewöhnliche Verbindung. Soweit es die Firewall angeht, hat niemand etwas geöffnet. Ein Host wird gepingt.\nWie es auf dem Draht aussieht Das ist der Teil, der das Argument beendet, sieh dir also die Firewall-Sicht an statt meiner.\nWas wirklich passiert und was die Firewall protokolliert, sind nicht dasselbe Bild Ein Tunnel, zwei Bilder Was wirklich passiert dein Host tun0 · 10.8.0.2 der Server tun0 · 10.8.0.1 überallhin, wohin er reichen kann SSH, Dateiabrufe hinausgeroutet beliebiger IP-Verkehr, durch den Tunnel als gewöhnliche Pakete Was die Grenz-Firewall sieht und protokolliert dein Host 198.51.100.9 der Server 192.0.2.7 Echo-Anfrage Echo-Antwort icmp echo request 198.51.100.9 \u0026gt; 192.0.2.7 icmp echo reply 192.0.2.7 \u0026gt; 198.51.100.9 icmp echo request 198.51.100.9 \u0026gt; 192.0.2.7 ... als Pings gezählt, Inhalt ungelesen Derselbe Draht. Die Firewall sieht nie die Pakete darin. Der Tunnel bewegt echten Verkehr zwischen zwei Hosts und dann hinaus überallhin, wohin der Server reichen kann. An der Grenze ist es nur Echo-Anfrage und Echo-Antwort — die Firewall protokolliert Pings und sieht nie die Pakete, die darin getragen werden. Sitz auf dem äußeren Interface mit tcpdump und fang nur ICMP ein, während die SSH-Sitzung läuft. Kein TCP zu Port 22 überquert die Grenze. Was überquert, ist Echo-Anfrage und Echo-Antwort, hin und her, jede dicker als ein echter Ping, weil sie ein Stück eines TCP-Segments in ihrer Nutzlast trägt:\n# on the boundary, watch only ICMP echo while traffic runs over the tunnel tcpdump -ni \u0026lt;wan-iface\u0026gt; \u0026#39;icmp[icmptype] = icmp-echo or icmp[icmptype] = icmp-echoreply\u0026#39; Lies die zwei Dinge, auf die es in dieser Aufnahme ankommt. Erstens die Nutzlastlängen: ein normaler ping sendet 56 Byte und jede Zeile ist gleich groß, während diese sich unterscheiden und groß ausfallen, weil die Größe des Dings, das du bewegst, in die Größe des Pings durchsickert. Zweitens die Rate: ein Diagnose-Ping ist einer die Sekunde, und das ist eine Flut, weil es eine Datei bewegt. Keins von beiden ist verborgen. Beide sitzen in aller Öffentlichkeit auf einem Protokoll, das sich niemand ansieht.\nUnd das ist der ganze Punkt. Nicht, dass das klug ist oder schwer zu bemerken, wenn man hinsieht. Fast niemand sieht hin, denn die Kiste ist eingestellt, ICMP zu erlauben, die Protokolle zählen es als Pings, und der Alarm wurde auf die Ports abgestimmt, um die sich jemand zu sorgen erinnert hat. Der Verkehr verlässt das Haus wie eine Gesundheitsprüfung, und die Gesundheitsprüfung ist eine Route überallhin, wohin der Server reichen kann.\nEin richtiges Full-Tunnel-VPN, von Hand gebaut Hans beweist, dass der Kanal da ist, aber es macht das Interface und die Adressierung für dich und gibt eine Route zurück, es zeigt dir also nicht ganz, was du gebaut hast. Um zu sehen, dass das ein VPN im vollen Sinn ist — der Verkehr der ganzen Maschine, der über Ping das Haus verlässt, keine Verbindung zwischen zwei benannten Hosts —, setz es von Hand zusammen. icmptunnel8, von Dhaval Kapil, ist das dafür, und seine eigene Beschreibung ist eine einzige Zeile: „Transparently tunnel your IP traffic through ICMP echo and reply packets.“ Dieselbe Idee, tun-Gerät und Echo-Nutzlasten, aber du legst die Verrohrung selbst, und nichts versteckt sich in einer Binärdatei.\nAuf dem Server startest du den Tunnel, bringst das Interface hoch und tust dann das, was das ganze Spiel verrät: sag dem Kernel, selbst keine Pings mehr zu beantworten, damit seine eigenen Echo-Antworten nicht mit denen streiten, die der Tunnel sendet.\nsudo ./icmptunnel -s 10.0.1.1 # server mode; creates tun0, then blocks # from a second shell, bring the interface up (iproute2, not the net-tools the repo ships) sudo ip addr add 10.0.1.1/24 dev tun0 sudo ip addr add 2001:db8:1::1/64 dev tun0 sudo ip link set tun0 mtu 1472 up # 1500 − 20 (IP) − 8 (ICMP); see below # stop the kernel replying to pings — echo now belongs to the tunnel sudo sysctl -w net.ipv4.icmp_echo_ignore_all=1 sudo sysctl -w net.ipv6.icmp.echo_ignore_all=1 # let the server route the client\u0026#39;s packets onward sudo sysctl -w net.ipv4.ip_forward=1 Lies die icmp_echo_ignore_all-Zeile noch einmal, denn sie sagt mehr, als sie aussieht. Dieses Stellrad ist das des Kernels selbst, und es kommt als Verteidigung: setz es, und, in den Worten des Kernels, es „will ignore all ICMP ECHO requests sent to it“9, ein Betreiber kann einen Host also ganz vom Ping-Radar nehmen. Es ist jetzt auf beiden Familien. net.ipv4.icmp_echo_ignore_all seit Jahren, und net.ipv6.icmp.echo_ignore_all später hinzugefügt, um es abzugleichen.10 Der Tunnel legt diesen Verteidigungsschalter aus dem umgekehrten Grund um: da der Kernel Echo nicht mehr selbst beantwortet, sind seine zwei Enden frei, Echo als reinen Transport zu nutzen. Was das Anzeichen ist. Die Leute, die den Stack geschrieben haben, behandeln Echo schon als etwas, das ein Host vernünftigerweise verweigern darf — die Regel in diesem Beitrag trifft dieselbe Entscheidung einmal, an der Grenze, für jeden Host dahinter.\nAuf dem Client bringst du das Interface hoch und zeigst dann die Standardroute hinein. Nicht ein Host, der durch den Tunnel erreicht wird. Alles.\nsudo ./icmptunnel -c \u0026lt;server-public-ip\u0026gt; # client mode; creates tun0 sudo ip addr add 10.0.1.2/24 dev tun0 sudo ip addr add 2001:db8:1::2/64 dev tun0 sudo ip link set tun0 mtu 1472 up # keep the route to the server itself OUT of the tunnel... sudo ip route add \u0026lt;server-public-ip\u0026gt; via \u0026lt;gateway\u0026gt; dev \u0026lt;iface\u0026gt; # ...then send everything else down it sudo ip route replace default dev tun0 Die eigenen client.sh und server.sh des Projekts greifen weiter nach net-tools ifconfig und route. Die ip-Befehle oben sind die iproute2-Entsprechungen und machen dieselbe Aufgabe. Diese Route zum Server ist die Zeile, die Leute vergessen: halte sie aus dem Tunnel heraus, oder die Echo-Pakete, die den Tunnel tragen, versuchen, durch den Tunnel zu reisen, und nichts verlässt das Haus. Alles andere geht jetzt durch tun0, in Echo gewickelt, und erreicht den Server. Ob es weiter geht, ist eine Routing-Entscheidung. Eine einzelne Masquerade-Regel auf dem Server würde es unter der eigenen Adresse des Servers auf das öffentliche Internet legen, und sie ist absichtlich nicht hier, denn der Tunnel ist das, was gezeigt wird, und er braucht sie nicht.\nDas ist ein Full-Tunnel-VPN, aus Ping gebaut, in einer Handvoll Befehle. Jedes Paket, das der Client sendet — Web, DNS, SSH, alles davon — wird in tun0 eingefangen und verlässt das Haus als Echo-Anfrage zum Server, und die Antworten kommen als Echo-Antworten zurück. Eine Maschine in einem Netz, das „nur ICMP erlaubt“, hat gerade ihren gesamten ausgehenden Verkehr an eine Kiste draußen übergeben, und die Grenze hat einen Host protokolliert, der gern pingt.\nSelbst gebaut, in Python Hier ist der Teil, der jeden beunruhigen sollte, der hofft, sich dagegen zu verteidigen, indem er ein Werkzeug erkennt. Weder Hans noch icmptunnel tut etwas, das du nicht selbst an einem Nachmittag schreiben könntest. Öffne ein tun-Gerät, wickle jedes Paket als Nutzlast einer Echo-Anfrage ein, wickle die aus, die zurückkommen. Das ist der ganze Mechanismus, und der nackte Tunnel sind etwa sechzig Zeilen Python aus der Standardbibliothek, mit überhaupt nichts zu installieren. Die Fassung unten legt eine Sache obendrauf: sie verschlüsselt die Nutzlast, und das ist der einzige Teil, der eine Abhängigkeit hereinzieht.\n#!/usr/bin/env python3 # pingvpn.py — a VPN tunnel over ICMP echo, in one short file. # # Not a product. It exists to show the channel is trivial to rebuild, so a # defence that hunts for a known tool is chasing the wrong thing entirely. # Linux, needs root (a tun device and a raw ICMP socket both do), and the # `cryptography` package for the AES (pip install cryptography). # # server: sudo python3 pingvpn.py --server # client: sudo python3 pingvpn.py --client \u0026lt;server-public-ip\u0026gt; # # The payload is encrypted with AES-128-GCM under a pre-shared key before it # goes on the wire, so what a firewall sees in the echo data is random bytes — # the same as a real ping\u0026#39;s padding, and nothing for content inspection to read. import argparse import fcntl import hashlib import os import select import socket import struct import sys from cryptography.hazmat.primitives.ciphers.aead import AESGCM TUNSETIFF = 0x400454CA IFF_TUN = 0x0001 IFF_NO_PI = 0x1000 MAGIC = 0x4954 # \u0026#39;IT\u0026#39; in the id field, so we ignore real pings ECHO_REQUEST = 8 ECHO_REPLY = 0 PSK = b\u0026#34;change-me-to-a-shared-secret\u0026#34; # pre-shared secret, both ends KEY = hashlib.sha256(PSK).digest()[:16] # 128-bit key -\u0026gt; AES-128-GCM AEAD = AESGCM(KEY) def open_tun(name=b\u0026#34;tun0\u0026#34;): fd = os.open(\u0026#34;/dev/net/tun\u0026#34;, os.O_RDWR) fcntl.ioctl(fd, TUNSETIFF, struct.pack(\u0026#34;16sH\u0026#34;, name, IFF_TUN | IFF_NO_PI)) return fd def encrypt(data): # -\u0026gt; nonce || ciphertext+tag nonce = os.urandom(12) return nonce + AEAD.encrypt(nonce, data, None) def decrypt(blob): # raises on a packet that is not ours return AEAD.decrypt(blob[:12], blob[12:], None) def checksum(data): if len(data) % 2: data += b\u0026#34;\\x00\u0026#34; total = sum(struct.unpack(\u0026#34;!%dH\u0026#34; % (len(data) // 2), data)) total = (total \u0026gt;\u0026gt; 16) + (total \u0026amp; 0xFFFF) total += total \u0026gt;\u0026gt; 16 return ~total \u0026amp; 0xFFFF def build_echo(icmp_type, payload): head = struct.pack(\u0026#34;!BBHHH\u0026#34;, icmp_type, 0, 0, MAGIC, 0) csum = checksum(head + payload) return struct.pack(\u0026#34;!BBHHH\u0026#34;, icmp_type, 0, csum, MAGIC, 0) + payload def main(): ap = argparse.ArgumentParser(description=\u0026#34;a VPN tunnel over ICMP echo\u0026#34;) group = ap.add_mutually_exclusive_group(required=True) group.add_argument(\u0026#34;--server\u0026#34;, action=\u0026#34;store_true\u0026#34;) group.add_argument(\u0026#34;--client\u0026#34;, metavar=\u0026#34;SERVER_IP\u0026#34;) args = ap.parse_args() out_type = ECHO_REQUEST if args.client else ECHO_REPLY in_type = ECHO_REPLY if args.client else ECHO_REQUEST peer = args.client # None on the server until a client is seen tun = open_tun() sock = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_ICMP) print(\u0026#34;tun0 created. bring it up with an address and route, then send traffic.\u0026#34;, file=sys.stderr) while True: readable, _, _ = select.select([tun, sock], [], []) if tun in readable: # a packet wants to leave this host packet = os.read(tun, 65535) if peer: sock.sendto(build_echo(out_type, encrypt(packet)), (peer, 0)) if sock in readable: # something arrived over ICMP data, _ = sock.recvfrom(65535) ihl = (data[0] \u0026amp; 0x0F) * 4 # skip the IP header the kernel adds icmp = data[ihl:] if len(icmp) \u0026lt; 8 or icmp[0] != in_type or icmp[4:6] != struct.pack(\u0026#34;!H\u0026#34;, MAGIC): continue try: packet = decrypt(icmp[8:]) # wrong key or a real ping -\u0026gt; skip except Exception: continue if args.server: peer = socket.inet_ntoa(data[12:16]) # reply to whoever sent os.write(tun, packet) # hand the carried packet to the stack if __name__ == \u0026#34;__main__\u0026#34;: main() Das ist der ganze Tunnel. Er öffnet tun0 und ein rohes ICMP-Socket und schiebt Pakete zwischen ihnen: was den Host verlässt, wird als Echo-Anfrage gewickelt, oder auf dem Server als Echo-Antwort, und an das ferne Ende gesendet; was über ICMP ankommt, wird ausgewickelt und dem Stack zurückgegeben. Das id-Feld ist auf einen Wert festgenagelt, damit es über echte Pings hinwegsteigt, und der Server lernt aus der Quelle des ersten Pakets, das er sieht, wohin er antworten soll.\nDie Verschlüsselung ist der Punkt, bei dem es sich zu verweilen lohnt, denn sie ist, was echte Werkzeuge tun, und sie ist, warum du das nicht fängst, indem du in das Paket siehst. Die Nutzlast wird mit AES-128-GCM unter einem vorab geteilten Schlüssel versiegelt, bevor sie gewickelt wird, die Byte im Echo-Datenfeld sind also nicht von der zufälligen Füllung zu unterscheiden, die ein echter ping trägt. Streich die zwei Krypto-Zeilen heraus, und der Tunnel läuft weiter auf nichts als der Standardbibliothek — der einzige Grund, warum er pip install cryptography braucht, ist das AES, und das AES ist genau der Teil, der einen lesbaren Tunnel in einen unlesbaren verwandelt. Bring ihn genauso hoch wie zuvor, ohne die Masquerade. Du brauchst sie nicht, um den Punkt zu beweisen:\n# server: start it (creates tun0, then blocks), then configure from the same shell sudo python3 pingvpn.py --server \u0026amp; sudo ip addr add 10.9.0.1/24 dev tun0 sudo ip addr add 2001:db8:9::1/64 dev tun0 sudo ip link set tun0 mtu 1400 up sudo sysctl -w net.ipv4.icmp_echo_ignore_all=1 sudo sysctl -w net.ipv6.icmp.echo_ignore_all=1 # client sudo python3 pingvpn.py --client \u0026lt;server-public-ip\u0026gt; \u0026amp; sudo ip addr add 10.9.0.2/24 dev tun0 sudo ip addr add 2001:db8:9::2/64 dev tun0 sudo ip link set tun0 mtu 1400 up sudo sysctl -w net.ipv4.icmp_echo_ignore_all=1 sudo sysctl -w net.ipv6.icmp.echo_ignore_all=1 sudo ip route add \u0026lt;server-public-ip\u0026gt; via \u0026lt;gateway\u0026gt; dev \u0026lt;iface\u0026gt; sudo ip route replace default dev tun0 Der Grund, es auszuschreiben, ist nicht das Werkzeug. Es ist, dass das Werkzeug wegwerfbar ist. Eine kurze Datei, keine Abhängigkeiten, bis du die Verschlüsselung hinzufügst, und jede Kopie, die jemand tippt, sieht auf dem Draht ein wenig anders aus. Eine Signatur, die diese eine fängt, fängt also nächste Woche nichts. Du kannst dich hier nicht herausblockieren, indem du die Software benennst, denn es gibt keine Software zu benennen.\nEs braucht nicht einmal eine Shell. Die Logik ist Byte hinein, Byte heraus, es portiert sich also auf alles, das ein Socket öffnen kann. Selbst WebAssembly: der Browser-Sandkasten verweigert einer Seite ein rohes Socket normalerweise rundweg, aber wo diese Barriere aufgehoben ist (ein Browser, dem der Nutzer die Erlaubnis erteilt hat, auf einer Maschine, wo der Nutzer mit Rechten genug läuft, dass ein rohes Socket geöffnet werden kann), läuft dasselbe kurze Programm in einem Tab. Was die unbequeme Hälfte davon ist. Du kannst deinen Nutzern hier nicht vertrauen. Der Host, der den Tunnel fährt, ist auf der Innenseite, gehalten von jemandem, den du für sicher hieltest, weil er hinter der Firewall sitzt, und die Firewall ist das, wodurch getunnelt wird. Perimeter-Vertrauen nimmt an, die Bedrohung sei außerhalb der Wand. Diese fängt innerhalb an, jedes Mal.\nAchte auf die MTU, und IPv6\u0026rsquo; Boden von 1280 Der Tunnel ist auf dem Draht nicht kostenlos. Jedes Paket, das du trägst, gewinnt einen äußeren IP-Header und einen ICMP-Header, bevor es das Haus verlässt, das innere Interface muss also unter dem sitzen, was der Pfad tragen kann. Auf IPv4 kostet das den Angreifer fast nichts. Setz die innere MTU niedrig (icmptunnels 1472 sind 1500 weniger 20 für den äußeren IP-Header und 8 für den ICMP-Header, und das Python oben fällt auf 1400 für Spielraum), und wo die Zahl noch falsch ist, fragmentiert IPv4 das übergroße Paket und setzt es am fernen Ende wieder zusammen, statt es zu verwerfen. Zwischen dem niedrigen Boden, den du wählen kannst, und der Fragmentierung, die über den Rest hinwegtapeziert, läuft der Tunnel über fast jeden Pfad. Genau diese Nachgiebigkeit macht IPv4 zum bequemen Ort dafür.\nIPv4' Fragmentierung und MTU-Spielraum lassen den Tunnel überall laufen; IPv6 hat keins von beiden, es scheitert also geschlossen Warum er auf IPv4 überall läuft und auf IPv6 geschlossen scheitert IPv4 IP-Hdr 20 B ICMP 8 B inneres Paket tun MTU 1472 B Zu groß? IPv4 fragmentiert und setzt wieder zusammen \u0026#8212; der Tunnel läuft über fast jeden Pfad. IPv6 IPv6-Hdr 40 B ICMPv6 8 B inneres Paket kann nicht unter 1280 B 1280 B harter Boden (RFC 8200) Zu groß? IPv6-Router verwerfen es, keine Fragmentierung \u0026#8212; der Tunnel scheitert geschlossen. IPv4' Rückfalllösungen \u0026#8212; ein Boden, den du wählen kannst, Fragmentierung für den Rest \u0026#8212; machen den Tunnel verlässlich. IPv6 hat keins von beiden, der Angriff, der auf IPv4 fast überall läuft, ist auf IPv6 also zerbrechlich. Die sicherere Familie hier. Packet Too Big \u0026#8212; ein Fehler, den du behältst, kein Echo \u0026#8212; lässt einen Sender die passende Größe finden. Nicht maßstabsgetreu. Der Tunnel verliert von jedem Paket einen äußeren IP- und ICMP-Header. IPv4 lässt dich die innere MTU abschaben und fragmentiert, was noch zu groß ist, es läuft also fast überall; IPv6 setzt einen harten Boden von 1280 Byte, und seine Router fragmentieren nicht, ein übergroßes Paket wird also verworfen und der Tunnel scheitert geschlossen — was IPv6 hier zur sichereren Familie macht. IPv6 ist weniger nachgiebig, und ausnahmsweise ist das auf deiner Seite. Der Boden ist hart: RFC 820011 §5 verlangt, dass „every link in the Internet have an MTU of 1280 octets or greater“, und IPv6-Router fragmentieren nicht unterwegs. Das nimmt beide Rückfalllösungen von IPv4 auf einmal, und es beißt den Tunnel in beide Richtungen. Fahr ihn über ICMPv6, und jede Verbindung auf dem Pfad muss 1280 tragen, ein Pfad, der darunter fällt, nimmt also den Transport herunter, und es gibt kein Abschaben unter dem Boden, wie du es auf IPv4 kannst. Trag IPv6 innerhalb des Tunnels, und du triffst dieselbe Wand von der anderen Seite: das innere Interface kann auch nicht unter 1280, während der äußere ICMPv6-Umschlag, 40 Byte Header und 8 ICMPv6, das Budget schon ausgibt, der Pfad muss also 1280 plus den Overhead erübrigen. Verfehl es an einer der beiden Stellen, und das Paket wird verworfen, nicht auf Größe geschnitten: der Tunnel kommt hoch, kleine Dinge funktionieren, alles voller Größe hängt. IPv6 ist hier also die sicherere Familie, nicht die riskantere. Der Angriff, der auf IPv4 über fast alles läuft, ist auf IPv6 zerbrechlich und scheitert geschlossen. Sicherer ist nicht dasselbe wie sicher, wohlgemerkt: der Echo-Kanal ist auch auf IPv6 offen, die Regel verwirft ihn also weiter auf beiden Familien — der Angreifer kann sich bloß nicht auf IPv6 lehnen, wie er sich auf IPv4 lehnt.\nDie Erholung davon ist der ICMP-Fehler, den zu behalten du sorgfältig warst. Packet Too Big ist, was einen Sender die funktionierende Größe finden lässt, und es ist ein Fehler, kein Echo, die Regel, für die dieser Beitrag argumentiert, lässt es also in Ruhe. Verwirf den Tunnel und behalte die Diagnosen — das ist der ganze Entwurf, und die MTU ist eine weitere Stelle, an der er sich bezahlt macht.\nDie Regel, auf Echo verengt Der letzte Beitrag gab das volle Transit-Regelwerk: erlaube die Fehler unter einer Ratenbegrenzung, verwirf das Echo. Ich drucke es nicht neu. Die Änderung, für die dieser Beitrag argumentiert, ist ein Paar Zeilen, und es ist das Paar, das die Arbeit macht:\n# permit the ICMP errors — these are load-bearing, keep them ip protocol icmp icmp type { destination-unreachable, time-exceeded, parameter-problem } \\ limit rate 100/second accept ip6 nexthdr ipv6-icmp icmpv6 type { destination-unreachable, packet-too-big, \\ time-exceeded, parameter-problem } limit rate 100/second accept # drop the tunnel — echo, both directions, both families ip protocol icmp icmp type { echo-request, echo-reply } drop ip6 nexthdr ipv6-icmp icmpv6 type { echo-request, echo-reply } drop Die Regel ist aber nicht die von Linux. Es ist dieselbe Absicht auf jeder Firewall, die den Namen wert ist: erlaube die Fehler, deckle ihre Rate, verwirf Echo in beide Richtungen auf beiden Familien. Hier ist sie also in den Dialekten, die du eher in der Hand hältst.\nBSD pf (pfSense, OPNsense, OpenBSD, FreeBSD):\n# permit the errors; block echo both directions, both families pass in proto icmp icmp-type { unreach, timex, paramprob } pass in proto icmp6 icmp6-type { unreach, toobig, timex, paramprob, \\ routersol, routeradv, neighbrsol, neighbradv } block in proto icmp icmp-type { echoreq, echorep } block in proto icmp6 icmp6-type { echoreq, echorep } Behalte die Neighbour-Discovery-Typen auf der icmp6-Zeile; das sind die, die das Segment herunternehmen, wenn du sie verlierst.\nCisco IOS (erweiterte ACLs, an der Kante angewandt):\nip access-list extended ICMP-EDGE permit icmp any any unreachable permit icmp any any time-exceeded permit icmp any any parameter-problem deny icmp any any echo deny icmp any any echo-reply ! ipv6 access-list ICMP6-EDGE permit icmp any any packet-too-big permit icmp any any unreachable permit icmp any any time-exceeded permit icmp any any parameter-problem permit icmp any any nd-ns permit icmp any any nd-na deny icmp any any echo-request deny icmp any any echo-reply Auf IPv4 ist der Echo-Typ echo; auf IPv6 ist es echo-request. Die Ratenbegrenzung wohnt in CoPP, nicht in der ACL.\nJuniper Junos (Firewall-Filter; der inet6-Filter spiegelt das und behält Neighbour Discovery):\nfirewall family inet filter icmp-edge { term errors { from { protocol icmp; icmp-type [ unreachable time-exceeded parameter-problem ]; } then { policer icmp-cap; accept; } } term drop-echo { from { protocol icmp; icmp-type [ echo-request echo-reply ]; } then discard; } } MikroTik RouterOS — verwirf die zwei Echo-Typen, dann akzeptiere den Rest von ICMP, was die Fehler behält und, auf v6, Neighbour Discovery:\n/ip firewall filter add chain=forward protocol=icmp icmp-options=8:0 action=drop comment=\u0026#34;echo request\u0026#34; add chain=forward protocol=icmp icmp-options=0:0 action=drop comment=\u0026#34;echo reply\u0026#34; add chain=forward protocol=icmp action=accept comment=\u0026#34;keep the errors (add limit= to cap)\u0026#34; /ipv6 firewall filter add chain=forward protocol=icmpv6 icmp-options=128:0 action=drop comment=\u0026#34;echo request\u0026#34; add chain=forward protocol=icmpv6 icmp-options=129:0 action=drop comment=\u0026#34;echo reply\u0026#34; add chain=forward protocol=icmpv6 action=accept comment=\u0026#34;keep errors and ND\u0026#34; Andere Syntax, eine Regel. Erlaube die Nachrichten, die die Wahrheit tragen, verwirf die, die deine Byte trägt.\nZwei Warnungen, die dich beide beißen werden, wenn du überfliegst.\nVerwirf Echo an der Grenze, nicht auf dem Draht zwischen einem Host und seinem eigenen Router. Auf IPv6 ist Neighbour Discovery ICMP — Typen 133 bis 137, nd-router-solicit bis nd-redirect — und es ist, wie das Segment die Aufgabe erledigt, die ARP in IPv4 erledigt. Trag ein Echo-Verwerfen auf eine Link-Local- oder Host-Kette, ohne die zu behalten, und das Segment hört innerhalb von Minuten auf zu funktionieren, und es wird nicht wie ein Firewall-Fehler aussehen. Filtere Echo, wo der Verkehr dein Netz verlässt, und lass die internen Ketten in Ruhe.\nVerwirf es in beide Richtungen, und es hört so oder so auf, nützlich zu sein. Nur die Anfrage zu blockieren stoppt, dass deine Hosts gepingt werden, lässt aber noch eine Antwort hinaus, und ein Tunnel kann mit ein wenig mehr Aufwand allein auf Antworten gebaut werden. Verwirf Anfrage und Antwort, auf IPv4 und IPv6, und der Kanal ist in beide Richtungen geschlossen.\nWas Ping zu verwerfen dich tatsächlich kostet Sei ehrlich über den Verlust, denn eine Kontrolle, die du überverkauft hast, ist eine Kontrolle, die jemand leise rückgängig macht, sobald es unbequem ist.\nDu verlierst ping über die Grenze. Das ist die Kosten, voll ausgesprochen. Es ist eine echte Kosten. ping ist der Reflex, es ist in jedermanns Fingern, und am Tag, nachdem du das ausgeliefert hast, wird jemand sagen, das Internet sei unten, weil sein Ping zum Gateway abläuft. Es ist nicht unten. Du hast dem Gateway gesagt, eine Anfrage nicht mehr zu beantworten, die immer nur eine Bequemlichkeit war.\nErreichbarkeitstests brauchen kein Echo. Eine TCP-Verbindung zu einem Port, von dem du weißt, dass er offen ist, sagt dir, dass der Host oben ist und der Pfad funktioniert, und sagt dir mehr als ein Ping, denn es beweist, dass ein Dienst geantwortet hat, nicht bloß ein Kernel:\n# \u0026#34;is it up and reachable?\u0026#34; without sending a single echo nc -zv \u0026lt;host\u0026gt; 443 # did the TCP handshake complete? traceroute -T -p 443 \u0026lt;host\u0026gt; # walk the path on TCP, read the errors back Beide reiten auf den ICMP-Fehlern, die du behalten hast, und dem TCP, das ein echter Dienst schon spricht. Keins sendet ein Echo. Der ehrliche Handel ist also der: du gibst das am wenigsten aussagende Werkzeug im Kasten auf, das, das „ist ein Kernel bereit zu antworten“ beantwortet und nichts weiter, und dafür schließt du den einzigen Teil von ICMP, den ein Angreifer in eine Route aus deinem Netz verwandeln kann. Die Diagnosen, nach denen du an einem schlechten Tag tatsächlich greifst, sind alle auf der anderen Seite der Linie, unberührt.\nEin Fisher-Price-Betriebssystem (Windows) ist kein Ausweg hieraus Betreibst du einen Laden mit einem Fisher-Price-Betriebssystem (Windows), liest du das vielleicht als jemand anderes Problem. Ist es nicht. Die Haftung liegt im Protokoll, nicht im Betriebssystem. Der Standard verpflichtet jeden Host, der einen Ping beantwortet, deine Byte zurückzugeben, und er hält nicht inne, um zuerst zu fragen, was der Host fährt.\nEine Kiste auf diesem Betriebssystem macht einen völlig guten Tunnelendpunkt. Hans liefert einen Windows-Client, eine Maschine innen kann also das Client-Ende sein und ihren Verkehr in Echo hinausgeben wie jede andere. Was sie nicht leicht sein kann, ist das Server-Ende, denn das will ein tun-Gerät und ein rohes ICMP-Socket offen gehalten, und auf diesem Betriebssystem können nur Mitglieder der Administratoren-Gruppe Sockets vom Typ SOCK_RAW anlegen12 — Microsofts eigene Worte. Der Server sitzt also auf einem echten Betriebssystem, wie meiner, und die Kiste hinter der Firewall, die sich leise hinauspingt, ist die, von der dir gesagt wurde, sie sei sicher, weil sie auf der Innenseite war.\nDas ist der Punkt für jeden, der es verteidigt. Die Grenzregel kümmert sich nicht, was das Innere fährt. Verwirf Echo, wo der Verkehr das Netz verlässt, und jeder Host dahinter ist abgedeckt — die, die du verwaltest, und die, von der dir versichert wurde, sie verstecke sich hinter NAT. Ich fahre das Ding nicht, und ich werde nicht so tun, als achte der Tunnel es. Die Behebung ist dieselbe Regel, an derselben Stelle, in was der Endpunkt auch gebootet ist.\nIst die Kiste selbst das, was du härtest (die Kiste, nicht das Netz), wird PowerShell sie zumindest davon abhalten, einen Ping auf eigene Rechnung zu beantworten oder abzugeben:\nforeach ($t in 8,0) { New-NetFirewallRule -DisplayName \u0026#34;Drop ICMPv4 Echo $t\u0026#34; -Protocol ICMPv4 -IcmpType $t -Direction Inbound -Action Block } foreach ($t in 128,129) { New-NetFirewallRule -DisplayName \u0026#34;Drop ICMPv6 Echo $t\u0026#34; -Protocol ICMPv6 -IcmpType $t -Direction Inbound -Action Block } Füg -Direction Outbound-Zwillinge hinzu, um sie davon abzuhalten, als Tunnel-Client hinauszugreifen, statt als Ziel dazusitzen, und lass die ICMPv6-Fehler- und Neighbour-Discovery-Typen in Ruhe, aus dem Grund, aus dem sie überall sonst auf dieser Seite in Ruhe gelassen werden. Aber halte es nicht für die Kontrolle. Eine Host-Firewall ist keine Transit-Firewall. Sie härtet die Kiste und ändert nichts an der Grenze, und die Grenze ist, wo das tatsächlich geschlossen wird.\nSprich das heute mit dem an, der deine Grenze betreibt Du hast das wahrscheinlich bis hierher gelesen und dabei an ein Netz gedacht, das nicht deins zu ändern ist. Die meisten Leute tun das. Das Nützliche ist also nicht, nach der Firewall zu greifen, es ist, die Frage dem zu stellen, der sie hält — deinem eigenen Netzteam, deinem MSP, oder dem Hersteller, dessen Kiste an der Kante sitzt —, und sie heute zu stellen, denn das ist seit 1996 eine offene Tür, und eine weitere Woche davon ist eine Entscheidung.\nFrag klar, und frag mit einem leeren Blick rechnend, denn ich würde die ganze Wirtschaftsleistung des Vereinigten Königreichs darauf wetten, dass niemand dort Echo einen zweiten Gedanken geschenkt hat. Es ist das eine Paket, das jeder erlaubt und niemand besitzt, und eine Regel, die niemand besitzt, ist genau die, die seit Jahren falsch dasitzt, ohne dass jemand es bemerkt.\nFrag sie vier Dinge, in diesen Worten, damit kein Raum bleibt, zuzunicken und nichts zu ändern:\nVerwerfen wir ICMP Echo-Anfrage und Echo-Antwort an der Grenze, auf IPv4 und IPv6 beide? Nicht „erlauben wir ICMP“ — die bestimmte Nachricht, beide Richtungen, beide Familien. Ist die Antwort nur eine Familie, ist es keine Antwort, denn der Tunnel zieht bloß auf die andere. Erlauben wir weiter die ICMP-Fehler? Destination Unreachable, Time Exceeded, Parameter Problem, und Packet Too Big auf IPv6, unter einer Ratenbegrenzung statt einer Sperre. Können sie es nicht sagen, stehen die Chancen gleich, dass sie entweder alles offen gelassen oder alles blockiert haben, und beides ist falsch. Haben wir IPv6 Neighbour Discovery auf den internen Ketten behalten? Typen 133 bis 137. Das ist das, was „wir haben ICMP gehärtet“ in ein Segment verwandelt, das eine Woche später leise stirbt, und es ist der Fehler, den eine hastige Änderung macht. Zeig mir die Regel. Keine Grundsatzaussage, die tatsächliche Zeile auf der tatsächlichen Kiste, und das Datum, an dem sie draufkam. Eine Kontrolle, auf die niemand zeigen kann, ist eine Kontrolle, die nicht da ist. Wird die Kiste vom Hersteller schon so geschlossen angekommen sein? Wird sie nicht. Die Voreinstellung fast überall ist, Echo durchzulassen und es als Paketzahl zu erfassen, was der ganze Grund ist, warum der Tunnel überhaupt funktioniert. Es nutzt keinen Fehler aus, es nutzt die Konfiguration, die als Standard ausgeliefert wird. Niemand schließt eine Tür, von der ihm nie gesagt wurde, dass sie offen war.\nDer Grund, auf der Wortwahl zu bestehen, ist, dass die faule Behebung zu diesem Beitrag „gut, wir blockieren ICMP“ ist, und diese Behebung ist schlimmer als das Loch. Sie zerstört Path MTU Discovery und Traceroute, sie wird dich hängenden Übertragungen nachjagen lassen, ohne etwas in den Protokollen, und auf IPv6 nimmt sie Teile des Internets ganz vom Tisch. Greift die Person, die du fragst, danach, halte sie auf. Die Anweisung ist mit Absicht eng: verwirf Echo, behalte die Fehler, behalte Neighbour Discovery. Damit sollte jeder, der Firewalls beruflich betreibt, diese Änderung an einem Nachmittag machen und dir sagen können, dass sie erledigt ist.\nUnd sind sie ein MSP, den du bezahlst, das zu betreiben: ein Lieferant, der dir deine eigene Echo-und-Fehler-Haltung nicht aus dem Kopf sagen kann, oder der „wir blockieren ICMP“ antwortet, als wäre das die sichere Wahl, hat dir gerade etwas über den Rest des Bestands gesagt. Das nächste Mal, wenn ein Fehler zwischen zwei Netzen sitzt und beide sagen, sie seien sauber, erinnere dich, welches von ihnen nicht beschreiben konnte, was seine eigene Firewall mit einem Ping macht.\nDie Diagnose, die nie eine Diagnose war Ping hatte einen guten Lauf. Mike Muuss hat es 1983 geschrieben, um zu prüfen, ob ein Host antwortet, hat es nach dem Sonar benannt, und es machte diese eine Aufgabe so gut, dass es das Erste wurde, nach dem jeder greift, und das Letzte, das irgendwer hinterfragt. Vierzig Jahre später ist es Muskelgedächtnis, und Muskelgedächtnis ist genau, wie eine Haftung überlebt. Niemand prüft das, was er schon immer getan hat, neu.\nAber sieh an, was es tatsächlich ist, der Gewohnheit entkleidet. Eine Nachricht, die keine Tatsache über das Netz trägt, die jeder Host mit deinen eigenen Byte zurückzugeben verpflichtet ist, die über ein Protokoll läuft, das die Kontrollen nicht prüfen und die Protokolle nicht lesen. Alles, was es harmlos wirken lässt — es ist nur eine Diagnose, es ist nur ein Keepalive, jeder erlaubt es —, ist dasselbe, das es zum saubersten Weg von einem gefilterten Netz macht, den es gibt. Die Branche blockiert die ICMP-Fehler, die die Wahrheit tragen und das Netz zerstören, wenn sie weg sind, und winkt Echo durch, das trägt, was immer du hineinlädst. Sie hat das Protokoll genau verkehrt herum.\nDie Behebung ist nicht klug. Behalte die Nachrichten, die dir die Wahrheit sagen, und verwirf die, die bloß deine Byte zurückgibt. Sie kostet dich einen Befehl, dem für eine Diagnose zu vertrauen du ohnehin kein Recht hattest, und sie schließt eine Tür, die seit 1996 offen steht, dokumentiert in einem Hacker-Magazin, seit zwei Jahrzehnten verpackt und weit gelassen, weil sie zu schließen hieße, jemand könnte nicht pingen. Wisse, was ein Ding kostet, nicht, was es ausgezeichnet ist. Ping ist mit nichts ausgezeichnet. Es kostet dich den einen Kanal, den du nicht sehen kannst.\nLoki, Phrack 49 — ein Befehlskanal, getragen in ICMP-Echo-Nutzlasten, 1996.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nPtunnel — trägt eine TCP-Sitzung in ICMP Echo.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 792 — ICMP: „the data received in the echo message must be returned in the echo reply message“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 4443 — ICMPv6: Echo-Daten „MUST be returned entirely and unmodified in the ICMPv6 Echo Reply message“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 4890 — die ICMPv6-Nachrichten, die eine Firewall nicht verwerfen darf.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 1812 — Router-Anforderungen: Time Exceeded ist ein MUSS, benannt nach Traceroute.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nHans — IP-über-ICMP-Echo-Tunnel, von Friedrich Schöller.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nicmptunnel — tunnelt IP-Verkehr durch ICMP-Echo- und -Antwort-Pakete, von Dhaval Kapil.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nLinux-Kernel — IP sysctl — icmp_echo_ignore_all: „the kernel will ignore all ICMP ECHO requests sent to it“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nLinux-Commit e6f86b0f — „ipv6: Add icmp_echo_ignore_all support for ICMPv6“ — die IPv6-Entsprechung, von Virgile Jarry.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 8200 §5 — IPv6 verlangt, dass jede Verbindung eine MTU von mindestens 1280 Oktetten hat.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMicrosoft — TCP/IP raw sockets — „only members of the Administrators group can create sockets of type SOCK_RAW“.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://blogs.damiendye.uk/de/networking/ping-the-diagnostic-tool-that-opens-a-whole-lot-more/","summary":"Ping, nicht der Rest von ICMP, ist die Haftung: Echo ist ein Kanal, den jeder Host mit deinen eigenen Byte beantworten muss, ein Netz, das ‚nur Ping erlaubt‘, hat also schon ein volles VPN nach draußen. Der Beitrag geht zuerst die Bedrohung durch — was sie deinen Ausgang kostet, und wie ein Besucher in deinem WLAN oder an einer offenen Ethernet-Buchse eines öffnet —, dann drei funktionierende Tunnel allein auf Ping (Hans, icmptunnel und ein kurzer Python-Tunnel mit AES-128), die MTU- und IPv6-Fallen, und die Regel, die es schließt: Echo verwerfen, die Fehler behalten, in nftables, pf, Cisco, Junos, MikroTik und Windows.","title":"Ping: das Diagnosewerkzeug, das viel mehr öffnet"},{"content":" Is Your MSP Lying To You — 3 parts\nBelügt dich dein MSP, um dir Premium-Produkte zu verkaufen?you are here Was dein MSP dir gebaut hat, und wer sonst noch drankommt Wenn es kaputtgeht, wer trägt es dann wirklich? Kurze Antwort: manche schon.\nDie längere Antwort ist schlimmer, und sie ist die, die deine Zeit wert ist. Die meisten müssen nie lügen, weil das Arrangement es für sie erledigt. Sie werden von den Herstellern bezahlt, deren Produkte sie empfehlen, zu Sätzen, die sich danach richten, welches Produkt du nimmst und wie viel davon verbraucht wird, und niemand ist verpflichtet, davon ein Wort zu erwähnen. Setz ein Unternehmen dreißig Jahre lang in diese Lage und Unehrlichkeit wird überflüssig. Die Auswahlliste schreibt sich von selbst.\nVon deinem Platz aus, am empfangenden Ende der Rechnung, kosten eine Lüge und ein manipuliertes Verfahren genau dasselbe.\nIn diesem Teil geht es um den Verkauf: wer die Person bezahlt, die dich berät, was es nie auf die Auswahlliste schafft, warum die bessere Antwort die ist, die sie dir nicht anbieten, und was du still und leise mietest. Teil zwei handelt davon, was gebaut wird, sobald die Papiere unterschrieben sind, und wer sonst noch drankommt. Teil drei handelt davon, wer es trägt, wenn das Ding umfällt, und was das Gehen kostet. Einiges davon habe ich selbst mit angesehen. Der Rest steht mit dem Namen einer Aufsichtsbehörde im öffentlichen Protokoll, und jede Behauptung hier trägt einen Link.\nNichts davon setzt voraus, dass du technisch bist. Du musst nur fragen.\nDie einfache Lösung ist das Anzeichen Nimm einen häufigen Fall. Ein Heimarbeiter bekommt seinen Laptop nicht dazu, einen VPN-Tunnel ins Büro zu halten. Der Dienstleister schaut es sich an und kommt mit etwas zurück, das der Kunde am Heimende ändern soll. Nicht an ihrem Ende. Am Heimende.\nDer Tunnel ist L2TP über IPsec auf eine Cisco Meraki MX, und was tatsächlich nicht stimmt, ist NAT-Traversal. Der Client verhandelt immer noch auf UDP 500, statt auf UDP 4500 zu wechseln, weil NAT-T am Büroende nie konfiguriert wurde. RFC 3947 ist da unverblümt: sobald ein NAT erkannt ist, „MUST set both UDP source and destination ports to 4500“ — der Initiator muss also beide Ports auf 4500 setzen. Er tut es nie. Der Tunnel stirbt im NAT. Jedes Mal.\nDie Antwort sitzt auf ihrer eigenen Firewall, ausgeschaltet. Dieselbe MX kann AnyConnect, das „will attempt to connect using both TLS, and DTLS (Datagram TLS) over TCP and UDP 443 respectively“. Gewöhnliches TLS auf einem gewöhnlichen Port. Ein NAT versteht das bestens — es gibt nichts zu durchqueren und nichts zu konfigurieren — und es würde an dem Nachmittag funktionieren, an dem jemand es einschaltet.\nNiemand macht einen Paketmitschnitt. Niemand prüft, auf welchem Port der Client tatsächlich spricht. Das sind die ersten zwei Dinge, die man tut, und sie würden die Sache in einer Minute beenden.\nJetzt ein zweiter Fall vom selben Dienstleister, und darin steckt nirgends ein Netzwerk. Ein Etikettendrucker, und ein Versandetikett, das im richtigen Format herauskommen muss. Das ist die ganze Anfrage. Es ist auch das Einzige, was ein Etikettendrucker tut.\nDie Antwort, die zurückkam, war, dass das nicht möglich sei.\nEs war eine Option im Druckertreiber. Ein Kästchen, in einem Einstellungsdialog, in Software, die sie verwalten, und die ganze Arbeit war, es anzuhaken und einen Testdruck zu machen. Niemand musste etwas kaufen. Niemand musste etwas entwerfen. Sie wollten es nicht anhaken.\nBeachte, dass „nicht möglich“ eine Antwort ohne jede Messung darin ist, und es ist die eine Antwort, die ein Ticket schließt, ohne dass irgendwer owt tun muss. Sie wird auch schwerer zurückzunehmen, je länger sie steht, denn jetzt nachzusehen hieße zuzugeben, dass es etwas nachzusehen gab.\nDas ist die Form, auf die man achten muss, und es ist zweimal dieselbe Form. Der Fehler ist kostenlos zu beheben, die Behebung sitzt in Geräten, die der Dienstleister ohnehin besitzt und für deren Betrieb er ohnehin bezahlt wird, und was stattdessen zurückkommt, ist entweder eine Anweisung, etwas beim Kunden zu ändern, oder die glatte Feststellung, dass es nicht geht. Wenn die billige Antwort ohne Messung weggewinkt wird, bekommst du keine Diagnose. Du wirst verwaltet.\nEin Ingenieur, der den Fehler gefunden hat, sagt dir, was der Fehler ist. Jemand, der ihn nicht gefunden hat, sagt dir, dass es nicht geht, oder sagt dir, was du kaufen sollst.\nWer deinen Berater bezahlt Fang beim Geld an, denn alles andere folgt ihm.\nWenn dein MSP einen Hyperscaler empfiehlt, ist er nicht neutral. Microsofts eigene Abrechnungsdokumentation beschreibt den Partner Earned Credit — eine Gutschrift auf die Kosten deines Azure-Verbrauchs, verdient von dem Partner, der die Adminrechte zur Verwaltung hält. Deine Rechnung steigt, er bekommt eine Scheibe. Daneben sitzen Wiederverkäufermargen, Volumenstufen, Zertifizierungsrabatte, Marketingfonds und Quartalsziele, quer über jeden Hersteller im Stack, nicht nur diesen einen.\nNichts davon ist geheim, und nichts davon verstößt gegen irgendeine Regel. Es ist veröffentlicht, es ist normal, und so funktioniert der Channel seit dreißig Jahren.\nZwei zahlen deinen Berater, und nur einer davon bist du Du Fragst, welches Produkt du kaufst Dein Dienstleister Schreibt die Auswahlliste, aus der du wählst Der Hersteller Legt fest, was eine Empfehlung einbringt eine Gebühr eine Option Rabatt Rabatt, Marge, Deal Registration, Vertriebsziel Nichts davon muss dir erwähnt werden Ein Finanzberater darf nur vom Kunden bezahlt werden (FCA Handbook, COBS 6.1A). Ein IT-Berater darf von beiden bezahlt werden, und nichts verpflichtet ihn zu sagen, wer mehr zahlt. Zwei Parteien bezahlen dieselbe Empfehlung. Nur eine davon sitzt in der Besprechung, und nur eine der Zahlungen muss erwähnt werden. Hier ist der Teil, der dich beunruhigen sollte. Niemand muss dir irgendetwas davon sagen — nicht den Satz, nicht die Ziele, nicht die Gutschrift. Die Person, die dir das Produkt empfiehlt, wird von der Firma bezahlt, die das Produkt herstellt, zu einem Satz, der davon abhängt, welches Produkt sie dir einredet und wie viel davon du dann verbrauchst, und es gibt nirgends eine Pflicht, davon ein Wort in das Angebot zu schreiben, das du gerade liest.\nEine andere Branche hat sich genau dieses Arrangement angesehen und es verboten. Nach den Regeln der FCA darf ein Finanzberater „only be remunerated for the personal recommendation \u0026hellip; by adviser charges“ und darf „not solicit or accept \u0026hellip; any other commissions, remuneration or benefit“. Du bezahlst deinen Berater. Der Produktanbieter nicht. Diese Regel existiert, weil die Aufsicht etwas Offensichtliches herausgefunden hat. Du kannst Beratung nicht von Verkauf unterscheiden, wenn der Verkäufer vom Hersteller bezahlt wird.\nIn der IT gab es diese Abrechnung nie. Die CMA hat den Cloud-Markt durchleuchtet und sich zugesagte Ausgaben, Egress-Gebühren und Wechselhürden genau angesehen, aber die Schicht in der Mitte hat sich noch niemand angesehen. Den Laden, der zwischen dir und dem Hersteller sitzt und zugleich eine Pflicht dir gegenüber und ein Ziel von ihm hält.\nEs lohnt sich auch, das Ding beim Namen zu nennen.\nEin Anreiz ist eine Zahlung von einer Partei, um eine Entscheidung zu formen, auf die sich eine andere Partei verlässt. Das ist der Mechanismus, wie das Programm auf der Website des Herstellers auch heißen mag. Der Hersteller zahlt, der Kunde verlässt sich, und die Empfehlung verschiebt sich.\nEs ist auch am Ende des MSP zwanghaft, und das ist die Hälfte, die sich niemand ansieht. Verfehl die Stufe und du verzichtest nicht bloß auf einen Bonus. Dein Einkaufspreis steigt auf alles, was du in den nächsten zwölf Monaten verkaufst. Der Druck lautet also nicht „verkauf das und krieg was Schönes“. Er lautet „verkauf das, oder dein ganzes Geschäft wird teurer“. Niemand in dieser Lage wählt frei, und es war nie so entworfen, dass es sich wie eine Wahl anfühlt.\nDas englische Recht kennt diese Form bereits. Der Bribery Act 2010 braucht keinen Amtsträger in der Nähe — Abschnitt 3 erfasst „any activity connected with a business“, und er greift, wo von der Person, die diese Tätigkeit ausübt, erwartet wird, sie „in good faith“ oder „impartially“ auszuüben, oder wo sie „in a position of trust“ ist. Lies diese drei Bedingungen. Dann lies das Angebot auf deinem Schreibtisch.\nIch beschuldige niemandes Kundenbetreuer einer Straftat. Was hier läuft, ist langweiliger als das und schwerer zu beheben. Das Arrangement sitzt haarscharf auf der richtigen Seite der Linie, und das Einzige, was es dort hält, ist, dass nie festgestellt wurde, dass dir ein MSP überhaupt Unparteilichkeit schuldet. Bei der Finanzberatung wurde es festgestellt, und die Provision hörte auf. Hier hat es niemand festgestellt, also hat sie das nicht.\nNenn einen Anreiz eine milde Form von Korruption und die Leute sträuben sich. Leg die Zahlung, das Ziel und die Auswahlliste auf dieselbe Seite und frag dann, wie man es sonst nennen soll.\nDer kleine Lieferant wird nie genannt Die Liste der Lieferanten, die man dir gezeigt hat, ist nicht die Liste der Lieferanten, die es gibt. Es ist die Liste, bei denen dein MSP schon ein Konto hat.\nUm auf diese Liste zu kommen, braucht ein Hersteller ein Partnerprogramm. Stufen, Akkreditierung, Rabatte, Deal Registration, einen Distributor, der die Linie führt. Das ist eine Maschine. Sie zu betreiben kostet Geld, das rein gar nichts damit zu tun hat, wie gut das Produkt ist. Es gibt in diesem Land reichlich kleine Läden, die bessere Geräte und bessere Software bauen als das Logo auf deinem Angebot, und sie werden nie darauf erscheinen, weil sie zwölf Mitarbeiter und kein Channel-Team haben.\nSchau, was die Maschine mit der Empfehlung macht.\nDeal Registration bindet deinen MSP an einen Hersteller, bevor überhaupt jemand mit dir über Anforderungen gesprochen hat. Sie melden die Gelegenheit an, sie bekommen einen besseren Einkaufspreis und Schutz davor, dass ein anderer Partner dir dasselbe anbietet, und von diesem Moment an gibt es einen Grund, den Entwurf zu diesem Hersteller zu lenken, der mit deinem Geschäft nowt zu tun hat.\nDie Stufen erledigen den Rest. Gold, Platin, wie es dieses Jahr auch heißt, der Status läuft über Jahresvolumen, und er setzt ihren Rabatt auf alles andere, was sie das ganze Jahr verkaufen. Dein Projekt kann das sein, was sie über die Linie bringt. Das wird dir nicht gesagt.\nDann entscheidet der Distributor, was übrig bleibt. Ein MSP kauft über einen Distributor, der Distributor führt die Linien, für die er Verträge hat, und ein Hersteller, der nicht auf der Preisliste steht, könnte genauso gut nicht existieren.\nWas dich das kostet, ist nicht abstrakt. Ein kleinerer Lieferant stellt dich normalerweise zu den Leuten durch, die die Software geschrieben haben, statt zu einem Skript im First Level, ändert etwas, weil du darum gebeten hast, und ist dir nächstes Jahr immer noch verpflichtet, weil du ein echter Teil seines Umsatzes bist statt eines Rundungsfehlers. Nichts davon passt in eine Vergleichsmatrix, und nichts davon zahlt irgendwem einen Rabatt.\nFrag also, was es bräuchte, um einen dieser kleineren Läden auf die Auswahlliste zu bekommen. Die Antwort sagt dir, für wen die Auswahlliste aufgestellt wurde.\nUnd das Mandat kommt aus einem Land Schau dir die Logos auf dem Angebot an. Der Hypervisor, die Cloud, die Netzwerktechnik, die Firewall, die Bürosuite, das CRM, das Backup-Ziel, das Monitoring. Fast alle amerikanisch.\nNichts davon ist ein Urteil über Qualität. Es ist das, was passiert, wenn der Weg zum Markt ein Channel-Programm ist, denn die Firmen, die groß genug sind, so etwas weltweit zu betreiben, sitzen in einem Land. Die Ziele, die dein MSP trägt, die Rabatte, die deine Auswahlliste formen, und die Stufe, die seine Marge setzt, sind also alle in den Vereinigten Staaten geschrieben.\nWeshalb es sich lohnt zu wissen, wie dieses Land derzeit mit den Regeln über das Gewinnen von Aufträgen im Ausland umgeht.\nAm 10. Februar 2025 unterzeichnete der Präsident eine Verfügung mit dem Titel „Pausing Foreign Corrupt Practices Act Enforcement to Further American Economic and National Security“. Sie wies den Justizminister an, für 180 Tage „cease initiation of any new FCPA investigations or enforcement actions“, mit der erklärten Begründung, dass Durchsetzung gegen amerikanische Unternehmen „for routine business practices in other nations“ der amerikanischen Wettbewerbsfähigkeit schade.\nDer FCPA verfolgt die Bestechung ausländischer Amtsträger. Das ist die Praxis, die hier beschrieben wird.\nWas folgte, steht im Protokoll. Neue Richtlinien des Justizministeriums vom 9. Juni 2025 verengten die Durchsetzung auf Fälle mit Bezug zu Kartellen, direktem Schaden für amerikanische Firmen oder nationaler Sicherheit. Über das ganze Jahr 2025 brachte die Börsenaufsicht SEC überhaupt keine zivilrechtlichen FCPA-Verfahren und löste ihre FCPA-Einheit auf, während das Justizministerium rund die Hälfte seiner laufenden Ermittlungen einstellte. Zur Sitzung der OECD-Arbeitsgruppe gegen Bestechung im März 2025 erschien es auch nicht.\nDasselbe Gesetz, andere Richtung. Es hat einem französischen Ingenieurkonzern 2014 772 Millionen Dollar abgenommen, und es ist der Grund, warum der französische Staat einen Bericht darüber in Auftrag gab, ob amerikanisches extraterritoriales Recht als Handelswaffe wirkt. Das habe ich in wie weit das Recht eines Landes reicht durchgegangen. Das Recht reicht also für ausländische Firmen über Grenzen und wird für inländische ausgesetzt, von der Regierung des Landes, aus dem deine gesamte Produktliste kommt.\nErwarte auch nicht, dass das UK die Lücke füllt. Das Recht hier ist nicht der schwache Teil — der Bribery Act 2010 geht stellenweise weiter als das amerikanische Gesetz, und Abschnitt 7 macht es für eine Wirtschaftsorganisation zur Straftat, Bestechung durch jemanden zu unterlassen zu verhindern, der in ihrem Namen handelt. Streng, breit, und seit fünfzehn Jahren in Kraft.\nDer schwache Teil ist, dass Durchsetzung in dieser Größenordnung immer nur als gemeinsame Operation funktioniert. Airbus ist der größte Bestechungsvergleich, an dem dieses Land je beteiligt war, und Airbus\u0026rsquo; eigene Bekanntmachung legt die Form dar: 3.598 Millionen Euro Strafen am 31. Januar 2020, davon 2.083 Millionen an den französischen Parquet National Financier, 984 Millionen an das Serious Fraud Office, 526 Millionen an das Justizministerium und 9 Millionen an das Außenministerium, wobei SFO und PNF es als gemeinsames Ermittlungsteam führten. Das Geld überquert mehrere Länder und die Beweise auch, und keine einzelne Behörde kann alles allein erzwingen. Es braucht alle.\nBeachte das Datum. Januar 2020 liegt innerhalb der ersten Trump-Regierung, und das damalige Justizministerium nahm seine 526 Millionen Euro gern entgegen. Die Pause kam fünf Jahre später, vom selben Präsidenten in seiner zweiten Amtszeit. Das ist kein Unterschied zwischen Regierungen. Es ist eine 2025 getroffene Entscheidung.\nEiner von ihnen erscheint nicht mehr, und das geht tiefer als ein leerer Stuhl. Eine Staatsanwaltschaft, die keine Verfahren eröffnet, produziert auch nichts zum Teilen. Keine Vorladungen, keine Dokumentenherausgaben, keine kooperierenden Beschuldigten, keine unter Druck gesetzten Zeugen — die Beweise, die Airbus möglich machten, existierten, weil jemand losging und sie holte. Schließ die Hälfte eines Aktenbestands und bring keine neuen Verfahren, und es liegt nichts im Topf, aus dem sich jemand anders bedienen könnte. Das ist kein Land, das sich weigert, Dinge herauszugeben. Es ist ein Land, das nichts mehr herauszugeben hat.\nEs schließt auch die andere Tür. Airbus\u0026rsquo; eigene Bekanntmachung führt das Ergebnis auf „reporting, cooperation and new compliance standards“ im Unternehmen zurück. Firmen melden sich, wegen dem, was ihnen passiert, wenn sie es nicht tun. Nimm weg, was ihnen passiert, und die Selbstanzeigen, mit denen die meisten dieser Fälle anfangen, hören auf einzugehen. In London ebenso wie in Washington.\nDer Bribery Act wird dadurch nicht schwächer. Ihm geht nur der Nachschub an Beweisen aus, der ihn genau bei den Fällen brauchbar machte, für die er geschrieben wurde.\nAchtzehn Monate davon, und es hat in dieser Branche keine einzige Auswahlliste bewegt. Niemand hat es in einem Risikoregister, niemand fragt danach auf einem Beschaffungsformular, und niemand, der dir ein Fünfjahresabo verkauft, hat es erwähnt.\nDas Weiterbildungsbudget ging zuerst Es gibt einen zweiten Grund, warum das Produkt immer wieder gewinnt, und er ist weniger zynisch als der erste. Viele der Leute, die dir verkaufen, könnten das andere gar nicht.\nDie Investitionen der Arbeitgeber in Weiterbildung sinken in diesem Land seit zwanzig Jahren. Die Auswertung des Employer Skills Survey 2024 durch das Learning and Work Institute setzt sie real auf 36 % weniger je Beschäftigtem als 2005 — 1.700 Pfund gegen 2.634 Pfund. Allein seit der Erhebung 2022 sind es weitere 13 % weniger. Die Ausbildungsabgabe kam 2017, um genau das umzukehren, und die Ausgaben je Beschäftigtem einschließlich der Abgabe sind seither um 23 % gefallen.\nDann schau, welche Branchen zwischen 2022 und 2024 am härtesten gekürzt haben. Öffentliche Verwaltung um 50 %, Finanzdienstleistungen um 47 %, und Information und Kommunikation um 30 %. Letzteres ist unsere. Fast ein Drittel weg in zwei Jahren, in der Branche, die sich am schnellsten ändert.\nWährenddessen ist das Ding, das verteidigt wird, gewachsen. Ich habe die veröffentlichten Schwachstellen im Abstand eines Jahrzehnts direkt aus der National Vulnerability Database gezählt: 6.595 CVEs 2015 veröffentlicht, und 49.972 im Jahr 2025. Siebeneinhalbmal so viele in zehn Jahren, gegen ein Weiterbildungsbudget, das um ein Drittel gesunken ist. Diese zwei Linien laufen in entgegengesetzte Richtungen, und das tun sie seit Jahren.\nDie Kontrollen, die den Unterschied sichtbar machen würden, sind auch nicht da. Die eigene Cyber Security Breaches Survey 2025/2026 der Regierung setzt Zwei-Faktor-Authentifizierung bei 47 % der Unternehmen an — dieselbe Kontrolle, die die Five-Eyes-Behörden 2022 für MSP-Konten benannten, und dieselbe, wegen der die ICO Advanced ein Bußgeld auferlegte. Dieselbe Erhebung hat formale Cybersicherheitsrichtlinien binnen eines Jahres von 59 % auf 52 % fallen sehen und Notfallpläne, die Cybersicherheit abdecken, von 53 % auf 44 %. Nicht stabil. Fallend.\nUnd dann setz eine Cloud-Mandantschaft unter das Ganze. Ein kleines Unternehmen verwaltet seine eigene nicht. Der MSP hält den globalen Admin, baut das Identitätsmodell, setzt den Conditional Access, entscheidet, welcher Speicher öffentlich ist und welcher nicht, und besitzt die Konsole. Genau dafür wurde er angeheuert. Wenn also eine Mandantschaft falsch konfiguriert endet, waren die Hände darauf die des Auftragnehmers. Kein Kunde, der das falsche Kästchen anklickt.\nDer Wirkungsradius hat sich auch geändert. Ein 2005 falsch konfigurierter Server reichte etwa so weit wie das Kabel, in dem er steckte. Eine heute falsch konfigurierte Mandantschaft ist in der Sekunde des Speicherns im Internet, sie ist dieselbe Mandantschaft für jedes System, das dieses Unternehmen betreibt, und die Zugangsdaten, die sie verwalten, liegen bei jemandem, den man nie getroffen hat, in einer Firma, die man nicht auditieren darf.\nDie Sicherheitsbehörden von fünf Ländern haben 2022 eine Warnung dazu geschrieben, und die allererste Maßnahme auf ihrer Liste betrifft die Konten, die ein Dienstleister nutzt, um in deine Systeme zu kommen. Sie steht zuerst, weil das der Weg hinein ist.\nDann ist da, was diese Branche Weiterbildung nennt. Eine Herstellerzertifizierung ist Produktschulung. Sie lehrt dich, wo die Knöpfe in der Konsole einer Firma sind und wie diese Firma beschlossen hat, ihre Funktionen zu nennen, sie ist von der Firma geschrieben und bepreist, deren Produkte sie abdeckt, und genug davon zu halten ist Bedingung für die Partnerstufe, die die Marge setzt. Es ist ein Vertriebskanal mit Doktorhut.\nEine Konsole zu kennen ist nicht dasselbe wie zu wissen, wie das Ding funktioniert. Ein Ingenieur mit fünf Zertifizierungen hat vielleicht nie einen RFC gelesen, nie einen Paketmitschnitt gemacht und noch nie von Grund auf herausgefunden, warum etwas fehlgeschlagen ist. Setz diese Person vor einen Tunnel, der nicht hochkommt, und die ehrliche Antwort steht ihr nicht zur Verfügung. Das IPv6 im Heimnetz des Kunden zu beschuldigen schon.\nSo treffen sich die zwei Hälften. Sie werden dafür bezahlt, ein Produkt zu verkaufen, und immer öfter ist das Produkt die einzige Antwort, die sie haben. Ein Kunde, der für Fachwissen zahlt, bekommt am Ende keines von beidem.\nNiemand hat aufgeschrieben, was du brauchtest Bitte darum, deine Anforderungen zu sehen. Nicht das Angebot, nicht den Kostenvoranschlag, nicht das Architekturdiagramm mit deinem Logo darauf. Die Anforderungen.\nEine ordentliche Erhebung ist langweilig und sie ist nicht kurz. Was muss der Dienst leisten, und für wen. Wie viele Leute, von wo, womit. Was ist die stärkste Stunde und wie ist das Wachstum über drei Jahre. Wie lange darf er ausfallen, bevor es echtes Geld kostet, und wie viele Daten kannst du dir zu verlieren leisten. Was darf das Land nie verlassen, und unter wessen Recht. Was muss einen Brand in einem Gebäude überstehen. Wofür haftest du vertraglich gegenüber deinen eigenen Kunden. Wie hoch ist das Budget, investiv und laufend, getrennt ausgewiesen. Was besitzt du schon, das noch Leben in sich hat. Wer hält es danach am Laufen, und was kann er schon betreiben.\nDas ist ein Vormittag Arbeit mit den richtigen Leuten im Raum — und es sollte in einem Dokument enden, das du abzeichnest, bevor irgendwer einen einzigen Kasten malt.\nWenn dich niemand das meiste davon gefragt hat, hast du keinen Entwurf bekommen. Du hast das bekommen, was sie ohnehin verkaufen, mit dem Namen deiner Firma auf dem Deckblatt.\nAchte auch auf das Anzeichen in die andere Richtung. Wenn die Dimensionierung im ersten Gespräch stattfand, bevor irgendwer sich angesehen hat, wie deine Last tatsächlich aussieht, dann kamen die Zahlen aus einer Vorlage und nicht aus deinem Bestand, und echte Dimensionierung braucht Daten. Jemanden, der sich ansieht, was deine Geräte tatsächlich tun, lange genug, um einen Monatsabschluss und ein Quartalsende zu sehen.\nEine Option ist keine Wahl Ein Entwurf ist eine Menge von Entscheidungen mit der Begründung daneben. Was Optionen heißt, und Kosten für alle davon, nicht nur für die, die sie dir andrehen wollen.\nDu solltest das Nichtstun bekommen, bepreist, einschließlich dessen, was es dich kostet, wenn es kaputtgeht. Du solltest das Billigste bekommen, das die Anforderungen erfüllt. Du solltest die Empfehlung bekommen, und du solltest das bekommen, was für dich überdimensioniert ist, damit du siehst, wo die Grenze liegt. Jedes davon mit dem, was es in der Anschaffung kostet, was es über fünf Jahre im Betrieb kostet, was es nicht kann — und was du als Nächstes tun müsstest, wenn du herauswächst.\nUnd entscheidend: du solltest die Liste dessen bekommen, was ausgeschlossen wurde und warum. Das ist der Teil, der zeigt, dass tatsächlich jemand nachgedacht hat.\nWenn du genau eine Antwort bekommen hast, und diese Antwort zufällig der Hersteller ist, in dem sie zertifiziert sind, und das Lizenzmodell, das monatlich zahlt, hast du keinen Entwurf bekommen. Du hast einen Kostenvoranschlag in den Kleidern eines Entwurfs bekommen. Mehr nicht.\nWas die Auswahlliste herausfiltert, bevor du sie je siehst Vier Antworten auf dieselbe Anforderung Open Source, mit Supportvertrag Marge ist die eigene Arbeit des Anbieters Ein kleinerer britischer Lieferant Kein Partnerprogramm zum Beitreten Was du schon besitzt, konfiguriert Nichts zur Verlängerung abzurechnen Der Hersteller im Partnerprogramm Rabatt, Deal Registration, Ziel Zahlt es? Ist es im Programm? Was deinen Schreibtisch erreicht Eine Option, angeboten Kein Vergleich, keine bepreiste Alternative Die anderen drei wurden nie bepreist, du hast also nie erfahren, was sie kosten und ihr Fehlen sieht aus, als gäbe es nichts zu sagen Der Filter läuft, bevor du irgendetwas siehst. Drei Antworten auf dieselbe Anforderung werden nie bepreist, sodass ihr Fehlen sich liest, als hätte es nichts zu vergleichen gegeben. Es gibt eine einfache Frage, die das ans Licht bringt, und ich würde sie im Raum stellen. Was habt ihr sonst erwogen, und was hat es gekostet? Wer die Arbeit gemacht hat, hat die Zahlen parat und wird ganz gern danach gefragt. Wer sie nicht gemacht hat, wird dir sagen, die Alternativen seien nicht supportet, nicht enterprise-tauglich oder nichts, wofür er seinen Namen hergeben würde. Nichts davon ist eine Zahl.\nOpen Source kommt nie auf die Liste Es ist nicht so, dass sie es hassen. Es gibt keine Marge daran, keinen Rabatt dafür, keine Zertifizierung zu verkaufen und kein Quartalsziel, das es bewegt.\nDer Einwand ist immer derselbe, und es ist die eine Behauptung in diesem Beitrag, die schlicht unwahr ist — „es ist nicht supportet“. All das ist supportet, kommerziell, mit Vertrag und SLA und jemandem zum Anrufen — Proxmox verkauft Subskriptionen je Sockel, und Red Hat, SUSE und Canonical verkaufen Support für den Stack. Du wählst, wer es supportet, statt zu wählen, ob es überhaupt supportet ist. Was du aufhörst zu bezahlen, ist das Recht, Software zu benutzen, die du schon hast.\nDann sind da die Geräte, die schon dastehen. Die werden völlig übersehen. Bei meinem letzten Arbeitgeber habe ich aus ausgemusterten HPC-Knoten eine Private Cloud gebaut — Proxmox, Ceph und eine vollständige Ansible-Kette darüber — und kam auf 7 Server, 480 Kerne, 15 TiB RAM und 1,8 PiB Speicher, ohne Budget und mit drei Leuten. Ein MSP, der dieselbe Anforderung anbietet, hätte neue Hardware und eine Subskription kalkuliert — für Geräte, die du schon gekauft und bezahlt hast, springt für ihn nichts heraus.\nDie andere Hälfte davon sind die Geräte, die schon bei dir stehen, und das ist die Hälfte, die überhaupt nie bepreist wird. Ein Server hört an dem Tag, an dem sein Supportvertrag ausläuft, nicht auf zu funktionieren. „End of Support“ ist ein Datum, das der Hersteller gewählt hat, keine Messung, die irgendwer an der Hardware vorgenommen hat, und eine Kiste mit fünf guten Jahren darin ist dir mehr wert als jedem, der ihren Ersatz verkauft. Open Source ist das, was dich sie weiter nutzen lässt, denn die Lizenz kümmert sich nicht darum, wie alt die CPU ist oder ob das Logo vorn noch Garantie hat.\nDas ist der Teil, der niemandem etwas zahlt. Es gibt keinen Rabatt auf Hardware, die dir schon gehört, keine Stufengutschrift für eine Maschine, die stehen bleibt, und keine Verlängerung einer Lizenz, die niemand kaufen musste. Als solches wird es nicht vorgeschlagen, und der Ausdruck, zu dem stattdessen gegriffen wird, ist „End of Life“, was nach Technik klingt und ein Verkaufsdatum ist.\nVerlang, dass die Open-Source-Option ordentlich bepreist wird, Support inklusive, neben den anderen — und verlang die Variante, die wiederverwendet, was du hast, bepreist gegen die, die es nicht tut. Nicht, um dir die kommerzielle ausreden zu lassen. Um den Abstand zu sehen, damit die Entscheidung deine ist.\nWie die Alternative tatsächlich aussieht Es gibt zu fast allem auf einem Angebot eine supportete Open-Source-Antwort, und es lohnt sich, mit dem Teil anzufangen, der dich am meisten kostet, denn es sind nie die Server.\nDie Software je Arbeitsplatz. Hier steckt das wiederkehrende Geld, und hier wird eine Alternative nie erwähnt. Bürosuite: LibreOffice, ONLYOFFICE oder Collabora Online, das supportete Installationen verkauft und dir das browserbasierte Bearbeiten gibt, von dem Leute glauben, es käme nur von einem Ort. Mail, Kalender und geteilte Kontakte: grommunio spricht MAPI, Outlook verbindet sich also damit wie mit Exchange, und es wird mit Support verkauft; SOGo und mailcow decken dasselbe Feld anders ab. Dateien, Freigaben und das, wofür Leute ein Cloud-Laufwerk tatsächlich benutzen: Nextcloud, mit einem Enterprise-Vertrag dahinter. Chat und Besprechungen, also die Teams-Hälfte: Mattermost und Rocket.Chat sind die nächsten Entsprechungen, beide selbst hostbar mit kaufbarem Support, und Zulip steht unter Apache-Lizenz und kann richtig mit Threads. Matrix mit Element, Nextcloud Talk und Jitsi decken den Rest ab. Und die SharePoint-Hälfte — Intranet, Dokumentenbibliotheken, Teamseiten — sind XWiki, BookStack, OpenProject, Seafile und Nextcloud zusammen.\nDie Geschäftsanwendungen. ERP: Odoo Community, ERPNext, Dolibarr. CRM: SuiteCRM, für das die Firma dahinter Support verkauft, oder EspoCRM. Buchhaltung: GnuCash, oder das in Dolibarr und ERPNext eingebaute Rechnungswesen. Dokumentenmanagement: Paperless-ngx. Auswertungen: Metabase. Service Desk und Inventarisierung, wofür dir dein MSP ein Produkt berechnet: GLPI und Zammad.\nIdentität und Geheimnisse, an denen alles andere hängt. Keycloak, FreeIPA oder Samba als Domänencontroller. Für Passwörter kann Bitwarden selbst gehostet werden, Vaultwarden ist ein schlanker AGPL-Server, der mit denselben Clients spricht, und Passbolt und KeePassXC decken dieselbe Aufgabe anders ab. Das ist auf den meisten Angeboten eine monatliche Zeile je Nutzer.\nGeräteverwaltung, also die Intune-Zeile auf deiner Rechnung. Fleet macht Inventar, Richtlinien und Registrierung über die Plattformen, die ein Bestand tatsächlich enthält, gebaut auf osquery. MicroMDM übernimmt die Apple-Registrierung, Headwind die von Android, und Ansible, Puppet oder Salt machen darunter die Konfiguration. Für die Fernzugriffshälfte — das Thema, dem ein späterer Abschnitt dieser Reihe ganz gewidmet ist — steht MeshCentral unter Apache-Lizenz und RustDesk unter AGPL, und beide laufen auf einem Server, der dir gehört. Was heißt, dass die Antwort auf „welches Fernwartungswerkzeug ist auf meinen Maschinen, und wer kann sich an der Konsole anmelden“ eine sein kann, die du selbst hostest und patchst, statt einer, von der du hinterher erfährst.\nUnd das Aktualisieren selbst ist längst nicht mehr die schwarze Kunst, als die es verkauft wird. Sogar auf dem Fisher-Price OS (Windows) laufen Anwendungsaktualisierungen inzwischen über winget, das MIT-lizenziert ist, gegen ein gemeinschaftliches Manifest-Repository unter derselben Lizenz; Chocolatey und Scoop machen dieselbe Arbeit schon länger, und jedes Unix hat es seit den Neunzigern. Wenn also Patch-Management auf einem Angebot als hochwertige gemanagte Zeile auftaucht, schau, was da tatsächlich verkauft wird. Der Mechanismus ist kostenlos und wird vom Plattformhersteller mitgeliefert, und ihn einzurichten ist ein Nachmittag. Danach ist es eine geplante Aufgabe. Ein Cron-Eintrag, oder wie die Konsole so etwas nennt, laufend auf einer Maschine, die ohnehin da war. Du zahlst eine Monatsgebühr für eine Arbeit, die sich selbst erledigt.\nDie Antwort darauf soll sein, dass du dafür bezahlst, dass jemand das Ergebnis beobachtet und handelt, wenn es fehlschlägt, und das wäre das Geld wert. Also schau dir die Belege für das Beobachten an. Bei Capita wurde der Alarm in zehn Minuten ausgelöst und knapp drei Tage später bearbeitet, gegen ein Ziel von einer Stunde, von einem Team, das die Aufsicht als unterbesetzt befand. Draußen im Internet stehen Firewalls, die Schwachstellen tragen, die Jahre nach dem Erscheinen eines Fixes in den Katalog ausgenutzter Schwachstellen kamen. Das Beobachten ist der Teil, der die Rechnung rechtfertigen würde, und es ist der Teil mit den wenigsten Belegen dafür, dass er stattfindet.\nDie Telefonanlage, eine der ältesten monatlichen Zeilen je Nebenstelle, die es gibt. Asterisk macht das seit fünfundzwanzig Jahren, FreePBX setzt eine Weboberfläche darauf, FreeSWITCH ist die andere Engine, und Kamailio und OpenSIPS machen SIP-Routing im Carrier-Maßstab. Wenn du es fertig statt zusammengebaut willst, liefern Wazo, FusionPBX und Issabel es alle gebaut aus.\nEs lohnt sich auch, sich zu erinnern, was mit der proprietären passierte, die die meisten Dienstleister vorschlagen. Im März 2023 veröffentlichte CISA eine Warnung, wonach „3CXDesktopApp — a voice and video conferencing app — was trojanized, potentially leading to multi-staged attacks against users employing the vulnerable app“. Niemand musste eine Schwachstelle finden und ausnutzen. Es kam als die eigene signierte Anwendung des Herstellers über den eigenen Update-Kanal des Herstellers, auf jeden Schreibtisch, auf den ein Partner sie ausgerollt hatte.\nAdobe, das wie alles andere ein Abo je Arbeitsplatz ist. Die meisten Unternehmen zahlen überhaupt nicht für eine Kreativsuite. Sie zahlen für Acrobat und für Unterschriften. Stirling PDF ist ein selbst gehosteter Werkzeugkasten, der das Zusammenführen, Teilen, Schwärzen, OCR und Formularausfüllen macht, wofür Acrobat Pro gekauft wird, und Okular oder LibreOffice Draw decken den Rest ab. Zum Unterschreiben stehen Documenso und DocuSeal beide unter AGPL und sind beide selbst hostbar — und eine Gebühr je Umschlag fürs Unterschreiben eines Dokuments ist etwa das sauberste Beispiel, das dieser Beitrag dafür hat, dass etwas gemessen und berechnet wird, was dein eigener Server umsonst täte. Wo es wirklich ein Designteam gibt: GIMP und Krita für Bilder, Inkscape für Vektoren, Scribus fürs Layout, darktable und RawTherapee für Fotografie, Kdenlive für Video, Blender für 3D und Compositing, Audacity und Ardour für Audio.\nVideo, das einen eigenen Absatz wert ist. Kameras werden als gemanagtes Produkt verkauft, mit einer Lizenz je Kanal und einem Rekorder, in den du nicht hineindarfst. Frigate ist MIT-lizenziert und macht Objekterkennung lokal auf Hardware, die dir gehört; ZoneMinder ist seit zwanzig Jahren GPL. Für Konferenzen Jitsi und BigBlueButton. Und denk daran, um welches Produkt es ging, wegen dem Cisco 8,6 Millionen Dollar und weitere 6 Millionen zur Beilegung zahlte, ein paar Abschnitte weiter. Videoüberwachungssoftware, verkauft an Behörden. Der Premium-Kamera-Stack kommt nicht mit Sicherheit im Paket.\nSpeicher und Dateisysteme, und beachte, dass dir hier überhaupt nie jemand eine Wahl anbietet. OpenZFS für prüfsummengesicherten Speicher mit Snapshots und Send/Receive, Btrfs, XFS, CephFS. Das Dateisystem unter deinen Daten ist eine technische Entscheidung mit echten Folgen dafür, wie viel davon du nach einem schlechten Tag zurückbekommst, und es kommt üblicherweise als das an, womit die Appliance ausgeliefert wurde.\nDie Infrastruktur, zuletzt, weil sie der billigste Teil der Rechnung ist. Hypervisor und Cluster: Proxmox VE. Speicher: Ceph, das gern auf den Platten läuft, die dir schon gehören, statt auf einem neuen Array. Firewall und Routing: nftables, OPNsense. VPN: WireGuard oder strongSwan. Für das Mesh-Overlay, das jetzt alle verkaufen, lohnt es sich, das Bild richtig zu haben. Tailscales Clients sind Open Source und der eigene gehostete Koordinationsserver ist es nicht — die Firma erklärt, er „remains proprietary as part of our managed service“. Aber es gibt einen offenen Koordinationsserver, und er ist ernst zu nehmen: Headscale ist BSD-lizenziert, „an open source, self-hosted implementation of the Tailscale control server“, und Tailscale beschäftigt seinen Hauptentwickler und sagt zugleich, es „does not set Headscale\u0026rsquo;s product direction“. Das Ganze lässt sich also auf eigenen Geräten betreiben. NetBird und Nebula sind die anderen Wege. Lastverteilung: HAProxy und keepalived. Monitoring: Prometheus, Grafana, Zabbix. Backup: Proxmox Backup Server, Bareos, restic. Konfigurationsmanagement: Ansible. Und für die Integrationsarbeit, die entweder als Individualentwicklung oder als Cloud-Automatisierungsabo je Ausführung angeboten wird: Node-RED ist Apache-lizenziert, läuft auf einer Kiste, die dir gehört, und rechnet dir keine Ausführungen ab.\nDrei Stellen, an denen ich nicht so tue, als wäre der Wechsel sauber. Erstens Teams und SharePoint. Das Ziel ist nicht das Problem, was man dir auch erzählt — die Produkte oben sind reif und Unternehmen laufen darauf. Die Migration ist das Problem: Jahre angesammelter Sites, Berechtigungsvererbung, die nie jemand dokumentiert hat, Power-Automate-Abläufe, die jemand gebaut hat und dann gegangen ist, und Verhalten beim gemeinsamen Bearbeiten, das Mitarbeiter erwarten, ohne es benennen zu können. Das ist echte Arbeit, und sie sollte als echte Arbeit bepreist werden, statt in irgendeine Richtung weggewinkt zu werden. Beachte aber auch, was du nicht mehr trägst. Diese Abläufe und diese Sites sind Geschäftsprozesse, die im Rechenzentrum von jemand anderem laufen, auf einer Plattform, die du nicht neu starten kannst. Wenn sie stehen bleiben, reparierst du sie nicht. Du wartest, und du sagst deinen eigenen Kunden, dass du wartest. Und die britische Buchhaltung hat eine harte Kante: die Umsatzsteuer muss über Software eingereicht werden, die HMRC anerkennt, und HMRC veröffentlicht die Liste. Die Open-Source-Wege zu Making Tax Digital existieren — GnuCash hat eine Community-Brücke, ERPNext hat ein UK-VAT-Modul — aber sie sind gemeinschaftlich gepflegt und kein Produkt mit einem Supportvertrag dahinter. Das ist eine echte Einschränkung und sie gehört in den Vergleich. Drittens lebt und stirbt eine arbeitende Designagentur mit dem Dateiaustausch, und Kunden, die dir eine .psd schicken und eine zurückerwarten, sind ein echtes Problem und keine Prinzipienfrage. Für alle anderen, die ein PDF ausfüllen und unterschreiben lassen müssen, gibt es überhaupt keinen Wechsel zu machen. Es ist einfach aufhören zu zahlen.\nWarum das bessere Geschäft nie verkauft wird Warum wird also nichts davon angeboten? Weil es für sie das bessere Geschäft wäre und nicht das schlechtere, was die Weigerung interessanter macht statt weniger interessant.\nEs gibt zwei Wege, an einem Kunden zu verdienen. Verkauf eine Lizenz weiter, und die Marge wird von jemand anderem gesetzt, von ihm gedeckelt, von ihm zur Verlängerung neu bepreist und gezahlt, ob du in dem Monat gearbeitet hast oder nicht. Roll einen offenen Stack aus und betreib ihn, und die Marge ist deine eigene Arbeit zu deinem eigenen Satz, ohne dass unterwegs jemand eine Scheibe nimmt und ohne dass ein Hersteller die Zahl im nächsten April ändern kann. Das Zweite ist je Kunde mehr wert, und es baut etwas auf. Ein Ingenieur, der Ceph betreiben oder einen Mailserver hinstellen kann, mit dem Outlook spricht, ist nächstes Jahr mehr wert als dieses. Jemand, der nur je eine Konsole bedient hat, ist nächstes Jahr genau gleich viel wert, und nur so lange, wie es diese Konsole gibt.\nEs ist auch schwerer, und das ist der ganze Punkt. Es muss jeden Monat neu verdient werden. Es braucht Ingenieure statt Administratoren, und Ingenieure sind teuer, brauchen Jahre zum Heranwachsen und können hinausspazieren und sich selbstständig machen. Eine Lizenz geht nie.\nDas ist eine Festlegung, und Festlegung ist das, was vermieden wird. Weiterverkaufen verlangt von niemandem etwas. Nimm dieses Jahr einen Hersteller, nächstes Jahr einen anderen, und wenn es umfällt, war es ohnehin nie dein Entwurf. Den Stack selbst zu betreiben heißt, ihn zu wählen, ihn ordentlich zu lernen und um zwei Uhr nachts vor einem Kunden dafür geradezustehen. Für das eine musst du etwas wissen. Für das andere brauchst du einen Portal-Login.\nEs bricht auch die Rechnung, auf der das Modell läuft. Ein Managed Service wird über Hebelwirkung bepreist — so viele Kunden je Ingenieur wie möglich, Nachwuchskräfte, die Runbooks abarbeiten, Eskalation erst, wenn das Runbook ausgeht. Das funktioniert, weil die Arbeit auf Schritte reduziert wurde. Setz einen Stack hinein, den jemand tatsächlich verstehen muss, und das Verhältnis bricht zusammen, die Lohnkosten steigen, und das Unternehmen findet sich abhängig von Leuten, die gehen und Kunden mitnehmen könnten.\nDie Frage unter der Auswahlliste war also nie, welches Produkt besser ist. Sie lautet, ob eine Firma bereit ist, die Sorte zu sein, die Leute beschäftigt, die etwas wissen.\nUnd da kommt die Weiterbildungszahl von vorhin wieder ins Spiel. Eine Branche, die ihre Ausgaben für Qualifikation in zwei Jahren um 30 % gekürzt hat, kann kein Können verkaufen, also verkauft sie Lizenzen. Lizenzen zu verkaufen heißt, dass sie das Können nie erwerben muss, also bleibt die Weiterbildung gekürzt, und nächstes Jahr hat sie noch weniger anzubieten. Das ist eine Schleife, und sie dreht sich nur in eine Richtung.\nDer Rest ist Anreiz, und den haben wir schon durch. Der Hersteller zahlt einen Rabatt auf die Lizenz und überhaupt nichts auf die Arbeit. Der Vertriebler wird auf Produkt vergütet. Und wenn ein Hyperscaler einen Ausfall hat, ist es die Schuld des Hyperscalers, während ein Cluster, den du selbst gebaut hast, deine ist — Weiterverkaufen kauft jemandem also einen Ort, an dem er die Schuld ablegen kann. Das ist einem Unternehmen, das lieber nicht verantwortlich wäre, echtes Geld wert.\nNichts davon macht es zur richtigen Antwort für dich. Es erklärt nur, warum der Vergleich nie geschrieben wird.\nDie IPv4-Steuer Das ist das sauberste Beispiel im ganzen Beitrag, denn du kannst auf beide Seiten einen Preis setzen.\nSie bauen dir einen reinen IPv4-Dienst. Dann verkaufen sie dir die öffentlichen Adressen, die du brauchst, um ihn zu erreichen, je Adresse, je Monat, für immer. Frag nach einer weiteren und es gibt ein Formular, eine Begründung und eine Zeile auf der Verlängerung.\nIPv6 kostet dagegen nichts extra. Die Zuteilung kommt mit der Registry-Mitgliedschaft, die du ohnehin bezahlst, und RIPEs Gebührenordnung 2026 ist ein pauschaler Satz von 1.800 Euro je LIR-Konto, egal was du hältst. RIPE-690 sagt, ein Endstandort bekommt ein /48 oder ein /56. Auf der v6-Seite gibt es keinen Zähler je Adresse. Es gibt nichts zu zählen.\nDie Zahlen auf der anderen Seite sind auch öffentlich. AWS berechnet 0,005 Dollar pro Stunde für jede öffentliche IPv4-Adresse, ob verwendet oder nicht, das sind etwa 43,80 Dollar im Jahr je Adresse. Auf dem Transfermarkt lag der Durchschnittspreis im ersten Halbjahr 2026 bei 20,04 Dollar je Adresse, bei einem üblichen Mietsatz von etwa 0,59 Dollar je Adresse und Monat. Eine Adresse ist also grob zwanzig Dollar im Kauf wert und vermietet sich im Großhandel für etwa sieben im Jahr — und sie wird dir als knappe Ressource weiterverkauft. Eine monatliche Zeile auf deiner Rechnung und ein Formular, wenn du eine weitere willst.\nDie Knappheit ist echt. Der Grund, warum du immer noch dafür bezahlst, nicht. Einen Dienst dual-zustacken ist ein Nachmittag Arbeit, und es verwandelt eine wiederkehrende Gebühr in eine einmalige Änderungsanforderung, was genau der Grund ist, warum es nie vorgeschlagen wird.\nWenn du das volle Bild willst, wer sich in diesem Land tatsächlich bemüht hat: ich habe alle gezählt, in Uns sind nie die Adressen ausgegangen. Uns ist die Mühe ausgegangen.\nCloud als Standard, wenn alles, was du hast, vor Ort steht Denk daran, wo die Arbeit tatsächlich stattfindet. Ein Produktionsstandort. Eine Kfz-Werkstatt. Ein Cateringbetrieb.\nJeder Nutzer ist im Gebäude. Jedes Datum entsteht im Gebäude — die Maschinen, die Kassen, die Auftragskarten, der Bestand, das CAD, die CNC-Programme, die Bestellungen über den Tresen. Alles, was diese Daten verbraucht, ist ebenfalls im Gebäude. Kein zweiter Standort, kein Außendienst, keine Kunden, die auf ein Web-Frontend gehen, und kein Monat, in dem sich die Last verdoppelt.\nSetz die Anwendung in das Rechenzentrum von jemand anderem und jedes dieser Bytes verlässt nun das Gelände und kommt sofort zurück. Dieselben Nutzer. Dieselben Daten. Dieselbe Verarbeitung. Plus ein WAN in der Mitte, eine monatliche Rechnung und eine Abhängigkeit von einer Leitung, die dir nicht gehört.\nNichts, worin die Cloud wirklich gut ist, gilt hier. Elastische Skalierung ist für Last, die sich bewegt, und eine Werkshalle im Zweischichtbetrieb bewegt sich nicht. Globale Reichweite ist für Nutzer, die woanders sind, und deine stehen an der Maschine. Das Gebäude von jemand anderem ist eine echte Antwort für Notfallwiederherstellung, aber Notfallwiederherstellung ist ein Backup-Ziel und nicht der Ort, von dem aus du die Fertigung fährst.\nWas es dir einbringt, ist eine neue Art anzuhalten. Vor Ort ist eine tote Breitbandleitung ein Ärgernis, und die Arbeit geht weiter, bis jemand sie repariert. In der Cloud ist es ein Stillstand — die Leitung geht, die Werkstatt kann keinen Auftrag aufrufen, die Küche kann keine Bestellung annehmen, die Produktion steht, und du wartest auf den Techniker von jemand anderem, gegen ein SLA, das du nie verhandelt hast.\nWohin die Arbeit tatsächlich geht, sobald die Anwendung das Gebäude verlässt Vor Ort Dein Gebäude Die Leute Stehen an der Maschine Die Daten Entstehen hier, alle Die Anwendung Auch hier Nichts verlässt das Gelände. Eine tote Breitbandleitung ist ein Ärgernis, und die Arbeit geht weiter, bis jemand sie repariert. Cloud als Standard, und der Weg, den sie wirklich nimmt Dein Gebäude Dieselben Leute, dieselben Daten Die Vermittlung, in der deine Leitung landet Der Kern deines ISP und wen er als Transit kauft Ein Peering-Punkt oder das Edge-Netz des Anbieters Das Rechenzentrum Die Anwendung lebt jetzt hier Drei Gebäude, die dir nicht gehören, die du nicht anrufen kannst und nie gewählt hast und jedes Byte macht auch den Rückweg, für jedes Speichern und jedes Nachschlagen Eine tote Leitung ist jetzt ein Stillstand. Die Werkstatt kann keinen Auftrag aufrufen, die Küche keine Bestellung annehmen, die Produktion steht, und du wartest auf den Techniker von jemand anderem gegen ein SLA, das du nie verhandelt hast. Dieselben Nutzer, dieselben Daten, dieselbe Verarbeitung. Der Unterschied sind vier fremde Netze in der Mitte, von denen du keines anrufen kannst, wenn es stehen bleibt. Und dein Breitband ist nur die Hälfte davon. Die andere Hälfte ist ihres, und die geht auch aus. AWS\u0026rsquo; eigene Nachbetrachtung zum Oktober 2025 beschreibt eine Störung in seiner Hauptregion Nord-Virginia von 23:48 Uhr am 19. Oktober bis 14:20 Uhr am 20. Oktober — den besseren Teil von fünfzehn Stunden — in der Kunden und andere AWS-Dienste „were unable to establish new connections“. Die Ursache war, in ihren Worten, „a latent defect within the service\u0026rsquo;s automated DNS management system“. Neun Tage später riss Azure Front Door Microsoft 365, Outlook und das Azure-Portal für fast einen ganzen Arbeitstag mit sich. Microsoft führt darüber eine laufende Historie, und es ist kein kurzes Dokument.\nAusfallzeit ist auch nicht alles. Das andere, was vorn auf dem Angebot verkauft wurde, war Kapazität auf Abruf, und das hat einen eigenen dokumentierten Fehlermodus. Microsoft veröffentlicht eine Seite mit dem Titel „Troubleshooting Azure VM allocation failures“. AWS veröffentlicht „How do I troubleshoot InsufficientInstanceCapacity errors when I start or launch an EC2 instance?“. Lies diese Titel noch einmal. Beide Hersteller pflegen ständige Dokumentation für den Fall, dass du eine Maschine anforderst und keine da ist — kein Fehler, kein Ausfall, einfach nichts frei in dieser Region an diesem Tag. Darüber sitzen Kontingente, je Abonnement gesetzt, was eine zweite Art ist, ein Nein zu bekommen.\nDie elastische Skalierung auf dem Angebot trägt also einen Vorbehalt, den das Angebot nicht trägt. Elastisch innerhalb dessen, was frei ist, in dieser Region, an dem Tag, an dem du fragst. Und Dienstleister melden trotzdem weiter Kunden in überlasteten Regionen an, denn eine Unterschrift zählt dieses Quartal und eine Kapazitätsprüfung nicht. Du findest es beim Ausrollen heraus, was der schlechteste verfügbare Moment ist — nachdem die Migration beschlossen ist, nachdem die Geräte vor Ort weg sind und nachdem der Rückfallweg abgebaut wurde, um den Umzug zu bezahlen.\nLies, was das alles für die Werkstatt und die Küche bedeutet. Auf eigenen Geräten ist ein Ausfall jemand, den du anrufen kannst, oder eine Maschine, zu der jemand hinlaufen und sie neu starten kann. In der Cloud von jemand anderem gibt es überhaupt keinen Hebel. Du kannst es nicht eskalieren, du kannst deine eigene Wiederherstellung nicht priorisieren, und der Dienstleister, den du bezahlst, kann es auch nicht. Er lädt dieselbe Statusseite neu wie alle anderen. Was du als Ausfallsicherheit gekauft hast, entpuppt sich als eine Abhängigkeit, die du mit mehreren Millionen anderen Kunden teilst, und an dem Tag, an dem sie versagt, ist deine Lage dieselbe wie ihre.\nWarum ist es dann immer die Empfehlung? Weil ein Kauf deinen MSP einmal bezahlt. Ein Abo bezahlt ihn jeden Monat, prozentual, mit einer Gutschrift des Herstellers obendrauf. Dich zu migrieren nimmt ihm außerdem die Hardware vom Teller, und das ist der Teil des Dienstes, den er am schwersten besetzt bekommt. Drei Gründe, die in dieselbe Richtung zeigen, keiner davon deiner.\nDann ist da, wo deine Daten landen. Nach 18 U.S.C. § 2713, eingefügt durch den CLOUD Act, muss ein US-Anbieter auf ordnungsgemäße Zustellung hin Daten in seinem „possession, custody, or control“ herausgeben, „regardless of whether such communication, record, or other information is located within or outside of the United States“. „Es liegt in der UK-Region“ ist also eine wahre Antwort auf eine Frage, die du nicht gestellt hast. Die Region sagt dir, wo die Platte steht. Das Gesetz folgt dem, wem die Firma gehört.\nNiemand hat dir das als Entscheidung vorgelegt. Es kam als Annahme daher, in einem Angebot, geschrieben von jemandem, der mehr verdient, wenn du ja sagst.\nÜber diese Abhängigkeit habe ich ausführlich geschrieben, in was es kostet, deine Technik zu mieten.\nAll das geschah, bevor irgendetwas gebaut wurde Beachte, wann es stattfindet, das Ganze. Bevor eine Maschine in ein Rack kommt, bevor sich irgendwer irgendwo angemeldet hat, in Besprechungen und auf Tabellen, in denen du meist nicht warst. Der Rabatt, die Anforderungen, die niemand erhoben hat, die eine Option, die fehlende Open-Source-Zeile, die Adressen, die du jetzt für die Laufzeit des Vertrags mietest, das Rechenzentrum, das niemand im Gebäude brauchte — nichts davon ist technisch, und alles davon wird in den ersten zwei Wochen entschieden.\nDeshalb ist es deine Aufmerksamkeit wert, selbst wenn du nie einen Switch aufgemacht hast. Deshalb ist es auch so schwer, es hinterher wieder aufzudröseln. Alles Nachgelagerte erbt diese zwei Wochen. Der Bestand wird so gebaut, wie die Auswahlliste es sagte. Die Werkzeuge tauchen auf, weil es das ist, was der Dienstleister ohnehin besitzt und ohnehin kennt. Die Schlüssel landen dort, wo sein Prozess sie hinlegt. Und der Vertrag, der am Ende unterschrieben wird, entscheidet, Jahre im Voraus, wer den Schaden trägt, an dem Morgen, an dem etwas stehen bleibt.\nTeil zwei handelt also davon, was tatsächlich gebaut wurde: die Kiste, von der sie sich nicht abbringen lassen, die Perimeter-Technik mit der schlechtesten Bilanz auf der Liste ausgenutzter Schwachstellen, die Grundlagen, die das waren, was du gekauft hast, und die Werkzeuge, die von einer Konsole aus, die du nie gesehen hast, jede Maschine erreichen, die dir gehört. Zwei der Versäumnisse darin haben eine Feststellung einer Aufsichtsbehörde daran. Keines davon passierte einem Kunden. Sie passierten einem Dienstleister, und die Kunden waren stromabwärts.\nIs Your MSP Lying To You — 3 parts\nBelügt dich dein MSP, um dir Premium-Produkte zu verkaufen?you are here Was dein MSP dir gebaut hat, und wer sonst noch drankommt Wenn es kaputtgeht, wer trägt es dann wirklich? Quellen Abgerufen am 28. August 2026.\nWie das Geld funktioniert.\nMicrosoft-Partner-Center-Abrechnungsdokumentation — Partner Earned Credit, angewandt auf die Kosten des Azure-Verbrauchs des Kunden. FCA Handbook, COBS 6.1A — Beratungshonorare: die Regel, dass eine Firma für eine Empfehlung nur vom Kunden bezahlt werden darf und keine Provision vom Produktanbieter annehmen darf. CMA-Marktuntersuchung zu Cloud-Diensten — die Arbeit der britischen Wettbewerbsaufsicht zum Cloud-Markt. Adressen.\nRIPE-NCC-Gebührenordnung 2026 — 1.800 Euro je LIR-Konto, pauschal. RIPE-690 — /48 oder /56 an einen Endstandort, Oktober 2017. AWS-Gebühr für öffentliche IPv4 — 0,005 Dollar je Adresse und Stunde, ab Februar 2024. IPv4-Transfermarkt, erstes Halbjahr 2026 — Durchschnitt 20,04 Dollar je Adresse, Mietsatz etwa 0,59 Dollar je Adresse und Monat, Zusammenfassung von CircleIDs Analyse öffentlich bepreister Transaktionen. Das VPN.\nCisco Merakis AnyConnect-Fehlersuchleitfaden — TLS und DTLS auf 443, ohne NAT-Problem zu lösen. RFC 3947 und RFC 3948 — NAT-Traversal für IPsec und der Wechsel auf UDP 4500. Support, den man tatsächlich kaufen kann.\nProxmox-VE-Subskriptionen — ein Beispiel für kommerziellen Support für Open-Source-Infrastruktur. Weiterbildung und Qualifikation.\nLearning and Work Institute, 24. Dezember 2025 — Weiterbildungsinvestitionen der Arbeitgeber real um 36 % je Beschäftigtem seit 2005 gesunken, und in Information und Kommunikation zwischen 2022 und 2024 um 30 %, auf Basis des Employer Skills Survey 2024. National Vulnerability Database — CVE-Veröffentlichungszahlen nach Jahr, quartalsweise summiert: 6.595 im Jahr 2015 gegen 49.972 im Jahr 2025. Cyber Security Breaches Survey 2025/2026 — Zwei-Faktor-Authentifizierung bei 47 % der Unternehmen, formale Richtlinien auf 52 % gefallen, Kontinuitätspläne mit Cyber-Abdeckung auf 44 %. CISA-Warnung, 30. März 2023 — die trojanisierte 3CX-Desktop-Anwendung. Recht und Politik.\nPräsidialverfügung, 10. Februar 2025 — Aussetzung der Durchsetzung des Foreign Corrupt Practices Act, in den Worten der Regierung selbst. Just Security, über das Jahr danach — die Durchsetzungsrichtlinien vom Juni 2025, die aufgelöste FCPA-Einheit der SEC und die eingestellten Ermittlungen. Bribery Act 2010 und Abschnitt 7 — das britische Gesetz und der Unternehmensstraftatbestand des Unterlassens von Präventionsmaßnahmen. Airbus, 31. Januar 2020 — der eigene Bericht des Unternehmens über den dreiseitigen Vergleich und wie sich die Strafen auf PNF, SFO, DoJ und DoS aufteilen. Gerichtsbarkeit.\n18 U.S.C. § 2713 — die CLOUD-Act-Vorschrift: Herausgabe unabhängig davon, wo die Daten gespeichert sind. Wenn die Plattform stehen bleibt.\nAWS-Nachbetrachtung, Oktober 2025 — die DynamoDB- und DNS-Störung in us-east-1, in Amazons eigenen Worten. Azure-Statushistorie — Microsofts eigene laufende Aufzeichnung seiner Vorfälle. ","permalink":"https://blogs.damiendye.uk/de/random/is-your-msp-lying-to-you-part1/","summary":"Teil 1 von 3. Manche lügen. Die meisten müssen es nie, weil sie von dem Hersteller bezahlt werden, dessen Produkt sie empfehlen, und niemand muss es sagen. Die Anzeichen dafür, dass dir verkauft statt für dich konstruiert wird, und was es nie auf die Auswahlliste schafft.","title":"Belügt dich dein MSP, um dir Premium-Produkte zu verkaufen?"},{"content":" Is Your MSP Lying To You — 3 parts\nBelügt dich dein MSP, um dir Premium-Produkte zu verkaufen? Was dein MSP dir gebaut hat, und wer sonst noch drankommtyou are here Wenn es kaputtgeht, wer trägt es dann wirklich? Teil eins war der Verkauf. Hier geht es um den Bestand.\nDie Papiere sind unterschrieben, die Rechnung läuft monatlich, und es gibt Geräte. Manches davon deins, manches ihres, das meiste ausgewählt, bevor irgendwer gefragt hat, was das Unternehmen zwischen acht und sechs eigentlich tut. Was folgt, sind die Geräte selbst: was ausgewählt wird, was darin eingeschaltet gelassen wurde, und wer sonst noch von einer Konsole aus, an der du dich nie angemeldet hast, an die Maschinen kommt, die du bezahlt hast.\nZwei der Versäumnisse hier tragen die Feststellung einer Aufsichtsbehörde mit einer Zahl daran. Keines davon passierte einem Kunden — sie passierten einem Dienstleister, und die Kunden waren stromabwärts. Jede Behauptung trägt einen Link.\nDie Kiste, von der sie sich nicht abbringen lassen Jetzt der unangenehme Teil. Ich will das mit Belegen machen statt mit Behauptungen, denn es ist der Abschnitt, bei dem Leute nach dem Wort Verschwörung greifen — und nach diesem Wort zu greifen ist die Art, wie das Thema fallen gelassen wird, ohne dass jemand hinsehen muss.\nCisco ist in weiten Teilen dieser Branche die Standardempfehlung. Schau also, was der Hersteller selbst über undokumentierte Zugänge in seine eigenen Geräte veröffentlicht hat.\nIm März 2018 veröffentlichten sie eine Meldung zu CVE-2018-0141: bei Prime Collaboration Provisioning konnte man sich per SSH anmelden, wegen „a hard-coded account password on the system“ — einem fest einprogrammierten Kontopasswort. Acht Monate später CVE-2018-15439 bei den Small-Business-Switches, wo „the affected software enables a privileged user account without notifying administrators of the system“, ohne verfügbare korrigierte Software bei Veröffentlichung und mit einer Umgehungslösung stattdessen. Im Oktober 2023 CVE-2023-20101: der Emergency Responder wurde mit einem Root-Konto mit „default, static credentials that cannot be changed or deleted“ ausgeliefert, Zugangsdaten, die „typically reserved for use during development“ sind.\nEin Konto, von dem niemandem erzählt wurde, das du nicht entfernen kannst, mit Root auf einer Kiste in deinem Bestand. Nenn es, wie du willst. Es ist das, was die eigene Meldung des Herstellers beschreibt.\nDann ist da das Snowden-Material, das inzwischen mehr als ein Jahrzehnt alt ist und nie zurückgezogen wurde. Im Dezember 2013 veröffentlichte der Spiegel den ANT-Katalog und berichtete, eine NSA-Abteilung habe sich „into nearly all the security architecture made by the major players in the industry \u0026ndash; including American global market leader Cisco and its Chinese competitor Huawei“ eingegraben. Dieselbe Berichterstattung beschrieb, wie Geräte dorthin gelangen: Sendungen werden in geheime Werkstätten umgeleitet, in einem Verfahren, das die NSA Interdiction nennt, wo „at these so-called \u0026rsquo;load stations,\u0026rsquo; agents carefully open the package in order to load malware onto the electronics, or even install hardware components that can provide backdoor access“. Ein interner NSA-Newsletter von 2010, 2014 mit den Fotos veröffentlicht, legte das Verfahren in den eigenen Worten der Behörde dar: Geräte, die „being delivered to our targets throughout the world are intercepted“, würden dann „re-packaged and placed back into transit to the original destination“.\nWas die Berichterstattung nicht zeigt, ist Mittäterschaft. Der Spiegel sagte klar, nichts in den Dokumenten deute darauf hin, dass die Hersteller davon wussten oder halfen, und Cisco bestritt damals jede Beteiligung, und im Mai 2014 gab sein Chefjustiziar zu Protokoll: „as a matter of policy and practice, Cisco does not work with any government, including the United States Government, to weaken our products“. Sie beschwerten sich beim Präsidenten darüber. Dem Anschein nach waren sie hier auch Opfer.\nNimm das für bare Münze. An der Kiste in deinem Rack ändert es nichts, denn Interdiction hat die Hilfe des Herstellers nie gebraucht. Und es lohnt sich zu wissen, welches Gewicht das Dementi hat, denn Ciscos Wort ist vor Gericht geprüft worden. 2019 legten sie ein Verfahren nach dem False Claims Act für 8,6 Millionen Dollar auf Bundesebene bei, plus 6 Millionen Dollar über eine Gruppe von Bundesstaaten, wegen Videoüberwachungssoftware, die an Behörden verkauft wurde mit „flaws that would permit unauthorized access to the system, with the potential to control and otherwise manipulate security cameras and the recorded footage“. Die Darstellung der New Yorker Generalstaatsanwaltschaft ist, dass Cisco 2009 von den Mängeln wusste und sie erst 2013 behob, nachdem die Ermittlung begonnen hatte. Vergleiche sind keine Schuldanerkenntnisse und ich tue nicht so. Sie sind trotzdem vier Jahre, in denen ein Produkt an Polizeibehörden und öffentliche Stellen verkauft wurde, mit einem bekannten Weg hinein, ohne das zu sagen.\nDas Protokoll lautet also: undokumentierte Root-Konten nach eigenem Eingeständnis, ein zehn Jahre alter Katalog, der sie nennt, eine Lieferkette, deren Kompromittierbarkeit vorgeführt wurde, und eine Zeit, in der sie von einem Loch wussten und weiterverkauften. Jedes Einzelne davon könnte man abtun. Zusammen sind sie ein Muster. Eine Erklärung einer interessierten Partei entkräftet kein Muster.\nDie Antwort darauf sind Kontrollen, kein Verbot. Das Risiko gehört mit allem anderen ins Entwurfsdokument, und die Alternativen werden bepreist statt weggewischt. Frag, welche konkurrierenden Geräte bewertet wurden und was sie kosteten. Frag, wie die Richtlinie zu Firmware-Prüfung und -Aktualisierung lautet und wer sie kontrolliert. Frag, wie die Geräte angenommen und geprüft werden, und von wem. Frag, was bei einer Seriennummer passiert, die nicht zur Bestellung passt.\nUnd beachte, welche Hersteller in deiner Branche diese Prüfung bekommen und welche nicht. Dieselbe Branche, die Huawei wegen einer Fähigkeit, die niemand öffentlich vorgelegt hat, in ein Risikoregister setzte, schreibt Cisco ohne eine Zeile Begründung ins Feindesign, auf die Kraft eines Partner-Logos hin. Ich habe darüber geschrieben, was mit diesem Argument passiert, wenn man den Maßstab gleichmäßig anlegt. Ein Partner-Logo ist eine Geschäftsbeziehung mit Zielen daran. Als solches ist es kein Sicherheitsbefund.\nDie Firewall ist der Weg hinein Weite das von einem Hersteller auf die Kategorie aus, denn die Firewall ist das Produkt, das ein MSP am härtesten verkauft. Sie ist der Posten, der den Sicherheitsteil des Vertrags rechtfertigt.\nCISA führt einen Katalog von Schwachstellen, die nachweislich in freier Wildbahn ausgenutzt werden — nicht theoretisch gefährlich, tatsächlich gegen jemanden eingesetzt. Ich habe den Katalog gezogen und nach Hersteller ausgezählt. Version 2026.08.27 hält 1.685 Einträge. Cisco steht für 96 davon, nur hinter Microsofts 386, und 42 davon sitzen auf den Firewall- und Edge-Linien. Fortinet hat 29. Palo Alto Networks hat 15. Zur Einordnung: Ivanti hat 35 und SonicWall 17.\nSchau, was die Einträge tatsächlich sind, denn das Muster wechselt nie. Es ist die Verwaltungsoberfläche oder das VPN, also der Teil, der absichtlich ins Internet gestellt ist.\nDer einzige Teil dieser Zeitleiste, den du schließen musst Eine Schwachstelle, von veröffentlicht bis gepatcht auf deiner Kiste Veröffentlicht eine CVE-Nummer existiert Patch verfügbar der Teil des Herstellers ist erledigt Ausnutzung bestätigt in CISAs Katalog aufgenommen Deine Kiste gepatcht von dem, den du bezahlst Deine Angriffsfläche Nachweislich gegen jemanden eingesetzt, sitzt immer noch auf deinem Perimeter Cisco 96 Einträge, Fortinet 29, Palo Alto 15. Das sind die Zahlen der Hersteller und sie sind öffentlich. Die Länge dieser schattierten Spanne ist deine, und niemand fragt danach. Jeder Dienstleister hat die Zahl. Es ist dieselbe Messung, die die ICO bei Capita vornahm. Die Gesamtzahl des Herstellers ist öffentlich und ist nicht die Zahl, die entscheidet, ob es dich trifft. Die schattierte Spanne ist es, und sie gehört dem, den du bezahlst. Palo Altos CVE-2024-3400 war eine Befehlsinjektion in der GlobalProtect-Funktion von PAN-OS, mit 10,0 bewertet, als Zero-Day ausgenutzt. Später im selben Jahr ließ CVE-2024-0012 „an unauthenticated attacker with network access to the management web interface“ mit 9,8 glatt an der Authentifizierung vorbei, und es wurde mit einer Befehlsinjektion in derselben Oberfläche verkettet.\nFortinets CVE-2022-40684 war eine „authentication bypass using an alternate path or channel“ mit 9,8. Sein CVE-2018-13379, ein Path Traversal im SSL-VPN, kam im November 2021 in den Katalog. Jahre nachdem es den Patch gab, weil Kisten immer noch ungepatcht im Internet standen und man in sie hineinspazierte.\nCiscos CVE-2023-20198 in der IOS-XE-Weboberfläche wurde mit 10,0 bewertet. CVE-2025-20333, im VPN-Webserver seiner Secure-Firewall-ASA- und -FTD-Software, wurde im September letzten Jahres mit 9,9 bewertet.\nUnd dann ist da CVE-2026-20316, am 29. Juli 2026 in den Katalog aufgenommen. Cisco Secure Firewall Management Center, „use of hard-coded password“, was „an unauthenticated, remote attacker to log in to an affected device“ erlaubt. Ein statisches Zugangsdatum, in der Kiste, die die Firewalls verwaltet, als ausgenutzt bestätigt, einen Monat vor diesem Beitrag. Dasselbe Versagen wie 2018 und 2023 im Abschnitt oben, auf der Maschine, die deinen Perimeter verwaltet.\nJetzt der nützliche Teil, denn „manche Hersteller sind schlechter als andere“ ist nicht wirklich die Lehre. Jedes davon hat ein öffentliches Protokoll und nichts davon taucht in einem Angebot auf. Wichtiger noch: die Gesamtzahl des Herstellers ist nicht die Zahl, die entscheidet, ob es dich trifft. Deine Angriffsfläche ist die Lücke zwischen dem Eintrag einer Schwachstelle in diesen Katalog und dem Patchen deiner Kiste. Diese Lücke zu schließen ist nicht Sache des Herstellers. Sie gehört dem, den du für den Betrieb bezahlst.\nWas dieselbe Messung ist, die die ICO bei Capita vornahm. Alarm bei zehn Minuten, Handlung bei achtundfünfzig Stunden, Ziel eine. Niemand fragt seinen Dienstleister nach dieser Zahl beim Firewall-Patchen, und es ist eine Zahl, die jeder Dienstleister hat.\nWenn die Grundlagen das sind, was du gekauft hast In Teil eins ging es um den Verkauf. Hier geht es um das, was danach kam, in zwei Fällen, in denen eine Aufsichtsbehörde ermittelt und veröffentlicht hat, was sie fand.\nIm März 2025 belegte der Information Commissioner die Advanced Computer Software Group mit einem Bußgeld von 3,07 Millionen Pfund wegen eines Ransomware-Vorfalls im August 2022. Advanced „provides IT and software services to organisations, including the NHS and other healthcare providers“. Die Angreifer kamen „via a customer account that did not have multi-factor authentication“ hinein. NHS 111 wurde gestört, Pflegepersonal kam nicht an Patientenakten, und die persönlichen Daten von 79.404 Menschen wurden entwendet. Die Feststellung der ICO zur Ursache lohnt langsames Lesen: „while Advanced had installed multi-factor authentication across many of its systems, the lack of complete coverage meant hackers could gain access“. Es war auch das erste Bußgeld, das die ICO gegen einen Auftragsverarbeiter statt gegen die Organisation verhängt hat, deren Daten es waren.\nIm Oktober 2025 belegte dieselbe Aufsicht Capita mit einem Bußgeld von 14 Millionen Pfund wegen des Angriffs von 2023, bei dem die persönlichen Daten von 6,6 Millionen Menschen abflossen. Am 22. März 2023 landete eine bösartige Datei auf einem Mitarbeitergerät. Ein Alarm hoher Priorität ging binnen zehn Minuten los. Das Gerät wurde 58 Stunden lang nicht in Quarantäne genommen, gegen eine angestrebte Reaktionszeit von einer Stunde, und die ICO fand, dass das Security Operations Centre „was understaffed, and in at least six months before the incident fell well below the target response times for responding to security alerts“, neben unzureichenden Penetrationstests und Risikobewertungen.\nLies, was diese zwei Feststellungen gemeinsam haben. Kein raffinierter Gegner. Kein Zero-Day. Nicht owt, was niemand hätte kommen sehen können. Zwei-Faktor-Authentifizierung, die gekauft, aber nicht fertiggestellt wurde, und eine Alarmwarteschlange, die niemand besetzt hatte. Beides sind Posten, die jemand abgezeichnet und grün gemeldet hat.\nUnd nichts davon hat sich an die Branche herangeschlichen. Am 11. Mai 2022, drei Monate vor dem Vorfall bei Advanced, gaben die Cybersicherheitsbehörden des UK, Australiens, Kanadas, Neuseelands und der Vereinigten Staaten eine gemeinsame Warnung zu Bedrohungen für Managed Service Provider und ihre Kunden heraus, weil ihnen „recent reports that observe an increase in malicious cyber activity targeting managed service providers“ bekannt waren. Die erste taktische Maßnahme auf der Liste betrifft die Durchsetzung von Zwei-Faktor-Authentifizierung auf den MSP-Konten, die in die Umgebung des Kunden hineinreichen.\nDie Sicherheitsbehörden von fünf Ländern haben es öffentlich aufgeschrieben und die Kontrolle benannt. Drei Jahre später verhängt eine Aufsicht immer noch Bußgelder dafür, dass sie nicht fertiggestellt wurde.\nKeines davon ist eine Geschichte über kleine Unternehmen. Hier ist eine. Am Freitag, dem 24. November 2023, fiel der IT-Dienstleister CTS für den Rechtssektor bei einem Cybervorfall aus. Die eigene Zeitung der Law Society berichtete, dass rund 80 Kanzleien keine Transaktionen abschließen konnten, mit abgeschalteten Systemen und feststeckenden Verträgen. Das sind Kanzleien für Immobilienübertragung, die meisten davon kleine Büros, und ihre Kunden waren Menschen mitten im Umzug. Einer davon sagte es klar: „This leaves us with so much uncertainty — with movers needing to be booked, days needing to be taken off work at potentially short notice and lives put on hold.“ CTS konnte nur sagen, es sei „unable to give a precise timeline for full restoration“.\nNiemand in dieser Kette hat CTS ausgewählt. Die Kanzlei hat es ausgewählt, und jeder Mandant stromabwärts der Kanzlei hat die Entscheidung geerbt, ohne je gefragt worden zu sein.\nDas ist es, was du kaufst, wenn du einen Managed Service kaufst.\nUnd wie hättest du es erfahren? Beachte etwas an jedem Vorfall im Abschnitt oben. Keiner davon passierte dem Kunden. Sie passierten dem Dienstleister, und die Kunden saßen stromabwärts der schlechten Woche von jemand anderem.\nStell die Frage also direkt. Wenn ihr kompromittiert werdet, erfahren wir es von euch? Und wie schnell?\nEs gibt eine rechtliche Untergrenze, und sie liegt niedriger, als Leute annehmen. Wo sie personenbezogene Daten in deinem Auftrag verarbeiten, sagt Artikel 33: „the processor shall notify the controller without undue delay after becoming aware of a personal data breach“. Keine feste Stundenzahl. Du hingegen hast als Verantwortlicher 72 Stunden Zeit, den Information Commissioner zu unterrichten, sobald du Kenntnis erlangst. Lies die beiden zusammen. Jede Stunde, die sie damit verbringen zu entscheiden, ob sie es dir sagen, ist eine Stunde weniger auf einer Uhr, die gegen dich läuft, nicht gegen sie.\nUnd diese Untergrenze deckt nur personenbezogene Daten ab. Ein Einbruch in ihre Verwaltungskonsole, ohne bisherigen Beleg, dass etwas von dir bewegt wurde, kann überhaupt keine Pflicht auslösen, es dir zu sagen — während die Zugangsdaten, die jede Maschine erreichen, die dir gehört, in fremden Händen sitzen. Das ist die Lücke. Sie ist nicht klein.\nDenk daran, wer vor dir informiert wird. Ihre Anwälte, wegen des Anwaltsprivilegs. Ihr Versicherer, weil die Police es sagt. Ihre Aufsicht, auf der gesetzlichen Uhr. Du stehst weiter unten auf dieser Liste, als dir lieb ist, und der Anreiz bei jedem Schritt ist, weniger zu sagen, bis man mehr weiß.\nWas die Alternativen übrig lässt, und die sind alle schlechter. Du erfährst es, weil deine Systeme stehen bleiben, so wie es die Immobilienkanzleien erfuhren. Du erfährst es, weil ein Journalist anruft. Oder du erfährst es, weil jemand den Namen des Dienstleisters auf der Leak-Seite einer Ransomware-Bande entdeckt, was kein Benachrichtigungsverfahren ist, sondern ein Zufall aus dem Marketing von jemand anderem.\nAlso vertragle es, und sei konkret, denn vage Klauseln fallen auf die gesetzliche Untergrenze zurück. Benachrichtigung über jeden erheblichen Vorfall in ihrem Netz binnen einer genannten Stundenzahl, schriftlich, unabhängig davon, ob deine Daten bestätigt betroffen sind. Benachrichtigung, wenn irgendein Zugangsdatum mit Zugriff auf deine Systeme offengelegt worden sein könnte. Benachrichtigung, wenn sie auf einer Leak-Seite auftauchen. Ein benannter Ansprechpartner auf deiner Seite, kein Sammelpostfach.\nDann stell die Frage, die dir am meisten sagt, und stell sie, während sie dir noch verkaufen wollen. Hattet ihr einen Vorfall? Was ist passiert, wann haben Kunden es erfahren, und wie haben sie es erfahren? Ein Dienstleister, der einen durchgemacht und ordentlich gehandhabt hat, erzählt dir davon. Es ist der beste Beleg, den er hat. Wer sagt, es sei nie passiert, hat entweder sehr viel Glück gehabt, ist sehr klein, oder zählt nicht owt.\nDas Werkzeug, das alle Kunden auf einmal erreicht Kein MSP verdient Geld damit, Maschinen einzeln anzufassen. Die Wirtschaftlichkeit braucht eine Konsole, die alles erreicht, und dafür ist Remote-Monitoring-and-Management-Software da. RMM sitzt auf jeder Maschine unter Vertrag, läuft als System, und der Dienstleister steuert das Ganze von einem einzigen Login aus.\nEine Konsole erreicht jede Maschine, bei jedem Kunden Der Werkzeughersteller Liefert den Agenten und jedes Update dazu einem signierten Update wird beim Eintreffen vertraut Die Konsole deines Dienstleisters Ein Login, jeder Kunde, den er hat Ein anderer Kunde Agent auf jeder Maschine Dein Gebäude Agent auf jeder Maschine, läuft als System Ein anderer Kunde Agent auf jeder Maschine Die Maschine vertraut der Konsole. Die Konsole vertraut dem Hersteller. Deiner Firewall wurde gesagt, sie solle das alles erlauben. Die Reichweite ist das Produkt. Eine Konsole, jeder Kunde, jede Maschine — weshalb ein Angreifer, der die Konsole bekommt, alles auf einmal bekommt. Dreh das um und schau es von deiner Seite an. Auf deinen Maschinen ist Software, die du nicht ausgewählt hast, wahrscheinlich nicht benennen kannst und deren Patch-Historie du nie gesehen hast. Als solche kann sie alles, mit jeder von ihnen, jederzeit.\nDie Bilanz dieser Werkzeuge ist nicht beruhigend. Fang 2021 an.\nKaseya, Juli 2021. CISA und das FBI beschrieben eine Reaktion auf Ransomware, die „leveraging a vulnerability in the software of Kaseya VSA on-premises products — against managed service providers (MSPs) and their downstream customers“ vorging. Rund fünfzig Dienstleister waren betroffen, und bis zu 1.500 Unternehmen darunter, von denen die meisten nie von Kaseya gehört hatten und kein Mitspracherecht darüber hatten, dass es da war.\nIm Januar 2023 gaben CISA, die NSA und das MS-ISAC eine gemeinsame Warnung heraus, um „network defenders about malicious use of legitimate remote monitoring and management (RMM) software“ zu warnen, nach einer Kampagne im Oktober davor, in der Angreifer Leute per Phishing dazu brachten, ScreenConnect und AnyDesk zu installieren, und damit dann einen Rückerstattungsbetrug gegen die Bankkonten der Opfer fuhren. Dafür musste niemand einen MSP kompromittieren. Das Werkzeug funktioniert für sie genauso gut wie für den Dienstleister.\nIm Februar 2024 stellte sich heraus, dass ConnectWise ScreenConnect CVE-2024-1709 trug, das „may allow an attacker direct access to confidential information or critical systems“. Es wurde mit 10,0 bewertet. Beachte die Schwachstellenklasse: Authentifizierungsumgehung über einen alternativen Pfad oder Kanal, Wort für Wort dieselbe Kategorie wie die FortiOS-Umgehung weiter oben. Anderer Hersteller, anderes Produkt, derselbe Fehler. Volle Punktzahl, in der Software, die jeden Kunden erreicht, den ein Dienstleister hat.\nDann SimpleHelp. CISAs Warnung vom Juni 2025 beschreibt Ransomware-Akteure, die „leveraging unpatched instances of a vulnerability in SimpleHelp Remote Monitoring and Management (RMM) to compromise customers of a utility billing software provider“ vorgingen und „downstream customers“ für doppelte Erpressung erreichten. Die zugrunde liegende Schwachstelle, CVE-2024-57727, lässt einen nicht authentifizierten Angreifer „server configuration files containing various secrets and hashed user passwords“ direkt vom Host ziehen.\nBeachte, wo der Schaden jedes Mal landet. Nicht beim Hersteller. Auch nicht wirklich beim Dienstleister. Bei den Kunden darunter, die das Werkzeug nie gekauft haben, denen nie gesagt wurde, welches es ist, und die überhaupt kein Mitspracherecht darüber hatten, wann es gepatcht wird.\nEin Vorbehalt zu diesen Quellen, denn er ist wichtig. Es sind amerikanische Warnungen, und zwar weil CISA Vorfalldetails veröffentlicht und das NCSC in der Regel keine Namen nennt. Das ist ein Unterschied in der Offenlegung, kein Unterschied im Verhalten. Die Werkzeuge sind dieselben Werkzeuge aus demselben Katalog, und ein kleiner IT-Dienstleister in diesem Land betreibt heute Nachmittag ScreenConnect oder SimpleHelp oder einen ihrer Wettbewerber auf deinen Maschinen.\nFrag also, welches es ist. Frag, welche Version, wann es zuletzt gepatcht wurde, wer sich an der Konsole anmelden kann, ob jedes Konto darauf Zwei-Faktor-Authentifizierung hat, und wie der Plan aussieht, wenn eines davon das nächste Mal eine Zehn ausliefert.\nDann frag noch eines, denn die Antwort sagt dir etwas, was die anderen nicht sagen. Funktioniert es über IPv6?\nEs ist 2026 eine faire Frage und sie schlägt härter ein, als sie aussieht. Wenn das Verwaltungswerkzeug nur IPv4 spricht, dann ist IPv4 das, was dein Netz behalten muss — nicht weil dein Geschäft es braucht, sondern weil ihre Werkzeuge es brauchen. Das ist ein Adressierungsplan, der von der Software eines Lieferanten gesetzt wird statt von deinen Anforderungen, und du zahlst monatlich für die Adressen, die das möglich machen. Ein Heimarbeiter an einem Mobilfunkanschluss ist womöglich schon in einem reinen IPv6-Netz, in welchem Fall das ganze Arrangement sich auf eine Übersetzung stützt, die jemand anderes pflegt.\nUnd wenn die Antwort ist, dass sie das nie geprüft haben, hast du das erfahren, wonach du eigentlich gefragt hast.\nZuerst eine schlichtere Frage, die im ganzen Sicherheitsgerede vergessen geht. Welche Last legt der Agent auf die Maschine, und wo sind die Belege?\nDie Antwort, die du bekommst, ist „vernachlässigbar“. Das ist ein Adjektiv. Was du willst, ist eine Zahl, gemessen auf Hardware wie deiner statt aus einem Datenblatt abgeschrieben — durchschnittliche und Spitzen-CPU, belegter Speicher, Plattenaktivität während eines Inventarlaufs oder Patch-Scans, und Netzwerkverkehr pro Tag. Genommen auf der ältesten Maschine im Bestand, nicht auf der neuesten.\nUnd miss den ganzen Stapel, nicht einen Agenten allein. Fernwartung, Virenschutz, Endpoint Detection, den Backup-Client, Monitoring, Inventarisierung. Jeder Hersteller sagt unter einem Prozent, es sind sechs davon, und die Person, die tatsächlich auf diesem Laptop arbeiten muss, ist die, die herausfindet, was sechs davon zusammen ergeben. Nahe null ist das richtige Ziel. Belege sind der einzige Weg, es festzustellen.\nVerlang die Zahlen vor dem Rollout, und verlang, danach eigene auf einer Maschine deiner Wahl zu nehmen. Ein Dienstleister, der seinen Werkzeugen vertraut, bietet beides an, ohne dass man drängen muss.\nNoch eines zum Werkzeug selbst, und es ist das, was Leute am seltsamsten finden, bis sie es zu Ende denken. Wirst du benachrichtigt, wenn sich der Agent auf deinen Maschinen aktualisiert?\nDer Agent ist die Software mit den höchsten Rechten in deinem Bestand. Er läuft als System, auf allem, und er wechselt die Version, wann immer der Dienstleister oder der Hersteller es beschließt. Software wird von einem Dritten quer über dein gesamtes Unternehmen installiert, stillschweigend, und bei den meisten Verträgen sagt dir niemand, dass es passiert ist.\nJetzt setz das neben das, was bei Kaseya tatsächlich schiefging. Ein bösartiges Update, über einen vertrauten Verwaltungskanal auf jede Maschine gleichzeitig geschoben. Von deinem Platz aus, an dem Tag, ist das von einem routinemäßigen Agenten-Update nicht zu unterscheiden — derselbe Kanal, dieselben Rechte, dieselbe Stille. Der einzige Unterschied ist die Absicht. Absicht ist nichts, was du beobachten kannst.\nVerlang also Benachrichtigungen über Versionswechsel, frag, wer ein Agenten-Update freigibt und ob es irgendwo getestet wird, bevor es dich erreicht, und frag das Wichtigste: was würde dir sagen, dass eine Verteilung stattgefunden hat, die nicht hätte stattfinden sollen? Wenn die ehrliche Antwort nichts ist, dann ist die Kontrolle, auf die du dich verlässt, die eigene Wachsamkeit des Dienstleisters, und darum geht es in diesem ganzen Abschnitt.\nUnd die Schlüssel, die es aufsperren Dann ist da, was die Konsole aufsperrt. Das bekommt noch weniger Aufmerksamkeit als die Konsole.\nEin MSP hält Administratorzugangsdaten für jeden Kunden in seinen Büchern. Das ist die Aufgabe — es ist das ganze Produkt. Der Maßstab, den er an seine eigenen Zugangsdaten anlegt, sollte also höher sein als der, den er für deine setzt, und in der Praxis ist er regelmäßig niedriger. Gemeinsame Konten, weil individuelle Logins für zwölf Ingenieure über zweihundert Mandanten lästig sind. Passwörter in einem Tresor, den der ganze Service Desk lesen kann. SSH-Schlüssel ohne Passphrase auf Laptops, die abends im Zug nach Hause fahren. Notfallkonten, die niemand angerührt hat, seit die Person, die sie angelegt hat, die Firma verlassen hat.\n„Wir benutzen MFA“ ist da, wo dieses Gespräch normalerweise endet, und das sollte es nicht, denn die Formen davon sind nicht gleichwertig. CISA ordnet sie von stärkster zu schwächster: FIDO/WebAuthn und PKI-basiert ganz oben, was sie „the gold standard“ nennt; app-basierte Einmalpasswörter und Push-Benachrichtigungen darunter, „vulnerable to push bombing attacks as well as user error“; und SMS ganz unten, was „should only be used as a last resort MFA option“. Nur die oberste Reihe ist phishing-resistent. Alles darunter kann weitergeleitet, ermüdet oder abgefangen werden, während die Person, die es freigibt, glaubt, sie melde sich ganz normal an.\nDie Angreifer haben dieses Dokument auch gelesen. CISAs Warnung zu Scattered Spider sagt, die Gruppe „targets large companies and their contracted information technology (IT) help desks“. Nicht den Kunden. Den Help Desk, der die Zugangsdaten des Kunden zurücksetzen kann. Das ist erheblich leichter, und es bringt dir alle auf einmal.\nDie Frage ist also enger als die, ob sie MFA benutzen. Ist jedes Konto, das deine Systeme erreicht, auf einem Hardware-Token — einem Token, keiner App — und was passiert, wenn abends um elf jemand beim Service Desk anruft und sagt, er sei ein Ingenieur, der sich ausgesperrt hat?\nDie Behebung ist hier ungewöhnlich einfach, was ihr Fehlen schwer verzeihlich macht. Google sagte KrebsOnSecurity 2018, es habe „has not had any of its 85,000+ employees successfully phished on their work-related accounts since early 2017“, seit es statt Passwörtern und Einmalcodes physische Sicherheitsschlüssel verlangte. Nicht weniger Vorfälle. Keine. Derselbe Artikel merkt an, dass der einfache Schlüssel für zwanzig Dollar zu haben war.\nJetzt skalier das auf einen Managed Service Provider. Sie müssen deinen Mitarbeitern keine Schlüssel ausgeben. Sie müssen sie ihren eigenen Ingenieuren ausgeben, und davon gibt es vielleicht ein Dutzend, die die Zugangsdaten halten, die jeden Kunden in den Büchern erreichen. Ein Dutzend Schlüssel, einmal gekauft, gegen einen Wirkungsradius, der jedes Unternehmen abdeckt, das sie anfassen. Zwanzig Pfund das Stück. Wenn dir jemand sagt, Hardware-Tokens seien unpraktikabel, frag, wie viele Leute tatsächlich einen bräuchten.\nUnd es gibt dazu eine verwandte Frage, die du zu deinem eigenen Bestand stellen solltest, denn die meisten Kunden sind nie darauf gekommen. Wer hält das Notfallkonto für deine Systeme? Bei sehr vielen Verträgen lautet die ehrliche Antwort, dass der Dienstleister es tut und du überhaupt keines hast. Du kommst nicht in deine eigene Infrastruktur, ohne ihn anzurufen. Das ist keine Sicherheitskontrolle, es ist eine Abhängigkeit. Sie beißt an den schlimmsten Tagen und nicht an den gewöhnlichen. An dem Tag, an dem du kündigst. An dem Tag, an dem sie von jemandem gekauft werden, den du nicht ausgesucht hast. An dem Tag, an dem sie die Kompromittierten sind und du ohne sie handeln musst.\nDu solltest deine eigenen Notfallzugangsdaten halten, versiegelt, in den Vertrag geschrieben und an einem Datum getestet, auf das jemand zeigen kann. Wenn dein Dienstleister zögert, hat dir das Zögern selbst etwas gesagt.\nDieselbe Frage läuft bis zum Schreibtisch hinunter, und das ist die, die völlig vergessen wird. Jeder Laptop und jeder Desktop, den sie für dich gebaut haben, hat ein BIOS-Administratorpasswort, beim Bau von jemandem auf ihrer Seite gesetzt. Dir gehört die Maschine. Sie halten den Schlüssel dazu.\nDenk daran, was dieses Passwort tatsächlich regelt. Bootreihenfolge. Secure Boot. Ob das Ding überhaupt von einem USB-Stick startet. Also ob du eine Maschine, die dir gehört, neu installieren kannst, eine wiederherstellen kannst, die nicht bootet, einen Schwung an jemand anderen übergeben oder sie ordentlich löschen kannst, bevor sie aus der Tür gehen. Auf einem Laptop kann es auch das sein, was zwischen einem Dieb und der Platte steht. Nichts davon ist exotisch. Es ist das gewöhnliche Geschäft, Computer zu besitzen, und in sehr vielen Beständen kann der Eigentümer nichts davon tun, ohne den Lieferanten anzurufen.\nVerlang alles. Jeder Laptop, jeder Desktop, jeder Server — das BIOS- oder Firmware-Passwort, das BMC-Login bei allem, was eines hat, und das Bootloader-Passwort bei allem, wo GRUB oder sein Äquivalent gesperrt wurde, was dieselbe Sperre eine Ebene höher ist und das, was zwischen dir und einem Rettungsstart auf einem Server steht, der nicht hochkommt. Wenn es auf allen dasselbe Passwort ist, ist auch das wissenswert. Und wenn die Antwort nein lautet, frag warum, denn die angebotenen Gründe sind dünn: der ehrliche ist, dass es ihren Bau einfacher macht, und der Rest ist als Sicherheit verkleidet. Ein Passwort, das du nicht haben darfst, schützt dich vor niemandem. Es schützt sie davor, dass du gehst.\nDann ist da das Konto, mit dem du dich tatsächlich anmeldest, um eine Maschine zu reparieren. Lokaler Administrator auf jeder Windows-Kiste, Root auf jeder Linux-Kiste, und etwas Entsprechendes auf jedem Switch, jeder Firewall und jedem Hypervisor im Gebäude. Zwei Fragen decken alles ab, und sie decken auch die Firmware- und Bootloader-Passwörter oben ab. Sind sie auf jeder Maschine anders, und wessen Passwortverwaltung hält sie — deine oder ihre?\nAnders sein zählt mehr, als Leute erwarten. Ein lokales Administratorpasswort über zweihundert Maschinen sind nicht zweihundert Passwörter, es ist eines, und es sitzt auf dem am schlechtesten verteidigten Laptop der Firma ebenso wie auf dem Finanzserver. Das ist keine theoretische Schwäche, es ist der Standardzug — komm auf irgendetwas, lies das Passwort, lauf zu allem. Microsoft liefert die Antwort mit. Windows LAPS setzt auf jeder Maschine ein anderes Passwort, wechselt es nach Zeitplan und sichert es in Active Directory oder deiner eigenen Entra-Mandantschaft. Microsofts eigene Seite nennt als ersten Nutzen „protection against pass-the-hash and lateral-traversal attacks“, und die Funktion ist in jeder unterstützten Windows-Version kostenlos, ohne dass für das Ablegen der Passwörter im eigenen Verzeichnis etwas weiter zu zahlen wäre. Wenn die Antwort also ein Passwort überall lautet, ist es kein Lizenzproblem und kein Werkzeugproblem. Jemand hat es nie eingeschaltet.\nWessen System das Passwort zu deiner Maschine hält Die verbreitete Regelung Ihr Tresor, oder der an ihre Werkzeuge geschraubte Jedes Administratorpasswort deiner Firma, gehalten von einer Firma ohne Konto für dich Deine Maschinen Server, Laptops, Switches, Firewalls, Hypervisoren Das Protokoll, wer eines las, ist ihres Du kannst nicht auditieren, wo du kein Login hast Entziehen heißt höflich bitten, im schlechtesten Moment Die Regelung, die du willst Dein Verzeichnis, oder dein Tresor Ein anderes Passwort je Maschine, gewechselt, hinterlegt, wo deine Zugriffskontrolle hinreicht Dieselben Maschinen Dem Dienstleister wird Zugriff gewährt, keine Obhut Du behältst den Nachweis, wer was gelesen hat Du siehst es heute, ohne jemanden zu fragen Du kannst ihn an einem Dienstagnachmittag entziehen Ein lokales Administratorpasswort über zweihundert Maschinen sind nicht zweihundert Passwörter. Es ist eines, und es sitzt auf dem am schlechtesten verteidigten Laptop ebenso wie auf dem Finanzserver. Microsoft liefert die Antwort darauf für nowt, und es legt das Passwort in dein Verzeichnis statt in ihres. Dieselben Maschinen, dieselben Passwörter, zwei verschiedene Antworten darauf, wer sie hält und wer sehen kann, wann eines gelesen wird. Wessen System es ist, ist der Punkt, auf den man drücken muss, und beachte, wohin LAPS das Passwort standardmäßig legt: in dein Verzeichnis, unter deine Zugriffskontrolle, mit deinem Nachweis darüber, wer es gelesen hat. Das ist die Form, die du bei allem willst. Das Zugangsdatum zu deiner Maschine lebt in etwas, das dir gehört, und deinem Dienstleister wird Zugriff darauf gewährt — Zugriff, den du sehen und an einem Dienstagnachmittag ohne Nachfrage entziehen kannst.\nDie andere Form ist die verbreitete. Die Passwörter sitzen in ihrem Passwortmanager, oder im an ihr Fernwartungswerkzeug geschraubten Tresor für privilegierte Zugriffe, und du hast kein Login dafür. Dann wird jedes Administratorpasswort in deiner Firma von einer Firma gehalten, bei der du kein Konto hast, das Protokoll darüber, wer eines gelesen hat, ist ihres, und an dem Tag, an dem die Beziehung sauer wird, bittest du höflich um die Schlüssel zu Maschinen, die dir gehören.\nStell also die Folgefrage, und stell sie jetzt statt beim Ausstiegsgespräch. Wie kommen die in unser System? Es gibt drei ehrliche Antworten. Verschiebt die Hinterlegung in unser Verzeichnis oder unseren Tresor und nehmt delegierten Zugriff darauf. Oder gebt uns heute Lesezugriff auf euren, mit einem Export, den wir selbst laufen lassen können, in einem Format, das unser eigener Tresor schluckt. Oder übergebt uns nach Zeitplan eine versiegelte, datierte Kopie, die wir öffnen und testen. „Es ist alles in unserem System und ihr könnt es haben, wenn ihr geht“ steht nicht auf der Liste, denn der Tag, an dem du gehst, ist der Tag, an dem sie den geringsten Grund haben, bei irgendetwas schnell zu sein.\nUnd frag, was danach mit diesen Passwörtern geschieht. Ein Zugangsdatum, das ihre Ingenieure vier Jahre lang kannten, wird nicht durch eine E-Mail sicher, die sagt, es sei weg. Jedes davon muss beim Ausscheiden gewechselt werden, von dir, auf Maschinen, für die du jetzt das Firmware-Passwort hältst.\nUnd dann die Live-Fassung von all dem. Wirst du benachrichtigt, wenn ein Passwort zu einem deiner Systeme gelesen wird?\nKein Protokoll, das sie führen und dir auf Nachfrage zeigen könnten. Eine Nachricht, die bei dir ankommt: welches Zugangsdatum, welcher Ingenieur, welches Ticket, und wann. Die Fähigkeit steht nirgends in Frage — jeder Tresor, der den Namen verdient, protokolliert eine Entnahme, und Microsofts eigene Hinterlegung tut es in deiner eigenen Mandantschaft, wo das Abrufen eines Passworts im Entra-Audit-Log als „Recover device local administrator password“ gegen das Konto geschrieben wird, das es getan hat. Die einzig echte Frage ist also, ob der Nachweis irgendwohin zeigt, wo du ihn sehen kannst.\nFrag, und wenn die Antwort nein lautet, frag warum nicht. Es gibt hier irgendwo ein ehrliches Nein — ein Alarm bei jeder Entnahme in einem großen Bestand würde vierzigmal am Tag losgehen und du würdest ihn ab Mittwoch nicht mehr lesen. Das hat eine Antwort, statt das Ende des Gesprächs zu sein. Alarmiert bei denen, die selten sein sollten: dem Domänenadministratorkonto, den Notfallzugangsdaten, den Firmware- und Bootloader-Passwörtern, den Wiederherstellungsschlüsseln. Und alarmiert bei jeder Entnahme ohne Ticketnummer daran, denn das ist entweder schlampige Aktenführung oder genau das, wovon du hören willst, und für keines von beidem ist es gut, es beim Quartalsgespräch zu erfahren.\nWas sie tun können, sobald sie drin sind Noch eines, und es ist das, was am häufigsten einen leeren Blick erntet. Wirst du benachrichtigt, wenn einer ihrer Ingenieure in deine Systeme geht?\nKein Protokoll, das sie führen. Eine Benachrichtigung, die du erhältst — wer hineinging, wann, wie lange, und gegen welches Ticket. Frag danach, und wenn die Antwort nein lautet, frag warum nicht.\nEs gibt einen Präzedenzfall, und er sitzt in den Produkten, die sie dir weiterverkaufen. Microsofts Customer Lockbox lässt einen Microsoft-Ingenieur deine ausdrückliche Zustimmung einholen, bevor er in einem Supportfall an deine Inhalte kommt. Google veröffentlicht Access-Transparency-Protokolle darüber, dass eigene Mitarbeiter deine Daten anfassen, und Access Approval lässt sie vorher fragen. Die größten Lieferanten der Erde haben also, mit weit engerem Zugriff als dein Dienstleister ihn hält, Freigabeabläufe und Zugriffsprotokolle für ihre eigenen Mitarbeiter gebaut und geben dir den Nachweis.\nDein MSP hat Domänenadministrator. Frag, was er dir gibt.\nUnd es gibt einen härteren Grund als Rechenschaft. Eine Benachrichtigung, die bei dir ankommt, ist das einzige unabhängige Zeichen, das du je bekommst, dass ihre Zugangsdaten von jemandem benutzt werden, der nicht sie ist. Wenn ein Angreifer über einen Service Desk hereinspaziert, sitzt jedes Protokoll, das es zeigen würde, in der Organisation, die gerade kompromittiert wurde. Eines, das in deinem Posteingang landet, sitzt außerhalb davon.\nEine Ebene tiefer, an der Maschine selbst. Kann sich das Fernwartungswerkzeug mit jemandes Arbeitsplatz verbinden, ohne dass diese Person zustimmt?\nBei einem Server um drei Uhr nachts ist unbeaufsichtigter Zugriff der ganze Sinn und niemand mit Verstand widerspricht. Bei einer Maschine, an der jemand sitzt, mit offener Mail und der Arbeit auf dem Bildschirm, ist es ein anderer Vorgang. Jedes ernsthafte Fernwartungsprodukt lässt sich so einstellen, dass es vor dem Verbinden fragt, dass es während einer laufenden Sitzung eine sichtbare Anzeige zeigt, und dass die Person ablehnen kann. Ob deines irgendetwas davon tut, ist eine Konfigurationseinstellung, und die Einstellung wurde von den Leuten gewählt, denen sie passt.\nFrag also drei Dinge, und halt sie getrennt. Können eure Ingenieure einen Mitarbeiter-Desktop ohne Nachfrage erreichen? Sieht die Person, die davor sitzt, überhaupt irgendetwas, während jemand verbunden ist? Kann sie ablehnen?\nWenn das Erste ja ist und die anderen beiden nein, ist das keine technische Einschränkung. Es ist eine Standardeinstellung, die niemand noch einmal angeschaut hat, in einem Produkt, das von der Partei gekauft wurde, der sie nützt. Es lohnt sich auch, das demjenigen vorzulegen, der in deiner Organisation für Datenschutz zuständig ist, denn jemandem ohne sein Wissen beim Arbeiten auf den Bildschirm zu schauen ist eine Entscheidung, die einen Namen daran haben sollte.\nDann die Frage, die entscheidet, ob irgendetwas davon hinterher beweisbar ist. Werden ihre Ingenieure aufgezeichnet, während sie an deinen Systemen arbeiten?\nSitzungsaufzeichnung ist nichts Exotisches und keine große Bitte. Sie ist ein Aushängeschild jedes Produkts für privilegierte Zugriffe auf dem Markt, was heißt, dass dein Dienstleister womöglich schon dafür zahlt und sie nie eingeschaltet hat. Eine aufgezeichnete Sitzung gibt dir ein Video, oder ein Tastenanschlag- und Befehlsprotokoll, oder beides, gebunden an einen benannten Ingenieur und eine Ticketnummer. So sieht Rechenschaft aus, wenn sie echt ist statt versprochen — keine Zusicherung, dass Ingenieure sich benehmen, sondern ein Nachweis, der es zeigen würde, wenn einer es nicht täte.\nFrag also, ob sie an ist, und frag dann, wie du an die Aufzeichnungen kommst, denn eine Aufzeichnung, die du nicht bekommen kannst, ist kein Beweis, sondern ein Gerücht. Es gibt drei Antworten, die etwas wert sind, in absteigender Reihenfolge. Die Aufzeichnungen landen in einem Speicher, der dir gehört, geschrieben während sie entstehen. Oder du hast heute Lesezugriff auf ihr System, mit einem Export, den du selbst laufen lassen kannst. Oder es gibt einen Anforderungsweg mit einer genannten Bearbeitungszeit — Stunden, schriftlich, im Vertrag — den du mindestens einmal an einer gewöhnlichen Sitzung getestet hast statt zum ersten Mal während eines Streits.\nWas du nicht willst, ist die verbreitete Regelung: Aufzeichnungen nur beim Dienstleister, Aufbewahrungsdauer vom Dienstleister gesetzt, Löschung im Belieben des Dienstleisters. Das ist eine Kontrolle, die perfekt funktioniert bis zu dem Tag, an dem sie gegen den Dienstleister gebraucht wird. Frag also, wer die Aufbewahrung verkürzen kann, wer eine löschen kann, und ob das Ansehen einer Aufzeichnung selbst protokolliert wird. Und frag, was mit allem an dem Tag passiert, an dem du gehst.\nSei fair gegenüber der anderen Seite davon, denn es gibt eine. Eine Aufzeichnung eines Ingenieurs, der einen Laptop repariert, ist auch eine Aufzeichnung dessen, was deine Mitarbeiter auf diesem Bildschirm hatten, und hin und wieder eines im Klartext getippten Zugangsdatums. Die Aufzeichnungen sind selbst sensibel und wollen dieselbe Handhabung wie der Tresor: verschlüsselt, zugriffskontrolliert, beim Ansehen protokolliert, für eine genannte Dauer aufbewahrt und nicht länger. Ein Dienstleister, der das anspricht, bevor du es ansprichst, hat über das Problem nachgedacht. Einer, der es nie bedacht hat, hat dir auch etwas gesagt.\nDasselbe Werkzeug bewegt fast sicher Dateien, in beide Richtungen. Frag, ob es das tut, und frag dann, was drumherum gebaut wurde.\nAusgehend ist das, was niemand bepreist. Eine Übertragung über den Verwaltungskanal ist verschlüsselt, vertraut und sitzt außerhalb jeder Kontrolle, die du schon bezahlt hast — der Data Loss Prevention, der Egress-Überwachung, der Richtlinie über USB-Sticks. Jeder mit Konsolenzugriff kann von allem auf jeder Maschine eine Kopie nehmen, und bei den meisten Installationen gibt es davon keinen Nachweis, den man dir je zeigen wird.\nEingehend ist, wie die Vorfälle weiter oben in diesem Beitrag tatsächlich passiert sind. Eine Datei auf jeden Endpunkt gleichzeitig zu schieben ist kein Fehler dieser Produkte, es ist das Aushängeschild. Ransomware hat es einfach so benutzt, wie es gebaut wurde.\nFrag also, ob Dateiübertragung überhaupt aktiviert ist, ob sie auf den Maschinen abgeschaltet werden kann, die sie nie brauchen, ob jede Übertragung mit Datei, Richtung, Maschine und Ingenieur protokolliert wird — und ob dieses Protokoll zu dir kommt oder zu den anderen in ihren Posteingang.\nUnd zuletzt dazu, denn das ist das, was überhaupt niemand zu fragen denkt. Was sammelt der Agent tatsächlich, und was passiert damit?\nDiese Werkzeuge sammeln erheblich mehr als einen Patch-Stand. Hardware- und Software-Inventar, Ereignisprotokolle, Leistungstelemetrie, oft Sitzungsaufzeichnungen und Bildschirmfotos, manchmal einiges mehr, je nachdem, was eingeschaltet ist. Das ist ein detailliertes Bild davon, wie dein Unternehmen arbeitet und was deine Mitarbeiter den ganzen Tag tun. Es verlässt dein Gelände fortlaufend.\nFrag also, was gesammelt wird, wo es gespeichert wird und unter wessen Rechtsordnung, wie lange es aufbewahrt wird und wer es sehen kann — denn die Antwort ist meistens der Dienstleister und der Hersteller des Werkzeugs, was eine zweite Firma ist, die du nie ausgesucht hast und mit der du keinen Vertrag hast. Frag, ob irgendetwas davon für etwas anderes als deine Betreuung verwendet wird: Produktanalytik, Benchmarking, Modelltraining. Frag, was mit alldem an dem Tag passiert, an dem der Vertrag endet, und lass es dir schriftlich statt in einem Gespräch geben.\nUnd beachte, wessen Daten es sind. Aufzeichnungen über deine Mitarbeiter und deine Systeme, gehalten von jemandem, der in deinem Auftrag verarbeitet, ist ein Satz mit Pflichten daran, und die sind deine und nicht seine.\nDer Chip, der antwortet, wenn die Maschine aus ist Es gibt unter alldem noch eine Schicht, und es lohnt sich, danach beim Namen zu fragen. Benutzen sie Intel vPro, oder die Active Management Technology darunter?\nFalls du dem noch nicht begegnet bist, die Kurzfassung: Verwaltungsfirmware läuft auf einem separaten Controller im Chipsatz, mit eigenem Netzwerkstapel. Sie antwortet, während die Maschine ausgeschaltet ist, sofern Netzstrom und ein Kabel da sind. Sie kann die Kiste einschalten, BIOS-Einstellungen ändern, ein entferntes Abbild einbinden und neu installieren, und in der richtigen Konfiguration Bildschirm und Tastatur auf Hardwareebene übernehmen — bevor das Betriebssystem geladen ist, und unabhängig davon, ob es das je tut.\nEs gibt echte Gründe, das zu wollen. Eine Maschine, die nicht bootet, eine BIOS-Einstellung an einem Gerät fünfhundert Kilometer entfernt, eine Neuinstallation, ohne jemanden hinauszuschicken. In einem großen, verteilten Bestand ist es nützlich und ich tue nicht so, als wäre es das nicht.\nAber schau, wo es sitzt. Unterhalb des Betriebssystems, was heißt unterhalb jeder Kontrolle, die du gekauft hast. Dein Endpunktschutz kann es nicht sehen, denn es läuft nicht im Betriebssystem. Deine Host-Firewall filtert es nicht, denn der Verkehr erreicht den Netzwerkstapel des Betriebssystems nie — er wird auf eigenen Ports behandelt, bevor irgendetwas anderes einen Blick daraufwirft. Deine Protokollierung deckt es nicht ab. Nichts, was du installiert hast, kann dir sagen, dass eine Sitzung stattgefunden hat.\nWo deine Kontrollen enden, und was darunter weiterläuft Eine Maschine, von oben nach unten Deine Anwendungen und deine Daten Das, was das Unternehmen wirklich benutzt Deine Kontrollen sehen es Endpunktschutz, Protokollierung, Host-Firewall Das ist der Teil, für den du zahlst Deine Kontrollen sind das Das Betriebssystem Alles darüber läuft darin Deine Kontrollen laufen hier Unter dieser Linie schaut nichts zu, was du installiert hast Firmware und BIOS Vom Hersteller aktualisiert, nach dessen Zeitplan Nicht in deinem Patchen Management-Engine, vPro oder ein BMC Eigener Prozessor, eigener Netzstapel, eigene Ports Antwortet bei ausgeschalteter Maschine Verwaltungsverkehr kommt hier an Alles, was du gekauft hast, läuft im Betriebssystem. Die zwei Schichten darunter nicht, und nichts, was oberhalb der Linie installiert ist, kann dir sagen, dass eine Sitzung stattgefunden hat. Die Sicherheitsbilanz ist auch nicht beruhigend. CVE-2017-5689 wurde mit 9,8 bewertet, und die Beschreibung lohnt langsames Lesen: „an unprivileged network attacker could gain system privileges to provisioned Intel manageability SKUs“. CISA gab eine Warnung heraus und CERT/CC einen Schwachstellenhinweis. Beachte das Wort „provisioned“ — im Ruhezustand ist es kein Weg hinein, eingeschaltet ist es einer. Und die Firmware, die es trägt, aktualisiert sich nicht über das normale Patchen, für das du zahlst. Sie kommt vom Hersteller der Maschine, nach dessen Zeitplan.\nDann ist da der Teil, der jeden beunruhigen sollte, der für Menschen statt für Server verantwortlich ist. Bildschirmkontrolle auf Hardwareebene heißt, dass jemand ein Display beobachten kann, während das Betriebssystem keine Ahnung davon hat. Frag, ob die Zustimmungsabfrage des Nutzers erzwungen wird und ob die sichtbare Sitzungsanzeige eingeschaltet ist, denn beides ist Konfiguration und beides kann von dem abgeschaltet werden, der es eingerichtet hat.\nDie Fragen sind also kurz. Ist es auf unseren Maschinen eingerichtet, und wer hat das getan, und wann — war es Teil eines Baus, den niemand erwähnt hat? Welche konkreten Aufgaben brauchen es, und wie viele Maschinen brauchen diese Aufgaben tatsächlich? Welches Netz erreicht die Verwaltungsports, und ist das von allem anderen abgetrennt? Wird Zustimmung erzwungen, ist die Anzeige an, und wo ist die Prüfspur? Und kann es auf jeder Maschine, die es nicht braucht, wieder ausgeschaltet werden?\nWenn die Antwort auf die erste „wir wissen es nicht“ lautet, ist das für sich wissenswert, denn es heißt, die Fähigkeit sitzt da, von jemandem eingerichtet und von niemandem beobachtet.\nDas Risiko kam gratis mit Dreh diesen ganzen Teil auf den Kopf und er sagt eines. Jede Fähigkeit darin kam als Bequemlichkeit an und wurde als eine bepreist. Der Agent, der tausend Maschinen patcht, ist das, was eine Datei auf tausend Maschinen legen kann. Der Chip, der eine Fahrt über dreihundert Kilometer spart, antwortet, wenn die Maschine aus ist, und sagt deiner Protokollierung nichts. Die Bequemlichkeit wurde angeboten, aufgeschlüsselt und abgezeichnet. Die Fähigkeit kam in derselben Kiste mit, unbepreist. Sie taucht auf keinem Dokument auf, das man dir je gezeigt hat.\nNichts davon ist ein Argument dafür, ganz darauf zu verzichten. Bestände müssen gepatcht werden, und jemand muss an eine tote Maschine kommen können. Es ist ein Argument dafür, zu wissen, was im Gebäude ist, wer es erreichen kann, von wo, und was nötig wäre, damit die Person mit dieser Reichweite jemand anderes ist als die Firma, die sie gerade hält. Eine Rechnung wird es dir nie sagen, denn eine Rechnung ist eine Liste dessen, wofür du zahlst. Sie ist keine Liste dessen, wem du ausgesetzt bist. Niemand in diesem Arrangement ist je gebeten worden, die zweite zu erstellen.\nTeil drei handelt davon, was passiert, wenn eines davon losgeht. Was der Vertrag tatsächlich verspricht, wer am Ende den Schaden trägt, wie die Ausreden klingen, und was es kostet zu gehen, wenn du endgültig genug hast.\nIs Your MSP Lying To You — 3 parts\nBelügt dich dein MSP, um dir Premium-Produkte zu verkaufen? Was dein MSP dir gebaut hat, und wer sonst noch drankommtyou are here Wenn es kaputtgeht, wer trägt es dann wirklich? Quellen Abgerufen am 28. August 2026.\nWeiterbildung und Qualifikation.\nNational Vulnerability Database — CVE-Veröffentlichungszahlen nach Jahr, quartalsweise summiert: 6.595 im Jahr 2015 gegen 49.972 im Jahr 2025. Die Geräte.\nCVE-2018-0141 — fest einprogrammiertes Kontopasswort, Cisco Prime Collaboration Provisioning, März 2018. CVE-2018-15439 — Small Business Switches, ein privilegiertes Konto aktiviert, ohne Administratoren zu benachrichtigen, November 2018. CVE-2023-20101 — Cisco Emergency Responder, statische Root-Zugangsdaten, die nicht geändert oder gelöscht werden können, Oktober 2023. Der Spiegel, 29. Dezember 2013 — der ANT-Katalog, der unter anderem Cisco und Huawei nennt, aus den Snowden-Dokumenten. Der Spiegel, 29. Dezember 2013 — Einblick in TAO: Interdiction, Load Stations, und was mit einer umgeleiteten Sendung passiert. Ars Technica, 14. Mai 2014 — der interne NSA-Newsletter von 2010 und Fotos eines Cisco-Routers, der ein Implantat bekommt, veröffentlicht in Glenn Greenwalds No Place to Hide. Cisco, 13. Mai 2014 — die Antwort des Unternehmens, in seinen eigenen Worten. Generalstaatsanwaltschaft New York, 2019 — der Vergleich mehrerer Bundesstaaten über an Behörden verkaufte Videoüberwachungssoftware und die Zeitleiste 2009 bis 2013. Die Perimeter-Technik.\nCISA Known Exploited Vulnerabilities Catalogue — Version 2026.08.27, 1.685 Einträge; die Zahlen je Hersteller in diesem Beitrag sind meine eigene Auszählung dieser Datei. CVE-2024-3400, CVE-2024-0012 — PAN-OS, GlobalProtect und die Verwaltungsweboberfläche. CVE-2022-40684, CVE-2018-13379 — FortiOS-Authentifizierungsumgehung und SSL-VPN-Path-Traversal. CVE-2023-20198, CVE-2025-20333, CVE-2026-20316 — Cisco IOS XE Weboberfläche, der ASA-VPN-Webserver, und ein fest einprogrammiertes Passwort im Secure Firewall Management Center. CISA, Implementing Phishing-Resistant MFA — die Rangfolge der MFA-Formen, von stärkster zu schwächster. KrebsOnSecurity, Juli 2018 — Google zu über 85.000 Beschäftigten und keinem erfolgreichen Phishing nach verpflichtenden physischen Sicherheitsschlüsseln. Gemeinsame Warnung AA23-320A — Scattered Spider und sein Zielen auf beauftragte IT-Help-Desks. Windows-LAPS-Überblick — ein anderes lokales Administratorpasswort je Maschine, gewechselt und in dein eigenes Active Directory oder deine Entra-Mandantschaft gesichert; kostenlos in jeder unterstützten Windows-Version. Wenn es schiefgeht.\nICO, März 2025 — Advanced Computer Software Group mit 3,07 Millionen Pfund Bußgeld belegt, das erste Bußgeld der Aufsicht gegen einen Auftragsverarbeiter. Die Vollstreckungsseite trägt die Einzelheiten. ICO, Oktober 2025 — Capita mit 14 Millionen Pfund Bußgeld wegen der Datenpanne von 2023 belegt: der Zehn-Minuten-Alarm, die 58-Stunden-Reaktion gegen ein Ziel von einer Stunde, und das unterbesetzte Security Operations Centre. Law Society Gazette, 28. November 2023 — rund 80 Kanzleien für Immobilienübertragung konnten keine Transaktionen abschließen, nachdem ihr IT-Dienstleister ausfiel. CISA und das FBI zum Kaseya-VSA-Angriff, Juli 2021 — Ransomware gegen Managed Service Provider und ihre nachgelagerten Kunden. Gemeinsame Warnung AA23-025A, 25. Januar 2023 — CISA, die NSA und das MS-ISAC zum bösartigen Einsatz legitimer RMM-Software. CVE-2024-1709 — ConnectWise-ScreenConnect-Authentifizierungsumgehung, CVSS 10,0, Februar 2024. CISA-Warnung AA25-163A, Juni 2025 und CVE-2024-57727 — Ransomware-Akteure erreichen nachgelagerte Kunden über ungepatchtes SimpleHelp RMM. Gemeinsame Warnung AA22-131A, 11. Mai 2022 — die britischen, australischen, kanadischen, neuseeländischen und US-Behörden zu Bedrohungen für Managed Service Provider und ihre Kunden. ","permalink":"https://blogs.damiendye.uk/de/random/is-your-msp-lying-to-you-part2/","summary":"Teil 2 von 3. Was tatsächlich gebaut wird, sobald die Papiere unterschrieben sind: Cloud für ein Unternehmen mit einem Gebäude, die Kiste, von der sie sich nicht abbringen lassen, die Grundlagen, die das waren, was du gekauft hast, und der Agent auf jeder Maschine, der der Konsole von jemand anderem antwortet.","title":"Was dein MSP dir gebaut hat, und wer sonst noch drankommt"},{"content":" Is Your MSP Lying To You — 3 parts\nBelügt dich dein MSP, um dir Premium-Produkte zu verkaufen? Was dein MSP dir gebaut hat, und wer sonst noch drankommt Wenn es kaputtgeht, wer trägt es dann wirklich?you are here In Teil eins ging es darum, wie die Auswahlliste geschrieben wird. In Teil zwei darum, was daraufhin gebaut wurde. In diesem Teil geht es um den Morgen, an dem es aufhört zu funktionieren, und um alles, was daraus folgt.\nWer vertraglich haftet, und für wie viel. Was im Raum gesagt wird, wenn die Antwort niemand lautet. Was ein Dienstleister, den man behalten sollte, stattdessen tut. Und was es braucht, einen zu verlassen, der es nicht ist, was sich als der Teil herausstellt, den niemand plant, bis er ihn in dieser Woche braucht.\nWas hat der Aufpreis eigentlich gekauft Die Belege stehen in Teil zwei und ich führe dich da nicht noch einmal durch. Nimm als gegeben, dass die teure Option keine Kompetenz gekauft hat, die Grundlagen nicht fertiggestellt hat und dir keine Kiste verschafft hat, in die einzubrechen irgendwie schwerer wäre.\nWoran hängt also das Geld?\nNicht am Silizium, das jedes Jahr billiger wird. Nicht an den Adressen. Nicht an den Ingenieursstunden, in einer Branche, die ihre Weiterbildungsausgaben in zwei Jahren um fast ein Drittel gekürzt hat. Der Aufpreis hängt am Channel — an einem Hersteller, der groß genug ist, Stufen, Rabatte, Deal Registration und ein Distributorennetz zu betreiben, was eine Schlange von Leuten heißt, die alle bezahlt werden, bevor irgendetwas gebaut wird, und jeder von ihnen auf deiner Rechnung.\nDas ist die Hälfte des Verkäufers, und für sich erklärt sie nicht viel. Reichlich Käufer sind vollkommen fähig und unterschreiben trotzdem. Hier ist also die andere Hälfte, und sie ist die unbequemere.\nDer Aufpreis kauft Deckung. Nicht für die Firma. Für die Person, die unterschreibt.\nDas bekannte Logo einzusetzen ist auf eine Art vertretbar, wie das offene zu wählen es nie ist. Wenn die marktführende Firewall kompromittiert wird, wurden es alle anderen auch, und du hattest Pech. Wenn das Ding kompromittiert wird, das du selbst zusammengebaut hast, hast du es gewählt, und man wird dich fragen warum. Das Ergebnis für das Unternehmen ist dasselbe. Die Folge für die Einzelperson nicht, und jeder Einkäufer oberhalb einer bestimmten Ebene versteht das, ohne dass es jemand laut sagen müsste.\nAls solches schließt sich der Ring. Der Verkäufer wird mehr dafür bezahlt, die teure Option zu empfehlen. Der Käufer ist persönlich sicherer, wenn er sie annimmt. Keiner von beiden handelt zu irgendeinem Zeitpunkt gegen seine eigenen Interessen — und die einzige Partei, die die Kosten dieses Arrangements trägt, ist das Unternehmen, für das beide arbeiten.\nDas ist die Antwort auf die Frage, mit der diese Reihe anfing, und sie ist schlimmer als Lügen. Ein Lügner weiß, was die Wahrheit ist. Dieses Arrangement braucht niemanden, der es weiß. Es braucht nur, dass die Auswahlliste immer wieder gleich herauskommt, und das tut sie.\nDie Berichte, die du nie bekommst Jeder wiederkehrende Posten auf der Rechnung eines Managed Service sollte ein Dokument hervorbringen. Die meisten bringen nichts hervor, und fast niemand fragt.\nNimm das Patchen der Infrastruktur, den Posten über dem für die Arbeitsplätze. Der ehrliche Weg, eine Flotte zu aktualisieren, ist ein Playbook — Ansible oder was auch immer — an einem Ort, den du sehen kannst, nach Zeitplan ausgeführt, mit hinterlassener Ausgabe. Verlang also, das Playbook zu sehen, und verlang, das Ausführungsprotokoll zu sehen. Bei sehr vielen Verträgen gibt es weder noch. Die Updates sind manuell, wenn sie stattfinden, sie finden statt, wenn sich jemand erinnert, und der Posten wird so oder so jeden Monat berechnet. Was dir als Automatisierung verkauft wurde, ist eine Notiz im Kalender.\nWas jeder Posten auf der Rechnung hervorbringen sollte AUF DER RECHNUNG DAS DOKUMENT ALS NACHWEIS WAS ÜBLICH ANKOMMT Patchen Das Playbook und sein Ausführungsprotokoll dort, wo du es lesen kannst, nach Zeitplan gefahren Ein Erfüllungsprozentsatz Backup Ein Rücksicherungstest, datiert was zurückkam, worauf, wie lange, wer es prüfte Ein Bericht voller grüner Haken Monitoring Die Alarme, auch an dich geschickt direkt aus dem System, nach Zeitplan, unbearbeitet Ein Dashboard, monatlich kuratiert Dokumentation Einträge in deinen eigenen Systemen dein IPAM, deine Inventardatenbank, dein Wiki Ein Export, nach ihrem Zeitplan Ein Backup, das nie jemand zurückgespielt hat, ist kein Backup. Es ist eine Hypothese über ein Backup. Verlang den jüngsten Rücksicherungstest. Die Antwort, oder die Pause davor, ist die ganze Überprüfung. Jeder wiederkehrende Posten sollte ein Dokument hinterlassen. Die meisten hinterlassen einen Prozentsatz, einen grünen Haken oder gar nichts. Dann die Backups. Das ist das Schlimmste davon, denn es ist der Posten, an den Leute am meisten glauben.\nDu bekommst einen Backup-Bericht. Grüne Haken, abgeschlossene Jobs, geschriebene Bytes, alles wöchentlich eingehend und nichts davon gelesen. Dieser Bericht ist nicht der, auf den es ankommt. Ein Backup, das nie jemand zurückgespielt hat, ist kein Backup. Es ist eine Hypothese über ein Backup.\nDas Dokument, das du willst, ist ein Rücksicherungstest. Was wurde zurückgespielt, auf welche Hardware, wie lange hat es von Anfang bis Ende gedauert, und wer hat die Daten danach geöffnet und bestätigt, dass es die Daten waren. Verlang den jüngsten.\nDann frag dasselbe noch einmal für die Offline-Kopie, denn das ist eine eigene Behauptung und sie braucht einen eigenen Beleg. Alle sagen, sie hätten eine. Verlang, sie zu sehen — das Medium, wo es liegt, das letzte Schreibdatum, wer die Zugangsdaten hat — und frag, wann zuletzt aus dieser Kopie zurückgespielt wurde statt aus dem laufenden Backup-System. Das sind verschiedene Medien in verschiedenen Formaten, und das eine zu testen beweist überhaupt nichts über das andere. Die Offline-Kopie ist die, die eine schlechte Woche überlebt, und sie ist die, aus der am wenigsten wahrscheinlich je zurückgelesen wurde. Frag, wie oft das gemacht wird, und gegen welche Systeme, und ob jemand von deiner Seite je das Ergebnis gesehen hat. Bei vielen Verträgen ist es nie gemacht worden, denn es kostet einen Tag von jemandes Zeit und niemand rechnet den ab.\nEs gibt zu all dem eine vorgelagerte Frage, und sie entscheidet, ob irgendetwas vom Rest etwas bedeutet. Kommen diese Berichte zu dir, oder nur zu ihnen?\nMeistens erzeugen die Werkzeuge sie, sie landen im Posteingang des Dienstleisters, jemand liest sie, wenn Zeit ist, und dir wird Bescheid gesagt, wenn es ein Problem gibt. Das ist keine Rechenschaft. Es ist Selbstbewertung mit einer Rechnung daran, und es verlangt, dass du ihnen genau bei dem glaubst, wofür du sie bezahlst.\nVerlang also, dass die Berichte auch zu dir kommen. Direkt aus dem System, nach Zeitplan, in welcher Form das Werkzeug sie ausspuckt — keine Folie, zusammengestellt von der Person, die gemessen wird, und kein grünes Dashboard, für die Monatsbesprechung kuratiert. Backup-Erfolge und, wichtiger, -Fehlschläge. Der Patch-Lauf und was er ausgelassen hat. Alarmmengen und Reaktionszeiten gegen das Ziel. Der Rücksicherungstest, wenn er stattfindet, und die Ausnahmeliste, wie sie steht.\nDu musst nicht jeden lesen. Du musst es können, und sie müssen wissen, dass du es kannst. Das ist der ganze Mechanismus, und es ist der Unterschied zwischen jemandem vertrauen und in der Lage sein, nachzuprüfen.\nUnd wenn sich das als schwierig herausstellt, frag warum. Jeder Bericht auf dieser Liste existiert schon und wird schon irgendwohin geschickt. Einen zweiten Empfänger hinzuzufügen ist eine Zeile in einer Verteilerliste, kein Projekt. Zögern ist hier kein technisches Problem, und es ist mehr wert als die Antwort es gewesen wäre.\nEs gibt eine größere Fassung derselben Frage, und sie entscheidet, ob du je irgendetwas selbst nachprüfen kannst. Wo lebt die Dokumentation?\nFrag, ob sie deinen Bestand in deinen Systemen erfassen — deinem IPAM, deiner Inventardatenbank, deinem Wiki — oder in ihren. Die meisten sagen ihren, und es wird als Effizienz dargestellt. Ihre Werkzeuge, ihre Vorlagen, ihr Prozess, nichts für dich zu betreiben.\nSchau, was dieses Arrangement bewirkt. Der Adressierungsplan, das Netzdiagramm, das Inventar, die Runbooks und die Lizenzschlüssel sind alles Aufzeichnungen über dein Unternehmen, mit deinem Geld erstellt, über Geräte, die dir gehören. Gehalten an einem Ort, an dem du sie nicht sehen kannst. Du kannst nicht auditieren, was du nicht lesen kannst, du hast also keine Möglichkeit zu wissen, ob die Dokumentation zum Bestand passt — und Dokumentation driftet ständig von der Wirklichkeit weg, was normal und verzeihlich ist, aber unsichtbare Drift ist die Art, wie du es während eines Vorfalls erfährst statt während einer Überprüfung.\nDann ist da, was am Ende passiert, worauf der Abschnitt übers Gehen zurückkommt. Dokumentation in deinen eigenen Systemen ist schon deine, schon aktuell, schon in einem Format, das du benutzt. Dokumentation in ihren ist ein Export, nach ihrem Zeitplan, in welcher Form ihr Werkzeug ihn anbietet, üblicherweise ein PDF von etwas, das eine Datenbank war.\nStell die Frage also klar, und verlang Lesezugriff heute statt im Grundsatz. Ein Dienstleister, der in deinen Systemen arbeitet, hat eine Entscheidung getroffen, die ihn wenig kostet und dir viel gibt, und er wird es dir sagen. Einer, der darauf besteht, das Bild in seinen eigenen Werkzeugen zu behalten, hat die gegenteilige Entscheidung getroffen, und es lohnt sich zu fragen, welchen Teil davon er attraktiv fand.\nDiese Lücke ist nicht akademisch. Jeder Vorfall in Teil zwei landet darauf. Die Kaseya-Kunden, die achtzig Immobilienkanzleien, die Pensionskassen hinter Capita — für jeden von ihnen war die einzige Frage, auf die es an dem Tag ankam, ob die Rücksicherung funktionierte. Das ist der Moment, in dem ein Bericht, nach dem niemand gefragt hat, zum einzigen Dokument im Gebäude wird, das etwas wert ist.\nWenn dein Dienstleister keinen Rücksicherungstest vorlegen kann, kaufst du kein Backup. Du kaufst Kopieren, und du findest an dem schlimmsten Morgen des Jahres heraus, was von beidem es war.\nNiemand haftet Sich einen Ort zu kaufen, an dem man die Schuld ablegt, verdient mehr als den Satz, den es in Teil eins bekommen hat, denn Rechenschaft ist das, worum dieses ganze Arrangement herumgebaut ist. Nicht moralisch. Vertraglich.\nFang mit dem Service Level Agreement an und lies, was es tatsächlich verspricht. Fast immer ist es eine Reaktionszeit. Vier Stunden bis zur Bestätigung, acht bis zum Erscheinen, so etwas in der Art. Zu reagieren liegt vollständig in ihrer Kontrolle, es kann also gefahrlos versprochen werden. Zu reparieren nicht, also wird es nicht versprochen. Such nach einer Zeile, die sie auf ein Ergebnis festlegt — der Dienst funktioniert, die Daten kommen zurück, der Standort verkauft — und bei den meisten Verträgen gibt es nirgends eine.\nDann finde die Haftungsobergrenze. Sie ist da, und sie liegt üblicherweise bei den Gebühren, die du in den vorangegangenen zwölf Monaten gezahlt hast, manchmal darunter. Das Schlimmste, was ihnen passieren kann, ist also, dir zurückzuzahlen, was du ihnen schon gegeben hast. Das Schlimmste, was dir passieren kann, ist das Unternehmen. Diese zwei Zahlen sind nicht im selben Universum, und die Lücke dazwischen ist die tatsächliche Risikolage, in der du bist.\nWas die Vereinbarung verspricht, und was jede Seite verlieren kann Worauf die Vereinbarung sie tatsächlich festlegt Den Fehler binnen vier Stunden bestätigen Versprochen Binnen acht Stunden erscheinen Versprochen Der Dienst läuft wieder, die Daten kommen zurück, der Standort verkauft Nicht versprochen Und was jede Seite am schlimmsten Tag verliert Sie gedeckelt auf etwa zwölf Monate der Gebühren, die du schon gezahlt hast Du die Bestellungen, die Löhne, die Kunden, das Unternehmen Reagieren liegt in ihrer Kontrolle, also wird es versprochen. Reparieren nicht, also nicht. Die zwei Balken sind derselbe Vertrag, von jedem Ende aus gesehen. Der Weiterverkauf schiebt den Rest stromaufwärts. Wenn der Hyperscaler ausfällt, ist es die Schuld des Hyperscalers. Wenn die Firewall eine Zehn ausliefert, ist es die Schuld des Herstellers. Wenn ein trojanisiertes Installationsprogramm signiert und als gewöhnliches Update ausgeliefert ankommt, ist das ebenfalls der Hersteller. Jedes davon ist wahr, und keines nützt dir etwas, denn du hattest nie eine Beziehung zu einer dieser Firmen. Du hattest eine mit dem Laden, der sie in deinem Namen ausgewählt und dafür einen Rabatt genommen hat.\nUnd unter alldem sitzt der leiseste Mechanismus von allen. Du kannst eine Anforderung nicht verfehlen, die nie aufgeschrieben wurde. Das Anforderungsdokument, das in Teil eins niemand geschrieben hat, ist nicht nur Schlamperei — es ist Schutz. Keine erfasste Anforderung, kein messbares Versprechen. Kein messbares Versprechen, kein Verstoß. Von einem Entwurf, den niemand abgezeichnet hat, kann nicht abgewichen werden.\nSchau, was passierte, als Rechenschaft endlich irgendwo ankam. Capita bekam 14 Millionen Pfund Bußgeld, und es kam vom Information Commissioner nach Datenschutzrecht, wegen eines Alarms, den achtundfünfzig Stunden lang niemand bearbeitet hat. Nicht von einem Kunden, und nicht nach einem Dienstleistungsvertrag. Das Geld ging an den Staat. Die 6,6 Millionen Menschen, deren Daten aus der Tür gingen, und die 325 Pensionskassen, die die Folgen tragen, waren nicht die, die es angestrengt haben, und nicht die, die bezahlt wurden.\nDas Arrangement also, von Anfang bis Ende. Der Hersteller verkauft ein Produkt unter einer Lizenz, die die Eignung für irgendetwas Bestimmtes ausschließt. Der Dienstleister verkauft Stunden gegen eine gedeckelte Haftung und ein Reaktionszeitversprechen. Der Versicherer bepreist, was übrig ist. Und der Schaden setzt sich bei dem Unternehmen ab, das nicht ausweichen kann, der einzigen Partei in der Kette, die nie irgendetwas ausschließen durfte.\nJeder in der Kette schließt seinen Teil aus, und alles landet an einem Ort Jede Schicht reicht die Folge nach unten und behält ihre Marge Der Hersteller Lizenz schließt Eignung für alles aus Der Distributor Bewegt das Produkt, nimmt einen Schnitt Der Dienstleister Stunden verkauft gegen gedeckelte Haftung Der Versicherer Bepreist, was übrig bleibt Das Unternehmen, das am Montag die Türen aufmachen muss Stellt etwas her, beschäftigt Leute, kann nicht schnell ausweichen und ist die einzige Partei in der Kette, die nichts ausschließen kann Jede Schicht darüber ist rechtlich aus dem Schneider. Der Schaden muss trotzdem irgendwo sitzen. Jede Schicht ist rechtlich aus dem Schneider, und jede wird bezahlt, bevor irgendetwas gebaut wird. Die Folge wandert weiter, bis sie jemanden erreicht, der sie nicht weitergeben kann. In alldem steckt ein einfacherer Test, und er braucht keinen Anwalt.\nWenn ein Laden an das glaubt, was er empfohlen hat, sollte er bereit sein, dahinterzustehen. Das ist, was eine Empfehlung ist. Du hast nicht die Kiste gekauft — jeder mit einer Website kann dir eine Kiste verkaufen. Du hast jemandes Urteil gekauft, dass dies die richtige Kiste für dich ist, und dafür wurde er bezahlt, und noch einmal bezahlt von dem Hersteller, dessen Kiste es dann war.\nWenn es also versagt und die Antwort zurückkommt, der Hersteller habe alle im Stich gelassen, schau, was gerade passiert ist. Der Teil, den du tatsächlich gekauft hast, ist ausgeschlossen worden. Das Urteil verdampft in genau dem Moment, in dem es geprüft wird, und übrig bleibt ein Laden, der ein Produkt durchgereicht und unterwegs eine Marge genommen hat.\nNiemand verlangt von einem MSP, für Microsoft zu haften. Aber zwischen für einen Hyperscaler haften und hinter dem eigenen Rat stehen liegt eine weite Lücke, und jedes andere Handwerk lebt irgendwo darin. Ein Elektriker, der einen Verteilerkasten einbaut, darf nicht den Hersteller dafür verantwortlich machen, dass er ihn ausgewählt hat. Ein Statiker, der einen Träger vorgibt, besitzt die Vorgabe. Sie tragen ihr Urteil, denn das Urteil war die Leistung.\nFrag also, was dein Dienstleister zu tragen bereit ist. Nicht das Produkt des Herstellers — seine eigene Empfehlung. Die Antwort, oder die Länge der Pause davor, sagt dir, was er insgeheim davon hält.\nUnd dann ist es deine Schuld Der Vertrag ist die leise Hälfte davon. Die laute Hälfte taucht an dem Tag auf, an dem tatsächlich etwas kaputtgeht, und sie ist vor der Lösung da.\nSchau, in welche Richtung die Verantwortung wandert. Nach außen, in jede verfügbare Richtung, und ungefähr in dieser Reihenfolge. Der Hersteller hat einen schlechten Patch ausgeliefert. Die Leitung war die des Netzbetreibers. Es ist ein bekanntes Problem und alle sehen es. Niemand hätte es vorhersehen können, gesagt über eine Schwachstelle, die lange genug auf der Liste der ausgenutzten stand, um sich einen Bart wachsen zu lassen. Der vorherige Dienstleister hat es so hinterlassen, was sechs Monate lang eine faire Antwort ist und im dritten Jahr immer noch gegeben wird. Dann gehen die äußeren Richtungen aus, und eine bleibt. Du hast das Upgrade nie freigegeben. Das war außerhalb des Umfangs, deine Mitarbeiter haben auf den Link geklickt, und du hast nie ein Ticket aufgemacht.\nHier ist der unbequeme Teil. Manches davon stimmt. Ein Kunde, der drei Jahre in Folge denselben Austausch abgelehnt hat, besitzt diese Entscheidung, und ein Dienstleister, der das sagt, ist ehrlich zu dir. Die Frage ist also nicht, ob die Ausrede zutrifft. Sie ist, wann sie zum ersten Mal gesagt wurde. Ein Risiko, das dir vor dem Ausfall schriftlich vorgelegt wurde, mit dem, was es zu beheben kostet, und dem, was es kostet, es nicht zu tun, ist ein Dienstleister, der deinen Bestand verwaltet. Derselbe Satz, in der Woche danach geschickt, ist eine Verteidigung im Aufbau. Dieselben Worte, anderes Datum, entgegengesetzte Bedeutung.\n„Du hast nie ein Ticket aufgemacht“ ist die, bei der es sich zu verweilen lohnt, denn es ist überhaupt keine Ausrede. Es ist das laut ausgesprochene Betriebsmodell. Nichts ist irgendjemandes Aufgabe, bis du es bemerkst, was dich zur Überwachung macht, und du zahlst eine Monatsgebühr an einen Laden, dessen Erkennungsschicht ein anrufender Kunde ist. Sobald du diese Antwort einmal gehört hast, weißt du, was die Leistung ist.\nEs gibt davon eine aktivere Fassung, und sie funktioniert weit besser, als sie sollte. Du berufst eine Besprechung ein, um zu fragen, warum die letzten sechs Monate so gelaufen sind, wie sie gelaufen sind, und die Tagesordnung, die zurückkommt, handelt von etwas ganz anderem: einer dringenden Sicherheitssache, einer Lizenzfrist, die niemand erwähnt hatte, einer End-of-Life-Meldung zu einer Kiste, die seit zwei Jahren End of Life ist und plötzlich in diesen zwei Wochen dringend geworden ist. Es wird mit echter Sorge und einem beigefügten Angebot vorgetragen, und es frisst die Stunde. Du gehst hinaus, nachdem du zugestimmt hast, Geld auszugeben, und das, wofür du die Besprechung einberufen hast, wurde überhaupt nie ausgesprochen.\nBeachte, was die hergestellte Krise immer gemeinsam hat. Sie braucht einen Kauf, sie braucht ihn in diesem Quartal, und sie verlangt von niemandem im Raum, irgendetwas zuzugeben. Echte Dringlichkeit sieht anders aus, denn sie kommt mit einer Kennung, einem Veröffentlichungsdatum, den konkreten Maschinen in deinem Bestand, die es betrifft, und dem, was sie bereits getan haben, während sie darauf warteten, es dir zu sagen. Die erfundene Sorte kommt als Herstellerfrist und gerundete Zahl an. Frag, wann sie zum ersten Mal auf ihrem Radar auftauchte. Wenn die Antwort dieselbe Woche ist, in der du angefangen hast, unangenehme Fragen zu stellen, ist das kein Zufall und war nie als einer gemeint.\nFühr also deine eigene Akte, und fang damit an, bevor du sie brauchst. Jedes Mal, wenn dir gesagt wird, eine Sache sei in Ordnung, verlang das per E-Mail. Jedes Mal, wenn du etwas ablehnst, schreib auf, was dir gezeigt wurde und was es angeboten war. Es dauert eine Minute und es heißt, dass du an dem Tag, an dem es deine Schuld wird, nach dem Datum fragen kannst, und die Antwort existiert oder sie existiert nicht. Ein Laden, der diese Arbeit ordentlich macht, ist ohnehin zuerst da. Er beginnt mit: das haben wir übersehen, hier ist, was wir ändern, und sagt es, bevor du zu Ende gefragt hast. Es kostet ihn einen Satz, was genau der Grund ist, warum so wenige ihn ausgeben.\nUnd wenn du die erfundene Krise bekommst, oder die Schuld für etwas bei dir landet, was dir nie jemand vorgelegt hat, sag es im Raum. Nicht als Beschwerde hinterher und nicht als Notiz für die Akte. Frag sie, ob sie das für professionell halten, ob es die Antwort ist, die sie akzeptieren würden, wenn man sie ihnen gäbe, und wo darin die Integrität steckt. Jemandem wird unbehaglich, und das ist der ganze Zweck des Fragens. Ein Laden, der noch Selbstachtung hat, nimmt es hin, sagt: berechtigt, und kommt nächsten Monat anders zurück. Du weißt binnen einer Minute, welche Sorte dir gegenübersitzt.\nDann fang trotzdem an zu suchen. In dieser Woche. Eine schlechte Besprechung entscheidet es nicht, aber das Ablenken war nie ein schlechter Tag. Es war eine Entscheidung über dich: dass es billiger ist, zu verwalten, wie du dich fühlst, als zu reparieren, was du gekauft hast, und dass du es hinnehmen wirst. Läden machen diese Rechnung nicht rückgängig, weil ein Kunde ein Gesicht gezogen hat. Einen Dienstleister ordentlich zu ersetzen dauert Monate, die du noch gar nicht angefangen hast zu verbringen, und der Zeitpunkt dafür ist, solange du noch ruhig genug bist, gut zu wählen, statt in den zwei Wochen nach dem Ausfall, der dich endgültig entscheidet.\nStell diese in der nächsten Besprechung Nichts davon kostet dich owt, und du musst kein Ingenieur sein, um irgendetwas davon zu fragen.\nIch habe die Fragen in eine Tabelle gepackt statt auf die Seite — 120 davon über fünfzehn Bereiche, jede mit dem, wie eine kompetente Antwort klingt, gegen das, wie eine Ausweichantwort klingt, und einer Spalte zum Festhalten, welche du bekommen hast.\n\u0026#8615; Lieferantenfragen, die lange Fassung msp-supplier-questions.xlsx · 26 kB Behandle es als Stichwortliste, nicht als Skript. Lies es durch, markier das Dutzend, das deinen Vertrag tatsächlich betrifft, und stell die. Niemand sitzt hundert Fragen in einer Stunde durch und du würdest weniger erfahren, wenn man es versuchte. Schick es vor der Besprechung hinüber, statt es in einer aus dem Hut zu ziehen — ein Dienstleister, der die Arbeit ordentlich macht, ist über die Vorwarnung froh, und wie er die Vorwarnung aufnimmt, ist selbst eine Antwort.\nEine Frage darin fragt, welche ihrer Empfehlungen ihnen einen Rabatt, eine Gutschrift, eine Marge oder ein Ziel beim Hersteller einbringen. Das ist die, die die Temperatur in einem Raum ändert, und das sollte sie nicht. Ein Dienstleister, der nichts zu verbergen hat, antwortet gerade heraus, denn er hätte dasselbe ohnehin empfohlen und hätte lieber, dass du es weißt. Beobachte, was passiert, wenn du fragst. Die Antwort zählt weniger als die Reaktion.\nEin Dienstleister, der die Arbeit ordentlich macht, hat all das parat. Schon, heute, ohne Vorbereitung. Die aufgeschriebenen Anforderungen, die bepreisten Optionen, die Open-Source-Zeile im Vergleich, der dual-gestackte Adressplan, das gepatchte Fernwartungswerkzeug und die Risiken im Register, wo sie hingehören. Frag, und du findest in einer einzigen Besprechung heraus, welche Sorte du bezahlst.\nUnd wenn es das Fragen selbst ist, was sie verärgert, hast du alles herausgefunden, was du brauchtest.\nJedes Konto wird still All das setzt voraus, dass du gehen kannst, wenn du musst. Es lohnt sich, das zu prüfen, bevor du es musst, denn beim Gehen hört ein Managed-Service-Vertrag auf, von Technik zu handeln.\nNimm an, dass du es irgendwann brauchen wirst. Jede dieser Vereinbarungen driftet gleich, bei wem auch immer du unterschreibst. Die Aufmerksamkeit, die du bekamst, während sie den Auftrag gewannen, dünnt aus, sobald der Dauerauftrag läuft, und du sackst in ihren Büchern zu einer Monatszahl ab statt zu einem Bestand, über den jemand nachdenkt. Niemand setzt sich hin und beschließt aufzuhören, sich zu kümmern. Der beste Ingenieur geht dorthin, wo Lärm ist, die Überprüfungen finden still und leise nicht mehr statt, und deine Geräte sitzen auf dem, was in dem Jahr, in dem du unterschrieben hast, die richtige Antwort war, während der Rest des Gewerbes ohne dich weiterzieht.\nVersteh, was ein stilles Konto tatsächlich ist, denn der Ausdruck klingt wie ein Kompliment und ist keines. Ein stilles Konto ist eines, das niemand geprüft hat. Die Backups laufen jede Nacht grün und niemand hat eines auf eine Ersatzmaschine zurückgespielt und zugesehen, wie es hochkommt. Das Failover-Paar ist nie umgeschaltet worden, denn das hieße, einen Ausfall zu buchen, und jemand müsste dabei sein. Die Firmware ist die, die mitgeliefert wurde, das Zertifikat ist von dem verlängert worden, der daran gedacht hat, und die Dokumentation beschreibt ein Netz, das vor zwei Umzügen stillgelegt wurde. Die Lizenzzahl ist seit dem Jahr, in dem du elf Mitarbeiter mehr hattest, nicht angeschaut worden. Nichts davon erzeugt ein Ticket, also erreicht nichts davon irgendjemandes Bildschirm, und das Konto segelt durch jede interne Überprüfung, weil das Einzige, was gemessen wird, ist, ob du angerufen hast.\nDann findest du es heraus. Nicht bei einer Überprüfung, denn es gab keine. Du findest es an dem Morgen heraus, an dem die Rücksicherung gebraucht wird, oder wenn der Prüfer nach dem Diagramm fragt, oder wenn ein Ding, das sechs Jahre unberührt lief, stehen bleibt und niemand mehr im Gebäude weiß, was es tat. Ein stilles Konto zahlt so viel wie ein geschäftiges und kostet weit weniger in der Betreuung. Das ist der ganze Anreiz, und er zeigt davon weg, dass je jemand den Deckel öffnet.\nDer Rat, der sie Geld kostet Stell den Test andersherum und frag, was du eigentlich kaufen sollst. Es ist nicht die Abwesenheit von Ärger. Abwesend sein kann jeder. Wofür du zahlst, ist jemand, der das Geschäft gut genug kennt, um mit Dingen anzukommen, nach denen du nicht gefragt hast: eine Art, den Monatsabschluss zu machen, die aufhört umzufallen, eine Lizenz, für die du zahlst und die seit vorletztem Jahr niemand geöffnet hat, eine billigere Art, die Daten zu halten, ein Plan für die Kiste, die alle stillschweigend nicht neu starten. Manches davon kostet sie Umsatz, es dir zu sagen, was genau der Grund ist, warum es das ehrliche Signal ist. Frag dich, wann dein Dienstleister dir zuletzt eine Empfehlung vorgelegt hat, die seine eigene Rechnung kleiner gemacht hat.\nDie häufigste Form davon ist kein Rabatt. Es ist jemand, der durchgeht, was du schon betreibst. Den meisten Läden fehlt es nicht an Software, ihnen fehlt jemand, der sich je ordentlich mit der Software hingesetzt hat, die sie haben: die Lizenzstufe, die die Funktion, für die angeboten wird, schon enthält, das Modul, das im ursprünglichen Projekt bezahlt und nie ausgerollt wurde, der Ablauf im Finanzsystem, der das Neueintippen beenden würde, wenn ihm jemand zwei Tage gäbe, das zweite Abo, das gekauft wurde, weil niemand den ersten Lieferanten gefragt hat, ob sein Produkt das auch kann, die Auswertung, die nie jemand gebaut hat, sodass die ganze Firma in eine Tabelle exportiert und die Arbeit dort macht. Ein echter Dienstleister fängt in diesem Haufen an. Was du besitzt, wozu es sich bringen lässt, was es nie können wird, und wie viel vom Problem verschwindet, wenn das, wofür du ohnehin zahlst, so konfiguriert wird, wie es gemeint war — all das, bevor irgendwer eine Preisliste aufschlägt.\nWas dir sagt, wie sie an dir verdienen wollen, denn diese Arbeit ist die unbequeme Sorte. Sie heißt, die Dokumentation von jemand anderem zu lesen, ein System zu lernen, das sie nicht weiterverkaufen und für dessen Kenntnis sie nichts bekommen, und sich mit den Leuten hinzusetzen, die es den ganzen Tag benutzen, um herauszufinden, was freitags um vier tatsächlich passiert. Kein Rabatt kommt daraufhin an. Es ist auch genau das, was du zu kaufen glaubtest. Und manchmal ist die Antwort am Ende wirklich ein neues System, in welchem Fall kauf das neue System. Ausgeben ist nicht das Problem. Die Reihenfolge lautet: was du betreibst, was es noch können wird, wo es wirklich zu kurz greift, und erst dann, was zu beschaffen ist. Eine Empfehlung, die die ersten drei überspringt, war nie eine Bewertung. Sie war ein Katalog mit deinem Namen oben drauf.\nUnd ein Dienstleister, der sich nie hingesetzt und gelernt hat, was das Unternehmen tut, kann nichts davon. Es ist ein Unterschied, ob man weiß, dass du neunzig Postfächer hast, oder ob man weiß, in welcher Stunde welchen Tages es wirklich weh täte, das System zu verlieren, das die Bestellungen annimmt. Das eine ist Inventar, das andere ist Verständnis, und nur das zweite bringt Rat hervor, der das Geld wert ist. Ein Laden, der in drei Jahren nichts vorgeschlagen hat, der nicht sagen kann, was du verkaufst oder wann deine Hochsaison ist, der das Licht anlässt und die Rechnung jeden Monat am selben Tag erhöht, ist kein Partner und tut nicht mehr so. Es ist ein Abo mit einer Telefonnummer daran. Keines zum Behalten.\nDas entgegengesetzte Versagen taucht im besseren Anzug auf. Das ist der Dienstleister, der nie still ist, der jedes Quartal etwas für dich hat, und dessen Antwort auf jede Frage, die du je gestellt hast, mit einer Artikelnummer daran zurückkam. Es sieht aus wie Aufmerksamkeit. Was Rat von Verkauf trennt, ist nicht die Menge davon, und es sind auch nicht die guten Folien — es ist, ob die Empfehlung fähig ist, als „lass es in Ruhe, du brauchst dieses Jahr nichts, und das Geld ist besser für das Ding in der Ecke ausgegeben, für das niemand budgetiert hat“ zurückzukommen. Wenn in der ganzen Beziehung nicht eine Empfehlung sie je einen Verkauf gekostet hat, wirst du nicht beraten. Du wirst eine Liste entlanggeführt, und Teil eins handelt davon, woher diese Listen kommen. Ein Partner redet dir manchmal das Ausgeben aus. Für alle anderen bist du ein Konto, das kauft, was man ihm zeigt, was eine Melkkuh mit einem Service Desk daran ist, und niemand Beteiligter muss darüber unehrlich sein, damit genau das geschieht.\nEinen schlechten loswerden Arbeite durch, was tatsächlich passieren muss. Alles davon. Administratorzugangsdaten für jedes System übergeben. Dokumentation, die beschreibt, wie der Bestand gebaut ist, sofern sie existiert. Kontrolle über die Domainnamen und über das Konto, in dem das DNS liegt. Private Schlüssel der Zertifikate. Abos aus dem Partnervertrag des Dienstleisters heraus in eine Mandantschaft, die deine ist. Ihr Agent von jeder Maschine entfernt, von ihnen. Und der bisherige Anbieter, der wochenlang detailliert mit seinem Nachfolger zusammenarbeitet, ohne dafür bezahlt zu werden, und gerade erfahren hat, dass er raus ist.\nWas auf dem Weg hinaus wandern muss, und wer es hält Gehalten von dem Laden, den du verlässt Jedes Administratorzugangsdatum Dokumentation, falls welche geschrieben wurde Die Domains, und das DNS-Konto Private Schlüssel der Zertifikate Lizenzen unter ihrem Partnervertrag Ihr Agent, auf jeder Maschine, die dir gehört Und Wochen der Zeit ihrer Ingenieure muss wandern unbezahlt Deine, oder die deines Nachfolgers Bevor die Kündigungsfrist endet Und an diesem Tag Ihnen wurde gerade gesagt, dass sie raus sind Der Ingenieur, der deinen Bestand kannte, ist auf einem Auftrag, der zahlt Die Hälfte dessen, was du verlangst, stellt sich als kostenpflichtig heraus Nichts davon ist Sabotage Je schlechter sie waren, desto weniger von dieser Liste existiert zum Übergeben. Ein Laden, der deine Anforderungen nie aufschrieb, schrieb auch die Übergabemappe nicht, und das Durcheinander ist der Burggraben. Verlang die Mappe also heute, solange man sich noch versteht, und prüf eine Seite davon gegen eine laufende Maschine. All das liegt bei dem Laden, dem gerade gesagt wurde, dass er raus ist, und nichts von dem Umziehen ist Arbeit, für die ihn jemand bezahlt. Jetzt der Teil, der dich am meisten beunruhigen sollte. Je schlechter ein Dienstleister, desto schwerer wird dieser Ausstieg, denn die Versäumnisse sind dieselben Versäumnisse. Ein Laden, der deine Anforderungen nie aufgeschrieben hat, hat auch die Übergabemappe nicht geschrieben. Ein Laden, der die Zugangsdaten in einem gemeinsamen Tresor hielt, hat keinen sauberen Weg, sie jemand anderem zu geben. Ein Laden ohne Playbook und ohne Rücksicherungstest hat nichts zu übergeben außer Zugang und viel Glück. Das Durcheinander ist der Burggraben. Niemand hat sich hingesetzt und es so entworfen, und es funktioniert besser, als wenn er es getan hätte.\nNimm also an, dass die Dokumentationszeile nicht hält. Dokumentation ist das Erste, was ungeschrieben bleibt, und das Letzte, was jemand prüft, und was auf dem Weg hinaus ankommt, wird einen Bestand beschreiben, der ohne sie weitergezogen ist. Das ist der gute Fall. Der schlechte ist eine Mappe, die vollständig aussieht und falsch ist: ein Diagramm mit einem Switch darauf, der vor zwei Jahren auf den Schrott ging, ein Runbook für einen Server, der seither neu gebaut wurde, ein Zugangsdatenblatt voller Konten, mit denen sich niemand anmelden kann. Falsche Dokumentation ist schlimmer als keine, denn du handelst danach. Keine schickt dich wenigstens hin, um nachzusehen.\nBepreise den Ausstieg so, als überlebte ihn nichts. Jemand geht die Racks ab, liest die Konfiguration von den laufenden Geräten, exportiert die Firewall-Regeln und die DHCP-Bereiche und die Zonendateien, und schreibt auf, was tatsächlich läuft. Das sind Wochen Arbeit, und in einem Ausstieg sind es Wochen, die du unter Kündigungsfrist verbringst, während die Einzigen, die die Antworten kennen, schon erfahren haben, dass sie raus sind. Mach es stattdessen jetzt. Verlang die Mappe heute, dann nimm eine Seite davon und prüf sie gegen eine laufende Maschine. Wenn sie hält, hast du etwas Wissenswertes gelernt. Wenn sie die Bits nicht wert ist, mit denen sie gespeichert wird, hast du das auch gelernt, und du hast es mit einem Jahr Zeit gelernt, es in Ordnung zu bringen, statt mit zwei Wochen.\nDiese Zusammenarbeitszeile ist die, die tatsächlich weh tun wird, und die, die niemand bepreist. Lies sie als Bitte zurück: ein Laden, der gerade das Konto verloren hat, wird gebeten, Wochen damit zu verbringen, es den Leuten zu erklären, die es ihm abgenommen haben. Niemand muss sich weigern. Das Konto wandert auf den Stapel der Abgänge, der Ingenieur, der deinen Bestand kannte, geht auf einen Auftrag, der noch zahlt, und deine Fragen landen bei dem, der übrig ist. Antworten kommen in Tagen statt Stunden zurück. Der Übergabetermin wird drei Wochen im Voraus gebucht. Die Hälfte dessen, was du verlangst, stellt sich als kostenpflichtig heraus, und der Eine, der das Ding gebaut hat, ist im März gegangen. Nichts davon ist Sabotage. Alles davon kostet dich genau das, was Sabotage kosten würde.\nDein Nachfolger trägt es, und dann trägst du es noch einmal. Sein erster Monat geht damit drauf herauszufinden, was er geerbt hat. Das ist Erkundung, für die er dir nichts vorzeigen kann, also bepreist er sie entweder ehrlich und sieht gegen die Verlängerung des Bisherigen teuer aus, oder er schluckt sie und fängt die Arbeit schon im Rückstand an. Du zahlst so oder so. Kauf die Zusammenarbeit also, bevor du sie brauchst. Schreib sie beim Eintritt in den Vertrag statt beim Austritt: eine definierte Übergabephase, eine benannte Person, die sie macht, ein Tagessatz, vereinbart solange sie deine Unterschrift noch wollen, und Zugang, der aktiv bleibt, bis der neue Laden sagt, er kann weg. Zahl für eine Überlappung und rechne es als billig. Und komm nie an den Umschalttag, während der ausscheidende Dienstleister den einzigen Schlüssel zu etwas hält, das dir gehört.\nDer Papierkram tut sein Übriges. Kündigungsfristen in Monaten statt Wochen, automatische Verlängerungstermine, die verstreichen, während du noch entscheidest, und eine Übergabe, bepreist als professionelle Dienstleistung zu einem Tagessatz, den jemand festlegt, nachdem du schon gekündigt hast. Nichts davon ist ungewöhnlich, und nichts davon bricht eine Regel.\nPrüf den Ausstieg also, während die Beziehung gut ist und niemand verärgert ist. Verlang die Übergabemappe jetzt, schriftlich, als Lieferergebnis statt als Versprechen. Frag, wer der Inhaber deiner Domains tatsächlich ist. Frag, ob deine Lizenzen in deiner eigenen Mandantschaft sitzen oder unter ihrem Partnervertrag, und was ein Umzug bedeutet. Ein Dienstleister, der die Arbeit ordentlich macht, beantwortet alle drei aus dem Stand, denn ein Laden, der seiner Arbeit vertraut, hat keinen Grund, das Gehen schwer zu machen.\nUnd wenn die Antworten vage sind, denk daran, was der nächste Abschnitt darüber sagt, bei wem du dich beschwerst.\nFür den Verkauf gibt es keine Aufsicht Etwas sollte inzwischen nagen. Jedes Versagen in dieser Reihe, an dem eine formale Feststellung hing, ist ein Sicherheitsversagen. Die ICO zu Advanced. Die ICO zu Capita. CISA zu den Werkzeugen. Zum Verkauf — der Auswahlliste, dem Rabatt, der einen Option, der Verlängerung — gibt es nichts. Nicht eine einzige Vollstreckungsmaßnahme gegen einen britischen MSP.\nDas ist nicht so, weil der Verkauf sauber wäre. Es ist so, weil niemand die Aufgabe hat hinzuschauen.\nDas Verbraucherrecht endet an deiner Haustür. Der Consumer Rights Act 2015 schützt Verbraucher, und eine GmbH, die einen Managed Service kauft, ist keiner. Der Digital Markets, Competition and Consumers Act 2024 gab der CMA im April 2025 direkte Vollstreckungsbefugnisse, gerichtet auf aggressive Verkaufspraktiken, irreführende Angaben und offensichtlich unausgewogene Vertragsbedingungen. Es sind Verbraucherbefugnisse. Die eigene Bilanz der CMA zum ersten Jahr lohnt sich wegen der Formulierung ebenso wie wegen der Zahlen: vierzehn Untersuchungen, zwei Vergleiche, 760.000 Pfund „refunded to consumers“, 4,7 Millionen Pfund Bußgelder, 157 Beratungs- und Warnschreiben. Verbraucher, jedes Mal. Nicht der Dreißig-Personen-Hersteller, der letzten Frühling fünf Jahre Managed Service unterschrieben hat.\nTelekommunikation ist die eine Ecke, in der eine britische Aufsicht überhaupt in der Nähe war. Sie zeigt, wie Durchsetzung aussieht, wenn jemand die Zuständigkeit hat. Im Juli 2015 belegte Ofcom einen kleinen Telekommunikationsanbieter für Geschäftskunden mit 200.000 Pfund Bußgeld wegen Falschberatung beim Verkauf von Festnetzdiensten an eine Basis von „around 100,000 small businesses“, und ließ ihn die betroffenen Kunden entschädigen und seine Verkaufsunterlagen neu schreiben. Richtiges Verhalten, richtige Kundengröße, falsche Branche, und elf Jahre her.\nFür IT-Dienstleistungen gibt es kein Äquivalent. Rechne es von deinem Platz aus zusammen. Kein Widerrufsrecht. Keine Schlichtungsstelle zum Eskalieren. Keine Aufsicht mit Zuständigkeit. Keine Pflicht für irgendwen, dir zu sagen, was der Hersteller ihm zahlt. Keine veröffentlichten Feststellungen zum Lernen, weil es keinen Ort gibt, aus dem eine Feststellung kommen könnte. Der Vertrag wurde vom Lieferanten aufgesetzt, und das einzige Mittel darin ist zu klagen — was Kosten heißt, Jahre, und ein Rechtsbudget, das ein kleines Unternehmen nicht hat, wie der Lieferant sehr wohl weiß.\nDie Finanzberatung hatte genau dieses Problem und hat es gelöst. Die Lösung war nicht kompliziert — sag, wer den Berater bezahlt, und stell sicher, dass der Produktanbieter nicht die Antwort ist.\nFür die IT wird es keine solche Reform geben. Niemand kommt, um deinen MSP dazu zu bringen offenzulegen, was der Hersteller ihm zahlt, und das Cyber Security and Resilience Bill, das derzeit durchs Parlament geht und Managed Service Provider in die NIS-Verordnungen holen würde, handelt von Erkennung und Meldung, nicht davon, wer für die Beratung zahlt.\nWenn dir also jemand sagt, es gebe keine Belege für ein Problem darin, wie in diesem Land Technik verkauft wird, hat er recht. Es bedeutet überhaupt nichts. Es gibt keine Belege, weil es keinen Prüfer gibt, keinen Beschwerdeweg, der in einem öffentlichen Dokument endet, und kein Verzeichnis dessen, was mit allen anderen passiert ist, die denselben Vertrag unterschrieben haben. In einem Markt, den niemand beaufsichtigt, ist das Fehlen von Belegen nur das Fehlen von jemandem, der hinschaut.\nWas das über das Gewerbe sagt Nimm die Rechnungen weg und schau, wer in diesem Arrangement tatsächlich steht.\nAn dem einen Ende Unternehmen, die Dinge herstellen und tun. Ein Betrieb, der Teile fräst. Eine Werkstatt. Eine Küche, die Menschen sattmacht. Anwälte, die jemanden an einem Freitag in ein Haus bringen. Jeder von ihnen bringt etwas hervor, auf das man zeigen kann, und jeder von ihnen trägt das Risiko in diesem Beitrag, denn sie sind die einzige Partei in der Kette, die nichts ausschließen kann.\nAn dem anderen Ende mehrere Schichten, die überhaupt nichts hervorbringen. Ein Hersteller, dessen Lizenz die Eignung für einen bestimmten Zweck ausschließt. Ein Distributor, der eine Kiste zwischen Lagern bewegt und einen Schnitt nimmt. Ein Partnerprogramm, das jemanden dafür bezahlt, ein Logo einem anderen vorzuziehen. Ein Dienstleister, der Stunden gegen eine gedeckelte Haftung verkauft. Jeder nimmt seine Marge und reicht die Folge nach unten weiter, und die Folge wandert weiter, bis sie den Einzigen erreicht, der am Montag die Türen aufmachen muss.\nEin Gewerbe ist eine Gruppe von Menschen, die etwas können, die dafür bezahlt werden, dass sie es können, und die hinter dem stehen, was sie sagen, weil ihr Name daran steht. Daran gemessen ist der größte Teil dieser Branche ein Vertriebskanal mit Zertifizierungen.\nSchau, was dafür hergegeben wurde. Können zuerst, denn du kannst nicht ein Drittel aus dem herausschneiden, was du für Weiterbildung ausgibst, und dann mit ernstem Gesicht Fachwissen verkaufen. Dann Urteilsvermögen, vorne im Auftrag verkauft und in dem Moment ausgeschlossen, in dem es geprüft wird. Und zuletzt die schlichte Bereitschaft zu sagen „das ist nicht die richtige Antwort für dich“, wenn die richtige Antwort weniger zahlt — was das Einzige ist, was Rat von Verkauf trennt, und nichts kostet außer Nerven.\nDer Ausweg daraus ist unglamourös und vollständig verfügbar. Besitz die Geräte, die du besitzen kannst. Halt deine eigenen Schlüssel. Halt die Dokumentation an einem Ort, den du erreichst, ohne irgendwen anzurufen. Lern genug über deine eigenen Systeme, um zu merken, wenn dir etwas Blödes erzählt wird — nicht, um sie selbst zu betreiben, nur um zu erkennen, wenn ein Adjektiv ankommt, wo nach einer Zahl gefragt wurde. Das ist keine Nostalgie danach, dass jeder einen Server im Schrank hatte. Es ist der einzige Hebel, den es gibt, und er ist billig.\nEs gibt Leute in diesem Gewerbe, die nie aufgehört haben, die Arbeit ordentlich zu machen, und sie sind nicht schwer zu erkennen, wenn man weiß, worauf man achtet. Sie bieten die langweilige Option an. Sie sagen dir, was ein Ding kostet, statt was es gepreist ist. Sie legen das Risiko schriftlich vor, bevor du fragst, und sie sind erleichtert, wenn endlich jemand nachprüft.\nDie anderen haben es so eingerichtet, dass es nie jemand tut. Du darfst fragen, was es kostet, wer wen bezahlt, und was passiert, wenn es kaputtgeht. Niemand in diesem Arrangement wird es von sich aus sagen, und das ist nicht dasselbe, wie dass es dir nicht zustünde.\nIs Your MSP Lying To You — 3 parts\nBelügt dich dein MSP, um dir Premium-Produkte zu verkaufen? Was dein MSP dir gebaut hat, und wer sonst noch drankommt Wenn es kaputtgeht, wer trägt es dann wirklich?you are here Quellen Abgerufen am 28. August 2026.\nRecht und Politik.\nCyber Security and Resilience (Network and Information Systems) Bill 2024-26 — Briefing der House of Commons Library dazu, Managed Service Provider in die NIS-Verordnungen zu holen. Wer sich beschweren darf.\nConsumer Rights Act 2015 und der Digital Markets, Competition and Consumers Act 2024 — die Schutzrechte, und für wen sie gelten. CMA, direkte Verbraucherdurchsetzung nach einem Jahr — April 2025 bis April 2026: 14 Untersuchungen, 760.000 Pfund an Verbraucher zurückerstattet, 4,7 Millionen Pfund Bußgelder. Ofcom belegt Unicom mit Bußgeld, 31. Juli 2015 — 200.000 Pfund wegen Falschberatung gegenüber kleinen Unternehmen, das Nächstliegende an einem Durchsetzungspräzedenzfall, in der Telekommunikation statt in der IT. ","permalink":"https://blogs.damiendye.uk/de/random/is-your-msp-lying-to-you-part3/","summary":"Teil 3 von 3. Reaktionszeiten statt Ergebnissen, eine Haftungsobergrenze in Höhe der bereits gezahlten Gebühren, und ein Dienstleister, dessen Ausreden am Ende bei dir landen. Die Fragen, die das ans Licht bringen, was ein echter stattdessen tut, und was es braucht, einen schlechten loszuwerden.","title":"Wenn es kaputtgeht, wer trägt es dann wirklich?"},{"content":"Eine Verbindung, die abläuft, sagt dir fast nichts. Am anderen Ende lauscht vielleicht nichts, eine Firewall drei Hops entfernt verwirft vielleicht deinen SYN im Stillen, ohne auch nur eine Log-Zeile zu erzeugen, oder die Route existiert schlicht nicht — und von dort, wo du sitzt, sieht jedes davon gleich aus. Du wartest. Nichts passiert.\nSo wird das Ticket als „Port 445 ist irgendwo blockiert“ geschrieben, und „irgendwo“ ist es, was es zurückspringen lässt. Dein Provider prüft seinen Rand, findet ihn sauber und gibt es zurück. Du prüfst deine Host-Firewall, findest sie sauber und gibst es zurück. Eine Woche vergeht. Nichts ist behoben.\nDas Wort, das den Schaden anrichtet, ist „irgendwo“. Es muss nicht dort stehen. Jeder Router zwischen dir und dem Ziel ist verpflichtet, dir zu sagen, wenn er der eine ist, und diese Pflicht steht seit 1995 in den Standards. Du musst nur richtig fragen.\nWarum das buchstabiert werden muss Weil zu viele Leute in dieser Branche die Grundlagen nicht können, und das kostet ihre Arbeitgeber jede Woche echtes Geld.\nIch meine keine Junioren. Ich meine Leute mit Jahren auf dem Buckel, Zertifikaten an der Wand und „Senior“ im Jobtitel, deren Diagnose eines abgelaufenen Ports bei „ist blockiert“ endet und nicht weitergeht. Sie lassen ping laufen. Es scheitert, oder es klappt, und so oder so haben sie nichts über den Port gelernt, nach dem sie gefragt wurden. Dann geht das Ticket an den Provider, der Provider lässt es zurückspringen, und zwei Wochen Gehalt von jemandem verschwinden in einem Thread, der ein einziger Befehl hätte sein können.\nNichts davon ist schwer. Einen Drop von einem Reject unterscheiden, die TTL auf einer Antwort lesen, wissen, dass ein Stern in einem Traceroute für sich genommen nichts heißt — das ist ein Nachmittag zum Lernen und hält eine Laufbahn lang. Der Grund, warum Leute es nicht wissen, ist nicht, dass sie dumm sind. Es ist, dass niemand es lehrt. Hersteller-Schulungen bringen dir die Konsole eines Herstellers bei. Zertifikate bringen dir die Prüfung bei. Die Grundlagen darunter werden am ersten Tag vorausgesetzt und nie wirklich behandelt, also kommen Leute in Senior-Rollen, ohne dass es ihnen je gezeigt wurde, und dann ist es peinlich zu fragen.\nStatt darüber zu jammern, steht es hier also aufgeschrieben. Das sind die Grundlagen, buchstabiert, mit den Befehlen und einem Skript, das du heute laufen lassen kannst.\nUnd ein Wort dazu, warum ich mir die Mühe gemacht habe: Ich habe das gegen meine eigene Leitung laufen lassen, während ich es schrieb, und fand drei Fehler, von denen ich nichts wusste. Einen SMB-Drop elf Hops weit draußen. Gefälschte SMTP-Resets einen Hop entfernt. Eine Firewall-Regel, die es auf IPv4 gibt und auf IPv6 nicht. Ein Nachmittag, kein Root, auf einer Leitung, um die ich mich selbst kümmere und auf die ich achte. Denk mal darüber nach, was unbemerkt auf den Netzen sitzt, für deren Betrieb jemand bezahlt wird.\nWarum das Fisher-Price-OS (Windows) hier nicht vorkommt Zwei Gründe, warum es hier nicht steht. Einer davon ist technisch und einer nicht, und ich gebe dir lieber beide, als so zu tun, als wäre alles Technik.\nDer technische ist, dass es das nicht kann. tracert sendet ICMP-Echo-Requests und sonst nichts — Microsofts eigene Referenz beschreibt es als „sending Internet Control Message Protocol (ICMP) echo Request or ICMPv6 messages to the destination with incrementally increasing time to live (TTL) field values“, und es gibt nirgends in seiner Syntax einen Port-Parameter. pathping ist dasselbe Werkzeug mit angeschraubter Statistik. Test-NetConnection sagt dir, ob ein TCP-Port offen oder zu ist, und nichts weiter darüber, wie weit weg die Antwort herkam. Nicht eines davon kann den Port, um den es dir wirklich geht, in einer gewählten Entfernung untersuchen, was die ganze Methode in diesem Beitrag ist.\nDu kannst dich auch nicht drumherum skripten. Die TTL auf einem Socket zu setzen ist in .NET einfach genug, aber den ICMP-Fehler zurückzulesen ist die schwere Hälfte, und es gibt kein Äquivalent zu dem Trick, auf den sich dieser Beitrag stützt — keinen Weg, den Kernel den Fehler auf dem gewöhnlichen Socket melden zu lassen, der ihn verursacht hat. Das lässt einen Raw-Socket übrig, und Microsofts eigene Dokumentation sagt „only members of the Administrators group can create sockets of type SOCK_RAW“. Der unprivilegierte Weg existiert also nicht und der privilegierte will ein lokales Admin-Token. Du bist bei Drittanbieter-Downloads, bevor du angefangen hast.\nDer andere Grund ist, dass es mir egal ist, und das sage ich lieber, als es aufzuhübschen. Der Name ist auch kein billiger Seitenhieb, er ist eine Beschreibung. Es ist das OS, das man in die Hand gedrückt bekommt, wenn man nie ein anderes hatte, es versteckt die Maschine vor dir als Design-Ziel statt als Unfall, und in dem Moment, in dem du dem Netz eine präzise Frage stellen willst, stellt sich heraus, dass das Werkzeug nie gebaut wurde — weil von den Leuten, für die es gebaut ist, nie erwartet wurde, dass sie fragen. Dreißig Jahre später kann tracert immer noch kein Paket auf einen Port zielen.\nEs ist kein richtiges Betriebssystem für echte IT-Leute, und wenn es das einzige ist, das du je benutzt hast, dann machst du diesen Job nicht auf dem Niveau, für das dieser Beitrag geschrieben ist. Mir ist klar, dass das schlecht ankommt. Ich schreibe nicht, um gemocht zu werden, ich schreibe auf, was ich messe, für Leute, die Dinge messen, und es ist mir ziemlich egal, dass jemand, der nur es je betrieben hat, es lieber anders formuliert hätte.\nDie Werkzeugliste ist das Argument, nicht die Meinung. Jedes Unix in der Tabelle weiter unten lässt dich ein Hop-Limit setzen und ein Protokoll wählen, vier davon aus einem einzigen Befehl, und Linux macht die ganze Messung ohne auch nur ein sudo. Das liegt nicht daran, dass sie schwerer zu bedienen sind. Es liegt daran, dass sie von Leuten gebaut wurden, die erwarteten, dass der, der an der Tastatur sitzt, Dinge wissen will. Ein Betriebssystem, dessen Diagnose bei ping endet, hat dir klar gesagt, was es von der Person hält, die es benutzt, und dreißig Jahre, in denen Leute das akzeptiert haben, sind, wie wir bei einer Branche gelandet sind, die kein verworfenes Paket orten kann.\nIch betreibe es also nicht, ich habe es seit Jahren nicht im Ernst betrieben, und ich schreibe ihm keinen eigenen Abschnitt, um über eine Lücke, die real ist, ausgewogen zu wirken. Alles, worauf ich baue, und alles, von dem aus zu messen sich lohnt, ist Unix, und dort lebt dieser Beitrag.\nWenn die kaputte Kiste zufällig das Fisher-Price-OS (Windows) betreibt, ändert das nichts an der Methode. Hol dir eine Shell auf irgendetwas anderem — eine Linux-VM, einen Mac, einen Raspberry Pi am selben Switch — und lauf das Hop-Limit auf sie zu. Die Messung schert sich nicht im Geringsten darum, was das ferne Ende betreibt. Sie schert sich nur darum, was dazwischen liegt.\nTTL ist ein Hop-Budget, und jeder Router schuldet dir eine Quittung Der IPv4-Header hat ein 8-Bit-Feld Time to Live. Der Name ist ein Überbleibsel: es wurde in Sekunden spezifiziert, und seit Jahrzehnten behandelt es nichts als Sekunden. RFC 1812 hat den Streit 1995 beigelegt und die Hop-Count-Lesart normativ gemacht:\nEach router (or other module) that handles a packet MUST decrement the TTL by at least one, even if the elapsed time was much less than a second. Since this is very often the case, the TTL is effectively a hop count limit on how far a datagram can propagate through the Internet.\nDann der Teil, der hier zählt, aus demselben Abschnitt:\nIf the TTL is reduced to zero (or less), the packet MUST be discarded, and if the destination is not a multicast address the router MUST send an ICMP Time Exceeded message, Code 0 (TTL Exceeded in Transit) message to the source.\nDas ist ein MUST. Keine Nettigkeit, kein Vorschlag. RFC 792 sagte 1981 nur, ein Gateway „may also notify the source host“; dreizehn Jahre später wurde die Anforderung verschärft, und RFC 1812 sagt in ebenso vielen Worten, warum:\nICMP Time Exceeded messages are required because the traceroute diagnostic tool depends on them.\nIPv6 hat die Fassade fallen lassen und das Feld umbenannt. RFC 8200 nennt es Hop Limit — „8-bit unsigned integer. Decremented by 1 by each node that forwards the packet“ — und die Ablauf-Nachricht wurde ICMPv6 Typ 3, Code 0, „hop limit exceeded in transit“.\nLies das als Instrument statt als Regel, und es sagt etwas Nützliches. Jeder Router auf dem Pfad ist ein Leuchtfeuer, das du nach Entfernung ansprechen kannst. Setz das Hop-Limit auf 4, und der vierte Router gibt sich zu erkennen. Du musst die Topologie nicht kennen, du brauchst zu nichts Zugriff, und du brauchst nicht die Kooperation des Betreibers. Du brauchst ein Paket pro Hop.\nTraceroute macht genau das seit den späten 1980ern. Was es schlecht macht, ist genau das, worauf es dir ankommt, denn standardmäßig untersucht es UDP-Ports oben im Bereich 33434, ein Port, den niemand filtert und niemand bedient, also erzählt es dir von einem Pfad, den nichts Echtes je nutzt. Ein sauberes Traceroute zu einem Host, den du auf TCP/445 nicht erreichst, beweist nur, dass UDP/33434 dort ankommt. Was nie die Frage war.\nAlso untersuche den Port, um den es dir geht.\nLies, was zurückkam, nicht ob etwas zurückkam Bevor du Hops zählst, sieh dir an, was das ferne Ende tut, wenn du es mit einem normalen Hop-Limit erreichst. Es gibt fünf verschiedene Antworten, und Leute werfen sie routinemäßig in einen Topf.\nWas zurückkommt Was es heißt Wer es geschickt hat SYN-ACK, die Verbindung öffnet der Port ist offen der Host, oder etwas, das für ihn antwortet TCP RST aktiv abgelehnt der Host, auf dem nichts lauscht, oder ein Gerät, das auf Reject konfiguriert ist ICMP 3/13, communication administratively prohibited ein Gerät lehnt per Policy ab und sagt es dieses Gerät — seine Quelladresse ist deine Antwort ICMP 3/1, 3/2, 3/3 Host, Protokoll oder Port unerreichbar der letzte Router, oder der Host gar nichts jemand verwirft im Stillen unbekannt, also geh und miss es Die dritte Zeile ist die, für die es sich lohnt, seine Gewohnheiten zu ändern. Wenn eine Firewall darauf konfiguriert ist, abzulehnen statt zu verwerfen, setzt sie ihre eigene Adresse in das Quellfeld des ICMP und liefert dir den Schuldigen gratis. Auf Linux ist das, was nft ... reject with icmpx admin-prohibited erzeugt, und was iptables -j REJECT --reject-with icmp-admin-prohibited schon immer erzeugt hat. Die meisten Werkzeuge werfen es weg und drucken „filtered“. nmap --reason zeigt es. Das Skript weiter unten auch.\nZeile zwei und fünf sind das interessante Versagen. Ein stiller Drop ist eine Policy-Entscheidung, dir nichts zu sagen, und weil er auf fast jeder kommerziellen Firewall die Voreinstellung ist, ist er der, dem du tatsächlich begegnest. Erwarte Stille.\nZeile zwei verdient auch Misstrauen. Ein Reset ist kein Beweis, dass der Host ihn geschickt hat, und darauf komme ich mit einem Live-Beispiel zurück, denn ich fand eins auf meiner eigenen Leitung, während ich das schrieb.\nLauf den Port, um den es dir geht — zweimal Die Methode sind zwei Läufe und ein Diff. Das ist das Ganze.\nLauf das Hop-Limit von 1 auf 20 hoch, mit genau dem Protokoll und Port, der scheitert, und schreib auf, welcher Router bei jedem Hop antwortet. Mach dasselbe mit etwas, das funktioniert — idealerweise derselbe Host und ein Port, der öffnet. Der Hop, bei dem die Antworten in Lauf eins aufhören und in Lauf zwei weitergehen, ist das Gerät, das dich verwirft. Lauf zwei gibt dir seine Adresse. Warum die Antworten aufhören statt sich zu ändern: Ein Router wendet seine eingehende Access-List an, bevor er sonst irgendetwas mit dem Paket tut, also ist das Paket, wenn die Policy Drop sagt, weg, bevor der Weiterleitungspfad je auf das Hop-Limit schaut, kein Time Exceeded wird erzeugt, und das Gerät setzt seinen Namen nie unter das, was es tat. Damit beginnt die Stille bei dem schuldigen Hop, nicht danach.\nIch habe ein kleines Werkzeug für das Laufen geschrieben, weil keins der nativen es portabel macht. Es setzt IP_TTL (oder IPV6_UNICAST_HOPS) auf einem gewöhnlichen Socket, verbindet und liest den ICMP-Fehler zurück. Auf Linux meldet IP_RECVERR diesen Fehler auf genau dem Socket, der ihn provoziert hat, was heißt: das Ganze läuft unprivilegiert — kein Root, keine Raw-Sockets, keine Capabilities. Auf macOS, den BSDs und Solaris reicht dir der Kernel das ICMP nicht so, also fällt es auf einen Raw-Socket zurück und braucht Root.\n\u0026#8615; hopfind.py — der TTL-Walker hopfind.py · 11 kB Es sind 279 Zeilen Standardbibliothek und sonst nichts, und das Ganze ist am Ende dieses Beitrags abgedruckt, falls du es lieber liest als herunterlädst.\npython3 hopfind.py example.net 445 # the port under suspicion python3 hopfind.py example.net 443 # the reference run python3 hopfind.py example.net 53 --proto udp python3 hopfind.py 2001:db8::1 443 -6 Benutze für beide Läufe dasselbe Protokoll. Eine TCP-Spur gegen eine ICMP-Spur zu vergleichen heißt, zwei Pfade zu vergleichen, denn Load-Balancing hasht über das Fünf-Tupel, und ICMP hat keine Ports zum Hashen. Derselbe Host, dasselbe Protokoll, ein anderer Port ist der ehrliche Vergleich.\nAlles unten ist echte Ausgabe von meiner eigenen Leitung am 28. August 2026, als unprivilegierter Benutzer auf Fedora gelaufen. Jede Adresse darin wurde in die Dokumentationsbereiche umgeschrieben — RFC 5737 für IPv4, RFC 3849 für IPv6, mit dem einen Interface-Identifier ebenfalls geändert. Also ist 198.51.100.x mein eigener Router und mein ISP, 203.0.113.x ist Transit und Peering, 192.0.2.x ist das ferne Netz, und 2001:db8::/32 ist der ganze IPv6-Pfad. Die Struktur bleibt durchweg erhalten: dieselben Präfixgrenzen, dieselben Host-Teil-Formen, dieselbe Anzahl verschiedener Netze. Die Hop-Nummern, die Zeiten, die ICMP-Typen und welcher Hop verstummte sind genau wie gemessen.\nEin Host, drei Ports, drei verschiedene Fehler Durchweg dasselbe Ziel: ein Host im öffentlichen Internet, vierzehn Hops entfernt, mit offenem 443. Zuerst der Referenzlauf.\n$ python3 hopfind.py 192.0.2.4 443 --max 15 walking to 192.0.2.4 TCP/443 hop limit 1-15 1 198.51.100.254 0.3 ms ICMP 11/0 time exceeded in-transit 2 198.51.100.133 28.8 ms ICMP 11/0 time exceeded in-transit 3 * 4 198.51.100.153 6.3 ms ICMP 11/0 time exceeded in-transit 5 * 6 203.0.113.240 16.5 ms ICMP 11/0 time exceeded in-transit 7 203.0.113.188 16.5 ms ICMP 11/0 time exceeded in-transit 8 203.0.113.185 16.5 ms ICMP 11/0 time exceeded in-transit 9 203.0.113.15 15.6 ms ICMP 11/0 time exceeded in-transit 10 203.0.113.125 16.1 ms ICMP 11/0 time exceeded in-transit 11 192.0.2.31 26.6 ms ICMP 11/0 time exceeded in-transit 12 * 13 * 14 192.0.2.4 19.5 ms connected Verdict: TCP/443 is open. It answered at hop 14. Beachte die Hops 3, 5, 12 und 13. Vier Router auf einem Pfad, der klar funktioniert, sagten nichts, weil eine Menge Geräte so konfiguriert sind, dass sie für sich selbst kein ICMP erzeugen, oder es hart raten-limitieren. Ein Stern ist kein Beweis für eine Firewall. Nimm wenigstens das eine mit. Das Signal ist nie die Anwesenheit von Sternen in einem einzelnen Lauf; es ist, wo zwei Läufe nicht mehr übereinstimmen.\nJetzt derselbe Host auf 445, der von hier abläuft.\n$ python3 hopfind.py 192.0.2.4 445 --max 15 walking to 192.0.2.4 TCP/445 hop limit 1-15 1 198.51.100.254 0.3 ms ICMP 11/0 time exceeded in-transit 2 198.51.100.133 8.0 ms ICMP 11/0 time exceeded in-transit 3 * 4 198.51.100.153 6.4 ms ICMP 11/0 time exceeded in-transit 5 203.0.113.76 5.6 ms ICMP 11/0 time exceeded in-transit 6 203.0.113.240 15.9 ms ICMP 11/0 time exceeded in-transit 7 203.0.113.188 15.8 ms ICMP 11/0 time exceeded in-transit 8 203.0.113.185 16.6 ms ICMP 11/0 time exceeded in-transit 9 203.0.113.15 15.9 ms ICMP 11/0 time exceeded in-transit 10 203.0.113.125 15.0 ms ICMP 11/0 time exceeded in-transit 11 * 12 * 13 * 14 * 15 * Verdict: answers stop after hop 10 (203.0.113.125). Whatever swallows TCP/445 is hop 11. Walk a port that works and read off the address at hop 11. Hop 11 beantwortete den 443-Lauf in 26,6 ms und sagte zum 445-Lauf gar nichts. Dieselbe Kiste, derselbe Pfad, dieselben zehn Router davor. Quervergleich mit dem Lauf, der funktioniert, und Hop 11 hat einen Namen: 192.0.2.31. Das ist das Gerät, das SMB verwirft, drei Hops vor dem Ziel und acht Hops hinter dem Rand meines Providers. Nicht meins, und nicht das meines ISP.\nHop 5 macht den Punkt über Sterne von der anderen Seite. Er war ein Stern im 443-Lauf und antwortete im 445-Lauf — genau andersherum als der Fehler. Das könnte ICMP-Raten-Limitierung sein, oder die zwei Läufe könnten verschiedene Pfade durch einen Load-Balancer nehmen. Ich weiß nicht, welches, und du auch nicht. Wiederhol beide Läufe, bevor du einem glaubst.\nZwei Hop-Limit-Läufe zum selben Host, und der Hop, ab dem sie nicht mehr übereinstimmen Zwei Läufe zum selben Host, und der Hop, ab dem sie nicht mehr übereinstimmen Eine Probe pro Hop-Limit. Eine schattierte Zelle heißt: dieser Router hat ICMP Time Exceeded zurückgeschickt und sich benannt. Router antwortet nichts kam zurück ab hier still 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Hop-Limit auf der Probe TCP/443 Referenz, öffnet \u0026#8226; \u0026#8226; * \u0026#8226; * \u0026#8226; \u0026#8226; \u0026#8226; \u0026#8226; \u0026#8226; \u0026#8226; * * \u0026#10003; öffnet TCP/445 im Test, läuft ab \u0026#8226; \u0026#8226; * \u0026#8226; \u0026#8226; \u0026#8226; \u0026#8226; \u0026#8226; \u0026#8226; \u0026#8226; * * * * Hop 11 beantwortete einen Lauf, den anderen nicht Hops 3, 5, 12 und 13 schwiegen auf einem Pfad, der klar funktioniert — ein Stern allein heißt nichts. Hop 11 antwortete dem Referenzlauf in 26,6\u0026#160;ms und dem Testlauf gar nicht. Das ist die Grenze, und der Referenzlauf gibt ihr eine Adresse:\u0026#160;192.0.2.31. Dieselben zwei Läufe nebeneinander. Die einzige Zelle, die zählt, ist Hop 11, und was an ihr zählt, ist die Uneinigkeit: er beantwortete einen Lauf und den anderen nicht. Dann Port 25. Der hat mich gestoppt.\n$ python3 hopfind.py 192.0.2.4 25 --max 15 walking to 192.0.2.4 TCP/25 hop limit 1-15 1 192.0.2.4 0.4 ms TCP reset Verdict: a reset came back to a probe with a hop limit of 1. Nothing more than one hop away can have sent it, so check the reply TTL before you believe the host did. Ein Hop-Limit von 1 heißt, das Paket starb an meinem eigenen Router. Es ging einen Hop. Es kann nicht vierzehn gereist sein. Trotzdem kam in 0,4 ms ein TCP-Reset mit der Adresse des Ziels darauf zurück, und mein Kernel meldete brav connection refused. Ohne gesetztes Hop-Limit hätte ich das als „das ferne Ende hat keinen Mailserver“ gelesen und das Ticket geschlossen.\nEtwas einen Hop entfernt fälscht Resets für ausgehendes SMTP und signiert sie mit der Adresse des Ziels. Ausgehenden Port 25 zu blockieren ist etwas völlig Gewöhnliches für einen Consumer-Router oder einen ISP, und es mit einem Reset statt einem Drop zu tun ist wohl die höfliche Variante, aber der Reset trägt die Adresse von jemand anderem, und ich hatte keine Ahnung, dass meiner das tut. Das Hop-Limit ist, was es erwischt hat, und sonst nichts in der Antwort hätte es getan.\nUm eins daneben: wo die Access-List in der Pipeline sitzt Das Urteil oben sagt, der Verwerfer ist Hop 11, weil die Antworten nach Hop 10 aufhörten. Sei vorsichtig mit dieser Arithmetik, denn sie hängt von der Reihenfolge ab, in der das schuldige Gerät zwei Aufgaben erledigt.\nDie meisten Geräte wenden zuerst die eingehende Policy an und die Hop-Limit-Prüfung als Zweites. Deny greift, das Paket wird verworfen, und nie wird ein Time Exceeded erzeugt, also taucht das Gerät nie auf und die Stille beginnt bei seiner eigenen Hop-Nummer. Das ist der Fall oben. Es ist auch der häufige.\nManche Plattformen erledigen den Hop-Limit-Ablauf im Fast Path, bevor die Policy ausgewertet wird. Dort beantwortet das Gerät die an es adressierte Probe und verwirft nur Proben, die weiter zielen, also taucht es normal auf und die Stille beginnt einen Hop später.\nWarum der schuldige Hop meist nicht auftaucht: die Policy wird vor der Hop-Limit-Prüfung ausgewertet Im Hop, der dich verwirft, entscheidet die Reihenfolge zweier Prüfungen, was du siehst Deine Probe kommt mit einem Hop Restbudget an und trifft auf eine Regel, die verwirft. Policy zuerst \u0026#8212; fast alle Firewalls, und jeder in diesem Beitrag gemessene Fall der Router bei Hop N Probe rein Eingangs-Policy Hop-Limit-Prüfung weiterleiten verworfen, bevor irgendetwas das Hop-Limit ansieht Es wird kein ICMP erzeugt, dieser Router bekennt sich also nicht zum Drop. Dein Lauf verstummt\u0026#160;bei\u0026#160;Hop\u0026#160;N. Ablauf zuerst \u0026#8212; manche Plattformen erledigen ihn im Fast Path der Router bei Hop N Probe rein Hop-Limit-Prüfung Eingangs-Policy weiterleiten abgelaufen, also geht ICMP 11/0 mit der Adresse dieses Routers zurück Er antwortet für sich selbst und schluckt nur Proben, die weiter zielen. Dein Lauf verstummt ab Hop\u0026#160;N+1. Warum der verwerfende Hop meist unsichtbar bleibt. Auf fast allen Firewalls wird das Deny zuerst ausgewertet, also ist die Probe weg, bevor der Weiterleitungspfad den abgelaufenen Hop-Limit bemerkt, und nie wird ein ICMP erzeugt. Auf Geräten, die den Ablauf im Fast Path erledigen, beantwortet dasselbe Gerät die an es adressierte Probe und schluckt nur die weiter gezielten. Die ehrliche Lesart von „Antworten hören nach Hop N auf“ ist also: der Verwerfer ist Hop N+1, wenn er deine Probe entsorgt hat, bevor er merkte, dass das Budget aufgebraucht war, oder Hop N selbst, wenn er die an ihn adressierte Probe beantwortet und alles weiter Gezielte geschluckt hat. Zwei benachbarte Geräte, und der Lauf, der funktioniert, benennt beide. Zitier die Adressen, nicht die Hop-Zahl — eine Hop-Zahl heißt nichts für die Person, die dein Ticket liest und von irgendwo anders zählt.\nDie TTL der Antwort sagt dir, wer wirklich geantwortet hat Der SMTP-Reset oben wurde vom Hop-Limit erwischt, das hinaus ging. Es gibt eine zweite, unabhängige Prüfung, die in jeder Antwort verfügbar ist, die zurück kommt, und sie kostet nichts.\nAnfangs-TTL-Werte sind nicht standardisiert, aber in der Praxis gibt es drei:\nBeginnt bei Typischer Absender 64 Linux, macOS, die BSDs, illumos, die meisten Hosts 255 Cisco IOS, Junos, Solaris, der Eigenverkehr der meisten Netzgeräte 128 das Fisher-Price-OS (Windows), das du zum Ablesen einer Antwort davon immer noch brauchst Zieh die empfangene TTL vom nächsthöheren Wert ab und du hast die Hop-Zahl zurück. Eine Antwort, die mit TTL 50 ankommt, begann bei 64 und kam 14 Hops. Eine mit TTL 250 begann bei 255 und kam 5. ping druckt es ungefragt:\nping -c1 192.0.2.4 # ttl=50 → 14 hops away tcpdump -n -v \u0026#39;icmp\u0026#39; # -v prints the ttl of every packet it shows Zwei Dinge fallen daraus. Beide sind gratis.\nEine Antwort, deren Rückwärts-Hop-Zahl nicht zu den anderen Antworten des Hosts passt, wurde nicht vom Host geschickt. Wenn ein Echo-Reply von einem Server 14 Hops weit zurückkommt und der RST auf Port 25 einen Hop weit zurückkommt, hat eine Middlebox den RST geschrieben. Derselbe Trick wie im Abschnitt oben, vom anderen Ende, und er funktioniert sogar, wenn du die ausgehende TTL nicht setzen kannst.\nEine Antwort, die bei 255 begann, kam von Netzgerät, nicht von einem Server. Nützlich, wenn du herauszufinden versuchst, ob das, was dich ablehnt, der Host ist oder der Router davor.\nUm das Feld auf TCP statt ICMP zu sehen, brauchst du eine Aufzeichnung, und der Filter ist es wert, ihn sich zu merken:\n# every hop-limit expiry coming back to you, IPv4 and IPv6 tcpdump -n -v \u0026#39;icmp[icmptype] == 11 or icmp6[icmp6type] == 3\u0026#39; # who is resetting you, and from how far tcpdump -n -v \u0026#39;tcp[tcpflags] \u0026amp; tcp-rst != 0\u0026#39; tcpdump druckt den Ablauf als ICMP time exceeded in-transit — dieselbe Formulierung, die die Standards benutzen, und dasselbe Ereignis, das auf Plattformen, die es so formulieren, als „TTL expired in transit“ auftaucht.\nDerselbe Trick mit nativen Werkzeugen, auf fünf Unixen Wenn du lieber kein Skript laufen lässt, erledigen die nativen Werkzeuge das meiste davon. Sie sind sich nur uneiniger, als du erwarten würdest. -P insbesondere heißt drei verschiedene Dinge, je nachdem, wessen Traceroute du in der Hand hast, und eins davon ruiniert deinen Test still und leise.\nLinux (traceroute 2.1.x) macOS / FreeBSD OpenBSD NetBSD Solaris 11 TCP-Proben -T -P tcp nicht nutzbar nein nein ICMP-Proben -I -I -I -I -I UDP zu festem Port -U -p N -e -p N nein nein nein Zielport -p N (konstant für TCP) -p N (erhöht sich ohne -e) -p N (erhöht sich) -p N (erhöht sich) -p N (erhöht sich) was -P heißt nicht genutzt Probe-Protokoll numerisches Protokoll, „will not work reliably for most protocols“ DF setzen und Pfad-MTU prüfen Pause zwischen Proben, in Sekunden braucht Privilegien ja, für -T und -I ja ja ja ja Jedes davon braucht Raw-Sockets, also braucht jedes Privilegien — obwohl macOS und die BSDs Traceroute meist setuid root ausliefern, sodass du vielleicht kein sudo davorsetzen musst. Linux tut es nicht, und Fedora tut es nicht, was der halbe Grund ist, warum das Skript oben existiert.\nDrei Fallen in dieser Tabelle, und ich habe alle drei einen Nachmittag verschwenden sehen.\nAuf den BSDs und macOS ist -p ein Basis-Port, der sich mit jeder Probe erhöht. Also testet traceroute -P tcp -p 445 host 445, dann 446, dann 447, und bei Hop 10 fragst du nach einem Port, von dem nie jemand gehört hat. Du willst auch -e, was die Man-Page firewall evasion mode nennt und was eigentlich nur „halt den Port still“ heißt:\nsudo traceroute -P tcp -e -p 445 example.net # macOS, FreeBSD Auf Linux tut schlichtes -p dasselbe für die voreingestellte UDP-Methode, und du brauchst -U -p für einen konstanten UDP-Port. Für TCP ist -T -p schon konstant — die Man-Page ist ausdrücklich, dass „for TCP and others specifies just the (constant) destination port to connect“.\nsudo traceroute -T -p 445 example.net # Linux sudo traceroute -U -p 53 example.net # Linux, UDP/53 specifically Auf Solaris und NetBSD gibt es überhaupt keinen Weg, den Port festzunageln, und auf Solaris ist -P eine Pause in Sekunden, also läuft eine kopierte Linux-Befehlszeile ohne Fehler und misst nichts von dem, wonach du gefragt hast. Solaris hat auch keinen TCP-Probe-Modus. Das ist der Fall, in dem du das Skript willst.\nRedox ist der Ausreißer und einen Satz wert, weil ich die Frage erwarte. Sein ganzes Netzwerk-Toolkit ist netutils — dns, ifconfig, nc, ping, telnetd, wget. Kein Traceroute, kein tcpdump, nichts zum Aufzeichnen. Wenn eine Redox-Kiste das eine Ende des Problems ist, miss vom anderen Ende und richte den Lauf auf sie.\nmtr verdient auch eine Erwähnung, weil es den Wiederhol-und-Mittel-Teil macht, den die Tabellen oben dich von Hand tun lassen:\nsudo mtr -T -P 445 --report --report-cycles 20 example.net Lass das gegen den scheiternden Port laufen und noch einmal gegen einen funktionierenden, nebeneinander. Dieselbe Methode, hübschere Ausgabe.\nNichts davon funktioniert, wenn jemand ICMP blockiert Jede Messung in diesem Beitrag besteht aus ICMP-Fehlern, die zu mir zurückreisen. Blockier die, und die ganze Diagnose wird dunkel — und eine Menge anderes auch.\nICMP pauschal zu blockieren wird mancherorts immer noch als Sicherheitshaltung behandelt. Verteidigbar ist sie seit den 1990ern nicht mehr. Die Angriffe, die sie stoppen soll, waren Ping of Death und Smurf, beide in den Stacks behoben statt am Rand, und beide behoben, bevor manche der Ingenieure, die den Rat noch wiederholen, geboren waren. Was pauschales Blockieren heute stoppt, ist Diagnose. Sonst nichts.\nRFC 1812 lässt an dem Punkt keinen Raum für Interpretation: Time Exceeded ist ein MUST, und der Standard nennt als Grund, dass Traceroute davon abhängt. Verwirf es, und du hast ein Werkzeug kaputtgemacht, das das eigene Router-Anforderungsdokument des Internets als Rechtfertigung für die Existenz der Nachricht benennt.\nPath MTU Discovery ist die teure. Sie braucht ICMP 3/4, fragmentation needed, zurück zum Absender. Filter das, und du bekommst den Fehler, den jeder Netzwerk-Ingenieur mindestens einmal gejagt hat, den, bei dem der Handshake fertig wird und kleine Übertragungen klappen und alles, was ein volles Paket trägt, für immer hängt. SSH verbindet und scp stockt. Die Seite lädt und das Bild kommt nie an. Nichts in den Logs. Nichts, wonach man greppen könnte.\nAuf IPv6 hört es auf, Geschmackssache zu sein. RFC 4890 §4.3.1 listet die Nachrichten, die eine Firewall nicht verwerfen darf:\nDestination Unreachable (Type 1) - All codes Packet Too Big (Type 2) Time Exceeded (Type 3) - Code 0 only Parameter Problem (Type 4) - Codes 1 and 2 only und zu Packet Too Big ist es unverblümt über die Folge: „Effectively, parts of the Internet will become inaccessible.“ IPv6-Router fragmentieren nicht. Wenn Packet Too Big den Absender nicht erreicht, gibt es keinen Erholungspfad.\nDie Kontrolle ist ein Rate-Limit, kein Drop. Erlaube eingehend Typ 3 und Typ 11, zähl sie, deckle sie bei so etwas wie hundert pro Sekunde, logge, was den Deckel überschreitet, und du hast die Diagnose behalten, Path MTU Discovery am Laufen gehalten und jedes bisschen des Schutzes behalten, den die pauschale Regel überhaupt zu bieten schien. Zu beschränken, wie viel von etwas du annimmst, ist eine Kontrolle. Alles davon abzulehnen und das Härtung zu nennen, ist bloß, sich der Messung zu verweigern.\nFür alle, die einen MSP betreiben: Wenn die Leitung deines Kunden ICMP-Fehler verwirft, hast du ihm die Fähigkeit genommen, zu beweisen, in welchem Netz ein Fehler steckt — und dir selbst auch. Wenn das nächste Mal ein Fehler zwischen zwei Providern sitzt, die beide sagen, es sei sauber, ist das die Rechnung für die Policy.\nAußer Echo. Das verwerfe. Alles oben handelt von ICMP-Fehlern. Echo ist ein anderes Tier, und es ist der eine Teil des Protokolls, den ich am Rand von der Leitung nehmen würde.\nSieh dir an, was der Standard von ihm verlangt. In IPv4 sagt RFC 792 über einen Echo-Request, dass „the data received in the echo message must be returned in the echo reply message“. IPv6 ist noch unverblümter — RFC 4443 definiert das Feld als „zero or more octets of arbitrary data“ und verlangt dann, dass es „MUST be returned entirely and unmodified in the ICMPv6 Echo Reply message“.\nLies das als Angreifer statt als Betreiber. Der Standard verpflichtet jeden Host auf der Erde, einen Block Bytes deiner Wahl anzunehmen und ihn dir direkt zurückzureichen. Das ist kein Nebeneffekt. Es ist ein vorgeschriebener, bidirektionaler Kanal für beliebige Nutzlast, der über ein Protokoll läuft, das die meisten Firewalls ohne Prüfung durchlassen und das die meiste Protokollierung als Paketzahl statt als Inhalt festhält.\nLeute bauen seit dreißig Jahren Tunnel darauf. Loki tat es 1996 in Phrack 49. Ptunnel trägt eine volle TCP-Sitzung in Ping und ist seit zwei Jahrzehnten nur ein Paket entfernt. Wenn deine Egress-Policy „alles blockieren, ICMP erlauben, weil das Netzwerk-Team es braucht“ ist, hast du keine Egress-Policy. Du hast ein VPN mit Extra-Schritten, und der Verkehr geht hinaus und sieht aus wie jemand, der testet, ob das Internet läuft.\nRFC 4890 widerspricht mir, und es ist es wert, das klar zu sagen, statt nur die Hälfte zu zitieren, die passt. §4.3.1 setzt Echo Request und Echo Response in dieselbe Nicht-verwerfen-Liste wie die Fehler. Dann lies die Begründung, die es gibt:\nFor Teredo tunneling [RFC4380] to IPv6 nodes on the site to be possible, it is essential that the connectivity checking messages are allowed through the firewall.\nDer angegebene Grund, Echo offen zu halten, ist, dass jemand damit einen Tunnel durch deine Firewall bauen muss. Das ist mein Argument, aufgeschrieben von den Leuten, die den Gegenstandpunkt vertreten.\nDie Policy ist also schmal, nicht pauschal:\n# transit rules. permit the errors, drop the ping ip protocol icmp icmp type { destination-unreachable, time-exceeded, parameter-problem } \\ limit rate 100/second accept ip protocol icmp icmp type { echo-request, echo-reply } drop ip6 nexthdr ipv6-icmp icmpv6 type { destination-unreachable, packet-too-big, \\ time-exceeded, parameter-problem } limit rate 100/second accept ip6 nexthdr ipv6-icmp icmpv6 type { echo-request, echo-reply } drop Auf IPv6, trag dieses Muster nicht auf eine Link-Local- oder Host-Chain, ohne Neighbour Discovery zu behalten. Die Typen 133 bis 137 — nd-router-solicit bis nd-redirect — sind, wie IPv6 die Aufgabe erledigt, die ARP in IPv4 erledigt. Verwirf die, und das Segment hört innerhalb von Minuten auf zu funktionieren, und es sieht nicht wie ein Firewall-Fehler aus. Filter Echo am Rand, nicht auf der Leitung zwischen einem Host und seinem eigenen Router.\nWas kostet dich das? ping über die Grenze, und sonst nichts. Alles in diesem Beitrag funktioniert weiter, denn nicht eine Messung hier sendet einen Echo-Request. hopfind.py läuft TCP und UDP und liest die Fehler, die zurückkommen; traceroute -T und -U tun dasselbe. Path MTU Discovery braucht Packet Too Big, was ein Fehler ist. Der Rückwärts-TTL-Trick funktioniert auf jeder Antwort, und ein TCP-Handshake gibt dir eine. Das Einzige, was du verlierst, ist das am wenigsten aussagekräftige Werkzeug im Kasten, und dieser ganze Beitrag ist ein Argument dafür, warum bei ping aufzuhören überhaupt das Problem ist.\nMeine eigene Leitung tut schon genau das, obwohl ich bezweifle, dass es Absicht war. ping zu meinem Standard-Gateway bekommt 100 % Verlust, und ICMP Time Exceeded von genau diesem Gateway kommt in 0,3 ms zurück — wie jeder Trace in diesem Beitrag zeigt. Echo zu, Fehler offen. Wer auch immer diese Firmware ausgeliefert hat, hatte die richtige Antwort, und ich fand nur beim Nachsehen heraus, dass er sie hatte.\nDieselbe Regel, einmal geschrieben Hier der Fehler, den ich in meinem eigenen Haus nicht zu finden erwartete. Ein öffentlicher DNS-Resolver, auf TCP/443 über beide Familien gelaufen, Minuten auseinander.\n$ python3 hopfind.py 192.0.2.53 443 --max 10 walking to 192.0.2.53 TCP/443 hop limit 1-10 1 * 2 * 3 * 4 * 5 * 6 * 7 * 8 * 9 * 10 * Verdict: nothing answered at all, not even the first hop. Gar nichts. Nicht ein Hop. Mein eigener Router meldete nicht einmal den Ablauf, den er erzeugt haben muss, denselben Ablauf, den er in 0,3 ms für jeden anderen Lauf in diesem Beitrag meldete — der Drop passiert also bei Hop 1, bevor die Hop-Limit-Prüfung je läuft, und Hop 1 ist meiner.\nDer Pfad ist in Ordnung, was dasselbe Ziel auf UDP beweist:\n$ python3 hopfind.py 192.0.2.53 53 --proto udp --max 10 1 198.51.100.254 0.3 ms ICMP 11/0 time exceeded in-transit 2 198.51.100.133 5.4 ms ICMP 11/0 time exceeded in-transit 3 * 4 198.51.100.167 14.5 ms ICMP 11/0 time exceeded in-transit 5 203.0.113.50 6.3 ms ICMP 11/0 time exceeded in-transit 6 203.0.113.174 5.7 ms ICMP 11/0 time exceeded in-transit 7 203.0.113.201 6.4 ms ICMP 11/0 time exceeded in-transit 8 * Sieben Hops sauberer Antworten an dieselbe Adresse. Es ist also nicht das Routing und es ist nicht das Ziel — etwas auf meiner Leitung verwirft TCP zu diesem Host und lässt UDP zu ihm durch.\nDann derselbe Resolver, derselbe Port, über IPv6:\n$ python3 hopfind.py 2001:db8:53::53 443 -6 --max 10 walking to 2001:db8:53::53 TCP/443 hop limit 1-10 1 2001:db8:1:ee:beef:abcd:fec0:2a30 0.5 ms ICMP 3/0 hop limit exceeded in-transit 2 2001:db8:1::15c 24.6 ms ICMP 3/0 hop limit exceeded in-transit 3 * 4 2001:db8:2:200::50 5.5 ms ICMP 3/0 hop limit exceeded in-transit 5 2001:db8:2:2::4 5.7 ms ICMP 3/0 hop limit exceeded in-transit 6 2001:db8:2:991:: 16.6 ms ICMP 3/0 hop limit exceeded in-transit 7 2001:db8:53::53 5.7 ms connected Verdict: TCP/443 is open. It answered at hop 7. Glatt durch. Sieben Hops, kein Drama. Derselbe Dienst, derselbe Port, dieselbe Absicht, und die Regel existiert nur auf einer Adressfamilie.\nWer auch immer diese Regel schrieb, schrieb sie für IPv4 und schrieb nie den Zwilling. Ich habe keine Ahnung, was sie erreichen sollte — meine Vermutung ist irgendetwas darüber, DNS lokal zu halten — aber was auch immer es war, sie erreicht es auf der Hälfte des Verkehrs, solange diese Leitung IPv6 hat. Wenn sie aus einem Grund da war, funktioniert sie nicht. Wenn nicht, sollte sie nicht da sein.\nDas ist die Alltagsversion des Dual-Stack-Problems, und es ist weit häufiger als die Debatten darüber, ob man IPv6 überhaupt ausrollen soll. Zwei Regelwerke. Eins gepflegt.\nDas ganze Skript Keine Abhängigkeiten, keine Installation, nichts als die Standardbibliothek. Python 3.6 oder neuer, und auf Linux gar keine Privilegien.\nDie zwei Klassen sind die ganze Portabilitäts-Geschichte. ErrorQueue ist der Linux-Weg: IP_RECVERR auf dem Socket scharfschalten, und nachdem die Probe scheitert, MSG_ERRQUEUE lesen und die Adresse des Routers aus der sock_extended_err-Struktur ziehen, an die der Kernel sie anhängt. RawIcmp ist überall sonst: einen Raw-ICMP-Socket öffnen, lesen, was ankommt, die Quelladresse vom Paket nehmen. Das erste braucht nichts, das zweite braucht Root, und dem Rest des Programms ist egal, welches ihm gereicht wurde.\nEin Detail ist es wert, hervorgehoben zu werden, weil es der Unterschied zwischen einer richtigen Antwort und einer plausiblen ist. In probe() wird die Error-Queue geleert, bevor SO_ERROR befragt wird. Ein ICMP-Fehler erreicht einen TCP-Socket als schlichter errno — ICMP 3/3 port unreachable kommt als ECONNREFUSED an, genau wie ein echter Reset — also hätte SO_ERROR zuerst zu prüfen den gefälschten SMTP-Reset weiter oben in diesem Beitrag als ehrliche Ablehnung vom fernen Ende gemeldet. Lies zuerst die Queue, und ee_origin sagt dir, dass ein Router gesprochen hat.\n#!/usr/bin/env python3 \u0026#34;\u0026#34;\u0026#34;hopfind - work out how many hops away the thing blocking your port is. Walks the IPv4 TTL, or the IPv6 hop limit, up from 1 and records which router answers at each step - using the protocol and port you actually care about instead of traceroute\u0026#39;s default UDP high ports. Run it twice. Once against something that works, once against the port that does not. The hop where the answers stop is the device dropping you, and the run that works gives you its address. python3 hopfind.py example.net 445 # the port under suspicion python3 hopfind.py example.net 443 # the reference run python3 hopfind.py example.net 53 --proto udp python3 hopfind.py 2001:db8::1 443 -6 On Linux this needs no privileges at all: IP_RECVERR and IPV6_RECVERR hand the ICMP errors back on the ordinary socket that caused them. On macOS, the BSDs and Solaris the errors have to be read off a raw ICMP socket, which means root. Written for https://blogs.damiendye.uk/networking/how-far-away-is-the-firewall/ Public domain. Do what you like with it. \u0026#34;\u0026#34;\u0026#34; import argparse import errno import os import select import socket import struct import sys import time # Linux socket options. Absent from the socket module on some builds, so they # are spelled out rather than looked up. IP_RECVERR = 11 IPV6_RECVERR = 25 # ee_origin values from linux/errqueue.h. Anything else means the errno came # from the local stack rather than from a router. SO_EE_ORIGIN_ICMP = 2 SO_EE_ORIGIN_ICMP6 = 3 ICMP_V4 = { (11, 0): \u0026#34;time exceeded in-transit\u0026#34;, (11, 1): \u0026#34;fragment reassembly time exceeded\u0026#34;, (3, 0): \u0026#34;net unreachable\u0026#34;, (3, 1): \u0026#34;host unreachable\u0026#34;, (3, 2): \u0026#34;protocol unreachable\u0026#34;, (3, 3): \u0026#34;port unreachable\u0026#34;, (3, 4): \u0026#34;fragmentation needed\u0026#34;, (3, 9): \u0026#34;net administratively prohibited\u0026#34;, (3, 10): \u0026#34;host administratively prohibited\u0026#34;, (3, 13): \u0026#34;communication administratively prohibited\u0026#34;, (5, 0): \u0026#34;redirect\u0026#34;, } ICMP_V6 = { (3, 0): \u0026#34;hop limit exceeded in-transit\u0026#34;, (3, 1): \u0026#34;fragment reassembly time exceeded\u0026#34;, (1, 0): \u0026#34;no route to destination\u0026#34;, (1, 1): \u0026#34;communication administratively prohibited\u0026#34;, (1, 3): \u0026#34;address unreachable\u0026#34;, (1, 4): \u0026#34;port unreachable\u0026#34;, (2, 0): \u0026#34;packet too big\u0026#34;, } def describe(family, icmp_type, icmp_code): table = ICMP_V4 if family == socket.AF_INET else ICMP_V6 return table.get((icmp_type, icmp_code), \u0026#34;unrecognised\u0026#34;) def is_expiry(family, icmp_type): \u0026#34;\u0026#34;\u0026#34;Was this the router saying \u0026#39;your hop budget ran out here\u0026#39;?\u0026#34;\u0026#34;\u0026#34; return icmp_type == (11 if family == socket.AF_INET else 3) class ErrorQueue: \u0026#34;\u0026#34;\u0026#34;Linux. The kernel reports the ICMP error on the socket that provoked it.\u0026#34;\u0026#34;\u0026#34; def arm(self, sock, family): if family == socket.AF_INET: sock.setsockopt(socket.IPPROTO_IP, IP_RECVERR, 1) else: sock.setsockopt(socket.IPPROTO_IPV6, IPV6_RECVERR, 1) def extra_readers(self): return [] def collect(self, sock, family): try: _, ancillary, _, _ = sock.recvmsg(0, 1024, socket.MSG_ERRQUEUE) except OSError: return None wanted = (socket.IPPROTO_IP, IP_RECVERR) if family == socket.AF_INET \\ else (socket.IPPROTO_IPV6, IPV6_RECVERR) for level, kind, data in ancillary: if (level, kind) != wanted or len(data) \u0026lt; 16: continue # struct sock_extended_err, then the sockaddr of the router that # sent the error - SO_EE_OFFENDER in the kernel headers. _, origin, icmp_type, icmp_code = struct.unpack_from(\u0026#34;=IBBB\u0026#34;, data, 0) if origin not in (SO_EE_ORIGIN_ICMP, SO_EE_ORIGIN_ICMP6): return None addr = None if len(data) \u0026gt;= 24: offender_family, = struct.unpack_from(\u0026#34;=H\u0026#34;, data, 16) if offender_family == socket.AF_INET: addr = socket.inet_ntoa(data[20:24]) elif offender_family == socket.AF_INET6 and len(data) \u0026gt;= 40: addr = socket.inet_ntop(socket.AF_INET6, data[24:40]) return addr, icmp_type, icmp_code return None class RawIcmp: \u0026#34;\u0026#34;\u0026#34;macOS, the BSDs, illumos, Solaris. Read the ICMP off a raw socket, as root.\u0026#34;\u0026#34;\u0026#34; def __init__(self, family): proto = socket.IPPROTO_ICMP if family == socket.AF_INET else socket.IPPROTO_ICMPV6 self.sock = socket.socket(family, socket.SOCK_RAW, proto) self.sock.setblocking(False) def arm(self, sock, family): pass def extra_readers(self): return [self.sock] def collect(self, sock, family): try: packet, peer = self.sock.recvfrom(1500) except OSError: return None if family == socket.AF_INET: # BSD raw sockets hand back the IP header too. header_len = (packet[0] \u0026amp; 0x0F) * 4 packet = packet[header_len:] if len(packet) \u0026lt; 2: return None return peer[0], packet[0], packet[1] def probe(dest, port, proto, family, hop_limit, timeout, listener): \u0026#34;\u0026#34;\u0026#34;One probe at one hop limit. Returns (icmp, socket_state, note).\u0026#34;\u0026#34;\u0026#34; kind = socket.SOCK_STREAM if proto == \u0026#34;tcp\u0026#34; else socket.SOCK_DGRAM sock = socket.socket(family, kind) if family == socket.AF_INET: sock.setsockopt(socket.IPPROTO_IP, socket.IP_TTL, hop_limit) else: sock.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_UNICAST_HOPS, hop_limit) listener.arm(sock, family) sock.setblocking(False) try: if kind == socket.SOCK_DGRAM: sock.connect((dest, port)) sock.send(b\u0026#34;\\x00\u0026#34; * 32) else: try: sock.connect((dest, port)) except BlockingIOError: pass except OSError as exc: sock.close() return None, None, \u0026#34;local error: %s\u0026#34; % exc.strerror readers = [sock] + listener.extra_readers() writers = [] if kind == socket.SOCK_DGRAM else [sock] deadline = time.time() + timeout icmp = state = None while time.time() \u0026lt; deadline: ready_r, ready_w, ready_x = select.select( readers, writers, [sock], max(0.01, deadline - time.time())) if not (ready_r or ready_w or ready_x): continue # Drain the error queue first, always. An ICMP error reaches a TCP # socket as a plain errno, so SO_ERROR on its own cannot tell you # whether a router spoke or the far end did. icmp = listener.collect(sock, family) if icmp: break if ready_w: err = sock.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR) if err == 0: state = \u0026#34;connected\u0026#34; elif err == errno.ECONNREFUSED: state = \u0026#34;TCP reset\u0026#34; else: state = os.strerror(err) break sock.close() if icmp or state: return icmp, state, None return None, None, \u0026#34;no reply\u0026#34; def walk(dest, port, proto, family, first, last, timeout, listener): print(\u0026#34;walking to %s %s/%d hop limit %d-%d\u0026#34; % (dest, proto.upper(), port, first, last)) answered = [] for hop in range(first, last + 1): started = time.time() icmp, state, _ = probe(dest, port, proto, family, hop, timeout, listener) rtt = (time.time() - started) * 1000 if icmp: addr, icmp_type, icmp_code = icmp print(\u0026#34; %2d %-39s %7.1f ms ICMP %d/%d %s\u0026#34; % (hop, addr or \u0026#34;?\u0026#34;, rtt, icmp_type, icmp_code, describe(family, icmp_type, icmp_code))) if is_expiry(family, icmp_type): answered.append((hop, addr)) else: return answered, hop, \u0026#34;icmp-reject\u0026#34;, addr elif state: print(\u0026#34; %2d %-39s %7.1f ms %s\u0026#34; % (hop, dest, rtt, state)) return answered, hop, state, dest else: print(\u0026#34; %2d *\u0026#34; % hop) return answered, None, \u0026#34;silent\u0026#34;, None def main(): parser = argparse.ArgumentParser(description=__doc__.splitlines()[0]) parser.add_argument(\u0026#34;host\u0026#34;) parser.add_argument(\u0026#34;port\u0026#34;, nargs=\u0026#34;?\u0026#34;, type=int, default=443) parser.add_argument(\u0026#34;--proto\u0026#34;, choices=(\u0026#34;tcp\u0026#34;, \u0026#34;udp\u0026#34;), default=\u0026#34;tcp\u0026#34;) parser.add_argument(\u0026#34;--first\u0026#34;, type=int, default=1, help=\u0026#34;hop limit to start at\u0026#34;) parser.add_argument(\u0026#34;--max\u0026#34;, type=int, default=20, help=\u0026#34;hop limit to stop at\u0026#34;) parser.add_argument(\u0026#34;--wait\u0026#34;, type=float, default=2.0, help=\u0026#34;seconds to wait per hop\u0026#34;) parser.add_argument(\u0026#34;-6\u0026#34;, dest=\u0026#34;v6\u0026#34;, action=\u0026#34;store_true\u0026#34;, help=\u0026#34;force IPv6\u0026#34;) parser.add_argument(\u0026#34;-4\u0026#34;, dest=\u0026#34;v4\u0026#34;, action=\u0026#34;store_true\u0026#34;, help=\u0026#34;force IPv4\u0026#34;) args = parser.parse_args() family = socket.AF_INET6 if args.v6 else socket.AF_INET kind = socket.SOCK_STREAM if args.proto == \u0026#34;tcp\u0026#34; else socket.SOCK_DGRAM dest = socket.getaddrinfo(args.host, args.port, family, kind)[0][4][0] if sys.platform.startswith(\u0026#34;linux\u0026#34;): listener = ErrorQueue() else: try: listener = RawIcmp(family) except PermissionError: sys.exit(\u0026#34;%s cannot report ICMP errors on a normal socket, so this \u0026#34; \u0026#34;needs a raw one. Run it as root.\u0026#34; % sys.platform) answered, stop, why, who = walk(dest, args.port, args.proto, family, args.first, args.max, args.wait, listener) what = \u0026#34;%s/%d\u0026#34; % (args.proto.upper(), args.port) print() if why == \u0026#34;connected\u0026#34;: print(\u0026#34;Verdict: %s is open. It answered at hop %d.\u0026#34; % (what, stop)) elif why == \u0026#34;icmp-reject\u0026#34;: print(\u0026#34;Verdict: %s at hop %d is refusing %s on policy, and is honest \u0026#34; \u0026#34;enough to say so.\u0026#34; % (who, stop, what)) elif why == \u0026#34;TCP reset\u0026#34;: print(\u0026#34;Verdict: a reset came back to a probe with a hop limit of %d.\u0026#34; % stop) print(\u0026#34; Nothing more than %s away can have sent it, so check the reply\u0026#34; % (\u0026#34;one hop\u0026#34; if stop == 1 else \u0026#34;%d hops\u0026#34; % stop)) print(\u0026#34; TTL before you believe the host did.\u0026#34;) elif answered: last_hop, last_addr = answered[-1] print(\u0026#34;Verdict: answers stop after hop %d (%s).\u0026#34; % (last_hop, last_addr)) print(\u0026#34; Whatever swallows %s is hop %d.\u0026#34; % (what, last_hop + 1)) print(\u0026#34; Walk a port that works and read off the address at hop %d.\u0026#34; % (last_hop + 1)) else: print(\u0026#34;Verdict: nothing answered at all, not even the first hop. Either the\u0026#34;) print(\u0026#34; first hop is the one dropping you, or the ICMP errors are being\u0026#34;) print(\u0026#34; filtered on the way back. Walk a port that works to tell those\u0026#34;) print(\u0026#34; two apart.\u0026#34;) if __name__ == \u0026#34;__main__\u0026#34;: main() Was dir das nicht sagen kann Die Methode ist billig und über die meisten Dinge ehrlich, aber sie ist kein Topologie-Scanner. Sei im Ticket ehrlich darüber, was du wirklich gemessen hast.\nVerschiedene Fünf-Tupel können verschiedene Pfade nehmen. ECMP hasht die Quell- und Zielports in die Wahl des nächsten Hops, also traversieren zwei Läufe auf zwei verschiedenen Ports gar nicht garantiert dieselben Router, was eins der zwei Dinge ist, die erklären könnten, warum Hop 5 oben einen Lauf beantwortet und beim anderen still bleibt. Wiederhol beide Läufe. Eine Grenze, die sich bewegt, ist unbewiesen.\nMPLS versteckt Hops. Ein Label-Switched-Core kann sich als ein Hop präsentieren, oder als gar keiner. Jede Zählung über den Backbone von jemand anderem ist eine Untergrenze.\nICMP-Erzeugung ist fast überall raten-limitiert. Untersuche schneller, als der Router antwortet, und du fertigst deine eigenen Sterne an. hopfind.py sendet eine Probe pro Hop und wartet; das ist Absicht.\nDer Rückweg muss nicht dem Hinweg entsprechen. Die Hop-Zahl hinaus ist nicht die Hop-Zahl zurück, und Rückwärts-TTL-Arithmetik misst nur die Rückstrecke.\nAnycast heißt, der Host bei Hop N ist vielleicht nicht zweimal dieselbe Kiste. Besonders öffentliche Resolver und CDNs.\nEin fertiger Handshake heißt nicht, dass die Sitzung überlebt. Eine zustandsbehaftete Firewall kann den SYN erlauben und verwerfen, was bei der Prüfung folgt. Wenn die Verbindung öffnet und dann stirbt, ist das das falsche Instrument — geh und zeichne auf.\nDu hast das erste Gerät gefunden, das verwirft, nicht das, zu dem sich jemand bekennt. In einem CGN oder einem Carrier-Netz kann die Adresse bei Hop N+1 eine von mehreren Kisten hinter einer Adresse sein. Es ist trotzdem das Richtige zum Zitieren, weil es eine Tatsache über den Pfad ist.\nWofür es eigentlich da ist Das Zurückspringen beenden. Das ist der ganze Ertrag der Übung.\n„Port 445 ist irgendwo blockiert“ ist eine Einladung, das Ticket zurückzugeben. Das hier nicht:\nTCP/445 zu 192.0.2.4 wird bei Hop 11 still verworfen, Adresse 192.0.2.31. Hop 11 antwortet ICMP Time Exceeded auf TCP/443 auf demselben Pfad in 26 ms und antwortet auf 445 gar nicht, der Drop ist also eine Policy-Entscheidung auf diesem Gerät, kein Routing-Fehler. Zehn Hops davor sind sauber. Viermal über zwanzig Minuten reproduziert, aus einer unprivilegierten Shell, Skript beigefügt.\nDas gibt niemand zurück. Es benennt ein Gerät, sagt, was es tat, sagt, was es nicht tat, und zeigt den Rechenweg. Ob sie es ändern, ist immer noch ihre Entscheidung. Aber die Woche Ping-Pong ist vorbei, und es hat vier Befehle gebraucht.\nAlles darin kam aus einem 8-Bit-Feld, das 1981 als Timer spezifiziert wurde, nie ein einziges Mal als solcher benutzt wurde und leise aus „irgendwo“ eine Adresse macht.\nEs lohnt sich, es lesen zu lernen.\n","permalink":"https://blogs.damiendye.uk/de/networking/how-far-away-is-the-firewall/","summary":"„Port 445 ist irgendwo blockiert“ ist keine Diagnose, und genau darum springen Firewall-Tickets eine Woche lang zwischen dir und deinem Provider hin und her. Jeder Router auf dem Pfad schuldet dir ein ICMP Time Exceeded, wenn dein Hop-Budget aufgebraucht ist, und das macht aus einem Timeout eine Entfernung. Ich bin das TTL auf meiner eigenen Leitung hochgelaufen und fand drei Fehler, von denen ich nichts wusste: einen SMB-Drop elf Hops weit draußen, gefälschte SMTP-Resets einen Hop entfernt und eine IPv4-Regel ohne IPv6-Zwilling.","title":"Die Firewall ist elf Hops entfernt"},{"content":"Es gibt eine Geschichte, die die britische Branche über IPv6 erzählt, und sie geht so. Der Umstieg ist schwer. Die Technik ist alt. Die Kunden fragen nicht danach. Es ist kein Geld damit zu verdienen. Eines Tages, wenn sich der Business Case dreht, kümmern wir uns darum.\nJeder Teil davon ist eine Lüge, die sich die Branche selbst erzählt, damit sie keine Arbeit machen muss.\nIPv6 wurde im Dezember 1995 spezifiziert. Ich kam über das 6bone dazu, das experimentelle Testnetz, das es trug, bevor das echte Internet es wollte, und ich fuhr sowohl den Linux-Stack als auch den Stack von Microsoft Research auf Windows XP, um zu sehen, wie sie sich unterschieden. Meinen Zugang hatte ich von Hurricane Electric.\nDas 6bone wurde am 6. Juni 2006 abgeschaltet, also zog ich zu 6to4, dem automatischen Tunneln, und später zu einem Hurricane-Electric-Tunnel — immer noch kostenlos, und sie routen dir auf Nachfrage ein /48. Natives IPv6 kam 2017 bei mir zu Hause an, als ich den Anbieter zu Zen wechselte.\nFast zwanzig Jahre lang kam mein IPv6 also von einer amerikanischen Transitfirma, die es verschenkte, und nicht von irgendeinem der britischen Provider, die ich bezahlte. Hurricane Electric verteilte geroutete /48 an jeden, der eines wollte. Mein eigener Anbieter wollte mir eine statische IPv4 für einen Fünfer im Monat verkaufen.\nDie Daten sagen den Rest. Die IETF beerdigte das 6bone 2006 und erklärte 6to4s Anycast-Relays im Mai 2015 für überholt, mit der Begründung, der Mechanismus sei „unsuitable for widespread deployment and use in the Internet“. Ich habe zwei offizielle Übergangsmechanismen überlebt, während ich darauf wartete, dass mir ein britischer ISP eine Adresse gibt. An dem Tag, an dem das 6bone abgeschaltet wurde, hatten siebenunddreißig der vierzig britischen Anbieter in der Grafik weiter unten noch nicht einmal eine Zuteilung bei der Registry beantragt. Zweiundzwanzig davon — mehr als die Hälfte — fragten erst 2015 oder später, in dem Jahr, in dem die IETF auch 6to4 aufgab.\nEs ist seit Windows Vista 2007 in jedem Betriebssystem, das irgendwer betreibt, standardmäßig eingeschaltet. Es kostet bei der Registry nichts extra. Der größte ISP, der es in diesem Land je versucht hat, hat die Sache in drei Jahren mit einem Team erledigt, das in einen Besprechungsraum passt, und einen Preis dafür gewonnen.\nDreißig Jahre nach der Spezifikation. Vierzehn Jahre nach dem Tag, an dem das Internet es dauerhaft eingeschaltet hat. Und die Antwort in diesem Land war, das Internet absichtlich kaputtzumachen, das kaputte Stück in mehr Maschinerie zu wickeln und dem Kunden die Unannehmlichkeit in Rechnung zu stellen.\nDas ist kein Kostenproblem. Es ist ein Keine-Lust-Problem, und es läuft seit zwanzig Jahren.\nWas ich gemessen habe, und wie Alles unten ist entweder die Arbeit von jemand anderem, verlinkt, oder eine Zahl, die ich selbst erzeugt habe. Wo sie meine ist, liegt das Skript, das sie gezählt hat, im Download unten, so wie es lief. Die eine Ausnahme sind die Adress-Summen, und wie die berechnet werden, erkläre ich in den Vorbehalten. Vier öffentliche Quellen, alle kostenlos: die Delegierungsdateien der Registries, der Routingtabellen-Dump von RIPE, die RIPE-Datenbank und das DNS. Wo ich eine Stichprobe genommen habe statt alles zu messen, sage ich das.\nDie Routing-Zahlen kommen aus zwei Sätzen öffentlicher Dateien.\nDie ersten sind die Delegierungsdateien, eine je regionaler Registry, die jeden Adressblock und jede AS-Nummer auflisten, die diese Registry vergeben hat, das Land, für das sie registriert sind, und eine undurchsichtige Kennung für die Organisation, die sie hält. Die von RIPE deckt Europa und den Nahen Osten ab, und sie ist die, auf die es fürs UK ankommt — aber ein paar Dutzend im UK registrierte AS-Nummern sitzen stattdessen in den Dateien von ARIN und APNIC, und der Vergleich weiter unten braucht sie alle. Meine wurden am 26. und 27. August 2026 erzeugt.\nDie zweite ist der Dump der globalen Routingtabelle vom Routing Information Service der RIPE, der jedes Präfix im BGP und die AS-Nummer auflistet, die es ankündigt. IPv4 und IPv6 kommen als getrennte Dateien. Meiner wurde am 27. August 2026 um 18:06 UTC erzeugt.\nLeg die zusammen und du kannst eine Frage beantworten, die niemand in der britischen Branche laut gestellt haben will: wie viele der Netze, die dieses Land registriert hat, haben IPv6 tatsächlich eingeschaltet?\n\u0026#8615; Die Skripte, fertig zum Ausführen ipv6-uk-2026-scripts.zip · 10 kB Nimm die für GB registrierten AS-Nummern aus den Delegierungsdateien, nimm jede AS-Nummer, die aus den RIS-Dumps ein Präfix originiert, und comm die zwei Listen je Adressfamilie gegeneinander. Das ergibt die erste Tabelle unten. Eine Falle, die es zu benennen lohnt: lexikalisch sortieren, nicht mit sort -n. comm vergleicht Zeichenketten, und numerisch sortierte Eingaben geben dir stillschweigend die falsche Antwort statt eines Fehlers, den du bemerken würdest.\nTausch GB gegen einen beliebigen anderen Ländercode und du bekommst die Zeile dieses Landes in der Vergleichstabelle weiter unten. 05-country-row.sh tut genau das.\nDie Zahlen auf Organisationsebene nutzen das achte Feld, das der undurchsichtige Handle der Registry für das Konto ist, das die jeweilige Ressource hält. Die bleiben allein auf der RIPE-Datei — die Handles sind lokal zu jeder Registry, fünf davon aneinanderzuhängen würde also dieselbe Firma zweimal zählen statt sie zusammenzuführen. Britische Organisationen sind RIPE-Mitglieder, also sind sie bei RIPE. So viele halten eine AS-Nummer und überhaupt kein IPv6:\n03-org-no-ipv6.sh zählt sie. Und 04-silent-holders.py ist das, worauf es am meisten ankommt. Die Organisationen, die IPv6 halten, im BGP aktiv sind und nichts davon ankündigen.\nVier Vorbehalte vor den Zahlen, denn sie sind wichtig, und ich sage sie lieber selbst, als dass man sie mir vorhält.\nDie Organisations-Handles sind pro Registry-Konto, eine Firma mit mehreren Konten zählt also mehrfach.\nEin IPv6-Präfix im BGP anzukündigen ist nicht dasselbe wie einem Kunden IPv6 zu geben. Es ist der Boden, nicht die Decke. Ein Netz, das nichts ankündigt, hat es mit Sicherheit nicht ausgerollt. Ein Netz, das etwas ankündigt, könnte trotzdem darauf sitzen.\nDie Adress-Summen fassen überlappende Präfixe zusammen. Ein Netz, das ein /16 zusammen mit vier /17 daraus ankündigt, kündigt 65.536 Adressen an, nicht 196.608, und die Präfixe naiv zu zählen bläht die großen Halter um das Zwei- bis Dreifache auf. Ich benutze Pythons ipaddress.collapse_addresses vor dem Summieren.\nDie Liste von fünfzig Websites weiter unten ist eine von Hand gewählte Stichprobe, keine Messung des ganzen Landes. Andere fünfzig ergäben einen anderen Anteil. Sie illustriert ein Muster, sie beweist keinen Anteil, und ich nenne die, über die ich rede, unterwegs beim Namen.\nDie ersten beiden davon machen die Routing-Zahlen freundlicher zur Branche, als die Wahrheit es ist.\nDie Zählung Britische AS-Nummern, und wie viele IPv6 führen Britische Netze in der globalen Routingtabelle, 27. August 2026 Quelle: RIPE-NCC-Delegierungsdatei und RIPE-RIS-Routingtabellen-Dump auf britische Firmen registriert 3.106 in der Routingtabelle sichtbar 2.248 kündigen IPv4 an 2.078 kündigen IPv6 an 1.048 IPv4 und überhaupt kein IPv6 1.200 57,7 % der aktiven britischen Netze Von diesen 1.200 halten\u0026#160;463 IPv6-Raum, den die Registry ihnen schon ausgegeben hat, und haben nie ein einziges Präfix davon angekündigt. Weitere 1.113 britische Organisationen mit einer AS-Nummer haben nie überhaupt nach IPv6 gefragt, obwohl es zusätzlich zur Mitgliedschaft, die sie schon zahlen, nichts kostet. Jede AS-Nummer, die auf eine britische Organisation registriert ist, gemessen gegen die globale Routingtabelle am 27. August 2026. Die Lücke rechts ist das ganze Argument: 1.200 britische Netze sind im Internet aktiv und haben überhaupt kein IPv6, und 463 davon halten von der Registry ausgegebenen IPv6-Raum, den sie nie angekündigt haben. AS-Nummern, die auf britische Organisationen registriert sind 3.106 In der globalen Routingtabelle sichtbar 2.248 Kündigen IPv4 an 2.078 Kündigen IPv6 an 1.048 Kündigen IPv4 und kein IPv6 an 1.200 — 57,7 % Knapp sechs von zehn aktiven britischen Netzen führen überhaupt kein IPv6. Nicht teilweise. Nicht hinter einem Schalter. Nicht im Labor. Kein einziges Präfix.\nJetzt der Teil, der das Kostenargument endgültig beendet.\nVon den 2.363 britischen Organisationen, die eine AS-Nummer halten, halten 1.113 — 47,1 % — überhaupt keine IPv6-Zuteilung. Sie haben die Registry nie danach gefragt.\nEine RIPE-NCC-Mitgliedschaft kostet 1.800 Euro im Jahr für 2026, pauschal, und diese Gebühr deckt deine Zuteilungen ab. Ein IPv6-/29 gibt dir 524.288 Subnetze von der Größe des gesamten IPv4-Internets. Es ist kostenlos bei einer Mitgliedschaft, die diese Organisationen ohnehin schon bezahlen, und es kommt in ein paar Tagen an.\nDie Hälfte von ihnen hat nie das Formular ausgefüllt.\nUnd von denen, die es taten, halten 463 britische Organisationen IPv6-Raum, kündigen der Welt jeden Tag IPv4 an und kündigen überhaupt kein IPv6 an. Das sind 44,7 % der britischen IPv6-Halter, die im BGP aktiv sind.\nLies das noch einmal, denn es ist der ganze Beitrag in einem Satz. Sie haben die Adressen beantragt. Sie haben die Adressen bekommen. Sie haben sie in eine Tabelle geschrieben. Dann konnte sich niemand aufraffen, sie in einen Router zu tippen.\nDas kannst du nicht mit Geld erklären. Niemand hat etwas ausgegeben. Es gibt keine Rechnung, keine Beschaffung, keinen Business Case, keinen Investitionsantrag. Es gibt ein kostenloses Ding, das in einem Registry-Konto liegt, und eine Technikabteilung, die seit vierzehn Jahren das Ticket nicht aufgemacht hat.\nWer auf dieser Liste steht Das sind die größten britischen Netze, die IPv4 und kein IPv6 ankündigen, nach der Menge Adressraum, die sie tatsächlich ankündigen, am 27. August 2026. Die Namen kommen aus der RIPE-Datenbank, die dir sagt, wer irgendeines davon hält:\ncurl -s https://rest.db.ripe.net/ripe/aut-num/AS15914.json \\ | python3 -c \u0026#39;import sys,json; a=json.load(sys.stdin)[\u0026#34;objects\u0026#34;][\u0026#34;object\u0026#34;][0][\u0026#34;attributes\u0026#34;][\u0026#34;attribute\u0026#34;]; print(next(x[\u0026#34;value\u0026#34;] for x in a if x[\u0026#34;name\u0026#34;]==\u0026#34;org\u0026#34;))\u0026#39; Die größten britischen Netze ohne IPv6 Die größten britischen Netze mit IPv4 und ohne IPv6, 27. August 2026 Im BGP angekündigte IPv4-Adressen, überlappende Präfixe zusammengefasst. Namen aus der RIPE-Datenbank. 0k 50k 100k 150k 200k Vodafone Limited AS25310 229.376 Nationwide Building Society AS8698 131.072 British Airways plc AS15914 131.072 Convergence Group (Metronet) AS42973 94.976 Rackspace Ltd AS24867 86.016 Lloyds Banking Group AS49758 81.920 QinetiQ Limited AS24775 69.632 Barclays Bank plc AS12701 68.608 MUFG Securities EMEA AS8651 65.792 Universität Warwick AS201773 65.792 NatWest Markets plc AS21054 65.536 PricewaterhouseCoopers Services AS21296 65.536 London Borough of Hackney AS39400 65.536 Wireless Logic Limited AS51320 39.424 Zusammen sitzen die britischen Netze ohne IPv6 auf\u0026#160;4.232.232 IPv4-Adressen. Barclays hält 141.228.0.0/16 seit August 1990. Die vierzehn größten britischen Netze, die am 27. August 2026 IPv4 und kein IPv6 ankündigen, nach dem Adressraum, den sie tatsächlich ankündigen. Überlappende Präfixe vor dem Summieren zusammengefasst. Schau dir die Liste an und versuch, das Wort „Kostenhürde“ zu sagen, ohne zu lachen.\nVier der Clearingbanken. Eine weltweite Wirtschaftsprüfungsgesellschaft, deren gesamtes Produkt darin besteht, anderen zu sagen, wie sie ihre Angelegenheiten führen sollen. Ein Rüstungstechnologiekonzern. Ein Hosting-Anbieter, dessen Kunden ihn dafür bezahlen, dass er das weiß. Ein Konnektivitätsanbieter fürs Internet der Dinge, der SIM-Karten verkauft, ohne IPv6.\nZusammen sitzen die britischen Netze, die kein IPv6 ankündigen, auf 4.232.232 IPv4-Adressen. Der Transfermarkt lag im ersten Halbjahr 2026 im Schnitt bei 20,04 Dollar je Adresse, das ist also ein Bestand im Wert von irgendwo nördlich von achtzig Millionen Dollar. Was der eigentliche Grund ist, warum sich keiner von ihnen bewegt hat: sie sind adressreich, die Knappheit ist also das Problem von jemand anderem, und die langfristige Installation des Internets ist niemandes Aufgabe im Besonderen.\nDas ist keine Strategie. Das ist Bequemlichkeit.\nDie Delegierungsdatei trägt das Datum, an dem jeder Block vergeben wurde, du kannst also genau sehen, wie bequem:\ngrep -E \u0026#39;\\|ipv4\\|(141\\.228|155\\.131|155\\.136|161\\.2)\\.0\\.0\\|\u0026#39; \\ delegated-ripencc-extended-latest | cut -d\u0026#39;|\u0026#39; -f4,5,6 Barclays hält 141.228.0.0/16 seit dem 6. August 1990. Nationwide und NatWest nahmen ihre im November 1991, vier Tage auseinander. British Airways bekam 161.2.0.0/16 im April 1992. Das sind Class-B-Blöcke aus der Zeit vor dem Web, vergeben, als Adressen kostenlos waren und niemand zählte.\nAlle, die danach kamen, zahlen dafür. AWS begann am 1. Februar 2024, 0,005 Dollar pro Stunde für jede öffentliche IPv4-Adresse zu berechnen — 43,80 Dollar im Jahr, je Adresse — und sagte klipp und klar, warum: die Kosten, eine zu beschaffen, „has risen more than 300% over the past 5 years.“ Die Knappheit ist real und sie hat einen Preis. Sie wird nur nicht von den Leuten bezahlt, die vier Millionen Adressen halten, die sie 1991 für nowt bekommen haben.\nWie wir gegen Länder wie uns dastehen Zwei Zahlen je Land. Die erste ist der Anteil seiner Menschen, die Google über natives IPv6 erreichen, das ist Googles Messung vom 25. August 2026. Die zweite ist der Anteil seiner aktiven Netze, die ein IPv6-Präfix ankündigen, das ist meine, aus denselben Dateien wie oben. Ich habe es auf entwickelte Volkswirtschaften beschränkt. Uns mit Ländern zu vergleichen, die das Internet spät bekamen, sagt nichts über uns. Nach Menschen sortiert.\nLand Nutzer auf IPv6 Netze mit IPv6 Aktive Netze Frankreich 85,6 % 48,5 % 1.368 Deutschland 76,6 % 63,9 % 2.291 Belgien 72,8 % 45,8 % 273 Vereinigte Staaten 56,6 % 25,9 % 18.453 Japan 56,1 % 56,4 % 721 Vereinigtes Königreich 53,7 % 42,3 % 2.078 Norwegen 52,6 % 66,9 % 278 Niederlande 51,9 % 61,8 % 1.023 Kanada 43,6 % 33,1 % 1.578 Irland 38,1 % 41,5 % 195 Australien 37,2 % 26,3 % 1.652 Schweden 36,1 % 53,6 % 642 Südkorea 18,1 % 5,3 % 916 Italien 17,6 % 35,8 % 1.078 Spanien 13,3 % 26,7 % 934 Sechster von fünfzehn. Frankreich hat zwei Drittel mehr seiner Menschen auf IPv6 als wir, aus derselben europäischen Lieferkette, bei denselben Geräteherstellern, mit denselben Kunden, die ihnen sagen, dass niemand danach fragt. Deutschland ist bei den Nutzern dreiundzwanzig Punkte vor uns und bei den Netzen zweiundzwanzig.\nDie zwei Prozentspalten stimmen nicht miteinander überein, und die Uneinigkeit ist die Geschichte.\nNutzer auf IPv6 gegen Netze mit IPv6, fünfzehn entwickelte Volkswirtschaften Menschen auf IPv6, gegen Netze, die IPv6 führen Googles Nutzermessung, 25. August 2026, gegen meine Zählung aktiver Netze, die ein IPv6-Präfix ankündigen, 27. August 2026. Anteil der Menschen Anteil der Netze Frankreich 85,6 % 48,5 % Deutschland 76,6 % 63,9 % Belgien 72,8 % 45,8 % USA 56,6 % 25,9 % Japan 56,1 % 56,4 % Ver. Königreich 53,7 % 42,3 % Norwegen 52,6 % 66,9 % Niederlande 51,9 % 61,8 % Kanada 43,6 % 33,1 % Irland 38,1 % 41,5 % Australien 37,2 % 26,3 % Schweden 36,1 % 53,6 % Südkorea 18,1 % 5,3 % Italien 17,6 % 35,8 % Spanien 13,3 % 26,7 % 0 % 20 % 40 % 60 % 80 % 100 % Ein langer blauer Balken über einem kurzen pinken heißt, drei oder vier Carrier haben die Arbeit gemacht und der Rest des Landes nicht. Frankreich, Belgien, die USA und das UK haben diese Form. Norwegen, Schweden und Japan nicht. Dieselben fünfzehn Länder auf beiden Maßen, sortiert nach dem Anteil der Menschen, die IPv6 nutzen. Wo der Netzbalken viel kürzer ist als der Nutzerbalken, tragen ein paar große Carrier das Land und sonst hat sich niemand bemüht. Das ist die Form der Vereinigten Staaten, Belgiens, Frankreichs — und des Vereinigten Königreichs. Der Nutzerprozentsatz eines Landes wird von drei oder vier Firmen gesetzt. Der Netzprozentsatz wird von allen anderen gesetzt. Wenn der erste hoch und der zweite niedrig ist, heißt das, die großen Zugangsnetze haben die Arbeit gemacht und der Rest des Landes ist auf ihnen mitgefahren.\nDie Vereinigten Staaten sind der klarste Fall: 56,6 % ihrer Menschen sind auf IPv6 und nur 25,9 % ihrer Netze. Die Kabel- und Mobilfunkanbieter tragen fast jeden. Die anderen achtzehntausend amerikanischen Netze haben nichts getan.\nUnserer ist derselbe Trick mit kleineren Zahlen — 53,7 % der Nutzer gegen 42,3 % der Netze. Diese 53,7 % sind keine nationale Leistung. Sie sind Sky und BT und ein Rundungsfehler von allen anderen.\nNorwegen und Schweden sind die ehrliche Gegenform: weniger Nutzer auf IPv6 als bei uns, mehr Netze, die es führen. Mehr ihrer Branche hat die Arbeit tatsächlich gemacht, und es sind die Endkunden-ISPs, die hinterherhinken, nicht das Gewerbe.\nUnd eine Zeile verdient einen genaueren Blick, denn sie ist die, nach der Leute greifen, wenn sie sich über uns besser fühlen wollen.\nSüdkorea ist das schlechteste Land auf dieser Liste, mit Abstand. Von 916 aktiven koreanischen Netzen kündigen 61 IPv6 an. Einundsechzig.\nEines der schnellsten Breitbandnetze der Erde, eine Chipindustrie, die Geld druckt, und 94,7 % seiner Netze haben es nie eingeschaltet. Die drei großen Carrier — KT, SK Broadband und LG U+ — kündigen es alle an, weshalb 18,1 % der koreanischen Nutzer es haben. Die anderen achthundertfünfzig Netze haben nowt getan.\nWas auch immer dort die Ausrede ist, es ist nicht Geld, es ist nicht Können, und es ist nicht der Zustand der Glasfaser.\nZwanzig Jahre Dinge anschrauben Hier ist, was die Branche gebaut hat, statt die Adressen einzutippen.\nAls die Adressen knapp wurden, war die Antwort Carrier-Grade NAT: setz hunderte Kunden hinter eine öffentliche IPv4-Adresse und übersetze dazwischen. Alles unten existiert, um das überlebbar zu machen, und jedes einzelne dieser Dokumente ist ein Stück Ingenieursarbeit, das jemand lieber gemacht hat, als IPv6 auszurollen.\nAnbau Wofür er da ist RFC 6598 (2012) Verbrennt ein ganzes /10 — vier Millionen Adressen — als „shared address space“, damit die Notlösung gegen die Knappheit ihre eigenen Adressen bekommt RFC 6333 (2011) DS-Lite: IPv4 über das IPv6-Netz tunneln, das du gebaut, dem Kunden aber nicht gegeben hast RFC 6877 (2013) 464XLAT: IPv4 nach IPv6 und wieder zurück übersetzen, auf derselben Reise RFC 6888 (2013) Die Liste der Anforderungen, die ein Carrier-Grade NAT erfüllen muss, um nicht gefährlich zu sein RFC 7021 (2013) Eine vollständige Untersuchung der Anwendungen, die Carrier-Grade NAT kaputt macht RFC 7422 (2014) Deterministische Adressabbildung, erfunden allein dazu, den Provider nicht am Protokollvolumen bankrottgehen zu lassen RFC 7597 / 7599 (2015) MAP-E und MAP-T: zwei weitere Wege, IPv4 über IPv6 zu tragen, ohne zuzugeben, dass man IPv6 hat Zwanzig Jahre Notlösungen gegen die eine Änderung, die sie ersetzen Was wir stattdessen gebaut haben, und wofür es stattdessen war IPv6 vermeiden Shared Address Space — ein /10 verbrannt RFC 6598, 2012 DS-Lite — IPv4 über einen IPv6-Kern tunneln RFC 6333, 2011 464XLAT — aus IPv4 heraus und zurück RFC 6877, 2013 Regeln für überlebbares Carrier-Grade NAT RFC 6888, 2013 Studie: welche Anwendungen es kaputt macht RFC 7021, 2013 Deterministische Abbildung, weniger Logs RFC 7422, 2014 MAP-E und MAP-T — wieder IPv4 über IPv6 RFC 7597/9, 2015 Dazu die NAT-Ebene selbst: Sitzungstabellen, Portblock- Zuteilung, Application Gateways, Failover, Kapazitäts- planung, eine Logpipeline — und ein Vorratsdatengesetz, das die zerstörte Zuordenbarkeit übertünchen soll. IPv6 machen Dual-Stack Eine Adressfamilie mehr, auf dem Routingprotokoll und der Firewall-Policy, die du schon fährst. Keine neue Ebene im Verkehrspfad. Kein Sitzungszustand zu dimensionieren. Keine Logs wegen eines Gesetzes. Kostenlos von der Registry. Beide Spalten sind Ingenieursarbeit, und die linke ist größer. Der Unterschied ist, dass die Arbeit links bei einem Hersteller gekauft werden kann und die rechts von den Leuten verstanden werden muss, denen das Netz gehört. Zwei Jahrzehnte Standardisierungsarbeit, Hardware und Protokollierung, alles im Dienst davon, das Ding rechts nicht zu tun. Dual-Stack ist eine Adressfamilie, hinzugefügt neben der, die du ohnehin fährst. Alles links existiert, um das zu vermeiden. Schau dir die Form davon an. Jeder Punkt auf der Liste ist schwerer als Dual-Stack. IPv4 in IPv6 zu tunneln ist strikt mehr Arbeit als IPv6 zu routen, denn du musst das IPv6 ohnehin routen, um den Tunnel zu tragen. Zwischen Familien zu übersetzen ist mehr Arbeit als nicht zu übersetzen. Ein Carrier-Grade NAT ist eine zustandsbehaftete Kiste mitten in deinem Netz, mit Kapazitätsplanung, Failover, Sitzungstabellen, Portblock-Zuteilung, Application-Layer-Gateways für die Protokolle, die es kaputt macht, und einer Protokollierungspipeline, dimensioniert für eine gesetzliche Pflicht.\nDual-Stack ist eine Adressfamilie, ein Routingprotokoll, das du schon fährst, und eine Firewall-Policy, die du schon geschrieben hast.\nDie Branche hat sich diese zwei Optionen angesehen und zwanzig Jahre lang die teure genommen, weil man die teure kaufen konnte und die billige verstehen musste. Eine Kiste zu kaufen ist eine Beschaffungsübung. IPv6 einzuschalten heißt, dass jemand im Haus wissen muss, wie das Netz funktioniert.\nWas das tatsächlich kaputt macht Für alle, die das für Ästhetik halten, hier ist, was eine geteilte Adresse deine Nutzer kostet, in der Reihenfolge, in der sie dich deswegen anrufen.\nNichts kommt von außen rein. Kein Port-Forwarding, also nichts selbst gehostet, keine Spielkonsole als Host, kein Site-to-Site-VPN ohne Relay, keine Überwachungskamera ohne Hersteller-Cloud, kein Fernzugriff auf das Ding am anderen Standort. Jedes davon wird durch einen Rendezvous-Dienst eines Dritten ersetzt, also noch eine Firma, die deine Daten hält, weil dein Anbieter dir keine Adresse geben wollte.\nDu erbst den Ruf von Fremden. Teil dir eine Adresse mit ein paar hundert Leuten und du teilst dir ihr Verhalten. Ratenbegrenzungen, CAPTCHAs, Wikipedia-Sperren, Geo-Fehler beim Streaming und Betrugsbewertungen landen bei dir für etwas, das jemand anderes getan hat.\nDie Ports gehen aus. Ein Carrier-Grade NAT hat 65.535 Ports je öffentlicher Adresse und Protokoll, und eine einzige moderne Browsersitzung frisst Dutzende. Überbuch das und der Fehler ist keine saubere Fehlermeldung. Es ist ein langsamer, sporadischer, nicht reproduzierbarer Fehler, der nach allem aussieht außer nach dem, was er ist, und er verbrennt pro Vorfall Tage an Supportzeit.\nJede Notlösung muss für immer gepflegt werden, von Leuten, die diese Zeit für die Lösung hätten aufwenden können.\nUnd dann gibt es das, was aufgehört hat, eine Unannehmlichkeit zu sein, und zu jedermanns Problem wurde. Niemand kann sagen, wer was getan hat.\nDer Anbau, der es bis ins Parlament schaffte Sobald hunderte Kunden sich eine Adresse teilen, identifiziert eine Adresse niemanden mehr. Also kann die Polizei eine IP-Adresse nicht zu einer Person auflösen, und die Antwort darauf war nicht IPv6. Es war Gesetzgebung.\nAbschnitt 21 des Counter-Terrorism and Security Act 2015 änderte das Vorratsdatenregime eigens so, dass der zuständige Minister Anbieter zwingen kann, die zusätzlichen Daten aufzubewahren, die nötig sind, um „to link the unique attributes of a public Internet Protocol (IP) address to the person (or device) using it at any given time.“ Die Erläuterungen sagen unverblümt, warum das nötig war: Anbieter „may share IP addresses between multiple users, and the providers generally have no business purpose for keeping a log of who used each address at a specific point in time.“\nLies das als Ingenieur und nicht als Jurist. Die Branche hat die Zuordenbarkeit kaputt gemacht, um sich Arbeit zu sparen, und das Parlament hat ein Gesetz verabschiedet, das sie verpflichtet, ein Protokollierungssystem zu bauen, um den Schaden zu übertünchen.\nZwei Jahre später sagte Europol es deutlich. Im Oktober 2017 veröffentlichte es einen Aufruf an die Branche, Carrier-Grade NAT nicht mehr zu benutzen, mit Zahlen: 90 % der mobilen Internetanbieter und 50 % der Festnetzanbieter hatten eine Technik übernommen, die sie daran hinderte, ihre eigenen Teilnehmer zu identifizieren. Europols damaliger Direktor sagte, CGN „has created a serious online capability gap in law enforcement efforts to investigate and attribute crime“, und merkte an, es „forces judiciary and law enforcement authorities to investigate many more individuals than would normally be necessary.“\nEuropol sagte auch den leisen Teil. Carrier-Grade NAT „was supposed to be a temporary solution until the transition to IPv6 was completed“. Stattdessen steigerte die Branche seinen Einsatz weiter, während der Ersatz danebenlag, fertig, kostenlos und ignoriert.\nZu den Kosten, IPv6 nicht auszurollen, gehören also: ein Gesetz, eine landesweite Aufbewahrungspflicht, unschuldige Menschen, die in Ermittlungen hineingezogen werden, weil sie sich eine Adresse mit jemandem teilten, der nicht unschuldig war, und eine anhaltende Fähigkeitslücke, die die Polizei als Problem der öffentlichen Sicherheit beschreibt.\nNiemand hat das in den Business Case geschrieben. Es taucht in der Folie „IPv6 hat keinen ROI“ nie auf, denn es wird nicht von denen bezahlt, die es verursacht haben.\nEs versteckt nicht nur Kriminelle. Es hilft ihnen. Das Zuordnungsargument ist das, was die Strafverfolgung vorbringt, und es geht darum, Leute nach der Tat zu fassen. Es gibt ein zweites Argument, das weit seltener gemacht wird und schlimmer ist: Adressteilung schwächt aktiv die Abwehr, die Angriffe überhaupt erst verhindert.\nDas ist nicht meine Analyse. Die IETF veröffentlichte den Katalog in RFC 6269, Issues with IP Address Sharing, im Juni 2011. Das war, bevor das UK den größten Teil des Carrier-Grade NAT ausrollte, das es heute fährt. Ihre klaren Worte: Adressteilung „creates a vector for attack amplification in numerous ways.“\nHier ist, wovor sie warnte, und was tatsächlich kaputtging.\nRatenbegrenzung und Sperren funktionieren nicht mehr. Die Standardabwehr gegen Passwortraten und Credential Stuffing ist, Fehlversuche je Adresse zu zählen und den Übeltäter in die Strafbank zu setzen. Teil diese Adresse zwischen hunderten Leuten und der Zähler misst eine Menschenmenge. RFC 6269 ist unverblümt beim Ergebnis: „In the presence of widespread large-scale address sharing, penalty box solutions to service abuse simply will not work.“ Die fehlgeschlagenen Logins eines Nutzers sperren alle anderen aus, also erhöhen die Betreiber die Schwellen, und die Schwellen zu erhöhen ist genau das, was der Angreifer wollte.\nSperrlisten werden zu Kollateralschaden. Sperr den Spammer und du sperrst die Straße, in der er wohnt. Also hört der vernünftige Betreiber auf zu sperren, und der Missbrauch geht weiter von einer Adresse, die niemand anzufassen wagt.\nInfizierte Maschinen bleiben infiziert. Missbrauchsmeldungen und Malware-Benachrichtigungen kommen als Adresse und Zeitstempel an. Hinter einem CGN ohne Portprotokollierung kann der Anbieter nicht sagen, welcher seiner Kunden den Bot fährt, also erfährt der Kunde es nie und die Infektion bleibt. Schlimmer noch, RFC 6269 nennt das umgekehrte Problem: „someone else\u0026rsquo;s worm can interfere with the ability to access the service for other subscribers sharing the same IP address.“\nAdressbasierte Zugangskontrolle versagt. Jede auf Quelladressen gebaute Freigabeliste lässt jetzt eine Menschenmenge herein statt eines Kunden.\nUnd eine Abwehr wird messbar geschwächt und nicht bloß stumpf. Blinde TCP-Angriffe hängen davon ab, das Fünftupel zu erraten, und die Gegenmaßnahme der Branche ist, den Quellport zu randomisieren (RFC 6056). Ein Carrier-Grade NAT gibt jedem Teilnehmer eine Scheibe des Portbereichs statt des ganzen. In den Worten von RFC 6269: „with shared IPv4 addresses, the port selection space is reduced.“ Die Notlösung gegen die Adressknappheit nimmt einem Angriffsabwehrmechanismus direkt Entropie weg.\nDann gibt es den Teil, der jeden beunruhigen sollte, unabhängig davon, was er von Polizeiarbeit hält. Wenn der Server die Quellports nicht protokolliert hat und das NAT keine Ziele, buchstabiert RFC 6269 aus, was ein Anbieter tun muss, wenn eine rechtmäßige Anfrage kommt: er „would need to disclose the identity of all subscribers who had active sessions on the NAT during the time period in question. This may be a large number of subscribers.“\nDie Alternative dazu, einen schuldigen Teilnehmer zu identifizieren, ist, die Identitäten mehrerer hundert unschuldiger herauszugeben. Das ist das tatsächliche Datenschutzergebnis der Adressteilung, und es ist das Gegenteil dessen, was ihre Verteidiger für sie behaupten.\nDrei Dinge müssen zusammenpassen, und niemand ist verpflichtet, irgendeines davon zu liefern Leute nehmen an, die Protokolle lägen irgendwo und man müsse nur fragen. Meistens gibt es sie nicht, und der Grund ist Arithmetik und nicht böser Wille.\nUm eine geteilte Adresse in einen Haushalt zurückzuverwandeln, müssen drei getrennte Dinge alle gut gegangen sein:\nDer Server am anderen Ende hat den Quellport protokolliert. RFC 6302 bat internetzugewandte Server 2011, Quellport und Zeitstempel neben der Adresse zu protokollieren. Es ist eine Empfehlung. Niemand setzt sie durch, und sehr viele Server protokollieren immer noch nur die Adresse. An dem Punkt ist die Spur tot, bevor sie das britische Ende erreicht. Der Anbieter hat die Zuordnung aufbewahrt. Jede Sitzung, monatelang. Die Uhren waren einig. RFC 6269 warnt, dass bei einem stark ausgelasteten CGN „even very small amounts of clock skew between a third party\u0026rsquo;s server and the CGN operator will result in ambiguity about which customer was using a specific port at a given time.“ Verfehl eines davon und du hast nichts. Und das mittlere ist die Stelle, an der es auseinanderfällt, denn die Standarddokumente enthalten die Rechnung.\nRFC 7422 hat echte Zahlen darauf gesetzt. Betreiber berichteten von grob 33.000 Verbindungen je Haushalt und Tag. Bei etwa 150 Bytes je Protokolleintrag sind das 5 MB je Teilnehmer und Tag, 150 MB im Monat. Für einen Anbieter mit einer Million Teilnehmern: 150 Terabyte Protokolle im Monat, 1,8 Petabyte im Jahr — aufzubewahren für die sechs bis zwölf Monate, die das Gesetz erwartet, und auf Anfrage zu durchsuchen.\nUnd es ist nie nur ein Protokoll. NAT444, der Fall, für den RFC 7422 seine Einträge dimensioniert, setzt eine Übersetzung in den Router des Kunden und eine weitere beim Carrier, und jedes Tor, das ein Paket durchquert, muss aufschreiben, was es getan hat. Eine einzelne Sitzung zu rekonstruieren heißt, getrennte Tabellen, geführt von getrennten Parteien, gegen das Uhrenproblem oben zu korrelieren. Die Beweise kommen in Stücken aus verschiedenen Systemen, oder sie kommen nicht.\nUnd das Geld ist nur die Hälfte davon. Sitzungsdatensätze in dieser Rate zu erfassen, sie irgendwohin zu schicken, sie so zu indizieren, dass eine rechtmäßige Anfrage in Stunden statt Wochen beantwortet ist, und das Ganze ein Jahr zu halten, ist ein Data-Engineering-Projekt. Es gibt kein Dashboard dafür und keine Kiste zu kaufen. Es muss von jemandem gebaut werden, der versteht, was er baut, und das ist nicht Klicken, was in dieser Branche nah genug daran ist zu sagen, dass es nicht gebaut wird.\nDafür zahlen wollte auch nie jemand. Und die IETF wusste das, weshalb RFC 6888 den Betreibern das Gegenteil dessen sagt, was die öffentliche Sicherheit braucht: „A CGN\u0026rsquo;s port allocation scheme SHOULD minimize log volume“, begründet damit, dass „huge log volumes can be problematic to CGN operators.“ RFC 7422 existiert zu keinem anderen Zweck, als diese Rechnung zu drücken.\nDer Entwurfshinweis an die Branche lautet also: protokolliert weniger, die Wirtschaftlichkeit sagt, 1,8 Petabyte im Jahr sind unbezahlbar, und die rechtliche Erwartung ist eine vollständige Aufzeichnung. Die können nicht alle gleichzeitig wahr sein, und was nachgibt, ist die Aufzeichnung.\nDeshalb fand Europol, dass die Mehrheit der Zugangsanbieter einen Teilnehmer nicht identifizieren kann, wenn eine gerichtliche Anordnung zugestellt wird. Nicht weil sie sich sperren. Weil das, wonach gefragt wird, nie wirtschaftlich aufzubewahren war und niemand je dazu gezwungen wurde.\nZwei Dinge folgen daraus, und sie sind meine und nicht jemandes Zitat.\nErstens: ein großer Teil der britischen Internetanschlüsse ist konstruktionsbedingt nicht zuordenbar. Mobilfunk ist der klarste Fall, und unabhängige Messung setzt ihn höher an als Europol, bei 95 %. Die Anonymität, die früher Tor erforderte oder ein VPN, das jemand kaufen musste, ist damit die Werkseinstellung eines britischen Mobilfunkanschlusses — kostenlos mit der SIM ausgegeben, an alle, einschließlich der kleinen Zahl von Leuten, die der ganze Apparat finden soll.\nZweitens, und schlimmer: die billige gezielte Methode kaputt zu machen ist das, was die Nachfrage nach der teuren ungezielten erzeugt. Wenn du einen Beschluss an eine Adresse zustellen kannst und einen Haushalt bekommst, brauchst du nichts weiter. Wenn das aufhört zu funktionieren, zuckt der Staat nicht mit den Schultern. Er greift nach etwas Breiterem. Das war das Gesetz von 2015: eine Aufbewahrungspflicht über die gesamte Teilnehmerbasis, um Fragen über eine Handvoll Leute zu beantworten.\nNichts davon existiert auf der anderen Seite. Es wird nichts übersetzt, es gibt also überhaupt keinen Datensatz je Verbindung aufzubewahren. Die Adresse im Protokoll des Servers am anderen Ende ist schon das Präfix des Teilnehmers: ein Datensatz, einmal geschrieben, als die Leitung geschaltet wurde, in einem System. Selbst ein Anbieter, der Präfixe täglich rotiert, schreibt ein paar hundert im Jahr je Kunde, gegen die zwölf Millionen, auf die 33.000 Verbindungen am Tag hinauslaufen. Es ist nicht so, dass IPv6 weniger protokolliert. Es gibt nichts zu protokollieren.\nDie Leute, die die Notlösung schrieben, wussten das. Mitten in einer Spezifikation, die aus keinem anderen Grund geschrieben wurde, als CGN protokollierbar zu machen, hielten sie inne, um festzuhalten, dass „native IPv6 will offer subscribers a better experience than CGN“.\nEine Branche weigerte sich, je Netz zwei Wochen an ein kostenloses Protokoll zu wenden, und das Land bekam stattdessen ein Vorratsdatenregime.\nWürde das zu beheben Kinder besser schützen als der Online Safety Act? Ich will hier vorsichtig sein, denn dieses Argument lässt sich leicht schlecht machen, und die schlecht gemachte Fassung verdient die Abfuhr, die sie bekäme.\nFang damit an, wie eine Ermittlung wegen Kindesmissbrauchs tatsächlich läuft. Eine Plattform entdeckt das Material und meldet es. Die Meldung trägt eine Adresse und einen Zeitstempel. Die Polizei stellt dem Zugangsanbieter zu, um daraus einen Teilnehmer zu machen, und der Teilnehmer ist eine Adresse in der echten Welt mit einer Tür daran. Das ist die ganze Kette, und jeder Schritt danach hängt vom vorherigen ab.\nJetzt setz ein Carrier-Grade NAT in die Mitte. Die Meldung kommt immer noch an. Die Adresse löst immer noch auf. Zu mehreren hundert Haushalten, und Europol fand, dass Ermittlungen deswegen „dropped or delayed“ wurden. Zu ihren Fallbeispielen gehören ein Staatsanwalt, der die Mitglieder eines IS-unterstützenden Forums nicht identifizieren konnte, sodass die Anklage nicht zustande kam, und HMRC, das Massensteuerbetrug bis zu Mobilfunkadressen zurückverfolgte und die Spuren „frustrated from the outset“ fand.\nNCMECs CyberTipline nahm 21,3 Millionen Meldungen im Jahr 2025 entgegen und leitete mehr als 18,8 Millionen an die Strafverfolgung weiter, darunter über 53.000 mit einem Kind in unmittelbarer Gefahr. NCMEC hält auch fest, dass mehr als 10 % der Branchenmeldungen mit Informationen ankamen, die zu schlecht waren, um herauszufinden, an welche Jurisdiktion sie zu schicken sind. Diese Zahl geht nicht auf CGNAT zurück und ich behaupte das auch nicht — aber sie sagt dir, wo in dieser Pipeline Fälle sterben. Sie sterben an Metadaten.\nDie ehrliche Fassung des Vergleichs lautet also so. Carrier-Grade NAT macht die letzte Meile des Online Safety Act kaputt. Das Parlament hat Pflichten zum Erkennen und Melden auferlegt und das Zugangsnetz außerstande gelassen, das Gemeldete aufzulösen. Du kannst so viele Meldepflichten erlassen, wie du willst. Wenn der letzte Schritt eine Menschenmenge zurückgibt, ist die Meldung Papier.\nUnd die Kosten der beiden Dinge sind nicht im Entferntesten vergleichbar. Der Act ist die größte Internetregulierung, die dieses Land versucht hat — tausende Dienste im Anwendungsbereich, eine Aufsicht, die jahrelang Kodizes schreibt, Altersprüfung mit Millionen Checks am Tag, und ein Umgehungsproblem, das groß genug ist, dass das Parlament im Oberhaus über VPN-Nutzung debattiert hat. IPv6 kostet bei der Registry nichts und braucht ein kompetentes Team ein paar Wochen. Eines davon ist der ganzen Branche abverlangt worden. Das andere ist nie von irgendwem verlangt worden.\nDrei Dinge müssen klar gesagt werden, denn ohne sie ist das Argument wertlos.\nErstens. Es ist kein Ersatz, und ich schlage es auch nicht als einen vor. IPv6 tut nichts dagegen, dass ein Zwölfjähriger Pornografie findet. Es tut nichts gegen Empfehlungssysteme, Autoplay oder Livestreaming. Es tut nichts gegen Material, das in einem anderen Land gehostet wird, und das ist das meiste davon. Das sind die Probleme, für die der Act geschrieben wurde, und keine Protokolländerung rührt daran.\nZweitens. IPv6 ist keine Identitätsschicht, und wer es als eine verkauft, verkauft es über Wert. Privacy Extensions rotieren die Adresse eines Geräts von Entwurf wegen, die Adresse der Maschine ist also nicht das Stabile. Stabil ist das der Leitung delegierte Präfix — das /56, das Sky seit 2016 jedem Teilnehmer gibt. Das löst zu einem Teilnehmer auf, was genau die Auflösung ist, die eine rechtmäßige Anfrage braucht, und nicht mehr. Es ist eine Wiederherstellung dessen, was eine einzelne IPv4-Adresse je Leitung früher gab, keine neue Überwachungsfähigkeit.\nDrittens. Die Eigenschaft, die die Polizei behindert, behindert auch alle anderen, die dich verfolgen, und manche Leute schätzen das. Einer von fünfhundert hinter einer geteilten Adresse zu sein ist echte Deckung in der Menge gegen kommerzielles Profiling. Ich halte sie nicht für das wert, was sie kostet — es ist Deckung, erkauft damit, Missbrauch unzuordenbar und Ratenbegrenzung nutzlos zu machen, und es ist Deckung, die die Plattformen mit Cookies und Fingerprinting ohnehin meist durchschauen. Aber es ist ein echtes Argument und es verdient, genannt statt ignoriert zu werden.\nAlso nein, das ist nicht IPv6 statt des Online Safety Act. Es ist, dass Britannien das teuerste Online-Sicherheitsgesetz seiner Geschichte auf eine Installation geschrieben hat, von der es wusste, dass sie kaputt ist, während die Lösung kostenlos, gut dokumentiert und die ganze Zeit verfügbar war, in der der Gesetzentwurf verfasst wurde.\nWas wirklich zu fordern ist Kein Verbot. Ein Verbot ist das falsche Instrument und es würde nach hinten losgehen.\nEs ist kein IPv4 mehr zu vergeben — RIPE ist seit November 2019 leer, und ein neuer Anbieter bekommt ein einzelnes /24 von einer Warteliste. Verbiete morgen die Adressteilung und der kleine Betreiber kann Kunden überhaupt nicht mehr anschließen, während die Läden, die auf Class-B-Blöcken von 1990 sitzen, unberührt weitermachen. Es würde genau die Leute zementieren, um die es in diesem Beitrag geht.\nDas bessere Instrument existiert bereits und jemand hat das Experiment bereits durchgeführt.\n2012 unterzeichneten Belgiens Bundespolizei, seine Telekommunikationsaufsicht, sein Rat der Generalstaatsanwälte und sein ISP-Verband einen zweiseitigen freiwilligen Verhaltenskodex. Maximal 16 Teilnehmer hinter einer IPv4-Adresse. Den Einsatz von CGN begrenzen. Mit der Einführung von IPv6 beginnen.\nBis 2017 lagen die meisten belgischen Betreiber innerhalb der Grenze, einer war auf 8 heruntergegangen, und die belgische Polizei sah im Schnitt vier Nutzer je Mobilfunkadresse. Europols eigene Zusammenfassung des Warum ist der Teil, den man zweimal lesen sollte: die größten Anbieter „are quickly moving towards IPv6 because no financial interest to invest in CGN anymore.“ Deckle die Überbuchung und die Wirtschaftlichkeit der Notlösung bricht zusammen, denn ein NAT, das nur sechzehn Leute stapeln darf, ist nicht billiger als das Protokoll, das keine braucht.\nIn jenem Jahr hatte Belgien mit 49 % die höchste IPv6-Verbreitung der Welt, als Britannien und Frankreich bei 14 % lagen und Spanien und Italien unter 1 %. Belgien ist mit 72,8 % immer noch Dritter in der Ländertabelle oben.\nDas ist die Forderung. Nicht „du darfst keine Adressen teilen“ — du darfst keinen Anschluss verkaufen, der zugleich nicht zuordenbar ist und kein IPv6 hat. Geteilte Adressierung neben funktionierendem IPv6 ist in Ordnung. So arbeitet jedes Mobilfunknetz der Erde. Geteilte Adressierung ohne IPv6 heißt, einen kaputten Dienst zu verkaufen und der Öffentlichkeit die Folgen in Rechnung zu stellen.\nSky hat vor elf Jahren bewiesen, dass es geht Wäre es wirklich schwer, hätte es im UK niemand geschafft.\nSky startete Anfang 2013 ein internes IPv6-Projekt und war 2016 fertig, wobei rund 90 % seiner Festnetzbasis — etwa fünf Millionen Nutzer — IPv6 bekamen und nutzten. Ihr Ingenieur hat das Ganze auf RIPE Labs aufgeschrieben: 6PE über den MPLS-Kern, dual-gestacktes Peering und Transit, RADIUS-Attribute, um es je Teilnehmer freizuschalten, Firmware-Arbeit über sieben CPE-Modelle einschließlich fünf alter, und Kapazitäts-Upgrades bei RADIUS und DNS.\nDrei Jahre, ein ISP, und dasselbe Openreach-Kupfer, über das alle anderen verkauften. ISPreview berichtete über den Abschluss im September 2016, wobei Sky bis Jahresende 95 % seiner Basis erwartete, und Sky bekam dafür den Jim Bound IPv6 Award.\nIhr Rat war: „Do not underestimate the work required to enable IPv6, and do not leave it to the last minute to begin the journey.“\nElf Jahre später ist der größte Teil der Branche immer noch in der letzten Minute und behandelt sie als Wohnort.\nAlle haben die Adressen seit Jahren Sky war der erste der großen ISPs. Es war bei weitem nicht der erste im Land, und kein einziger Anbieter auf dieser Liste kann sagen, er habe auf die Registry gewartet.\nRIPE stempelt das Zuteilungsdatum in den Namen des Blocks, du kannst also jeden selbst nachprüfen:\nwhois -h whois.ripe.net 2a01:4b00::/32 | grep -E \u0026#39;netname|^org:\u0026#39; # netname: UK-BCUBE-20110225 -\u0026gt; Hyperoptic, zugeteilt am 25. Februar 2011 Jedes Datum unten kam aus dieser Abfrage gegen die eigene Zuteilung des Anbieters, gegengeprüft an der Delegierungsdatei. Die großen ISPs sind fett, der Rest sind die Glasfaserbauer. Ob Kunden tatsächlich IPv6 bekommen, stammt aus ISPreviews Umfrage im Stand März 2025 und aus dem Mobilfunk-Tracker für die Telefonnetze.\nWie lange jeder britische Anbieter IPv6 hält, und ob Kunden es bekommen Wie lange jeder britische Anbieter IPv6 hält — und ob Kunden es wirklich bekommen Zuteilungsdaten aus der RIPE-Delegierungsdatei und ihren Netname-Stempeln. Ob es Kunden erreicht: ISPreview, März 2025, und der Community-Mobilfunk-Tracker. Kunden bekommen es teilweise — nur ein Netz liefern es immer noch nicht (17 von 40) 2002 2002 2006 2006 2010 2010 2014 2014 2018 2018 2022 2022 2026 2026 TalkTalk (als Opal Telecom) Andrews \u0026amp; Arnold Vodafone UK EE (als T-Mobile) Sky Gigaclear O2 (Telefónica UK) BT Virgin Media (als NTL) KCOM Hyperoptic (als Bcube) Zen Internet B4RN Trooli (als Call Flow) Exascale Three UK Community Fibre Ogi (als NetSupport) WightFibre Truespeed Airband G.Network Wessex Internet Quickline FibreNest Wildanet Fibrus (als B4B Networks) Zzoomm GoFibre (als Borderlink) Toob Netomnia / YouFibre Pine Media BeFibre Squirrel Internet brsk Lit Fibre (als Broadreach) iDNET * Grain Hey! Broadband Octaplus Jeder der vierzig hält seit mindestens drei Jahren IPv6-Raum, die meisten seit über einem Jahrzehnt. 17 davon geben ihn bis heute keinem Kunden. Vierzig britische Anbieter, sortiert nach dem Datum, an dem die Registry ihnen IPv6 gab. Jeder Balken läuft von dieser Zuteilung bis heute. Die blauen Balken liefern es an Kunden aus; die pinken haben das nie getan. Vierzig Anbieter. Jeder einzelne hält seit mindestens drei Jahren IPv6-Adressraum, die meisten seit über einem Jahrzehnt — und siebzehn davon geben ihn bis heute keinem Kunden.\nHyperoptic hält 2a01:4b00::/32 seit Februar 2011. Fünfzehn Jahre Glasfaser in Wohnblocks bauen, Gigabit-Anschlüsse verkaufen und Leute hinter Carrier-Grade NAT setzen, mit einer ungenutzten IPv6-Zuteilung in den Büchern. Trooli hat seine seit dreizehn Jahren. Truespeed und Airband seit zehn.\nAndrews \u0026amp; Arnold ist der, an dem man den Rest messen muss. Ein kleiner ISP in Bracknell mit einem Bruchteil der Kunden und Ingenieure von allen anderen auf der Liste, der seit 2002 jeder Leitung IPv6 gibt, und einer der Läden hinter 6UK. TalkTalk nahm seine Zuteilung drei Monate früher und liefert es Endkunden bis heute nicht aus.\nVirgin Media nahm seinen Block drei Wochen bevor Zen den seinen nahm. Zen hat ihn ausgeliefert, und ich hänge seither an einem ihrer /48. Virgin sagt immer noch „wenn wir so weit sind“.\nUnd schau ans Ende der Tabelle. Squirrel, brsk, Lit Fibre und Octaplus bekamen ihre Zuteilungen alle in den letzten sechs Jahren und liefern alle IPv6 aus, während Anbieter, die seit 2011 Raum halten, es nicht tun. Spät anzufangen ist nicht das Hindernis. Überhaupt anzufangen ist es.\nZwei Namen aus dieser Umfrage sind nicht in der Grafik, und der Grund ist bei beiden derselbe. Cuckoo ist eine Endkundenmarke, die Vorleistungen über Openreach, CityFibre und andere einkauft, und Freedom Fibre ist ein Vorleistungsnetz, dessen Kunden über Vertriebspartner kommen. Keiner hält eigenen Adressraum, IPv6 ist also die Entscheidung von jemand anderem für sie. iDNET ist mit einem Sternchen markiert, weil deren Raum eine provider-unabhängige Zuweisung ist und keine eigene Zuteilung.\nDer eine Fall, der es entscheidet Wenn du das Argument auf eine einzige Firma reduziert haben willst, ist es Plusnet.\nBT kaufte Plusnet im Januar 2007. Plusnet sitzt unter dem eigenen RIPE-Konto von British Telecommunications, hat also seit Juni 2010 Zugang zu BTs IPv6-Zuteilung. BT liefert IPv6 aus. EE, die andere Schwesterfirma, liefert IPv6 aus. ISPreview merkte an, dass BT und Plusnet sogar nahezu identische Kundenrouter verwenden, und nannte die Lücke „somewhat of a peculiarity“.\nPlusnet testete IPv6 2011 und forderte den Rest der Branche öffentlich auf, endlich loszulegen. 2019 sagte es, es werde im Frühjahr 2020 starten. 2021 erwartete es, „im kommenden Jahr gute Fortschritte zu machen“. Im November 2023 fuhr es einen dreimonatigen Test über zwei Standorte in Chesterfield und Sheffield, mit etwa zwanzig Mitarbeitern und wohlgesonnenen Kunden darauf.\nIm April 2026 fragte sein eigenes Kundenforum immer noch, wo IPv6 geblieben sei.\nEin Mutterkonzern. Eine Adresszuteilung. Nahezu identische Hardware. Ingenieure, die für dieselbe Gruppe arbeiten und den Flur hinuntergehen können zu den Leuten, die es schon gemacht haben. Drei Marken, und eine davon schafft in fünfzehn Jahren nicht, was die anderen zwei fertiggestellt haben.\nWas auch immer das aufhält, es ist nicht die Technik, das Geld, die Geräte oder der Adressraum. Es ist jemand, der entscheidet, dass es dieses Quartal nicht sein Problem ist, seit fünfzehn Jahren.\nVirgin Media, sechzehn Jahre „wenn wir so weit sind“ Das andere Ende der Skala verdient es, benannt zu werden, denn die Chronologie ist öffentlich und sie ist bemerkenswert.\nMärz 2010: ein Kunde fragt in Virgin Medias eigenem Forum, wann IPv6 kommt. Die Antwort ist „wenn wir so weit sind“.\nNovember 2016: Virgin sagt ISPreview, es plane, IPv6 bis Mitte 2017 einzuführen. Tut es nicht.\nJuni 2018: über einen Endkundentest wird berichtet. Dezember 2018: eine dritte Präsentation vor dem UK IPv6 Council, mit Andeutungen auf 2019.\n2021: eine Erklärung, man „continuing to plan our IPV6 deployment having tested several solutions and intend to introduce IPV6 for our customers in future.“\nFebruar 2024: Virgin Media sperrt den vierzehn Jahre alten Forenthread.\nAugust 2026: immer noch nichts.\nSechzehn Jahre. In dieser Zeit wurde die Firma gekauft, mit O2 fusioniert, hat ihren Kern zweimal neu gebaut und ihren gesamten Routerbestand ersetzt. Zu keinem Zeitpunkt hat jemand eine Adressfamilie hinzugefügt. Den Thread zu sperren ist das Ehrlichste auf dieser Liste. Es ist der Moment, in dem sie aufhörten, so zu tun, und anfingen, die Beschwerde statt das Problem zu verwalten.\nDie Altnets hatten überhaupt keine Ausrede Die Glasfaserbauer waren die Chance, sauber anzufangen. Neue Netze, neue Geräte, kein Altbestand, in diesem Jahrzehnt eingestellte Ingenieure. Schau, wo sie in der Zuteilungstabelle stehen, und die meisten haben den Adressraum genommen und aufgehört.\nEine Firma also, die institutionelles Geld einsammelte, um ein brandneues Glasfasernetz zu bauen, riss die Straßen auf, blies Glasfaser zu hunderttausend Haushalten, kaufte neue Router, schrieb einen neuen Provisionierungs-Stack. Und setzte ihre Kunden hinter eine geteilte Adresse in einem Netz ohne IPv6, 2026, mit dem Adressraum bereits im eigenen Registry-Konto.\nUnd dann verlangen mehrere von ihnen 5 Pfund im Monat für eine statische öffentliche IPv4.\nSie haben das funktionierende Ding weggenommen, sich geweigert, den kostenlosen Ersatz auszuliefern, und den daraus entstehenden Schaden in einen Posten auf deiner Rechnung verwandelt. Es gibt ein Wort für ein Geschäftsmodell, das einen Fehler herstellt und dann die Behebung verkauft, und es ist nicht „Innovation“.\nDie Websites verraten das Spiel Die Routingtabelle zeigt, was Netze tun. Das DNS zeigt, was alle anderen tun. Also habe ich am 27. August 2026 fünfzig der bekanntesten Websites des UK in eine Datei geschrieben — Zentralregierung, die Banken, die großen Einzelhändler, die Telkos, Verkehr und ein paar Universitäten — und jede gefragt, ob sie auf IPv6 antwortet:\nwhile read -r d; do n=$(dig +short AAAA \u0026#34;$d\u0026#34; | grep -c \u0026#39;:\u0026#39;) printf \u0026#39;%-46s %s\\n\u0026#39; \u0026#34;$d\u0026#34; \u0026#34;$([ \u0026#34;$n\u0026#34; -gt 0 ] \u0026amp;\u0026amp; echo AAAA || echo none)\u0026#34; done \u0026lt; sites.txt | sort -k2 Dann habe ich jede Antwort gegen einen zweiten Resolver geprüft, denn ein rekursiver Server mit einem schlechten Tag ist kein Befund:\ndig @1.1.1.1 +short AAAA www.tesco.com | grep -c \u0026#39;:\u0026#39; Siebzehn von fünfzig hatten einen AAAA-Eintrag. Dreiunddreißig nicht, und beide Resolver waren sich bei jedem einig.\nZu denen ohne IPv6 gehören www.bbc.co.uk, www.nhs.uk, www.hmrc.gov.uk, www.hsbc.co.uk, www.barclays.co.uk, www.lloydsbank.com, www.santander.co.uk, www.tesco.com, www.johnlewis.com, www.marksandspencer.com, www.britishairways.com, tfl.gov.uk, monzo.com — eine 2015 gegründete Bank, ohne irgendeinen Altbestand — und, mein Liebling, www.sky.com.\nSky. Die Firma, die fünf Millionen Kunden auf IPv6 gebracht und einen Preis dafür gewonnen hat. Ihre eigene Website antwortet nicht auf IPv6.\nJetzt der Teil, der die These über jeden Zweifel hinaus beweist.\nFünfzehn der siebzehn, die IPv6 haben, haben es von einem Lieferanten bekommen und nicht von sich selbst. Ich habe jede aufgelöst und nachgeschlagen, wem die antwortende Adresse gehört:\nwhois -h whois.radb.net -- \u0026#34;$(dig +short AAAA www.sainsburys.co.uk | grep \u0026#39;:\u0026#39; | head -1)\u0026#34; | grep -i descr www.gov.uk und www.cam.ac.uk antworten von Fastly. ico.org.uk, www.parliament.uk, www.ofcom.org.uk, www.asda.com, www.autotrader.co.uk, www.nationalrail.co.uk und www.jisc.ac.uk antworten von Cloudflare, das IPv6 standardmäßig für alle einschaltet. natwest.com und nationwide.co.uk antworten von Azure Front Door. www.legalandgeneral.com und www.screwfix.com antworten von CloudFront. www.sainsburys.co.uk und www.next.co.uk antworten von Akamai.\nZwei haben es selbst gemacht: Imperial College London, das aus eigenem Adressraum antwortet, und die eigene Website des UK IPv6 Council. Eine Universität und die Leute, deren ganzer Zweck IPv6 ist. Das ist die Liste.\nUnd www.tesco.com, www.sky.com und www.nhs.uk sitzen ebenfalls auf Akamai — dasselbe CDN, dasselbe Produkt — und haben überhaupt kein IPv6.\nAkamai ist da seit Juni 2022 deutlich: „Akamai has enabled IPv4+IPv6 dual-stack as the default for our CDN delivery products for many years, meaning that customers have needed to opt-out for content to be IPv4-only.“ Sie ergänzten, sie hätten das Umschalten einfach gemacht, auch über die API.\nDerselbe Anbieter. Dieselbe Plattform. Standardmäßig an. Die eine Organisation hat es in Ruhe gelassen und die andere ist hineingegangen und hat es abgeschaltet, oder hat eine uralte Konfiguration behalten, die seither niemand gelesen hat. Sainsbury\u0026rsquo;s hat IPv6 und Tesco nicht, und der Unterschied zwischen ihnen ist ein einzelner Konfigurationsschalter und jemandes Aufmerksamkeit.\nDanach steht kein Kostenargument und kein Komplexitätsargument mehr. Es steht nur noch, ob irgendwer aufgepasst hat.\nÜber die ganze Stichprobe hält die Regel: wo IPv6 als Standardeinstellung eines Lieferanten ankommt, hat Britannien es. Wo eine britische Organisation etwas hätte entscheiden müssen, hat es sie nicht. Zwei Seiten von fünfzig, und eine davon war das IPv6 Council.\nWas uns zur Managed-Service-Branche bringt Die Endkunden-ISPs bekommen die Schuld für CGNAT, und sie haben sie verdient. Aber die Schicht, die den größten Schaden anrichtet, ist die, die Fachwissen verkauft: die Managed Service Provider, die Systemintegratoren, die ausgelagerten Netzwerkteams, die Beratungen, die das Feindesign schreiben.\nGeh zurück zur Liste der größten britischen Netze ohne IPv6 — die Banken, British Airways, PwC, QinetiQ. Das sind keine zusammengeschusterten Start-ups. Das sind Läden, die sehr viel Geld dafür zahlen, dass jemand anderes ihr Netz betreibt, oder ein großes Team beschäftigen, um es selbst zu betreiben. Hinter jeder dieser AS-Nummern steckt ein Entwurfsdokument, ein Änderungsprozess, ein Architektur-Gremium und ein Lieferant mit „Netzwerk“ im Namen. Nicht einer von ihnen hat einen IPv6-Plan hervorgebracht.\nDas Muster ist überall dasselbe, wo man hinschaut:\nDie Vorlage ist IPv4. Der Baustandard, das Firewall-Regelwerk, die Monitoring-Checks, das IPAM, das Runbook, der Notfallplan, die Übergabemappe für den Kunden — alles IPv4, einmal geschrieben, ein Jahrzehnt lang kopiert. Eine Adressfamilie hinzuzufügen heißt, das alles zu überarbeiten, und niemand wird dafür bezahlt, es zu überarbeiten.\nNiemand hat danach gefragt. Das ist der Satz, der in dieser Branche jedes IPv6-Gespräch beendet, und er ist ein Geständnis. Nach TLS 1.3 hat auch niemand gefragt. Niemand hat dich gebeten, mit SMBv1 aufzuhören. Kunden kaufen das Ergebnis und bezahlen dich dafür, zu wissen, was das Ergebnis erfordert. „Der Kunde hat nicht danach gefragt“ heißt „ich will es nicht lernen und sie können es nicht beurteilen“.\nRFC 1918 fühlt sich unendlich an. Zehn-Punkt sind 16,7 Millionen Adressen, ein internes Netz fühlt sich also nie knapp an, es gibt also nie ein auslösendes Ereignis. Dann kommt die Fusion, beide Bestände liegen auf 10.0.0.0/8, und die Antwort ist ein weiteres Jahrzehnt NAT über überlappende Subnetze und ein Dokument, das erklärt, welche falsche Adresse welche echte meint — wieder mehr Maschinerie, um die Adressfamilie zu vermeiden, die das zum Nichtproblem gemacht hätte.\nIPv6 legt Kompetenz offen. Das ist der eigentliche Grund. Dual-Stack lässt dich nicht verstecken.\nDu musst wissen, was deine Firewall-Policy tatsächlich ist, denn du musst sie zweimal schreiben. Du musst wissen, wie dein DNS aussieht. Du musst Neighbour Discovery verstehen, Präfix-Delegierung, und was dein CPE mit einem /56 anstellt.\nEin Ingenieur, der sich mit NAT als zufälliger Sicherheitskontrolle durchgeschlagen hat, findet vor Publikum heraus, dass es nie eine war. Es gibt in dieser Branche zwanzigjährige Karrieren, die auf dieser einen Verwechslung gebaut sind.\nAlso wird es nicht vorgeschlagen. Nicht weil es Geld kostet — tut es nicht — sondern weil es vorzuschlagen heißt, es zu verantworten, und es zu verantworten heißt, es zu lernen.\nDas meine ich mit stinkfaul. Nicht faul im Sinne von wenig arbeiten. Diese Branche arbeitet außerordentlich hart. Sie arbeitet hart an Carrier-Grade NAT und daran, einem Kunden zu erklären, warum seine Überwachungskamera von außen nicht mehr erreichbar ist. Sie macht jede Menge Arbeit, solange die Arbeit die Sorte ist, die man kaufen kann, und nicht die, die man verstehen muss.\nUnd das hört gerade auf, Geschmackssache zu sein. Das Cyber Security and Resilience Bill, das derzeit durchs Parlament geht, würde die NIS-Verordnungen so ändern, dass unter anderem „managed service providers (organisations that provide third-party IT services to other businesses)“ erfasst werden. Es ist noch kein Gesetz. Wenn es das ist, hören Erkennung, Protokollierung und Vorfallmeldung auf, Produktlinien zu sein, die diese Schicht verkauft, und werden zu Pflichten, die sie erfüllen muss.\nSetz das neben die Kette weiter oben. Jede Missbrauchsmeldung aufzulösen beginnt damit, dass ein Server am anderen Ende einen Quellport protokolliert hat, und der Server am anderen Ende ist sehr oft eine Kiste eines dieser Läden. Die Leute, die demnächst nachweisen müssen, dass sie einen Vorfall erkennen und melden können, sind dieselben, die man gegenwärtig nicht dazu bringt, eine Adressfamilie einzuschalten oder einen Paketmitschnitt zu lesen, wenn ein Tunnel nicht hochkommt.\nDie drei Ausreden Du hörst jedes Mal dieselben drei, und keine hält eine Minute.\n„Dual-Stack ist alles doppelt.“ Ich habe es bei Nominet produktiv gefahren, auf F5-Loadbalancern vor der .uk-Registry, ich weiß also, was der Einwand wert ist. Die NAT-Ebene, die du stattdessen gekauft hast, ist es auch, und die sitzt im Verkehrspfad, mit einer Sitzungstabelle, einem Kapazitätsmodell, einer Failover-Geschichte und einer Protokollierungspflicht daran. Du hast nie zwischen Komplexität und Einfachheit gewählt. Du hast die Komplexität genommen, die mit einer Rechnung kam.\n„Die Geräte unterstützen es nicht.“ 2006 war das fair. 2026 heißt es, deine Geräte sind ohne Support, was zuzugeben schlimmer ist als das, was du eigentlich nicht sagen wolltest.\n„Damit ist kein Umsatz zu machen.“ Mit Backups auch nicht.\nWas die Leute so schreiben Die Ausreden oben sind, was du in einer Besprechung hörst. Darunter liegt eine Schicht technischer Behauptungen, die in Forenthreads, Kommentarspalten und LinkedIn-Antworten jedes Mal wiederholt werden, wenn IPv6 aufkommt, und die meisten davon sind seit über einem Jahrzehnt falsch.\nEin Teil davon ist ehrliche Verwirrung und ein Teil ist jemand, der beschlossen hat, etwas nicht zu lernen, und nach einem Grund greift. So oder so lohnt es sich, sie durchzugehen, denn diese Behauptungen leisten echte Arbeit. Sie sind das, was ein Ingenieur einem Manager erzählt, der es nicht überprüfen kann.\n„NAT ist meine Firewall. IPv6 setzt jedes Gerät direkt ins Internet.“\nDas ist der große, und er ist andersherum. Der Schutz, den Leute NAT zuschreiben, kommt daher, dass es keine Zuordnung gibt, bis etwas von innen eine anfordert — und das ist eine zustandsbehaftete Firewall, und es ist die Firewall, die die Arbeit macht, nicht die Übersetzung. Die IETF hat das 2007 in RFC 4864 gesagt: diese Rolle, „often marketed as a firewall, is really an arbitrary artifact“, während eine echte Firewall dir „explicit and more comprehensive management controls“ gibt.\nJeder IPv6-Router für Endkunden kommt mit standardmäßigem Deny für eingehenden Verkehr. Du bekommst dieselbe Haltung, aus einer Policy, die jemand aufgeschrieben hat, statt aus einem Nebeneffekt davon, dass die Adressen ausgegangen sind. Und du kannst dann genau das eine erlauben, was du erlauben wolltest, statt der Port-Forwarding-Séance.\nWenn dein gesamtes Sicherheitsmodell „Angreifer finden meine Geräte nicht“ lautet, hattest du kein Sicherheitsmodell. Du hattest NAT.\n„IPv6 ist langsamer.“\nDiese verdient eine ehrliche Antwort statt einer Abfuhr, denn die Wahrheit ist gemischt und die Leute, die das sagen, liegen nicht einfach falsch.\nInhalteanbieter, die dafür optimiert haben, messen Gewinne: Facebook berichtete von rund 15 % schnelleren Seitenaufbauten über IPv6, Akamai von rund 5 % auf Mobilgeräten. APNICs breitere Messung des ganzen Internets ist weniger schmeichelhaft und hat IPv6-Roundtrip-Zeiten im Schnitt marginal höher — in der Größenordnung einer Millisekunde, und mit der Zeit besser werdend.\nAlso: im Großen und Ganzen ein Gleichstand, besser wo jemand die Arbeit gemacht hat, gelegentlich einen Hauch schlechter, wo niemand es getan hat.\nEs lohnt sich zu wissen, wo die Kosten tatsächlich sitzen, denn der Header ist das, was Leute sich vorstellen, und der Header ist nicht das Problem.\nDer IPv4- und der IPv6-Header, und was jeder einen Router kostet Die zwei Header, und was jeder einen Router kostet Felder maßstäblich über 32 Bit gezeichnet. Quellen: RFC 791 (IPv4) und RFC 8200 (IPv6). Arbeit je Hop für den Router breiterer Nachschlageschlüssel IPv4 20 Bytes, mit Optionen bis 60 031 Version IHL Type of Service Total Length Identification Flags Fragment Offset Time to Live Protocol Header Checksum Source Address Destination Address Options — variable Länge, 0 bis 40 weitere Bytes IPv6 40 Bytes, fest. Immer. 031 Version Traffic Class Flow Label Payload Length Next Header Hop Limit Source Address (128 Bit) Destination Address (128 Bit) IPv4 zwingt einen Router,\u0026#160;die Header-Prüfsumme bei jedem Hop neu zu berechnen, ein Längenfeld zu lesen, bevor er weiß, wo die Nutzlast beginnt, und einen Fragmentierungspfad zu tragen. IPv6 lässt alle drei fallen — und verlangt\u0026#160;einen viermal so breiten Schlüssel. Die zwei Header nebeneinander, Felder maßstäblich über 32 Bit gezeichnet. Orange schattiert ist Arbeit, die ein Router bei jedem Hop leisten muss; blau schattiert ist der breitere Nachschlageschlüssel. Fang damit an, was IPv6 dem Router abgenommen hat. IPv4 trägt eine Header-Prüfsumme. Die Time to Live ändert sich bei jedem Hop, die Prüfsumme muss sich also mitändern, und RFC 6583 listet „verifying and updating the checksum“ als Schritt im Weiterleitungsprozess selbst auf. IPv6 hat keine. Dieser Schritt fällt einfach weg.\nDann die Länge. Ein IPv4-Header ist variabel, wofür IHL da ist: ein Router liest eine Länge, bevor er weiß, wo die Nutzlast beginnt. Ein IPv6-Header ist 40 Bytes. Immer. Jedes Feld sitzt an einem festen Offset und nichts muss vorher ausgerechnet werden.\nDann die Fragmentierung. IPv4-Router können unterwegs fragmentieren, weshalb Identification, Flags und Fragment Offset überhaupt im Header sitzen. RFC 8200 ist da eindeutig: „fragmentation in IPv6 is performed only by source nodes, not by routers along a packet\u0026rsquo;s delivery path“. Auch dieser Pfad fällt weg.\nAllein bei der Header-Behandlung ist IPv6 das billigere Protokoll zum Weiterleiten. Es wurde so gebaut.\nDie eine Stelle, an der es mehr kostet, ist pro Route, und die stellt sich als unwichtig heraus. Der Nachschlageschlüssel ging von 32 auf 128 Bit, ein IPv6-Weiterleitungseintrag ist also breiter und braucht auf vielen Geräten zwei Hardware-Slots, wo eine IPv4-Route einen braucht. Alle beenden das Argument dort. Es lohnt sich, einen Schritt weiterzugehen, denn die volle Tabelle ist viermal kleiner.\nIm RIS-Dump, erzeugt am 28. August 2026 um 02:03 UTC, gab es 1.229.166 IPv4-Präfixe in der globalen Routingtabelle und 300.470 IPv6-Präfixe. Viermal so viele IPv4-Routen, jede ein Viertel so breit. Der reine Schlüsselspeicher endet also in einem Unentschieden: 4,92 MB gegen 4,81 MB. Jetzt wende die Zwei-Slots-je-IPv6-Route-Regel an, um die Leute sich sorgen. Eine volle IPv6-Tabelle braucht immer noch etwa die Hälfte der Hardware-Einträge einer vollen IPv4-Tabelle.\nUnd der Grund, warum die IPv4-Tabelle so groß ist, ist die Knappheit selbst. 767.543 dieser 1,2 Millionen Routen sind /24 — 62 % des gesamten IPv4-Internets sitzen beim längsten Präfix, das irgendwer akzeptiert, weil Blöcke zerlegt, verkauft und stückweise von denen angekündigt wurden, die sie kauften. Jede davon ist ein Router irgendwo, der einen Eintrag hält, den er nicht bräuchte, wenn der Raum nicht ausgegangen wäre.\nDie IPv4-Routingtabelle ist viermal so groß wie die IPv6-Tabelle Die IPv4-Routingtabelle ist viermal so groß — und das meiste davon ist die Knappheit Verschiedene Präfixe in der globalen Routingtabelle, RIPE-RIS-Dump erzeugt 02:03 UTC, 28. August 2026. IPv432-Bit-Schlüssel 767.543 davon sind /24 1.229.166 IPv6128-Bit-Schlüssel 300.470 Viermal so viele IPv4-Routen, jede ein Viertel so breit — der reine Schlüsselspeicher endet also unentschieden, 4,92 MB gegen 4,81 MB. Zähl eine IPv6-Route als zwei Hardware-Einträge, wie die Leute befürchten, und eine volle IPv6-Tabelle braucht immer noch etwa die Hälfte. 62 % der IPv4-Tabelle sind /24\u0026#160;— Blöcke zerlegt, verkauft und stückweise angekündigt, weil der Raum ausging. Jede ist ein Eintrag, den ein Router sonst nicht halten müsste. Verschiedene Präfixe in der globalen Routingtabelle am 28. August 2026, gezählt aus dem RIPE-RIS-Dump. Der massive Teil des IPv4-Balkens sind die /24 — Deaggregation, die die Adressknappheit erzwungen hat. Das Speicherargument läuft also andersherum, als es in Besprechungen erzählt wird. IPv6 zu führen ist billiger für deine FIB als IPv4 zu führen, und es wird jedes Jahr billiger, in dem der Transfermarkt ein weiteres /16 in sechzehn /24 zerlegt.\nUnd die CPU-Spitzen, die Leute wirklich treffen, sind weder das eine noch das andere. Ein moderner Router leitet beide Familien in Silizium bei Leitungsgeschwindigkeit weiter. Weh tut alles, was ein Paket von diesem Pfad in die Steuerungsebene schiebt, die RFC 6583 „a \u0026lsquo;slower\u0026rsquo; software process running on a general purpose processor“ nennt. Dieser Prozessor war für Routingprotokolle dimensioniert. Nie für Verkehr.\nZwei Dinge schieben Pakete zu ihm. Das erste sind Extension Header. Sie sind eine Kette statt eines festen Blocks, eine Kiste, die die Layer-4-Ports für eine ACL oder einen ECMP-Hash will, muss also eine Liste variabler Länge abgehen, um sie zu finden, und ein Hop-by-Hop-Options-Header „may be examined or processed by any node along a packet\u0026rsquo;s delivery path“. Auf reichlich Geräten heißt das: hochgereicht.\nDas zweite ist Neighbour Discovery. Ein /64 deckt Billionen Adressen ab, die nie vergeben werden, eines zu scannen bringt einen Router also dazu, Adressen aufzulösen, die es nicht gibt. RFC 6583 existiert dafür und nennt es einen Denial of Service.\nBeide haben bekannte Antworten. Hop-by-Hop am Rand filtern, ND ratenbegrenzen, den Neighbour-Cache deckeln. Keines davon ist ein Grund, warum das Protokoll langsam ist. Es sind Gründe, warum ein unkonfigurierter Router langsam ist, und das zeigt dorthin, wohin der Rest dieses Beitrags zeigt.\nJetzt wieg eine Millisekunde gegen die Alternative, die du tatsächlich ausgerollt hast — eine zustandsbehaftete Übersetzungskiste im Pfad jeder Verbindung, die eine Sitzungstabelle hält und manche davon rundheraus kaputt macht. Niemand hat zwanzig Jahre wegen einer Millisekunde gezögert.\n„Es gibt reichlich IPv4, du kannst es einfach kaufen.“\nKannst du. So sieht eine Knappheit aus. Blöcke, die 1990 umsonst vergeben wurden, wechseln jetzt für rund 20 Dollar je Adresse den Besitzer, und AWS berechnet 43,80 Dollar im Jahr für jede, die du benutzt.\nDass es einen Markt für etwas gibt, beweist nicht, dass es reichlich davon gibt. Es beweist, dass jemand herausgefunden hat, wie er dir die Knappheit in Rechnung stellt.\nNiemand hätte sie je dazu gebracht Das UK hat dazu überhaupt keine Politik, und hatte nie eine.\nEs gab einen Versuch. 6UK wurde 2010 mit 20.000 Pfund Anschubfinanzierung des Ministeriums für Wirtschaft, Innovation und Qualifikation gegründet, unterstützt von Vint Cerf, mit LINX, AAISP, Timico und Easynet dahinter. Im Dezember 2012 traten seine ehrenamtlichen Direktoren auf der Mitgliederversammlung zurück, niemand kandidierte für das Board, und es wurde abgewickelt. Sein Abschiedsurteil: Marktanreize reichen nicht, „one factor appears to dominate IPv6 adoption rates, namely government support“, und „countries with hands-off governments fall behind.“\nVierzehn Jahre später ist genau das passiert. Das UK IPv6 Council gibt es noch, aber ein Forum ist kein Hebel.\nVergleich das mit den Vereinigten Staaten, wo OMB-Memorandum M-21-07 verlangte, dass 80 % der IP-fähigen Anlagen des Bundes bis zum Ende des Haushaltsjahres 2025 IPv6-only sind. Die Behörden haben es verfehlt. Sie hatten trotzdem eine Zahl zum Verfehlen, ein Datum, bis zu dem sie es verfehlen konnten, und jemanden, der aufstehen und das Verfehlen erklären muss. Hier gibt es nichts zu verfehlen, also hat nie jemand irgendetwas erklären müssen.\nDie britische Regierung verlangt IPv6 in ihrer eigenen Beschaffung in keiner nennenswerten Weise. Ofcom misst es nicht. Keine Aufsicht fragt danach. Und so haben www.nhs.uk und www.hmrc.gov.uk es erwartungsgemäß nicht, während www.gov.uk es hat. Und www.gov.uk hat es nur, weil es über Fastly ausgeliefert wird, das IPv6 vor Jahren im Auftrag anderer eingeschaltet hat.\nIch habe schon einmal darüber geschrieben, was passiert, wenn niemand einen Vertrag über eine Branche hält — die Mechanismen, die funktionieren, erweisen sich als die, die jemand mit Mitteln zu bedienen beschließt, und wenn es niemand tut, passiert ein Jahrzehnt lang nichts. IPv6 im UK ist wieder dieses Muster, ohne auch nur eine Mitgliederabstimmung am Ende.\nUnd es ist nicht so, dass niemand es bemerkt hätte Das Fehlen einer Anforderung wäre enttäuschend, wenn das unbemerkt geblieben wäre. Ist es nicht.\nDer Staat hat herausgefunden, was Carrier-Grade NAT anrichtet, und Gesetze darüber gemacht. Das Parlament hat direkt auf das Problem geschaut, es gut genug verstanden, um ein Gesetz darüber zu schreiben, und das Gesetz geschrieben, das den Schaden aufnimmt. „Verpflichtet sie, das Protokoll auszurollen, das ihn beseitigt“ wurde entweder nie aufgeworfen oder aufgeworfen und fallen gelassen.\nWir sind also ein Land, dessen erklärte Position ist, dass IP-Zuordenbarkeit wichtig genug für Antiterrorgesetzgebung ist, und das keinen einzigen Anbieter bittet, das kostenlose Ding zu tun, das sie wiederherstellt. Betrug, Kontoübernahme, Belästigung, Morddrohungen, Meldungen über Kindesmissbrauch und Terrorismus kommen alle beim Zugangsnetz an und stellen dieselbe Frage, und für viele britische Anschlüsse lautet die ehrliche Antwort „einer dieser mehreren hundert Haushalte“.\nDas National Cyber Security Centre gehört zum GCHQ und veröffentlicht Leitlinien zu sehr vielen Dingen. Es verlangt von niemandem IPv6. Niemand in Britannien tut das.\nwww.ncsc.gov.uk und www.gchq.gov.uk antworten allerdings beide auf IPv6. Die Internet Watch Foundation auch. Alle drei, weil sie hinter Cloudflare sitzen, das es standardmäßig für alle eingeschaltet hat. www.police.uk hat keines.\nUnd was das für die siebzehn bedeutet Siebzehn der vierzig Anbieter in diesem Beitrag verkaufen Anschlüsse ohne IPv6, und etwa die Hälfte der Glasfaserbauer setzt Kunden hinter Carrier-Grade NAT.\nIch beschuldige keinen von ihnen einer Straftat, und niemand in diesen Gebäuden hofft auf eine.\nAber ein Anschluss hinter Carrier-Grade NAT ohne IPv6 kann keinem Teilnehmer zugeordnet werden. Das ist unbestritten. Die IETF hat es 2011 aufgeschrieben, Europol 2016 und 2017, das Parlament 2015 — alles veröffentlicht, bevor der Großteil dieser Ausrüstung gekauft wurde. Die Alternative war kostenlos und die ganze Zeit verfügbar.\nDas ist es, was „wir kommen irgendwann zu IPv6“ bedeutet, wenn man es zu Ende verfolgt.\nWas konkret zu tun ist Kurz, denn nichts davon ist schwer. Das ist der Punkt des ganzen Beitrags.\nWenn du Konnektivität einkaufst: schreib IPv6 als Muss-Kriterium in die Ausschreibung, nicht als Kann. Verlang natives Dual-Stack und ein delegiertes Präfix, schriftlich, und frag nach der Größe.\nWenn die Antwort ein einzelnes /64 ist, frag weiter. RFC 6177 hat das 2011 erledigt: einem Heimstandort ein /64 zu geben „precludes the expectation that even home sites will grow to support multiple subnets“, und es ist „strongly intended that even home sites be given multiple subnets worth of space, by default“.\nWas es nicht getan hat, ist eine Größe zu nennen. Es zog das alte pauschale /48 zurück, sagte, die Wahl „is an issue for the operational community“, und ließ im Vorbeigehen ein Rechenbeispiel fallen: als Heim-Standard „of less than /48, such as a /56“.\nDie Betreiber haben es selbst beantwortet. RIPE-690 ist ihr eigenes Praxisdokument und es ist unverblümt. Ein /48 je Kunde, wenn du einen einfachen Plan willst. Ein /48 für Geschäftskunden und ein /56 für Privatkunden, wenn du einen pragmatischen willst. Alles länger als ein /56 ist „strongly discouraged“, und ein /64 entspricht nicht den IPv6-Standards und macht Kunden-LANs kaputt.\nDer Boden ist also ein /56, und es ist die Zahl der IETF selbst und nicht irgendjemandes Vorliebe. Sky gibt jedem Teilnehmer seit 2016 eines. Zen gibt ein /48 aus, das sind 65.536. Ein Unternehmen sollte sich mit weniger als einem /48 nicht zufriedengeben.\nWenn dir ein Anbieter sagt, ein /48 an ein Haus sei verschwenderisch: ein britischer ISP macht das seit Jahren, während sie noch an ihrer Position arbeiteten.\nWenn du eine AS-Nummer betreibst: du hältst wahrscheinlich schon ein /29, das du nie angekündigt hast. Prüf es.\nAS=AS20712 # deine AS-Nummer ORG=$(whois -h whois.ripe.net \u0026#34;$AS\u0026#34; | awk \u0026#39;/^org:/{print $2; exit}\u0026#39;) # welches IPv6 die Registry dir schon gegeben hat whois -h whois.ripe.net -- \u0026#34;-i org $ORG\u0026#34; | grep -i \u0026#39;^inet6num\u0026#39; # was du davon tatsächlich ankündigst whois -h whois.ripe.net -- \u0026#34;-i origin $AS\u0026#34; | grep -i \u0026#39;^route6\u0026#39; Wenn der erste Befehl ein Präfix ausgibt und der zweite nichts, bist du einer der 463.\nKündige es an, dual-stack deinen Rand und ein internes VLAN, und setz ein AAAA auf einen öffentlichen Dienst. Das ist zwei Wochen Arbeit für einen Ingenieur, und es macht aus deiner Organisation statt einer Statistik in der Tabelle oben eine, die angefangen hat.\nWenn du eine Website betreibst: prüf auf einen AAAA-Eintrag. Wenn du hinter einem CDN sitzt, ist es wahrscheinlich ein Schalter, den du heute Nachmittag kostenlos umlegen kannst. Wenn er aus ist, hat ihn jemand ausgeschaltet.\nWenn du Managed Services verkaufst: schreib IPv6 einmal in den Baustandard und die Vorlage fürs Feindesign, und jeder Kunde danach bekommt es standardmäßig. Niemand muss danach fragen, denn nach TLS fragt auch niemand.\nWenn du ein Ingenieur bist, der es nie gemacht hat: bau heute Abend ein Labor. Rund 90 % meines eigenen Verkehrs läuft über natives IPv6 und es ist das Unaufregendste an meinem Netz. Hol dir einen Tunnel oder einen VPS mit einem /64, setz Adressen auf Dinge, mach es kaputt, repariere es. Es dauert einen Abend, bis es aufhört, beängstigend zu sein, und es ist das mit Abstand Billigste, was du dieses Jahr für deine Laufbahn tun kannst.\nDie Fragen, die ich nicht klären kann Alles oben kann ich dir zeigen. Dieser Teil ist das, was ich immer wieder wende, und ich habe auf nichts davon eine saubere Antwort.\nWarum können manche und andere nicht? Das ist die Frage, auf die es ankommt, und die Daten machen sie eher seltsamer als klarer.\nSky und Virgin Media haben demselben Land Breitband verkauft, unter derselben Aufsicht, zur selben Zeit. Der eine war 2016 fertig. Der andere sagt seit 2010 „wenn wir so weit sind“. Sainsbury\u0026rsquo;s und Tesco sitzen auf demselben CDN, bei einem Produkt, bei dem Dual-Stack der Standard ist, und der eine hat IPv6 und der andere nicht. Norwegen und Britannien kaufen bei denselben Herstellern, und 66,9 % der norwegischen Netze führen IPv6 gegen 42,3 % der unseren.\nJeder äußere Faktor, den man beschuldigen könnte, ist in diesen Paaren konstant gehalten. Gleiches Land, gleiche Lieferanten, gleiche Geräte, gleiche Kunden, gleiches Jahrzehnt, gleiche Aufsicht, gleiches Geld. Und die Ergebnisse sind entgegengesetzt.\nDie Ursache liegt also nicht in den Umständen. Sie liegt im Gebäude. Irgendwo bei Sky gab es einen Menschen, der das zu seiner Sache machte und es drei Jahre lang zu seiner Sache behielt. An den anderen Orten gab es den nicht, oder es gab ihn und niemanden über ihm hat es gekümmert. Das ist die ganze Variable, und sie ist keine technische.\nWas eine unbequeme Antwort ist, denn du kannst sie nicht beschaffen, und du kannst sie nicht in ein Strategiepapier schreiben.\nLiegt es an der Ausbildung? Teilweise, und weniger, als du denken würdest.\nSchau noch einmal auf die 463 Läden, die IPv6 halten, das sie nie angekündigt haben. Jemand in jedem dieser Gebäude wusste genug, um zu wissen, dass sie es brauchen, wusste, wen man fragt, füllte das Formular aus und bekam es ausgestellt. Das Wissen war da und das Durchziehen nicht.\nAusbildung bringt einen Ingenieur dahin, es zu können. Sie bringt ihn nicht dahin, dazu gebracht zu werden. Niemand hat je eine schlechte Beurteilung dafür bekommen, IPv6 nicht ausgerollt zu haben. Niemand hat je deswegen einen Auftrag verloren. Bis eines davon zutrifft, landet die Ausbildung auf dem Stapel mit allem anderen, was jemand in einem Kurs gelernt und nie benutzt hat.\nWie lange, bis wir alle darauf sind? Auf die kann ich eine Zahl setzen, und sie ist schlimmer, als ich erwartet hatte.\nGoogle misst seit 2008 den Anteil seiner eigenen Besucher, die über IPv6 ankommen. Jeweils Mitte August genommen, damit es Gleiches mit Gleichem ist:\nDie weltweite IPv6-Verbreitung bremst vor der Hälfte ab Die weltweite IPv6-Verbreitung wird langsamer, nicht schneller Anteil von Googles eigenen Besuchern, die über natives IPv6 ankommen, jeweils Mitte August. Quelle: Google-IPv6-Statistik. 0\u0026#160;% 10\u0026#160;% 20\u0026#160;% 30\u0026#160;% 40\u0026#160;% 50\u0026#160;% 2017 18,1 % 2018 2019 2020 2021 2022 2023 2024 2025 2026 48,1 % Punkte in dem Jahr dazu +3,6 +5,0 +4,4 +3,3 +4,3 +3,3 +2,3 +2,6 +1,1 Dieses Jahr kamen\u0026#160;1,1 Punkte dazu, der kleinste Zuwachs seit zehn Jahren, gegen 6,6 Punkte bis August 2017. Googles Messung seiner eigenen Besucher, die über natives IPv6 ankommen, jeweils Mitte August genommen, damit es Gleiches mit Gleichem ist. Die Linie ist der Stand. Die Balken sind, was jedes Jahr dazugekommen ist. Wir beschleunigen nicht auf die Ziellinie zu. Wir bremsen vor der Hälfte ab. Dieses Jahr brachte 1,1 Punkte, den kleinsten Zuwachs seit einem Jahrzehnt, gegen 6,6 Punkte im Jahr bis August 2017.\nZieh die Gerade aus den letzten drei Jahren und die Welt erreicht 100 % im Jahr 2049. Zieh sie allein aus diesem Jahr und es ist 2073. Keines davon ist eine Prognose. Eine Kurve, die abflacht, erreicht die Spitze überhaupt nicht durch Trägheit. Sie bleibt irgendwo in den Sechzigern stehen und der Rest bewegt sich nie, denn die Netze, die es bis dahin nicht getan haben, sind die, die ohnehin nichts bewegt hätte.\nIch läge da gern falsch. Die Zahl ist jedes Jahr kleiner geworden, in dem ich sie mir angesehen habe.\nBrauchen wir ein Gesetz? Bei der bin ich am meisten hin und her gegangen, und ich bin bei „nicht das Gesetz, nach dem die Leute greifen“ gelandet.\nGegen ein Gebot: die Amerikaner haben das stärkste erlassen, das irgendwer hat, und es verfehlt. Eine Frist ist kein Rollout.\nDafür: 6UKs Abschiedsurteil von 2012 war, dass Marktanreize nicht reichen und dass die Länder, die zurückfallen, die mit zurückhaltenden Regierungen sind. Vierzehn Jahre britischer Daten stimmen ihnen zu.\nUnd hier ist der Teil, der es entscheidet. Dieses Land hat zu diesem Problem bereits Gesetze gemacht — es hat sie nur in die falsche Richtung gemacht. Wir waren bereit, Gesetze zu machen, um Adressteilung aufzunehmen. Wir waren nie bereit, Gesetze zu machen, um sie zu beseitigen.\nWas ich fordern würde, ist kein Verbot und kein Ziel, sondern das belgische Instrument, weiter oben beschrieben: eine harte Grenze dafür, wie viele Teilnehmer sich eine Adresse teilen dürfen. Es braucht keine neuen Adressen, es schließt niemanden vom Markt aus, und es wirkt über die Wirtschaftlichkeit statt über jemandes guten Willen.\nEin Gebot allein bringt eine nützliche Sache hervor, und es ist nicht der Rollout. Es ist eine benannte Person, die das Verfehlen erklären muss. So eine hatten wir nie.\nWie sind wir dann so schnell auf IPv4 umgestiegen? Weil jemand das alte abschalten konnte.\nDer Vergleich ist exakt, und fast niemand zieht ihn. Das ARPANET fuhr das Network Control Program, das Hosts mit 8 Bit adressierte — 6 für den Knoten und 2 für den Host, also 64 Knoten zu 4 Maschinen, insgesamt 256 Hosts. Ende der 1970er war das offensichtlich nicht genug, und die Antwort war ein neues Protokoll mit einer größeren Adresse. Dasselbe Problem, das wir jetzt haben, gut vierzig Jahre früher.\nJon Postel veröffentlichte den Übergangsplan im November 1981. Im März 1982 erklärte das US-Verteidigungsministerium TCP/IP zu seinem offiziellen Standard. Beide Protokolle liefen nebeneinander, und am 1. Januar 1983 wurde NCP abgeschaltet. Hosts, die nicht umgestellt hatten, verloren den Zugang zum Netz. Vint Cerf erinnert sich an „I survived the TCP/IP switchover“-Anstecker, die danach von denen getragen wurden, die durchgekommen waren.\nVierzehn Monate vom Plan zum Stichtag.\nJetzt zähl, was das möglich gemacht hat. Grob ein paar hundert Hosts, nicht vier Milliarden. Ein Netz, nicht jedes Netz. Ein Geldgeber, dem jede Maschine darin gehörte und der die Löhne aller zahlte, die sie anfassten. Eine einzelne Organisation, die ein Datum setzen konnte, und — das ist der entscheidende Teil — die das alte Protokoll an diesem Datum aufhören lassen konnte zu funktionieren.\nNichts davon existiert heute, und das ist die ganze Antwort. IPv4 hat nicht gewonnen, weil die Migration einfach war. Es hat gewonnen, weil jemand in der Lage war, die Diskussion zu beenden.\nHeute ist niemand in dieser Lage. Es gibt keine Autorität, die IPv4 abschalten kann, und es wird nie eine geben. Was heißt, dass dieser Übergang nicht auf die Art beendet werden kann wie der letzte — er kann nur dadurch beendet werden, dass mehrere tausend Läden jeder für sich beschließen, sich zu bemühen.\nNach den Zahlen dieses Jahres landet das 2073. Neunzig Jahre nach dem Stichtag.\nWir haben Dinge früher ordentlich gemacht Ein Standard ist etwas, das man einhält, wenn niemand hinsieht. Das ist alles. Es gibt dafür keinen Prüfer, kein Zertifikat, keinen Auditor, der auftaucht und deine Routingtabelle sehen will, und zwanzig Jahre haben nun genau gezeigt, was dieses Land mit einer Pflicht macht, die niemand durchsetzt.\nWir lassen sie fallen, und dann kaufen wir etwas, um die Lücke abzudecken.\nNichts davon ist ein technisches Versagen und ich tue nicht so, als wäre es eines. Britannien kann diese Arbeit. Die Fähigkeiten sind hier, die Geräte sind hier, der Adressraum ist ausgegeben und liegt wartend in Konten, die wir ohnehin bezahlen. Was weg ist, ist der Instinkt, eine Arbeit ordentlich zu machen, weil sie die Arbeit ist — ohne extra dafür bezahlt zu werden und ohne dass jemand über einem steht und einen dazu bringt.\nFrag, was es tatsächlich aufhält, und du landest beim Geld, aber nicht so, wie die Leute es meinen.\nEin Carrier-Grade NAT hat eine Bestellnummer. Es hat einen Hersteller, ein Angebot, einen Rabatt, einen Supportvertrag und ein Verlängerungsdatum. Es kommt in die Investitionsplanung, es wird über fünf Jahre abgeschrieben, und jemandes Name steht auf dem Business Case. Es zu liefern ist ein sichtbares Ding, auf das ein Manager in einer Beurteilung zeigen kann.\nIPv6 hat nichts davon. Keine Rechnung, keinen Lieferanten, keine Verlängerung, nichts, was in ein Budget kommt, und nichts, wovon irgendwer sich nachsagen lassen kann, es gekauft zu haben. Es ist einfach Arbeit, ordentlich gemacht, von Leuten, die wissen, was sie tun, ohne Rendite in diesem Quartal. Niemand in dieser Branche ist je für etwas befördert worden, das nie in einem Budget auftauchte.\nAls solches verliert die billigere Option, jedes Jahr, seit zwanzig Jahren. Nicht weil irgendwer es abgewogen und falsch entschieden hätte, sondern weil hier eine Managementkultur gewachsen ist, die nur die Teile der Technik sehen kann, die mit einem Preis daran ankommen. Billig war nie das Hindernis. Nicht abrechenbar war es. So sieht es aus, wenn ein Unternehmen aufhört, sich um Standards zu scheren, und nur noch darum, was es auf eine Rechnung schreiben kann, und es ist eine Entscheidung von Leuten, die gut genug bezahlt werden, um es besser zu wissen.\nDann ist da, was sie uns statt einer Adresse verkauft haben, und das sollte die Leute wütender machen, als es das tut.\nDas Internet wurde so gebaut, dass jede Maschine jede andere Maschine direkt erreichen kann. Kein Detail des Entwurfs. Der Entwurf. Deshalb konnte jeder mit einem Anschluss und einer Idee etwas hinstellen, das die ganze Welt erreichen konnte. Setz einen Kunden hinter eine geteilte Adresse und das ist weg. Du kannst fragen, aber du kannst nie antworten. Du bist dauerhaft Konsument der Dienste anderer Leute und nie Anbieter deiner eigenen.\nDas ist kein bedauerlicher Nebeneffekt einer Knappheit. Es ist eine Neuarchitektur, und sie passt allen, die sie verkaufen. Die Kamera, die jetzt die Cloud des Herstellers braucht. Der Fernzugriff, der jetzt jemandes Relay braucht. Das Ding, das die Leute früher zu Hause betrieben und das jetzt ein Monatsabo ist. Jedes davon ist jemand, dem etwas gehörte, umgewandelt in jemanden, der es mietet, und ein Anschluss, still herabgestuft von einem Platz im Internet zu einem Fenster auf das von jemand anderem.\nWir haben die Mitte des Internets einer Handvoll Firmen auf einem anderen Kontinent überlassen und dann überrascht dagestanden, dass es zentralisiert endete. Du kannst nicht selbstständig sein auf einem Anschluss, der dich nowt hosten lässt.\nSelbstständigkeit ist der Teil, auf den ich immer wieder zurückkomme, denn dieses Land hat aufgehört, sie von sich zu erwarten. Der Instinkt ist jetzt zu warten. Auf einen Hersteller, eine Aufsicht, eine Förderung, ein Gebot, einen Kunden, der anruft und fragt. Nichts davon kommt. Es ist kein Marktsignal unterwegs, keine Politik im Entwurf, keine Frist, deren Verfehlen irgendwer erklären müsste.\nWas es dort lässt, wo es die ganze Zeit war. Eine kostenlose Zuteilung, die in einem Registry-Konto mit dem Namen deiner Firma darauf liegt, und zwei Wochen zwischen dir und der ordentlich gemachten Arbeit.\nNiemand kommt, um dich dazu zu bringen. Genau deshalb zählt es.\nDu kannst nachsehen, ob es dein Gebäude ist. Das Skript liegt im Download oben im Beitrag.\nQuellen Alles unten wurde am 27. August 2026 abgerufen.\nDie Daten, aus denen ich gemessen habe. Jede Zahl von mir kommt daher. Sie sind kostenlos, sie sind öffentlich, und du kannst das Ganze an einem Nachmittag wiederholen.\nDelegierungsdateien der Registries, eine je regionaler Registry: RIPE NCC, APNIC, ARIN, LACNIC, AFRINIC. Die von RIPE wurde am 26. August 2026 erzeugt, der Rest am 27. August 2026. RIPE-RIS-Routingtabellen-Dumps, riswhoisdump.IPv4.gz und riswhoisdump.IPv6.gz, erzeugt am 27. August 2026 um 18:06 UTC. RIPE-Datenbank-REST-Schnittstelle, für die Organisation hinter jeder AS-Nummer. Das öffentliche DNS, für den AAAA-Durchlauf, gegengeprüft an einem zweiten Resolver. Messungen anderer Leute.\nGoogle-IPv6-Statistik — natives IPv6 je Land unter Googles eigenen Besuchern, Zahlen mit Stand 25. August 2026. APNIC zur IPv6-Leistung und zu IPv6-Sicherheitsmissverständnissen — das gemessene Bild statt des Forenbildes. Preise auf dem IPv4-Transfermarkt, erstes Halbjahr 2026, Zusammenfassung von CircleIDs Analyse öffentlich bepreister Transaktionen. Standards. Die Anbauten, in der Reihenfolge ihrer Veröffentlichung.\nRFC 3056 — 6to4, automatisches Tunneln, Februar 2001. RFC 3701 — der Auslaufplan fürs 6bone, der die Abschaltung auf den 6. Juni 2006 setzte. RFC 7526 — Abkündigung der 6to4-Anycast-Relays und Überführung nach Historic, Mai 2015. RFC 4864 — was NAT gibt und was nicht, und warum die Firewall, die Leute zu haben glauben, „an arbitrary artifact“ ist, 2007. RFC 4941, RFC 7217 und RFC 8981 — temporäre und undurchsichtige Adressen, weshalb die IPv6-Adresse eines Geräts kein stabiler Bezeichner ist. RFC 801 — Jon Postels NCP/TCP-Übergangsplan, November 1981, mit dem Stichtag 1. Januar 1983. RFC 1883 — die ursprüngliche IPv6-Spezifikation, Dezember 1995. RFC 6333 — DS-Lite, 2011. RFC 6056 — Quellport-Randomisierung, die Abwehr, die CGN schwächt, 2011. RFC 6269 — Issues with IP Address Sharing, Juni 2011. Der eigene Katalog der IETF dessen, was CGN kaputt macht, einschließlich Missbrauchsprotokollierung, Strafbank, Sperrlisten, Port-Randomisierung und Nachverfolgbarkeit. RFC 791 und RFC 8200 — die zwei Headerformate, und warum IPv6 die Prüfsumme, die variable Länge und die Fragmentierung unterwegs fallen ließ. RFC 6583 — Erschöpfung des Neighbour-Discovery-Caches auf einem /64, und die Trennung von Weiterleitungs- und Steuerungsebene, die entscheidet, was einen Router CPU kostet. RFC 6177 — wie viel Adressraum ein Endstandort bekommen sollte, 2011. Ersetzt das pauschale /48 von RFC 3177, schließt das einzelne /64 aus und übergibt die eigentliche Zahl der operativen Gemeinschaft. RIPE-690 — die eigene Antwort der europäischen Betreiber auf diese Frage, Oktober 2017: /48 oder /56 an einen Endnutzer, nie ein /64. RFC 6302 — Quellport, Zeitstempel und Protokoll protokollieren, 2011. RFC 6598 — Shared Address Space, 2012. RFC 6877 — 464XLAT, 2013. RFC 6888 — Anforderungen an Carrier-Grade NAT, 2013. RFC 7021 — die Auswirkung von Carrier-Grade NAT auf Anwendungen, 2013. RFC 7422 — deterministische Abbildung zur Reduktion der CGN-Protokollierung, 2014. RFC 7597 und RFC 7599 — MAP-E und MAP-T, 2015. World IPv6 Launch, 6. Juni 2012. Hurricane Electrics kostenloser Tunnelbroker — wo viele von uns IPv6 bekamen, während unsere eigenen ISPs keines hatten. Recht und Politik.\nCyber Security and Resilience (Network and Information Systems) Bill 2024-26 — Briefing der House of Commons Library zu dem Gesetzentwurf, der Managed Service Provider in die NIS-Verordnungen holen würde. Counter-Terrorism and Security Act 2015, Abschnitt 21 — Vorratsspeicherung einschlägiger Internetdaten und die zugehörigen Erläuterungen. Europol, Oktober 2017 — Strafverfolgung fordert das Ende von Carrier-Grade NAT, mit den Zahlen 90 % mobil und 50 % Festnetz. OMB-Memorandum M-21-07 — die IPv6-only-Anforderung des US-Bundes, November 2020. Online Safety Act 2023. Europol EC3, Carrier Grade NAT and crime attribution online — Gregory Mouniers Präsentation vor RIPE 74, mit der Umfrage unter EU-Strafverfolgern von August 2016, den Fallbeispielen und dem belgischen Verhaltenskodex samt Ergebnissen. NCMEC-CyberTipline-Daten — Meldungsvolumen und Weiterleitungen 2025. A Multi-perspective Analysis of Carrier-Grade NAT Deployment, ACM IMC 2016 — die unabhängige Messung des CGN-Einsatzes bei Mobil- und Festnetzanbietern. RIPE-NCC-Gebührenordnung 2026 — 1.800 Euro je LIR-Konto, pauschal. Hersteller, in ihren eigenen Worten.\nAkamai, Juni 2022 — Dual-Stack ist der Standard und Kunden müssen sich aktiv abmelden. AWS, 2023 — die Gebühr für öffentliche IPv4, und warum. Berichterstattung und Protokoll.\nSkys eigener Bericht auf RIPE Labs — wie fünf Millionen Nutzer umgezogen wurden. ISPreview, September 2016 — Sky schließt den Rollout ab. CircleID, September 2016 — der Jim Bound IPv6 Award. ISPreview, Dezember 2012 — 6UK wickelt sich selbst ab. ISPreviews Umfrage zu IPv6 und CGNAT bei Altnets — April 2024, aktualisiert im März 2025. ISPreview zu Plusnets IPv6-Test, November 2023 — der Test von 2011, der verpasste Start 2020 und der Hinweis, dass BT und Plusnet nahezu identische Router ausliefern. Ein gemeinschaftlich gepflegter Tracker britischer Mobilfunknetze und IPv6 — von Nutzern gemeldet statt offiziell, und die Quelle dafür, welche Mobilfunknetze heute IPv6 vergeben. havevirginmediaenabledipv6yet.co.uk — die Virgin-Media-Chronologie, 2010 bis heute. Internet Society, September 2016 — Sky bei 90 % seiner Basis, jeder Teilnehmer bekommt ein /56. Internet Society, September 2016 — Ron Broersmas Bericht über die Migration von NCP zu TCP/IP 1983, einschließlich der 256-Host-Grenze und dessen, was mit denen geschah, die die Frist verpassten. The Register, Januar 2013 — dreißig Jahre nach dem Stichtag, und die Anstecker, die die Leute danach trugen. UK IPv6 Council. ","permalink":"https://blogs.damiendye.uk/de/networking/we-never-ran-out-of-addresses/","summary":"IPv6 ist seit fast zwanzig Jahren fertig, kostenlos und in jedem Betriebssystem standardmäßig eingeschaltet. Die Antwort des UK darauf waren Carrier-Grade NAT, ein Gesetz über Protokollierung und 5 Pfund im Monat dafür, dir die Adresse zurückzugeben, die du früher hattest. Ich habe jedes britische Netz in der globalen Routingtabelle gezählt, um herauszufinden, wer IPv6 wirklich eingeschaltet hat — 1.200 haben es nicht, und 463 davon sitzen auf Adressraum, den sie beantragt und nie benutzt haben.","title":"Uns sind nie die Adressen ausgegangen. Uns ist die Mühe ausgegangen."},{"content":"Offenlegung vorweg: ich arbeite für croit, das Ceph verkauft und in den Tabellen unten auftaucht. Ich habe versucht, mit uns so kritisch zu sein wie mit allen anderen. Jede Zahl kommt aus der öffentlichen Git-Geschichte, aus Cephs eigenen Aufzeichnungen im Baum oder aus einer namentlich genannten öffentlichen Aussage — alles nachvollziehbar, alles in den Quellen am Ende aufgeführt.\nCeph hält eine Menge Technik hoch, an die niemand denkt. Proxmox-Cluster, OpenStack, Kubernetes, nationale Forschungslabore, Banken, Telekommunikationsfirmen, Teilchenbeschleuniger. Zwanzig Jahre später ist es noch die erste Antwort, wenn jemand Block-, Datei- und Objektspeicher aus einem Cluster aus gewöhnlicher Hardware will.\nWer schreibt es also, wer pflegt es, und wer betreibt es?\nNicht „wer steht auf der Mailingliste“ oder „wer hat auf der Cephalocon gesprochen“. Ich habe ceph/ceph geklont, jeden Commit ohne Merge genommen, der in den zehn Jahren bis 2026-08-27 verfasst wurde, und die Autoren über Cephs eigene .organizationmap plus einen dokumentierten Satz Korrekturen auf Firmen abgebildet. Dann habe ich Cephs Governance-Datei aus dem Baum genommen und alle 38 Mitglieder des Steering Committee zu dem Arbeitgeber in ihrer eigenen veröffentlichten Adresse verfolgt. Dann habe ich nachgesehen, wer öffentlich sagt, dass er es betreibt.\nDas Jahrzehnt Rang Organisation Commits Anteil 1 Red Hat 42.354 60,8 % 2 SUSE 6.191 8,9 % 3 IBM 4.308 6,2 % 4 Intel 2.066 3,0 % 5 ZTE 1.176 1,7 % 6 QiAnXin 900 1,3 % 7 Ceph Foundation 691 1,0 % 8 Mirantis 566 0,8 % 9 IONOS 498 0,7 % 10 China Mobile 397 0,6 % 11 Proxmox 254 0,4 % 12 croit 242 0,3 % 13 Cloudbase Solutions 239 0,3 % 14 Bloomberg 231 0,3 % 15 XSKY 225 0,3 % — Clyso 181, Huawei 159, Inspur 155, Cafe Bazaar 130, CERN 121, SK Telecom 120, UMCloud 106, Deutsche Telekom 105, EasyStack 103, ISCAS 99, Tencent 83 und 460 weitere Organisationen — Kein Arbeitgeber in der Adresse sichtbar 6.295 9,0 % Zeile 1 und Zeile 3 sind dasselbe Team. Am 4. Oktober 2022 haben Red Hat und IBM angekündigt, dass Red Hats gesamtes Ceph-Team zu IBM wechselt, wobei IBM Red Hats Sponsoring der Foundation übernahm und hilft, das Upstream-Testlabor zu finanzieren. Die Menschen haben sich nicht geändert; ihre E-Mail-Adressen ziehen vier Jahre später noch um, ein Ingenieur nach dem anderen.\nZusammengezählt: 46.662 Commits. 67,0 % des Jahrzehnts.\nSetz dich damit hin, bevor du etwas anderes liest, denn das ist der Handel, der Ceph existieren lässt. Eine Firma hat Dutzende Ingenieure dafür bezahlt, verteilten Speicher zu bauen und zu betreuen, den sie dann verschenkt. Zehn Jahre davon, durch zwei Übernahmen und einen Wechsel des Eigentümers. Niemand hat sie dazu gezwungen.\nDie letzten drei Jahre Rang Organisation Commits Anteil 1 Red Hat 7.273 45,0 % 2 IBM 3.818 23,6 % 3 QiAnXin 597 3,7 % 4 Ceph Foundation 526 3,3 % 5 IONOS 498 3,1 % 6 Intel 279 1,7 % 7 Proxmox 249 1,5 % 8 Bloomberg 220 1,4 % 9 croit 157 1,0 % 10 Clyso 153 0,9 % 11 Cafe Bazaar 118 0,7 % 12 ISCAS (Institute of Software, Chinese Academy of Sciences) 99 0,6 % — Kein Arbeitgeber in der Adresse sichtbar 2.008 12,4 % 16.160 Commits. Red Hat plus IBM: 11.091, oder 68,6 %.\nDer Anteil einer Firma an Ceph, über ein Jahrzehnt und über drei Jahre Der Anteil bewegt sich nicht. Was darin steckt, schon. Zehn Jahre bis 2026-08-27 69.613 Commits Red Hat\u0026#160;\u0026#160;60,8 % IBM 6,2 % SUSE 8,9 % alle anderen\u0026#160;\u0026#160;24,1 % Red Hat + IBM: 46.662 Commits, 67,0 % Letzte drei Jahre 16.160 Commits Red Hat\u0026#160;\u0026#160;45,0 % IBM\u0026#160;\u0026#160;23,6 % SUSE: 13 alle anderen\u0026#160;\u0026#160;31,4 % Red Hat + IBM: 11.091 Commits, 68,6 % SUSE war der zweitgrößte Beitragende des Jahrzehnts. In den letzten drei Jahren schrieb es 13 Commits, und 2025 und 2026 überhaupt keinen. Der Anteil der einen Firma bewegt sich zwischen dem Jahrzehnt und dem jüngeren Fenster kaum — 67,0 % gegen 68,6 %. Was sich ändert, ist alles darum herum. Die Widerstandskraft, über die niemand spricht Hier ist der Teil, den ich nicht erwartet habe, und es ist das Beste an der ganzen Übung.\nCeph hat die zwei Ereignisse, vor denen diese Daten dir zu fürchten sagen würden, schon überlebt, und es hat nicht gezuckt.\nSein Schöpfer, Sage Weil, schrieb 7.517 Commits über das Jahrzehnt — mehr als jede Organisation außer Red Hat, SUSE und IBM. Allein 2017 schrieb er 2.184 Commits, 21,5 % des ganzen Projekts, im Alleingang. Er ist im Oktober 2021 zurückgetreten, nach 17 Jahren; sein letzter Commit ist auf 2022-01-20 datiert.\nDer zweitgrößte Beitragende des Jahrzehnts, SUSE, schrieb 6.191 Commits und erreichte in einem Jahr einen Höchststand von 1.839. Dann strich es SUSE Enterprise Storage für Ranchers Longhorn und fuhr herunter: 463 im Jahr 2021, 110 im Jahr 2022, 14 im Jahr 2023, 10 im Jahr 2024, seither nichts.\nBeides innerhalb derselben fünf Jahre. Wäre ein so konzentriertes Projekt zerbrechlich, dann wäre es damals gebrochen.\nEs ist nicht gebrochen. Die Commit-Rate dieses Jahres liegt bei 14,6 am Tag gegen 14,8 im letzten Jahr. Flach. Veröffentlichungen kamen weiter. Die Governance wurde in ein Executive Council und ein Steering Committee mit 38 Personen umgebaut, und sie hielt.\nJahr Commits insgesamt Red Hat + IBM Anteil Alle anderen 2016 10.286 5.834 56,7 % 4.452 2017 10.158 6.942 68,3 % 3.216 2018 8.099 5.265 65,0 % 2.834 2019 9.000 5.934 65,9 % 3.066 2020 8.361 5.230 62,5 % 3.131 2021 7.381 4.517 61,1 % 2.864 2022 4.731 2.937 62,0 % 1.794 2023 4.634 3.315 71,5 % 1.319 2024 5.410 3.571 66,0 % 1.839 2025 5.389 3.730 69,2 % 1.659 2026 3.495 2.329 66,6 % 1.166 (2026 läuft bis zum 27. August, also etwa acht Monate.)\nZwischen 57 und 72 Prozent von einem Hersteller, jedes Jahr, ein Jahrzehnt lang. Das Volumen liegt unter dem Höchststand von 2016, und das passiert, wenn ein Projekt aufhört, seine Fundamente neu zu bauen, und anfängt, sie zu betreuen. Die letzten drei Jahre sind flach oder eine Spur aufwärts.\nCephs Commit-Volumen nach Jahr — der Anteil hält, die Summe halbiert sich Commits je Jahr, und wer sie geschrieben hat Cephs main-Zweig, Commits ohne Merges, nach Autorendatum 0 3k 6k 9k 12k 2016 57 % 2017 68 % 2018 65 % 2019 66 % 2020 63 % 2021 61 % 2022 62 % 2023 72 % 2024 66 % 2025 69 % 2026* 67 % Red Hat + IBM — ein Team seit Oktober 2022 alle anderen SUSE-Höchststand: 1.839 Sage Weil geht SUSE: 110 im Jahr 2022, 14 im Jahr 2023, 0 bis 2026 * 2026 läuft bis 27. August; aufgetragen mit der heutigen Tagesrate von 14,6 Commits, gegen 14,8 für 2025. Commit-Volumen nach Jahr, aufgeteilt zwischen dem Red-Hat-/IBM-Team und allen anderen. Markiert: SUSEs Höchststand und Ausstieg, und Sage Weils Abgang. Ceph hat beides ohne Änderung des Takts verkraftet. Ceph hat die Firmen überlebt, die es gebaut haben Das ist die eigentliche Geschichte des Jahrzehnts, und in einem Drei-Jahres-Fenster sieht man sie überhaupt nicht.\nSieh die Zeilen 2, 5, 8, 10, 13 und 15 an. SUSE, ZTE, Mirantis, China Mobile, Cloudbase Solutions, XSKY — plus Inspur, EasyStack, UMCloud, Kylin, UnitedStack, Xtao, Istuary und weitere weiter unten. Zusammen weit über 10.000 Commits. Fast alles davon hat aufgehört.\nSUSE: 6.191 Commits, Höchststand 2020, jetzt null. ZTE: 1.176 Commits, allein 1.071 im Jahr 2016, letzter Commit 2020. Mirantis: 566 Commits, weg. XSKY, EasyStack, Inspur, UMCloud, Kylin, UnitedStack: die Speicher-Kohorte der OpenStack-Zeit, alle heruntergefahren. Jede davon war eine Firma, die ein Produkt auf Ceph gewettet hat. Die Produkte wurden gestrichen oder gedreht. Und Ceph ist noch hier und liefert mit derselben Rate aus, mit ihrem Code noch im Baum und jemand anderem, der ihn betreut.\nDie beste Veranschaulichung ist das Dashboard. Über das Jahrzehnt sieht src/pybind/mgr/dashboard so aus:\nsrc/pybind/mgr/dashboard, zehn Jahre Commits Anteil SUSE 1.408 36,6 % Red Hat 1.177 30,6 % IBM 734 19,1 % Kein Arbeitgeber sichtbar 478 12,4 % Das Ceph-Dashboard war größtenteils SUSEs Arbeit. SUSE hat das Projekt dann ganz verlassen. In den letzten drei Jahren ist dasselbe Verzeichnis 57,5 % IBM und 30,3 % Red Hat, und das Dashboard liefert weiter aus und gewinnt weiter Funktionen.\nDas ist Upstream-First-Entwicklung, die genau die Aufgabe macht, für die sie da ist. Ein Hersteller hat viel hineingesteckt, der Hersteller ist gegangen, und die Nutzer haben die Software behalten. Hätte SUSE dieses Dashboard als geschlossene Schicht obendrauf gebaut, wie es reichlich Speicherhersteller täten, wäre es mit der Produktlinie gestorben. Es ging stattdessen in den Upstream und hat deshalb überlebt.\nDas nächste Jahrzehnt wird von mehreren Firmen gleichzeitig gebaut Crimson ist die Neuschreibung der OSD von Grund auf — des Dienstes, der deine Platten besitzt — auf dem Seastar-Framework, ausgerichtet auf das Modell eines Threads je Kern, das modernes NVMe verlangt. Es ist die größte Wette auf Cephs nächste zehn Jahre. Über das Jahrzehnt:\nsrc/crimson, zehn Jahre Commits Anteil Red Hat 3.038 52,1 % Intel 1.269 21,8 % QiAnXin 824 14,1 % Kein Arbeitgeber sichtbar 450 7,7 % Und über die letzten drei Jahre sind Red Hat und IBM zusammen mit 45,4 % eine Minderheit davon, mit QiAnXin bei 28,4 % und Intel bei 13,4 %.\nDas Wichtigste, was gerade in Ceph gebaut wird, ist tatsächlich eine Aufgabe mehrerer Firmen. Nicht der Fahrplan eines Herstellers mit ein paar angeschraubten Beitragenden — drei Läden machen schwere Ingenieursarbeit am selben Teilsystem, öffentlich, über Jahre.\nQiAnXin verdient eine Anmerkung, denn es ist kein Name, den die meisten Speicherleute kennen. Es ist eine chinesische Firma für Unternehmenssicherheit, 2014 als Tochter von Qihoo 360 gegründet und um 2016 herausgelöst; Qihoo 360 verkaufte seinen restlichen Anteil von 22,6 % im April 2019 an Firmen im Umfeld der China Electronics Corporation, und CEC hielt bis zum Börsengangsantrag 2020 38,3 %. Die Firmengeschichte ist im Git-Log lesbar: ihr führender Beitragender, Xuehan Xu, hat 2017 und 2018 Commits unter @360.cn und ab 2021 unter @qianxin.com. Eine Sicherheitsfirma ohne Speicherprodukt zu verkaufen hat 900 Commits in Cephs zukünftige OSD gesteckt. Das ist ein offenes Projekt, das so arbeitet, wie es draufsteht.\nWer Ceph pflegt, und wer sie bezahlt Code zu schreiben ist eine Sache; die Schlüssel zu halten eine andere. Ceph hält seine Governance im Repository, in doc/governance.rst, und das Ceph Steering Committee ist dort mit Namen und E-Mail aufgeführt. Damit ist die Frage nach Maintainer und Arbeitgeber aus einer primären Quelle beantwortbar statt geraten.\nAchtunddreißig Sitze, verfolgt zu dem Arbeitgeber in der jeweils selbst angegebenen Adresse:\nArbeitgeber Sitze Red Hat 16 IBM 9 Clyso 3 Persönliche Adresse (Anthony D\u0026rsquo;Atri, Myoungwon Oh) 2 croit — Igor Fedotov 1 Bloomberg — Joseph Mundackal 1 Intel — Yingxin Cheng 1 Ceph Foundation — Zac Dover 1 XSKY — Haomai Wang 1 ZTE — Xie Xingguo 1 Ubiquiti — Yehuda Sadeh 1 11:11 Systems — David Orman 1 Red Hat und IBM halten 25 von 38 Sitzen — 65,8 %. Gegen 67,0 % der Commits des Jahrzehnts und 68,6 % der letzten drei Jahre. Das Governance-Gremium spiegelt den Code fast genau, und das ist die gesunde Richtung: die Leute, die die Arbeit machen, haben das Wort, und damit hält niemand ein Veto, das er sich nicht verdient hat.\nSitze im Ceph Steering Committee nach Arbeitgeber — 25 von 38 sind eine Firma Wer Ceph pflegt, nach dem, der sie bezahlt 38 Sitze im Ceph Steering Committee, aus der Adresse, die jedes Mitglied in doc/governance.rst angibt Red Hat IBM Clyso persönliche Adresse je ein Sitz 16 9 3 2 8 croit, Bloomberg, Intel, Ceph Foundation, XSKY, ZTE, Ubiquiti, 11:11 Systems Red Hat + IBM: 25 von 38 Sitzen, 65,8 % Gegen 67,0 % der Commits des Jahrzehnts und 68,6 % der letzten drei Jahre. Das Gremium spiegelt den Code. XSKY und ZTE halten weiter Sitze. Keine der beiden Firmen hat seit 2020 eine Zeile zu Ceph beigetragen. Fünf der 38 haben seit 2021 keinen Commit, oder überhaupt keinen. Steuern ist nicht dieselbe Aufgabe wie Code schreiben — aber zwei dieser Sitze gehören Firmen, die das Projekt ganz verlassen haben. Die 38 Sitze im Ceph Steering Committee nach dem Arbeitgeber in der jeweils angegebenen Adresse, aus doc/governance.rst. Die Zusammensetzung des Gremiums folgt der Verteilung der Commits eng. Zwei Einzelheiten sind es wert, herausgezogen zu werden, und beide sagen etwas Gutes.\nXSKY und ZTE halten weiter Sitze. Keine der beiden Firmen hat seit 2020 eine Zeile beigetragen — Haomai Wangs letzter Commit ist 2020-03-18, Xie Xingguos 2020-07-24, nach 750 Commits im Jahrzehnt. Ceph hat sie nicht hinausgeworfen. Ein Projekt, das den Leuten, die große Teile von BlueStore und der OSD gebaut haben, Jahre nachdem ihr Arbeitgeber davongegangen ist, einen Sitz warmhält, ist keines, das Beitragende als Wegwerfware behandelt.\nYehuda Sadeh sitzt mit einer @ui.com-Adresse im Gremium. Er hat das RADOS Gateway geschrieben — die S3- und Swift-Vordertür auf RADOS, den Reliable Autonomic Distributed Object Store, auf dem alles andere in Ceph sitzt —, angefangen 2008 bei DreamHost, über Inktank, Red Hat und IBM: 972 Commits allein im Jahrzehnt und tausende davor. Im Juli 2025 schrieb er noch cephx-Krypto-Code. Dann machte er im Juni 2026 genau einen Commit, doc: governance/csc: update email address, der seinen eigenen Eintrag auf Ubiquiti änderte. Er hat den Arbeitgeber gewechselt und seinen Sitz behalten. Dein Ansehen reist hier mit dir, und das ist eines der besseren Dinge an der Arbeit im Offenen.\nDie Komponentenleiter Die Komponentenleiter besitzen jedes Teilsystem im Tagesgeschäft:\nKomponente Was es ist Leiter Arbeitgeber Cephadm Cluster ausrollen und verwalten Adam King Red Hat CephFS Das POSIX-Dateisystem Venky Shankar Red Hat Crimson Die OSD der nächsten Generation Matan Breizman Red Hat Dashboard Die Weboberfläche zur Verwaltung Afreen Misbah IBM RADOS Der Objektspeicher, auf dem alles andere sitzt Radosław Zarzyński Red Hat RBD RADOS Block Device — virtuelle Platten Ilya Dryomov Red Hat RGW RADOS Gateway — die S3- und Swift-Schicht Adam Emerson, Eric Ivancich Red Hat NVMe-oF Gateway für NVMe over Fabrics Aviv Caro IBM Seastore Crimsons Speicher-Backend Yingxin Cheng Intel Zehn benannte Leiter, neun bei Red Hat oder IBM, und Seastore — Crimsons Speicher-Backend — von Intel aus geleitet. Über ihnen sitzt das dreiköpfige Executive Council, geschaffen als Sage Weil ging: Dan van der Ster (Clyso), Neha Ojha (Red Hat), Patrick Donnelly (IBM). Clyso hält ein Drittel des höchsten Governance-Gremiums bei 0,3 % der Commits des Jahrzehnts — das Council wurde um Urteilsvermögen und Ansehen gebaut, nicht um Kopfzahlen.\nDie Maintainer sind umgezogen, und der Code ist geblieben Das stärkste Argument dafür, dass Ceph ein echtes Gemeingut ist und nicht das Produkt einer Firma, ist, was passiert, wenn seine Maintainer den Job wechseln. Jeder Einzelne davon ist über Adressen im Repository nachvollziehbar:\nMaintainer (heutiger Arbeitgeber) Laufbahn, nach dem Git-Log Letzter Commit Igor Fedotov (croit) — BlueStore Mirantis (2015–17) → SUSE (2017–24) → croit (2021–) 2026-08-24 Kefu Chai (Proxmox) — Kern, Build Red Hat (2015–22, 4.770 Commits) → XSKY → Proxmox (2025–) 2026-08-18 Radosław Zarzyński (Red Hat) — RADOS-Leiter Mirantis (2015–17) → Red Hat (2017–) 2026-06-16 Dan van der Ster (Clyso) — Executive Council CERN (2013–22) → Clyso (2023–) 2026-03-18 Zac Dover (Ceph Foundation) — Dokumentation selbstständig → Clyso → Ceph Foundation 2026-07-23 Yehuda Sadeh (Ubiquiti) — RGW-Autor DreamHost → Inktank → Red Hat → IBM → Ubiquiti 2026-06-08 Mark Nelson (Clyso) — Leistung DreamHost → Inktank → Red Hat → Clyso 2024-04-16 Xuehan Xu (QiAnXin) — Crimson Qihoo 360 (2017–18) → QiAnXin (2021–) 2026 Je drei Arbeitgeber, in manchen Fällen vier, und die Arbeit lief durch jeden Wechsel weiter. Igor Fedotov hat inzwischen die Ceph-Strategien von zwei seiner Arbeitgeber überlebt und pflegt weiter das Werk, das deine Byte auf die Platte legt. Die ehrliche Antwort auf „was, wenn ein Hersteller geht“ ist also die: die Ingenieure machen weiter.\nWer Ceph tatsächlich betreibt Beiträge sind nur die Hälfte. Hier ist, wer laut sagt, dass er Ceph betreibt, mit den Zahlen, die er selbst veröffentlicht hat.\nOrganisation Öffentlich genannte Installation CERN, die Europäische Organisation für Kernforschung 19 Produktions-Cluster, etwa 73 PB roh, plus 5 weitere in einem neuen Rechenzentrum — das Speicher-Rückgrat unter CERNs IT-Cloud Bloomberg Objektspeicher von hunderten TB bis über 8 PB; 6 PB Rohkapazität im laufenden Betrieb hinzugefügt, eine Steigerung um 50 % an einem Cluster im Betrieb, in unter einer Stunde Wikimedia Foundation Fünf Produktions-Ceph-Cluster — Block für Cloud VPS, S3 über Multisite-RGW, und CephFS für Airflow, Dumps und ML-Lab DigitalOcean Ceph treibt seinen Block-Storage-Dienst über RBD, mit „hundreds of enterprise-class SSDs“ je Region und dreifacher Replikation über Server und Racks OVHcloud „Persistent storage for virtual machines is ensured by Ceph RADOS Block Device“ in seiner On-Prem Cloud Platform Proxmox Liefert Ceph als eingebaute hyperkonvergente Speicheroption in Proxmox VE CERN ist einen näheren Blick wert, denn es ist die ausführlichste öffentliche Darstellung, die irgendwer veröffentlicht hat. Aus einem Vortrag der CERN-IT vom September 2024 von Enrico Bocchi:\nCERN-Ceph, nach Anwendung Rohgröße Cluster Blöcke — OpenStack Cinder/Glance, HDD 3× Replika 25,1 PB 5 Blöcke — Flash, EC 4+2 976 TB 2 Dateisystem — OpenStack Manila, K8s/OKD, HPC, HDD 3× Replika 13,4 PB 5 Dateisystem — Flash, 3× Replika 1,7 PB 4 Objekte — S3, Swift, Sicherungen, HDD EC 4+2 28,2 PB 2 Objekte — Multi-Site, EC 4+2 3,6 PB 1 EC 4+2 ist Erasure Coding, vier Datenstücke zu zwei Paritätsstücken. HPC ist High-Performance Computing, K8s ist Kubernetes und OKD ist dessen Upstream-Distribution. Die Zahlen sind Rohkapazität, vor Replikation und Coding-Overhead.\nNeunzehn Produktions-Cluster, betrieben nach dem genannten Grundsatz „don\u0026rsquo;t put all your eggs in the same basket“, mit fünf weiteren, die in ein neues Rechenzentrum gehen. Die Geschichte des Dienstes ist eine stille Werbung für die Software: 300 TB Proof of Concept 2013, 3 PB produktiv für RBD bis zum Dezember, 3 PB auf 6 PB erweitert ohne Ausfall 2016, S3 und CephFS produktiv 2018, ein ganzer CephFS-Cluster 2022 physisch umgezogen ohne Ausfall, Kernel-RBD produktiv 2023.\nWas es am CERN trägt, ist der aufschlussreiche Teil: GitLab, OpenStack, OpenShift, Kubernetes, Harbor, Jenkins, Grafana, Kafka, OpenSearch, InfluxDB, HTCondor, Slurm, Jupyter, Spark, Zenodo, Indico, und die Virtualisierung von NFS, AFS und CVMFS. Ceph ist dort kein Nebenversuch. Es ist der Boden, auf dem der Rest des Gebäudes steht.\nUnd die Zahl für die ganze Gemeinschaft, aus der eigenen Squid-Veröffentlichungsmitteilung der Linux Foundation: 1 Exabyte Daten über mehr als 3.000 Ceph-Cluster.\nDieses Exabyte ist ein Boden, keine Summe Das ist der Teil, an dem man anhalten sollte, denn er verändert, wie man jede Verbreitungszahl über Ceph liest.\nCephs Telemetrie ist freiwillig. Du wirst nur gezählt, wenn jemand ceph telemetry on --license sharing-1-0 ausführt. Jeder, der es nie ausgeführt hat, ist unsichtbar, und in der Praxis sind das die meisten, denn es ist nicht die Voreinstellung und nichts nervt einen damit.\nNimm jetzt Proxmox dazu. Proxmox VE liefert Ceph als seine hyperkonvergente Speicheroption: drei Knoten, ein paar Klicks in der Weboberfläche, pveceph darunter, und du hast einen Ceph-Cluster. Eine sehr große Zahl von Menschen betreibt Ceph produktiv, ohne sich je selbst als Ceph-Nutzer zu begreifen. Sie sind Proxmox-Nutzer. Sie sind keiner Mailingliste beigetreten, sie werden nie ein Testimonial schreiben, sie haben die Telemetrie nicht eingeschaltet, und sie kommen in keiner Tabelle oben vor.\nJede kleine Hosting-Firma, jeder Managed-Service-Anbieter, jeder Universitätslehrstuhl, jedes Homelab, das still in Produktion gegangen ist, und jeder Drei-Knoten-Cluster im Büro in dieser Klammer ist eine echte Ceph-Installation, die keine Zahl in diesem Beitrag zählt. Dasselbe gilt für jeden, der Ceph über Rook auf Kubernetes bekommt, oder in einer Hersteller-Appliance, die nie sagt, was unter dem Deckel liegt.\n1 EB über 3.000 Cluster ist also die Zahl aus den Clustern, die die Hand gehoben haben. Der wirkliche Bestand ist ein gutes Stück größer, und niemand weiß, um wie viel. Das ist eine seltsame Lage für Infrastruktursoftware — normalerweise weiß der Hersteller es, denn du musstest eine Lizenz kaufen —, und es folgt unmittelbar daraus, dass das Ding kostenlos ist.\n478 Organisationen haben Code eingebracht Das Commit-Log ist gleichzeitig eine Liste derer, die Ceph in großem Maßstab betreiben, denn eine Firma, die Patches schickt, ist fast immer eine Firma, die das Ding betreibt. Über das Jahrzehnt tauchen 478 verschiedene organisatorische E-Mail-Domains auf, 140 davon mit fünf oder mehr Commits.\nDie Namen, gruppiert, allein aus dem Git-Log:\nHersteller von Chips, Platten und Hardware: Intel, Samsung, Seagate, SanDisk, Western Digital, Quantum, Mellanox, Lenovo, Fujitsu, Hitachi, Nokia, Arm, Linaro, HiSilicon, Synology, 45Drives Clouds und Hoster: DigitalOcean, OVH, IONOS, Akamai, Linode, Hetzner, Binero, City Network, iland, 11:11 Systems, Vexxhost, StackHPC, Canonical, Deutsche Telekom, China Telecom, China Unicom, China Mobile, Chunghwa Telecom Internet- und Unternehmensnutzer: Bloomberg, eBay, GoDaddy, Flipkart, Wikimedia, Naver, LINE, Kakao, SK Telecom, Alibaba, Tencent, Baidu, ByteDance, Kuaishou, UnionPay, SenseTime, Sangfor, Micro Focus, MITRE, Igalia, Walmart Labs Speicherhersteller und Integratoren: SUSE, Mirantis, XSKY, EasyStack, Inspur, UMCloud, Kylin, UnitedStack, H3C, Xtao, Eisoo, Cloudin, Istuary, ProphetStor, SoftIron, Bigtera, Cloudbase Solutions, Digiware, Bisect, 42on, croit, Clyso, Proxmox, DreamHost Forschung und Bildung: CERN, das Institute of Software der Chinese Academy of Sciences (ISCAS), die Pennsylvania State University, die Boston University, die University of Michigan, die Carnegie Mellon University, plus die Associate-Mitglieder der Foundation — FAS Research Computing in Harvard, das Greek Research and Technology Network (GRNET), die Monash University, das South African Radio Astronomy Observatory (SARAO), der Science and Technology Facilities Council (STFC), SWITCH, SLAC in Stanford, und das Center for Research in Open Source Software (CROSS) an der UC Santa Cruz Nicht alle davon sind aktuell, und das ist der Sinn, ein Jahrzehnt anzusehen. Es zeigt die ganze Spannweite derer, die sich auf diese Software so schwer gestützt haben, dass sie Patches zurückgeschickt haben, und wie breit diese Streuung war.\nDie Akteure, die sagen, sie stützten Ceph, gegen das, was sie liefern Die gestufte Mitgliedschaft der Foundation ist, wo Firmen Unterstützung erklären. Die Stufen folgen nicht der Ingenieursarbeit, und die klarste Veranschaulichung kommt von den drei Diamond-Mitgliedern, die in der eigenen Ceph-Squid-Veröffentlichungsmitteilung der Linux Foundation zitiert werden.\nDiamond-Mitglied Was es öffentlich sagte Commits, letzte 3 Jahre IBM — Vincent Hsu, IBM Fellow, CTO \u0026amp; VP of IBM Storage „reinforce our trust in Ceph and our commitment to open source“ 11.091 (mit Red Hat) Bloomberg — Matthew Leonard, Head of Storage Engineering „Our Diamond Membership is a symbol of our commitment to the future of Ceph and its growing community“ 220 45Drives — Doug Milburn, Co-founder and President „our unwavering commitment to open-source excellence“ 0 IBMs Aussage ist von der größten Ingenieursverpflichtung in der Geschichte des Projekts gedeckt, und noch mehr. Bloombergs ist von 220 Commits, einem Sitz im Steering Committee und einem produktiven Bestand von 8 PB gedeckt, über den sie offen sprechen — nach jedem Maß ein ernster Beitrag. 45Drives baut und verkauft Ceph-Hardware-Appliances und finanziert die gemeinsame Infrastruktur; das ist auch ein echter Beitrag, und es ist kein Code.\nDas ganze Bild über die Stufen:\nMitglied Stufe Commits, letzte 3 Jahre IBM Diamond 11.091 (mit Red Hat) Bloomberg Diamond 220 CLYSO Diamond 153 45Drives Diamond 0 Western Digital Platinum 0 42on Gold 1 croit Silver 157 DigitalOcean Silver 13 Canonical Silver 9 OVHcloud, Sony, OSNexus, CloudFerro Silver je 0 Und in die andere Richtung — vier der sieben größten Beitragenden sind überhaupt keine Mitglieder:\nBeitragender Commits Mitglied? QiAnXin 597 Nein IONOS 498 Nein Intel 279 Nicht mehr Proxmox 249 Nein Foundation-Stufe gegen Commits — das Geld und der Code haben nichts miteinander zu tun Was sie zahlen, gegen das, was sie geschrieben haben Ceph-Foundation-Stufe gegen Commits auf main, 2023-08-27 bis 2026-08-27 200 400 600 Commits DIAMOND IBM, mit Red Hat 11.091 Bloomberg 220 CLYSO 153 45Drives überhaupt nichts PLATINUM Western Digital überhaupt nichts GOLD 42on 1 SILVER croit 157 DigitalOcean 13 Canonical 9 sechs weitere Silver-Mitglieder überhaupt nichts, alle sechs KEINE MITGLIEDER QiAnXin 597 IONOS 498 Proxmox 249 Cafe Bazaar 118 Die sechs Silver-Mitglieder mit nichts: OVHcloud, Sony Interactive Entertainment, OSNexus, CloudFerro, Intelligent Systems, LongVan. Zwei der vier Mitglieder der höchsten Stufe schrieben nichts. Der dritt- und fünftgrößte Beitragende zu Ceph sind überhaupt keine Mitglieder. Foundation-Stufe gegen Commits der letzten drei Jahre. Sponsoring und Ingenieursarbeit sind verschiedene Beiträge — die Stufen messen das erste, nicht das zweite. Ich lese das nicht als Heuchelei, und ich wäre froh, wenn es niemand sonst täte. Das Geld der Foundation bezahlt das Upstream-Testlabor, die kontinuierliche Integration, die jeden Pull Request abfängt, die Cephalocon und das Community-Personal — Dinge, ohne die Ceph nicht könnte, und Dinge, die ein Hardware-Hersteller, der Ceph-Appliances ausliefert, zu Recht finanziert. Western Digital, DigitalOcean und OVHcloud verkaufen alle Produkte, die sich auf Ceph stützen, und sie zahlen in das Gemeingut ein, das es am Laufen hält. Das ist ein fairer Handel.\nDie praktische Lehre ist eng: lies die Mitgliederseite als Liste derer, die die gemeinsame Infrastruktur finanzieren, und das Commit-Log für die, die den Code schreiben. Das sind verschiedene Fragen mit verschiedenen Antworten, und beide Antworten sind nützlich.\nDie Gründungsmitglieder, acht Jahre später Die Foundation wurde am 12. November 2018 gegründet. Die Liste ist zweimal aktenkundig — die Mitteilung der Linux Foundation und die Agenturmeldung —, und sie stimmen genau überein: dreizehn Premier-Mitglieder, zehn General, acht Associate.\nGegen die Mitgliederseite von heute: vier von dreizehn Premier-Mitgliedern sind noch unter ihrem eigenen Namen aufgeführt (Canonical, DigitalOcean, OVHcloud, Western Digital), fünf, wenn man IBM als Red Hats Sitz mitzählt. Zwei von zehn General-Mitgliedern sind übrig — croit und Intelligent Systems.\nUnd alle acht Associate-Mitglieder sind noch da. Ihre vollen Namen, wie die Gründungsmitteilung sie nennt:\nBoston University Information Services and Technology CERN — die Europäische Organisation für Kernforschung FAS Research Computing, Harvard University Das Greek Research and Technology Network (GRNET) Monash University, Melbourne Das South African Radio Astronomy Observatory (SARAO) Der Science and Technology Facilities Council (STFC) bei UK Research and Innovation (UKRI) Das Center for Research in Open Source Software (CROSS) an der University of California, Santa Cruz — wo Ceph überhaupt geschrieben wurde, als Sage Weils Doktorarbeit bei Scott Brandt, Ethan Miller, Darrell Long und Carlos Maltzahn; das ursprüngliche Papier von 2006 liegt noch auf ceph.io Acht von acht, über acht Jahre.\nDie zahlenden Mitglieder haben gewechselt. Die Universitäten und Forschungslabore, die kostenlos beitreten, sind acht Jahre dabeigeblieben, ohne dass eines gegangen wäre. Das sind die Leute, die Ceph in großem Maßstab für die Wissenschaft betreiben, und nicht einer ist davongegangen.\nDie Quincy-Dokumentation trägt noch die Mitgliederliste, wie sie etwa 2022 stand, und die gibt den Halbzeitstand: zwölf der vierundzwanzig kommerziellen Mitglieder in dieser Momentaufnahme sind inzwischen weg, genau die Hälfte. Cephs Takt hat sich in dieser Zeit nicht geändert.\nZu croit, da es mein Arbeitgeber und einer der Überlebenden ist. Die croit GmbH ist am ersten Tag als Gründungs-General-Mitglied beigetreten und ist acht Jahre später noch Mitglied — ein längerer Lauf, als Intel, SUSE, ZTE, Arm oder Samsung geschafft haben. Es sind auch 0,3 % der Commits des Jahrzehnts. Dabeizubleiben ist nicht dasselbe wie zu bauen, und ich werde Langlebigkeit nicht als Beitrag verkleiden, für die Firma, die mich bezahlt.\nDas Handbuch ist eine Person, und die Foundation bezahlt ihn Zeile 7 der Jahrzehnt-Tabelle ist „Ceph Foundation“, 691 Commits. Das ist so gut wie ein Mann.\nZac Dover hat 1.060 Commits über das Jahrzehnt, fast alles Dokumentation. Über die letzten drei Jahre ist er 28,4 % von allem in doc/ — der größte einzelne Beitragende, vor Red Hat und IBM. Seine Adressgeschichte läuft @gmail.com, dann @clyso.com, dann @proton.me, in Cephs eigenen Aufzeichnungen auf die Ceph Foundation abgebildet.\ndoc/, letzte drei Jahre Commits Anteil Ceph Foundation 499 28,4 % Kein Arbeitgeber sichtbar 383 21,8 % Red Hat 379 21,5 % IBM 333 18,9 % doc/ ist das eine Verzeichnis, in dem der größte einzelne Beitragende weder Red Hat noch IBM ist, und man merkt es. Das Ceph-Handbuch ist besser als das, was die meiste Infrastruktursoftware dieser Größe schafft. Einen technischen Autor zu bezahlen, der keinem Hersteller Rechenschaft schuldet, ist das Klügste, was die Foundation mit dem Geld tut.\nEinzelpersonen können die Nadel noch bewegen Die stärksten Einzelpersonen des Jahrzehnts, nach Autorennamen gruppiert:\nPerson Commits im Jahrzehnt Arbeitgeber Sage Weil 7.517 Red Hat — Schöpfer, 2022 gegangen Kefu Chai 5.538 Red Hat → Proxmox Casey Bodley 2.472 Red Hat Patrick Donnelly 2.330 Red Hat → IBM Jason Dillaman 1.629 Red Hat — 2021 gegangen Radosław Zarzyński 1.607 Mirantis → Red Hat Samuel Just 1.415 DreamHost → Inktank → Red Hat John Mulligan 1.300 Red Hat Yingxin Cheng 1.202 Intel Zac Dover 1.060 Ceph Foundation Yehuda Sadeh 972 Red Hat → IBM → Ubiquiti Alfredo Deza 930 Red Hat — 2019 gegangen Einundzwanzig Menschen haben die Hälfte der Commits des Jahrzehnts geschrieben; einundneunzig haben 80 % geschrieben. Das ist für eine große C++-Codebasis normal, und es ist auch, warum Einzelpersonen hier so viel zählen.\nDer klarste Beleg, dass die Tür offen ist: der fünfte Platz der letzten drei Jahre ist ein Ingenieur bei IONOS. Max Kellermann hat seit 2024 498 Commits — mehr als Intel, Proxmox, Bloomberg, croit oder Clyso als Firmen geschafft haben — über src/mds, src/common, src/mon, src/tools, src/librbd, src/mgr und src/rgw. Er ist 19,3 % aller CephFS-Metadatenarbeit im Fenster, nur hinter Red Hat.\nNiemand hat ihn ernannt. Er ist aufgetaucht und hat angefangen, Dinge zu richten, und drei Jahre später ist er einer der geschäftigsten Beitragenden zu einem Projekt, das von einer Fortune-50-Firma geführt wird. Man kann noch in Ceph hineinlaufen und etwas bedeuten.\nProxmox ist die andere Seite derselben Münze: 249 Commits in den letzten drei Jahren, 241 davon von Kefu Chai seit dem 30. September 2025. Proxmox ist in elf Monaten von nichts zu einem Ceph-Beitragenden der Top Ten geworden, indem es einen guten Ingenieur eingestellt hat.\nRGW: wo die Arbeit tatsächlich ist Willst du wissen, wohin Cephs Ingenieursarbeit geht, ist die Antwort Objektspeicher, und der Grund ist einfach: RGW hat den weitesten Weg vor sich, bis es dem gleichkommt, mit dem es konkurriert.\nsrc/rgw ist über das Jahrzehnt das größte funktionale Teilsystem in Ceph — 6.958 Commits, vor Crimsons 5.827, den 4.499 der OSD, den 3.848 des Dashboards, den 2.560 von BlueStore und den 2.546 von CephFS. Es ist viermal so groß wie der Einsatz für die Blockschicht. In den letzten drei Jahren nahm es 1.705 Commits, nur hinter Crimson, und Crimson ist eine Neuschreibung auf grüner Wiese. Bei ausgelieferter Software ist RGW das größte laufende Funktionsprogramm im Projekt.\nAmazons S3 ist ein bewegliches Ziel mit einer riesigen API-Fläche, und jedes Jahr wachsen ihm Funktionen zu, die Kunden dann von allem erwarten, das sich S3-kompatibel nennt. RGW jagt also. Zähl die letzten drei Jahre RGW-Commit-Titel nach Funktionsbereich, und die Form dieser Jagd ist deutlich:\nRGW-Arbeit in den letzten 3 Jahren Commits, die es nennen Multisite-Replikation 94 Accounts 94 IAM — Identitäts- und Zugriffsverwaltung 72 Policy 71 Bucket-Benachrichtigungen 69 STS (zeitweilige Zugangsdaten) 67 Topics 50 Roles 47 Restore 41 POSIX-/Dateisystem-Gateway 40 Serverseitige Verschlüsselung (SSE) 38 Multipart-Upload 32 Lifecycle 16 KMS — Schlüsselverwaltungsdienst 12 S3 Select 11 Prüfsummen 11 Cloud-Übergang 10 Versionierung, CORS, Object Lock, Bucket-Logging, Tagging 28 zusammen (Stichwortzählung über 1.705 Commit-Titel, ein Commit kann also in mehr als einer Zeile auftauchen — der Punkt ist die Verteilung, nicht eine genaue Summe.)\nDas ist keine Pflege. Das sind Identitäts-Accounts, Rollen und Richtlinien, Sitzungstoken, Bucket-Benachrichtigungen und Topics, SSE-KMS, Object Lock, Lifecycle-Regeln, S3 Select, Prüfsummen, Cloud-Tiering und Multisite-Replikation — die AWS-Funktionsliste, ausgebaut. Lies die jüngeren Titel, und du findest Arbeit an der SigV4-Signaturprüfung, an der Behandlung von x-amz-content-sha256, an vorsignierten URLs. Kleinteilige Kompatibilitätsdetails, die Art, die nur zählt, weil irgendjemandes Client-Bibliothek Amazons genaues Verhalten erwartet und ohne es umkippt.\nEs ist auch, warum RGW von den großen Teilsystemen die gemischteste Liste an Beitragenden hat. Über das Jahrzehnt ist Red Hat 64,3 % davon, aber Bloomberg (8,6 % im jüngeren Fenster) und Cafe Bazaar (6,2 %) sind auch dabei — Firmen, die große Objektspeicher produktiv betreiben und die Dinge richten, die sie beißen.\nWägst du Ceph für S3-Arbeit ab, ist das die Zahl, die dich beruhigen sollte. Der Abstand zu Amazon ist der Grund, warum RGW mehr Aufmerksamkeit bekommt als alles andere im Baum, und der größte einzelne Ingenieurseinsatz im Projekt ist darauf gerichtet, ihn zu schließen.\nRBD: stabiler Code, kein Rückgang src/librbd ist Cephs Blockgerät — was Proxmox nutzt, was OpenStack Cinder nutzt, was die meisten Kubernetes-CSI-Treiber nutzen. Betreibst du Ceph, betreibst du wahrscheinlich RBD. Sein Commit-Graph sieht so aus:\nRBD-Commits nach Jahr — eine Komponente geht in die Pflege über Commits auf\u0026#160;src/librbd, nach Jahr Cephs Blockgerät — was Proxmox, OpenStack Cinder und die meisten Kubernetes-CSI-Treiber nutzen 0 100 200 300 400 431 2015 477 2016 258 2017 276 2018 209 2019 455 2020 165 2021 85 2022 49 2023 74 2024 45 2025 19 2026 Funktionsarbeit im Wesentlichen fertig Jason Dillaman schrieb 281 der 455 Commits von 2020 — dauerhafter Write-Back-Cache und Krypto — dann ging RBD in die Pflege über. 2026 läuft bis 27. August. Das ist kein Rückgang — es ist eine reife Komponente, die gepflegt und nicht neu gebaut wird. Commits auf src/librbd nach Jahr. Die schwere Funktionsarbeit war um 2020 fertig — Jason Dillaman schrieb 281 der 455 Commits dieses Jahres, am dauerhaften Write-Back-Cache und an der Krypto — und die Komponente ist seither in die Pflege übergegangen. 159 Commits in den letzten drei Jahren, etwa einer die Woche, gegen 1.705 für RGW und 1.944 für Crimson.\nSo sieht stabiler Code aus, und es ist eine Eigenschaft. Blockspeicher über RADOS ist ein gelöstes Problem. RBD hat seit Jahren Momentaufnahmen, Klone, Layering, Mirroring, Verschlüsselung, Live-Migration und einen dauerhaften Cache, und es gibt nichts wie die S3-API, die davoneilt, denn was ein Hypervisor von einem Blockgerät will, hat sich in einem Jahrzehnt kaum verändert. Die Funktionsarbeit ist getan. Was bleibt, ist Instandhaltung: Fehlerbehebungen, Schritt halten mit dem Kernel, der gelegentliche Leistungsgewinn.\nStell es absichtlich neben RGW. RGW nimmt zehnmal die Commits, weil es zehnmal so weit vor sich hat. RBD nicht, also nimmt es sie nicht. Eine Komponente, die aufgehört hat, ihre Form zu verändern, ist keine Komponente, die verkommt — und würde librbd plötzlich 400 Commits im Jahr nehmen, wollte ich wissen, was schiefgegangen ist, denn das sind die Platten meiner virtuellen Maschinen, die es hält.\nDas eine, was zu wissen wert ist, ist, dass es das Fachwissen in sehr wenige Köpfe legt. RBD ist mehr oder weniger Ilya Dryomov, der sich um beide Enden kümmert — Upstream-Ceph und den rbd-Treiber im Linux-Kernel. Das ist etwa die beste Lage, die es gibt, und es ist trotzdem eine Person tief. Was dir sagt, wen du fragen sollst, nicht ob du es einsetzen sollst.\nWo die Arbeit sitzt Dieselbe Abbildung über den Baum, Jahrzehnt und jüngeres Fenster nebeneinander:\nBereich Führend im Jahrzehnt Anteil Führend letzte 3 Jahre IBM-Gruppe, letzte 3 J. src/mds — CephFS-Metadaten Red Hat 78,5 % Red Hat 56,4 % 73,9 % src/osd — heutige OSD Red Hat 69,7 % Red Hat 56,9 % 84,0 % src/cephadm — Ausrollen Red Hat 66,8 % Red Hat 73,7 % 92,0 % src/rgw — S3 Red Hat 64,3 % Red Hat 56,1 % 66,7 % src/librbd — Block Red Hat 61,1 % Red Hat 76,7 % 83,0 % src/crimson — nächste OSD Red Hat 52,1 % Red Hat 42,0 % 45,4 % doc/ — das Handbuch Red Hat 45,6 % Ceph Foundation 28,4 % 40,5 % src/os/bluestore — das Werk Red Hat 36,9 % IBM 46,5 % 54,2 % src/pybind/mgr/dashboard SUSE 36,6 % IBM 57,5 % 87,8 % Zwei Dinge sind hier abzulesen. Eigentum: je näher an den Teilen, die ein Hersteller verkauft — Werkzeuge zum Ausrollen, die Oberfläche —, desto mehr ist es eine Firma; je weiter draußen — die OSD der nächsten Generation, das Speicherwerk, das Handbuch —, desto voller, und dort ist der Platz, wenn du irgendwo beitragen willst, das noch nicht besetzt ist.\nVolumen: nach Commits insgesamt über das Jahrzehnt ist die Reihenfolge RGW 6.958, Crimson 5.827, die OSD 4.499, das Dashboard 3.848, die Monitore 2.896, BlueStore 2.560, CephFS 2.546, RBD 1.750, cephadm 1.685. Der Einsatz folgt dem Abstand zum Fertigsein, nicht dem Anteil an den Installationen. RGW ist erster, weil die S3-Gleichheit weit weg ist; RBD ist fast unten, weil Blockspeicher fertig ist.\nBlueStore verdient seine eigene Zeile. Es ist das Werk, das deine Byte auf die Platte schreibt, und über die letzten drei Jahre ist der zweitgrößte Beitragende nach IBM croit mit 18,1 % — Igor Fedotov, sein Hauptmaintainer, in einer Firma von ein paar Dutzend Leuten. Mein Arbeitgeber, also wäge mich entsprechend. Der Punkt steht, wer auch seinen Scheck ausstellt: eine kleine Firma kann den Maintainer einer der sicherheitskritischsten Komponenten im Stapel beschäftigen, und das Projekt ist dadurch besser.\nWer den Merge-Knopf hält Ich habe auch Merges gezählt — 7.893 in den letzten drei Jahren, dem zugerechnet, der den Knopf gedrückt hat:\nOrganisation Merges Anteil Red Hat 3.892 49,3 % IBM 1.597 20,2 % Ceph Foundation 524 6,6 % Proxmox 202 2,6 % Intel 136 1,7 % croit 76 1,0 % 69,5 % der Merges gegen 68,6 % der Commits. Das Tor und die Arbeit haben dieselbe Form. Das ist nicht eine Firma, die den Code schreibt, und eine andere, die beherrscht, was landet, und das ist der Fehlerfall, um den man sich in unternehmensgetragener Open Source tatsächlich sorgen sollte. Ceph hat ihn nicht.\nWoher die Zahlen kommen Alles davon ist nachvollziehbar. Ceph pflegt seine eigene Abbildung von Beitragenden auf Organisationen im Repository — .organizationmap, neben .mailmap, .peoplemap und .githubmap — und dokumentiert den Befehl, um sie zu nutzen.\ngit clone --filter=blob:none --no-checkout https://github.com/ceph/ceph.git cd ceph git show HEAD:.organizationmap \u0026gt; /tmp/orgmap # Ceph\u0026#39;s own documented method, over the last ten years git log --no-merges --since=2016-08-27 --until=2026-08-27 --pretty=\u0026#39;%aN \u0026lt;%aE\u0026gt;\u0026#39; \\ | git -c mailmap.file=/tmp/orgmap check-mailmap --stdin \\ | sort | uniq -c | sort -rn | head -30 # the maintainer-to-employer mapping, straight from the repo git show HEAD:doc/governance.rst | sed -n \u0026#39;/^.. _csc:/,/^\\.\\. _ctl:/p\u0026#39; \\ | grep -oE \u0026#39;\\* [^\u0026lt;]+\u0026lt;[^\u0026gt;]+\u0026gt;\u0026#39; Lass das Erste laufen, und du bekommst ein kleineres IBM als meines, denn die offizielle Abbildung ist veraltet. Sie kennt aainscow@uk.ibm.com, bill_scales@uk.ibm.com, ylifshit@ibm.com, rkachach@ibm.com, leonid.usov@ibm.com und die maschinell erzeugten li-*.ibm.com-Hostnamen nicht. Mit dem eigenen Werkzeug des Projekts wird die Konzentration unterschätzt.\nMeine Korrekturen auf die Abbildung:\nJede Adresse, die auf ibm.com endet — samt uk.ibm.com, il.ibm.com, in.ibm.com, de.ibm.com und den li-*.ibm.com-Formen — ist IBM. redhat.com und inktank.com sind Red Hat, getrennt von IBM gezeigt, aber seit Oktober 2022 dasselbe Team. Sieben persönliche Adressen sind Arbeitgebern zugerechnet, wo das Repository es selbst belegt: sage@newdream.net (Red Hat), idryomov@gmail.com (in Cephs eigener doc/governance.rst als idryomov@redhat.com aufgeführt), max.kellermann@gmail.com (IONOS), xxhdx1985126@gmail.com (QiAnXin), yuvalif@yahoo.com (IBM), yingxincheng@gmail.com (Intel), shraddha.agrawal000@gmail.com (IBM). Alles andere behält seine Domain. Persönliche Adressen bleiben „kein Arbeitgeber sichtbar“, statt geraten zu werden. Vorbehalte, die ich nicht beheben kann. Commits sind eine grobe Einheit — ein sorgfältiges Refactoring über 900 Zeilen zählt einmal, vierzig Tippfehlerbehebungen zählen vierzig, und nichts hier ist gewichtet. E-Mail-Domains sind unvollkommen: 9,0 % des Jahrzehnts zeigen keinen Arbeitgeber, und einige dieser Leute werden sicher dafür bezahlt, Ceph zu schreiben. Reviews sind in Git unsichtbar — Ceph reviewt in GitHub-Pull-Requests, nicht in Reviewed-by:-Zeilen, von denen ich in drei Jahren zwölf gefunden habe; das wichtigste Tor im Projekt hinterlässt in einem Klon keine Spur. Die Zahlen sind nur main, Backports auf stabile Zweige sind also nicht gezählt, was die Pflegearbeit unterschätzt. Und jede Verbreitungszahl hier ist ein Boden, aus dem Telemetriegrund oben.\nWo eine Aussage auf einem Datum ruht, habe ich das Autorendatum genommen; wo sie auf jemandes Arbeitgeber ruht, eine Adresse, die er selbst veröffentlicht hat.\nWas ich daraus mitnehme Ceph ist ein unternehmensfinanziertes Projekt mit einer echten Gemeinschaft an den Rändern, und das ist es sein ganzes kommerzielles Leben lang gewesen. Das ist kein Seitenhieb. Irgendwer muss Ingenieure bezahlen, damit sie verteilten Speicher in diesem Maßstab betreuen, und zehn Jahre lang hat irgendwer das getan.\nIch werde nicht vorgeben, Ceph sei typisch, denn ich habe nachgesehen. LWNs Statistik für Linux 6.15 verzeichnet 2.068 Entwickler von mindestens 195 Arbeitgebern, mit der größten einzelnen Firma, Intel, bei 12,0 % der Changesets. Ceph sind 1.718 Menschen über ein Jahrzehnt mit einer Firma bei 67,0 %. Der Kernel verteilt seine Abhängigkeit von Unternehmen über Dutzende Firmen. Ceph packt sie in eine. Das ist ein echter Unterschied, und „das machen doch alle“ wäre eine faule Art, ihn wegzuwischen.\nAber hier ist, was zehn Jahre Daten dazu sagen, ob das zählt, und es ist eine bessere Antwort, als ich suchen ging:\nCeph ist zäh auf die Weise, auf die es ankommt. Es hat den Mann verloren, der es geschrieben hat und der ein Fünftel der Arbeit machte. Es hat SUSE verloren, seinen zweitgrößten Beitragenden und den Autor des Dashboards. Es hat ZTE, Mirantis, XSKY, EasyStack, Inspur und die Hälfte der Gründungsmitglieder der Foundation verloren. Die Commit-Rate von heute liegt innerhalb von zwei Prozent der letztjährigen. Zwanzig Jahre Speicheringenieurskunst liegen in diesem Baum unter LGPL-2.1 oder LGPL-3, und niemand kann es schließen, neu lizenzieren oder zurücknehmen.\nDie Maintainer sind mitnehmbar. Fedotov hat BlueStore durch drei Arbeitgeber am Laufen gehalten. Kefu Chai ging von Red Hat zu Proxmox und machte weiter. Sadeh hat RGW bei DreamHost geschrieben und im Juni seine Gremiumsadresse auf Ubiquiti geändert. Geht eine Firma, bleiben ihre Leute oft.\nDie Tür ist wirklich offen. Ein Ingenieur bei IONOS wurde in drei Jahren der fünftgrößte Beitragende. Proxmox kam mit einer Einstellung in die Top Ten. Eine Sicherheitsfirma ohne Speicherprodukt baut ein Fünftel der OSD der nächsten Generation. 478 Organisationen haben Patches geschickt. Willst du hinein, hält dich nichts auf außer der Arbeit.\nDie Nutzerbasis ist weit größer, als irgendwer messen kann. Ein Exabyte über 3.000 Cluster ist, was über freiwillige Telemetrie die Hand gehoben hat, und CERN allein macht neunzehn Produktions-Cluster aus. Jeder hyperkonvergente Proxmox-Cluster, jede Rook-Installation, jede Hersteller-Appliance mit Ceph unter dem Deckel ist echter Produktivbetrieb, den keine veröffentlichte Zahl zählt. Software, die so breit und so still ausgerollt ist, verschwindet nicht einfach.\nDer Einsatz geht dorthin, wo die Lücke ist, nicht dorthin, wo die Nutzer sind. RGW ist das größte Programm im Projekt — 6.958 Commits über das Jahrzehnt —, weil Amazon bei S3 einzuholen eine lange Jagd auf ein bewegliches Ziel ist. RBD sitzt fast unten, weil Blockspeicher fertig ist. Eine niedrige Commit-Zahl an einer reifen Komponente ist eine erledigte Arbeit und keine Warnung, und diese zwei Zahlen verkehrt zu lesen ist der leichteste Fehler bei solchen Daten. Ich habe ihn im ersten Durchgang selbst gemacht.\nBeurteile Lieferanten nach Commits, nicht nach Stufen. Die Geschichte ist öffentlich, und vier Zeilen Shell zeigen dir, wer das Ding, von dem du abhängen willst, tatsächlich betreut. Geschlossener Speicher bietet dir das zu keinem Preis.\nWägst du Ceph also ab: die Konzentration ist zu wissen wert, wenn du fünf Jahre voraus planst, und sie ist kein Grund, sich zurückzuhalten. Eine reife Blockschicht. Der größte Ingenieurseinsatz des Projekts genau auf die S3-Gleichheit gerichtet. Eine künftige OSD, die von drei Firmen gleichzeitig gebaut wird. Ein Handbuch, das besser ist als die meisten. Eine Governance, die den Verlust ihres Gründers durchgehalten hat. Ein Jahrzehnt Review im Offenen, die Arbeit von 478 Organisationen im Baum, und eine Lizenz, deren schlimmster Fall ein Fork und keine Sackgasse ist. Nach dem Zeugnis von 69.613 Commits ist dieses Projekt bei guter Gesundheit.\nUnd zähl es selbst, wenn du mir nicht glaubst. Die Befehle stehen oben, die Daten sind öffentlich, und nichts in diesem Beitrag muss auf Vertrauen genommen werden — nicht meines und nicht das von irgendwem sonst.\nQuellen Quellen des Ceph-Projekts\n„Ceph: A Scalable, High-Performance Distributed File System“ — Weil, Brandt, Miller, Long und Maltzahn, OSDI \u0026lsquo;06, November 2006. Das Papier, als das Ceph anfing ceph/ceph auf GitHub — das Repository, aus dem jede Commit-Zahl kommt; .organizationmap, .mailmap, .peoplemap, .githubmap, doc/governance.rst und COPYING liegen alle im Baum Ceph-Governance — Mitgliedschaft im Executive Council und im Ceph Steering Committee, mit Adressen Ceph-Komponententeam — Komponentenleiter Mitglieder der Ceph Foundation — heutige Mitgliedschaft nach Stufe Dokumentation der Ceph Foundation — Stufenaufbau und kostenlose Associate-Mitgliedschaft Mitglieder der Ceph Foundation, Quincy-Dokumentation — Mitgliedschaft, wie sie etwa 2022 stand Ceph-Telemetriemodul — bestätigt, dass die Telemetrie freiwillig ist „Red Hat\u0026rsquo;s Ceph team is moving to IBM“, 4. Oktober 2022 Ceph Community Newsletter, November 2021 — Sage Weils Rücktritt Ceph Foundation und Linux Foundation\nIntroducing Ceph Squid — die oben zitierten Aussagen der Diamond-Mitglieder und die Zahlen von 1 Exabyte und über 3.000 Clustern The Linux Foundation Launches Ceph Foundation, 12. November 2018 — Liste der Gründungsmitglieder Dieselbe Mitteilung über PRNewswire — genutzt, um die Liste unabhängig zu bestätigen Installationen\n„Ceph: Infrastructure Storage at CERN“ — Enrico Bocchi, CERN IT Storage, 27. September 2024. Jede CERN-Zahl oben kommt aus diesem Vortrag Why We Chose Ceph to Build Block Storage — DigitalOcean „We Added 6 Petabytes Of Ceph Storage and No Clients Noticed“ — Matthew Leonard und Joseph Mundackal, Bloomberg, Cephalocon 2020 Ceph auf Wikitech — die fünf Produktions-Cluster der Wikimedia Foundation Ceph-RBD-Blockspeicher — OVHclouds eigene Dokumentation Deploy Hyper-Converged Ceph Cluster — Proxmox VE liefert Ceph als hyperkonvergenten Speicher Firmen\n„SUSE says tschüss to Ceph-based enterprise storage product“, The Register, 25. März 2021 — SUSE Enterprise Storage für Longhorn gestrichen Qi An Xin files for $634m IPO, Global Venturing, 13. Mai 2020 — QiAnXins Ursprung in Qihoo 360, der CEC-Anteil und die Beteiligungsverhältnisse ","permalink":"https://blogs.damiendye.uk/de/ceph/who-actually-writes-and-uses-ceph/","summary":"Ich habe jeden Commit auf Cephs main-Zweig der letzten zehn Jahre gezählt — 69.613 davon von 1.718 Menschen aus 478 Organisationen —, alle 38 Mitglieder des Steering Committee zu ihren Arbeitgebern verfolgt und die öffentlich genannten Installationen gesammelt. Das Ergebnis ist ein Projekt, das den Verlust seines Gründers und seines zweitgrößten Beitragenden ohne einen Takt Aussetzer verkraftet hat und heute noch mit derselben Rate ausliefert.","title":"Wer Ceph tatsächlich schreibt und nutzt"},{"content":"Diesmal existiert der Host. Er sitzt bloß auf dem falschen Hypervisor Letztes Mal war das Problem, dass die im Inventar genannte Maschine noch nicht existierte — keine IP, kein SSH, kein Python, nichts, wohin man verbindet. Jeder Task musste von ihr weg delegiert werden.\nEine VMware-Migration dreht das um und ändert nichts. Die Maschine existiert, sie läuft, Leute benutzen sie. Du verbindest dich trotzdem nie zu ihr. Sie ist ein Name und ein Sack Variablen, die etwas beschreiben, das woanders neu zu bauen ist. Jeder Task läuft weiter auf dem Steuerknoten, und jetzt sind am anderen Ende zwei APIs statt einer.\nEin Wort dazu, was das ist. Dieser Beitrag ist der Entwurf und das Playbook, keine Kriegsgeschichte. Ich habe es noch nicht von Anfang bis Ende gegen einen produktiven Bestand laufen lassen. Alles, was ich unten über das Verhalten der Module sage, wurde aus dem ausgelieferten Code gelesen und geprüft, und ich habe klar gesagt, wo eine Aussage aus der Quelle kommt und nicht aus einem Lauf. Wenn ich damit eine echte Migration gemacht habe, bekommen die Zahlen und die Überraschungen ihren eigenen Beitrag.\nDie Fassungen, gegen die das geprüft wurde:\n$ ansible --version | head -1 ansible [core 2.20.7] $ ansible-galaxy collection list | grep -E \u0026#39;vmware|proxmox\u0026#39; community.proxmox 1.6.0 community.vmware 6.2.1 vmware.vmware 2.9.0 Die Ausschnitte unten sind aus einem einzelnen Playbook geschnitten — migrate.yml, ein dynamisches vSphere-Inventar in inventory/vmware.vms.yml und ein group_vars/all.yml. Ich habe die Namen von Datacenter, Knoten und Speicher der Lesbarkeit zuliebe verallgemeinert.\nDie Form der Aufgabe Fünf Schritte, und nur der letzte kostet etwas.\nGäste oben, nichts steht auf dem Spiel der Ausfall entdecken die verteilten Portgruppen und ihre VLAN-Tags lesen sdn eine VLAN-Zone, ein VNet je VLAN auf Proxmox bauen plattenlose Hüllen, richtige CPU, RAM, Firmware und MACs umlagern die VMDKs per storage vMotion auf NFS, im laufenden Betrieb umschalten abschalten, Platten importieren, Bootreihenfolge setzen, Gast starten Alles Umkehrbare ist getan, bevor irgendetwas abgeschaltet wird Der langsame Teil ist das Umlagern, und es kostet überhaupt keine Ausfallzeit. Wenn das Fenster aufgeht, liegen die Platten schon auf Speicher, den Proxmox einbindet, die Umschaltung ist also ein lokaler Import und keine Kopie. Eine Hülle ohne Platte ist billig zu löschen, ein Fehler vor der Umschaltung kostet also nur Zeit. Die Migration auf halbem Weg aufzugeben lässt jeden Gast weiter auf VMware laufen, unberührt. Alles Umkehrbare passiert zuerst. Die langsame Stufe ist kostenlos, und die teure Stufe ist kurz, denn bis dahin sind die Platten schon dort, wo sie sein müssen. Die Reihenfolge ist der ganze Entwurf. Entdecken ändert nichts. Das Netz zu bauen ändert nur Proxmox. Die Hüllen zu bauen ändert nur Proxmox, und eine Hülle ohne Platte ist billig zu löschen. Die Platten zu bewegen ist langsam, aber im Betrieb. Nur das letzte Play schaltet etwas ab.\nGeh auf halbem Weg weg, und jeder Gast läuft weiter auf VMware, unberührt.\nZwei Collections, und eine davon wird abgewickelt Du brauchst beide, und nicht aus dem Grund, den du vermuten würdest.\ncollections: - name: community.vmware version: \u0026#34;\u0026gt;=6.2.1\u0026#34; - name: vmware.vmware version: \u0026#34;\u0026gt;=2.5.0\u0026#34; - name: community.proxmox version: \u0026#34;\u0026gt;=1.6.0\u0026#34; community.vmware ist die alte, breite Collection, und sie wird auseinandergenommen. Ihre MANIFEST.json erklärt {\u0026quot;vmware.vmware\u0026quot;: \u0026quot;\u0026gt;=2.5.0\u0026quot;} als harte Abhängigkeit, die erste zu installieren zieht also die zweite mit, ob du danach gefragt hast oder nicht. Module ziehen eines nach dem anderen um, und die, nach denen man in einer Migration greift, stehen an verschiedenen Punkten dieses Umzugs:\nvmware_dvs_portgroup_info — noch nur in community.vmware, und es ist das, was deine VLANs liest. vmware_vmotion — noch nur in community.vmware. vmware_guest_powerstate — abgekündigt, entfernt in community.vmware 7.0.0. Nimm vmware.vmware.vm_powerstate. vmware_vm_inventory — abgekündigt, entfernt in 7.0.0. Nimm vmware.vmware.vms. Ansible sagt dir beim ersten Lauf von den Modul-Abkündigungen, was anständig ist:\n[DEPRECATION WARNING]: community.vmware.vmware_guest_powerstate has been deprecated. Use vmware.vmware.vm_powerstate instead. This feature will be removed from collection \u0026#39;community.vmware\u0026#39; version 7.0.0. Vom Inventar-Plugin sagt es dir nichts, denn Inventar-Plugins werden ausgewertet, bevor diese Maschinerie läuft. Da musst du hingehen und das Plugin lesen.\nIn der Aufteilung steckt ein dritter Fallstrick. vmware.vmware.vm_portgroup_info sieht aus wie genau das, was eine Netzmigration will — je VM, je NIC, gibt dir die Portgruppe und das VLAN. Aber es baut auf ModuleRestBase auf und importiert com.vmware.vapi, was heißt, dass es das vSphere Automation SDK auf dem Steuerknoten braucht, nicht bloß pyVmomi. Seine dokumentierte Rückgabe ist auch veraltet: der RETURN-Block verspricht name und vlan_id, während der Code tatsächlich portgroup_name und für den verteilten Fall ein vlan_info-Dict baut. Ich bin unten einen anderen Weg gegangen und brauchte keins von beiden.\nDas Inventar ist die Entdeckung Es gibt in diesem Playbook kein „geh und finde die VMs“-Play, denn bis der erste Task läuft, hat das Inventar es schon getan — in einer Abfrage des Property Collectors statt in einer Schleife je VM.\n# inventory/vmware.vms.yml plugin: vmware.vmware.vms hostname: \u0026#34;{{ lookup(\u0026#39;ansible.builtin.env\u0026#39;, \u0026#39;VMWARE_HOST\u0026#39;) }}\u0026#34; username: \u0026#34;{{ lookup(\u0026#39;ansible.builtin.env\u0026#39;, \u0026#39;VMWARE_USER\u0026#39;) }}\u0026#34; password: \u0026#34;{{ lookup(\u0026#39;ansible.builtin.env\u0026#39;, \u0026#39;VMWARE_PASSWORD\u0026#39;) }}\u0026#34; validate_certs: false search_paths: - /Datacenter-1 properties: - name - config.name - config.uuid - config.guestId - config.firmware - config.template - config.hardware.numCPU - config.hardware.numCoresPerSocket - config.hardware.memoryMB - config.hardware.device - summary.runtime.powerState gather_compute_objects: true hostnames: [\u0026#39;name\u0026#39;] filter_expressions: - \u0026#39;config.template\u0026#39; Der Dateiname zählt. Das verify_file des Plugins beansprucht nur Dateien, die auf vms.yml, vms.yaml, vmware_vms.yml oder vmware_vms.yaml enden. Nenn sie vcenter.yml, und sie ist still nicht dein Inventar.\nsearch_paths filtert vor der Abfrage, nicht danach. Auf einem großen Bestand ist das der Unterschied zwischen Sekunden und Minuten — anders als filter_expressions, wozu die Dokumentation ausdrücklich ist: es läuft nach dem Sammeln und „does not affect the speed of the inventory plugin“.\nfilter_expressions verwirft einen Host, wenn der Ausdruck wahr ist. config.template entfernt daher Templates, was sich beim ersten Mal verkehrt liest.\nUnd die wichtige Zeile ist config.hardware.device, die in keiner voreingestellten Property-Liste irgendwo steht. Es ist das ganze Hardware-Inventar der VM, und es trägt drei Dinge, ohne die diese Migration nicht weiterkommt: die MAC jeder NIC, den dvportgroup-Schlüssel, an dem jede NIC hängt, und den Datastore-Pfad jeder Platte. Ohne es bist du zurück bei einer vmware_guest_info-Schleife, ein Hin und Her je VM.\nDie Geräte kommen als JSON zurück, mit ihrem vSphere-Typ in _vimtype erhalten. Das ist zu wissen wert, denn so unterscheidest du eine NIC von einer Platte. Ich habe den Encoder gelesen statt zu raten:\n{ \u0026#34;_vimtype\u0026#34;: \u0026#34;vim.vm.device.VirtualVmxnet3\u0026#34;, \u0026#34;macAddress\u0026#34;: \u0026#34;00:50:56:87:a5:9a\u0026#34;, \u0026#34;backing\u0026#34;: { \u0026#34;_vimtype\u0026#34;: \u0026#34;...DistributedVirtualPortBackingInfo\u0026#34;, \u0026#34;port\u0026#34;: { \u0026#34;_vimtype\u0026#34;: \u0026#34;vim.dvs.PortConnection\u0026#34;, \u0026#34;portgroupKey\u0026#34;: \u0026#34;dvportgroup-1014\u0026#34; } } } Ein compose-Block kann die unbequemen Pfade also in flache Hostvars hochziehen:\ncompose: vm_moid: moid vm_firmware: config.firmware vm_memory_mb: config.hardware.memoryMB vm_num_cpu: config.hardware.numCPU # A virtual NIC is any device with a MAC. Filtering on _vimtype does not # work cleanly here, because VMXNET3, E1000 and SR-IOV cards are all # different types with no shared substring. vm_nics: \u0026gt;- config.hardware.device | selectattr(\u0026#39;macAddress\u0026#39;, \u0026#39;defined\u0026#39;) | selectattr(\u0026#39;macAddress\u0026#39;, \u0026#39;ne\u0026#39;, None) | list # Disks are one exact type, so this one can match on it. vm_disks: \u0026gt;- config.hardware.device | selectattr(\u0026#39;_vimtype\u0026#39;, \u0026#39;eq\u0026#39;, \u0026#39;vim.vm.device.VirtualDisk\u0026#39;) | list Diese Unsymmetrie ist echt, und sie erwischt Leute. Es gibt keinen Typ VirtualEthernetCard, auf den man passen könnte. Das ist die abstrakte Basisklasse, und was vCenter dir tatsächlich gibt, ist VirtualVmxnet3, VirtualE1000, VirtualE1000e, VirtualPCNet32 oder VirtualSriovEthernetCard. Es gibt keine Teilzeichenkette, die alle gemeinsam haben. Eine MAC zu haben ist allerdings etwas, das nur eine NIC tut.\nJedes Info-Modul versteckt das Feld, das du brauchst Das ist der rote Faden der ganzen Aufgabe, und wenn du es dreimal gesehen hast, fängst du an, jede Voreinstellung zu prüfen, bevor du den Task schreibst.\nvmware_dvs_portgroup_info hat sechs show_*-Optionen. Fünf stehen voreingestellt auf true. Die sechste ist show_vlan_info, und sie steht auf false.\nshow_mac_learning=dict(type=\u0026#39;bool\u0026#39;, default=True), show_network_policy=dict(type=\u0026#39;bool\u0026#39;, default=True), show_teaming_policy=dict(type=\u0026#39;bool\u0026#39;, default=True), show_uplinks=dict(type=\u0026#39;bool\u0026#39;, default=True), show_port_policy=dict(type=\u0026#39;bool\u0026#39;, default=True), show_vlan_info=dict(type=\u0026#39;bool\u0026#39;, default=False), Lass es in Ruhe, und du bekommst MAC-Learning-Richtlinie, Teaming-Richtlinie, Uplink-Reihenfolge und Port-Richtlinie für jede Portgruppe im Bestand. Alles außer dem VLAN-Tag, dem einzigen Feld, nach dem eine Netzmigration tatsächlich fragt. Der Task ist also verkehrt herum zu dem, was du aus dem Bauch schreiben würdest: schalte das eine Ding an, schalte die anderen fünf aus.\n- name: Read the distributed portgroups community.vmware.vmware_dvs_portgroup_info: datacenter: \u0026#34;{{ vcenter_datacenter }}\u0026#34; show_vlan_info: true show_network_policy: false show_teaming_policy: false show_port_policy: false show_mac_learning: false show_uplinks: false register: dvs_pgs Es ist kein Einzelfall. vmware.vmware.vms hat gather_compute_objects, das cluster und esxi_host füllt — voreingestellt false. community.vmware.vmware_vm_info hat show_allocated, den Block mit CPU und Speicher — voreingestellt false. In allen drei Fällen ist das teuer zu sammelnde Feld das, das die Migration braucht, und die Voreinstellung schützt einen nur lesenden Berichtsfall, der nicht der ist, in dem du steckst.\nvlan_id ist drei verschiedene Typen Dann bekommst du die VLAN-Tags und stellst fest, dass sie nicht eine Form haben. Direkt aus get_vlan_info:\nif isinstance(vlan_obj, vim...TrunkVlanSpec): ... return dict(trunk=True, pvlan=False, vlan_id=vlan_id_list) elif isinstance(vlan_obj, vim...PvlanSpec): return dict(trunk=False, pvlan=True, vlan_id=str(vlan_obj.pvlanId)) else: return dict(trunk=False, pvlan=False, vlan_id=str(vlan_obj.vlanId)) Eine Access-Portgruppe gibt dir die Zeichenkette \u0026quot;100\u0026quot;. Ein PVLAN gibt eine Zeichenkette. Ein Trunk gibt eine Liste von Zeichenketten, jede entweder \u0026quot;20\u0026quot; oder \u0026quot;20-30\u0026quot;. Und jeder verteilte Switch hat mindestens einen Trunk, ob du einen gemacht hast oder nicht, denn die Uplink-Portgruppe ist ein Trunk, der \u0026quot;0-4094\u0026quot; trägt.\n| int steht dir also nicht zur Verfügung, bis du die anderen zwei Formen weggeworfen hast:\naccess_pgs: \u0026gt;- {{ dvs_pgs.dvs_portgroup_info | dict2items | map(attribute=\u0026#39;value\u0026#39;) | flatten | rejectattr(\u0026#39;vlan_info.trunk\u0026#39;) | rejectattr(\u0026#39;vlan_info.pvlan\u0026#39;) | rejectattr(\u0026#39;vlan_info.vlan_id\u0026#39;, \u0026#39;in\u0026#39;, [\u0026#39;0\u0026#39;, 0]) | list }} Drei Rejects, in dieser Reihenfolge. Trunks gehen, PVLANs gehen, und dann gehen die untagged Portgruppen, was auch die Uplink-Gruppen und alles auf VLAN 0 erledigt.\nIch übersetze Trunks und PVLANs nicht automatisch, und ich würde bei jedem widersprechen, der das täte. Ein VMware-Trunk, der auf Proxmox landet, braucht entweder eine Q-in-Q-Zone oder ein VLAN-fähiges VNet, und welches richtig ist, hängt davon ab, was der Gast zu sehen erwartet. Das ist eine Entscheidung, keine Abbildung. Das Playbook gibt sie aus und macht weiter:\nTASK [Report what was found] ok: [localhost] =\u0026gt; { \u0026#34;msg\u0026#34;: \u0026#34;3 access portgroups -\u0026gt; [100, 200]. Not translated: [\u0026#39;dvs_001-uplink\u0026#39;] (trunks), [\u0026#39;isolated\u0026#39;] (PVLANs).\u0026#34; } Die VLANs in SDN spiegeln Eine VLAN-Zone, an eine Bridge gebunden, dann ein VNet je VLAN mit dem Tag darauf.\n- name: Create the VLAN zone community.proxmox.proxmox_zone: zone: \u0026#34;{{ sdn_zone }}\u0026#34; type: vlan bridge: \u0026#34;{{ sdn_bridge }}\u0026#34; mtu: \u0026#34;{{ sdn_mtu }}\u0026#34; state: present - name: Create one VNet per VMware VLAN community.proxmox.proxmox_vnet: vnet: \u0026#34;{{ sdn_vnet_prefix }}{{ item.vlan_info.vlan_id | int }}\u0026#34; zone: \u0026#34;{{ sdn_zone }}\u0026#34; tag: \u0026#34;{{ item.vlan_info.vlan_id | int }}\u0026#34; alias: \u0026#34;{{ item.portgroup_name }}\u0026#34; state: present loop: \u0026#34;{{ access_pgs | unique(attribute=\u0026#39;vlan_info.vlan_id\u0026#39;) }}\u0026#34; throttle: 1 VNet-Namen sind kurz und eingeschränkt, VMware-Portgruppennamen nicht. Production-Web-Tier-VLAN100 ist ein völlig gewöhnlicher Portgruppenname und ein unmöglicher VNet-Name. Der Name wird also erzeugt — v100, aus dem Tag —, und das für Menschen lesbare Original geht in alias, wo es in der Oberfläche und in der pvesh-Ausgabe sichtbar bleibt. Den Namen aus dem VLAN statt aus der Portgruppe abzuleiten heißt auch, dass die Abbildung in sechs Monaten durch Hinsehen umkehrbar ist.\nZwei Portgruppen auf demselben VLAN fallen in ein VNet zusammen. Das ist richtig — sie waren in VMware auch dieselbe Broadcast-Domäne —, aber du solltest es passieren sehen, und dafür ist unique(attribute='vlan_info.vlan_id') da. Zwei Portgruppen namens prod-web und prod-web-b, beide auf VLAN 100, ergeben ein v100.\nthrottle: 1 ist keine Vorsicht, es ist das Modul. Jeder SDN-Schreibvorgang in community.proxmox nimmt eine globale Cluster-Sperre, wendet die anstehende Konfiguration an und gibt sie frei — get_global_sdn_lock(), dann apply_sdn_changes_and_release_lock(). Lauf sie parallel, und sie stehen ohnehin an der Sperre Schlange; die Drossel hört bloß auf, etwas anderes vorzugeben. Auch zu wissen wert: das Zurückrollen im Fehlerfall hängt von der Fassung ab — das Modul prüft is_lock_and_rollback_supported und sagt dir auf älterem PVE, dass es nicht zurückrollen konnte, statt es zu tun.\nEine kosmetische Sache, die dich an dir zweifeln lässt. In 1.6.0 gibt proxmox_vnet bei jedem einzelnen Anlegen sein ganzes Params-Dict als Ansible-Warnung aus:\nself.module.warn(f\u0026#34;{vnet_params}\u0026#34;) self.proxmox_api.cluster().sdn().vnets().post(**vnet_params) Das ist eine Debug-Zeile, die jemand liegen gelassen hat. Es ist Lärm, kein Fehler.\nBau die Hüllen, ohne Platten Jetzt die VMs, und hier verdient sich der Entwurf. Jede VM wird in Proxmox mit der richtigen Kernzahl, dem richtigen Speicher, der richtigen Firmware und den richtigen NICs auf den richtigen VLANs gebaut. Überhaupt keine Platten.\nEine plattenlose Hülle ist schnell angelegt, umsonst gelöscht und bootet zu einer PXE-Eingabe, wenn jemand sie versehentlich startet. Du kannst vierhundert davon an einem Nachmittag bauen, das Ergebnis ansehen, entscheiden, dass es falsch ist, alles löschen und es wieder machen. Nichts wurde kopiert, nichts wurde abgeschaltet, und niemand hat es gemerkt.\nDie abgeleiteten Werte sind Erklärungen, keine Tasks. Ansible wertet sie faul gegen den Host aus, der gerade im Blick ist, jede VM bekommt also ihre eigenen, ohne ein einziges set_fact:\n# group_vars/all.yml pve_vmid: \u0026#34;{{ vmid_base | int + (vm_moid | regex_replace(\u0026#39;^vm-\u0026#39;, \u0026#39;\u0026#39;) | int) }}\u0026#34; pve_bios: \u0026#34;{{ \u0026#39;ovmf\u0026#39; if vm_firmware == \u0026#39;efi\u0026#39; else \u0026#39;seabios\u0026#39; }}\u0026#34; pve_cores: \u0026#34;{{ vm_cores_per_socket | int }}\u0026#34; pve_sockets: \u0026#34;{{ ((vm_num_cpu | int) / (vm_cores_per_socket | int)) | round(0, \u0026#39;ceil\u0026#39;) | int }}\u0026#34; Die VMID kommt aus der vCenter-MoID. vm-42 wird 20042. Das zählt mehr, als es aussieht: das Umschalt-Play muss die VM finden, die das Bau-Play angelegt hat, und ein zweiter Lauf muss auf derselben landen, statt still eine zweite zu bauen. Die API die nächste freie ID zuteilen zu lassen — was passiert, wenn du vmid weglässt, und worüber ich letztes Mal geschrieben habe — macht das unmöglich.\nDer Speicher braucht keine Umrechnung. VMware meldet config.hardware.memoryMB, und Proxmox will MB. Sockel schon: VMware gibt dir vCPUs insgesamt und Kerne je Sockel, Proxmox will Sockel und Kerne.\n- name: Create the VM shell delegate_to: localhost community.proxmox.proxmox_kvm: node: \u0026#34;{{ proxmox_node }}\u0026#34; vmid: \u0026#34;{{ pve_vmid }}\u0026#34; name: \u0026#34;{{ inventory_hostname }}\u0026#34; cores: \u0026#34;{{ pve_cores }}\u0026#34; sockets: \u0026#34;{{ pve_sockets }}\u0026#34; memory: \u0026#34;{{ vm_memory_mb }}\u0026#34; ostype: \u0026#34;{{ pve_ostype }}\u0026#34; bios: \u0026#34;{{ pve_bios }}\u0026#34; scsihw: \u0026#34;{{ default_scsihw }}\u0026#34; efidisk0: \u0026#34;{{ {\u0026#39;storage\u0026#39;: pve_target_storage, \u0026#39;efitype\u0026#39;: \u0026#39;4m\u0026#39;, \u0026#39;pre_enrolled_keys\u0026#39;: false} if pve_bios == \u0026#39;ovmf\u0026#39; else omit }}\u0026#34; agent: \u0026#34;enabled=1\u0026#34; onboot: false state: present onboot: false mit Absicht. Nichts sollte mitten in einer Migration von selbst starten, am wenigsten eine Maschine, auf deren Platten noch ein anderer Hypervisor schreibt.\nDie Firmware richtig zu haben ist nicht wahlfrei. Ein UEFI-Gast, der auf eine SeaBIOS-VM importiert wird, importiert einwandfrei und weigert sich dann zu booten, und du verbringst eine Stunde damit. config.firmware ist efi oder bios und bildet direkt auf ovmf und seabios ab. Ein UEFI-Gast braucht auch eine EFI-Variablenplatte, die mit der VM angelegt werden muss — unten steht, warum.\nproxmox_kvm richtet keine NIC und sagt es dir nicht Letztes Mal habe ich geschrieben, dass proxmox_kvm sich verweigert statt zu aktualisieren. Hier ist die schärfere Fassung davon, die mich beim Schreiben gebissen hat und es wert ist, genau zu sein.\nupdate steht voreingestellt auf false, ein zweiter Lauf gegen eine VM, die schon existiert, tut also nichts. In Ordnung, und dokumentiert. Aber setz update: true, und das Modul weigert sich weiterhin, manche Parameter anzufassen:\n# If update, don\u0026#39;t update disk (virtio, efidisk0, tpmstate0, ide, sata, scsi) # and network interface, unless update_unsafe=True if update_unsafe is False: ... if \u0026#34;efidisk0\u0026#34; in kwargs: del kwargs[\u0026#34;efidisk0\u0026#34;] Es löscht sie aus der Anfrage und macht weiter. Du korrigierst also eine NIC in deiner Inventar-Abbildung, läufst mit update: true neu, siehst Ansible changed melden, und die NIC ist genau so falsch wie vorher. Das changed ist wahr — irgendetwas anderes in der Nutzlast wurde aktualisiert — aber nicht das, was du beheben wolltest.\nupdate_unsafe: true hebt die Einschränkung auf, und der Name ist ehrlich. Dieselbe Sperre deckt Platten ab, auf einer VM mit Platten ist ein unsicheres Update also ein guter Weg, eine zweite Kopie einer davon zu bekommen. Das ist kein Schalter, nach dem man in einer Migration greift.\nDer Ausweg ist, net überhaupt nicht zu nutzen. NICs kommen mit proxmox_nic dran, einem Modul, dessen ganze Aufgabe eine Schnittstelle ist und das richtig konvergiert:\n- name: Attach each NIC to its VNet delegate_to: localhost community.proxmox.proxmox_nic: vmid: \u0026#34;{{ pve_vmid }}\u0026#34; interface: \u0026#34;net{{ idx }}\u0026#34; bridge: \u0026#34;{{ sdn_vnet_prefix }}{{ pg_vlan[item.backing.port.portgroupKey] }}\u0026#34; mac: \u0026#34;{{ item.macAddress }}\u0026#34; model: \u0026#34;{{ default_net_model }}\u0026#34; state: present loop: \u0026#34;{{ vm_nics }}\u0026#34; loop_control: index_var: idx Das ist dieselbe Aufteilung, bei der ich letztes Mal gelandet bin: proxmox_kvm, um die Maschine zu beschreiben, proxmox_disk und proxmox_nic für die Dinge, die sich danach ändern. Der Parameter heißt mac, nicht mac_addr.\nefidisk0 lässt sich nicht auf dieselbe Weise auslagern — proxmox_disk hat kein efitype und kein pre_enrolled_keys —, es muss also beim Anlegen dran und beim ersten Mal richtig sein.\nNimm die MAC mit. VMware teilt MACs aus 00:50:56:... zu, und Proxmox nimmt sie ohne Murren. Sie zu behalten heißt, dass DHCP-Reservierungen weiter passen, MAC-gebundene Lizenzen weiter gelten und jede Firewall-Regel, die gegen eine MAC geschrieben ist, weiter greift. Sie zu ändern heißt einen Tag voll kleiner Rätsel. proxmox_nic nimmt auch model: vmxnet3, wenn der Gast dieselbe Karte sehen soll wie vorher, aber auf KVM ist virtio die bessere Karte, und ein Windows-Gast will so oder so neue Treiber.\nVerweigern statt raten Eine NIC auf einer Standard-Portgruppe hat überhaupt kein backing.port. Ihr Backing ist ein NetworkBackingInfo mit einem deviceName. Sie steht nicht in der Abbildung, und das Richtige ist anzuhalten:\n- name: Every NIC must sit on a distributed portgroup with a VNet ansible.builtin.assert: that: - vm_nics | rejectattr(\u0026#39;backing.port.portgroupKey\u0026#39;, \u0026#39;defined\u0026#39;) | list | length == 0 - vm_nics | map(attribute=\u0026#39;backing.port.portgroupKey\u0026#39;) | reject(\u0026#39;in\u0026#39;, pg_vlan.keys() | list) | list | length == 0 fail_msg: \u0026gt;- {{ inventory_hostname }} has NICs that do not map to a Proxmox VNet. Attaching it to the wrong network is worse than not building it. Zwei Bedingungen statt einer, denn die erste muss vor der zweiten laufen: map(attribute=...) über eine NIC ohne port würde am undefinierten Zugriff platzen. Wirf die formlosen zuerst weg, dann prüf den Rest gegen die Abbildung.\nEin Export, zweimal eingebunden Hier ist der Teil, der das Ganze billig macht.\nStell einen NFS-Export dorthin, wo beide Hypervisoren ihn einbinden können. vCenter sieht einen Datastore namens nfs-migration; die Proxmox-Knoten binden denselben Export ein und sehen /mnt/pve/nfs-migration. Jetzt storage-vMotion die VMDKs dorthin.\nStorage vMotion ist im Betrieb. Der Gast bedient die ganze Zeit weiter Verkehr. Nichts wird umgeschaltet, kein Fenster ist nötig, und es kann auf halbem Weg aufgegeben werden, ohne Folgen über verschwendetes I/O hinaus. Es ist mit weitem Abstand die langsamste Stufe, und es kostet nichts.\n- name: Relocate to the NFS datastore delegate_to: localhost throttle: 2 community.vmware.vmware_vmotion: moid: \u0026#34;{{ vm_moid }}\u0026#34; destination_datastore: \u0026#34;{{ nfs_datastore_vmware }}\u0026#34; timeout: \u0026#34;{{ vmotion_timeout }}\u0026#34; timeout steht voreingestellt auf 3600 — eine Stunde. Eine VMDK mit 2 TB schafft das nicht, und der Fehlerfall ist auf eine stille Weise unangenehm: der Ansible-Task scheitert, während die vMotion in vCenter weiterläuft. Du hast jetzt ein Playbook, das sagt, es sei gescheitert, und einen Bestand, der noch beschäftigt ist. Setz ihn auf etwas, das deinen tatsächlichen Speicher widerspiegelt.\nthrottle: 2, denn der Engpass ist nicht der Steuerknoten. Storage vMotion ist vom Array und vom Netz begrenzt. Sechs gleichzeitig geben dir nicht den sechsfachen Durchsatz; sie geben dir sechs langsame Migrationen und ein wütendes Speicher-Team.\nDas Modul ist auf die Weise idempotent, die du willst — es setzt storage_vmotion_needed = False, wenn die VM schon auf dem Ziel-Datastore liegt —, ein zweiter Lauf zum Aufsammeln von Nachzüglern ist also sicher.\nBis das fertig ist, sitzen die Byte auf Speicher, den Proxmox schon eingebunden hat. Damit muss sie nichts weiter kopieren. Nie.\nDie Umschaltung Das ist das einzige Play, das Ausfallzeit kostet, und die Reihenfolge darin ist nicht verhandelbar.\nZuerst ein Problem, das leicht zu übersehen ist: das Inventar ist jetzt veraltet. Es wurde vor der vMotion gesammelt, vm_disks hält also noch die alten Datastore-Pfade. Importiere von denen, und du zeigst Proxmox auf einen Pfad, den es nicht sehen kann.\n- name: Re-read the inventory now the disks have moved ansible.builtin.meta: refresh_inventory Und deshalb ist das Zwischenspeichern in der Inventar-Konfiguration abgeschaltet. Ein warmer Cache würde refresh_inventory genau die veralteten Daten zurückgeben, zu deren Ersatz es aufgerufen wurde. Das ist eine echte Abwägung — vCenter ist nicht schnell —, aber ein falscher Pfad hier ist eine gescheiterte Umschaltung in einem Fenster, und das Hin und Her ist dagegen billig.\nDann abschalten. Eine VMDK zu importieren, die ein ESXi-Host noch offen hat, gibt dir bestenfalls eine absturzkonsistente Kopie:\n- name: Shut the guest down in VMware delegate_to: localhost vmware.vmware.vm_powerstate: moid: \u0026#34;{{ vm_moid }}\u0026#34; state: \u0026#34;{{ \u0026#39;shutdown-guest\u0026#39; if vm_power_state == \u0026#39;poweredOn\u0026#39; else \u0026#39;powered-off\u0026#39; }}\u0026#34; timeout: 600 force: true shutdown-guest ist ein sanftes Herunterfahren über die VMware Tools; force: true stoppt alles hart, was nicht innerhalb der Zeit geht. Am neuen Modul heißt der Parameter timeout, nicht state_change_timeout wie am abgekündigten.\nDann der Import, der der Dreh- und Wendepunkt ist:\n- name: Import each VMDK onto its VM delegate_to: localhost throttle: 2 community.proxmox.proxmox_disk: vmid: \u0026#34;{{ pve_vmid }}\u0026#34; disk: \u0026#34;scsi{{ idx }}\u0026#34; storage: \u0026#34;{{ pve_target_storage }}\u0026#34; import_from: \u0026gt;- {{ item.backing.fileName | regex_replace(\u0026#39;^\\[[^\\]]+\\]\\s*\u0026#39;, \u0026#39;/mnt/pve/\u0026#39; ~ nfs_storage_pve ~ \u0026#39;/\u0026#39;) }} format: \u0026#34;{{ pve_target_format }}\u0026#34; timeout: \u0026#34;{{ import_timeout }}\u0026#34; create: regular state: present loop: \u0026#34;{{ vm_disks }}\u0026#34; loop_control: index_var: idx Das regex_replace erledigt die Übersetzung zwischen den zwei Welten. vCenter nennt eine Platte [nfs-migration] app01/app01.vmdk; Proxmox erreicht dieselbe Datei unter /mnt/pve/nfs-migration/app01/app01.vmdk. Derselbe Export, dieselben Byte, keine zweite Kopie. Du behältst die Deskriptor-.vmdk und ignorierst die -flat.vmdk daneben — qemu-img liest den Deskriptor und folgt ihm zum Extent.\nDrei Dinge zu import_from, alle im Modul und alle zu wissen wert, bevor das Fenster aufgeht.\nEs greift nur beim Anlegen. Im Update-Zweig:\n# \u0026#39;import_from\u0026#39; fails on disk updates playbook_config = self.get_create_attributes() playbook_config.pop(\u0026#34;import_from\u0026#34;, None) Existiert scsi0 auf dieser VM schon, wird der Parameter verworfen, und du bekommst ein gewöhnliches Update. Ein zweiter Lauf nach einem schlechten Import importiert also nicht neu. Er tut still überhaupt nichts und meldet Erfolg. Geht ein Import schief, lösch die Platte, bevor du es wieder versuchst.\ntimeout steht voreingestellt auf 600 Sekunden. Zehn Minuten, um die Platte einer virtuellen Maschine zu importieren und umzuwandeln. Die eigene Dokumentation des Moduls sagt, ihn zu erhöhen; nimm den Rat an.\nUnd ein absoluter Pfad braucht root. Die Dokumentation ist unverblümt:\n\u0026lt;STORAGE\u0026gt;:\u0026lt;VMID\u0026gt;/\u0026lt;FULL_NAME\u0026gt; or \u0026lt;ABSOLUTE_PATH\u0026gt;/\u0026lt;FULL_NAME\u0026gt;. \u0026lt;STORAGE\u0026gt;:import/\u0026lt;FULL_NAME\u0026gt; for PVE 9.x and later, to use storage\u0026rsquo;s import directory. Attention! Only root can use absolute paths.\nDas landet unbequem neben dem Rat, den ich letztes Mal gegeben habe und zu dem ich stehe: nimm ein eingegrenztes API-Token, nicht root. Dieser Rat hält für jede andere Stufe hier: Entdecken, SDN, Hüllen bauen, Bootreihenfolge setzen laufen mit einem Token gut. Dieser eine Task nicht, und keine Menge Rechte auf der Rolle wird das ändern, denn die Einschränkung hängt daran, dass der Nutzer root ist, und nicht an einer Berechtigung.\nEs gibt drei ehrliche Auswege und keinen klugen vierten:\nPVE 9.x: nimm \u0026lt;storage\u0026gt;:import/\u0026lt;file\u0026gt; und bleib beim Token. PVE 8.x: mach diesen einen Task als root@pam, und nur diesen. PVE 8.x, kein root über die API: lass stattdessen qm importdisk über SSH laufen. Das Playbook nimmt die ersten zwei über ein Flag, denn etwas anderes vorzugeben würde das Problem bloß zu dem verschieben, der es laufen lässt.\nSchließlich die Bootreihenfolge, die ein gewöhnliches Update ist und daher von der update_unsafe-Einschränkung unberührt bleibt:\n- name: Boot from the first imported disk delegate_to: localhost community.proxmox.proxmox_kvm: node: \u0026#34;{{ proxmox_node }}\u0026#34; vmid: \u0026#34;{{ pve_vmid }}\u0026#34; boot: \u0026#34;order=scsi0\u0026#34; update: true Nichts startet den Gast. Das ist Absicht. Starte ihn von Hand, sieh zu, wie er hochkommt, und denk erst dann daran, in VMware etwas zu löschen.\nEs laufen lassen Das Ganze ist ein Playbook, nach Stufen getaggt, denn das sind keine Schritte, die man zusammen laufen lassen will:\nansible-playbook migrate.yml --tags discover # look, change nothing ansible-playbook migrate.yml --tags sdn # build the VLANs ansible-playbook migrate.yml --tags build # build the diskless shells ansible-playbook migrate.yml --tags relocate # storage vMotion, live ansible-playbook migrate.yml --tags cutover # power off and import --limit ist durchweg dein Freund. Mach zuerst eine VM. Mach einen Cluster. Das Playbook hat keine Meinung dazu, wie viel du abbeißt, und das Inventar gibt dir Gruppen umsonst — power_poweredOn, cluster_\u0026lt;name\u0026gt;, plus vmware_windows und vmware_linux aus dem groups-Block.\nPrüf, worauf du zeigst, bevor du darauf zeigst:\nansible-inventory --graph ansible-inventory --host some-vm Worauf ich weiter achten würde Dinge, die ich erwarte zu finden, wenn das auf einen echten Bestand trifft, jetzt aufgeschrieben, damit ich hinterher nicht behaupten kann, ich hätte sie kommen sehen:\nWindows-Gäste booten nicht sauber von einem VirtIO-SCSI-Controller, ohne dass der Treiber vorher da ist. virtio-scsi-single ist der richtige Controller und der falsche, um ihn einer Windows-VM zu geben, die ihn nie gesehen hat. Das ist ein eigenes Problem, und nichts oben löst es. Die VMware Tools sollten vor dem Umzug herunter, nicht danach. Momentaufnahmen. Eine VM mit einer Kette von Momentaufnahmen hat mehr als eine .vmdk je Platte, und die Basis zu importieren gibt dir den Zustand vor der Momentaufnahme. Erst zusammenführen. Die Reihenfolge von config.hardware.device entscheidet, welche Platte scsi0 wird. Sie hat überall, wo ich hingesehen habe, mit der Reihenfolge des Gastes übereingestimmt, aber ich würde es auf einem Datenbankserver mit mehreren Platten prüfen, bevor ich ihr in einem Fenster vertraue. Unabhängige Platten und RDMs lassen sich nicht wie gewöhnliche storage-vMotionen. Nichts davon ändert die Form. Bau die Hüllen zuerst, beweg die Platten, während alles noch läuft, und halte den Ausfall auf das eine Play, das ihn braucht.\n","permalink":"https://blogs.damiendye.uk/de/ansible/vmware-to-proxmox-ansible/","summary":"Einen vSphere-Bestand mit dem dynamischen Inventar lesen, seine VLANs in Proxmox-SDN spiegeln und jede VM als plattenlose Hülle neu bauen, bevor eine einzige Platte umzieht. Warum jedes VMware-Info-Modul genau das Feld versteckt, das die Migration braucht, warum vlan_id drei verschiedene Typen ist, und warum ein NFS-Export, zweimal eingebunden, aus der Umschaltung ein lokales Lesen macht.","title":"VMware nach Proxmox mit Ansible — bau die Hüllen, bevor du ein Byte bewegst"},{"content":"Ich war von 2017 bis 2019 DNS-Registry-Systemadministrator bei Nominet, der .uk-Registry. Was hier über ICANN folgt, ist alles öffentliches Protokoll, und ich habe das komplett verlinkt. Wo ich stattdessen aus dem Job heraus rede, sage ich das.\nFrag die meisten Ingenieure, wer DNS betreibt, und du bekommst eine von zwei Antworten. Entweder ein Schulterzucken oder irgendwas über dreizehn Root-Server. Beide sind falsch, und die zweite ist auf interessantere Weise falsch, denn sie zeigt auf die Maschinen statt auf die Datei.\nDie Kontrolle über DNS ist nicht auf dreizehn Server verteilt. Sie sitzt in einer Textdatei und in der Handvoll Läden, die entscheiden, was hineinkommt, die sie bearbeiten, signieren und veröffentlichen. Alles andere im System — jeder Resolver, jeder Registrar, jede Zone, die du je betrieben hast — liegt stromabwärts dieser Datei und bezieht seine Autorität von ihr.\nIn diesem Beitrag geht es darum, wer diese Datei hält, was die Übergabe von 2016 tatsächlich übertragen hat, und was die Leute, die sie halten, damit gemacht haben. Die Maschinerie darunter — was eine Registry eigentlich ist, wie Namen hineinkommen und wer einen wieder wegnehmen kann — ist die Fortsetzung.\nVor ICANN war es ein Telefonanruf Nichts an der heutigen Regelung ist zwangsläufig, und die Geschichte sagt, wofür ICANN eigentlich gebaut wurde.\nAm Anfang gab es überhaupt kein DNS. Ab 1972 gab es eine Textdatei, HOSTS.TXT, die jeden Maschinennamen im ARPANET und die Adresse enthielt, unter der er lebte. Sie wurde am Stanford Research Institute von Elizabeth Feinler und ihrem Team gepflegt, und wenn du deine Maschine darin haben wolltest, riefst du während der Bürozeiten beim Network Information Center an und fragtest. Alle anderen holten sich die Datei ab und zu und hofften, sie sei aktuell.\nDas skaliert nicht, und Anfang der 1980er tat es das ganz offensichtlich nicht mehr. DNS wurde gebaut, um sie zu ersetzen — ein Baum, nach unten delegiert, damit kein einzelnes Büro die ganze Liste halten musste.\nDie Spitze des Baums musste trotzdem jemand halten. Jahrelang war dieser Jemand ein einzelner Mann. Jon Postel an der University of Southern California betrieb die Namens- und Nummernvergabe mit Forschungsgeldern der US-Regierung. Die IANA — Internet Assigned Numbers Authority — war zu dem Zeitpunkt keine Institution. Sie war Postel und eine Handvoll Kollegen, und sie funktionierte, weil die Leute, die das Netz betrieben, ihm vertrauten.\nGeld kam 1993 ins Spiel, als die National Science Foundation InterNIC — Network Solutions unter anderem — mit der Registrierung beauftragte. Am 14. September 1995 endete die kostenlose Registrierung. Network Solutions verlangte 50 Dollar im Jahr bei zwei Jahren Mindestlaufzeit, und 30 % davon gingen in einen Regierungsfonds, den ein Gericht später als illegale Steuer einstufte. Eine Firma, ein Preis, sonst nirgendwo hin, und bis 1997 eine Kartellklage.\nDann tat Postel im Januar 1998 das Ding, das dir sagt, woraus die Autorität der Root eigentlich besteht.\nEr schrieb acht der zwölf Root-Server-Betreiber an, gestützt auf nichts als sein eigenes Ansehen, und bat sie, ihre Server auf IANAs Maschine statt auf die von Network Solutions zu richten. Alle acht taten es. Für etwa eine Woche war die autoritative Root des Internets dort, wo Jon Postel die Leute gebeten hatte hinzuschauen.\nEr nannte es einen Test. Viele lasen es als Demonstration — dass die Root den Ingenieuren gehörte, die sie gebaut hatten, und nicht einem Regierungsauftragnehmer. Die Reaktion klärt, welche Lesart Washington wählte. Ira Magaziner, der zuständige Berater des Präsidenten, sagte Postel, er werde nie wieder am Internet arbeiten. Der Test wurde rückgängig gemacht.\nICANN wurde in jenem September in Kalifornien gegründet. Postel starb im Monat darauf.\nDie Regelung, um die es in diesem Beitrag geht, wurde also gebaut, um zwei echte Probleme zu lösen: ein Namensraum, der von einem niemandem rechenschaftspflichtigen Monopolisten verkauft wurde, und eine Root, deren Autorität darauf beruhte, dass einem einzelnen Mann breit vertraut wurde. Beides waren echte Probleme. ICANN war die Antwort darauf.\nZwei Codes, die die Regel überlebten Zwei lose Enden aus jener Zeit, bevor es weitergeht, denn zusammen sagen sie mehr darüber, wie dieses System wirklich funktioniert, als irgendetwas in ICANNs Satzung.\nDas Vereinigte Königreich nahm den falschen Code und behielt ihn.\nRFC 920 sagte im Oktober 1984, Länder-Top-Level-Domains würden aus den zweibuchstabigen Codes der ISO 3166 genommen. Der ISO-3166-Code des Vereinigten Königreichs ist GB. Nach der Regel, wie sie geschrieben steht, müsste die Domain des UK .gb heißen.\nIst sie nicht, weil das UK zuerst da war. JANET, das akademische Netz, hatte sich ein paar Monate vor Aufstellung der ISO-abgeleiteten Liste bereits auf uk als Top-Level-Kennung festgelegt, und .uk wurde am 24. Juli 1985 registriert. .gb wurde ebenfalls zugewiesen, in der Erwartung, dass .uk mit der Zeit dorthin umziehen würde.\nDer Umzug fand nie statt. Niemand hat ihn erzwungen. .gb saß dann vier Jahrzehnte in der Root und hatte in seinem ganzen Leben eine einzige Second-Level-Domain aufgesammelt — hmg.gb, für Her Majesty\u0026rsquo;s Government — die kaum genutzt wurde. Die ISO bog sich schließlich um die Tatsachen vor Ort herum und reservierte UK auf Wunsch des Vereinigten Königreichs ausnahmsweise.\nÜbrigens wurde niemand beraubt. UK war nicht der Code eines anderen Landes — es ist in ISO 3166 ausnahmsweise für das Vereinigte Königreich reserviert, auf dessen eigenen Wunsch, und kein anderer Staat hatte je einen Anspruch darauf. Genau deshalb hat niemand die Sache erzwungen: es gab keine geschädigte Partei, die sich hätte beschweren können.\nUnd genau das macht es erzählenswert. Die ISO-3166-Regel ist starr für jeden, der hinein will: kein Eintrag auf der Liste, keine Länderdomain. Deshalb lobbyieren Territorien überhaupt darum, in ISO 3166 aufgenommen zu werden, und deshalb haben Orte ohne Anerkennung gar keine ccTLD. Für einen Platzhirsch, der schon in der Root ist, erwies sich dieselbe Regel als Empfehlung.\nEs gibt sogar ein gutes Argument, dass das UK am Ende den besseren Namen bekam. GB ist Great Britain, und das lässt Nordirland weg. UK nicht. Der regelwidrige Code beschreibt den Staat genauer, als der regelkonforme es getan hätte.\nUnd die Sowjetunion steht immer noch in der Root. Das ist noch seltsamer.\n.su wurde am 19. September 1990 an die Sowjetunion delegiert. Die Sowjetunion hörte fünfzehn Monate später auf zu existieren.\nEs ist immer noch da. Fünfunddreißig Jahre nachdem der Staat, zu dem es gehört, aufgehört hat zu existieren, ist .su aktiv und nimmt Registrierungen an — mit Stand Mai 2025 etwas über 111.500 Namen, verwaltet aus Moskau.\nDie Regel sagt, ccTLDs kommen aus ISO 3166. ISO 3166 führt die Sowjetunion nicht. Und es ist nicht so, dass die Regel nie angewendet worden wäre: .dd für die DDR und .yu für Jugoslawien gingen beide, als diese Staaten gingen. .su war das, was nicht ging, und niemand hat den Unterschied je in den Begriffen der Regel erklären können.\nWas daraus wurde, ist vorhersehbar genug. Als .ru Ende 2011 seine Registrierungsprüfungen verschärfte, zog das Geschäft nebenan. Bösartige Seiten in .su verdoppelten sich 2011 und verdoppelten sich 2012 erneut, was dieselbe Geschichte ist wie bei den billigen neuen gTLDs und den kostenlosen ccTLDs weiter unten in diesem Beitrag: Missbrauch ist eine Flüssigkeit, und er fließt dorthin, wo die Prüfungen am schwächsten sind.\nZwei Ländercodes also, die die Regel überlebten, die sie hervorgebracht hat. .uk, weil niemand einen Platzhirsch zum Umziehen zwang, .su, weil niemand eine Delegierung gehen ließ, als ihr Land ging. In beiden Fällen ist das Regelwerk klar, und in beiden Fällen blieb es unbeachtet, weil es durchzusetzen bedeutet hätte, jemandem etwas wegzunehmen, der es schon hatte.\nDas ist der ganze Charakter von Autorität im DNS, sichtbar schon bevor es ICANN gab, und als solches sollte dich nichts von dem, was folgt, überraschen.\nWas diese Antwort dann war, ist der Rest dieses Beitrags.\nDie achtzehn Jahre bis zur Übergabe ICANN wurde am 30. September 1998 in Kalifornien gegründet und unterschrieb sofort ein Memorandum of Understanding mit dem US-Handelsministerium. Sie fing nicht unabhängig an und wurde dann amerikanisch. Sie war vom ersten Tag an amerikanisch, von Konstruktion wegen, und die Regelung wurde in der einen oder anderen Form achtzehn Jahre lang verlängert.\nFang mit dem an, was sie richtig gemacht hat, denn es gibt eines, und es zählt.\n1999 brach ICANN das Registrierungsmonopol. Network Solutions war der einzige Ort gewesen, an dem man ein .com kaufen konnte; das Shared Registration System ließ andere Registrare Namen in derselben Zone verkaufen, und der Preis fiel und fiel weiter. Das ist eine echte Leistung, sie ist der Grund, warum eine Domain heute kostet, was sie kostet, und nichts weiter unten in diesem Beitrag streicht sie.\nDann fängt das Muster an, das sich durch alles andere zieht.\n2000. ICANN hielt eine weltweite Wahl ab, bei der Internetnutzer fünf Board-Mitglieder direkt wählten. Sie wurde nie wiederholt. Die At-Large-Struktur, die sie ersetzte, berät und stimmt nicht ab. Das erste und letzte Mal, dass die Öffentlichkeit ein bindendes Mitspracherecht bei ICANN hatte, hat ICANN es eingestellt.\n2005. Beim Weltgipfel zur Informationsgesellschaft in Tunis widersprach ein großer Teil der Welt der Tatsache, dass die USA die Root hielten. Herausgekommen ist das Internet Governance Forum — eine Jahreskonferenz ohne Autorität über irgendetwas. An der Root-Regelung änderte sich nichts.\n2005. Die .xxx-Affäre, die sechs Jahre lief und in diesem ganzen Beitrag der schärfste einzelne Beweis dafür ist, dass Gerichtsbarkeit nichts Abstraktes ist. Sozialkonservative Lobbygruppen in den Vereinigten Staaten setzten das Handelsministerium unter Druck. Die NTIA — National Telecommunications and Information Administration, der Arm des Handelsministeriums, der die Vereinbarung mit ICANN hielt — entwarf Briefe an ICANN und mobilisierte, in ihren eigenen Worten, ihre Mittel bei ICANN. Das Board — das auf Zustimmung zugesteuert war — lehnte den Antrag ab, neun zu fünf, dann noch einmal acht zu vier, wobei sowohl der Vorsitzende als auch der Vorstandschef ihre Position umkehrten. Viviane Reding, damals die zuständige EU-Kommissarin, nannte es den ersten klaren Fall politischer Einmischung der US-Regierung bei ICANN. .xxx wurde schließlich 2011 genehmigt, woraufhin das Handelsministerium erklärte, es sei enttäuscht.\nEine amerikanische innenpolitische Lobbykampagne, geleitet über eine amerikanische Bundesbehörde, änderte, welche Top-Level-Domains es im Internet gibt. Kein Vertrag, kein Gericht, keine Abstimmung außerhalb der Vereinigten Staaten.\n2009. Das Joint Project Agreement mit dem Handelsministerium wurde durch die Affirmation of Commitments ersetzt, weithin beschrieben als ICANNs Unabhängigkeit. Der IANA-Funktionsvertrag blieb genau da, wo er war.\nDann das, was es tatsächlich bewegte, und es war nichts, was ICANN getan hätte.\n2013. Edward Snowden. Am 7. Oktober, Monate nach Beginn der Enthüllungen, veröffentlichten die Spitzen von ICANN, der Internet Engineering Task Force, des Internet Architecture Board (IAB), des World Wide Web Consortium, der Internet Society und aller fünf regionalen Internet-Registries das Montevideo Statement, das die Globalisierung von ICANN und der IANA-Funktionen forderte und ausdrücklich den Schaden benannte, den flächendeckende Überwachung dem weltweiten Vertrauen zugefügt hatte. Die eigene technische Führung des Internets — ICANNs Vorstandschef unter den Unterzeichnern — sagte laut, dass die amerikanische Treuhänderschaft zur Belastung geworden war.\n14. März 2014. Die NTIA kündigte ihre Absicht an, ihre Treuhänderschaft über die IANA-Funktionen zu übertragen.\n1. Oktober 2016. Der Vertrag lief aus.\nDie Übergabe war also nicht verdient und sie wurde nicht nach Sachlage gewährt. Sie wurde nach achtzehn Jahren eingeräumt, weil ein US-Geheimdienstskandal die bestehende Regelung politisch unhaltbar machte und die technische Gemeinschaft das öffentlich sagte.\nWas man im Kopf behalten sollte, wenn man liest, was die Übergabe tatsächlich bewirkt hat.\nWas die Übergabe 2016 änderte, und was nicht Du wirst hören, die Amerikaner hätten 2016 das Internet übergeben. Wer argumentiert, ICANN sei ein Instrument amerikanischer Kontrolle, bekommt das zu hören, und wenn er dabei die Fakten falsch hat, verliert er die Diskussion an dieser Stelle. Also mach sie richtig.\nAm 1. Oktober 2016 lief der IANA-Funktionsvertrag zwischen NTIA und ICANN aus und wurde nicht verlängert. Das war real. Die US-Regierung hält keinen Vertrag mehr, der ihr ein Genehmigungsrecht über Änderungen an der Root-Zone gibt, und eine neue Satzung schuf eine Empowered Community mit der theoretischen Fähigkeit, Budgets abzulehnen und Board-Mitglieder abzuberufen.\nHier ist, was sich nicht änderte, und es war kein Versehen. Es stand als Ziel geschrieben.\nDer Übergabevorschlag hielt fest, dass die Rechtsordnung, in der ICANN ansässig ist, unverändert bleiben solle. Die neue Satzung verlangt, dass ICANN seinen Hauptsitz in Kalifornien behält. Die gesamte während der Übergabe gebaute Rechenschaftsstruktur ist auf kalifornischem Recht gebaut. Sie funktioniert, indem sie ICANN zu einem kalifornischen Non-Profit macht, das kalifornische Gerichte an seine eigene Satzung binden können.\nNach der großen Übergabe also: ICANN ist eine kalifornische Körperschaft, US-Bundesrecht und kalifornischem Recht unterworfen, deren Rechenschaftsmechanismen vor amerikanischen Gerichten durchsetzbar sind und nirgendwo sonst, und die Politik für eine Root-Zone setzt, die eine amerikanische Firma unter einer Vereinbarung mit dem amerikanischen Handelsministerium bearbeitet und signiert.\nDer Vertrag ging. Die Gerichtsbarkeit wurde bewusst behalten. Und die Gerichtsbarkeit ist der Teil mit Zähnen, denn sie verlangt niemandes Eingreifen. Sie gilt automatisch, ständig, standardmäßig.\nDie klarste Demonstration sind Sanktionen. OFAC — Office of Foreign Assets Control, Teil des US-Finanzministeriums — führt die amerikanischen Wirtschafts- und Handelssanktionen und entscheidet, mit wem US-Personen und -Firmen Geschäfte machen dürfen. ICANN ist eine kalifornische Körperschaft, also bindet OFAC sie, und es schränkt ein, mit wem ICANN Verträge schließen und wen sie akkreditieren darf.\nSei präzise beim Umfang: das erreicht Registries und Registrare generischer Top-Level-Domains (gTLDs), denn die halten ICANN-Verträge. Es erreicht keine Länder-Operationen (ccTLDs), die vollständig außerhalb von ICANNs Vertragsstruktur sitzen. Aber die Wirkung sickert weit über die rechtliche Grenze hinaus, denn Registrare außerhalb der Vereinigten Staaten haben OFAC-Beschränkungen auf ihre eigenen Kunden angewandt, in der irrigen Annahme, ein ICANN-Vertrag verlange das, oder schlicht durch Abschreiben amerikanischer Registrantenverträge. Amerikanische Außenpolitik pflanzt sich die Registrarkette hinunter fort, durch Nachahmung ebenso wie durch Recht.\nEs gibt keine Version davon, in der die Antwort auf „wer kontrolliert DNS“ nicht mit den Vereinigten Staaten beginnt.\nWer damit übrig bleibt, der gegen eine ICANN-Entscheidung etwas ausrichten kann, ist die andere Hälfte der Frage, und sie stellt sich besser, wenn es ein Protokoll gibt, an dem man sie prüfen kann. Dieser Beitrag kommt am Ende darauf zurück.\nDie Root ist eine Textdatei So viel dazu, wer das Sagen hat. Hier ist das Ding, über das sie das Sagen haben, und du kannst es dir einfach holen. ICANN veröffentlicht die Root-Zone per Zonentransfer — AXFR, der DNS-Mechanismus, um eine ganze Zone statt eines einzelnen Eintrags zu kopieren — an jeden, der fragt, ohne Zugangsdaten:\ndig . AXFR @xfr.dns.icann.org Im Moment sind das 1.578.790 Bytes über 24.886 Zeilen. Sie enthält 1.439 Delegierungen — jede Top-Level-Domain, die es gibt — von denen 1.350 einen DS-Eintrag tragen — den Delegation Signer, den Fingerabdruck, der den Signierschlüssel einer Kindzone an ihr Elternteil bindet — und daher Teil der signierten Kette sind.\nAnderthalb Megabyte. Der gesamte Namensraum des Internets, klein genug zum Mailen.\nDiese Datei ist die gesamte Autorität der Root. Ein Resolver, der kalt startet, weiß nichts außer den Adressen in seinen Root-Hints, und in dem Moment, in dem er eine Antwort bekommt, folgt er Delegierungen aus dieser Datei und aus nichts anderem. Ändere eine Delegierung darin und du hast geändert, wohin der Verkehr eines ganzen Landes geht. Es gibt keine zweite Kopie mit einer anderen Meinung, kein Konsensprotokoll, keine Abstimmung zum Auflösungszeitpunkt. Es gibt die Datei.\nDie Frage „wer kontrolliert DNS“ reduziert sich also auf eine viel engere: wer kann diese Datei ändern, und wer signiert sie danach.\nDrei Organisationen fassen sie an Die Antwort ist eine Dreierkette, und es lohnt sich, klar zu sein, wer was tut, denn in den Unterschieden liegen alle Streitfragen.\nPTI — Public Technical Identifiers, eine ICANN-Tochter — erfüllt die IANA-Funktionen. Sie nimmt Änderungsanträge zur Root-Zone von TLD-Betreibern entgegen, prüft sie und autorisiert sie. Das ist die Sachbearbeitungsebene, und zwar bewusst: die ganze Entwurfsabsicht ist, dass die IANA ein sorgfältiger Sachbearbeiter ohne Ermessen ist.\nVerisign ist der Root Zone Maintainer. Verisign nimmt die autorisierte Änderung, bearbeitet die Zonendatei, signiert sie mit dem Root-Zone-Signierschlüssel und veröffentlicht sie zur Verteilung. Verisign ist eine amerikanische Aktiengesellschaft und tut das unter einem Cooperative Agreement mit dem US-Handelsministerium.\nDie Root-Server-Betreiber stellen sie dann bereit. Sie sind der machtloseste Teil der Kette und der einzige, von dem irgendwer schon mal gehört hat.\nBeachte, wo das Ermessen tatsächlich sitzt. Nicht bei den Betreibern. Auch nicht wirklich beim Sachbearbeiter. Es sitzt bei dem, der die Politik setzt, die der Sachbearbeiter anwendet, und das ist ICANN, und bei der Firma, die den Stift und den Signierschlüssel hält, und das ist Verisign, unter einer Vereinbarung mit der amerikanischen Regierung.\nZehn von dreizehn Die Root-Server-Buchstaben sind es wert, vollständig aufgelistet zu werden, denn Leute zitieren die Zahl dreizehn, als impliziere sie Streuung:\nBuchstabe Betreiber Land A Verisign US B USC Information Sciences Institute US C Cogent Communications US D University of Maryland US E NASA Ames Research Center US F Internet Systems Consortium US G US Department of Defense (DISA) US H US Army Research Laboratory US I Netnod Schweden J Verisign US K RIPE NCC Niederlande L ICANN US M WIDE Project Japan Dreizehn Buchstaben, zwölf Organisationen, weil Verisign sowohl A als auch J hält. Zehn der dreizehn werden aus den Vereinigten Staaten betrieben. Zwei davon sind das amerikanische Militär.\nDas ist keine Verschwörung, es ist versteinerte Geschichte. Das sind die Institutionen, die in den 1980ern am Netz waren und nie gegangen sind. Aber ein historischer Zufall, der das US-Militär zwei der Root-Server des Internets betreiben lässt, ist immer noch das US-Militär, das zwei der Root-Server des Internets betreibt, und es ist eine seltsame Sache, die man als globales System bezeichnet.\nDie Betreiber haben zudem keinen nennenswerten Vertrag, der sie bindet. ICANN beschäftigt sie nicht und kann sie auf keine geradlinige Weise absetzen. Sie stellen die Root bereit, weil sie es immer getan haben. Die Stabilität des Systems auf dieser Ebene beruht auf gutem Willen und auf nowt Stabilerem, was funktioniert bis zu dem Tag, an dem es das nicht mehr tut.\nICANN betreibt die Root-Zone nicht Das ist die wichtigste Tatsache in diesem Beitrag und sie wird fast nie laut gesagt, also bekommt sie ihre eigene Überschrift.\nICANN betreibt die Root-Zone nicht.\nSie entscheidet, was hineingehört. Sie bearbeitet die Datei nicht, sie signiert die Datei nicht, und sie stellt die Datei nicht bereit. Verisign bearbeitet und signiert. Zwölf Organisationen stellen bereit. ICANNs Aufgabe ist zu sagen, wie die Antwort lauten soll, und dann jemand anderen dazu zu bringen, sie wahr zu machen.\nDiese Trennung ist das Einzige, was ICANN im Zaum hält.\nStell es dir ohne die Trennung vor. Eine Stelle setzt die Politik, hält den Stift, besitzt den Signierschlüssel und betreibt die Server. Zwischen der Entscheidung über eine Sache und dem Zustand, dass diese Sache überall auf der Erde wahr ist, steht keine andere Partei, kein zweites Paar Hände und niemand, der nein sagen könnte. Was immer du von ICANNs Bilanz unten hältst, diese Anordnung wäre schlechter.\nSo wie es ist, gibt es drei Bremsen. Keine einzige davon steht in einer Satzung.\nDie Datei ist öffentlich. Jeder kann die Root-Zone per AXFR ziehen — der Befehl steht oben in diesem Beitrag — und sie gegen die von gestern diffen. Du kannst eine Delegierung nicht heimlich ändern. Jemand anderes muss die Änderung machen. Der Maintainer macht die Bearbeitung und die Signatur. Das ist eine Organisation mehr, die zustimmen muss, und eine mehr, die ablehnen könnte. Die Betreiber stellen aus Einwilligung bereit. Wie oben: ICANN hat keinen nennenswerten Vertrag mit den Root-Server-Betreibern. Sie verteilen die Zone, weil sie es immer getan haben. Nichts verpflichtet sie, irgendetwas zu verteilen — und wie Postel 1998 zeigte, ist Einwilligung beweglich, wenn jemand, dem sie vertrauen, sie nett darum bittet. Die letzte ist die eigentliche Rückfallebene, und sie ist eine Ebene tiefer noch zu Lebzeiten genutzt worden. Als Verisign 2003 .com wildcardete, lieferte das Internet Systems Consortium (ISC) delegation-only in BIND aus, und die Betreiber hörten schlicht auf, die Antworten zu beachten. Niemand musste einen Streit in einem Politikforum gewinnen. Die Fähigkeit der technischen Gemeinschaft, sich zu weigern, steht nirgendwo geschrieben, und alle Beteiligten wissen, dass sie da ist.\nJetzt der unangenehme Teil, denn das ist dünner, als es klingt.\nNiemand hat diese Kontrolle entworfen. Es ist keine Gewaltenteilung, es ist ein Zufall dessen, wie die Arbeit in den 1990ern aufgeteilt wurde, und die Übergabe 2016 hat sie weder gestärkt noch aufgeschrieben. Es gibt keine Regel, die sagt, dass die Stelle, die die Politik setzt, nicht eines Tages auch den Stift halten darf.\nUnd die prüfende Partei ist eine kommerzielle Firma, mit der ICANN Geschäfte macht. Verisign hält die Rolle des Root Zone Maintainer und den .com-Vertrag und — wie der Rest dieses Beitrags darlegt — eine 20-Millionen-Dollar-Vereinbarung mit ICANN, unterschrieben in derselben Verhandlung wie eine .com-Preiserhöhung. Eine Kontrolle, die davon abhängt, dass die eine Partei bereit ist, der anderen etwas zu verweigern, hört auf zu funktionieren, sobald die beiden zusammen etwas unterschreiben.\nDie Trennung ist also das Beste an der heutigen Regelung. Sie ist auch ungeschrieben, ungeplant und von Gewohnheit zusammengehalten.\nDen Namensraum verkaufen Vor jedem Governance-Argument zeigt etwas Einfacheres, was die Leute, die ein Stück des Namensraums halten, damit machen, wenn nichts sie aufhält. Es ist wiederholt passiert, auf jeder Ebene, und beim ersten Mal ganz oben dauerte es neunzehn Tage.\nAm 15. September 2003 fügte Verisign den Zonen .com und .net einen Wildcard-A-Eintrag hinzu:\n*.com. IN A 64.94.110.11 Diese Adresse löst rückwärts zu sitefinder.verisign.com auf. Von diesem Moment an existierte jeder Name in .com und .net. Jeder Tippfehler, jede nicht registrierte Domain, jede fehlerhafte Zeichenkette, jeder abgelaufene Name — alle lösten auf, zu einer Verisign-Suchseite mit Verisigns Werbung.\nWarum das keine Werbegeschichte ist Die Beschwerden von damals drehten sich meist um die Anzeigen, und sie verfehlten den Punkt. NXDOMAIN ist kein Feature für die Benutzererfahrung. Es ist ein tragendes Protokollsignal, und eine enorme Menge Software oberhalb von DNS ist darauf gebaut, fragen zu können „gibt es diesen Namen?“ und eine wahrheitsgemäße Antwort zu bekommen.\nLösch die negative Antwort und Dinge gehen auf Arten kaputt, die mit Browsern nichts zu tun haben.\nMail war das Schlimmste daran, und es ist der Teil, den Leute bis heute falsch verstehen. Verisign veröffentlichte keinen Wildcard-MX-Eintrag. Musste es nicht. RFC 5321 §5.1 sagt, dass ein Absender, wenn eine MX-Abfrage nichts zurückgibt, auf den Adresseintrag der Domain zurückfällt und ihn als implizites MX mit Präferenz 0 behandelt. Verisign hatte gerade jeder nicht existierenden Domain in .com einen Adresseintrag gegeben. Also hatte jeder MTA im Internet — jeder Mail Transfer Agent, jede Maschine, die Mail weiterleitet —, wenn er den Standard korrekt befolgte, nun einen Mail Exchanger für soemcompany.com — und das war Verisigns Kiste.\nVerbinde dich auf Port 25 und sie antwortete:\n220 snubby2-wceast Snubby Mail Rejector Daemon v1.3 ready Verisigns erklärte Absicht war vernünftig genug: die Mail sofort ablehnen, damit sie nicht weltweit in Warteschlangen liegt. Die Umsetzung war es nicht. Snubby gab erst nachdem der sendende MTA den Nachrichtenkörper übertragen hatte auf und lieferte einen Code zurück, den die meisten MTAs als vorübergehenden Fehler lasen — statt eines sofortigen Bounce wurde Mail an vertippte Adressen also tagelang wiederholt, bevor sie starb. Verisign tauschte es später gegen einen Postfix-basierten Responder aus, nachdem Betreiber sich auf der NANOG-Liste beschwert hatten.\nAnti-Spam ging zur selben Zeit kaputt, und leiser. Zu prüfen, ob die Domain eines Absenders überhaupt existiert, war und ist eine der billigsten und wirksamsten Filterheuristiken, die es gibt. Über Nacht existierte jede Domain in den zwei größten TLDs. Die Prüfung gab für alles wahr zurück und hörte auf zu unterscheiden.\nUnd alles andere, was DNS spricht, aber nicht HTTP — Mail-Relays, FTP-Clients, Netzwerkdrucker, Monitoring-Systeme — bekam kein „kein solcher Host“ mehr, sondern einen Webserver, was sich meist als Timeouts und Hänger äußerte statt als saubere Fehler. Ein toter Name sah nun aus wie ein kaputter Dienst.\nEine Firma fügte einen Eintrag zu einer Zonendatei hinzu und änderte die Fehlersemantik des Internets.\nWas es stoppte Keine Governance. Technik, und dann eine Drohung.\nISC lieferte innerhalb von Tagen ein delegation-only-Feature in BIND aus, mit dem Betreiber synthetisierte Antworten aus TLD-Zonen verwerfen konnten — die technische Gemeinschaft leitete um die Registry herum, statt irgendwen anzurufen. Zahlreiche ISPs setzten es ein.\nICANN bat Verisign, den Dienst auszusetzen. Am 21. September weigerte sich Verisign. ICANN forderte es dann am 3. Oktober, mit ausdrücklich benannten vertraglichen Folgen, und Verisign zog die Einträge am 4. Oktober 2003 zurück. Das IAB veröffentlichte seinen architektonischen Einwand gegen Registry-Wildcards, und ICANNs eigenes Security and Stability Advisory Committee berichtete am 9. Juli 2004, der Dienst hätte nie ohne Prüfung ausgerollt werden dürfen und Registries sollten Wildcards auslaufen lassen.\nDann verklagte Verisign ICANN, am 27. Februar 2004, mit dem Argument, ICANN habe ihre Befugnisse überschritten, indem sie es stoppte. Der Fall wurde im August desselben Jahres größtenteils abgewiesen, und der Rest am 1. März 2006 verglichen — ein Vergleich, der Verisign ein neues .com-Registry-Agreement gab.\nLies diese Abfolge noch einmal. Die Registry monetarisierte den Namensraum, für dessen Betrieb sie beauftragt war, weigerte sich aufzuhören, wurde zum Aufhören gezwungen, verklagte die Stelle, die sie zwang, und ging aus dem Vergleich mit einem erneuerten Vertrag für die wertvollste TLD, die es gibt. Sie hält ihn immer noch. Es ist dieselbe Firma, die heute die Root-Zone bearbeitet und signiert.\nDann taten es sowieso alle anderen Die Registry zu stoppen stoppte die Idee nicht, es verschob sie nur einen Sprung nach unten. Wenn der autoritative Server nicht über Nichtexistenz lügen will, tut es der Resolver.\nAb August 2006 begann Earthlink, NXDOMAIN-Antworten an Barefruit umzuleiten und Suchseiten und Anzeigen auszuliefern. Paxfire verkaufte dasselbe und leitete zusätzlich bestimmte eingetippte Stichworte an zahlende Werbekunden um. Comcasts „Domain Helper“ tat es im großen Stil. Im UK betrieben BT und Virgin Media beide so etwas. Die Wirtschaftlichkeit ist aus Sicht eines ISP unwiderstehlich: vertippte Domains sind kostenloser Werbebestand, erzeugt von den Fingern der eigenen Kunden.\nDie Fehlermodi waren schlimmer als Verisigns, denn ein Resolver sieht jede Abfrage, nicht nur eine TLD. Barefruits Umsetzung kaperte NXDOMAIN für private Adressbereiche und brach damit Split-Horizon-Abfragen und VPN-Verhalten in Firmennetzen. Dan Kaminsky demonstrierte Cross-Site-Scripting (XSS) gegen die Umleitungsseiten selbst, denn nun löste jeder nicht existierende Hostname der Welt zu für Angreifer erreichbarem HTML auf, ausgeliefert in einem Kontext, den der Browser der Domain von jemand anderem zuordnete. Den Fehlerfall zu monetarisieren hatte eine fehlgeschlagene Abfrage in eine XSS-Angriffsfläche verwandelt.\nDie Protokollkorrektur Zwei Dinge machten dem ein Ende, und beide sind erwähnenswert, denn sie sind die Form jeder echten Korrektur im DNS: mach die Lüge erkennbar, dann mach sie vertraglich.\nDNSSEC liefert authentifizierte Nichtexistenz. NSEC- und NSEC3-Einträge lassen eine signierte Zone beweisen, dass ein Name nicht existiert, und ein validierender Resolver weist eine synthetisierte Antwort an ihrer Stelle zurück. Nichtexistenz hörte auf, die eine Antwort zu sein, die niemand überprüfen konnte. Es ist nicht wasserdicht — ein Resolver, der unterwegs Signaturen abstreift, kann die Antwort immer noch umschreiben, was genau der Grund ist, warum es zählt, auf dem Client zu validieren statt dem Resolver zu vertrauen, und es ist das Argument, das diese Seite bereits ausführlich gemacht hat.\nUnd ICANN hat diese eine Sache, das muss man ihr lassen, gelernt. Specification 6 des neuen gTLD-Registry-Agreements verbietet Wildcards, synthetisierte Einträge und Umleitung für nicht registrierte Namen rundheraus und verlangt von autoritativen Servern, Name Error, RCODE 3, zurückzugeben. Jeder der 1.200 Strings aus der Runde von 2012 ist vertraglich daran gehindert, das zu tun, was Verisign mit .com gemacht hat.\nDas ist eine echte Verbesserung, und es lohnt sich, genau zu sein, was sie hervorgebracht hat: nicht der Governance-Prozess, sondern neunzehn Tage sichtbarer Kaputtheit im Jahr 2003, die peinlich genug waren, um ein Jahrzehnt später in einen Vertrag geschrieben zu werden.\nUnd nichts davon berührte die Ländercodes Specification 6 bindet gTLDs. Sie bindet sie, weil die ein Registry-Agreement mit ICANN unterschreiben, und dieses Agreement ist der Hebel.\nEine ccTLD unterschreibt nichts dergleichen. Kein Registry-Agreement, keine Specification 6, keine Compliance-Funktion, keine Gebühr. Nichts in ICANNs Regelwerk regelt, wie eine Länderregistry ihre Zone betreibt — weshalb beides unten möglich war und weshalb niemand in der Lage war, es zu stoppen.\nDas ist nicht dasselbe wie zu sagen, ICANN sei abwesend, und ich will präzise sein, wo sie sitzt, denn ich habe zwei Jahre am empfangenden Ende davon verbracht.\nWas ICANN über einer ccTLD hält, ist die Delegierung selbst. Jeder NS-Eintrag, jedes Stück Glue, jeder DS-Eintrag und jede Kontaktänderung für .uk lebt in der Root-Zone, und der einzige Weg in die Root-Zone ist ein IANA-Änderungsantrag — geprüft gegen die registrierten administrativen und technischen Kontakte, und bearbeitet nach IANAs Zeitplan, nicht nach deinem. Nach RFC 1591 entscheidet die IANA letztlich auch, wer die Delegierung überhaupt hält. Neudelegierungen sind selten. Sie sind nicht hypothetisch.\nEine Länderregistry ist also souverän darin, wie sie läuft, und vollständig von einem Dritten abhängig für alles, was in der Root sichtbar sein muss. Die Momente, in denen du eine Änderung am dringendsten brauchst — ein Nameserver zieht um, ein Schlüsselwechsel, dessen DS veröffentlicht sein muss, bevor der alte geht — sind genau die Momente, in denen du in der Warteschlange von jemand anderem stehst. Das ist eine lebendige betriebliche Abhängigkeit und keine Governance-Abstraktion, und es ist ein Thema für die Fortsetzung.\nJetzt beachte, was diese Kombination erzeugt. ICANNs Griff um eine ccTLD ist genau dort fest, wo er eine Registry behindert, die sich benimmt, und genau dort abwesend, wo er eine hätte bremsen können, die es nicht tut. Sie kann deinen DS-Eintrag aufhalten. Sie konnte Kamerun nicht daran hindern, eine ganze Top-Level-Domain auf eine Werbeseite zu richten.\nDie Praxis hörte also nie auf. Sie zog nur dorthin, wo der Vertrag nicht hinreichte.\nKamerun wildcardete eine ganze Top-Level-Domain, um Tippfehler zu ernten.\nIm August 2006 richtete die .cm-Registry jeden nicht registrierten Namen in der Zone auf eine Parkseite mit bezahlten Suchlinks. An dem Spiel ist nichts Subtiles: .cm ist .com mit vergessenem o, der Zielmarkt war also die Vertipp-Rate der größten TLD, die es gibt, und der Betreiber war eine Regierungsbehörde — ANTIC, unter Kameruns Ministerium für Post und Telekommunikation.\nEs zahlte sich aus. NameJet meldete am ersten Tag über 500.000 Dollar an .cm-Verkäufen und mehr als 2 Millionen Dollar in der ersten Woche; hotels.cm ging 2009 für 81.100 Dollar weg. Es tat auch genau das, was man für die Sicherheit der Zone erwarten würde, denn eingehender Vertipp-Verkehr ist der ideale Lieferweg für einen feindlichen Download. Im Dezember 2009 stufte McAfee .cm als riskanteste TLD der Welt ein, mit 36,7 % ihrer Seiten als riskant bewertet.\nVerisign wurde in neunzehn Tagen gezwungen, denselben Trick zurückzunehmen. Kamerun fuhr ihn jahrelang. Der Unterschied ist nicht, dass das eine schlimmer war. Der Unterschied ist, dass das eine einen Vertrag unterschrieben hatte.\nTokelau wurde die größte Länderdomain der Erde, indem es Namen verschenkte.\nTokelau ist ein neuseeländisches Territorium im Südpazifik mit etwa 1.500 Einwohnern. Seine ccTLD, .tk, wurde von Freenom betrieben, das Registrierungen umsonst hergab. Bis 2016 war sie mit 31.311.498 Namen die meistregistrierte Länderdomain der Welt — eine Zahl, die zufälligerweise aus einer von Nominet veröffentlichten Weltkarte stammt.\nKostenlos war nicht kostenlos. Freenoms Bedingungen verlangten von einer kostenlosen Domain regelmäßigen Verkehr und sahen vor, dass die Registry sie zurücknehmen und ihre eigene Werbung darauf ausliefern konnte, wenn die Weiterleitung aufhörte zu funktionieren — oder wenn der Name anfing, lohnende Besucher anzuziehen. Das ist das ganze Geschäft, und es ist eleganter als Verisigns. Versuch nicht zu raten, welche Namen wertvoll sind. Verschenk den gesamten Namensraum zu Grenzkosten null, lass die Welt die wertvollen für dich entdecken, dann hol dir die zurück und monetarisiere den Verkehr. Rund ein Sechstel von Tokelaus Jahreseinkommen kam daher.\nDie externen Kosten landeten bei allen anderen. Kostenlose Registrierung ohne Prüfung ist der ideale Input für Massenmissbrauch — dieselbe Wirtschaftlichkeit wie bei den billigen neuen gTLDs, ganz bis auf null getrieben. Als Meta Klage einreichte, waren Freenoms fünf kostenlose ccTLDs — .tk, .ml, .ga, .cf, .gq — die Quelle von mehr als der Hälfte aller neuen Phishing-Domains aus Länder-TLDs.\nWas es stoppte, ist der Teil, auf den es hier ankommt.\nNicht ICANN, die keinen Vertrag und kein Standing hatte. Nicht Tokelau, das ein Sechstel seines Nationaleinkommens einsammelte. Nicht Neuseeland. Metas Anwälte, im Northern District of California, im März 2023, wegen Cybersquatting und Markenrechtsverletzung.\nFreenom stoppte neue Registrierungen innerhalb von Tagen. Phishing aus diesen Endungen fiel von über 60 % auf unter 15 %. Freenom verglich sich im Februar 2024 und verließ das Domain-Geschäft, und bis zu jenem März hatten rund 12,6 Millionen Domains — 99 % seines Portfolios — aufgehört aufzulösen.\nDie Rechtsabteilung eines einzelnen Konzerns entfernte, vor einem einzigen amerikanischen Gericht, zwölfeinhalb Millionen Namen aus dem Internet. Keine Governance-Instanz in der Geschichte des DNS hat je so viel Autorität über den Namensraum ausgeübt, und sie tat es nicht durch Governance.\nWas das dritte Mal in diesem Beitrag ist, dass die Antwort auf „was setzt hier eigentlich irgendetwas durch“ sich als ein Gericht in Kalifornien herausstellt — und das zweite Mal, dass die Durchsetzung eine Privatpartei war, die in ihrem eigenen kommerziellen Interesse handelte, das bei der Gelegenheit zufällig mit dem aller anderen zusammenfiel.\nUnd .uk ist auch eine ccTLD. Dieselbe Abwesenheit jedes Vertrags darüber, wie die Zone betrieben wird, dieselbe Abwesenheit von Specification 6, dieselbe Freiheit, sie zu wildcarden oder den Namensraum zu verschenken. Es tat keines von beidem. Es betrieb stattdessen einen Missbrauchsprozess.\nUnd hier hört die saubere Aufteilung auf, sauber zu sein, und das gehört bewusst verdorben.\nNominet betreibt nicht nur .uk. Es betreibt auch generische Top-Level-Domains — eigene und mehrere Dutzend weitere im Auftrag anderer Betreiber — und für die unterschreibt es das ICANN-Registry-Agreement wie alle anderen, Specification 6 und laufende Überwachung inklusive. Auf seiner eigenen Plattform war die vertragslose Zone rund dreißig zu eins in der Unterzahl.\nICANNs Anforderungen erreichten .uk also trotzdem. Nicht durch Autorität, die sie nicht hatte, sondern weil niemand bei Verstand zwei Betriebsregime nebeneinander fährt, um eine Ausnahme für eine Zone zu bewahren. Du baust das strenge Ding einmal und fährst alles darauf.\nEs ist dieselbe Form wie beim OFAC-Problem weiter oben: ICANNs formale Reichweite endet am Vertrag, und ihre tatsächliche Reichweite geht darüber hinaus, fortgepflanzt von Betreibern, für die überall zu erfüllen billiger ist als die Unterscheidung zu pflegen. Die Menge der Registries, die faktisch von ICANN regiert werden, ist deutlich größer als die Menge derer, die irgendetwas unterschrieben haben.\nDieser Bestand, wie es war, ihn zu betreiben, und was danach mit Nominet geschah, ist ein eigener Beitrag.\nBleibt die Frage, bei der dieser Beitrag aus verschiedenen Richtungen immer wieder landet: wenn die Verträge nicht hinreichen, was hält eine Registry dann davon ab, owt zu tun, was ihr passt?\nEine Fortsetzung wird sie von innerhalb Nominets beantworten — die Veröffentlichungspipeline, EPP (das Protokoll, mit dem Registrare Namen in einer Registry anlegen und ändern) und die Wirtschaftlichkeit darunter, Signieren im Registry-Maßstab, und wer einem einen Namen wirklich wegnehmen kann. In diesem Beitrag geht es um die Ebene darüber, und die Ebene darüber kommt nicht gut weg.\nDas Geld Der nächste Vorwurf ist einfacher und braucht weniger Auslegung.\nDas Produkt, das sie erfanden 2012 öffnete ICANN die Bewerbung für neue generische Top-Level-Domains. Jeder konnte sich bewerben, einen neuen String rechts vom Punkt zu betreiben, für eine zum großen Teil nicht erstattungsfähige Prüfgebühr von 185.000 Dollar.\nEs gingen 1.930 Bewerbungen ein. Das sind über 350 Millionen Dollar an Prüfgebühren, eingesammelt, bevor ein einziger String delegiert war. Bewerber, die früh zurückzogen, bekamen einen Teil davon gestaffelt zurück; die große Mehrheit davon blieb.\nICANN beschrieb die Gebühr als Kostendeckung.\nWo dann zwei Bewerber denselben String wollten und sich nicht privat einigten, versteigerte ICANN ihn zwischen ihnen und behielt den Erlös, der weitere 240.590.128 Dollar ausmachte. Das Programm ließ dich also für die Bewerbung zahlen und noch einmal fürs Gewinnen.\nStell die Frage, die 2008 hätte gestellt werden sollen: welches Problem hat das gelöst?\nDie erklärte Begründung waren Wettbewerb, Auswahl und Innovation. Vierzehn Jahre später sind die Ergebnisse messbar. Rund 1.200 Strings wurden delegiert. Stand August 2026 gibt es 1.112 neue gTLDs mit zusammen etwa 48,7 Millionen Domains — gegen .com allein mit mehr als dem Zehnfachen davon. Das Monopol des Platzhirschen wurde nicht im Geringsten gestört. Es bekam stattdessen eine Preiserhöhung.\nDas Auswahlargument scheitert an seinen eigenen Belegen. 34 % der Bewerbungen von 2012 waren .brand-Strings — eine Firma, die sich um ihre eigene Marke bewirbt, größtenteils damit sie niemand anders bekommt. Das sind für niemanden neue Auswahlmöglichkeiten. Viele wurden nie genutzt. McDonald\u0026rsquo;s hat .mcdonalds nie gestartet. Intel nahm .intel im Juli 2016 in Empfang und kündigte es im November 2020, Symantec gab .symantec zwei Monate früher auf, und SC Johnson bewarb sich um acht Strings — .scjohnson, .raid, .glade, .off, .duck darunter — und kündigte im Januar 2022 alle. Sechs Jahre nach dem Bewerbungsfenster war mehr als jede zehnte neue gTLD immer noch nicht gestartet, 144 hatten keine Sunrise-Periode erreicht, und L\u0026rsquo;Oréal saß auf Strings, für die es nie irgendeinen Plan angekündigt hatte.\nDas ist eine Menge toter Namensraum. Hier ist, warum es ICANN nicht stört.\nNach dem Basis-Registry-Agreement zahlt ein gTLD-Betreiber ICANN eine feste Gebühr von 25.000 Dollar im Jahr, plus 0,25 Dollar je Registrierung — aber erst, wenn die TLD 50.000 Transaktionen in einem Quartal überschreitet. Unterhalb dieser Schwelle gibt es überhaupt keine Transaktionsgebühr.\nLies, was das heißt. ICANNs Einkommen aus einer Top-Level-Domain mit null Namen darin ist genau dasselbe wie aus einer mit vierzigtausend: 25.000 Dollar im Jahr, jedes Jahr, für eine Delegierung, die niemand nutzt. Ein toter String ist in ICANNs Büchern kein Misserfolg. Er ist eine Rente ohne Supportaufwand.\nEs gab keinen finanziellen Grund für ICANN, sich darum zu scheren, ob irgendetwas davon funktionierte, und es ist schwer, Belege dafür zu finden, dass sie es tat.\nWas das Internet stattdessen bekam Das Programm brachte einen messbaren Effekt hervor, und es ist nicht der aus dem Prospekt.\nDie neuen Strings, die sich verkauften, verkauften sich über den Preis. Registries ohne Marke und ohne natürliche Nachfrage konkurrierten auf die einzige ihnen verfügbare Art, für einen Dollar oder weniger pro Namen, in großen Mengen, mit minimalen Prüfungen. Das ist ein Produkt, und es fand seinen Markt.\nInterisles Studie Cybercrime Supply Chain 2025 fand, dass neue gTLDs 47 % der gemeldeten Cybercrime-Domains trugen, während sie 12 % des Domain-Markts ausmachen — grob eine sechsfache Überrepräsentation. Dieselbe Studie verzeichnete 19,5 Millionen einzelne bei Angriffen genutzte Domains, plus 126 % gegenüber dem Vorjahr, davon 7,3 Millionen in Massen registriert. Der gemeinsame Faktor, den sie bei den am meisten missbrauchten Domains identifiziert, ist, dass sie billig sind.\nICANN hat Phishing nicht erfunden. Aber sie hat 1.200 neue Orte hergestellt, von denen aus man es tun kann, den Eintritt so bepreist, dass die einzig gangbare Strategie für die meisten von ihnen Menge zu Kosten nahe null war, und von jedem eine feste Gebühr genommen, unabhängig davon, was dabei herauskam.\nDer Vorzeige-Misserfolg des Programms macht den Punkt besser als jede Statistik. .sucks wurde an Vox Populi delegiert, das Markeninhabern während der Sunrise-Phase 2.499 Dollar pro Namen berechnete — ein Preis, der genau deshalb so gesetzt war, weil Marken ihn zahlen müssten, um jemand anderen davon abzuhalten. ICANNs Reaktion war, die Registry bei der US-Handelsaufsicht FTC anzuzeigen wegen Kampfpreisen. Die FTC fand keine Regelverstöße und merkte an, ICANN habe mehrere Bedenken, die die FTC zum neuen gTLD-Programm vorgebracht hatte, bereits ignoriert.\nDas ist die ganze Sache in einer Episode. ICANN entwirft das Programm, ignoriert die Warnungen der Aufsicht dazu, delegiert den String, kassiert die Gebühr und beschwert sich dann bei der Aufsicht über das vorhersehbare Ergebnis.\nDie Bewerbungen für die nächste Runde öffneten 2026. Die Gebühr beträgt 227.000 Dollar.\nDie Strings, die zu gefährlich zum Delegieren waren Noch etwas, das das Programm hervorbrachte, und das ist für jeden, der je ein internes Netz gebaut hat.\nOrganisationen haben immer schon Top-Level-Domains für den internen Gebrauch erfunden, in der Annahme, dass ein Name, den es öffentlich nicht gibt, es auch nie geben wird. .corp. .home. .mail. .local. Nimm irgendwas, steck es in dein Active Directory, von außen sieht es niemand.\nDie Runde von 2012 schlug vor, einige davon wirklich zu delegieren, womit jede dieser privaten Annahmen zu einem akuten Sicherheitsproblem wird: interne Namen fangen an, zu den Servern von jemand anderem aufzulösen, Abfragen, die früher fehlschlugen, fangen an, deine interne Struktur an eine Registry zu verraten, und Zertifikate, die für interne Namen ausgestellt wurden, werden zu Zertifikaten für Namen, die jetzt ein Fremder kontrolliert.\nNiemand hatte nachgesehen. Es kam nur ans Licht, weil Forscher maßen, was tatsächlich an die Root gestellt wurde, und feststellten, dass .home und .corp zu den meistabgefragten Strings überhaupt gehörten — stark genutzte Namen, die nie an irgendwen delegiert worden waren. ICANNs eigenes Security and Stability Advisory Committee brachte es 2013 zur Sprache, nachdem die Bewerbungen eingegangen waren.\n.corp, .home und .mail sind nie delegiert worden. Sie sind immer noch auf unbestimmte Zeit zurückgestellt, weil ihre Delegierung zu viel kaputt machen würde. Drei Strings, um die man sich beworben und für die man bezahlt hatte, erwiesen sich als zu gefährlich, um zu existieren.\nDas ist ein Programm, das die Root erweiterte, ohne vorher festzustellen, womit die Erweiterung kollidieren würde, und es hinterher aus den Messungen anderer Leute erfuhr. Wenn du das praktische Ende davon willst: es ist der Grund, warum eine interne TLD zu erfinden eine schlechte Idee ist — der Namensraum, den du erfunden hast, ist nur so lange privat, bis ihn jemand verkauft.\nDas Auktionsgeld Zwischen Juni 2014 und Juli 2016 sammelten diese Streitauktionen jene 240.590.128 Dollar ein, rund 233 Millionen nach Auktionskosten.\nDas ist Geld, erlangt durch den Verkauf von Stücken eines Namensraums, den ICANN nicht besitzt und treuhänderisch hält. Es gibt eine vertretbare Antwort darauf, was damit geschehen soll, und die Gemeinschaft setzte eine gemeinschaftsübergreifende Arbeitsgruppe ein, um eine zu finden.\nWährend diese Arbeitsgruppe noch tagte, nahm ICANNs Board 36 Millionen Dollar des Erlöses und steckte sie in ICANNs eigene Rücklage, der 68 Millionen Dollar zu ihrem Ziel fehlten. Nicht vorgeschlagen — beschlossen. Und als die Gemeinschaft widersprach, war die vorgelegte Position, die Alternative sei, dass ICANN die Gebühren erhöhe.\nDie Arbeitsgruppe machte trotzdem weiter. Das Board übernahm ihre Empfehlungen erst im Juni 2022 — sechs Jahre nach der letzten Auktion, während derer ICANN eine Viertelmilliarde Dollar des Geldes anderer Leute hielt und sich 36 Millionen davon nahm, während die Leute, die entschieden, wofür es da war, noch im Raum saßen.\nDie .org-Preisobergrenzen Im März 2019 schlug ICANN vor, das .org-Registry-Agreement mit gestrichenen Preisobergrenzen zu verlängern. Die Obergrenzen waren das, was den Betreiber von .org daran hinderte, den Wohltätigkeitsorganisationen, NGOs und Non-Profits, denen zwanzig Jahre lang gesagt worden war, .org sei ihr Ort, zu berechnen, was er wollte.\nDie öffentliche Kommentierung lief. 3.252 Kommentare waren gegen die Streichung. Sechs dafür. Zu den Gegnern gehörten NPR, die YMCA, C-SPAN, die National Geographic Society, AARP und der National Trust for Historic Preservation — nicht die üblichen Kommentatoren aus der Domain-Branche, sondern genau die Klientel, für die es .org gibt.\nAm 1. Juli 2019 unterschrieb ICANN das Agreement. Keine öffentliche Ankündigung. Ein Vergleich des unterschriebenen Textes mit dem vorgeschlagenen zeigte keine als Reaktion auf die Kommentierungsphase vorgenommenen Änderungen. Nicht „einige Bedenken berücksichtigt“ — dasselbe Dokument.\nWenn ein öffentliches Kommentierungsverfahren 542 zu 1 dagegen ausgehen und kein einziges Wort ändern kann, ist es keine Konsultation. Es ist eine Formalität, die eine Aktenspur erzeugt.\nDann der Verkauf Im November 2019, vier Monate später, kündigte die Internet Society an, sie verkaufe Public Interest Registry — den Non-Profit-Betreiber von .org — an Ethos Capital, eine Private-Equity-Firma, für 1,135 Milliarden Dollar.\nDie Streichung der Preisobergrenze ist das, was PIR 1,135 Milliarden Dollar wert machte. Eine Registry, die die Preise nicht erhöhen kann, ist eine Rente. Eine, die es kann, ist ein Wachstumswert. ICANN hatte vier Monate zuvor das eine in das andere verwandelt, gegen einhelligen Widerspruch, und der Markt hatte es sofort eingepreist.\nEthos Capital war im Mai 2019 gegründet worden. Die Domain ethoscapital.com wurde am 8. Mai 2019 von Fadi Chehadé, ICANNs früherem Vorstandschef registriert — in der Woche der Frist für ICANNs Mitarbeiter, ihren Bericht zur Streichung der Preisobergrenzen zu veröffentlichen. Sein Name tauchte auf Ethos Capitals Website nirgends auf, als der Deal angekündigt wurde. Seine Beteiligung wurde wegen WHOIS-Daten öffentlich — dem öffentlichen Register, wem eine Domain gehört, um das es im nächsten Abschnitt geht — und die Ironie schreibt sich von selbst. Ethos bestätigte dann, er habe die Transaktion beraten, und im Juli 2020 wurde er dessen Co-CEO.\nICANN blockierte den Verkauf schließlich, im April 2020. Es ist fair, das festzuhalten. Es ist auch fair festzuhalten, was dem vorausging: Monate, in denen ICANN darauf bestand, die Sache liege größtenteils außerhalb ihres Auftrags, anhaltende öffentliche Kampagnen, Briefe von US-Senatoren und schließlich ein Brief des Generalstaatsanwalts von Kalifornien, der ICANN von dem Deal abriet und die mangelnde Transparenz rund um Ethos Capital anführte.\nICANN war hier nicht die Schutzvorrichtung. ICANN strich die Obergrenzen, die die Gelegenheit schufen, und wurde selbst in letzter Minute von einem Justizbeamten eines Bundesstaats gestoppt — was eine weitere Demonstration dafür ist, dass der eigentliche Rechenschaftsmechanismus in diesem System die kalifornische Gerichtsbarkeit ist und nicht irgendetwas in der Satzung.\nDie Verisign-Vereinbarung Das ist dieselbe Gegenpartei wie bei der Wildcard, fünfzehn Jahre später. Im Oktober 2018 unterzeichneten NTIA und Verisign Amendment 35 zum Cooperative Agreement, das den .com-Preisstopp aufhob und Erhöhungen von 7 % pro Jahr in vier von je sechs Jahren erlaubte.\nDas war die Entscheidung der US-Regierung, nicht ICANNs. Aber die Erhöhungen brauchten trotzdem eine Änderung des .com-Registry-Agreements, und das ist ICANNs. Im März 2020 stimmte ICANN Amendment 3 zu — und daneben einem bindenden Letter of Intent, unter dem Verisign ICANN über fünf Jahre 20 Millionen Dollar zahlt, ab 1. Januar 2021, für Sicherheits- und Stabilitätsarbeit.\nBeides war vor Beginn der öffentlichen Kommentierung ausgehandelt. Die Kommentierungsphase lief, war überwältigend ablehnend und änderte nichts — dasselbe Muster wie bei .org, im selben Zeitfenster, mit demselben Ergebnis.\nNimm die Struktur beim Wort. Die Stelle, die entscheidet, ob ein Monopolist die Preise erhöhen darf, verhandelte zur selben Zeit und mit derselben Gegenpartei eine Zahlung an sich selbst. Die öffentliche Kommentierung kam danach und war Dekoration. Wofür das Geld auch ausgegeben wird, eine Regelung, in der die Aufsicht von den Beaufsichtigten in derselben Transaktion wie die Preiserhöhung bezahlt wird, ist eine, die keine kompetente Aufsicht eingehen würde, und das Wort, zu dem die Kommentierenden damals griffen — Schmiergeld — ist das naheliegende.\nDer .com-Großhandelspreis ist auf dieser Grundlage von 7,85 auf 10,26 Dollar gestiegen, bei einem Namen ohne technischen Bedarf für eine Preiserhöhung und ohne Wettbewerber, zu dem ein Registrant wechseln könnte.\nAcht Länder gegen eine Firma Wenn du eine einzelne Episode willst, die zeigt, wem ICANN tatsächlich Rechenschaft schuldet, dann ist es .amazon, und sie lief sieben Jahre.\nAmazon, die Firma, bewarb sich in der Runde 2012 um .amazon. Die Amazon Cooperation Treaty Organization widersprach — Bolivien, Brasilien, Kolumbien, Ecuador, Guyana, Peru, Suriname und Venezuela, acht souveräne Staaten, deren Gebiet der Name beschreibt und in denen rund 30 Millionen Menschen leben. Ihre Position war, dass ein gemeinsamer geografischer und kultureller Name nicht zum Privateigentum einer Firma werden sollte.\nSie nutzten den Kanal, den ICANN für Regierungen vorsieht. Das Governmental Advisory Committee (GAC) gab eine Konsensempfehlung gegen den Antrag ab, und im Mai 2014 akzeptierte ICANNs Board sie. Die Staaten hatten gewonnen, über den Mechanismus, der genau dafür entworfen war.\nAmazon reichte eine Klage im Independent Review Process (IRP) ein.\n2017 entschied das IRP-Panel für Amazon. Es befand, das Board habe im Widerspruch zu ICANNs eigener Satzung gehandelt, hielt fest, dass das Board eine GAC-Konsensempfehlung nicht als abschließend behandeln darf, wies es an, die Anträge in der Sache neu zu bewerten, und verurteilte ICANN, Amazon 163.045,51 Dollar an Kosten zu erstatten.\nIm Mai 2019 kam ICANN zu dem Schluss, es gebe keinen politischen Grund, die Anträge nicht weiterzuführen. Amazon bekam .amazon.\nLies die Struktur statt des Ergebnisses, denn das Ergebnis ist strittig und die Struktur nicht.\nRegierungen bekommen das GAC, und das GAC berät. Ein Konzern bekommt den Independent Review Process, und der IRP produziert eine bindende Feststellung, eine Anweisung an das Board und einen Kostenausspruch. Als diese beiden Kanäle frontal aufeinandertrafen, war die Feststellung des Panels ausdrücklich, dass der staatliche nicht abschließend ist.\nICANN hat also einen funktionierenden Rechenschaftsmechanismus. Er funktionierte. Er wurde von einer der größten Firmen der Erde erfolgreich genutzt, um den gemeinsamen Widerspruch von acht Ländern zu kippen, und ICANN bezahlte für dieses Vergnügen ihre Anwaltskosten.\nDas ist dieselbe Tatsache wie das Gerichtsbarkeitsproblem weiter oben in diesem Beitrag, in anderen Kleidern. Die Mechanismen sind real, und sie sind so geformt, dass die Parteien, die sie sich leisten können, diejenigen sind, die Ergebnisse aus ihnen herausholen. Acht Regierungen konnten den beratenden Kanal nicht halten. Eine Firma brachte den rechtlichen Kanal in drei Jahren zum Funktionieren.\nDer DSGVO-Kampf: was ICANN tut, wenn ein Gesetz für sie gilt Der stärkste Beleg über eine Institution ist nicht ihr Leitbild. Es ist, was sie tut, wenn zum ersten Mal eine Regel gegen sie durchgesetzt wird, die sie nicht selbst geschrieben hat.\nFür ICANN war dieser Moment die DSGVO, und das Protokoll ist eindeutig.\nEs fehlte ICANN nicht an Warnungen. Sie hatte, nach der Zählung des Register, mehr als ein Jahrzehnt Briefe, die ihr sagten, dass WHOIS — die Veröffentlichung von Name, Postanschrift, E-Mail-Adresse und Telefonnummer jedes Domain-Registranten, an jeden, ohne Zugangskontrolle — mit europäischem Datenschutzrecht unvereinbar sei. Die DSGVO selbst wurde 2016 verabschiedet, mit einem Vorlauf von zwei Jahren, eigens damit Organisationen sich vorbereiten konnten. ICANN kam im Mai 2018 ohne konformes Modell an.\nWas sie stattdessen tat, im April 2018, war nach Brüssel zu fahren und die Artikel-29-Datenschutzgruppe um ein einjähriges Durchsetzungsmoratorium zu bitten, plus die Erlaubnis, in der Zwischenzeit weiter die E-Mail-Adressen von Registranten zu veröffentlichen.\nLass dir auf der Zunge zergehen, was diese Bitte eigentlich ist. Keine Fristverlängerung für Papierkram. Eine Bitte, europäische Aufsichtsbehörden mögen zustimmen, eine grundrechtliche Verordnung ein Jahr lang gegen eine Organisation und ihre weltweiten Vertragspartner nicht durchzusetzen, weil diese Organisation nicht dazu gekommen war, sie einzuhalten. Es gibt in der DSGVO keinen Mechanismus, das zu gewähren. Datenschutz ist ein Grundrecht nach der Charta; keine Aufsichtsbehörde und auch nicht der Europäische Datenschutzausschuss hat die Befugnis, es für einen einzelnen Verantwortlichen auszusetzen. ICANN bat nicht um ein Zugeständnis, das ihr vorenthalten wurde. Sie bat um etwas, das es nicht gibt, offenbar ohne festgestellt zu haben, ob es das gibt.\nDie Artikel-29-Gruppe lehnte beides ab. ICANNs eigene Zusammenfassung des Treffens räumte ein, dass die E-Mail-Adressen von Registranten sowie administrativen und technischen Kontakten anonymisiert werden müssen, und ließ jede Erwähnung des erbetenen Moratoriums schlicht weg.\nDann klagte sie.\nAm 25. Mai 2018, dem Tag, an dem die DSGVO in Kraft trat, klagte ICANN gegen EPAG — Tucows\u0026rsquo; deutschen Registrar — in Bonn. EPAG hatte entschieden, keine Admin-C- und Tech-C-Kontaktdaten mehr zu erheben, mit der Begründung, personenbezogene Daten zu erheben, für die man keine Verwendung hat, sei genau das, was die DSGVO verbietet. Tucows\u0026rsquo; Position war, dass in der überwältigenden Mehrheit der Registrierungen Registrant, Admin- und Tech-Kontakt ohnehin dieselbe Person sind, die Erhebung also nicht bloß rechtswidrig, sondern sinnlos war.\nICANNs Rechtstheorie war, dass die DSGVO-Grundlage „zur Erfüllung eines Vertrags erforderlich“ die Erhebung decke, weil ICANNs eigener Vertrag mit dem Registrar sie verlangte. Das ist ein bemerkenswertes Argument: dass eine Organisation eine Rechtsgrundlage für die Verarbeitung der personenbezogenen Daten anderer Leute herstellen kann, indem sie eine Erhebungspflicht in einen Vertrag mit einem Dritten schreibt. Wenn das funktionierte, wäre Art. 6 Abs. 1 lit. b eine Formalität, die jeder durch Formulieren erfüllen könnte.\nEs funktionierte nicht. ICANN verlor in Bonn. Sie legte Rechtsmittel ein. Sie verlor wieder. Im August 2018 wies das Kölner Berufungsgericht sie ein drittes Mal ab, fand die früheren Entscheidungen überzeugend, hielt fest, es gebe keinen dringenden Notfall, der eine einstweilige Verfügung rechtfertige, und lehnte — das ist der Teil, den man zweimal lesen sollte — ICANNs Antrag ab, die Frage dem Gerichtshof der Europäischen Union vorzulegen, mit der Begründung, ICANNs Rechtsauslegung sei für die Entscheidung nicht erheblich. Das Gericht hielt das Argument nicht für knapp genug, um in Luxemburg nachzufragen.\nICANN gab trotzdem das Geld ihrer Mitglieder aus, um den Fall dorthin zu drücken. 2019 gab sie WHOIS ganz auf.\nDas technische Ergebnis war richtig — WHOIS, wie es existierte, hätte nicht existieren dürfen. Aber schau, wie es erreicht wurde. Zehn Jahre Warnungen ignoriert. Eine Bitte um Ausnahme von einem Grundrecht. Ein Prozess gegen den eigenen Vertragspartner, eingereicht am Tag des Inkrafttretens des Gesetzes, um festzustellen, dass das Gesetz nicht so gilt, wie die Aufsichtsbehörden sagten. Drei Niederlagen. Dann Kapitulation.\nDas ist keine Organisation, die ein Gesetz falsch gelesen hat. Es ist eine Organisation, die bis Gerichte es ihr dreimal sagten, nicht akzeptierte, dass das Gesetz überhaupt an sie gerichtet war.\nWas es alle anderen gekostet hat Der größte Teil dieses Beitrags handelt davon, was ICANN und die Registries getan haben. Hier geht es darum, wer dafür bezahlt hat, denn sie waren es sehr selten.\nJeder .com-Registrant auf der Erde zahlt die Erhöhung. Der .com-Großhandelspreis ging von 7,85 auf 10,26 Dollar. Verisigns eigene Berichterstattung setzt den .com-Bestand zum 31. März 2026 auf 163,6 Millionen Namen. Multipliziere die beiden, und diese Erhöhung ist in der Größenordnung von 394 Millionen Dollar im Jahr wert, genommen von jedem .com-Registranten überall auf der Welt, für einen Namen, der keine technische Änderung brauchte, die sie rechtfertigen würde. Ein Unternehmen in Lagos oder Manila zahlt dieselbe Erhöhung wie eines in Palo Alto, entschieden von einer amerikanischen Behörde und einem amerikanischen Non-Profit, das vom Begünstigten in derselben Verhandlung 20 Millionen Dollar genommen hat.\nDie .org-Entscheidung landet bei Wohltätigkeitsorganisationen weltweit. .org wurde dem Non-Profit-Sektor zwanzig Jahre lang als der Teil des Namensraums verkauft, der ihm gehört. Die Obergrenzen aufzuheben war eine Entscheidung, dass, wer immer es betreibt, ihnen berechnen darf, was der Markt hergibt. NPR und die YMCA können das verkraften. Eine kleine NGO, die von einer Förderung lebt, kann es nicht, und sie wurde auch nicht gefragt — 3.252 dagegen, sechs dafür, unterschrieben ohne ein geändertes Wort.\nDie Missbrauchslast trägt jeder, der einen Mailserver betreibt. Neue gTLDs sind 12 % des Markts und 47 % der gemeldeten Cybercrime-Domains. Jeder dieser Namen kommt im Posteingang von jemand anderem an, in der Missbrauchswarteschlange von jemand anderem, in den Betrugsverlusten von jemand anderem. ICANN kassierte 185.000 Dollar je Bewerbung und kassiert 25.000 Dollar im Jahr je String, unabhängig davon. Die Kosten dessen, was die billigen Strings dann hervorbrachten, fallen auf jeden Mail-Betreiber, jede Bank, jedes Sicherheitsteam und jede Person, die auf eine Phishing-Seite hereinfällt. Das ist eine externe Wirkung im Lehrbuchsinn, und das Programm wurde ohne eine Zeile dazu entworfen, wer sie tragen würde.\nSite Finder brach die Fehlersemantik des ganzen Planeten auf einmal. Das gehört klar gesagt, denn es liest sich leicht als amerikanische Geschichte. Es gibt eine Root und ein .com. Als Verisign änderte, was ein nicht existierender Name tut, änderte es das für jedes Netz auf der Erde gleichzeitig — einschließlich jedes Netzes ohne jede Beziehung zu Verisign, ohne Mitsprache bei der Entscheidung und ohne Ausweg außer die eigenen Resolver zu patchen, was sehr viele von ihnen dann auch taten.\nWHOIS ging bei denen dunkel, die es gegen Missbrauch einsetzten. Beide Schäden hier sind real und beide waren vermeidbar. Name, Anschrift, E-Mail und Telefonnummer jedes Registranten an jeden zu veröffentlichen, der fragte, war ein echter, jahrzehntelanger Schaden für Menschen überall auf der Welt, und die DSGVO hatte damit recht. Aber ICANN hatte mehr als zehn Jahre Vorwarnung und keinen Plan, also war der Mai 2018 kein gesteuerter Übergang zu abgestuftem Zugang. Es war eine abrupte Abschaltung. Missbrauchsforscher, Sicherheitsteams und Strafverfolgung, auch weit außerhalb Europas, verloren über Nacht ein funktionierendes Werkzeug, weil ICANN den Vorlauf mit Prozessieren verbracht hatte statt mit dem Bau des Ersatzes. Die Bloßstellung davor und das Vakuum danach gehören beide zu demselben Versäumnis, sich vorzubereiten.\nUnd 12,6 Millionen Namen hörten auf aufzulösen. Der Freenom-Zusammenbruch war ein gutes Ergebnis für die Phishing-Zahlen. Er war kein gutes Ergebnis für alle, die ein kostenloses .tk oder .ml nutzten, weil sie 10 Dollar im Jahr nicht erübrigen konnten, und davon gab es sehr viele, überproportional an Orten, wo 10 Dollar nicht nichts sind. Wenn der einzige kostenlose Namensraum im Internet zugleich der meistmissbrauchte ist, sind die, die ihn beim Untergang verlieren, nicht die Kriminellen. Die zogen in der Woche darauf zum nächsten billigen Ding.\nDie Form ist durchgängig. Die Entscheidungen fallen in Kalifornien, die Einnahmen werden in Kalifornien eingesammelt, und die Kosten werden weltweit an Leute verteilt, die keine Stimme, keinen Vertrag und kein Gericht haben, das sie erreichen können.\nUnd nur vor amerikanischen Gerichten Jetzt, wo das Protokoll vorliegt, komm zurück auf den Gerichtsbarkeitspunkt vom Anfang dieses Beitrags, denn er leistet mehr als die Rechtsform.\nAlle auf der Welt sind dem unterworfen, was ICANN entscheidet. Die Leute, die etwas dagegen ausrichten können, sind die, die in Kalifornien prozessieren können.\nÜberleg, wen das aussperrt. Einen ccTLD-Betreiber in Kamerun. Einen Registranten in Teheran, dessen Domain gelöscht wurde, weil ein Registrar OFAC überdehnt anwandte, das ihn nie band. Einen Registrar in Bonn — was genau der Grund ist, warum der Streit zwischen ICANN und EPAG als deutscher Fall nach deutschem Recht geführt werden musste und überhaupt nicht als ICANN-Rechenschaftssache. Jede kleine Registry, die keine amerikanischen Anwälte finanzieren kann, um einen Punkt kalifornischen Non-Profit-Rechts gegen eine Organisation mit einem neunstelligen Budget zu vertreten.\nDann überleg, wen es hereinlässt. Jeder Eingriff in diesem Beitrag, der tatsächlich etwas verändert hat:\nSite Finder endete, als ICANN Verisigns Vertrag bedrohte — und Verisigns Antwort war, vor einem US-Gericht zu klagen und mit einem erneuerten .com aus dem Vergleich zu gehen. Der .org-Verkauf wurde gestoppt, nachdem der Generalstaatsanwalt von Kalifornien einen Brief geschrieben hatte. Freenom hörte auf, weil Meta im Northern District of California klagte, und 12,6 Millionen Namen gingen dahinter dunkel. .amazon ging an Amazon, weil Amazon ICANN durch deren eigenen Independent Review Process zog und Kosten zugesprochen bekam. Vier Eingriffe, die funktionierten. Vier amerikanische Akteure — ein bundesstaatlicher Justizbeamter und drei Konzerne. Kein einziger davon ein Weg, der jemandem außerhalb der Vereinigten Staaten offensteht, und in dreien der vier war das Bewegende das kommerzielle Interesse einer Privatfirma, das bei diesen Gelegenheiten zufällig in dieselbe Richtung zeigte wie das aller anderen.\nDie Gemeinschaft hat das durchaus angesprochen. Eine Untergruppe zur Gerichtsbarkeit in der Rechenschafts-Arbeitsgruppe verbrachte Work Stream 2 damit und produzierte Empfehlungen, die die Dinge ungefähr dort ließen, wo sie sie vorfanden, was nicht überrascht, wenn der Übergabevorschlag die eine Änderung, auf die es ankam, schon vor Sitzungsbeginn für außerhalb des Auftrags erklärt hatte.\nGlobale Multi-Stakeholder-Governance löst sich also, an der einzigen Stelle, an der man sie prüfen kann, in Folgendes auf: du darfst in Kalifornien klagen, wenn du es dir leisten kannst.\nWas das Protokoll tatsächlich zeigt Stell sie zusammen, denn einzeln hat jedes eine Ausrede und zusammen haben sie keine.\nEine Organisation, der deutsche Gerichte dreimal sagen mussten, dass europäisches Recht für sie gilt, nachdem sie zuvor die Aufsichtsbehörden dieser Gerichte gebeten hatte, es einfach nicht durchzusetzen.\nEine Organisation, die ein Produkt erfand, nach dem niemand gefragt hatte, mehr als 350 Millionen Dollar an Gebühren dafür nahm, Bewerbungen dafür zu prüfen, weitere 240 Millionen mit der Versteigerung der umstrittenen, und jetzt 25.000 Dollar im Jahr von Top-Level-Domains kassiert, in denen nichts drin ist — während die Strings, die sich verkauften, zum billigsten Ort im Internet wurden, um eine Phishing-Domain zu kaufen.\nEine Organisation, deren öffentliches Kommentierungsverfahren 542 zu 1 dagegen ausgegangen ist und kein einziges Wort des Dokuments geändert hat, zu dem sie konsultierte.\nEine Organisation, die die Preisobergrenzen für den Non-Profit-Namensraum vier Monate vor dem 1,135-Milliarden-Dollar-Gebot des Private-Equity-Vehikels ihres früheren Vorstandschefs aufhob, und die von einem Generalstaatsanwalt eines Bundesstaats gestoppt werden musste statt von irgendeinem eigenen Mechanismus.\nEine Organisation, die vom Monopol-Registrar 20 Millionen Dollar in derselben Verhandlung nahm, in der sie dem Monopol-Registrar Preiserhöhungen erlaubte, und die öffentliche Kommentierung danach öffnete.\nEine Organisation, die sich 36 Millionen Dollar aus treuhänderisch gehaltenem Geld nahm, während die Gruppe, die entschied, wofür dieses Geld da war, noch tagte.\nUnd eine Organisation, die eine Klage der Registry, die die zwei größten Zonen des Internets gekapert hatte, dadurch verglich, dass sie dieser Registry einen erneuerten Vertrag für .com in die Hand drückte.\nEine Organisation, deren einziger funktionierender Rechenschaftsmechanismus von einer Billionen-Dollar-Firma genutzt wurde, um den einhelligen Widerspruch von acht Ländern zu kippen, mit Kosten zu Lasten ICANNs.\nEine Organisation, die um einen Ausschussbericht davon entfernt war, .corp und .home an Fremde zu delegieren, und aus den Messungen anderer Leute erfuhr, was das kaputt gemacht hätte.\nDer durchgehende Faden ist nicht Unfähigkeit. Unfähigkeit ist zufällig. Das hier hat eine Richtung: jedes Einzelne davon ging zugunsten der Platzhirsche, des Geldes und ICANNs eigenen institutionellen Interesses aus, und die Beteiligungsmechanismen — Kommentierungsphasen, Arbeitsgruppen, Empowered Communities — produzierten Dokumentation statt Ergebnissen.\nUnd das ist die Stelle, die die Politik für die Datei setzt. Kein Standardisierungsgremium, kein Gericht, nichts, was du gewählt hast. Ein kalifornisches Non-Profit mit einer solchen Governance-Bilanz, sitzend auf 1,5 Megabyte Text, gegen die jedes Netz auf der Erde auflöst.\nDas Einzige, was zwischen dieser Bilanz und der Datei steht, ist, dass ICANN den Stift nicht hält. Sie muss fragen. Alles oben ist, was eine Organisation tut, solange sie noch fragen muss — die Frage, die man also mitnehmen sollte, ist nicht, ob ICANN sich gut benimmt. Das tut sie erkennbar nicht. Sie lautet, was das Fragenmüssen aufrechterhält, wenn niemand es aufgeschrieben hat und die Partei, die gefragt wird, schon auf der Gehaltsliste steht.\n","permalink":"https://blogs.damiendye.uk/de/dns/who-actually-controls-dns/","summary":"Die Root des Internets ist eine 1,5 MB große Textdatei, die eine einzige amerikanische Firma bearbeitet und signiert. Wer DNS wirklich kontrolliert, was die IANA-Übergabe von 2016 geändert hat und was nicht, und was das dokumentierte Protokoll darüber sagt, wie ICANN diese Kontrolle genutzt hat.","title":"Wer DNS wirklich kontrolliert"},{"content":"Ich war von 2017 bis 2019 DNS-Registry-Systemadministrator bei Nominet, der .uk-Registry — im Haus, während sich der Druck aufbaute, aus dem 2021 die Revolte wurde. Die Abstimmung selbst kam nach meiner Zeit, und dieser Teil ist öffentliches Protokoll, wie üblich verlinkt. Wo ich davon rede, wie es von innen aussah, sage ich das.\nDer Begleitbeitrag zu diesem hier handelt von ICANN, und er landet aus verschiedenen Richtungen immer wieder bei derselben Frage: wenn niemand einen Vertrag über eine Registry hält, was bringt sie dann eigentlich dazu, sich zu benehmen?\n.uk ist ein guter Ort, um das zu beantworten, denn dort hält niemand einen. Es gibt kein ICANN-Registry-Agreement darüber, keine Specification 6, keine Compliance-Funktion, kein externes Monitoring und keinen Regulierer im gewöhnlichen Sinn. Ofcom betreibt es nicht. Die Regierung betreibt es nicht.\nSeine Mitglieder tun das. Und im März 2021 haben sie davon Gebrauch gemacht.\nWas Nominet wirklich ist Nominet ist eine company limited by guarantee. Sie hat keine Aktionäre. Sie hat Mitglieder — Registrare und andere Interessierte, die einen Beitrag zahlen und eine Stimme bekommen — und sie wurde gegründet, um .uk zum öffentlichen Nutzen zu betreiben, nicht für Gewinn.\nDiese Struktur ist die ganze Geschichte. Eine Firma ohne Eigentümer, die man reich machen könnte, nimmt trotzdem Geld ein, und eine Registry, die einen nationalen Namensraum ohne Wettbewerber betreibt, nimmt eine Menge davon ein. Wofür dieser Überschuss da ist, ist eine Frage, die die Satzung vage beantwortet und das Board in der Praxis.\nDie Mitglieder sind die einzige Kontrolle. Sonst gibt es nowt. Was in Ordnung ist, solange die Antworten zusammenpassen, und zum ganzen Spiel wird, sobald sie das nicht mehr tun.\nDer Bestand, von innen Hier kommt der Teil, den sich Außenstehende bei einer Registry selten vorstellen, und er ist für alles Weitere wichtig.\nNominet war nie nur .uk. Während meiner Zeit trug die Plattform:\n.uk, die Länderdomain (ccTLD), unter überhaupt keinem ICANN-Vertrag. .cymru und .wales, generische Top-Level-Domains (gTLDs), die Nominet selbst hält — und die stehen unter ICANN-Registry-Agreements. Die gTLDs anderer Leute. Im April 2016 übergab Minds + Machines Nominet das Backend für bis zu 28 seiner Strings — .london, .work, .law, .fashion, .cooking darunter — was Nominet nach Zahl der betriebenen TLDs in die oberste Riege der Registry-Betreiber brachte. Dazu Dot-Brands wie .bbc und .bentley. ICANNs Notfallrolle. Nominet ist einer von ICANNs Emergency Back-end Registry Operators, den Läden, denen ICANN eine gTLD übergibt, wenn sie sie demjenigen wegnimmt, der sie bis dahin betrieben hat. Nominet trat 2014 bei, und im Dezember 2017 hat ICANN das genutzt — Nominet wurde Notfall-Interimsbetreiber von .wed, nachdem der Registrierungsdatendienst des bisherigen Betreibers ausgefallen war. Das Resolver-Ende. Nominet baute und betrieb Protective DNS für das National Cyber Security Centre (NCSC), den rekursiven Resolver, den britische Behörden abfragen und der sich weigert, als bösartig bekannte Namen aufzulösen. Eine Klarstellung lohnt sich, denn „Nominet betreibt .uk„ ist lockerer formuliert, als es sein sollte.\nNominet betreibt die .uk-Registry und das meiste, was darunter sitzt — .co.uk, .org.uk, .me.uk und .uk selbst auf der zweiten Ebene. Es hat nie alles davon betrieben. .ac.uk gehört Jisc, Nachfolger des akademischen Netzes, das uk überhaupt erst benannt hat, und Jisc verwaltet und registriert Namen darunter seit 1996. Durch die Jahre, die dieser Beitrag abdeckt, war .gov.uk ebenfalls Jiscs — Nominet hat es erst 2024 übernommen, und selbst jetzt sitzen die Freigaben beim Central Digital and Data Office und nicht bei der Registry.\nEs geht noch weiter, und zwar in eine Richtung, die man nicht raten würde. Jisc stellt auch die Verwaltung für .gov.scot und für .gov.wales und .llyw.cymru — die beide innerhalb von .wales und .cymru leben, den zwei generischen Top-Level-Domains, die Nominet selbst hält. Nominet betreibt diese TLDs. Jemand anderes betreibt die Ecke der Regierungen darin.\nAlso ist selbst innerhalb des Namensraums eines Landes die Zuständigkeit aufgeteilt, und sie ist durch Geschichte und Gewohnheit aufgeteilt, nicht durch irgendjemandes Entwurf.\nEine Organisation saß also gleichzeitig in vier verschiedenen Verhältnissen zum Namenssystem. Für .uk vollständig außerhalb von ICANNs Reichweite. Für die gTLDs mittendrin, unter Vertrag und laufend gemessen. Das Instrument, zu dem ICANN griff, wenn sie jemand anderem eine Top-Level-Domain wegnehmen musste. Und der Resolver, der entschied, was ein Ministerium nachschlagen durfte.\nNichts davon ist ein Widerspruch. So sieht die Struktur aus, sobald man aufhört, Organigramme zu lesen, und anfängt, Verträge zu lesen. Autorität hängt hier an einzelnen Delegierungen, nicht an Firmen.\nZwei Regime, eine Plattform Jetzt der Teil, den man nur von innen sieht, und er ist der Grund, warum der Bestand wichtig ist und nicht bloß Randnotiz.\nFür die gTLDs unterschreibt Nominet das ICANN-Registry-Agreement wie alle anderen. Specification 6 gilt — keine Wildcards, keine synthetisierten Antworten. Specification 10 auch, und ICANN misst die Einhaltung laufend von außen: DNS-Auflösung, das Shared Registration System, der Whois-Dienst, Escrow-Hinterlegungen und korrekt signierte Zonen werden alle gegen Schwellenwerte überwacht, und durch einen davon zu fallen ist ein Compliance-Ereignis und nicht bloß ein Ausfall.\nZähl die Zonen. Auf der einen Seite .uk, ohne Vertrag. Auf der anderen mehrere Dutzend gTLDs, jede unter einem Registry-Agreement und einer Monitoring-Sonde. Die vertragslose Zone war auf ihrer eigenen Plattform etwa dreißig zu eins in der Unterzahl.\nZwei Vertragsregime auf einer Plattform, und das strenge gewinnt Eine Plattform, zwei Vertragsregime Nominet — eine Registry-Plattform, ein Satz Runbooks .uk 1 Zone kein Registry-Agreement keine Specification 6 keine Überwachung generische Top-Level-Domains ≈30 Zonen .cymru\u0026#160;· .wales\u0026#160;· MMX\u0026#160;×28\u0026#160;· .bbc\u0026#160;· .bentley ICANN-Registry-Agreement Spec 6, Spec 10, von außen überwacht das strenge Regime wird zum Hausstandard Niemand pflegt zwei Betriebsstandards, um eine Ausnahme für eine Zone zu bewahren. .uk bekommt ICANNs Regeln trotzdem\u0026#160;— kein Vertrag, keine Konsultation, niemand im UK gefragt. Eine Plattform, die beide Regime trägt. Die vertragslose Zone ist rund dreißig zu eins in der Unterzahl, also werden die für die gTLDs geschriebenen Regeln zur Art, wie alles betrieben wird — einschließlich der Zone, über die niemand irgendeine Autorität hat. Zwei Betriebsregime auf einer Plattform zu fahren ist schmerzhaft, also tut man es nicht. Zwei Escrow-Prozesse, zwei Monitoring-Regime, zwei Sätze Runbooks, zwei Rufbereitschaftsverfahren, zwei Antworten auf dieselbe Frage je nachdem, um welche Zone das Ticket zufällig geht — so entstehen Fehler um drei Uhr morgens. Wenn ICANN etwas für die gTLDs vorschreibt, baut man es nicht zweimal. Man baut es einmal und fährt alles darauf.\nWas heißt, dass ICANNs Anforderungen auch auf .uk landeten. Nicht weil ICANN irgendeine Autorität über .uk gehabt hätte — sie hatte keine — sondern weil der billigste sichere Weg, eine Regel zu erfüllen, die den größten Teil deines Bestands bindet, darin besteht, sie auf den ganzen anzuwenden, und weil eine Trennung absichtlich aufrechtzuerhalten, damit die ccTLD Dinge tun darf, die den gTLDs verboten sind, dir nichts einbringt außer einem zweiten Weg, auf dem die Plattform kaputtgehen kann.\nDafür wurde kein Vertrag unterschrieben. Es gab keine Konsultation. Niemand im Vereinigten Königreich wurde gefragt. Eine in Los Angeles für generische Top-Level-Domains geschriebene Anforderung prägte, wie die eigene Registry des Landes lief, auf dem Umweg über eine Bauentscheidung.\nFürs Protokoll: das machte ICANN auch zu einer realen Größe im Rufbereitschaftsplan statt zu einer Zeile in einem Positionspapier. Für einen Teil des Bestands war sie eine Gegenpartei mit einem Vertrag, einer auf unsere Infrastruktur gerichteten Sonde und einem Eskalationsweg.\n.uk verkaufen, um den Rest zu bezahlen Die kommerzielle Logik des Ganzen war das, wogegen die Mitglieder am Ende protestierten.\n.uk ist ein Monopol. Es gibt genau einen Ort, an dem man eine .uk-Domain kauft, die Nachfrage ist nahezu unelastisch, und die Marge finanziert, was immer das Board zu finanzieren beschließt. Ab 2016 führte The Register laut das Argument, dass .uk-Registranten überteuert abkassiert würden, um den Rest des Betriebs zu subventionieren.\nUnter dem 2015 berufenen CEO Russell Haworth drängte Nominet hart in die Cybersicherheit — der NCSC-Vertrag unter anderem — mit der Begründung, eine Registry, die auf nationaler DNS-Infrastruktur sitzt, sei gut aufgestellt, um Sicherheitsdienste zu verkaufen.\nDas war die Marschrichtung während meiner gesamten Zeit dort. Die Revolte kam 2021 nicht aus dem Nichts. Die Bedingungen dafür wurden Jahre früher gelegt, für jeden im Haus sichtbar.\nDie Wohltätigkeit ging zuerst Im Januar 2018, während ich dort war, zog sich Nominet aus seiner eigenen Wohltätigkeitsstiftung zurück.\nDer Nominet Trust war seit 2008 von der Registry finanziert worden — 44 Millionen Pfund in dieser Zeit, 4 Millionen 2016, 5,4 Millionen 2017. Er gab Geld an Technologie-für-den-guten-Zweck-Projekte. Er war, in einem ziemlich direkten Sinn, der öffentliche Nutzen in einer Public-Benefit-Gesellschaft. Er wurde unabhängig und wurde im Mai 2018 zum Social Tech Trust.\nHaworths erklärter Grund war, dass “the grant-giving, single funder model we set up in 2008 was not the most effective route to greatest impact.“ — das Fördermodell mit einem einzigen Geldgeber sei nicht der wirksamste Weg zur größten Wirkung.\nWas daneben angekündigt wurde, war ein Cyber Advisory Panel — unter Haworths Vorsitz — mit Zielrichtung Regierung und Großunternehmen, gestützt auf ein Marketingprogramm und, in Nominets eigenen Worten, möglicherweise eine Übernahme.\nStell die beiden nebeneinander, denn sie wurden zusammen angekündigt. Das Geld, das für eine unabhängige Wohltätigkeit das Haus verließ, hörte auf zu fließen. Ein kommerzielles Vorhaben unter dem Vorsitz des Vorstandsvorsitzenden fing an. Die Mitglieder wurden zu keinem von beidem befragt.\nEiner von ihnen, Andrew Bennett, stellte damals die naheliegende Frage: where are all future operating profits going to be spent? — wofür werden künftig eigentlich alle Betriebsgewinne ausgegeben?\nDrei Jahre später hat die Mitgliedschaft sie beantwortet.\nDeshalb sind die Absätze unten auch nicht bloß mein Eindruck. Die größte einzelne Bewegung von Public-Benefit-Geld in Nominets Geschichte ging von einer unabhängigen Stiftung mit eigener Governance an ein Gremium, dem der Vorstandsvorsitzende vorsaß, in einer Ankündigung, ohne die Eigentümer zu fragen. Was immer du von der Absicht hältst, die Richtung des Geldes steht im Protokoll.\n„Profit With a Purpose„ Das war die Formel. Sie war die Linie für die gesamte Strategie, und wir hörten sie sehr oft.\nDas Problem daran war nicht, dass sie ehrgeizig war. Es war, dass die beiden Hälften auseinandergefallen waren. Der Profit war real, wuchs und kam aus einem gefangenen Markt, der nirgendwo sonst ein .uk kaufen konnte. Der Zweck war eine Folie in einem Deck.\nProfit hoch, Zweck zurückgezogen — die zwei Hälften des Slogans driften auseinander „Profit with a purpose“, in den Zahlen Zweck — Zuwendungen an den Nominet Trust 4,0 Mio. £ 2016 5,4 Mio. £ 2017 zurückgezogen, Januar 2018 Trust losgelöst, sucht eigene Geldgeber ab 2018 44 Mio. £ insgesamt gegeben zwischen 2008 und 2018 — dann nichts. In denselben Jahren stieg der Preis einer .uk-Domain um über 50 %. Die Profit-Hälfte des Slogans funktionierte genau wie vorgesehen. Die zwei Hälften des Slogans, die sich in entgegengesetzte Richtungen bewegen. Die Spendenzahlen aus der Förderhistorie des Nominet Trust; die Preiserhöhung ist die Beschwerde der Mitglieder selbst von 2021. Man kann eine Firma an so einem Slogan festhalten, und irgendwann taten die Mitglieder genau das. Von innen erzeugte er vor allem jene besondere Müdigkeit, die davon kommt, bei jeder Betriebsversammlung zu hören, der kommerzielle Vorstoß sei der öffentliche Nutzen, während die tatsächliche Public-Benefit-Zeile nach unten geht.\nWohin das Geld ging Drei Dinge liefen, während ich dort war, und keines davon ist DNS für das Vereinigte Königreich.\nEin Funkfrequenzregister. Nominet baute eine TV-White-Space-Datenbank — ein Verzeichnis dessen, welche Funkfrequenzen an einem bestimmten Ort zu einer bestimmten Zeit frei nutzbar sind — und ließ sich von der FCC zulassen als Datenbankverwalter in den Vereinigten Staaten. Das Argument war, eine Registry sei eine Registry, und eine Firma, die in einer Art Nachschlagen gut ist, könne eine andere verkaufen.\nEin DNS-Sicherheitsprodukt. NTX, Bedrohungserkennung auf Basis der Untersuchung von DNS-Verkehr, verkauft an Regierungen und Großunternehmen. Mit anderen Worten ein Konkurrent zu OpenDNS, also ein Konkurrent zu Cisco, betreten von einer britischen Domain-Registry.\nFahrerlose Autos. Zusammen mit Drohnen und dem Internet der Dinge hochgehalten als die nächste große Welle von Dingen, die benannt und registriert werden müssten.\nWas aus ihnen wurde, ist die Antwort darauf, ob sie eine Strategie waren. Das Frequenzgeschäft wurde an RED Technologies verkauft, als Nominet sich neu ausrichtete. Die Cyber-Arbeit brachte die Technik hinter dem NCSC-Vertrag hervor, den Nominet dann 2024 verlor. Die fahrerlosen Autos kamen nie und die Domains, die sie gebraucht hätten, auch nicht.\nDas Gebot für Australien Es gab ein viertes, und es sagt am meisten über den Ehrgeiz. 2018 bot Nominet darauf, Australiens Registry zu betreiben.\nauDA, die .au verwaltet, hatte den Registry-Betrieb ausgeschrieben. Neun Gebote kamen aus aller Welt, drei kamen in die engere Wahl, und Afilias übernahm am 1. Juli 2018 und beendete damit sechzehn Jahre, in denen AusRegistry es betrieben hatte. auDA hat nie veröffentlicht, wer sonst geboten hat, du wirst das also nicht im Protokoll finden — aber Nominet war dabei, und ich war da, während wir darauf losgingen.\nHalt das gegen die anderen Nachrichten desselben Jahres. Im Januar 2018 zog sich Nominet aus der Wohltätigkeitsstiftung zurück, der es 44 Millionen Pfund gegeben hatte, mit der Begründung, Fördervergabe durch einen einzigen Geldgeber sei nicht der wirksamste Weg zur Wirkung. In denselben zwölf Monaten bot es darauf, die Domain-Registry eines Landes auf der anderen Seite der Welt zu betreiben.\nEs lohnt sich auch zu bemerken, was die .au-Ausschreibung ist, denn sie ist genau das, was die meisten Leute für .uk annehmen. auDA kann seine Registry im Wettbewerb ausschreiben und jemand anderem übergeben, und 2018 hat sie das getan. Für .uk gibt es kein Äquivalent. Nominets Position ist kein Vertrag, der zur Verlängerung ansteht — was eine stärkere Position ist, als Afilias sie in Australien gewonnen hat, und als solche ist sie es wert, im Kopf behalten zu werden, wenn man abwägt, wie viel Druck die Abstimmung der Mitglieder tatsächlich darstellte. Sie war der einzige Hebel, den es gab.\nUnd hier ist, was mit auDA geschah, während Nominet darauf bot, für sie zu arbeiten.\nParallel zur Ausschreibung führte die australische Regierung eine Überprüfung von auDA selbst durch. Im April 2018 berichtete sie, dass auDAs Management- und Governance-Rahmen “no longer fit-for-purpose„ sei — nicht länger zweckmäßig —, erließ 29 verpflichtende Reformen als neue Bedingungen der Anerkennung und setzte einen leitenden Beamten des Kommunikationsministeriums in auDAs Board, um die Arbeit zu beaufsichtigen. Sie sagte auch klipp und klar, sie werde die Delegierung für .au an einen anderen Anbieter überführen, wenn auDA nicht liefere.\nDas ist eine nationale Regierung, die schriftlich erklärt, sie werde die Domain ihres Landes verlegen, wenn die Stelle, die sie hält, sich nicht zusammenreißt. auDAs eigene Mitglieder meuterten zur selben Zeit — eine Petition für eine außerordentliche Mitgliederversammlung zur Abberufung von vier Führungskräften, drei Jahre bevor Nominets Mitglieder dasselbe mit fünf der ihren taten.\nZwei nationale Registries, zwei Non-Profits, die den Namensraum eines Landes halten, beide innerhalb von vier Jahren des Governance-Versagens bezichtigt. Das ist keine Nominet-Eigenart. Das ist es, was diese Struktur tut, wenn niemand genau genug hinschaut.\nWas die Mitglieder sahen Was das Warum dieser und nicht anderer angeht — da bin ich vorsichtig, denn ich kann dir sagen, wie es aussah, und nicht, was in irgendjemandes Kopf war. Die unter Mitarbeitern damals weit verbreitete Ansicht war, dass die Förderung den Vorlieben derjenigen folgte, die sie genehmigten. Ich kann dir kein Kontobuch zeigen, und ich werde nicht so tun, als könnte ich das.\nWorauf ich zeigen kann, ist, dass die formelle Beschwerde der Mitgliedschaft drei Jahre später eine besser belegte Fassung desselben Verdachts war — dass eine Körperschaft ohne Aktionäre und mit einem Public-Benefit-Zweck den Überschuss aus einem nationalen Monopol für Dinge ausgab, die den Leuten passten, die sie führten, und dass die Spenden, die das ganze Arrangement rechtfertigen sollten, währenddessen gekürzt worden waren.\nWohin der .uk-Überschuss ging, und wie jedes davon endete Wohin der Überschuss ging .uk ein Anbieter, kein Rivale Preise +50 % Nominet Trust 44 Mio. £ Zuwendungen, 2008 bis 2018 gestoppt, Jan. 2018 TV-White-Space-Frequenzdatenbank FCC-zugelassen in den USA verkauft NTX Cybersicherheit 12,6 Mio. £ Umsatz im letzten vollen Jahr 2,4 Mio. £ Verlust Gebot für Australiens Registry neun Bieter, drei in der Endauswahl an Afilias verloren Fahrerlose Autos, Drohnen, Internet der Dinge die nächste große Welle von Dingen mit Namensbedarf kamen nie Die eine Zeile, die tat, wofür es die Firma gab, ist die, die gestrichen wurde. Alles darunter bezahlten die Leute, die .uk-Domains kauften. Fünf Ziele für das Geld aus einem Monopol. Vier davon endeten in einem Verkauf, einem Verlust, einem verlorenen Gebot oder gar nichts — und das fünfte, das, wofür die Satzung überhaupt da war, war das, was gestoppt wurde. Die Beschwerde der Mitglieder war nicht, dass Diversifizierung falsch sei. Sie war Arithmetik. Die .uk-Preise stiegen um mehr als 50 Prozent. Wohltätige und gemeinnützige Zuwendungen fielen, während die Organisation Monopolmargen auf einem nationalen Gut machte. Die operative Leistung ging trotz Kostensenkungen zurück. Die Vergütung und die Boni der Geschäftsleitung stiegen die ganze Zeit über. Und Rückmeldungen der Mitglieder, gegeben über die von der Satzung vorgesehenen Kanäle, verliefen jahrelang im Sand.\nEine Firma ohne Aktionäre hatte angefangen, sich wie eine mit ungeduldigen Aktionären zu benehmen, und der Überschuss aus dem nationalen Namensraum bezahlte dafür.\nDie Mitglieder revoltieren Die Kampagne war PublicBenefit.uk, organisiert von Simon Blackler von der Hosting-Firma Krystal. Ihr Antrag war unverblümt: benannte Direktoren abberufen.\nNominets Reaktion ist der Teil, der festgehalten gehört, denn er sagt dir, was aus der Organisation geworden war.\nSie führte mit dem Geld der Mitglieder Kampagne gegen ihre eigenen Mitglieder — E-Mails, Anrufe und Postsendungen, die zur Ablehnung aufriefen. Sie weigerte sich, sich mit der Substanz der Kampagne zu befassen. Als die Kampagne ihr Recht auf die Kontaktdaten der Mitglieder wahrnahm, um ihren Fall vorzutragen, schickte Nominet keine Tabelle. Sie schickte ein physisches Paket mit den Daten, ausgedruckt auf mehr als 500 Blatt Papier, die E-Mail-Adressen weggelassen.\nSie blockierte außerdem einen zweiten Antrag, der zwei qualifizierte Übergangsdirektoren eingesetzt hätte, mit dem Argument, das sei nicht rechtmäßig — und kritisierte dann die Kampagne dafür, keinen Nachfolgeplan zu haben.\nAm 22. März 2021 kam es zur Abstimmung. Die Beteiligung lag bei 53 %. Der Antrag ging mit 52,7 % durch, und fünf der elf Board-Mitglieder gingen:\nMark Wood Vorsitzender Russell Haworth Chief Executive Eleanor Bradley Managing Director, Registry Ben Hill Chief Financial Officer Jane Tozer Non-executive Director Haworth trat Stunden vor der Abstimmung zurück, statt sie zu verlieren. Rob Binns wurde kommissarischer Vorsitzender.\nHier ist, was diese beiden meiner Ansicht nach ausmachten, und ich kennzeichne es als Meinung, weil es genau das ist.\nWood und Haworth führten Nominet so, wie eine Private-Equity-Gesellschaft ein Portfoliounternehmen führt. Nicht als Registry, die zufällig einen Überschuss erzeugt, sondern als Bilanz mit einem unterausgelasteten Gut daran geschraubt — ein gefangenes Monopol, das Bargeld abwirft, das man anderswo mit mehr Aufwärtspotenzial besser einsetzen könnte.\nJedes dokumentierte Ding oben passt dazu. Du nimmst das verlässliche Einkommen und erhöhst seinen Preis, weil die Kunden nirgendwo sonst hingehen können. Du stoppst den Abfluss, der keine Rendite bringt, und das ist die Wohltätigkeit. Du steckst die Differenz in ein Portfolio — Frequenzen, Cyber, eine ausländische Registry, fahrerlose Autos — in der Annahme, dass eines davon aufgeht. Du bezahlst die Leute, die das steuern, zu dem Satz, den diese Art Arbeit verlangt. Und du machst weiter, bis dich jemand mit dem nötigen Standing stoppt.\nEs ist nichts Ungewöhnliches daran, eine Firma so zu führen. Es ist keine Art, eine Public-Benefit-Körperschaft zu führen, die ein nationales Gut treuhänderisch hält, denn dieser Überschuss war nie Kapital auf der Suche nach einer Rendite. Er war das, was das ganze Arrangement erzeugen sollte, und die Satzung sagte das auch.\nDie Mitglieder haben am Ende dasselbe gesagt, in der einzigen Sprache, die ihnen zur Verfügung stand.\nEs lohnt sich, ehrlich über die Mehrheit zu sein. 52,7 % bei 53 % Beteiligung ist kein Erdrutsch, es ist ein knapper Sieg in einer gespaltenen Mitgliedschaft, und die Organisation kämpfte mit allem dagegen, was sie hatte. Sie verlor trotzdem.\nWas danach geschah Nominet zog sich aus der kommerziellen Cyber-Richtung zurück und wandte sich der Registry und der Public-Benefit-Arbeit zu. Dann kamen die Zahlen.\nDas Kerngeschäft erreichte seinen Höhepunkt in dem Jahr, in dem ich ging. Die verwalteten .uk-Domains erreichten mit 13.348.378 im Jahr 2019 ihren Höchststand. Bis Januar 2023 waren es 11.045.559. Bis Januar 2024 10.688.932. Ein Fünftel des Bestands, weg, und weiter fallend.\nDie Diversifizierung machte Verlust. In ihrem letzten vollen Jahr vor der Abrechnung setzte die Cyber-Sparte 12,6 Millionen Pfund um und wies einen Verlust von 2,4 Millionen Pfund aus. Das ist die Antwort auf die Frage, ob die vom Überschuss bezahlten Projekte eine Investition oder eine Liebhaberei waren, und es ist Nominets eigene Zahl.\nDann ging der Vertrag. 2024 schrieb das NCSC Protective DNS neu aus — ein Dienst, der rund eine halbe Billion Anfragen pro Jahr abwickelt — und Nominet verlor ihn. Die Arbeit ging ab September 2024 an Cloudflare mit Accenture, zu einem Abschluss, der mit etwa 30 Millionen Pfund berichtet wurde. Chief Executive Paul Fletcher sagte, die Regierung habe einen billigeren Wettbewerber gewählt.\nUnd das Backend-Buch fluktuiert. Im April 2021, Wochen nach der außerordentlichen Mitgliederversammlung, verkaufte MMX sein Portfolio für 120 Millionen Dollar an GoDaddy Registry — und die 28 Strings, die Nominet in die oberste Riege der Registry-Betreiber gebracht hatten, gingen mit dem Käufer. .blog war schon 2019 zu CentralNic abgewandert.\nFairerweise muss man sagen, dass das in beide Richtungen läuft. Amazon zog 2019 den Großteil seiner 54 gTLDs auf Nominets Plattform, und Microsoft verlagerte später .skype und .office von GoDaddy herüber. Nominet gewinnt Portfolios ebenso, wie es welche verliert.\nAber das ist der Punkt über das Geschäft, keine Verteidigung davon. Backend-Registry-Dienste sind Umsatz, den du nicht kontrollierst. Er kommt und geht mit der Firmentransaktion von jemand anderem — MMX ging nicht, weil Nominet die Plattform schlecht betrieb, es ging, weil MMX verkauft wurde. Die Finanzen einer Public-Benefit-Körperschaft auf ein Geschäftsbuch zu bauen, das an einem Dienstag hinausspazieren kann, weil sein Eigentümer 120 Millionen Dollar genommen hat, ist eine strategische Entscheidung, und sie wurde getroffen.\nUnd im selben Jahr gewann es .gov.uk.\n.gov.uk war jahrelang von Jisc betrieben worden, pro bono, unter einer alten Absichtserklärung — ein Arrangement, von dem die Regierung schließlich befand, es erfülle keine international anerkannten Standards. Das Central Digital and Data Office führte eine Beschaffung über den Crown Commercial Service durch, Nominet gewann sie im November 2023, und der Übergang wurde am 26. Juni 2024 abgeschlossen, eine Woche vor der Parlamentswahl terminiert, um die Wählerregistrierung aus der Schusslinie zu halten. Jiscs eigene Registry-Seite hält das Datum jetzt nüchtern fest — seit dem 26. Juni 2024 verwaltet sie den .gov.uk-Namensraum nicht mehr, blieb aber für einige Kunden als Registrar. Achtundzwanzig Jahre Betrieb eines nationalen Namensraums, endend in einer Zeile auf einer Webseite.\nDie genannten Anforderungen waren Ausfallsicherheit, Konformität mit ICANNs DNS-Standards und die Erfüllung des Cyber Assessment Framework des NCSC.\nLies das gegen das Argument weiter oben in diesem Beitrag. Der Grund, warum Nominet ein glaubwürdiger Bieter für den eigenen Namensraum der Regierung war, ist, dass es bereits nach ICANNs Standards lief — Standards, die es übernommen hatte, weil der größte Teil seines Bestands vertraglich daran gebunden war, und die .uk erreichten, weil niemand zwei Regime auf einer Plattform pflegt. Die Disziplin, die seitwärts hereinkam, über die gTLD-Verträge, ist das, was es für den Betrieb von .gov.uk qualifizierte.\n2024 war also nicht einfach ein schlechtes Jahr. Es verlor den größten Vertrag, den es hatte, und gewann den mit dem Namen der Regierung darauf.\nZwei Dinge an diesem Gewinn sind bemerkenswert, denn sie sind der Unterschied zwischen einen Namensraum betreiben und ihn halten.\nDie Regierung behielt die Autorität. Nominet betreibt die Registry. Das Central Digital and Data Office verwaltet und genehmigt weiterhin die Anträge — wer ein .gov.uk haben darf, bleibt eine Regierungsentscheidung, nicht die der Registry. So funktioniert .co.uk nicht, wo akkreditierte Registrare an jeden verkaufen, der auftaucht. Der technische Betrieb wurde ausgelagert. Das Sagen über den Namensraum nicht.\nUnd es ist ein Vertrag. .gov.uk wurde über den Crown Commercial Service beschafft, was heißt, dass es eine Laufzeit und ein Enddatum hat, und die Regierung hat genau einmal vorgeführt, was sie tut, wenn sie befindet, das Arrangement sei nicht gut genug: sie hat das Ganze nach gut zwanzig Jahren von Jisc weggeholt.\nNominet hält .gov.uk also zu Bedingungen, zu denen es .uk nicht hält. Das eine kann am Ende eines Vertrags von einem Beamten zurückgenommen werden, der sich gegen eine Verlängerung entscheidet. Das andere hat keinen Vertrag, keine Laufzeit und keine Verlängerung — und die Einzigen, denen es je gelungen ist, es zu disziplinieren, mussten dafür eine Mitgliederabstimmung organisieren.\nIm März 2024, mit verlorenem PDNS und schrumpfendem .uk, kündigte Fletcher eine Umstrukturierung mit bis zu 70 gefährdeten Stellen an.\nUnd dann der Satz, der den Kreis schließt. Fletcher merkte an, die Domain-Preise “cannot be held at the level set in January 2020 indefinitely.„ — könnten nicht unbegrenzt auf dem im Januar 2020 gesetzten Niveau gehalten werden.\n.uk-Preiserhöhungen gehörten zu den Dingen, wegen derer die Mitglieder revoltierten. Fünf Jahre später, mit verlustreich abgewickelter Diversifizierung, dem an einen billigeren Bieter verlorenen Flaggschiff-Vertrag und fallenden Registrierungen, ist die vorbereitete Antwort, den Preis von .uk wieder zu erhöhen.\nUnd der Blick von innen hat sich nicht erholt Die Mitglieder bekamen ihren Board-Wechsel. Ob sie die Organisation zurückbekamen, ist eine andere Frage.\nStand 25. August 2026 steht Nominets Glassdoor-Bewertung bei 2,9 von 5 über 97 Bewertungen, mit 31 %, die es weiterempfehlen würden, 22 % positiv zu den Geschäftsaussichten und 29 % Zustimmung zum Vorstandsvorsitzenden. Die am schlechtesten bewertete Kategorie ist das obere Management, mit 2,3. Die Bewertenden schätzen ihre Kolleginnen und Kollegen und die Arbeit hoch ein. Was sie nicht hoch einschätzen, ist die Ebene über ihnen.\nDas ist eine mittelmäßige Bewertung, keine vernichtende, und sie sollte als das gelesen werden, was sie ist: eine selbstselektierende Stichprobe auf einer öffentlichen Seite. Aber die Form der Beschwerde ist erkennbar die, die die Mitglieder 2021 vorbrachten — eine Strategie, die niemand erklären kann, Belohnung, die nach oben fließt, und die Leute, die die nationale Registry betreiben, werden nicht gefragt.\nAnderer Vorstandsvorsitzender. Dieselbe Beschwerde.\nWas das darüber sagt, wer eine ccTLD regiert Komm zurück zur Frage ganz oben.\nICANN hätte nichts davon tun können. Sie hatte keinen Vertrag über .uk, kein Standing und keinen Mechanismus außer einen Brief zu schreiben. Alles im ICANN-Beitrag über Specification 6, Compliance und Monitoring galt für Nominets gTLDs und nicht für die Zone, auf die es dem Land tatsächlich ankommt.\nDie britische Regierung tat es auch nicht, und es lohnt sich, klar zu sagen warum, denn die verbreitete Annahme ist falsch. .uk wird nicht per Regierungsvertrag vergeben. Es gibt keine Ausschreibung, kein Verlängerungsdatum und keinen Wettbewerber, der darauf wartet, dafür zu bieten. Nominet hält die Delegierung von der IANA, so wie jede andere Länderregistry ihre hält, und niemand vergibt die alle paar Jahre neu.\nWas die Regierung hat, ist eine Reservebefugnis, und fast niemand weiß, dass es sie gibt.\nDie Abschnitte 19 bis 21 des Digital Economy Act 2010 erlauben es dem zuständigen Minister, einzugreifen, wenn es bei einer qualifizierenden Internet-Domain-Registry ein “serious relevant failure„ gibt — ein schwerwiegendes einschlägiges Versagen, das die Verfügbarkeit oder das Ansehen der britischen Kommunikation oder die Interessen der Verbraucher oder der Öffentlichkeit beeinträchtigt. Nominet ist diese Registry. Nach Ankündigung und Gelegenheit zur Stellungnahme kann der Minister einen Verwalter über die Registry einsetzen oder bei Gericht beantragen, ihre Satzung zu ändern.\nDas ist erheblich mehr, als ICANN je über irgendeine ccTLD hatte. Und hier ist der Teil, bei dem es sich zu verweilen lohnt: diese beiden Abschnitte lagen vierzehn Jahre lang brach und wurden am 6. April 2024 in Kraft gesetzt — im selben Jahr, in dem Nominet den NCSC-Vertrag verlor und 70 Entlassungen ankündigte.\nIch werde nicht behaupten, dass diese Tatsachen zusammenhängen, denn ich weiß nicht, dass sie es tun. Im Protokoll steht, dass die Befugnis, einen Verwalter in die .uk-Registry zu setzen, 2024 scharf wurde und es die vierzehn Jahre davor nicht war.\nUnd das ist nur der inländische Weg. Es gibt einen zweiten, und er ist der Grund, warum kein ccTLD-Betreiber irgendwo seine Delegierung von Rechts wegen hält.\nEine Länderdelegierung kann verlegt werden. Die IANA delegiert ccTLDs neu, nach RFC 1591, ICP-1 und den GAC-Prinzipien, und sie hat das wiederholt getan — .kz, .iq, .za, .gd, .gw und andere. Die GAC-Prinzipien halten fest, dass jede Regierung innerhalb ihres eigenen Hoheitsgebiets die letztliche Verantwortung für nationale Politik trägt, und in der Praxis behandelt die IANA die Auffassung der anerkannten Regierung als wesentliche Erwägung bei jeder Übertragung der Domain ihres Landes.\nAustralien hat das, wie oben, 2018 schriftlich gegeben — reformieren oder die Delegierung wandert.\nEine britische Regierung, die entschiede, .uk müsse woanders hin, wäre also nicht blockiert. Es ginge nicht sofort, es ist keine Befugnis, die man per Ankündigung ausübt, und die lokale Internet-Community würde konsultiert. Aber die Maschinerie existiert, die Präzedenzfälle existieren, und die Meinung der Regierung ist der schwerste einzelne Faktor darin.\nWas .uk in eine Lage bringt, die man klar aussprechen sollte. Kommunikation ist einer der kritischen nationalen Infrastruktursektoren des Vereinigten Königreichs, und der Staat behandelt DNS entsprechend — das NCSC kauft seit Jahren Protective DNS für den öffentlichen Sektor ein. Eine Registry, die kritische nationale Infrastruktur betreibt, deren Regierung im Inland einen Verwalter über sie einsetzen kann und deren Wort bei einer internationalen Neudelegierung den Ausschlag gäbe, hält ihre Delegierung nicht als Eigentum. Sie hält sie auf Duldung, und die Duldung ist daran geknüpft, niemanden in Verlegenheit zu bringen.\nDiszipliniert hat sie eine Mitgliederabstimmung, knapp, sechs Jahre nach Beginn des Problems, nach einer Kampagne einer einzelnen Hosting-Firma, der man die Daten ihrer eigenen Mitglieder auf 500 Blatt Papier aushändigen musste, damit sie ihren Fall vortragen konnte.\nDas ist ein besserer Rechenschaftsmechanismus als alles, was ICANN hat. Er entfernte den Vorstandsvorsitzenden und den Aufsichtsratsvorsitzenden einer nationalen Registry, was kein ICANN-Verfahren je bei irgendwem geschafft hat. Er ist auch langsam, konfrontativ, davon abhängig, dass jemand beschließt, ein Jahr seines Lebens darauf zu verwenden, und er kam ein paar Prozentpunkte davor, zu scheitern.\nWas ungefähr dem entspricht, wo DNS-Governance überall steht. Die Mechanismen, die funktionieren, sind die, die jemand mit Mitteln zu bedienen beschließt. .cm hat jahrelang eine ganze Top-Level-Domain gewildcardet, weil niemand mit Standing Einspruch erhob. Freenom hörte erst auf, als Meta klagte. .uk änderte den Kurs, weil eine Hosting-Firma eine Abstimmung organisierte.\nNichts davon ist Governance in dem Sinn, den das Wort nahelegt. Es ist, wer zufällig aufgetaucht ist.\nEin freier Gedanke zum Schluss Alles oben ist entweder belegt oder als meine eigene Erfahrung gekennzeichnet. Dieser letzte Teil ist weder noch. Es ist, was ich denke, und es steht dir frei, anderer Meinung zu sein.\nIch fing 2017 bei Nominet an, das ist neun Jahre her. Russell Haworth übernahm 2015, das ist elf. Das ist lang genug, dass eine Organisation etwas gelernt haben könnte.\nHat sie?\nAuf dem Papier ja. Das abgewählte Board ist weg. Die kommerziellen Cyber-Ambitionen sind abgewickelt. Der wohltätige Arm wurde unabhängig und läuft unter eigenem Namen weiter. Die Mitglieder benutzten den einen Mechanismus, den sie hatten, und er funktionierte.\nDann schau, was tatsächlich vor dir liegt. .uk ist ein Fünftel kleiner als 2019 und schrumpft weiter. Der Vertrag, den die Diversifizierung schließlich hervorbrachte, ist an einen billigeren Bieter gegangen. Siebzig Stellen gingen mit. Der Vorstandsvorsitzende bereitet darauf vor, dass die .uk-Preise nicht unbegrenzt auf dem Niveau von 2020 gehalten werden können — was derselbe Hebel ist, der den Ärger überhaupt erst mit ausgelöst hat. Und die Belegschaft bewertet das obere Management mit 2,3 von 5, bei 29 % Zustimmung zum Vorstandsvorsitzenden. Ein anderer Vorstandsvorsitzender, und erkennbar dieselbe Beschwerde.\nMeine ehrliche Antwort ist also, dass die Leute ausgetauscht wurden und ich nicht überzeugt bin, dass die Organisation es wurde.\nEs ist bemerkenswert, wohin Haworth danach ging, denn es ist keine Kritik, und genau deshalb ist es wichtig. Vor Nominet hatte er vierzehn Jahre bei Thomson Reuters verbracht, in Finanzdaten. Danach ging er zu NBS, dann Byggfakta, dann Acclaro — Abo-Geschäfte mit professionellen Kunden, wiederkehrenden Erlösen und Preissetzungsmacht. NBS setzte 2023 45 Millionen Pfund bei 23,6 Millionen Pfund EBITDA um. Das sind gute Zahlen, und sie zu erreichen ist, wofür ein kommerzieller Vorstandsvorsitzender da ist.\nWas ziemlich genau der Punkt ist, und du musst mir die Charakterisierung nicht abnehmen. Sein eigenes berufliches Profil beschreibt ihn als Vorstandsvorsitzenden für Private-Equity-finanzierte B2B-Unternehmen. Das ist der Job, den er macht, er sagt es selbst, und er ist offensichtlich gut darin.\nEr ist ein kommerzieller Operator und er hat kommerzielle Dinge getan. Der Fehler war nie sein Naturell — es war, dieses Naturell an die Spitze einer Organisation zu setzen, deren Überschuss kein Kapital war und nie eines sein sollte, und dann sechs Jahre lang niemanden in die Lage zu versetzen, das zu prüfen.\nWobei NBS einen zweiten Blick wert ist, denn die Form davon ist vertraut.\nNBS verkauft Chorus, das Ausschreibungswerkzeug, in dem die meisten britischen Architekturbüros arbeiten. Es ist in Revit und ISO-19650-Abläufe verdrahtet, und es gibt keine ernsthafte Alternative — Architekten beschreiben es als unverzichtbares Werkzeug, für das sie schlicht weiterzahlen müssen. Die Lizenz eines Praktikers stieg von 1.385 Pfund im Jahr 2015 auf 7.350 Pfund, was das Architects\u0026rsquo; Journal als 400 % Anstieg über ein Jahrzehnt berichtete. Es gibt keinen Tarif für kleine Büros, ein Einzelpraktiker zahlt also pro Platz dasselbe wie ein 200-Personen-Büro. Die Worte in der Fachpresse sind “rip-off increases„ und “well above inflation“ — Abzocke-Erhöhungen und weit über der Inflation —, daneben die Beobachtung, dass es kaum eine Alternative zum Zahlen gibt.\nSei vorsichtig mit der Zuschreibung, denn die Daten passen nicht so zusammen, wie du es vielleicht gerne hättest. Chorus startete 2018. RIBA verkaufte NBS zwischen 2018 und 2020 für rund 172 Millionen Pfund, und ein früherer RIBA-Präsident hat gesagt, es hätte die Kontrolle nie abgeben dürfen — ein Satz mit einem gewissen Echo. Haworth führte das Geschäft von Oktober 2021 bis Oktober 2024. Die schärfsten berichteten Erhöhungen, und die lautesten Beschwerden, stammen aus 2024 und 2025, nachdem er gegangen war, und der Vorstandsvorsitzende, der sie heute öffentlich verteidigt, ist jemand anderes.\nDas ist also kein Beweis über einen Mann. Es ist ein Beweis über eine Form.\nEin Berufsverband verkauft das Werkzeug, ohne das seine Mitglieder nicht arbeiten können. Der Käufer entdeckt, dass die Kunden nicht gehen können. Der Preis steigt Jahr für Jahr weit über die Inflation, und die Beschwerden verlaufen im Sand, weil es nirgendwo hingeht. Das ist .uk, und es ist das, was .org beinahe geworden wäre, als ICANN die Preisobergrenzen vier Monate vor dem 1,135-Milliarden-Dollar-Gebot eines Private-Equity-Vehikels aufhob.\nWas die eigentliche Lehre ist, und sie ist für niemanden bequem, der gehofft hat, es sei um eine einzelne Führungskraft gegangen. Gefangene professionelle Kunden, ein unverzichtbares Werkzeug, kein alternativer Lieferant: dieses Arrangement erzeugt dasselbe Ergebnis, wer immer es führt, es sei denn, summat steht im Weg. Bei Nominet waren die Mitglieder das am Ende. Bei NBS ist da niemand — der Berufsverband, der diese Rolle hätte spielen können, verkaufte seinen Anteil und ging mit 172 Millionen Pfund davon.\nIch glaube auch nicht, dass es dabei wirklich um irgendeine einzelne Person geht. Setz irgendwen an die Spitze eines mitgliedereigenen Monopols, das ein nationales Gut betreibt, ohne dass ein Regulierer zuschaut, und gib ihm einen Überschuss ohne offensichtlichen Eigentümer, und der Sog geht immer dahin, ihn für etwas Interessanteres auszugeben als für das, was ihn verdient. .uk gut zu betreiben ist keine Geschichte, die man auf einer Konferenz erzählen kann. Auf Australien zu bieten schon.\nDie Korrektur muss, wenn sie kommt, von den Mitgliedern kommen — was heißt, dass jemand ein Jahr seines Lebens hergeben muss, um eine Abstimmung gegen einen Amtsinhaber zu organisieren, der das Geld eben dieser Mitglieder ausgibt, um sich zu wehren. Das ist einmal passiert, und es ging mit 2,7 Prozentpunkten bei 53 % Beteiligung durch. Niemand würde einen Rechenschaftsmechanismus so entwerfen.\nDie zwei echten Rückfallebenen lagen die ganze Zeit ungenutzt. Die Befugnisse aus dem Digital Economy Act traten erst 2024 in Kraft. Eine Neudelegierung ist von niemandem je ernsthaft vorgeschlagen worden.\nNeun Jahre später ist das, was ich gerne wüsste und von außen nicht sagen kann, ob heute jemand bei Nominet in einer Besprechung laut sagen könnte — wir sind ein Non-Profit, sollten wir dafür wirklich Geld ausgeben? — und ein Jahr später noch dort arbeiten würde.\nWenn die Antwort ja ist, hat es etwas gelernt. Wenn sie nein ist, dann haben sich 2021 nur die Namen geändert.\n","permalink":"https://blogs.damiendye.uk/de/dns/what-happened-at-nominet/","summary":"Die .uk-Registry gehört ihren Mitgliedern, und im März 2021 wählten sie das halbe Board ab. Wie der Bestand von innen wirklich aussah, warum der Betrieb von .uk neben Dutzenden gTLDs prägte, wie das Ganze geführt wurde, und wie eine Registry ohne Regulierer am Ende von den Einzigen diszipliniert wurde, die es konnten.","title":"Was bei Nominet geschah"},{"content":"Teil 1 von 8. Diese Reihe ist einfach geschrieben, mit kurzen Zeilen und alltäglichen Worten.\nWorum es in diesem Beitrag geht Was sich daran geändert hat, wie man Technik kauft. Warum es sich geändert hat. Warum es schwerer wurde, einen Anbieter zu verlassen. Warum Open Source dem kein Ende gesetzt hat. Wo das Ganze gelandet ist. Die Änderung Vor zwanzig Jahren hat man Software gekauft.\nMan hat einmal bezahlt. Diese Kopie war die eigene. Man konnte sie nutzen, solange sie lief.\nHeute wird die meiste Software gemietet. Man zahlt jedes Jahr, nur um sie weiter nutzen zu dürfen.\nHört man auf zu zahlen, hört sie auf zu laufen. Man besitzt nichts.\nGenau das ist ein Abonnement. Ein Abonnement ist eine Zahlung, die man wieder und wieder leistet, um einen Dienst behalten zu dürfen.\nMit dem Rechnen selbst ist dasselbe passiert. Früher hat man Server gekauft. Heute mieten viele Betriebe ihre Rechenleistung bei einem Cloud-Anbieter.\nEin Cloud-Anbieter ist eine Firma, die die Rechner für einen betreibt, in ihren eigenen Gebäuden.\nWarum es sich geändert hat Bleiben wir fair, denn das ist wichtig. Es hat sich geändert, weil Mieten oft das bessere Geschäft war.\nServer zu kaufen kostet vorne viel Geld. Mieten kostet vorne sehr wenig.\nCloud-Dienste waren zuverlässig und schnell eingerichtet. Kleine Teams bekamen Werkzeuge, die vorher nur große Firmen bezahlen konnten.\nAbonnements haben auch regelmäßige Aktualisierungen gebracht. Kein großes Umwälzen mehr, das man alle paar Jahre planen muss.\nAlso sind die meisten Betriebe gewechselt, und sie hatten gute Gründe. Niemand wurde gezwungen.\nDie Frage, die diese Reihe stellt, kommt später. Sie handelt davon, was passiert, sobald der Weg nach draußen schwierig geworden ist.\nWarum das Weggehen schwerer wurde Hier kommt der Teil, auf den es ankommt.\nJeder Schritt dieser Änderung hat verschoben, wo das Weggehen schwer ist.\nZuerst saß es im Dateiformat. Ein Dateiformat ist die Art, wie ein Programm die eigene Arbeit speichert. Konnte nur ein Programm die eigenen Dateien öffnen, kaufte man weiter dieses Programm.\nOffene Dateiformate haben das geregelt. Die meisten Dokumente lassen sich heute in mehr als einem Programm öffnen.\nAlso ist der schwere Teil weitergezogen. Er ist zur Schnittstelle gewandert.\nEine Schnittstelle ist die Art, wie eine Software mit einer anderen redet. Baut man alle eigenen Systeme um die Schnittstelle eines Anbieters, bedeutet ein Anbieterwechsel, alles neu zu schreiben.\nDann ist er noch einmal gewandert, zu den eigenen Daten.\nEine kleine Menge Daten zu verschieben ist einfach genug. Jahre davon zu verschieben ist langsam, und manche Anbieter verlangen Geld dafür, sie wieder herauszuholen.\nJeder Zug hat die Software selbst unwichtiger gemacht. Was heute zählt, ist daher, wie viel Arbeit es machen würde, wegzugehen.\nWo die Schwierigkeit des Weggehens im Laufe der Zeit saß Damals Später Heute Deine Daten Dateiformat Schnittstelle Das Programm Deine Daten Dateiformat Schnittstelle Das Programm Deine Daten Dateiformat Schnittstelle Das Programm Das blaue Feld ist der Teil, der schwer zu wechseln ist. Jedes Mal, wenn eine Schicht geöffnet wurde, wanderte die Schwierigkeit zur nächsten. Dieselben Schichten, 3 Mal. Der schwer zu wechselnde Teil ist nach oben geklettert: erst das Dateiformat, dann die Schnittstelle, dann die Daten. Warum Open Source dem kein Ende gesetzt hat Open-Source-Software ist Software, deren Code jeder lesen, nutzen und ändern kann.\nViele haben erwartet, dass sie das löst. Sie hat einen echten Teil davon gelöst, aber nicht den Teil, den man denken würde.\nOpen Source hat gewonnen. Der größte Teil des Internets läuft darauf. Der Code der meisten wichtigen Stücke liegt zum Lesen bereit.\nDer schwere Teil des Weggehens ist damit aber nicht verschwunden, denn er war schon weitergezogen.\nMan kann jede Zeile einer Datenbank lesen. 5 Jahre Daten aus dem Managed Service, der sie betreibt, bekommt man trotzdem nicht leicht heraus.\nEin Managed Service ist, wenn ein Anbieter die Software für einen betreibt, damit man es nicht selbst muss.\nDer Code ist offen. Der Dienst ist es nicht.\nEs gibt hier einen zweiten Punkt, und er ist berechtigt.\nEin großer Teil von Open Source wird von Freiwilligen am Leben gehalten, die nicht bezahlt werden. Große Firmen bauen Produkte auf dieser Arbeit.\n2024 wurde in einem weit verbreiteten Kompressionswerkzeug schädlicher Code gefunden, der darin versteckt war. Dieses Werkzeug wurde von 1 unbezahlten Person gepflegt. Bruce Schneier und andere haben es ausführlich aufgeschrieben.\nDie Lehre ist nicht, dass Open Source riskant ist. Sie ist, dass geteilte Arbeit, auf die sich alle stützen, bezahlt werden muss, und es oft nicht wird.\nWo es gelandet ist Legt man diese Schritte zusammen, kommt man dort heraus, wo wir jetzt sind.\nEine kleine Zahl von Firmen liefert die Dienste, von denen die meisten Betriebe abhängen.\nDie meisten dieser Firmen sitzen in 1 Land, den Vereinigten Staaten.\nZahlen, die das EuroStack-Projekt zusammengetragen hat, setzen nichteuropäische Anbieter bei rund 85 % des europäischen Cloud-Markts an.\nKeine einzelne Entscheidung hat das gemacht. Es ist das Ergebnis sehr vieler vernünftiger Entscheidungen, eine nach der anderen getroffen, über 20 Jahre.\nDas macht es zu einer Entwicklung und nicht zu einem Ereignis.\nWas das für dich bedeutet Nichts davon sagt, dass amerikanische Software schlecht ist. Viel davon ist sehr gut, und genau so ist sie überall hingekommen.\nEs bedeutet aber, dass 1 Frage mehr zählt als früher.\nWie lange würdest du brauchen, um zu einem anderen Anbieter zu wechseln?\nDiese Zahl entscheidet eine Menge, und Teil 2 erklärt, warum.\nZuerst veröffentlicht: 2026-08-25. Zuletzt aktualisiert: 2026-08-25.\n","permalink":"https://blogs.damiendye.uk/de/random/technology-you-rent/","summary":"Vor zwanzig Jahren hat man Software gekauft, und die Kopie war die eigene. Heute mietet man sie, und der Anbieter setzt die Bedingungen. Teil 1 von 8 geht durch, wie es dazu kam, und warum jeder Schritt den Wechsel schwerer gemacht hat.","title":"Wie Technik zu etwas wurde, das man mietet"},{"content":"Teil 2 von 8. Teil 1 hat behandelt, wie das Mieten das Kaufen ersetzt hat.\nWorum es in diesem Beitrag geht Wie der Preis gesetzt wird, sobald das Weggehen schwer ist. Wo der Gewinn besteuert wird. Wessen Recht für deine Daten gilt. Wie Handelsentscheidungen bis zu deiner Hardware durchschlagen. Was passiert, wenn ein Dienst einfach aufhört. 1. Der Preis folgt deinen Wechselkosten Fangen wir mit dem an, den die meisten Organisationen schon hinter sich haben.\n2023 hat Broadcom VMware gekauft. VMware macht die Software, mit der viele virtuelle Server auf 1 physischen Server betrieben werden.\nBroadcom hat daraufhin den Verkauf dauerhafter Lizenzen eingestellt. Kunden mussten auf Abonnements wechseln.\nFür viele von ihnen stiegen die Preise stark. AT\u0026amp;T gab in Gerichtsunterlagen an, die eigenen Kosten würden um etwa 1.050 % steigen.\nCISPE ist ein Branchenverband europäischer Cloud-Anbieter. Er hat sich bei der Europäischen Kommission beschwert und nennt dabei Zahlen ähnlicher Größe.\nIm März 2026 hat CISPE erneut Beschwerde eingelegt, nachdem das europäische Partnerprogramm geschlossen wurde. The Register hat berichtet, was die Anbieter davon hielten.\nNichts davon ist als rechtswidrig erwiesen. Die Beschwerden werden noch geprüft.\nAber das Muster ist deutlich genug, um daraus zu lernen.\nEine Verlängerung ist eine Verhandlung. Deine Position darin hängt an 1 Sache: wie leicht du gehen könntest.\nWürde das Gehen 3 Jahre dauern, hast du sehr wenig Raum, nein zu sagen.\nDabei geht es nicht nur um amerikanische Anbieter. Jeder Anbieter in dieser Lage hat denselben Vorteil.\n2. Wo der Gewinn besteuert wird Die zweite Kostenart ist schwerer zu sehen.\nViele große Technologiekonzerne verkaufen an Kunden in 1 Land und verbuchen den Gewinn in einem anderen.\nDie Landesgesellschaft wird oft behandelt wie ein Dienstleister für den Mutterkonzern. Der größte Teil des Gewinns geht woandershin.\nSo bekommt man große Umsätze in einem Land und eine kleine Steuerrechnung in diesem Land.\nTaxWatch ist eine Forschungsgruppe im Vereinigten Königreich. Sie hat geschätzt, dass 7 große Technologiekonzerne 2021 knapp 15 Milliarden Pfund Gewinn mit britischen Kunden gemacht haben. Nach ihrer Schätzung haben deren Gestaltungen die fällige britische Körperschaftsteuer um rund 2 Milliarden Pfund gedrückt.\nEuropa hat sich diese Gestaltungen vorgenommen. Die Ergebnisse sind gemischt, und es ist nur fair, beide Seiten zu zeigen.\nApple hat verloren. Im September 2024 hat der Gerichtshof der Europäischen Union bestätigt, dass die irischen Steuerregelungen eine rechtswidrige staatliche Beihilfe waren. Irland hat rund 14 Milliarden Euro zurückbekommen. Amazon hat gewonnen. Im Dezember 2023 hat derselbe Gerichtshof die Berufung der Europäischen Kommission in einem ähnlichen Fall zu Luxemburg abgewiesen. Es gibt außerdem ein globales Abkommen, Pillar Two genannt. Es setzt einen Mindeststeuersatz von 15 %.\nIm Januar 2026 hat die Organisation für wirtschaftliche Zusammenarbeit und Entwicklung eine Side-by-Side-Regelung veröffentlicht. Danach folgen Firmen mit Hauptsitz in den Vereinigten Staaten den Regeln der Vereinigten Staaten statt den meisten globalen.\nManche Länder haben eigene Digitalsteuern versucht. Kanada hat eine beschlossen und sie dann im Juni 2025 fallen gelassen, nachdem die Vereinigten Staaten deswegen die Handelsgespräche abgebrochen hatten.\nDas Geld wird also an einem Ort verdient. Wo es besteuert wird, entscheidet sich woanders.\n3. Wessen Recht gilt Das hier wird häufiger missverstanden als alles andere, deshalb lohnt sich Genauigkeit.\nViele glauben, Daten in Europa zu halten halte sie unter europäischem Recht und unter keinem anderen.\nDas ist nicht ganz richtig. Was zählt, ist, wer die Firma kontrolliert, die sie hält.\nDer CLOUD Act ist ein Gesetz der Vereinigten Staaten aus dem Jahr 2018. Es verpflichtet einen US-Anbieter, Daten herauszugeben, die er kontrolliert, egal wo diese Daten liegen. Das Justizministerium legt die Einzelheiten dar.\nEin Rechenzentrum in Frankfurt, betrieben von einer Firma in US-Eigentum, ist damit trotzdem für eine US-Anordnung erreichbar.\n„Unsere Daten bleiben in Europa“ und „unsere Daten liegen außerhalb des US-Rechts“ sind 2 verschiedene Aussagen. Sorgfältige Anbieter machen nur die erste.\nEine gerichtliche Anordnung folgt dem, der die Firma kontrolliert, nicht dem Standort des Gebäudes Rechenzentrum in Europa Hier liegen deine Daten Der Standort folgt EU-Recht Muttergesellschaft Sitz in einem anderen Land Kontrolliert die Daten betreibt den Standort Hier kommt die Anordnung an Die Anordnung muss nicht an das Gebäude gehen. Sie geht an den, der die Daten kontrolliert. Das Gebäude steht in Europa. Die Firma, die es betreibt, gehört woanders. Eine gerichtliche Anordnung geht an den Eigentümer, nicht an das Gebäude. Auch hier verschieben sich die Regeln, in beide Richtungen.\nSection 702 ist ein Überwachungsgesetz der Vereinigten Staaten. Es ist am 2026-06-12 ausgelaufen, weil der Kongress es nicht verlängert hat.\nDas heißt nicht, dass die Erfassung aufgehört hat. Schon erteilte Genehmigungen laufen weiter bis zu ihrem Ablauf, erwartet um März 2027. Das Brennan Center verfolgt das.\nDann gibt es noch das EU-US Data Privacy Framework. Es erlaubt, personenbezogene Daten aus Europa in die Vereinigten Staaten zu übermitteln.\nEine Klage dagegen wurde im September 2025 abgewiesen. Diese Entscheidung liegt nun in der Berufung.\nDas Framework ist heute geltendes Recht. Es ist auch das dritte seiner Art, denn die 2 davor wurden gekippt.\nScheitert eine Übermittlungsregelung, landen die Kosten bei der europäischen Organisation, die sie genutzt hat. 2023 hat die irische Datenschutzbehörde Meta mit 1,2 Milliarden Euro belegt, wegen Übermittlungen in die Vereinigten Staaten.\nAuf all das gibt es eine ruhige, praktische Antwort, und die ist es wert, sie zu kennen.\nHält dein Anbieter die Schlüssel zu deinen Daten, kann dein Anbieter eine gerichtliche Anordnung beantworten.\nHältst du die Schlüssel selbst, muss die Anordnung stattdessen zu dir kommen. Damit liegt die Entscheidung unter dem Recht deines eigenen Landes.\n4. Handelsentscheidungen schlagen bis zu deiner Hardware durch Technik ist heute Teil der Handelspolitik.\nIm Januar 2026 haben die Vereinigten Staaten 25 % Zoll auf eine enge Gruppe fortschrittlicher Computerchips und die Produkte gelegt, die sie enthalten. Eine zweite Stufe wurde angekündigt.\nOb deine eigene Hardware betroffen ist, ändert sich über die Zeit. Der Richtige zum Fragen ist dein Anbieter.\nAuch Handelsbeziehungen können schnell kippen. Gespräche zwischen den Vereinigten Staaten und Kanada sind am 2026-08-22 gescheitert, mit neuen Zöllen von 50 %. Kanada hat Gegenmaßnahmen angekündigt.\nDer kanadische Premierminister hat die Gründe öffentlich dargelegt.\nDer Punkt für dich ist ein enger, und er hängt an niemandes Politik.\nKosten und Verfügbarkeit von Hardware können sich wegen einer Entscheidung in einem anderen Land ändern, kurzfristig.\nIn einem 3-Jahres-Plan sollte man das einrechnen.\n5. Ein Dienst kann aus Gründen aufhören, die nicht deine sind Der letzte Punkt ist für die meisten Organisationen unwahrscheinlich. Er steht hier, weil er anders funktioniert als die übrigen.\nIm Februar 2025 haben die Vereinigten Staaten Sanktionen gegen den Ankläger des Internationalen Strafgerichtshofs verhängt.\nDer Anklager verlor daraufhin die Nutzung seines Microsoft-E-Mail-Kontos und wechselte zu einem schweizerischen Anbieter.\nDer Präsident von Microsoft sagte öffentlich, die Firma habe das Konto nicht geschlossen. Was genau passiert ist, ist weiter strittig, und es ist nur fair, das zu sagen.\nNicht strittig ist die Wirkung. Die deutsche Fachpublikation heise berichtete darüber als Weckruf für die digitale Souveränität in Europa. Es wurde im Europäischen Parlament aufgeworfen.\nBis Ende 2025 war der Gerichtshof auf openDesk umgezogen, eine Open-Source-Alternative.\nWorauf es hier ankommt, ist der Mechanismus.\nKeine offene Rechnung. Keine gebrochene Regel. Nichts an dem Dienst war verkehrt.\nEine Regierung hat eine Entscheidung getroffen, und ein Anbieter musste herausfinden, was er noch rechtmäßig liefern durfte.\nDeine Vereinbarung ist mit deinem Anbieter. Die rechtlichen Pflichten deines Anbieters bestehen gegenüber seiner eigenen Regierung.\nDarauf kann man nicht überwachen. Es gibt keine Warnleuchte auf einem Dashboard.\nFür die meisten Leser ist das Risiko klein, und es zu akzeptieren ist vernünftig. Vernünftig ist es nur, wenn du darüber nachgedacht hast.\nDas Muster über alle 5 Diese 5 Kostenarten sind sehr verschieden voneinander.\nDie erste wirst du sehr wahrscheinlich erleben. Der letzten begegnest du vielleicht nie.\nAber sie teilen 1 Sache.\nJede einzelne wird schlimmer, je schwerer es für dich ist zu gehen.\nEine Preiserhöhung ist ein Ärgernis, wenn du woanders hingehen kannst. Sie ist ernst, wenn du es nicht kannst.\nDas ist der Faden, der durch alles läuft, und er zeigt an eine nützliche Stelle.\nDie Frage, an der zu arbeiten sich lohnt, ist nicht, in welchem Land dein Anbieter sitzt. Sie ist, wie schnell du es dir anders überlegen könntest.\nTeil 3 sieht sich an, wer sonst noch für die Software bezahlt, die du nutzt.\nZuerst veröffentlicht: 2026-08-25. Zuletzt aktualisiert: 2026-08-25.\n","permalink":"https://blogs.damiendye.uk/de/random/what-renting-costs/","summary":"Sobald ein Anbieterwechsel schwer ist, ändern die Kosten ihre Gestalt. Der Preis folgt deinen Wechselkosten. Gewinn wird in einem Land erklärt und in einem anderen erwirtschaftet. Das Recht folgt dem Eigentümer der Firma, nicht dem Standort des Gebäudes. Teil 2 von 8, in einfacher Sprache.","title":"Was es kostet, seine Technik zu mieten"},{"content":"Teil 3 von 8. Teil 2 hat dargelegt, was Abhängigkeit dich kostet.\nWorum es in diesem Beitrag geht Die Jahre, in denen gegen Open Source gekämpft wurde. Warum der Kampf aufhörte. Wer die Software heute am Leben hält. Was passierte, als die Hersteller Geld verlangen wollten. Was mit Firmen passiert, nachdem sie gekauft wurden. Was das für dich bedeutet. Die Jahre, in denen gegen Open Source gekämpft wurde Open Source ist Software, deren Code jeder lesen, nutzen und ändern kann.\nHeute ist das ganz normal. Etwa 15 Jahre lang wurde es als Bedrohung behandelt.\nIm Oktober 1998 wurde ein interner Microsoft-Vermerk durchgestochen. Eric Raymond hat ihn mit Anmerkungen veröffentlicht, und er wurde als Halloween-Dokumente bekannt.\nDer Vermerk war ehrlich über die Qualität von Open Source. Er nannte die Art, wie tausende Leute daran zusammenarbeiten, bemerkenswert.\nDann legte er dar, was dagegen zu tun sei. Eine Zeile erklärt sehr viel:\nBy extending these protocols and developing new protocols, we can deny OSS projects entry into the market.\nAuf Deutsch: Indem wir diese Protokolle erweitern und neue Protokolle entwickeln, können wir Open-Source-Projekten den Zugang zum Markt verwehren. Das Zitat steht im Original, weil es eines ist.\nEin Protokoll ist eine vereinbarte Art, wie 2 Systeme miteinander reden.\nDer Plan war also nicht, ein besseres Produkt zu bauen. Der Plan war, die Verbindungsstellen zwischen Produkten zu ändern, damit ein Wettbewerber nicht einfach eingesetzt werden kann.\nIn den folgenden 10 Jahren kamen mehrere weitere Schritte.\n2003 behauptete eine Firma namens SCO, Linux enthalte Code, der ihr gehöre. Der Fall zog sich über Jahre, und SCO hat nicht gewonnen. Während er lief, waren viele Organisationen unsicher, ob man Linux gefahrlos einsetzen kann.\nMicrosoft schloss außerdem Patentvereinbarungen mit Mobiltelefonherstellern. Mehrere Jahre lang bekam es eine Zahlung für jedes verkaufte Gerät, auf dem Android lief, ein Betriebssystem, das es nicht geschrieben hatte.\n2008 wurden die Dokumentformate von Microsoft als internationaler Standard genehmigt. Mehrere nationale Normungsgremien haben gegen den Ablauf Einspruch erhoben.\nEuropa hat sich einem Teil davon entgegengestellt. Die Europäische Kommission verhängte gegen Microsoft 2004 eine Geldbuße von 497 Millionen Euro, wegen Informationen, die Wettbewerber brauchten, um mit seinen Produkten zu arbeiten.\nSie verhängte 2013 erneut 561 Millionen Euro, weil eine vereinbarte Abhilfe nicht umgesetzt worden war.\nDiese zweite Buße ist einen Moment wert. Das Problem war kein neues. Die vereinbarte Lösung war einfach nicht gemacht worden.\nWarum der Kampf aufhörte Er hörte um 2014 auf, weil er nicht funktioniert hatte.\nLinux war die Software geworden, auf der die meisten Server laufen. Es betreibt auch die meisten Cloud-Dienste und die meisten Mobiltelefone.\nMan kann etwas nicht mehr über die Gerichte herausnehmen, wenn alles darauf aufgebaut ist.\nAlso drehte sich das Vorgehen um.\nMicrosoft trat der Linux Foundation bei. Es gab einige seiner eigenen Werkzeuge als Open Source frei. 2018 kaufte es GitHub, die Seite, auf der ein großer Teil des Open Source dieser Welt geschrieben wird.\nAmazon und Google haben sehr große Geschäfte auf Open Source gebaut, und alle 3 Firmen stecken heute sehr viel Arbeit zurück hinein.\nDiese Arbeit ist echt, und die Software ist dadurch besser. Etwas anderes zu behaupten wäre albern.\nAber 1 Sache hat sich nicht geändert.\nDie Firmen, die Open Source einst aufhalten wollten, gehören heute zu seinen größten Geldgebern. Sie sind auch weiter die größten Firmen im Markt.\nOpen Source hat den technischen Streit gewonnen. Wer die stärksten Karten hält, hat es nicht geändert.\nWer die Software heute am Leben hält Hier kommt der Teil, der Leute außerhalb der Softwarewelt überrascht.\nEin großer Teil weit verbreiteten Open Source wird von sehr kleinen Teams am Leben gehalten. Ein Teil davon von 1 Person, in ihrer eigenen Zeit, für nichts.\nGenau diese Stücke sitzen dann in Produkten, die sehr große Firmen verkaufen.\nIm Dezember 2021 tauchte ein Fehler in Log4j auf, einem kleinen Werkzeug, mit dem Java-Programme festhalten, was sie tun.\nDer Fehler erlaubte Angreifern, eigenen Code auf betroffenen Systemen auszuführen. Er traf eine enorme Zahl von Organisationen auf einmal. Das britische National Cyber Security Centre gab Hinweise dazu heraus.\nDas Werkzeug wurde von einer kleinen Gruppe Freiwilliger gepflegt.\nDie Lehre ist nicht, dass Open Source riskant ist. Das meiste davon ist sehr gut und auf eine Weise einsehbar, wie es geschlossene Software nie ist.\nDie Lehre handelt davon, für Dinge zu bezahlen. Geteilte Arbeit, auf die sich viele Betriebe stützen, braucht Geld, und bekommt es oft nicht.\nDas ist behebbar, und manche Organisationen beheben es. Einen Maintainer zu bezahlen oder eine Stiftung zu finanzieren ist meist ein sehr kleiner Betrag gegen das, was die Software dir erspart.\nWas passierte, als die Hersteller Geld verlangen wollten Manche Firmen bauen Open Source und verkaufen einen bezahlten Dienst darum herum. Das ging lange gut genug.\nEs wurde schwerer, als Cloud-Anbieter begannen, dieselbe Software als eigenen Dienst anzubieten.\nDer Anbieter nahm die Einnahmen. Die Firma, die die Software geschrieben hatte, nicht.\nMehrere von ihnen antworteten mit einer Lizenzänderung, damit andere ihre Software nicht als konkurrierenden Dienst anbieten konnten.\nMongoDB hat 2018 die Lizenz geändert. Elastic folgte 2021. HashiCorp änderte 2023. Redis änderte 2024. Die Open Source Initiative legt die anerkannte Definition von Open Source fest. Sie entschied, dass 1 dieser neuen Lizenzen ihr nicht entspricht.\nViele Linux-Distributionen haben die betroffene Software daraufhin herausgenommen.\nDie weitere Gemeinschaft nahm Kopien der letzten offenen Versionen und führte sie getrennt weiter. So eine Kopie nennt man einen Fork.\nOpenSearch führt den früheren Elasticsearch-Code weiter. OpenTofu führt den früheren Terraform-Code weiter. Valkey führt den früheren Redis-Code weiter. Elastic und Redis sind seitdem beide zu offenen Lizenzen zurückgekehrt.\nEs lohnt sich anzusehen, wie das ausging, denn niemand der Beteiligten hat bekommen, was er wollte.\nEine Firma baute nützliche Software. Eine größere Firma verdiente daran mehr als der Hersteller. Der Hersteller schränkte die Lizenz ein, um zu überleben. Die Gemeinschaft wandte zu Recht ein, das sei kein Open Source mehr. Ein Fork erschien, oft von den größeren Firmen gestützt.\nAm Ende ist die Software weiter frei nutzbar. Die Forks werden überwiegend von den größten Marktteilnehmern gesteuert. Der Betrieb, der die ursprüngliche Arbeit bezahlt hat, steht schwächer da als zu Beginn.\nWas mit Firmen passiert, nachdem sie gekauft wurden Der zweite Weg, auf dem Wert einen Betrieb verlässt, hat nichts mit Softwarelizenzen zu tun.\nEs geht darum, wie eine Firma gekauft wird.\nHier ist das Muster, schlicht gesagt.\nEin Käufer leiht sich den größten Teil des Kaufpreises. Der Kredit wird dann durch die gekaufte Firma besichert. Die Firma trägt am Ende also die Schuld, mit der sie gekauft wurde.\nDer Käufer verkauft danach womöglich die Gebäude der Firma und mietet sie zurück. Das eingenommene Geld kann an die neuen Eigentümer ausgeschüttet werden. Die Firma zahlt nun Miete für Räume, die ihr früher gehörten.\nKosten, die sich nicht in diesem Jahr zeigen, werden gestrichen. Meist heißt das Instandhaltung, Personalzahl, Forschung und Produktentwicklung.\nDann wird die Firma weiterverkauft.\nDie Bank of England hat sich die Finanzstabilitätsseite davon angesehen. Ihre Untersuchung zu Private Equity hält fest, dass starke Verschuldung bei Buy-outs die Ausfallwahrscheinlichkeit dieser Firmen erhöht und deren Kreditgeber Verlusten aussetzt. Sie beobachtet den Sektor weiter.\nNicht jedes Buy-out läuft so, und viele Eigentümer investieren, statt auszuschlachten. Das ist ein Muster, das man erkennen soll, keine Beschreibung aller Käufer.\nWo es aber passiert, ist das Ergebnis jedes Mal dasselbe.\nDer Betrieb lief meist gut. Was nicht funktionierte, war der Betrieb plus die Schuld, die zu seinem Kauf aufgenommen wurde.\nDerselbe Betrieb vor und nach einem kreditfinanzierten Buy-out Vorher Nachher Die Arbeit Gleiches Personal, gleiche Kunden Besitzt seine Gebäude Keine Schuld aus dem Kauf Finanziert Instandhaltung Finanziert Forschung Gezahlte Miete: keine Die Arbeit Gleiches Personal, gleiche Kunden Mietet dieselben Gebäude Trägt den Kredit für den Kauf Instandhaltung gekürzt Forschung gekürzt Gezahlte Miete: jeden Monat gekauft mit geliehenem Geld Der Betrieb macht weiter dieselbe Arbeit für dieselben Kunden. Geändert hat sich, was er besitzt und was er nun auszahlen muss. Derselbe Betrieb, vorher und nachher. Die Arbeit und die Kunden bleiben, wo sie sind. Die Gebäude und die Kredite wechseln den Besitzer, und die laufenden Kosten steigen. Dasselbe Muster in der Software Das hat die Softwarewelt vor einigen Jahren erreicht.\nDer Vermögenswert, an dem gearbeitet wird, ist kein Gebäude. Es sind die Kunden, die nicht leicht gehen können.\nEin ausgereiftes Produkt mit langjährigen Kunden lässt sich neu bepreisen. Diese Kunden können nicht schnell wechseln, und daher zahlen die meisten.\nGleichzeitig lassen sich die Ausgaben für Entwicklung kürzen. Das zeigt sich erst nach Jahren, und dann ist der Verkauf längst durch.\nTeil 2 hat behandelt, wie das für VMware-Kunden aussah.\nEs gibt auch eine Variante, die von Investoren statt von Schulden getragen wird. Sie wurde oft genug beschrieben, um einen Namen verdient zu haben: enshittification, ein Wort, das der kanadische Autor Cory Doctorow ab 2022 verwendet — wörtlich etwa „Verscheißerung“.\nSie läuft in 3 Stufen.\nDer Dienst wird unter seinen Betriebskosten verkauft, bezahlt von Investoren. Er ist billig und gut, also wechseln die Leute dorthin. Sobald die Leute nicht leicht gehen können, wird er stattdessen auf die zahlenden Geschäftskunden zugeschnitten. Sobald beide Seiten gebunden sind, ändern sich die Bedingungen erneut, um den Gewinn zu heben. Stufe 1 ist die, auf die es in dieser Reihe ankommt.\nEine Firma, die jahrelang unter Kosten verkauft, gewinnt nicht, weil sie besser ist. Sie wird finanziert, um den Markt zu nehmen.\nKleinere Betriebe, die ihre eigenen Kosten decken müssen, können diesen Preis nicht halten. Viele machen zu.\nWenn die Preise später auf ein tragfähiges Maß steigen, ist die Auswahl, die es früher gab, oft verschwunden.\nWas das für dich bedeutet Daraus ergeben sich zwei praktische Dinge, und beide sind leicht genug zu tun.\nPrüfe, wie viele Leute deine Abhängigkeiten am Leben halten.\nSieh dir die Werkzeuge an, ohne die deine Systeme nicht laufen könnten. Finde heraus, wie viele Leute jedes davon aktiv pflegen.\nIst die Antwort 1 oder 2, ist das eine Sache, die man wissen sollte. Vielleicht willst du diese Arbeit finanzieren, eine eigene Kopie des Quellcodes halten oder planen, was du tätest, wenn sie aufhört.\nAchte darauf, wem deine Anbieter gehören.\nDeine Bedingungen folgen dem Eigentümer, nicht dem Produkt. Ein Eigentümerwechsel kann deine Verlängerung stärker verschieben als jede Änderung an der Software.\nPrüfe beim Abschluss, was du behältst, wenn du aufhörst zu zahlen. Prüfe, ob du das schon Installierte weiter betreiben darfst und ob du noch Sicherheitsaktualisierungen bekommst.\nBeides dauert nicht lang. Beides ist vor einer Verlängerung viel einfacher als während einer.\nTeil 4 sieht sich an, was Gerichte und Aufsichtsbehörden schon entschieden haben.\nZuerst veröffentlicht: 2026-08-25. Zuletzt aktualisiert: 2026-08-25.\n","permalink":"https://blogs.damiendye.uk/de/random/who-pays-for-the-software/","summary":"Die ersten 2 Beiträge haben angesehen, was Abhängigkeit dich kostet. Dieser sieht an, wer sonst die Rechnung zahlt: die Freiwilligen, die Software für sehr große Firmen am Leben halten, und die Betriebe, die gekauft, belastet und zurückgeschnitten werden. Teil 3 von 8, in einfacher Sprache.","title":"Wer für die Software bezahlt, die du nutzt"},{"content":"Teil 4 von 8. Teil 3 hat angesehen, wer für die Software bezahlt, die du nutzt.\nWorum es in diesem Beitrag geht Warum die Akten es wert sind, gelesen zu werden. Was über Google entschieden wurde. Was über Apple entschieden wurde. Was über Amazon entschieden wurde. Was über Meta entschieden wurde. Das Muster über alles hinweg. Warum die Akten es wert sind, gelesen zu werden Einen Anbieter zu wählen ist eine Vorhersage. Du entscheidest, wie er sich in 3 oder 5 Jahren verhalten wird.\nLeitbilder von Firmen helfen dabei wenig. Jeder hat eines, und sie sagen alle etwa dasselbe.\nTatsachenfeststellungen sind besser. Das sind Schlüsse, zu denen ein Gericht oder eine Behörde nach Anhörung von Beweisen gekommen ist.\nDamit arbeitet dieser Beitrag. Wo es eine europäische Entscheidung gibt, kommt sie zuerst.\nZwei Dinge vor der Liste, denn sie halten sie ehrlich.\nNicht jeder Fall ging gegen die Firmen aus. Manche gingen gegen die Behörden, und die stehen hier auch drin.\nUnd das ist keine Behauptung, europäische Firmen verhielten sich besser. Volkswagen und Wirecard klären das gut genug. Das Muster folgt aus Größe und Marktstellung, nicht aus der Herkunft einer Firma.\nGoogle Die Europäische Kommission war zuerst dran, und die Fälle brauchten lange bis zum Ende.\n2017 verhängte sie gegen Google 2,42 Milliarden Euro. Sie stellte fest, Google habe seinen eigenen Preisvergleichsdienst in den Suchergebnissen nach oben und Wettbewerber nach unten gedrückt.\nGoogle legte Rechtsmittel ein, und der Gerichtshof der Europäischen Union hat die Entscheidung im September 2024 bestätigt.\nDas sind 7 Jahre ab der Buße, und noch länger ab dem Verhalten.\n2018 verhängte die Kommission gegen Google 4,34 Milliarden Euro, wegen der Bedingungen für Telefonhersteller, die den Play Store wollten. Die Buße wurde später auf etwa 4,1 Milliarden Euro gesenkt, und das letzte Rechtsmittel wurde 2026 zurückgewiesen.\n2019 verhängte die Kommission gegen Google 1,49 Milliarden Euro wegen Werbeverträgen. Das Gericht hat diese Entscheidung 2024 aufgehoben, weil der Fall nicht belegt war. Die Behörde hat ihn verloren.\nIn den Vereinigten Staaten stellte ein Gericht 2024 fest, Google habe ein Monopol bei der Suche rechtswidrig aufrechterhalten. Im September 2025 legte dasselbe Gericht die Abhilfen fest. Es verlangte Änderungen an Standardvereinbarungen und eine gewisse Datenteilung mit Wettbewerbern. Es hat abgelehnt, Google zum Verkauf von Chrome oder Android zu verpflichten.\nEine gesonderte Entscheidung in den Vereinigten Staaten stellte im April 2025 fest, Google habe 2 seiner Werbeprodukte rechtswidrig aneinander gekoppelt. Über diese Abhilfe wird noch entschieden.\nApple 2021 verpflichtete ein Gericht in den Vereinigten Staaten Apple dazu, App-Entwicklern zu erlauben, Kunden auf andere Zahlungswege hinzuweisen.\nIm April 2025 stellte dasselbe Gericht fest, Apple habe sich nicht daran gehalten.\nEs stellte außerdem fest, dass eine leitende Person bei Apple unwahre Angaben gemacht hatte und dass die internen Unterlagen der Firma etwas anderes sagten. CNBC hat über die Entscheidung berichtet.\nDas Gericht legte die Sache der Staatsanwaltschaft zur Prüfung eines Strafverfahrens wegen Missachtung des Gerichts vor. Apple kündigte Rechtsmittel an.\nDieser Fall ist aus einem anderen Grund wichtig als die übrigen.\nEine Firma kann ihre Rechtsposition mit Nachdruck vertreten und trotzdem geradeaus mit einem Gericht umgehen. Die Feststellung, dass Angaben unwahr waren, ist etwas völlig anderes.\nDeine Beziehung zu einem Anbieter ist ein Bündel von Versprechen. Das hier ist ein direkter Beleg dafür, wie mit Versprechen umgegangen wird, sobald sie teuer werden.\nAmazon Im September 2025 stimmte Amazon zu, 2,5 Milliarden Dollar zu zahlen, um einen Fall der US-Handelsaufsicht Federal Trade Commission beizulegen. Die Behörde hat die Einzelheiten veröffentlicht.\nEs waren 1 Milliarde Dollar Strafe und 1,5 Milliarden Dollar zurück an die Kunden.\nDer Fall drehte sich um die Gestaltung von Anmeldung und Kündigung bei Prime. Der Vorwurf war, die Bildschirme seien darauf gebaut, Leute anzumelden, die das nicht gewählt hatten, und das Kündigen zu einer Mühe zu machen. Die Behörde sprach von etwa 35 Millionen Betroffenen.\nAmazon stimmte im Rahmen der Beilegung zu, den Anmelde- und Kündigungsvorgang zu ändern.\nBedienoberflächen dieser Größenordnung werden vor der Freigabe getestet und gemessen — das ist normale, sinnvolle Praxis. Daher ist die Wirkung einer Gestaltung meist bekannt, bevor sie ausgeliefert wird.\nMeta 2019 hat die US-Handelsaufsicht Federal Trade Commission eine Strafe von 5 Milliarden Dollar gegen Facebook wegen des Umgangs mit Privatsphäre verhängt, nach dem Fall Cambridge Analytica.\nDer größere Posten ist keine Buße.\n2021 gab eine frühere Mitarbeiterin interne Forschung der Firma an Journalisten und hat dann vor einem Ausschuss des US-Senats ausgesagt. Die BBC berichtete ihre zentrale Aussage: dass die Firma Gewinn immer wieder vor Sicherheit gestellt habe.\nEin Teil dieser Forschung befasste sich mit der Wirkung von Instagram auf jugendliche Nutzer. Teile davon kamen besorgniserregend zurück.\nMeta widersprach der Art, wie die Forschung beschrieben wurde. Die Firma sagte, die Ergebnisse seien gemischter als berichtet, und die frühere Mitarbeiterin habe nicht in diesen Teams gearbeitet. Die Wissenschaft dazu ist insgesamt nicht abgeschlossen, und es ist nur fair, das zu sagen.\nEin Punkt ist unstrittig, und das ist der, den man behalten sollte.\nDie Firma hat untersucht, ob ihr Produkt einer Gruppe von Nutzern schadet. Ein Teil dieser Arbeit kam besorgniserregend zurück. Die Ergebnisse erreichten die Öffentlichkeit, weil jemand sie aus dem Haus getragen hat.\nForschung, die nur so herauskommt, ist keine unabhängige Aufsicht.\nDas Muster über alles hinweg Legt man die Fälle nebeneinander, fallen 4 Dinge auf. Für die Planung zählen sie mehr als jeder einzelne Fall.\n1. Die Strafen sind klein gegen den Gewinn.\nEin paar Milliarden sind eine kleine Zahl gegen Umsätze in Hunderten von Milliarden. Sie landen auch Jahre, nachdem das Geld verdient wurde.\nIst eine Strafe geringer als der Vorteil, wirkt sie wie Betriebskosten und nicht wie Abschreckung.\n2. Die Abhilfen kommen spät.\nDer Abstand zwischen dem Verhalten und einer durchsetzbaren Abhilfe liegt in diesen Fällen bei etwa 7 bis 12 Jahren.\nWettbewerber halten selten so lange durch. Bis eine Abhilfe greift, hat der Markt, den sie schützen sollte, meist längst seine Gestalt geändert.\n3. Einzelpersonen werden selten angefasst.\nBußen zahlt die Firma — also ihre Anteilseigner — während die Leute, die die Entscheidungen freigegeben haben, meist ihre Bezahlung und ihre Stellen behalten.\nDas ist wichtig, weil es den Anreiz formt. Wo die Kosten bei der Firma landen und die Belohnung bei der Einzelperson, sieht die Entscheidung für die Entscheidende lohnend aus.\n4. Probleme sind innen bekannt, bevor sie außen bekannt sind.\nIn mehreren dieser Fälle hatte der Betrieb die Information zuerst. Sie erreichte die Öffentlichkeit stattdessen über ein Leck, eine Klage oder eine Behörde.\nVorsicht aber, was man daraus mitnimmt.\nDas sind meist keine Fälle, in denen eine Person Schaden anrichten wollte. Ein Team hat einen Anmeldebildschirm gegen eine Vorgabe verbessert. Ein Ranking wurde auf mehr Nutzung getrimmt. Ein Forschungsergebnis blieb unveröffentlicht.\nDie Entscheidungen sind über viele Leute verteilt, und jeder Schritt sieht für sich vernünftig aus. Genau das macht das Muster so stabil, und deshalb wird der Appell, sich mehr Mühe zu geben, daran wohl nichts ändern.\nWas man damit macht Nutze es für die Frage, die es tatsächlich beantwortet.\nWo ein Anbieter ein wirtschaftliches Interesse hat und du keine echte Alternative, sagen die Akten: das Ergebnis geht meist zugunsten des Anbieters aus.\nEine Korrektur kommt meist Jahre später und kostet den Anbieter meist weniger, als das Verhalten eingebracht hat.\nDas ist kein Grund, einen Anbieter wegen seines Sitzlandes zu meiden.\nEs ist ein guter Grund, von keinem Anbieter abhängig zu sein, den du nicht verlassen könntest.\nTeil 5 sieht sich an, wie das Recht eines Landes Firmen in einem anderen erreichen kann.\nZuerst veröffentlicht: 2026-08-25. Zuletzt aktualisiert: 2026-08-25.\n","permalink":"https://blogs.damiendye.uk/de/random/what-the-record-shows/","summary":"Einen Anbieter zu wählen heißt zu raten, wie er sich später verhält. Die faireste Grundlage dafür ist, was Gerichte und Aufsichtsbehörden schon entschieden haben. Teil 4 von 8 legt die Feststellungen dar, nimmt die verlorenen Fälle mit hinein und zieht das Muster.","title":"Was die Akten zeigen"},{"content":"Teil 5 von 8. Teil 4 hat angesehen, was Gerichte und Aufsichtsbehörden entschieden haben.\nWorum es in diesem Beitrag geht Recht, das Firmen in anderen Ländern erreicht. Was Frankreich daraus gemacht hat. Ältere Sorgen um Geschäftsinformationen. Druck über den Handel. Annahmen, die mit einem Produkt reisen. Recht, das Firmen in anderen Ländern erreicht Teil 2 hat erklärt, wie das Recht eines Landes an Daten reichen kann, die eine von ihm kontrollierte Firma hält.\nDasselbe Prinzip reicht an die Firmen selbst, und die Wirkungen können deutlich größer sein.\nDas in Europa am besten dokumentierte Beispiel ist Alstom, ein französischer Industriekonzern.\n2014 bekannte sich Alstom in den Vereinigten Staaten schuldig und stimmte zu, 772 Millionen Dollar zu zahlen. Der Fall lief unter dem Foreign Corrupt Practices Act, einem amerikanischen Antikorruptionsgesetz. Das US-Justizministerium hat die Einzelheiten veröffentlicht.\nDie Bestechung war echt. Das hier ist keine Geschichte über eine unschuldige Firma.\nEine Führungskraft von Alstom wurde außerdem auf der Durchreise in den Vereinigten Staaten festgenommen und saß eine Zeit im Gefängnis.\nEtwa im selben Zeitraum verkaufte Alstom sein Energiegeschäft an General Electric, eine amerikanische Firma.\nDie Führungskraft hat seitdem argumentiert, der ungelöste Fall habe während dieses Verkaufs als Druckmittel gewirkt. US-Staatsanwälte haben bestritten, zugunsten eines amerikanischen Käufers gehandelt zu haben.\nDieser Widerspruch ist nie ausgeräumt worden, und daher kann dieser Beitrag ihn auch nicht ausräumen.\nWas Frankreich daraus gemacht hat Zeigen lässt sich, was der französische Staat hinterher geschlossen hat.\nIm Juni 2019 ging ein Bericht an den französischen Premierminister. Er ist als Gauvain-Bericht bekannt, und sein Titel handelt davon, die französische und europäische Souveränität wiederherzustellen und Firmen vor Gesetzen mit extraterritorialer Reichweite zu schützen.\nExtraterritorial heißt: ein Gesetz, das über die Grenzen des Landes hinaus gilt, das es gemacht hat.\nDer Bericht stellte 3 Dinge fest, die hier wiederholt zu werden verdienen.\nSehr hohe Strafen, bis in zweistellige Milliardenhöhe in Dollar, waren französischen, europäischen und anderen nichtamerikanischen Firmen auferlegt worden. Ein großer Teil des Verhaltens hatte kaum einen direkten Bezug zum Gebiet der Vereinigten Staaten. Französische Firmen hatten keine wirksamen rechtlichen Mittel, sich zu wehren. Er hielt außerdem fest, dass amerikanische Firmen selten das Ziel waren.\nFrankreich hat daraufhin sein Abwehrgesetz aktualisiert, ein Gesetz, das begrenzt, welche Informationen französische Firmen an ausländische Behörden geben dürfen. Eine frühere parlamentarische Untersuchung hatte sich 2016 mit demselben Thema befasst.\nMan muss nicht jeden Schluss dieses Berichts schlucken. Es genügt, dass ein nationales Parlament sich die Frage angesehen und entschieden hat, dass es eine Frage der Souveränität ist.\nFür deine eigene Planung ist der Punkt kurz.\nRechtliche Angreifbarkeit durch ein anderes Land ist eine geschäftliche Angreifbarkeit. Nicht bloß eine Compliance-Frage.\nÄltere Sorgen um Geschäftsinformationen Diese Sorge ist nicht neu, und es lohnt zu wissen, wie weit sie zurückreicht.\n2001 veröffentlichte das Europäische Parlament einen Bericht über ein globales System zum Abfangen von Kommunikation, damals als ECHELON bekannt. Das Parlament hat seitdem eine Studie veröffentlicht, die diese Arbeit erneut aufgreift.\nDer Bericht kam zu dem Schluss, dass ein solches System existierte. Er prüfte auch Behauptungen, abgefangene Informationen seien für wirtschaftliche Vorteile genutzt worden, auch gegenüber europäischen Firmen.\nDiese Behauptungen waren damals bestritten und bleiben schwer zu beweisen.\nDer Grund, das zu erwähnen, ist nicht, sie zu klären. Er ist, dass das Europäische Parlament die Frage vor 25 Jahren ernst genug nahm, um eine formale Untersuchung zu führen, und dass sie seitdem nicht verschwunden ist.\nDruck über den Handel Teil 2 hat Zölle auf Hardware behandelt und dass Kanada seine Digitalsteuer fallen ließ, nachdem die Handelsgespräche abgebrochen wurden.\nEin Schritt verdient es, für sich festgehalten zu werden, denn er trifft Personen statt Waren.\nIm Januar 2026 hat das Außenministerium der Vereinigten Staaten Visabeschränkungen gegen 5 europäische Amtsträger verhängt. Sie hatten am Digital Markets Act und am Digital Services Act gearbeitet, den europäischen Gesetzen für große Online-Plattformen.\nDas kam zusammen mit Zolldrohungen im Zusammenhang mit europäischen Durchsetzungsmaßnahmen.\nDas Centre for Strategic and International Studies hat das beschrieben als Einsatz von Handelsmaßnahmen, um digitale Regulierung zu bremsen.\nDas Istituto Affari Internazionali, ein italienisches Institut, hat untersucht, ob die Durchsetzung des Digital Markets Act dadurch verhandelbar wird.\nDas ist die offene Frage. Lassen sich europäische Technikregeln durch Handelsdruck verschieben, ist der Schutz, den sie dir geben, weniger sicher, als der Text vermuten lässt.\nEs ist nur fair hinzuzufügen, dass Handelsdruck ein normales Mittel der Staatskunst ist, das viele Länder einsetzen, europäische eingeschlossen. Der Punkt hier ist, worauf er eingesetzt wird.\nAnnahmen, die mit einem Produkt reisen Der letzte Punkt ist leiser als die übrigen — kein Gerichtsverfahren, keine Buße — und er betrifft dich jeden Tag.\nSoftware wird für den Markt gebaut, den ihre Hersteller am besten kennen. Die Annahmen dieses Marktes reisen mit.\nManche wirst du sofort wiedererkennen.\nDatenschutzeinstellungen stehen oft von Haus aus auf Teilen, weil das in den Vereinigten Staaten der übliche Ansatz ist. Europäisches Recht beginnt damit, um Erlaubnis zu fragen. Werkzeuge zur Personalverwaltung setzen oft voraus, dass ein Arbeitsverhältnis kurzfristig enden kann und dass es keinen Betriebsrat zu beteiligen gibt. Standardvertragsbedingungen wollen Streitigkeiten oft vor einem US-Gericht und nach US-Recht verhandeln, auch bei einem europäischen Kunden. Inhaltsregeln folgen dem Verständnis von Meinungsfreiheit aus 1 Land und werden dann weltweit angewandt. Unterstützung für kleinere Sprachen kommt zuletzt, und manchmal gar nicht. Nichts davon geschieht, um Ärger zu machen — es ist das gewöhnliche Ergebnis davon, für einen Heimatmarkt zu bauen und das Ergebnis überall sonst zu verkaufen.\nEs erklärt allerdings etwas über den größeren Streit.\nDie Datenschutz-Grundverordnung, der Digital Markets Act und der Digital Services Act sind vor allem Europas Feststellung, dass es ein eigener Rechtsraum mit eigenen festen Regeln ist.\nDie Antwort darauf hat die Handelsmaßnahmen von oben umfasst.\nWas das für dich bedeutet Daraus fallen drei praktische Punkte.\nLies die Klausel zum anwendbaren Recht. Prüfe, wessen Gerichte einen Streit verhandeln würden. Bei einem großen Vertrag lohnt es sich, darüber zu verhandeln.\nFrage, wo die Muttergesellschaft deines Anbieters eingetragen ist. Diese Antwort entscheidet mehr als die Adresse des Rechenzentrums.\nPrüfe vor dem Kauf, ob ein Produkt zu deinem Rechtsrahmen passt. Einwilligung, Arbeitsrecht und Aufbewahrung sind die üblichen Stellen, an denen eine importierte Voreinstellung nicht zum örtlichen Recht passt.\nNichts davon braucht eine Meinung über irgendeine Regierung. Es ist gewöhnliche Anbieterprüfung, angewandt auf eine Frage, die die meisten Einkaufslisten noch auslassen.\nTeil 6 sieht sich die Sicherheit an, und den Maßstab, der angelegt wird, wenn ein Anbieter aus Gründen der nationalen Sicherheit ausgeschlossen wird.\nZuerst veröffentlicht: 2026-08-25. Zuletzt aktualisiert: 2026-08-25.\n","permalink":"https://blogs.damiendye.uk/de/random/how-far-the-law-reaches/","summary":"Teil 2 hat das Recht behandelt, das an deine Daten reicht. Teil 5 von 8 behandelt das Recht, das an deine Firma reicht: hohe Strafen nach amerikanischem Recht, ein französischer Parlamentsbericht zur Frage, ob das als Handelswaffe wirkt, Handelsdruck auf Steuerrecht und auf Aufsichtsbehörden, und Produkte, die die Annahmen eines Marktes überall mitnehmen.","title":"Wie weit das Recht eines Landes reicht"},{"content":"Teil 6 von 8. Teil 5 hat angesehen, wie weit das Recht eines Landes reicht.\nWorum es in diesem Beitrag geht Der Grund, der für den Ausschluss mancher Anbieter genannt wird. Was zu geschwächten Produkten belegt ist. Was 2024 passiert ist. Warum das auch Europa trifft. Was du dagegen tun kannst. Der Grund, der für den Ausschluss mancher Anbieter genannt wird Mehrere Regierungen haben chinesische Anbieter aus Telefon- und Internetnetzen ausgeschlossen und manche chinesische Apps auf Dienstgeräten beschränkt.\nDer genannte Grund ist meist derselbe: eine Firma kann gezwungen werden, ihrer eigenen Regierung zu helfen. Also trägt die Hardware ein Risiko, egal was der Code tut.\nDiese Begründung ist stichhaltig. Sie ist auch dieselbe Begründung, die in Teil 2 zur Frage benutzt wurde, wessen Recht für deine Daten gilt.\nBevor es weitergeht, sagen wir eine Sache klar.\nCyberoperationen des chinesischen Staates sind echt. Europäische Sicherheitsbehörden dokumentieren sie ebenso wie amerikanische, und dazu gehört Diebstahl von Geschäftsinformationen in großem Maßstab. Nichts in diesem Beitrag ist eine Verteidigung davon.\nAber wenn der Grundsatz lautet, dass ein Anbieter gezwungen werden kann, seiner eigenen Regierung zu helfen, dann gilt er für jeden Anbieter, der eine Regierung hat.\nLegt man ihn gleichmäßig an, sind die Akten auf europäischer und amerikanischer Seite nicht leer. An Stellen sind sie besser belegt als die Vorwürfe, weil Parlamente sie untersucht haben.\nWas zu geschwächten Produkten belegt ist Drei Punkte, jeder mit Quelle, geordnet danach, wie fest sie stehen.\nEin Nachrichtendienst besaß eine Verschlüsselungsfirma.\nDie Crypto AG war eine schweizerische Firma, die ab den 1950er-Jahren Chiffriergeräte an mehr als 120 Regierungen verkaufte.\nSie gehörte der amerikanischen CIA und dem deutschen BND. Die Geräte waren so verändert, dass diese Dienste die Nachrichten der kaufenden Regierungen mitlesen konnten.\nDas stützt sich auf mehr als Journalismus. Nachdem die Geschichte aufkam, hat das Aufsichtsgremium des schweizerischen Parlaments für die Nachrichtendienste selbst untersucht und im November 2020 einen Bericht veröffentlicht.\nDer schweizerische öffentliche Sender SWI hat über die Feststellungen berichtet, darunter, dass der schweizerische Nachrichtendienst seit 1993 Bescheid wusste.\nZu den Kunden gehörten europäische Regierungen. Es lief rund 50 Jahre.\nEin kryptografischer Standard wurde zurückgezogen.\nEin Zufallszahlengenerator namens Dual_EC_DRBG wurde als Standard der Vereinigten Staaten veröffentlicht — Zufallszahlen sind das, womit Verschlüsselung ihre Schlüssel unvorhersehbar macht.\nForscher zeigten, dass sein Aufbau es demjenigen, der bestimmte Werte darin wählte, erlaubte, seine Ausgabe vorherzusagen.\nDas Normungsgremium riet 2013 von der Nutzung ab und entfernte ihn 2014. The Register berichtete damals über die damit verbundenen geschäftlichen Vereinbarungen.\nHardware wurde auf dem Transportweg abgefangen.\nIm Dezember 2013 veröffentlichte das deutsche Magazin Der Spiegel einen Katalog von Werkzeugen zum Abfangen, der Router, Firewalls, Server und Speicher-Firmware bekannter Hersteller abdeckte.\nDie Berichte beschrieben auch, wie Hardware auf dem Transportweg umgeleitet, verändert, neu verpackt und weiter an den Kunden geschickt wurde.\nDer letzte Punkt ist einen Moment wert für jeden, der Hardware kauft.\nEr bedeutet, dass die Vertrauensgrenze nicht nur dein Anbieter ist — sie ist dein Anbieter und alles, was die Lieferung anfasst.\nÜber den zweiten Teil kann ein ehrlicher Anbieter dir keine Zusicherung geben.\nWas 2024 passiert ist Das ist das Ereignis, das die technische Frage beantwortet, und das Nützlichste in diesem Beitrag.\n1994 beschlossen die Vereinigten Staaten ein Gesetz, das Telefonfirmen verpflichtete, ihre Netze so zu bauen, dass Kommunikation auf rechtmäßiges Verlangen abgefangen werden kann.\nDer Zugang war damit dauerhaft, eingebaut und durch ein rechtliches Verfahren geregelt.\n2024 stellte sich heraus, dass eine dem chinesischen Staat zugeordnete Gruppe, öffentlich Salt Typhoon genannt, in mindestens 9 große amerikanische Telefonfirmen eingedrungen war.\nZu den erreichten Systemen gehörten die Abfangsysteme selbst. The Register berichtete über die Reaktion der Abgeordneten.\nDer Zugang, dessen Einbau eine Regierung verlangt hatte, wurde der Zugang, über den eine andere Regierung hereinkam.\nDas ist kein Pech. Es folgt daraus, wie so etwas funktioniert.\nEin eingebauter Zugang ist eine Fähigkeit, keine Regel. Das Gesetz, das ihn regelt, bindet nur Leute, die dieses Gesetz anerkennen. Wer eingebrochen ist, tut das nicht.\nJedes Argument für eingebauten rechtmäßigen Zugriff setzt voraus, dass der Zugriff beim vorgesehenen Nutzer bleiben kann. Das hier ist der deutlichste Beleg dafür, dass diese Voraussetzung nicht hält.\nWarum das auch Europa trifft Wenn diese Begründung richtig ist, ist sie überall richtig, und daher trifft sie auch europäische Vorhaben.\nVorhaben, Nachrichten auf dem Gerät zu durchsuchen, bevor sie verschlüsselt werden, erzeugen dieselbe Art eingebauten Zugangs.\nDas Vereinigte Königreich hat eine Befugnis, Firmen zur Bereitstellung technischer Fähigkeiten zu verpflichten. Sie wurde genutzt, um Änderungen an einer Verschlüsselungsfunktion zu verlangen, und der Anbieter hat diese Funktion im Vereinigten Königreich abgeschaltet, statt sie zu ändern.\nBeides wird von Demokratien verfolgt, mit Aufsicht, aus ernsten Gründen wie dem Schutz von Kindern.\nBeides baut auch genau die Art Fähigkeit, von der 2024 gezeigt hat, dass sie nicht zuverlässig beim vorgesehenen Nutzer bleibt.\nEin europäischer Zugang ist nicht sicherer als irgendein anderer, denn einem Eindringling ist es gleich, wie rechenschaftspflichtig die Einrichtung ist. Was ihn interessiert, ist, ob das Ding existiert.\nDeshalb ist die nützliche Fassung dieses Arguments eine technische und keine politische.\n„Traue keinen Anbietern aus Land X“ muss jedes Mal neu aufgemacht werden, wenn sich die Politik verschiebt.\n„Nimm an, dass jeder eingebaute Zugang irgendwann von jemandem genutzt wird, für den er nicht gebaut wurde“ hält unabhängig davon.\nWas du dagegen tun kannst Die praktische Antwort dreht sich nicht vor allem darum, bei wem du kaufst. Sie dreht sich darum, so zu bauen, dass die Frage weniger wichtig wird.\nBehandle das Netz als nicht vertrauenswürdig. Verschlüssele den Verkehr Ende zu Ende, und lass ein System einem anderen nicht schon deshalb vertrauen, weil es an einer bestimmten Stelle im Netz sitzt.\nHalte deine Verschlüsselungsschlüssel selbst, wo du kannst. Teil 2 hat erklärt, warum das ändert, wen man nach deinen Daten fragen kann. Es begrenzt auch, was ein Eindringling für lohnend hält.\nSende weniger. Daten, die du nie erhoben hast, können nicht abgefangen, angefordert oder verloren werden. Die unmodischste Maßnahme auf dieser Liste, und oft die wirksamste.\nPrüfe, was deine Hardware ausführt, bevor du ihr vertraust. Verifizierter Systemstart und Firmware-Prüfung sind es wert, eingeschaltet zu werden, wo deine Hardware sie unterstützt.\nBei wirklich sensiblen Systemen: prüfe die Lieferungen. Siegel, an denen sich Öffnen zeigt, und erfasste Seriennummern sind einfach genug.\nNichts davon verlangt von dir zu entscheiden, welche Regierung dir die größten Sorgen machen soll.\nGenau deshalb sind sie die bessere Antwort. Eine Maßnahme, die nur wirkt, wenn deine Einschätzung der Politik stimmt, ist keine richtige Maßnahme.\nTeil 7 tritt aus der Technik heraus und sieht sich an, wie andere Branchen mit demselben Problem umgegangen sind.\nZuerst veröffentlicht: 2026-08-25. Zuletzt aktualisiert: 2026-08-25.\n","permalink":"https://blogs.damiendye.uk/de/random/backdoors-and-who-is-accused/","summary":"Einen Anbieter aus Sicherheitsgründen auszuschließen braucht einen Maßstab, gleichmäßig angelegt. Teil 6 von 8 legt dar, was zu geschwächten Produkten und zum Abfangen belegt ist, samt einer schweizerischen parlamentarischen Untersuchung, und zeigt, warum ein eingebauter Zugang dem gehört, der ihn erreicht.","title":"Hintertüren, und wem sie vorgeworfen werden"},{"content":"Teil 7 von 8. Teil 6 hat Sicherheit und eingebaute Zugänge angesehen.\nWorum es in diesem Beitrag geht Warum der Vergleich nützlich ist. Saatgut, und Lizenzbedingungen für Lebendes. Supermärkte, und die Regeln, die für sie gebaut wurden. Warum die Technik nichts dergleichen hat. Was es dir sagt. Warum der Vergleich nützlich ist Es gibt die verbreitete Ansicht, Technik sei eine neue Art von Macht und brauche eine neue Art zu denken.\nDas ist eine tröstliche Ansicht, und sie ist überwiegend falsch. Sie zu glauben ist einer der Gründe, warum die Antwort so lange auf sich warten lässt.\nDas Problem in dieser Reihe ist ein altes. Ein Anbieter wird unverzichtbar. Die Alternativen des Kunden verschwinden. Bedingungen werden nicht mehr vereinbart, sondern verkündet.\nDas ist in Branchen passiert, in denen überhaupt keine Software steckt.\nDer Vergleich hilft auf 2 Weisen.\nEr zeigt, was als Nächstes kommt, denn diese Branchen sind auf dem Weg weiter.\nUnd er zeigt, wie eine ernsthafte Antwort aussieht, denn manche dieser Antworten existieren schon und wirken.\nSaatgut, und Lizenzbedingungen für Lebendes Ein Bauer, der Saatgut kauft, steckt in etwa in derselben Lage wie eine Organisation, die zentrale Software kauft.\nVier Firmen, Bayer, Corteva, Syngenta und BASF, halten den größten Teil des globalen Saatgutmarkts und einen ähnlichen Anteil bei Pflanzenschutzmitteln. Die schweizerische Organisation Public Eye veröffentlicht dazu Analysen.\nBei einzelnen Kulturen ist es noch enger, und eine Handvoll Firmen hält die meisten einschlägigen Patente.\nDie Lizenzierung wird bekannt vorkommen, wenn du je einen Softwarevertrag gelesen hast.\nPatentiertes Saatgut wird nicht einfach verkauft. Es wird lizenziert, und die Bedingungen können die älteste Praxis der Landwirtschaft unterbinden: einen Teil der Ernte dieses Jahres für die Aussaat im nächsten zurückzuhalten.\nDer Bauer kauft also die Nutzung des Saatguts für 1 Saison. Das Recht, es zu vermehren, was der ganze Sinn eines Saatkorns ist, endet beim Anbieter.\nDas ist ein dauerhafter Kauf, in einen wiederkehrenden verwandelt. Der Landwirtschaft ist das vor der Software passiert.\nEs gibt eine zweite bekannte Einzelheit.\nDas Saatgut ist oft darauf gebaut, mit einem bestimmten Pflanzenschutzmittel zu arbeiten, und dieselbe Firma verkauft beides. Das eine zu kaufen macht den Kauf des anderen leichter als einen Wechsel.\nAgrarökonomen haben die Folgen verfolgt: weniger Sorten im Umlauf, höhere Betriebsmittelkosten und weniger Möglichkeit, den Anbieter zu wechseln.\nSupermärkte, und die Regeln, die für sie gebaut wurden Die andere Hälfte der Lebensmittel zeigt dasselbe Problem von der Einkaufsseite. Das ist das Beispiel, das es wert ist, kopiert zu werden.\nEine kleine Zahl von Händlern erledigt den größten Teil des Lebensmittelumsatzes im Vereinigten Königreich.\nEin Lieferant steht damit sehr wenigen möglichen Kunden gegenüber. Einen zu verlieren kann den Betrieb beenden. Für den Händler ist der Austausch eines Lieferanten die Arbeit eines Vormittags.\nDieses Ungleichgewicht wurde gut genug dokumentiert, dass das Parlament handelte. Der Groceries Code Adjudicator wurde 2013 eingerichtet. Er überwacht, ob große Händler den Groceries Supply Code of Practice einhalten.\nSieh dir an, was dieser Kodex einschränkt, und denk dann an deine letzte Softwareverlängerung.\nVereinbarte Bedingungen nachträglich ändern, ohne Einvernehmen. Einem Lieferanten das Recht in Rechnung stellen, weiter Geschäfte zu machen. Kosten und Risiken ohne Ausgleich auf den Lieferanten schieben. Die Auslistung als Druckmittel in einem Streit benutzen. Die Europäische Union hat ihre eigene Fassung gebaut. Die Richtlinie 2019/633 über unlautere Handelspraktiken deckt die Liefer­kette für Landwirtschaft und Lebensmittel ab.\nSie verbietet verspätete Zahlung, kurzfristige Auftragsstornierung, einseitige Änderung von Bedingungen und die Drohung mit geschäftlichen Vergeltungsmaßnahmen. Jeder Mitgliedstaat hat eine Behörde zur Durchsetzung.\nKeines der beiden Regelwerke ist perfekt. Die Befugnisse des Adjudicator sind begrenzt, er deckt die Preisbildung selbst nicht ab, und er hat seine stärksten Befugnisse sparsam genutzt.\nAber der Grundsatz darin ist der, der in der Technik fehlt.\nWo die Verhandlungsmacht sehr ungleich ist, existiert Vertragsfreiheit nicht wirklich. Also werden bestimmte Praktiken glatt verboten, statt der Verhandlung überlassen zu werden.\nNiemand hat vorgeschlagen, einem Softwareanbieter zu untersagen, vereinbarte Bedingungen nachträglich zu ändern.\nNiemand behandelt eine Gebühr dafür, die eigenen Daten herauszuholen, als Kostenverschiebung auf die schwächere Partei.\nBei Lebensmitteln würde beides sofort auffallen. In der Software nennen wir es ein Lizenzmodell.\nWarum die Technik nichts dergleichen hat Vier Gründe, und sie sind es wert, verstanden zu werden, denn sie zeigen, was sich ändern müsste.\nGeschwindigkeit. Die Konzentration im Lebensmittelhandel hat etwa 100 Jahre gebraucht. Die Konzentration in der Cloud etwa 15. Als man sie deutlich sehen konnte, war sie schon passiert.\nKostenlose Dienste. Das Wettbewerbsrecht ist in den meisten Ländern um die Preise herum gewachsen, die Verbraucher zahlen. Ein Dienst mit dem Preis Null sieht unter diesem Maßstab harmlos aus, auch wenn der Kunde nicht der Nutzer ist.\nDie Behauptung, neu zu sein. Die Branche hat mit Erfolg argumentiert, ihre Wirtschaftlichkeit sei anders, und schwer zu verlassen zu sein sei bloß eine Eigenschaft komplexer Systeme statt einer Entwurfsentscheidung.\nOrganisation. Bauern haben Verbände, Genossenschaften und eine lange Gewohnheit, gemeinsam zu verhandeln. Sie haben das genutzt, um sich bestimmte rechtliche Schutzrechte zu erstreiten.\nTechnikkäufer haben Anwendergruppen und eine Konferenz. Als VMware-Kunden von großen Erhöhungen getroffen wurden, kam der eigentliche Widerstand von einem Branchenverband von Cloud-Anbietern, und er lief über das Wettbewerbsrecht. Teil 2 hat behandelt, wie lange das dauert.\nWas es dir sagt Zwei Schlüsse, und beide sind es wert, mitgenommen zu werden.\nDas Problem ist strukturell, nicht national.\nBayer ist deutsch. Die größten Supermärkte sind britisch, französisch und deutsch. Das Buy-out-Modell aus Teil 3 wird in ganz Europa eifrig genutzt.\nErsetze morgen jeden amerikanischen Anbieter dieser Reihe durch 4 europäische, und das Verhalten kommt zurück, weil es aus der Struktur folgt.\nDaher handelt der Rat hier davon, den Anbieter wechseln zu können, und nicht davon, ein Land auszuwählen.\nEine funktionierende Antwort existiert schon.\nWir müssen keine neue Theorie der Plattformregulierung erfinden.\nEs gibt ein Modell, in dem bestimmte Praktiken verboten sind, weil die Verhandlungsmacht ungleich ist, eine Schlichtungsstelle Beschwerden hört und die schwächere Partei nicht die ganze Beweislast trägt.\nEs wurde für Kohlköpfe gebaut. Es würde auf Cloud-Verträgen funktionieren.\nTeil 8 sieht sich an, was in Europa jetzt gebaut wird, und wie du prüfst, wo du stehst.\nZuerst veröffentlicht: 2026-08-25. Zuletzt aktualisiert: 2026-08-25.\n","permalink":"https://blogs.damiendye.uk/de/random/the-same-pattern-elsewhere/","summary":"Nichts davon ist neu, und es geht eigentlich nicht um Technik. Vier Firmen kontrollieren den größten Teil des weltweiten Saatguts. Zehn Händler bewegen den größten Teil der britischen Lebensmittel. Beides hat eine rechtliche Antwort erzeugt, die es für Software nicht gibt. Teil 7 von 8 vergleicht sie und fragt, warum die Technik davongekommen ist.","title":"Dasselbe Muster in anderen Branchen"},{"content":"Teil 8 von 8. Teil 7 hat das Muster mit anderen Branchen verglichen.\nWorum es in diesem Beitrag geht Was Europa tatsächlich gebaut hat. Was heute realistisch ist und was nicht. 3 Fragen, mit denen du herausfindest, wo du stehst. Ein ehrliches Wort über diese Seite. Die Entwicklung hat gedreht Viele Jahre lang war europäische digitale Unabhängigkeit vor allem ein Gespräch.\nSeit 2025 hat sich das geändert. Es gibt jetzt funktionierende Produkte, und Betriebe, die sie jeden Tag nutzen.\nDas ist die nützlichste Entwicklung der ganzen Reihe, denn es ist die, bei der du handeln kannst.\nOffice- und Zusammenarbeitssoftware openDesk ist ein Satz Open-Source-Werkzeuge für die alltägliche Büroarbeit. Dokumente, E-Mail, Kalender, Dateien, Chat und Videobesprechungen.\nBetreut wird es von ZenDiS, dem deutschen Zentrum für Digitale Souveränität.\nEs ist aus Werkzeugen gebaut, die schon existierten: Nextcloud für Dateien, Collabora für Dokumente, Open-Xchange für E-Mail und Kalender, Element für Chat, Jitsi für Video.\nEs ist im echten Einsatz. Die Bundeswehr hat eine mehrjährige Vereinbarung geschlossen. Das Robert Koch-Institut, eine deutsche Behörde für öffentliche Gesundheit, betreibt es für mehrere tausend Leute. Der Internationale Strafgerichtshof hat es 2025 gewählt.\nEs gibt inzwischen auch kommerzielle Angebote.\noffice.eu ist im März 2026 in Den Haag gestartet. Es ist eine gehostete Alternative in europäischem Eigentum zu den großen amerikanischen Office-Paketen.\nEuro-Office folgte im Juni 2026. Es ist ein gemeinsamer Dokumenteneditor, den mehrere europäische Firmen zusammen gebaut haben, darunter IONOS, Nextcloud, XWiki, OpenProject, Open-Xchange und office.eu.\nSo zusammenzuarbeiten ist wichtig. Es heißt, dass nicht jede Firma denselben Editor noch einmal für sich baut.\nRegierungen, die tatsächlich umziehen Manche Regierungen sind schon umgezogen, was den Übrigen echte Erfahrung zum Lernen gibt.\nDas dänische Digitalisierungsministerium ist ab Juli 2025 von Microsoft 365 zu LibreOffice gewechselt. LibreOffice ist ein kostenloses Office-Paket.\nDas deutsche Land Schleswig-Holstein zieht zehntausende Arbeitsplatzrechner auf Open Source um.\nFrankreich und Deutschland bauen außerdem gemeinsame Werkzeuge zusammen, statt dass jedes für sein eigenes bezahlt.\nEs ist nur fair zu sagen, dass das nicht immer glatt läuft.\nMünchen hat seine Stadtverwaltung über mehrere Jahre auf Linux umgezogen und dann 2017 zurück auf Windows. The Register hat damals über die Kosten berichtet.\nDie Hauptlehre aus München war keine technische. Die Software funktionierte überwiegend. Was nicht hielt, war die politische Unterstützung über Wechsel der Verwaltungsspitze hinweg, bei einem Vorhaben, das über ein Jahrzehnt lief.\nSolche Dinge brauchen also über viele Jahre gleichmäßigen Rückhalt. Das ist eine echte Voraussetzung, und es lohnt, ehrlich damit zu planen.\nZahlungen Zahlungen folgen derselben Entwicklung, und viele Leute wissen nicht, wie konzentriert sie sind.\nAuswertungen von Zahlen der Europäischen Zentralbank legen nahe, dass Visa und Mastercard 2025 rund 47 % des Kartenzahlungsvolumens im Euroraum abgewickelt haben. In mehreren Ländern ist der Anteil deutlich höher.\nMehrere europäische Länder haben eigene Kartensysteme. Das Problem ist, dass sie nicht über Grenzen hinweg funktionieren, also ist das System, das überall funktioniert, das amerikanische.\nWero ist die europäische Antwort. Betrieben wird es von der European Payments Initiative.\nEs begann mit Zahlungen zwischen Privatpersonen in Belgien, Frankreich und Deutschland. Inzwischen hat es zweistellige Millionenzahlen registrierter Nutzer. Luxemburg kam 2026 dazu, und die Niederlande ziehen ihr bestehendes iDEAL-System darauf um. Der European Payments Council veröffentlicht den Fortschritt.\nDas Bezahlen in Geschäften und online ist die nächste Stufe. Das ist die Stufe, die entscheidet, ob Wero eine echte Alternative wird.\nDer digitale Euro sitzt dahinter, auf einer längeren Zeitschiene um 2029.\nNeue Regeln Die Europäische Kommission hat ihren Vorschlag für einen Cloud and AI Development Act am 2026-06-03 veröffentlicht.\nEs ist der erste ernsthafte Versuch, Cloud-Souveränität von einem freiwilligen Etikett in eine rechtliche Anforderung zu verwandeln.\nEr staffelt Cloud-Anbieter in Stufen, danach, wo die Infrastruktur steht, wie unabhängig sie betrieben werden kann und wem sie gehört. Öffentliche Auftraggeber müssten Anbieter verlangen, die mindestens die niedrigste Stufe erfüllen.\nEs ist ein Vorschlag. Er ist noch kein Gesetz, und er kann sich auf dem Weg noch ändern.\nWas realistisch ist und was nicht Eine hoffnungsvolle Liste kann hier leicht schiefgehen, also sagen wir es schlicht.\nHeute realistisch. Bürodokumente, E-Mail, Kalender, Dateien, Chat und Video. Funktionierende europäische und Open-Source-Optionen existieren, und Betriebe betreiben sie gerade jetzt im Echtbetrieb.\nAuf dem Weg. Zahlungen und manche Cloud-Dienste. Die Teile existieren. Die Abdeckung füllt sich noch.\nNoch nicht. Cloud-Infrastruktur im großen Maßstab. Die europäische Kapazität liegt weit unter der Nachfrage.\nWas heute durch eine europäische oder Open-Source-Option ersetzt werden kann Wie ersetzbar jede Schicht heute ist Büroarbeit Dokumente, E-Mail, Kalender, Dateien, Chat, Video Jetzt ersetzbar Zahlungen Wero wächst; Geschäfte und Online sind die nächste Stufe Teilweise bereit Cloud-Infrastruktur Europäische Kapazität ist viel kleiner als die Nachfrage Noch nicht Computerchips Echte europäische Stärken, aber heute kein voller Ersatz Nicht in diesem Jahrzehnt Je weiter oben im Stapel du hinsiehst, desto mehr Wahl hast du heute. Nicht in diesem Jahrzehnt. Die Chips selbst. Europa hat echte Stärken, darunter ASML in den Niederlanden und Infineon und NXP im Chipentwurf. Nichts davon ersetzt heute einen Grafikprozessor für Rechenzentren.\nDie Bertelsmann Stiftung, eine deutsche Stiftung, hat geschätzt, dass der Aufbau eines vollständigen europäischen Stapels rund 10 Jahre und etwa 300 Milliarden Euro brauchen würde.\nVollständige Unabhängigkeit steht also nicht zur Debatte, und wer sie anbietet, verkauft mehr, als er hat.\nDaher war vollständige Unabhängigkeit auch nie das nützliche Ziel.\n3 Fragen, mit denen du herausfindest, wo du stehst Hier ist eine einfache Art, die eigenen Systeme anzusehen. Sie funktioniert für jeden Anbieter, in jedem Land.\nStelle diese 3 Fragen zu jedem Dienst, von dem du abhängst.\n1. Was hört auf zu funktionieren, wenn dieser Dienst aufhört?\nWerde konkret. Nenne die Systeme und die betroffenen Leute. „Es ist wichtig“ ist nichts, womit man planen kann.\n2. Wie viele Arbeitswochen bräuchte ein Umzug?\nDiese Zahl setzt deine Position bei jeder Verlängerung, solange du den Anbieter behältst.\nKannst du sie nicht schätzen, ist das schon eine Sache, die man wissen sollte.\n3. Könnte deine Organisation die Alternative wirklich betreiben?\nNicht, ob eine Alternative existiert. Ob dein Team, in der Größe, die es wirklich hat, sie betreiben könnte.\nLibreOffice ist eine echte Antwort für ein Ministerium mit Schulungsbudget. Es ist eine schwierigere Antwort für eine kleine Firma ohne IT-Personal.\nSortiere deine Dienste nach diesen 3 Antworten. Die Liste ist meist kurz, und oft nicht die, die man erwartet.\nFür viele Betriebe kommen E-Mail und Benutzerkonten oberhalb der Cloud-Rechenleistung heraus. Sie umzuziehen wird selten getestet und würde lange dauern.\nStelle dann dieselben 3 Fragen zu jeder europäischen Alternative, die du abwägst.\nEin einzelner europäischer Anbieter, den du nicht verlassen kannst, ist nicht viel besser als ein einzelner amerikanischer, den du nicht verlassen kannst.\nDer echte Vorteil offener Formate und offener Software ist nicht der Preis. Er ist, dass sie Frage 2 beantwortbar und Frage 3 möglich machen.\nEin ehrliches Wort über diese Seite Es wäre nicht fair, all das zu schreiben, ohne es auf mich selbst zu richten.\nDiese Seite ist mit Hugo gebaut und wird von Cloudflare ausgeliefert, einer amerikanischen Firma. Jeder Punkt dieser Reihe gilt für sie.\nIch habe Cloudflare gewählt, weil es gut funktioniert und mich nichts kostet. Würde das Konto morgen aufhören, würde ich ein paar DNS-Einstellungen ändern und woanders veröffentlichen.\nDie Angreifbarkeit ist also echt und die Folge ist klein. Das ist ein fairer Tausch, und ich habe ihn mit Absicht gemacht.\nDer Rest meiner eigenen Ausrüstung ist ebenfalls gemischt. Proxmox, über das ich oft schreibe, ist österreichisch. Es läuft auf Prozessoren, die in den Vereinigten Staaten entworfen wurden, auf Firmware, die ich nicht einsehen kann.\nEs gibt keinen Aufbau, der auf Null kommt. Das war auch nie das Ziel.\nDie Kurzfassung Technik ist von etwas, das man kaufte, zu etwas geworden, das man mietet.\nMieten ist oft besser, und genau deshalb ist es passiert.\nJede Kostenart des Mietens wächst, je schwerer es für dich ist zu gehen.\nSeit 2025 sind echte Alternativen für die alltägliche Büroarbeit gelandet, und für Zahlungen landen sie gerade.\nDas praktische Ziel ist also nicht, einem bestimmten Land auszuweichen. Es ist, die Zahl der Dienste zu senken, die du nicht innerhalb von 3 Monaten verlassen könntest.\nFang mit denen an, die du noch nie getestet hast. Da wartet die Überraschung meistens.\nZuerst veröffentlicht: 2026-08-25. Zuletzt aktualisiert: 2026-08-25.\n","permalink":"https://blogs.damiendye.uk/de/random/choice-coming-back/","summary":"Seit 2025 ist die europäische Antwort von Plänen zu Dingen geworden, die man installieren kann. Teil 8 von 8 behandelt, was gelandet ist, was ehrlicherweise noch Jahre entfernt ist, und gibt 3 Fragen, mit denen du herausfindest, wo du stehst.","title":"Wo deine Wahl zurückkommt"},{"content":"Jede Maschine in einer Active-Directory-Domäne findet ihren Domänencontroller, indem sie DNS fragt. Nicht aus einer konfigurierten Liste. Sie fragt nach einem SRV-Eintrag, und sie geht dorthin, wohin die Antwort sie schickt. Das macht eine Handvoll Einträge unter _msdcs zum sicherheitskritischsten Ding in der Zone und wirft zwei Fragen auf, die es wert sind, ordentlich beantwortet zu werden: wie signierst du sie, und wer darf sie schreiben. Keine wird oft gestellt, und beide werden standardmäßig schlecht beantwortet.\nDieser Beitrag beantwortet beide für einen Samba4-Domänencontroller. BIND mit dlz_bind9, das das Verzeichnis bereitstellt, Inline-Signing, ein Hidden Primary, den nie ein Client erreicht, eine Delegierung innerhalb einer öffentlichen Zone, sodass die Vertrauenskette bis zur Root läuft, und dynamische Client-Updates weit weg von den Locators.\nAber Signieren ist nur etwas wert, wenn du weißt, was es schützt, und das heißt, eine Ebene tiefer anzufangen — bei der Frage, wie ein Name überhaupt aufgelöst wird. Das erste Drittel hier ist also der Gang von der Root hinunter. Wenn du das schon im Schlaf beherrschst, spring zu Sambas zwei DNS-Backends.\nEin Resolver kommt fast ohne Wissen zur Welt Es lohnt sich, klar zu sein, mit wie wenig ein Resolver geboren wird, denn alles andere in diesem Beitrag folgt daraus.\nEin frisch installierter rekursiver Resolver kennt zwei Dinge. Er kennt die Adressen der Root-Server — eine Hints-Datei, dreizehn Namen von a.root-servers.net bis m.root-servers.net, per Anycast von weit mehr Instanzen als dreizehn bereitgestellt. Und, wenn er validiert, kennt er einen öffentlichen Schlüssel: den der Root.\nDas ist die gesamte eingebaute Konfiguration. Jede andere Tatsache, die er je bereitstellen wird — welche Server autoritativ für uk sind, wo deine Domäne lebt, welche Adresse dein Mailserver hat — wird zur Laufzeit durch Fragen gelernt und dann gecacht, bis ihre TTL abläuft.\nDas ist ein gutes Design. Niemand muss eine Liste der Nameserver des Internets ausliefern, und keine zentrale Stelle muss eine Änderung an deiner Zone genehmigen. Aber es hat eine Folge, um die es im Rest dieses Beitrags geht: ein Resolver glaubt, was ihm gesagt wird, von genau dem Server, auf den die vorherige Antwort ihn verwiesen hat. Nimm die Signaturen weg, und die ganze Struktur ist eine Kette von Behauptungen, jede nur dadurch beglaubigt, dass sie von der Adresse ankam, die die letzte Antwort genannt hat. Das ist viel Gewicht, das an einer Absenderadresse hängt.\nDer Gang den Baum hinunter Eine Abfrage ist nicht eine Frage. Sie ist eine Reihe von Verweisen den Namensbaum hinunter, und jeder Schritt ist eine eigene Anfrage an einen anderen Server.\nSagen wir, ein Client will dc01.ad.example.co.uk. Ein Resolver mit kaltem Cache tut das:\nFrag einen Root-Server. Die Root kennt die Antwort nicht und tut auch nicht so. Sie gibt einen Verweis zurück: einen leeren Antwortabschnitt, und im Authority-Abschnitt die NS-Einträge für uk, mit den Adressen dieser Nameserver als Glue im Additional-Abschnitt. Frag einen uk-Server. Noch ein Verweis, diesmal zu den Nameservern für example.co.uk. Frag einen example.co.uk-Server. Wenn ad.example.co.uk delegiert ist — und im Design später in diesem Beitrag ist es das — noch ein Verweis. Frag einen ad.example.co.uk-Server. Dieser ist autoritativ für den Namen, also antwortet er mit dem A-Eintrag und setzt das AA-Bit (Authoritative Answer). Eine einzelne Abfrage, den Delegierungsbaum hinuntergelaufen, ein Verweis nach dem anderen Rekursiver Resolver Kennt bei Geburt nur: \u0026#183; die Root-Hints \u0026#183; den öffentlichen Schlüssel 1 \u0026#160; Root-Server a\u0026#8211;m.root-servers.net Verweis die NS-Einträge für uk. \u0026#8212; plus ihre Adressen als Glue 2 \u0026#160; uk-Nameserver autoritativ für uk. Verweis die NS-Einträge für example.co.uk. 3 \u0026#160; example.co.uk hält die Delegierung Verweis ad.example.co.uk. ist delegiert \u0026#8212; frag seine Server 4 \u0026#160; ad.example.co.uk autoritativ für den Namen Antwort der A-Eintrag für dc01, mit gesetztem AA-Bit Jeder Schritt wird gecacht, bis seine TTL abläuft, ein warmer Resolver startet also bei Schritt 3 oder 4. Genau das macht einen einzigen vergifteten Cache-Eintrag so wertvoll. Eine Abfrage, vier Server. Jeder Schritt gibt nicht die Antwort zurück, sondern den Namen von etwas Besserem zum Fragen, und der Resolver cacht auf dem Weg nach unten jeden Schritt. Drei Dinge an diesem Gang zählen später.\nDer Verweis ist die Delegierung. Der Elternteil einer Zone hält ihren Inhalt nicht. Er hält NS-Einträge, die sagen „frag da drüben“, und — sobald das Signieren ins Spiel kommt — einen DS-Eintrag, der sagt „und hier ist der Fingerabdruck des Schlüssels, den du dann erwarten solltest“. Delegierung ist der einzige strukturelle Mechanismus, den DNS hat, und sie ist das, womit du eine interne Zone intern hältst.\nFast alles davon wird gecacht. Die Root- und TLD-Verweise haben lange TTLs, also springt ein warmer Resolver direkt zu Schritt drei oder vier. Deshalb lohnt es sich, den Cache eines Resolvers anzugreifen: vergifte einen Eintrag, und du hast alles darunter umgeleitet, so lange wie die TTL, die du gewählt hast.\nDer volle Name wird nicht an jeden Server geschickt. Unter QNAME-Minimierung fragt ein Resolver die Root nur nach uk, nicht nach dc01.ad.example.co.uk. Gut zu wissen, falls du je nach deinen internen Namen in einem Query-Log weiter oben suchst. Sie sollten nicht dort sein.\nStub, rekursiv, autoritativ Drei Wörter, die austauschbar benutzt werden und recht verschiedene Aufgaben meinen. Die Unterscheidung ist für die Active-Directory-Hälfte dieses Beitrags tragend, also lohnt es sich, sie festzunageln.\nWas er tut Läuft den Baum? Hält Zonendaten? Stub-Resolver Die Bibliothek oder der lokale Dienst, den deine Anwendungen aufrufen. Fragt einen konfigurierten Server und nimmt die Antwort. Nein Nein Forwarder Reicht Anfragen an einen anderen Resolver weiter, cacht die Antworten. Nein Nein Rekursiver Resolver Macht den Gang oben, cacht jeden Schritt, validiert optional Signaturen. Ja Nein Autoritativer Server Antwortet für Zonen, die ihm gegeben wurden, und nur für die. Sagt „weiß ich nicht“ zu allem anderen. Nein Ja Die wichtige Zeile ist die letzte. Ein autoritativer Server hat bei Rekursion nichts verloren, und ein rekursiver Resolver hat nichts damit zu tun, autoritativ zu sein. Beide zu kombinieren ist, wie du eine Maschine bekommst, die sowohl beliebige Fragen von Clients annimmt als auch Daten hält, von denen diese Clients abhängen — was genau die Maschine ist, die dein Domänencontroller nicht sein soll.\nAuf einem modernen Linux-Desktop gibt es eine weitere Ebene, die man kennen sollte. systemd-resolved betreibt einen Stub-Listener auf der Loopback-Adresse und schreibt eine resolv.conf, die auf sich selbst zeigt, mit options edns0 trust-ad. Dieses trust-ad ist das, was man beachten muss: es sagt dem Stub, dem AD-Bit (Authenticated Data) in Antworten von diesem Server zu glauben. Das AD-Bit ist für sich genommen kein Beweis für irgendetwas — es ist die Behauptung des vorgelagerten Resolvers, dass er validiert hat. Ihm zu vertrauen ist vernünftig, wenn der Vorgelagerte deiner ist und der Hop zu ihm vertrauenswürdig, und ansonsten bedeutungslos.\nWie Dienste tatsächlich gefunden werden Ein A-Eintrag beantwortet eine Frage: welche Adresse hat dieser Name. Er sagt nichts darüber, auf welchem Port der Dienst liegt, welchen von mehreren Servern man bevorzugen soll oder was zu tun ist, wenn der erste ausfällt.\nSRV-Einträge beantworten alle drei. Aus RFC 2782 ist die Form:\n_service._proto.name. TTL IN SRV priority weight port target Die Teile eines SRV-Eintrags und worüber jeder entscheidet der Transport die Domain der Dienst welche Art Server _ldap. _tcp. dc._msdcs. ad.example.com. 600 IN SRV 0 100 389 dc01.ad.example.com. ein Owner-Name \u0026#8212; Unterstriche halten ihn aus dem Host-Raum TTL Record-Typ Priorität Gewicht Port Ziel Niedrigere Priorität wird zuerst versucht. Gewicht teilt die Last zwischen den Servern auf derselben Priorität. Das Ziel muss ein Hostname mit A- oder AAAA-Einträgen sein \u0026#8212; niemals ein CNAME. Ein einzelnes Ziel \".\" heißt, der Dienst wird hier bewusst nicht angeboten. Ein SRV-Eintrag zerlegt. Der Owner-Name kodiert den Dienst und den Transport; der Eintragskörper trägt die Failover-Reihenfolge, den Lastanteil innerhalb einer Reihenfolge, den Port und ein Ziel, das ein echter Hostname sein muss. Jedes Feld verdient seinen Platz:\nDie Unterstrich-Präfixe halten die Dienst-Labels in einem eigenen Namensraum. _tcp kann niemals mit einem Host kollidieren, der tatsächlich tcp heißt, denn ein Hostname darf nicht mit einem Unterstrich beginnen. Priorität ist die Failover-Reihenfolge — niedriger wird zuerst versucht. Server mit einer höheren Prioritätsnummer werden nur benutzt, wenn alles darunter unerreichbar ist. Gewicht teilt Last innerhalb einer Priorität. Ein Paar mit Gewicht 100 und Gewicht 300 bekommt grob ein Viertel und drei Viertel der Clients. Es ist eine proportionale Ziehung, kein Round-Robin. Port befreit den Dienst von einer wohlbekannten Nummer, was ist, wie ein Client einen LDAP-Server auf 3268 findet, ohne dass jemand es fest verdrahtet. Ziel muss ein Name mit A- oder AAAA-Einträgen sein. RFC 2782 ist ausdrücklich, dass es kein CNAME sein darf und dass ein einzelnes Ziel von . heißt „dieser Dienst wird hier bewusst nicht angeboten“ — etwas Nützliches, um es absichtlich zu veröffentlichen. Das ist, was eine Domäne auffindbar statt konfiguriert macht. Eine domänenverbundene Maschine hat keine Liste deiner Domänencontroller. Sie hat einen Domänennamen, und sie fragt.\nDie Namen, die Active Directory veröffentlicht Eine AD-Domäne ist aus Sicht eines Clients größtenteils ein Satz von SRV-Einträgen. Der Baum unter _msdcs ist der interessante Teil, denn er ist, wie Clients „einen LDAP-Server“ von „einem Domänencontroller für diese Domäne“ von „einem Global Catalogue für diesen Forest“ unterscheiden:\nName Was danach fragt _ldap._tcp.\u0026lt;domain\u0026gt; Alles, was LDAP in der Domäne will _ldap._tcp.dc._msdcs.\u0026lt;domain\u0026gt; Domänencontroller-Lokalisierung — die große _ldap._tcp.pdc._msdcs.\u0026lt;domain\u0026gt; Speziell der PDC-Emulator _ldap._tcp.gc._msdcs.\u0026lt;forest\u0026gt; Global Catalogue _kerberos._tcp.\u0026lt;domain\u0026gt;, _kerberos._udp.\u0026lt;domain\u0026gt; KDC-Lokalisierung, bevor irgendein Ticket existiert _kpasswd._tcp.\u0026lt;domain\u0026gt;, _kpasswd._udp.\u0026lt;domain\u0026gt; Passwortänderungen _ldap._tcp.\u0026lt;site\u0026gt;._sites.dc._msdcs.\u0026lt;domain\u0026gt; Site-bewusste Lokalisierung — finde einen DC, der nah ist Sieh dir an, wofür diese Liste da ist. Kerberos-Authentifizierung kann nicht beginnen, bevor der Client einen KDC gefunden hat, und er findet den KDC per DNS. Site-bewusste Lokalisierung heißt, die Antwort entscheidet auch, gegen welches Rechenzentrum ein Client sich authentifiziert.\nDieselbe Idee, modernisiert SRV hat einen Nachfolger, den man kennen sollte. SVCB- und HTTPS-Einträge (RFC 9460) verallgemeinern das Muster: Dienstparameter in DNS, einschließlich ALPN, Port und Adress-Hinweisen, in einem Eintrag. So lernt ein Browser, direkt zu HTTP/3 zu gehen, ohne einen Redirect. Der HTTPS-Eintrag ist bereits weit verbreitet. Der Mechanismus ist im Geiste derselbe wie SRV: dem Client wird von DNS gesagt, wie er den Dienst erreicht. Was heißt, dass das Argument im nächsten Abschnitt genauso auf ihn zutrifft.\nAlles nach der Abfrage vertraut der Abfrage Hier ist der Angelpunkt, und er ist der Grund, warum ein DNS-Beitrag einen Sicherheitsabschnitt hat statt umgekehrt.\nEine domänenverbundene Maschine bootet und fragt, wo ein Domänencontroller ist. Sie bekommt einen Namen und einen Port. Sie verbindet dorthin, und dann fängt sie an, all die Dinge zu tun, die wir normalerweise für die Sicherheitsschicht halten: Kerberos, LDAP-Signing, Channel Binding, Zertifikatsvalidierung.\nWas passiert also, wenn die Antwort eine Lüge war?\nFair zu sein zählt hier, denn die Antwort ist nicht „sofortige Katastrophe“. Kerberos wurde mit gegenseitiger Authentifizierung entworfen, genau damit ein Client nicht seiner Namensabfrage ausgeliefert ist: ein Host, der kein Service-Ticket für den Namen vorweisen kann, nach dem der Client gefragt hat, kann den Austausch nicht abschließen. Bekomm eine SRV-Antwort, die auf eine Maschine ohne Schlüssel in der Domäne zeigt, und für einen streng konfigurierten Client scheitert es.\nDer realistische Schaden ist subtiler, und er liegt ganz in den Lücken drumherum:\nDowngrade. Ein Client, der auf NTLM zurückfällt, wenn Kerberos nicht funktioniert, ist gerade an den ausgeliefert worden, der geantwortet hat. Relay und Coercion. Der Angreifer muss nicht der DC sein. Der Name zu sein, zu dem ein Client verbindet, reicht, um damit anzufangen, diese Authentifizierung irgendwohin zu relayen, wo sie nützlich ist. Denial of Service, der wie ein Fehler aussieht. Zeige _ldap._tcp.dc._msdcs auf etwas, das nicht antwortet, und die Domäne ist zeitweise kaputt, auf eine Weise, die eine gute Weile niemand als DNS diagnostiziert. Alles ohne jede gegenseitige Authentifizierung. Zeitsynchronisation, Syslog, Monitoring, Backup-Agenten, dieses interne HTTP-Ding mit verify=False. Reichlich Umgebungen haben mehr davon, als sie zugeben würden. Das allgemeine Prinzip ist das, was man mitnehmen sollte: DNS ist ein Entdeckungsmechanismus, kein Autorisierungsmechanismus. Es ist völlig vernünftig, einen Dienst per Namen zu finden. Es ist nicht vernünftig, aufgrund eines Namens irgendetwas zu gewähren, und die Zahl der Systeme, die es leise tun — PTR-basierte Allowlists, Hostnamen-ACLs, „es ist im internen Netz, also muss es unseres sein“ — ist die eigentliche Angriffsfläche.\nWas DNSSEC behebt und was nicht DNSSEC existiert, um eine Frage zu beantworten: kam diese Antwort wirklich unverändert von der Zone, der der Name gehört?\nEs funktioniert (RFC 4033 und die zwei darauf folgenden) durch Signieren und durch das Verketten der Signaturen mit etwas, dem du bereits vertraust:\nJedes RRset in einer signierten Zone hat ein RRSIG — eine Signatur über diesen Satz. Die öffentlichen Schlüssel der Zone werden als DNSKEY veröffentlicht. Die Elternzone veröffentlicht einen DS-Eintrag: einen Hash des Kindschlüssels. Dieses DS ist selbst vom Elternteil signiert, dessen Schlüssel im DS seines Elternteils gehasht ist, den ganzen Weg hinauf zur Root — und der Schlüssel der Root ist das eine Ding, das dein Resolver von Geburt an kennt. Eine Vertrauenskette von der Root hinunter zu einer internen Zone . \u0026#8212; die Root der eine Schlüssel, den dein Resolver schon hat Wo jede Kette beginnt. Mit dem Resolver ausgeliefert, selten gerollt, implizit vertraut. signiertes DS für com. com. oder uk., oder worunter auch immer du sitzt Ein Elternteil bürgt für den Schlüssel seines Kindes. Das DS ist ein Hash des Kindschlüssels, vom Elternteil signiert. signiertes DS für example.com. example.com. öffentlich, signiert, DS beim Elternteil hinterlegt Die Zone, die du schon besitzt und schon signierst. Sie hält die Delegierung für die interne Zone und das DS, das sie authentifiziert. Mehr hält sie vom Inneren nicht. signiertes DS für ad.example.com. über der Linie: ins Internet veröffentlicht darunter: nur innerhalb der Umgebung ausgeliefert ad.example.com. die aus AD abgeleitete Sicht \u0026#8212; nur interne Server Innen signiert, von außen vertraut. Deine Resolver validieren sie Root \u0026#8594; com \u0026#8594; example.com \u0026#8594; hier, ohne lokalen Trust Anchor und ohne etwas zu verteilen. Die Daten verlassen nichts. Nur das Vertrauen kommt herein, über die gewöhnliche öffentliche Kette. Die Kette, die ein validierender Resolver baut. Jedes Elternteil bürgt mit einem signierten DS-Eintrag für den Schlüssel seines Kindes, sodass ein eingebauter Trust Anchor an der Root jede Zone darunter authentifiziert — einschließlich einer delegierten internen Zone, deren Inhalt nie das Gebäude verlässt. Verweigerung wird auch signiert, was leicht zu übersehen ist und mehr zählt, als es klingt. Ohne sie ist „kein solcher Name“ eine unbeglaubigte Antwort, die ein Angreifer fälschen kann, um etwas verschwinden zu lassen. NSEC und NSEC3 geben ein beglaubigtes „zwischen diesen zwei Namen existiert nichts“.\nDas ist eine echte Lösung für ein echtes Problem. Cache-Poisoning ist nicht theoretisch: der Kaminsky-Angriff machte Off-Path-Spoofing billig genug, um über das gesamte Internet hinweg Notfall-Patches zu erzwingen, und die Gegenmaßnahmen, die folgten — Quellport-Randomisierung, 0x20-Groß-Klein-Mischung — sind allesamt Versuche, das Raten schwerer zu machen, nicht Antworten überprüfbar. Seitenkanal-Arbeit hat seither wiederholt an ihnen genagt. Signaturen sind das Einzige in dieser Liste, das das Spiel ändert, statt den Preis zu erhöhen.\nJetzt die ehrlichen Grenzen, denn DNSSEC wird in beide Richtungen überverkauft.\nEs ist keine Vertraulichkeit. Signieren ist Public-Key-Authentifizierung; jede Anfrage und Antwort ist auf dem Draht immer noch im Klartext. Privatsphäre auf dem Client-Hop ist DoT, DoH oder DoQ, und die sind ein anderer Mechanismus, der ein anderes Problem löst. Den Hop zu einem Resolver zu verschlüsseln, der nicht validiert, kauft dir ein privates Gespräch mit etwas, das immer noch angelogen werden kann.\nEs validiert nicht Bedeutung, nur Herkunft. DNSSEC beweist, dass der Besitzer der Zone dies veröffentlicht hat. Wenn der Eintrag falsch ist, oder bösartig, oder von jemandem geschrieben, dem die Zone unklugerweise das Schreiben erlaubte, wird die Signatur genauso treu darauf angewandt. Eine Zone zu signieren, die nicht vertrauenswürdige Maschinen schreiben können, macht den Inhalt nicht vertrauenswürdig — es beglaubigt die Lüge. Halt diesen Satz fest; das letzte Drittel dieses Beitrags ist im Wesentlichen seine Folge.\nEs hilft nur, wenn jemand validiert. Wenn dein Resolver nicht validiert, sind Signaturen auf den Zonen, die du abfragst, Dekoration. Und wenn Validierung an einem Resolver quer durchs Netz vom Client geschieht, vertraut der Client dem AD-Bit und dem Pfad — siehe trust-ad oben.\nUnd es muss betrieben werden. Eine abgelaufene Signatur ist keine verschlechterte Antwort, sie ist SERVFAIL — der Name geht dunkel. Ein DS im Elternteil, das nicht mehr zum Schlüssel des Kindes passt, tut dasselbe. Das ist die ehrliche Kosten, und deshalb zählt die Automatisierung in den nächsten Abschnitten mehr als das anfängliche Signieren.\nWarum eine erfundene interne TLD nicht signiert werden kann Hier kommen Namensentscheidungen, die vor Jahren getroffen wurden, mit einer Rechnung zurück, und es lohnt sich, es zu buchstabieren, weil es der Grund ist, warum das Design dieses Beitrags eine echte, besessene Domäne für interne Namen benutzt.\nSieh noch einmal, wie die Kette gebaut wird: der Schlüssel einer Zone wird durch einen DS-Eintrag in ihrem Elternteil verbürgt. Ein validierender Resolver kann eine interne Zone also nur authentifizieren, wenn diese Zone einen Elternteil hat, der willens und in der Lage ist, ein DS für sie zu veröffentlichen.\nad.corp.local hat keinen solchen Elternteil. Genauso wenig .lan, .home oder irgendetwas anderes, das an dem Tag erfunden wurde, an dem die Domäne bereitgestellt wurde:\n.local ist für mDNS reserviert. Es für Unicast-DNS zu benutzen ist nicht bloß unsigniert, es ist eine dokumentierte Kollision damit, wie jedes Betriebssystem im Gebäude sich verhalten darf. Es bekommt unten einen eigenen Abschnitt, weil es in einer anderen Liga spielt als die anderen drei. .lan, .corp, .home sind nicht registrierte Zeichenketten. Es gibt keinen Elternteil, der ein DS hält, und die beantragten Versionen wurden wegen des Namenskollisions-Chaos in privaten Umgebungen von der Delegierung zurückgehalten. home.arpa ist ordentlich für Heimnetze reserviert, was ideal klingt — aber seine Delegierung ist bewusst unsicher. Es gibt keinen signierten Pfad hinunter zu ihm, per Design. .internal wurde von ICANN genau für diesen Zweck beiseitegelegt, und es löst das Kollisionsproblem. Dieses löst es nicht: keine Delegierung heißt kein DS, also keine Kette. Deine Optionen mit einer nicht verketteten internen Zone sind, sie unsigniert zu lassen, oder einen lokalen Trust Anchor auf jedem validierenden Resolver in der Umgebung zu konfigurieren und zur Root deiner eigenen privaten Insel zu werden — ein Schlüssel, den du jetzt von Hand verteilen, überwachen und rollen musst, auf jedem Resolver, für immer, mit SERVFAIL über die gesamte Domäne als Fehlermodus.\nEs gibt eine viel einfachere Antwort, und sie ist gratis: mach die interne Zone zu einer Delegierung innerhalb einer öffentlichen Zone, die du bereits besitzt und bereits signierst. ad.example.com, delegiert von example.com. Das DS geht in den öffentlichen Elternteil. Jeder validierende Resolver in der Umgebung authentifiziert interne Namen dann mit dem Trust Anchor, den er schon hat, und du verteilst nichts.\nDer Inhalt bleibt drinnen. Nur das Vertrauen kommt von außen. Diese Unterscheidung ist das Design im Rest dieses Beitrags.\n.local ist keine Stilfrage Eine dieser vier verdient einen eigenen Abschnitt, weil sie die ist, die Leute verteidigen, und weil die Verteidigung immer dieselbe ist: es funktioniert, wir benutzen es seit Jahren, wo ist das Problem.\nDas Problem ist, dass .local keine nicht registrierte Zeichenkette ist, die jemand eines Tages verkaufen könnte. Es ist ein Namensraum, der bereits einen Besitzer und ein definiertes Verhalten hat, und das Verhalten ist nicht „frag den DNS-Server“. RFC 6762 §3 ist darüber nicht zimperlich:\nAny DNS query for a name ending with \u0026ldquo;.local.\u0026rdquo; MUST be sent to the mDNS IPv4 link-local multicast address 224.0.0.251 (or its IPv6 equivalent FF02::FB).\nLies, was dieses MUST tatsächlich regelt. Es ist keine Aussage darüber, wem die Zeichenkette gehört. Es ist eine Anweisung darüber, wohin die Anfrage geht — und die Antwort ist eine Multicast-Gruppe auf dem lokalen Link, nicht dein Domänencontroller. Derselbe Abschnitt sagt, Namen unter .local seien „meaningful only on the link where they originate“, das DNS-Äquivalent einer 169.254-Adresse.\nEin Client, der die Spezifikation korrekt befolgt, wird deinen DNS-Server also nie nach einem .local-Namen fragen. Er ruft auf dem Draht, und nimmt, was auch immer antwortet.\nDas erzeugt eine Reihe von Fehlern mit einem sehr bestimmten Geschmack:\nAuflösung hängt vom Client ab, nicht von deinem DNS. macOS löst .local über Bonjour auf und tat es immer; systemd-resolved routet die local-Domäne standardmäßig zu mDNS; Windows macht mDNS seit Windows 10. Drei Stacks, drei Regelsätze, und deine Zonendatei wird von keinem von ihnen konsultiert. Es endet am ersten Router. mDNS ist per Design link-local. Ein Name, der an einem Schreibtisch im selben VLAN auflöst, löst nicht von einer anderen Etage, einem anderen Standort oder dem VPN auf — was das „funktioniert im Büro, kaputt zu Hause“-Ticket ist, das viermal als „Netzwerkproblem“ geschlossen wird, bevor jemand die Spezifikation liest. Das Verhalten ändert sich unter dir. Ob eine gegebene Maschine zuerst Multicast, zuerst Unicast oder beides parallel versucht, hängt vom Resolver-Stack und seiner Version ab. Umgebungen, die „seit Jahren einwandfrei“ auf .local liefen, sind meist Umgebungen, in denen ein Distributions-Update die Reihenfolge noch nicht geändert hat. Der Beweis fehlt dort, wo du ihn suchst. Das Query-Log des DC zeigt nichts, weil nichts ankam. Leute verbringen Tage am Server, und die Anfrage hat den Client nie verlassen. Und es kann nicht signiert werden, was der Punkt dieses Abschnitts ist. Kein Elternteil, kein DS, keine Kette, kein Weg, eine zu veröffentlichen. Jetzt leg das unter eine Active-Directory-Domäne. Der Realm wird vom Domänennamen abgeleitet. Die Service-Principals werden vom Realm abgeleitet. Die _msdcs-Locators — die Einträge, um die es in diesem ganzen Beitrag geht — sitzen unter einem Suffix, das ein konformer Client per Rufen ins lokale Segment auflösen muss. Du baust Kerberos auf einem Namensraum auf, den die Hälfte deiner Umgebung mit einem Protokoll auflöst, das zum Finden von Druckern entworfen wurde.\nUnd der Ausstieg ist teuer, was die ursprüngliche Entscheidung wert macht, unsentimental zu sein. Auf Samba gibt es keine In-Place-Umbenennung. Der dokumentierte Weg ist samba-tool domain backup rename gefolgt von einem Restore: du nimmst eine umbenannte Kopie der Datenbank, säst daraus einen neuen DC, und fügst jeden anderen DC von Grund auf neu hinzu, ohne dass eine Überlappung zwischen Alt-Namen- und Neu-Namen-DCs erlaubt ist. Es ist nicht Windows\u0026rsquo; rendom, das die DCs wenigstens einen nach dem anderen durchgeht. Es ist ein Neuaufbau mit einem hübscheren Namen.\nAlso die ehrliche Zusammenfassung. .local für eine Unicast-Domäne ist keine Vorliebe, keine Konvention und kein harmloses Stück Altlast. Es ist ein dokumentierter Konflikt mit einem Protokoll, das auf jedem Betriebssystem im Gebäude aktiviert ausgeliefert wird, und die Rechnung kommt Jahre später als zeitweise, nicht reproduzierbare Auflösungsfehler an — und, wenn du die Zone endlich signieren willst, als ein Domänen-Neuaufbau.\nDerselbe Fehler mit einem anderen Hut Wenn wir schon dabei sind: Port 5353.\nmDNS lauscht auf UDP 5353, und es ist kein Ersatzport, der zufällig frei ist. Einen normalen Unicast-DNS-Dienst darauf zu stellen, oder Resolver auf :5353 zu zeigen, weil 53 belegt war oder Root brauchte, richtet denselben Schaden aus der anderen Richtung an — jede mDNS-fähige Maschine in diesem Segment spricht jetzt mit deinem Namensdienst, und dein Namensdienst fängt jetzt Multicast-Dienstsuche ab, die er nie beantworten sollte. Der Name und der Port sind zwei Hälften eines Namensraums, und beide gehören bereits jemand anderem.\n.local auf 53, oder Unicast-DNS auf 5353. Dasselbe Missverständnis, dieselbe Klasse zeitweiser Fehler, dieselben Wochen der Zeit von jemand anderem.\nUnd sei ehrlich darüber, was das aussagt Microsoft empfahl .local in der Small-Business-Server-Ära, weshalb so viele Umgebungen es immer noch tragen, und hörte vor langer Zeit auf, es zu empfehlen. Eine .local-Domäne zu erben ist Pech. Die meisten, die das hier lesen und eine haben, haben sie nicht gewählt, und der Abschnitt oben ist ein Migrationsplan statt einer Anschuldigung.\nEine zu deployen ist eine völlig andere Sache, und ich werde deutlich dazu sein, denn das abzumildern hat niemandem geholfen.\nWer .local für Active Directory oder für Standard-Unicast-DNS deployt, oder einen DNS-Dienst auf Port 5353 stellt, ist kein IT-Profi. Er mag den Jobtitel tragen. Er macht den Job nicht. RFC 6762 ist seit 2013 veröffentlicht, in zwanzig Minuten lesbar, und der Satz, der die ganze Frage klärt, steht in Abschnitt 3. Den Namensdienst eines Unternehmens auf einem Namensraum zu bauen, den die Spezifikation für Link-Local-Multicast reserviert, ist keine vertretbare technische Entscheidung. Es ist jemand, der in dem einen Teil des Stacks rät, in dem Raten Fehler erzeugt, die niemand reproduzieren kann und alle dem Netzwerk anlasten.\nEr sollte aus deiner IT-Abteilung entfernt werden. Nicht seitwärts versetzt, nicht mit DNS unter Aufsicht betraut. Aus der Funktion entfernt. Die Rolle existiert, um zu wissen, welches Paket wohin geht und auf wessen Autorität. Wer das Dokument nicht gelesen hat, das den Namensraum regelt, den er für jede Maschine im Gebäude gewählt hat, erfüllt diese Rolle nicht, und ihn darin zu halten heißt, dass die nächste Entscheidung dieser Größe genauso getroffen wird.\nUnd jedes System, das er angefasst hat, sollte auditiert werden. Das ist der Teil, den Leute überspringen, und der Teil, der am meisten zählt. Eine Entscheidung wie diese ist nie isoliert. Wer RFC 6762 nicht prüfte, bevor er die Domäne benannte, hat auch nichts anderes geprüft — also geh und sieh dir an, was er sonst gebaut hat. Erwarte zu finden:\nDNS-Server, die zur Welt offen sind, Forwarder, die jedem antworten, der fragt, und nirgends ACLs. Dynamisches Update weit offen gelassen, und Zonen-Container mit Berechtigungen, die niemand seit Erstellung der Domäne überprüft hat. Zertifikate und Kerberos, auf Namen gebaut, die nie konsistent auflösen würden, mit den Fehlern durch Hosts-Dateien überklebt. Hosts-Dateien. Überall. Ganze Umgebungen wurden durch sie zusammengehalten, genau weil .local nie richtig funktionierte und jemand einen Workaround statt einer Ursache fand. Firewall-Regeln und Dienstkonten, angelegt, um die Symptome loszuwerden, immer noch vorhanden, immer noch mehr gewährend, als sich jetzt jemand erinnert. Das ist keine Rachsucht. Es ist, wofür ein Kompetenzsignal da ist. Wenn du eine Entscheidung findest, die getroffen wurde, ohne die Spezifikation zu lesen, ist die richtige Reaktion, anzunehmen, dass der Rest genauso getroffen wurde, und nachzusehen — denn dieselbe Person konfigurierte deine Authentifizierung, deine Zertifikate und deine Zugriffskontrolle, und du hast jetzt direkte Beweise dafür, wie sie an ein Problem herangeht, das sie nicht vollständig versteht.\nDieses Chaos zu erben kostet dich eine Migration. Die Person zu beschäftigen, die es immer noch anrichtet, kostet dich erheblich mehr.\nSambas zwei DNS-Backends Ein Samba-AD-Domänencontroller speichert seine DNS-Daten im Verzeichnis selbst, und es gibt zwei Wege, sie bereitzustellen.\nSAMBA_INTERNAL ist Sambas eigener DNS-Server, in den AD-DC eingebaut. Er behandelt die AD-Zonen und Kerberos-authentifizierte dynamische Updates und reicht alles andere an einen Forwarder. Samba beschreibt ihn als „the basic feature required in an AD“ unterstützend und empfiehlt ihn „for simple DNS setups“, was fair ist und wörtlich zu nehmen. Er bekommt unten einen eigenen Abschnitt, denn was er nicht tut, ist länger und interessanter als was er tut.\nBIND9_DLZ betreibt BIND als DNS-Server, mit Sambas dlz_bind9-Modul hineingeladen. DLZ — Dynamically Loadable Zones — ist eine BIND-Schnittstelle, um eine Zone mit etwas anderem als einer Zonendatei zu hinterlegen. Das Modul beantwortet BINDs Anfragen direkt aus sam.ldb, also gibt es keine Kopie, keinen Export-Schritt und keine Synchronisation, die schiefgehen kann: BIND liest das Verzeichnis, während es bereitstellt.\nDer interne DNS-Server macht keine Rekursion — er kann es nicht Fang mit dem Ding an, das fast immer falsch beschrieben wird, auch von Leuten, die es betreiben.\n„Der DC ist unser DNS-Server, er macht Rekursion für die Clients“ ist nicht, was passiert, denn der interne DNS-Server kann überhaupt keine Rekursion machen. Sambas eigene Feature-Liste sagt es klar. Das interne DNS unterstützt nicht:\nals Caching-Resolver zu agieren rekursive Anfragen (aber es kann an einen anderen rekursiven DNS-Nameserver weiterleiten) Shared-Key-Transaction-Signature (TSIG) Stub-Zonen Zonentransfers Round-Robin-Lastverteilung zwischen DCs wobei Scavenging und Conditional Forwarders ebenfalls als nicht implementiert gelistet sind.\nLies die ersten zwei zusammen, denn das ist die ganze Geschichte. Er kann nicht auflösen, und er kann nicht cachen. Was dns forwarder dir tatsächlich kauft, ist ein Relay: ein Client fragt den DC nach windowsupdate.com, der DC fragt einen echten Resolver, die Antwort kommt durch den DC zurück, und dann vergisst der DC sie vollständig. Der nächste Client stellt dieselbe Frage und das Ganze passiert wieder.\nSieh zurück auf die Tabelle weiter oben in diesem Beitrag und beachte, was das ist: ein Forwarder ohne den Cache des Forwarders. Er hat die Kosten der Rolle — einen zusätzlichen Hop, eine Abhängigkeit, ein Ding, das ausfallen kann — und keinen ihrer Vorteile.\nEin DC mit SAMBA_INTERNAL, der die Umgebung bereitstellt, ist also kein DNS-Server in dem Sinn, den Leute meinen. Er ist ein ungecachter Proxy für einen echten Resolver, und du hast ihn auf die Maschine gestellt, die dein Verzeichnis hält.\nWarum das ein Risiko ist und nicht nur eine Ineffizienz Die Ineffizienz ist leicht zu sehen: jede externe Abfrage im Gebäude wird zu einem Roundtrip durch den AD-DC, dauerhaft, ohne Cache, der die Kante nimmt. In einer ruhigen Domäne bemerkt es niemand. Genau deshalb überlebt es.\nDas Sicherheitsargument ist das, das es wert ist, gemacht zu werden, und es hat drei Teile.\nDer Listener ist im falschen Prozess. Das interne DNS ist eine Service-Task des AD-DC selbst, laufend mit den Privilegien des Verzeichnisses — nicht ein separater Daemon unter eigenem Konto, wie named es ist. Das Ding, das unbeglaubigtes UDP von allem parst, was Port 53 erreichen kann, läuft also innerhalb des Prozesses, der LDAP und Kerberos bereitstellt und sam.ldb besitzt. BIND hat dreißig Jahre feindlicher Aufmerksamkeit, einen eigenen Benutzer und die Angewohnheit, in einem Jail betrieben zu werden, genau weil ein DNS-Listener eine raue Gegend ist. Sambas interner Server ist ein Komfort-Feature, das zufällig in den Kronjuwelen wohnt.\nClients bereitzustellen heißt, für Clients erreichbar zu sein. Um der DNS-Server der Umgebung zu sein, muss er Anfragen von jeder Workstation annehmen, jedem Drucker, jedem Laptop eines Auftragnehmers auf dem Gast-VLAN, das jemand versehentlich gebrückt hat. Das ist eine große, dauerhaft offene, unbeglaubigte Angriffsfläche auf dem wertvollsten Host, den du hast, und du betreibst sie, um die Kosten eines Resolvers zu sparen, den ein Raspberry Pi hosten könnte.\nUnd ein zur Welt offener Forwarder ist die Waffe von jemand anderem. Ein DC, der für alles weiterleitet, was fragt, ist ein offener Forwarder. Sobald er außerhalb deines Netzes erreichbar ist, wird er zum Reflexions- und Amplifikations-Teilnehmer, was heißt, dass der Verkehr und die Missbrauchsmeldungen beide bei deinem Domänencontroller ankommen. Es gibt kein Rate-Limiting, nach dem man greifen könnte, denn der interne Server hat keins.\nNichts davon braucht eine Samba-Schwachstelle, um eine schlechte Idee zu sein. Es ist eine schlechte Idee allein von der Form her: es stellt einen unbeglaubigten, versehentlich-internetzugewandten, parser-lastigen Dienst in denselben Prozess wie dein Verzeichnis, um eine Aufgabe zu erledigen, von der dokumentiert ist, dass er sie nicht ordentlich kann.\nEr fällt früher um und reißt mehr mit sich Es lohnt sich, klar zu sein, was dieses Argument nicht ist. Es ist keine Behauptung, dass Sambas DNS-Code mehr Bugs hat als BINDs. BIND hat eine lange CVE-Liste, meist weil es die am meisten untersuchte DNS-Implementierung ist, die existiert, und Advisories zu zählen wäre eine schlechte Art, zwischen ihnen zu wählen.\nDer Vergleich, der zählt, ist strukturell, und er kommt auf drei Fragen mit drei unbequemen Antworten hinaus.\nWer kann ihm ein fehlerhaftes Paket schicken? Mit SAMBA_INTERNAL, das die Umgebung bereitstellt: jede Workstation, jedes Telefon im WLAN, alles, was zu Port 53 auf dieser Kiste routen kann. Mit dem Design in diesem Beitrag: der Signierer. Ein Host, ein TSIG-Schlüssel, allow-query auf ihn beschränkt. Das ist kein kleiner Gradunterschied. Es ist der Unterschied zwischen einem exponierten Dienst und einem effektiv unerreichbaren, und er überragt jeden Unterschied in Code-Qualität zwischen den zwei Implementierungen.\nWas fällt um, wenn es umfällt? Das ist das, was die Schwere entscheidet. named ist ein separater Daemon unter eigenem Konto; wenn er stirbt, hört DNS auf und der Domänencontroller authentifiziert weiter. Sambas internes DNS ist eine Service-Task innerhalb des AD-DC, also passiert alles, was es verklemmt, erschöpft oder abstürzen lässt, innerhalb des Prozesses, der LDAP und Kerberos bereitstellt. Ein DNS-Problem wird zu einem Verzeichnis-Ausfall. Und systemctl restart named kostet eine Sekunde, während einen DC neu zu starten eine andere Art Morgen ist.\nWas kannst du dagegen tun, während es passiert? BIND hat Response Rate Limiting, allow-query, allow-recursion, blackhole, Per-View-Policy und die Option, Clients gar nicht zu antworten. Der interne Server hat dns forwarder und eine Log-Datei. Wenn etwas anfängt, darauf einzuhämmern, gibt es keinen Regler zum Drehen.\nDann füge den fehlenden Cache hinzu. Jede Client-Abfrage ist ein frischer ausgehender Roundtrip, also kostet eine Abfrageflut den DC eine vorgelagerte Abfrage pro Paket statt einen Cache-Treffer — und sie kostet ihn im selben Prozess, der versucht, Kerberos-Tickets auszustellen. Du brauchst dafür keinen Exploit; du brauchst einen geschäftigen Morgen, eine sich schlecht benehmende Anwendung oder jemanden, der einen Scanner auf das falsche VLAN richtet. Anhaltend präsentiert es sich als langsame Authentifizierung, und niemand denkt daran, DNS anzusehen.\nAlso ja — selbst mit DLZ im Bild ist BIND der sicherere Ort dafür. Das DLZ-Modul gibt named tatsächlich Zugriff auf Sambas Daten, und das ist eine echte Überlegung, aus der dieser Beitrag bereits einen Punkt gemacht hat. Aber ein named-Absturz ist ein DNS-Ausfall statt eines Verzeichnis-Ausfalls, und in diesem Design nimmt dieses named gar keine Anfragen von der Umgebung an. Bugs sind eine Tatsache jeder Codebasis. Blast Radius und Erreichbarkeit sind Dinge, die du wählst.\nUnd er kann das Design in diesem Beitrag nicht bauen Es gibt einen einfacheren, endgültigeren Grund, warum er hier nicht das Backend ist.\nKeine Zonentransfers. Die Pipeline im nächsten Abschnitt — Hidden Primary, Signierer, eigenständige autoritative Server — beginnt mit einem AXFR aus dem DC. SAMBA_INTERNAL hat nichts zum Transferieren. Kein TSIG, außerdem, also fehlt sogar die Authentifizierung, die dieser Transfer bräuchte. Und kein Signieren, und keine Validierung von irgendetwas, das er weiterleitet.\nAlso die ehrliche Zusammenfassung von SAMBA_INTERNAL: es ist das Backend, das dich an einem Sonntagnachmittag im Labor eine AD-Domäne hochziehen lässt, ohne BIND zu konfigurieren, und darin ist es sehr gut. Samba sagt „simple DNS setups“ und meint es. Es ist kein Resolver, es wurde nie gebaut, um der DNS-Dienst für eine Umgebung zu sein, und in dem Moment, in dem du Signieren, Transfers, Views, ACLs, Caching oder Rate-Limiting willst, ist die Antwort nicht, es zu tunen. Es hat diese Regler nicht. Die Antwort ist BIND.\nWenn du es heute mit jedem Client auf den DC gezeigt betreibst, ist die Behebung nicht dringend, aber auch nicht optional: gib den Clients einen echten validierenden Resolver, und setze dns forwarder auf dem DC, damit er darauf zeigt, sodass der DC für seine eigenen Zonen antwortet und sonst nichts.\nUnd das ist der Teil, über den ich klar sein will, denn „benutz kein DLZ“ wird wiederholt, als wäre es eine Härtungsregel: DLZ ist nicht die Exposition. Es ist der Extraktionsmechanismus. Was zählt, ist nicht, welches Modul in BIND geladen ist — es ist, wer mit diesem BIND sprechen darf und was als Nächstes mit der Zone passiert. Ein DLZ-hinterlegtes BIND, das nur eine Transfer-Anfrage von deinem Signierer beantwortet, ist keine Angriffsfläche in irgendeinem interessanten Sinn. Ein SAMBA_INTERNAL-DC, der jede Namensabfrage von vierhundert Laptops abfängt, sehr wohl. Nur einer dieser zwei taucht auf Härtungs-Checklisten auf, und es ist nicht der, der zählt.\nZwei Dinge über DLZ sind wahr und wert, um sie herum zu planen statt sie zu fürchten:\nDas Modul ist versionsgekoppelt an BIND. Samba liefert eine separate .so pro BIND-Version, und named.conf nennt eine bestimmte. Ein BIND-Major-Upgrade heißt, das passende Modul muss vorhanden sein, sonst startet named nicht. Es ist eine Paketierungs-Abhängigkeit, die man im Voraus testet, keine Sicherheitseigenschaft. named braucht Zugriff auf Sambas Daten, weshalb Samba ein eigenes Verzeichnis für die Teile hält, die BIND braucht, statt ihm das ganze Private-Verzeichnis zu gewähren. Die Gewährung soll schmal sein — es lohnt sich, zu prüfen, dass sie es auf deinen DCs noch ist, denn es ist die eine Stelle, an der DLZ tatsächlich erweitert, was eine Kompromittierung von named erreichen würde. Der Grund, warum DLZ hier die richtige Wahl ist, ist, was es ermöglicht: BINDs DLZ-Schnittstelle unterstützt das Aufzählen einer ganzen Zone, was einen Zonentransfer aus einer DLZ-hinterlegten Zone überhaupt erst möglich macht. Dieser Transfer ist der erste Hop der Pipeline, und es ist BIND, das ihn macht, was heißt, dass der Rest der Pipeline gewöhnliche BIND-Konfiguration ist statt irgendetwas Exotisches.\nEs gibt eine Einschränkung, die alles Nachgelagerte formt, und es lohnt sich, sie klar zu sagen, weil man leicht das Gegenteil annimmt. Eine DLZ-Zone kann nicht selbst signiert werden. ISC ist darüber im BIND ARM ausdrücklich: DLZ „is unable to handle DNSSEC-signed data due to its limited API“. Du kannst keine dnssec-policy an die dlz-Anweisung hängen und fertig sein.\nWas du tun kannst — und was ISC für DLZ im selben Atemzug vorschlägt — ist, sie als Hidden Primary zu betreiben, wobei das Signieren von einer normalen BIND-Zone erledigt wird, die die Daten hereintransferiert. Das ist der nächste Abschnitt, und die Einschränkung ist der Grund, warum er die Form hat, die er hat.\nEs ist wert, zu wissen, dass das eine Samba-Einschränkung ist statt ein Gesetz von Active Directory. Microsofts DNS-Server macht seit Windows Server 2012 Online-Signing dynamischer, AD-integrierter Zonen. Die Zone wird an Ort und Stelle signiert, die privaten Schlüssel replizieren über die AD-Replikation selbst zu den Key Masters, und dynamische Updates funktionieren weiter. Auf Windows ist „signiere die AD-Partitionen“ eine echte Option, und die Antwort auf den Churn-Einwand ist eingebaut. (Auf Server 2008 R2 war sie es nicht: du konntest eine AD-integrierte Zone signieren, aber keine, die dynamische Updates annimmt, und jede Änderung hieß Neu-Signieren von Hand — woher die Folklore stammt, dass AD-Zonen nicht signierbar seien.)\nSamba hat kein Äquivalent. Kein Backend signiert: der interne Server hat gar kein DNSSEC, und DLZ kann keine signierten Daten tragen. Auf Samba ist die Transfer-und-Signier-Pipeline also nicht ein Design unter mehreren. Sie ist der Weg.\nDie Veröffentlichungs-Pipeline Jetzt ihre Form. Vier Rollen, und der DC ist ganz hinten, wo nichts ihn erreichen kann.\nEine Active-Directory-Zone von einem Hidden-Primary-Domänencontroller veröffentlichen Domänencontroller \u0026#8212; Hidden Primary BIND mit dlz_bind9, autoritativ aus dem Verzeichnis Rekursion aus \u0026#183; Transfer nur an den Signierer, mit TSIG Der Verzeichnis-Host nimmt keine Fragen an. Die wertvollste Maschine der Umgebung ist für die abhängigen Maschinen nicht erreichbar. AXFR beim SOA-Refresh ein Poll \u0026#8212; DLZ kann kein Notify senden Signier-Instanz \u0026#8212; ein normales Secondary transferiert die Zone herein und liefert sie signiert ein zweites named auf dem DC, oder ein eigener Host Die DLZ-Zone kann selbst nicht signiert werden. Signieren ist also ein normales Secondary mit der Kopie \u0026#8212; und ohne Clients in der Zone gibt es keine Fluktuation. Transfer hinaus die signierte Zone Autoritative Server einfache Secondaries der signierten Zone keine Schlüssel, kein Weg zum Verzeichnis Ein Einbruch bekommt eine Kopie, keine Fälschung. Ohne Schlüssel auf den Servern zur Umgebung hin kann kein neuer Eintrag erzeugt werden, der validiert. Anfragen mit Signaturen beantwortet Validierende Resolver worauf die resolv.conf der Clients zeigt interne Zonen weitergeleitet, öffentlicher Baum gelaufen Validierung geschieht nahe am Client. Die Kette läuft zum Root Trust Anchor, weil die interne Zone eine Delegierung in einer öffentlichen ist. kein Client- DNS am DC Die Veröffentlichung läuft in eine Richtung, vom Verzeichnis nach außen. Nichts, was ein Client sendet, kommt je oben an. Der DC ist ein Hidden Primary: er stellt die AD-Zone per Transfer bereit und beantwortet nichts sonst. Die Signier-Instanz ist eine gewöhnliche Secondary-Zone, die die transferierte Kopie hält — die DLZ-Zone selbst kann nicht signiert werden, also geschieht das Signieren immer einen Hop weiter, ob dieser Hop ein zweites named auf dem DC oder ein separater Host ist. Die eigenständigen autoritativen Server sind das Einzige, was Clients je sehen, und sie sind Secondaries der signierten Zone. 1. Der Domänencontroller — Hidden Primary. BIND mit dlz_bind9, autoritativ für die AD-Zonen aus dem Verzeichnis. Rekursion aus. Kein client-zugewandter Dienst. allow-transfer auf den Signierer allein beschränkt, mit TSIG. Aus Sicht des Netzes stellt der DC gar kein DNS bereit, und das Einzige, was ihn je abfragt, ist die nächste Kiste.\n2. Die Signier-Instanz — eine normale BIND-Zone, die die Daten hereintransferiert. Hier leben inline-signing und die dnssec-policy, auf einer Zone desselben Namens, die die transferierte Kopie hält. BIND behält die unsignierte Kopie, die es empfangen hat, und die signierte Kopie, die es veröffentlicht, als getrennte Dinge und signiert neu, wenn neue Transfers eintreffen. Weil es ein Transfer statt einer geteilten Datei ist, kann diese Instanz auf dem DC selbst sitzen — ein zweites named auf seiner eigenen Adresse — oder auf einem separaten Host, und die Konfiguration ist so oder so nahezu identisch.\nDer Handel ist der, wonach er aussieht: auf dem DC ist eine Maschine weniger zu betreiben, während ein separater Host private Schlüssel von der Kiste fernhält, die das Verzeichnis hält. Beides ist vertretbar, und die Wahl ändert sonst nichts an der Pipeline. Was zählt, ist, dass Signieren einmal geschieht, an einem definierten Punkt, unter einer Schlüsselrichtlinie — der Unterschied zwischen DNSSEC, das du betreibst, und DNSSEC, das um drei Uhr morgens abläuft.\n3. Die autoritativen Server — das Einzige, was Clients sehen. Einfache Secondaries der signierten Zone. Sie halten keine Schlüssel, signieren nicht und haben keinen Weg zum Verzeichnis. Wird einer kompromittiert, hat der Angreifer eine Kopie einer Zone und keine Fähigkeit, einen neuen Eintrag zu fälschen, der validiert.\n4. Die Resolver. Validierende rekursive Resolver für die Umgebung, die die internen Zonen bedingt an diese autoritativen Server weiterleiten und den öffentlichen Baum für alles andere laufen. Das ist, worauf die resolv.conf der Clients zeigt.\nZwei Eigenschaften fallen aus dieser Anordnung, die es wert sind, für sich genannt zu werden, weil sie der ganze Sinn sind:\nDie Maschine, die das Verzeichnis hält, ist für die Maschinen, die es benutzen, nicht erreichbar. Ein Domänencontroller ist der wertvollste Host in der Umgebung. Ihm einen client-zugewandten Netzdienst zu geben — einen, der unbeglaubigtes UDP von jeder Workstation beantwortet — ist ein schlechter Handel für einen Dienst, den andere Maschinen erledigen können. Signieren geschieht einmal, an einem definierten Punkt. Der übliche Einwand gegen das Signieren einer AD-Zone ist Churn — dass der Inhalt sich zu oft ändert, als dass Signaturen mithalten könnten. Dieser Einwand ist eigentlich ein Einwand gegen das Standard-Layout, nicht gegen das Signieren. Mit ausgelagerter Client-Registrierung, wie der nächste Abschnitt argumentiert, dass sie es sein muss, ändert sich die AD-Zone, wenn ein Domänencontroller herauf- oder heruntergestuft wird, und sonst ungefähr nie. Eine Zone, die nur DCs schreiben, ist eine stabile Zone, und eine stabile Zone ist ein unauffälliges Ding zum Signieren. Clients herauszuhalten ist nicht nur eine Sicherheitskontrolle; es ist, was die Zone ruhig genug macht, um sauber zu signieren. Wie das Signieren tatsächlich verdrahtet ist Die Form oben ist der wichtige Teil, aber „eine normale BIND-Zone, die die Daten hereintransferiert“ verdient es, gezeigt statt beschrieben zu werden, denn der erste Versuch daran scheitert meist am Versuch, das DLZ direkt zu signieren.\nAuf dem DC bleibt die DLZ-Seite bewusst stumpf. Sie stellt das Verzeichnis bereit, reicht die Zone an genau einen Peer und tut sonst nichts:\nkey \u0026#34;transfer-to-signer\u0026#34; { algorithm hmac-sha256; secret \u0026#34;...\u0026#34;; }; options { recursion no; allow-query { key transfer-to-signer; localhost; }; allow-transfer { key transfer-to-signer; }; notify no; }; dlz \u0026#34;AD DNS Zone\u0026#34; { database \u0026#34;dlopen /usr/lib64/samba/bind9/dlz_bind9_18.so\u0026#34;; }; Beachte, dass die .so die BIND-Major-Version in ihrem Namen trägt. Das ist die Versionskopplung aus dem vorigen Abschnitt konkret gemacht — ein BIND-Upgrade braucht das passende Samba-Modul an Ort und Stelle, bevor named startet.\nAuf der Signier-Seite ist die Zone eine gewöhnliche Secondary mit den angehängten Signier-Optionen. Das ist der Teil, der nicht auf dem DLZ leben kann:\ndnssec-policy \u0026#34;ad-internal\u0026#34; { keys { ksk lifetime P365D algorithm ecdsa256; zsk lifetime P90D algorithm ecdsa256; }; }; zone \u0026#34;ad.example.com\u0026#34; { type secondary; primaries { 192.0.2.10 key transfer-to-signer; }; file \u0026#34;ad.example.com.axfr\u0026#34;; inline-signing yes; dnssec-policy \u0026#34;ad-internal\u0026#34;; allow-transfer { key transfer-to-public; }; also-notify { 192.0.2.20; 192.0.2.21; }; }; Dass das auf einer Secondary funktioniert, ist das tragende Detail, und das ARM sagt es direkt:\nIf yes, BIND 9 maintains a separate signed version of the zone. An unsigned zone is transferred in or loaded from disk and the signed version of the zone is served with, possibly, a different serial number.\nBIND behält also zwei Kopien — die unsignierte, die es empfangen hat, in file geschrieben, und die signierte, die es bereitstellt, daneben mit einer .signed-Endung geschrieben. Ein Transfer trifft ein, die signierte Version wird neu erzeugt, und die nachgelagerten Server bekommen ein notify, denn an diesem Punkt ist es eine völlig gewöhnliche Zone. inline-signing yes ist tatsächlich die Voreinstellung, sobald eine dnssec-policy angehängt ist; es ist oben ausgeschrieben, weil eine Konfiguration, die sagt, was sie tut, die Zeile wert ist.\nSchlüsselrollover kommt mit der Richtlinie statt mit einem Cron-Job. ZSK-Rollover brauchen gar keine Eingabe; KSK-Rollover brauchen, dass das neue DS zum Elternteil kommt, was die CDS/CDNSKEY-Automatisierung von später in diesem Beitrag ist. rndc dnssec -status ad.example.com sagt dir, wo jeder Schlüssel in seiner Lebensdauer ist.\nOb dieser Block auf dem DC oder auf einem eigenen Host läuft, ist eine Frage, auf welche Adresse primaries zeigt. Auf dem DC ist es eine zweite named-Instanz auf einer zweiten Adresse, die von der ersten über das Loopback oder ein Management-Interface transferiert. Das ist, was „BIND mit DLZ kann der Signierer sein“ in der Praxis heißt: dieselbe Software, dieselbe Kiste wenn du willst, aber das Signieren geschieht auf der transferierten Kopie statt auf der DLZ-Zone.\nDer eine betriebliche Haken ist Notify — und er ist auf der DLZ-Seite. ISCs Handbuch ist darüber unverblümt: DLZ „has no built-in support for DNS notify“, also werden Secondary-Server nicht automatisch über Änderungen an den Zonen in der Datenbank informiert. Samba kann einen Eintrag im Verzeichnis ändern, und die DLZ-Instanz hat keine Ahnung, dass sie es jemandem sagen sollte.\nDer erste Hop ist also ein Poll, kein Push. Der Signierer aktualisiert auf dem SOA-Timer der Zone, die er transferiert, was heißt:\nDie Propagierung von einer DC-Änderung zu einem signierten, veröffentlichten Eintrag ist durch dieses Refresh-Intervall begrenzt, nicht durch Sekunden. Stufe einen DC herauf, und seine neuen _msdcs-Einträge erscheinen nachgelagert bis zu einem Refresh später. Dieses Intervall ist der Regler, den man dreht, wenn die Verzögerung zählt. Es ist ein Handel gegen die Frage, wie oft du das DLZ abgefragt haben willst, was das andere Ding aufbringt, das ISC über DLZ sagt: es macht Echtzeit-Datenbank-Lookups ohne Caching und ist „not recommended for use on high-volume servers“. Beide davon sind Argumente für diese Topologie statt gegen sie. Der einzige Client, den die DLZ-Instanz je hat, ist der Signierer, der einmal pro Refresh fragt. Die tatsächliche Abfragelast der Umgebung landet auf den eigenständigen autoritativen Servern, die eine einfache signierte Zonendatei mit voller Geschwindigkeit bereitstellen. Alles nachgelagert vom Signierer ist konventionell: die autoritativen Server sind Secondaries der signierten Zone, sie bekommen ein ordentliches notify, und sie berühren nie das Verzeichnis oder einen Schlüssel.\nClients dürfen die Zone mit den Locators nicht schreiben Das ist die wichtige, und es ist eine Design-Regel statt einer Einstellung.\nActive Directory registriert Einträge dynamisch. Eine Maschine tritt bei, und sie registriert sich selbst; ein DC startet, und er registriert die SRV-Einträge, die seine Dienste bewerben. „Sicheres“ dynamisches Update heißt, dass diese Updates beglaubigt sind — die Maschine beweist mit ihren eigenen Anmeldedaten, dass sie ist, wer sie zu sein behauptet, und es gibt eine Per-Eintrag-ACL, sodass eine Maschine im Allgemeinen nur einen Eintrag ändern kann, den sie erstellt hat.\nLies das sorgfältig, denn die Garantie ist enger, als es zuerst scheint. Sicheres dynamisches Update beglaubigt, wer schreibt. Es bewertet nicht, was der Eintrag bedeutet. Und der Satz der Konten, die schreiben dürfen, ist weit breiter, als Leute annehmen: in einer Standard-AD-integrierten Zone hält die Gruppe Authenticated Users Create All Child Objects auf dem Zonen-Container im Verzeichnis, weil ADIDNS jeden Eintrag als AD-Objekt unter CN=MicrosoftDNS,DC=DomainDnsZones speichert. Nicht nur Maschinenkonten — jedes beglaubigte Konto in der Domäne, einschließlich desjenigen, das dem gehört, der heute Morgen den Rechnungsanhang geöffnet hat.\nWas zwei Fehlermodi in einer Zone erzeugt, die sowohl Client-Einträge als auch Dienst-Locators hält:\nNamen, die noch nicht existieren, gehören niemandem. Per-Eintrag-ACLs schützen einen Eintrag, der bereits einen Besitzer hat. Ein Name, der nie registriert wurde, hat kein Objekt, auf dem eine ACL durchzusetzen ist, also bekommt ihn das erste Konto, das ihn erstellt. Das ist der Mechanismus hinter der ganzen Familie von ADIDNS-Angriffen, wobei der schärfste ein Wildcard ist: erstelle *, und jeder Name in der Zone, den niemand ausdrücklich beansprucht hat — Tippfehler, ausgemusterte Hosts, wpad — löst auf den Angreifer auf. Bestehende Einträge bleiben unberührt, was genau ist, warum es unbemerkt bleibt.\nDer Blast Radius schließt die Locators ein. Die Einträge unter _msdcs sind, wie jeder Client in der Domäne einen Domänencontroller und einen KDC findet. Sie sind die sicherheitskritischsten Einträge, die du besitzt, und in einem Standard-Deployment sitzen sie in derselben Zone, in die vierhundert Laptops jedes Mal schreiben, wenn sie ein DHCP-Lease bekommen.\nWer welche Zone schreiben darf: eine kombinierte Zone gegen eine Trennung nach Schreiber Standard \u0026#8212; eine Zone ad.example.com Locators und Client-Einträge zusammen _ldap._tcp.dc._msdcs. SRV _kerberos._udp SRV dc01 A laptop-042 A * A \u0026#8592; nicht beansprucht ein Name, den niemand registriert hat, hat keine ACL zum Durchsetzen jede beigetretene Maschine darf alles davon schreiben Ein kompromittiertes Maschinenkonto kann die Einträge umschreiben, die einen Domänencontroller lokalisieren. Getrennt nach Schreiber ad.example.com \u0026#8212; nur DCs kein Client hat einen Update-Pfad in diese Zone _ldap._tcp.dc._msdcs. SRV _kerberos._udp SRV dc01 A NS-Delegierung dyn.ad.example.com oder eine separate Samba-Zone mit eigener ACL laptop-042 A jede beigetretene Maschine darf schreiben kein Weg zu den Locators Wer was schreiben darf. Links, eine Zone, und jede beigetretene Maschine ist ein autorisierter Schreiber in der Zone, die die DC-Locators hält. Rechts wird die AD-Zone nur von DCs geschrieben, und Client-Registrierungen landen in einer separaten Sub-Zone, wo das Schlimmste, das eine kompromittierte Maschine tun kann, ist, über sich selbst zu lügen. Also die Regel: die Zone, die die Locators hält, wird von Domänencontrollern geschrieben, und von nichts sonst. Dynamische Client-Registrierung geht woandershin.\nWoandershin kann eins von zwei Dingen sein, und beide sind in Ordnung:\nEine delegierte Sub-Zone, anderswo bereitgestellt. Die AD-Zone hält eine NS-Delegierung für, sagen wir, dyn.ad.example.com, und die Einträge landen auf einem separaten Server, der die Updates annimmt. Sambas Partitionen nehmen gar keinen Client-Schreibzugriff an. Eine separate Zone in Samba mit eigener Update-ACL. Immer noch im Verzeichnis, aber ihre eigene Zone, sodass ein Client-Schreibzugriff keinen Weg zu _msdcs oder zu den eigenen Einträgen eines DC hat. Das erste gibt die härtere Trennung; das zweite ist weniger zu betreiben. Was die Regel bricht, ist keins von beiden. Es ist die Voreinstellung, wo die zwei zusammenleben. Was ist, wie die meisten Domänen immer noch laufen, weil niemand es gewählt hat und niemand zurückgegangen ist, um nachzusehen.\nUnd es gibt eine zweite Dividende, die, die das zurück an die Pipeline bindet. Eine Zone, die nur Domänencontroller schreiben, ist eine Zone, die sich kaum je ändert: eine DC-Heraufstufung, eine DC-Herunterstufung, und ansonsten Stille. Aller Churn in einer Standard-AD-Zone ist Client-Registrierung. Nimm die heraus, und der Einwand gegen das Signieren der AD-Partitionen geht mit ihr — es gibt keinen Strom von Updates, den die Signaturen jagen müssten, also ist es zu signieren Routine statt ein Kampf. Die Schreibdisziplin und das Signieren sind dieselbe Entscheidung, zweimal gesehen.\nNeben einem von beiden gibt es eine Berechtigung, die man sich ansehen sollte — und auf einem Microsoft-DC ist sie die direkte Behebung. Weil ADIDNS-Einträge Verzeichnisobjekte sind, kommt die Berechtigung aus einer AD-ACL statt aus irgendetwas im DNS-Protokoll: Authenticated Users, die Create All Child Objects auf dem Zonen-Container halten. Das zu straffen ist die sauberste Minderung für das Problem unbeanspruchter Namen und Wildcards, und in vielen Umgebungen kann die Berechtigung ganz entfernt werden, sobald du weißt, was sich tatsächlich selbst registrieren muss. Sambas AD-DNS speichert seine Einträge auf dieselbe Weise im Verzeichnis, also gilt dieselbe Frage — geh und sieh dir an, was dein Zonen-Container tatsächlich gewährt.\nAber Moment — sollten Clients 2026 überhaupt registrieren? Alles oben nimmt an, dynamisches Client-Update sei etwas, das du brauchst und sicher zu machen versuchst. Bevor du das akzeptierst, lohnt es sich, die Frage zu stellen, die niemand stellt, denn die Antwort hat sich geändert, seit dieses Verhalten entworfen wurde.\nDynamische DNS-Registrierung wurde für einen Desktop gebaut. Eine Kiste unter einem Schreibtisch, ein Netzwerkkabel, eine Adresse, die sie jahrelang behielt. In dieser Welt war eine Maschine, die ihren eigenen Namen registrierte, ordentlich und im Grunde wahr.\nJetzt sieh, was ein Client 2026 ist. Er wacht im Heim-WLAN auf. Er kommt ins Büro und tritt dem Firmen-WLAN bei. Er geht in eine Dockingstation und greift zusätzlich eine kabelgebundene Adresse ab. Jemand startet das VPN, und ein Tunnel-Adapter erscheint mit einer dritten Adresse. Sie gehen in ein Café, tethern an ein Telefon, und das VPN kommt auf einer vierten zurück. Das ist eine Maschine, ein Name und ein halbes Dutzend Adressen an einem Arbeitstag — und standardmäßig wird er eine gute Zahl davon zu registrieren versuchen.\nDie Zone füllt sich also mit Behauptungen, die einmal wahr waren.\nWindows registriert jeden Adapter, den es hat, es sei denn, jemand ist herumgegangen und hat Adressen dieser Verbindung in DNS registrieren pro Interface abgehakt. Ein gedockter Laptop im VPN ist eine Maschine mit drei aktiven Adaptern und einer Meinung über alle. Mehrere A-Einträge für einen Namen sind kein Fehlerzustand, es ist das normale Ergebnis. Eine Abfrage gibt sie alle zurück, Clients versuchen sie in beliebiger Reihenfolge, und Verbindungen zu diesem Namen scheitern im Verhältnis dazu, wie viele der Adressen tot sind. Das ist der Mechanismus hinter „Fernwartung kann die Maschine in der einen Minute sehen und in der nächsten nicht“. VPN-Adressen sind die schlimmsten davon, denn eine Tunneladresse ist eine Stunde lang gültig, und der Eintrag überlebt sie. Der Tunnel bricht ab, die Pool-Adresse geht an jemand anderen, und der Name zeigt jetzt auf einen Kollegen. Dockingstations trüben die Identität selbst. Sofern MAC-Address-Passthrough nicht konfiguriert ist, gehört das Lease der Dockingstation statt dem Laptop, also driften in einer Hot-Desk-Umgebung Namen, Leases und Maschinen täglich auseinander. Und Besitz macht es dauerhaft. Ein Eintrag kann nur von dem Konto aktualisiert werden, das ihn erstellt hat. Wenn ein Eintrag von DHCP unter einem Anmeldedatum erstellt wurde und die Maschine später versucht, ihn unter ihrem eigenen zu aktualisieren, scheitert das Update, leise, und die veraltete Adresse bleibt genau, wo sie ist. Die Aufräum-Geschichte ist auch nicht die Rettung, nach der sie klingt. Samba hat Scavenging seit 4.9, aber es ist standardmäßig aus (dns zone scavenging = yes, mit samba-tool dns zoneoptions --aging=1), und Samba selbst sagt, es „should only be enabled on new zones or new installations“, weil ältere Versionen dynamische Einträge als statisch und statische als dynamisch markierten. Auf den Umgebungen, die am ehesten voller Müll sind — denen, die seit Jahren laufen — ist das Werkzeug zum Aufräumen genau das, das anzuschalten man dir abrät. Es hatte auch eine eigene CVE.\nAlso stell die Frage direkt: was verbraucht tatsächlich den A-Eintrag eines Laptops?\nIn den meisten Läden sehr wenig. Benutzer verbinden zu Servern; Server verbinden nicht zu Laptops. Die echten Verbraucher sind Fernwartungs-Tools, RDP zu einer benannten Workstation und Inventar oder Monitoring — und fast all dieses Tooling pflegt sein eigenes Inventar und arbeitet von einem eincheckenden Agenten, weil es sich für mobile Clients ohnehin nie auf DNS verlassen konnte.\nWas nahelegt, die Voreinstellung umzukehren:\nServer und Infrastruktur bekommen Einträge aus dem Provisioning. Mit NetBox und Ansible schon im Bild wird der Eintrag von demselben Ding erstellt, das die Maschine erstellt hat, er ist per Konstruktion korrekt, und er wird entfernt, wenn die Maschine es wird. Der stabile kabelgebundene Bestand kann Einträge von DHCP nehmen, wenn etwas sie tatsächlich braucht, mit einem Anmeldedatum, das sie besitzt, sodass Updates nicht scheitern. Mobile Clients registrieren gar nichts. Sie sind Verbraucher von DNS, keine Veröffentlicher davon. Wenn etwas einen Laptop erreichen muss, braucht es einen Agenten, keinen A-Eintrag. Du landest am selben Ort, an den das Sicherheitsargument dich gestellt hat, aus einer völlig anderen Richtung. Weniger Schreiber heißt eine kleinere ADIDNS-Fläche, eine Zone, die nicht voller abgelaufener Behauptungen ist, und — zurück zur Pipeline — eine Zone, ruhig genug, um sie ohne Nachdenken zu signieren.\nDer Sicherheitsfall sagt, Clients dürfen die Zone mit den Locators nicht schreiben. Der betriebliche Fall fragt, warum sie überhaupt DNS schreiben. 2026, für eine Flotte, die ihre Adresse fünfmal am Tag ändert, ist „tun sie nicht“ eine völlig gute Antwort, und erheblich weniger Arbeit, als ihr Chaos sicher zu machen.\nGetrennte Sichten, und woher das Vertrauen kommt Das letzte Stück bindet die zwei Hälften des Beitrags zusammen.\nEs gibt zwei Sichten auf den Namensraum. Eine öffentliche Zone, ins Internet veröffentlicht, die die Handvoll Namen hält, die die Welt braucht. Und eine interne Sicht — der aus AD abgeleitete Inhalt, jeder beigetretene Host, jeder Dienst-Locator, die Site-Topologie — die die Welt nichts angeht. Dieser Inhalt ist eine Karte der Umgebung, und er sollte von außen unerreichbar und nicht transferierbar sein.\nAber das Vertrauen für die interne Sicht kommt von der öffentlichen Seite, und das ist, was dieses Design besser macht als die übliche interne-DNS-Insel:\nexample.com ist öffentlich und signiert, mit seinem DS im Elternteil und einer Kette zur Root. ad.example.com ist davon delegiert. Der öffentliche Elternteil veröffentlicht die Delegierung und ein DS für den Schlüssel der internen Zone. Die internen autoritativen Server stellen das signierte ad.example.com bereit. Die internen Resolver validieren es — Root → com → example.com → ad.example.com — mit nichts als dem Root Trust Anchor, den sie schon hatten. Kein lokaler Trust Anchor. Keine Insel. Kein von Hand verteilter Schlüssel. Die Daten verlassen nie das Gebäude, und der Validierungspfad ist der gewöhnliche öffentliche. Wenn du einen Resolver hinzufügst, validiert er interne Namen korrekt, ganz ohne DNSSEC-Konfiguration.\nEhrlich über den Handel, denn es gibt einen. Eine Delegierung und ein DS in der öffentlichen Zone zu veröffentlichen heißt, dass die Existenz von ad.example.com und die Namen seiner Nameserver öffentlich sind. Der Inhalt ist es nicht, und ist es nie — aber du hast der Welt gesagt, dass die Zone existiert. Im Gegenzug validiert jeder Resolver, den du besitzt, interne Namen gegen die echte Root. Das ist ein guter Handel für die meisten Umgebungen, und er sollte ein bewusster sein statt eine Überraschung.\nZwei Dinge, die man daneben richtig machen muss:\nHalte die interne Sicht unaufzählbar und nicht transferierbar. allow-transfer auf den internen autoritativen Servern ist für den Signierer und deine eigenen Secondaries, nichts sonst. Und bedenke, dass NSEC-beglaubigte Verweigerung jeden, der die Zone abfragen kann, sie von Ende zu Ende durchlaufen lässt; NSEC3 erhöht diese Kosten, aber die eigentliche Kontrolle ist, dass Außenstehende die Server gar nicht erreichen können. Automatisiere das DS. Ein DS im Elternteil, das aufhört, zum Schlüssel des Kindes zu passen, nimmt die ganze interne Domäne zu SERVFAIL. CDS/CDNSKEY existieren, damit das Kind eine Schlüsseländerung signalisieren kann und der Elternteil sie aufnehmen kann, ohne dass ein Mensch während eines Rollovers einen Eintrag editiert. Wenn die Elternzone bei einem Registrar oder Provider liegt, der es unterstützt, benutze es; wenn nicht, muss die Rollover-Prozedur vor dem ersten Roll aufgeschrieben werden, nicht währenddessen. Windows und Linux dazu bringen, wirklich zu validieren Alles bis hierher ging darum, eine Zone zu veröffentlichen, die verifiziert werden kann. Nichts davon tut irgendetwas, bis etwas auf der Client-Seite darauf besteht, sie zu verifizieren. Eine perfekt signierte Zone und ein Client, der nie eine Signatur prüft, erzeugen genau dieselbe Erfahrung wie eine unsignierte Zone, bis zu dem Tag, an dem sie es nicht tun.\nEs gibt nur zwei Orte, an denen Validierung geschehen kann, und der Unterschied zwischen ihnen ist der Unterschied zwischen einer Sicherheitskontrolle und einem höflichen Vorschlag.\nAm Resolver validieren und dem AD-Bit vertrauen. Der Client fragt einen Resolver, der Resolver macht die Kryptografie, und er meldet das Ergebnis, indem er ein Bit setzt — AD, Authenticated Data — in der Antwort. Der Client glaubt dem Bit. Das ist das Modell, das Windows benutzt, und es ist nur so stark wie der Pfad zwischen dem Client und dem Resolver, denn alles, was als der Resolver antworten kann, kann dieses Bit setzen.\nAuf dem Client selbst validieren. Die Maschine betreibt ihren eigenen validierenden Resolver, sodass der „Pfad zum Resolver“ ein Loopback-Socket innerhalb der Maschine ist und nichts mehr zu spoofen bleibt. Das ist stärker, und auf Linux ist es völlig erreichbar.\nDie Voreinstellung ist nichts Bevor du irgendetwas konfigurierst, lohnt es sich, zu sehen, was eine gängige Linux-Workstation ab Werk tut. Das ist eine Fedora-44-Maschine, systemd 259, unangetastet:\n$ resolvectl status | head -3 Global Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: stub $ grep options /etc/resolv.conf options edns0 trust-ad $ dig +dnssec cloudflare.com A | grep flags ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 Lies die drei zusammen, denn sie erzählen eine kleine Geschichte.\nDer Stub ist mit trust-ad konfiguriert — ihm wurde gesagt, dem AD-Bit zu glauben. systemd-resolved meldet DNSSEC=no/unsupported, validiert also selbst nichts. Und die Antwort für eine signierte Zone kommt mit den Flags qr rd ra und ohne ad zurück — nichts irgendwo in diesem Pfad behauptete, validiert zu haben.\nDas ist keine Fehlkonfiguration. Das ist die Voreinstellung. Einem Client kann gesagt werden, einer Behauptung zu vertrauen, die nichts in der Kette aufstellt. Nichts prüft es. Wert, eine Minute damit zu sitzen, bevor du sonst irgendetwas konfigurierst.\nLinux Drei Optionen, in aufsteigender Reihenfolge, wie wenig du dem Netz vertrauen musst.\n1. systemd-resolved, lokal validierend. Ein Drop-in statt die ausgelieferte Datei zu editieren:\n# /etc/systemd/resolved.conf.d/dnssec.conf [Resolve] DNSSEC=yes DNSOverTLS=opportunistic Dann systemctl restart systemd-resolved und mit resolvectl status bestätigen, dass die Zeile jetzt DNSSEC=yes liest.\nDie Einstellung, mit der man vorsichtig sein muss, ist die mittlere. DNSSEC=allow-downgrade sieht wie ein vernünftiger Kompromiss aus und ist keine Sicherheitskontrolle — resolved.conf(5) sagt es selbst:\nNote that this mode makes DNSSEC validation vulnerable to \u0026ldquo;downgrade\u0026rdquo; attacks, where an attacker might be able to trigger a downgrade to non-DNSSEC mode by synthesizing a DNS response that suggests DNSSEC was not supported.\nEin Angreifer, der Antworten fälschen kann, ist genau der Angreifer, gegen den DNSSEC existiert, also kauft ein Modus, den sie durch das Fälschen einer Antwort abschalten können, dir nichts gegen sie. Es ist yes, oder es ist Dekoration.\n2. Ein echter validierender Resolver auf dem Host. Der Validator von systemd-resolved ist bequem statt gründlich. Wo es zählt, betreibe Unbound oder BIND auf dem Loopback und zeige den Stub darauf:\n# unbound: validate against the root anchor, refuse to be stripped server: module-config: \u0026#34;validator iterator\u0026#34; auto-trust-anchor-file: \u0026#34;/var/lib/unbound/root.key\u0026#34; harden-dnssec-stripped: yes val-permissive-mode: no # the internal zone is reached like any other name — no local anchor needed forward-zone: name: \u0026#34;ad.example.com.\u0026#34; forward-addr: 192.0.2.53 BINDs Äquivalent ist eine Zeile — dnssec-validation auto; — die seine eingebaute Kopie des Root-Anchors benutzt und den Rollover für dich verwaltet.\n3. Umgebungsweit, an den Resolvern, die du schon betreibst. Das sind Stufe vier der Pipeline weiter oben in diesem Beitrag. Validierung geschieht dort, Clients vertrauen dem AD-Bit, und der Hop zwischen ihnen ist das Ding, das du schützen musst — mit DoT, oder mit einem Netz, über das du bereit bist, diese Annahme zu treffen.\nUnd beachte, was in keiner dieser Konfigurationen ist: ein Trust Anchor für die interne Zone. Weil ad.example.com eine Delegierung innerhalb einer öffentlich signierten Zone ist, validiert jede davon interne Namen über die gewöhnliche Kette von der Root. Das ist das Design aus dem vorigen Abschnitt, das sich bezahlt macht. Die Alternative ist, einen lokalen Anchor auf jeden Client und Resolver in der Umgebung zu schieben, und ihn bei jedem Rollover neu zu schieben.\nWindows Das Wichtige zuerst, denn es wird routinemäßig missverstanden: der Windows-DNS-Client validiert kein DNSSEC. Er macht keine Kryptografie, prüft keine Signatur und hält keinen Trust Anchor. Er ist ein Stub-Resolver, und das war er immer.\nWas du tun kannst, ist ihn zwingen, Antworten abzulehnen, die nicht in seinem Namen vom Server validiert wurden. Das ist die Name Resolution Policy Table, und sie ist pro Namensraum statt global:\n# Require validated answers for the internal zone Add-DnsClientNrptRule -Namespace \u0026#34;.ad.example.com\u0026#34; ` -DnsSecEnable -DnsSecValidationRequired # What is actually in force on this machine, including from Group Policy Get-DnsClientNrptPolicy -Effective Get-DnsClientNrptRule Für die Umgebung lebt dasselbe in Group Policy unter Computer Configuration → Policies → Windows Settings → Name Resolution Policy: erstelle eine Regel für den Namensraum, hake die DNSSEC-Option an, und hake die Anforderung an, dass der Client prüft, dass die Daten vom DNS-Server validiert wurden.\nZwei Dinge folgen daraus, und beide zählen.\nEtwas Vorgelagertes muss immer noch das Validieren tun. Die NRPT-Regel bringt den Client dazu, das AD-Bit zu fordern; sie erzeugt keins. Der Resolver, auf den diese Clients zeigen, muss ein validierender Resolver sein, oder jeder Name in diesem Namensraum scheitert.\nUnd deshalb hat die NRPT-Regel IPsec-Optionen daneben. Microsoft hat sie aus dem Grund dorthin gesetzt, der oben in diesem Abschnitt dargelegt wurde: ein Bit zu fordern, das jeder On-Path-Angreifer setzen kann, ist nicht viel von einer Forderung. Wenn du dich in einem nicht vertrauenswürdigen Netz auf das Resolver-validiert-Modell verlässt, muss der letzte Hop geschützt werden — IPsec zwischen Client und Resolver, oder DoT, wo der Resolver es unterstützt.\nEs fällt geschlossen aus, also roll es in dieser Reihenfolge aus Validierung zu erzwingen wandelt eine Klasse stiller Kompromittierung in eine Klasse lauter Ausfälle. Das ist der richtige Handel, und es ist trotzdem ein Ausfall: ein abgelaufenes RRSIG, ein DS im Elternteil, das nach einem Rollover nicht mehr passt, oder ein Resolver, der die Elternzone nicht erreichen kann, erzeugen alle SERVFAIL, und SERVFAIL für _ldap._tcp.dc._msdcs heißt, die Domäne ist unten statt verschlechtert.\nTu es also in dieser Reihenfolge:\nSchalte Validierung zuerst an den Resolvern ein, und lass die Clients in Ruhe. Achte für ein paar Wochen auf SERVFAIL in den Resolver-Logs — hier findest du die Zone, die seit einem Jahr leise kaputt ist. Automatisiere das DS, bevor du irgendetwas erzwingst, wie im vorigen Abschnitt. Die meisten selbstverschuldeten DNSSEC-Ausfälle sind ein Rollover, bei dem der Elternteil nie aktualisiert wurde. Dann erzwinge die Clients, ein Namensraum nach dem anderen, beginnend mit deiner eigenen Workstation und einer Test-OU statt der ganzen Umgebung. Der Fehler, gegen den du planst, ist ein Client, dem ein gefälschter Domänencontroller gereicht wird. Der Fehler, den du riskierst, ist ein Client, dem gar nichts gereicht wird. Der zweite ist behebbar und offensichtlich; der erste ist keins von beiden. Du hörst vom Ausfall innerhalb einer Minute. Vom anderen hättest du überhaupt nie gehört.\nDen letzten Hop verschlüsseln: DoT und DoH auf den internen Resolvern Der Validierungsabschnitt ließ eine Sache offen. Im Resolver-validiert-Modell — dem, das Windows dir gibt — vertraut der Client einem einzigen Bit, das der Resolver setzt, und dieses Bit ist nur den Pfad wert, über den es reiste. Etwas muss diesen Pfad schützen.\nBIND unterstützt beide verschlüsselten Transporte nativ, das ist also ein Konfigurations-Job statt eines Beschaffungs-Jobs:\nDNS over TLS — ein tls-Block, referenziert aus listen-on, üblicherweise auf Port 853. DNS over HTTPS — derselbe tls-Block plus ein http-Block, auf 443. Ausgehendes DoT, denn forwarders nimmt einen TLS-Transport pro Adresse oder für die ganze Liste. Zonentransfers über TLS, denn die primaries-Anweisung einer type secondary-Zone nimmt auch einen — was direkt für die Pipeline weiter oben in diesem Beitrag nützlich ist. Zuerst, sei klar, was das kauft, denn DoT und DNSSEC werden ständig vermischt, und sie sind keine Alternativen. DNSSEC beglaubigt die Daten, den ganzen Weg zurück zur Zone, die sie veröffentlicht hat. DoT schützt das Gespräch mit dem Resolver. Das eine überlebt einen feindlichen Resolver und ein feindliches Netz zwischen Resolvern; das andere hindert die Maschine in deinem WLAN daran, zu lesen und umzuschreiben, was dein Laptop fragte. Du willst beide, und keins ersetzt das andere. Den Hop zu einem Resolver zu verschlüsseln, der nicht validiert, ist ein privates Gespräch mit etwas, das immer noch angelogen werden kann.\nEs bereitstellen tls internal-resolver { key-file \u0026#34;/etc/pki/dns/resolver.key\u0026#34;; cert-file \u0026#34;/etc/pki/dns/resolver.pem\u0026#34;; protocols { TLSv1.3; }; }; http internal-doh { endpoints { \u0026#34;/dns-query\u0026#34;; }; }; options { dnssec-validation auto; listen-on port 53 { 192.0.2.53; }; listen-on port 853 tls internal-resolver { 192.0.2.53; }; listen-on port 443 tls internal-resolver http internal-doh { 192.0.2.53; }; listen-on-v6 port 853 tls internal-resolver { 2001:db8::53; }; }; Das Zertifikat ist die eigentliche Arbeit, und es ist der Teil, der übersprungen wird. Ein Client, der verifiziert — was der ganze Sinn ist — braucht ein Zertifikat, das für den Namen gültig ist, mit dem er konfiguriert wurde, ausgestellt von etwas, dem er bereits vertraut. Das heißt deine interne CA und deine bestehende Zertifikatsautomatisierung, nicht das ephemeral-Schlüsselwort. ephemeral erzeugt ein Wegwerf-Self-Signed-Zertifikat; es ist da, damit du beweisen kannst, dass der Listener funktioniert, und es ist für jeden Client, der tatsächlich prüft, wertlos.\nDarüber weiterleiten Wenn diese Resolver irgendwohin weiterleiten, statt den Baum selbst zu laufen, kann der vorgelagerte Hop auch verschlüsselt werden — und hier ist eine Unterscheidung wert, sie richtig zu machen:\ntls upstream { ca-file \u0026#34;/etc/pki/tls/certs/ca-bundle.crt\u0026#34;; remote-hostname \u0026#34;dns.example.net\u0026#34;; }; options { forwarders port 853 tls upstream { 192.0.2.1; }; }; Ohne remote-hostname bekommst du Verschlüsselung ohne Authentifizierung: der Verkehr ist für einen passiven Beobachter unlesbar, und ein aktiver Angreifer, der die Verbindung abfangen kann, präsentiert einfach sein eigenes Zertifikat. Mit remote-hostname und ca-file verifiziert BIND, mit wem es spricht. Das erste ist etwas wert. Nur das zweite ist es wert, eine Kontrolle genannt zu werden.\nDie Client-Hälfte ist nicht symmetrisch Hier wird eine gemischte Umgebung heikel, und es ist der Grund, beide Transporte zu konfigurieren statt einen zu wählen.\nLinux macht DoT ordentlich. systemd-resolved nimmt DNSOverTLS=yes für den strikten Modus, und dem Server kann der Name gegeben werden, gegen den zu verifizieren ist:\n[Resolve] DNS=192.0.2.53#resolver.ad.example.com DNSOverTLS=yes DNSSEC=yes Wie bei DNSSEC= ist die mittlere Einstellung die Falle: DNSOverTLS=opportunistic fällt auf Klartext zurück, wenn TLS nicht verfügbar ist, was ein Angreifer, der in die Verbindung eingreifen kann, arrangieren kann.\nWindows macht DoH, und nicht DoT. Client-DoH-Unterstützung kam in Windows 11 und Server 2022, pro Server mit einem Template konfiguriert:\n$doh = \u0026#34;https://resolver.ad.example.com/dns-query\u0026#34; netsh dnsclient add encryption server=192.0.2.53 dohtemplate=$doh DoT ist, zum Zeitpunkt des Schreibens, nur in Insider-Builds aufgetaucht. Auf freigegebenem Windows ist die verschlüsselte Option also DoH oder nichts, was genau ist, warum der NRPT-Abschnitt weiter oben stattdessen zu IPsec griff.\nDaher beide aus derselben BIND-Instanz bereitstellen. DoT für die Linux-Flotte und alles andere, das es spricht, DoH für Windows, ein Resolver, ein Zertifikat.\nWelches, wo Für einen internen Resolver ist DoT der bessere Transport und DoH die Kompatibilitätsantwort.\nDoT sitzt auf einem eigenen Port. Du kannst es sehen, erlauben, verweigern und auf alles alarmieren, das DNS macht und es nicht so macht. DoHs Vorteil — von gewöhnlichem Web-Verkehr auf 443 nicht zu unterscheiden — ist ein echter Nutzen in einem feindlichen Netz und ein Ärgernis in deinem eigenen, wo unterscheiden zu können, was DNS ist, ein Feature ist, für das du bezahlt hast. In der Umgebung, die du kontrollierst, bevorzuge den Transport, den du beobachten kannst, und betreibe DoH, weil Windows dir keine Wahl lässt, statt weil es besser ist.\nWenn du schon dabei bist: verschlüssele die Transfers Die Pipeline weiter oben in diesem Beitrag bewegt die AD-Zone per AXFR, und der Getrennte-Sichten-Abschnitt machte den Punkt, dass ihr Inhalt eine Karte der Umgebung ist. TSIG beglaubigt diese Transfers; es verbirgt sie nicht. Da die primaries-Anweisung einer Secondary eine TLS-Konfiguration annimmt, kann der Transfer auch über TLS laufen — RFC 9103, wenn du den Standard willst:\nzone \u0026#34;ad.example.com\u0026#34; { type secondary; primaries { 192.0.2.10 port 853 tls xfr-tls key transfer-to-signer; }; ... }; Vom Schlüssel beglaubigt, vom Transport verschlüsselt. Wenn irgendein Hop in dieser Pipeline eine Standortverbindung kreuzt, einen Hypervisor, den du teilst, oder irgendetwas, worauf du nicht gern einen Hub setzen würdest, ist es die zwanzig Minuten wert.\nWas es nicht behebt Es ist keine Validierung. Oben behandelt, und wert, wiederholt zu werden, weil Hersteller „sicheres DNS“ verkaufen und Verschlüsselung allein meinen. Es verbirgt nichts vor dem Resolver. Der Resolver sieht jede Abfrage vollständig. Verschlüsselung schützt den Pfad, nicht die Privatsphäre der Abfrage vor dem Betreiber — was in Ordnung ist, wenn der Betreiber du bist. Es tut nichts für einen Client, der das Zertifikat nicht verifiziert, und opportunistische Modi sind von genau dem Angreifer downgradebar, um den du dir Sorgen machst. Und es ist kein Grund, einen Listener auf den Domänencontroller zu stellen. Verschlüsseltes DNS auf dem DC würde das falsche Problem wunderschön lösen. Der DC antwortet immer noch niemandem. Wie du prüfst, was du hast Befehle zum Laufen gegen deine eigene Umgebung. Die Ausgaben sind der interessante Teil, und ein paar davon sind beim ersten Mal unbequeme Lektüre.\n# Walk the tree yourself, one delegation at a time dig +trace dc01.ad.example.com # Validate, and show the chain being built delv +rtrace +vtrace ad.example.com SOA # Is the resolver you are pointed at actually validating? # A deliberately broken test name must come back SERVFAIL, not an address dig @\u0026lt;resolver\u0026gt; dnssec-failed.org A # What does the estate advertise as a domain controller? dig SRV _ldap._tcp.dc._msdcs.\u0026lt;domain\u0026gt; dig SRV _kerberos._udp.\u0026lt;domain\u0026gt; # Is a DC answering for names it has no business answering? # Ask it for something it is not authoritative for. \u0026#34;recursion requested # but not available\u0026#34; is the answer you want. An actual address means it is # serving the estate — recursing if it is BIND, relaying to the forwarder # if it is SAMBA_INTERNAL. Either way it should not be doing that. dig @\u0026lt;dc\u0026gt; www.example.org A # Is the DC configured as the estate\u0026#39;s DNS relay? grep -E \u0026#39;dns forwarder|server services\u0026#39; /etc/samba/smb.conf # Will a DC hand its zone to anybody who asks? dig @\u0026lt;dc\u0026gt; AXFR ad.example.com # Which backend is this DC running, and does named have the module? grep -r dlz /etc/named.conf /var/lib/samba/bind-dns/ 2\u0026gt;/dev/null samba-tool dns query \u0026lt;dc\u0026gt; \u0026lt;domain\u0026gt; @ ALL # Is the internal zone chained to the public parent? dig DS ad.example.com @\u0026lt;public-authoritative-for-example.com\u0026gt; # What does the local stub actually do with the AD bit, and is the # hop to the resolver encrypted? resolvectl status # DNSSEC= and DNSOverTLS= per link grep options /etc/resolv.conf # trust-ad, trusting whom exactly? # Did anything in the path claim to have validated? Look for \u0026#34;ad\u0026#34; in the flags dig +dnssec ad.example.com SOA | grep flags # Validate independently of whatever the local resolver believes delv ad.example.com SOA # \u0026#34;fully validated\u0026#34; is the line you want # Is the resolver actually listening for DoT, and does its certificate # match the name clients are configured with? kdig +tls @192.0.2.53 ad.example.com SOA openssl s_client -connect 192.0.2.53:853 \\ -servername resolver.ad.example.com \u0026lt;/dev/null 2\u0026gt;/dev/null \\ | openssl x509 -noout -subject -dates Und auf einem Windows-Client, um zu sehen, ob er überhaupt irgendetwas fordert:\nGet-DnsClientNrptPolicy -Effective # the rules actually in force Resolve-DnsName ad.example.com -DnssecOk Get-DnsClientDohServerAddress # is the hop to the resolver encrypted? Die zwei, die am häufigsten eine Überraschung erzeugen, sind der Rekursions-Check und der AXFR-Versuch. Wenn ein DC einen davon für einen beliebigen Client beantwortet, ist die Pipeline in diesem Beitrag nicht vorhanden, was auch immer das Diagramm im Wiki sagt.\nDer dritte ist resolvectl status auf einer Maschine, die niemand angefasst hat. DNSSEC=no/unsupported neben trust-ad in resolv.conf ist der Normalzustand eines Linux-Desktops, und es heißt, die oben beschriebene Signier-Arbeit wird derzeit von niemandem geprüft.\nDie Kurzfassung Ein Resolver kommt zur Welt und kennt die Root-Server und einen Schlüssel und lernt alles andere, indem ihm gesagt wird. Namen werden durch das Laufen von Delegierungen hinunter gefunden, und Dienste werden durch das Fragen nach einem SRV-Eintrag gefunden — also kam, wenn ein Client anfängt, Kerberos mit einem Domänencontroller zu machen, die Identität dieses Domänencontrollers aus einer DNS-Antwort. Entdeckung per DNS ist korrekt und in Ordnung. Autorisierung per DNS ist es nicht, und eine überraschende Menge Infrastruktur tut es trotzdem leise.\nDNSSEC ist, was diese Antworten überprüfbar macht: Signaturen auf jedem Satz, ein DS in jedem Elternteil, eine Kette zu einem einzigen Trust Anchor an der Root, und beglaubigte Verweigerung, sodass ein Name nicht zum Verschwinden gebracht werden kann. Es kauft Herkunftsauthentifizierung und Integrität — nicht Privatsphäre, und nicht Korrektheit. Es signiert, was auch immer die Zone sagt, weshalb es eine Zone nicht retten kann, die nicht vertrauenswürdige Maschinen schreiben dürfen. Und es braucht einen Elternteil: eine erfundene interne TLD hat nirgends ein DS unterzubringen, also lassen .local, .lan, .internal und home.arpa dich alle entweder unsigniert oder eine private Insel von Hand verteilter Schlüssel betreibend.\nFür eine Active-Directory-Domäne erzeugt das ein Design statt einer Liste von Einstellungen. Benutze eine Delegierung innerhalb einer öffentlichen Zone, die du besitzt, sodass das Vertrauen die gewöhnliche Kette von der Root herunterkommt, während die Daten nie herausgehen. Stelle die AD-Partitionen mit BIND und dlz_bind9 bereit — DLZ ist nicht das Risiko, es ist, wie du die Zone aus dem Verzeichnis bekommst — und lass den DC ein Hidden Primary sein, der hinaustransferiert und niemandem sonst antwortet. Eine DLZ-Zone kann nicht selbst signiert werden, also ist das Signieren eine normale Secondary-Zone, die die transferierte Kopie hält, mit inline-signing und einer dnssec-policy darauf: ein zweites named auf dem DC, wenn du weniger Maschinen willst, ein separater Host, wenn du private Schlüssel vom Verzeichnis fernhalten willst. So oder so wird es einmal signiert, an einem definierten Punkt, unter einer Schlüsselrichtlinie — und der erste Hop ist ein Poll statt eines Push, weil DLZ kein Notify senden kann. Veröffentliche von eigenständigen autoritativen Servern, die keine Schlüssel halten und keinen Weg zum Verzeichnis haben.\nUnd halte Clients aus der Zone, die zählt. Sicheres dynamisches Update beglaubigt den Schreiber, nicht die Bedeutung, und in einer Standard-AD-integrierten Zone sind die Schreiber Authenticated Users — jedes Konto, nicht nur jede Maschine — also ist eine Zone, die sowohl Laptop-Einträge als auch _msdcs-Locators hält, einen gephishten Benutzer davon entfernt, dass einem Client mit einer völlig gültigen Signatur gesagt wird, der Domänencontroller sei woanders. Client-Registrierungen gehören in eine Sub-Zone, delegiert oder separat in Samba, wo das Schlimmste, das ein kompromittiertes Konto tun kann, ist, über sich selbst zu lügen.\nWobei die bessere Frage ist, ob Clients überhaupt registrieren sollten. Ein 2026er Laptop hat eine Adresse im Heim-WLAN, eine andere im Büro-WLAN, eine andere über die Dockingstation und eine andere im VPN, und er wird die meisten davon fröhlich veröffentlichen. Was den A-Eintrag eines Laptops verbraucht, ist fast nichts — die Werkzeuge, die eine Workstation erreichen müssen, halten ihr eigenes Inventar, weil DNS für mobile Clients ohnehin nie zuverlässig war. Einträge für Server sollten aus dem Provisioning kommen, und die Flotte sollte nichts registrieren.\nDann bring etwas dazu, die Signaturen zu prüfen, denn nichts vom Obigen ist etwas wert, bis ein Client eine Antwort ablehnt. Auf Linux heißt das DNSSEC=yes in systemd-resolved, oder ein echter validierender Resolver auf dem Loopback — niemals allow-downgrade, das ein Angreifer, der Antworten fälschen kann, einfach durch das Fälschen einer Antwort abschalten kann. Auf Windows heißt es zu akzeptieren, dass der DNS-Client selbst nie irgendetwas validiert, und eine NRPT-Regel zu benutzen, um ihn eine Antwort fordern zu lassen, die der Resolver validiert hat, mit geschütztem letztem Hop, weil diese Forderung ein einziges Bit ist. Schalte es zuerst an den Resolvern ein und achte auf SERVFAIL, automatisiere das DS, dann erzwinge die Clients. Es fällt geschlossen aus, was die richtige Richtung ist und trotzdem ein Ausfall.\nNichts davon ist exotisch. Es ist Delegierung, Transfer und Signieren — die drei Dinge, die DNS immer getan hat — so angeordnet, dass die Maschine, die dein Verzeichnis hält, nicht die Maschine ist, die Fragen vom Parkplatz annimmt, und dass, wenn etwas einen Client anlügt, der Client es bemerkt.\n","permalink":"https://blogs.damiendye.uk/de/dns/samba4-securing-ad-records-with-dnssec/","summary":"Jede domänenverbundene Maschine findet ihren Domänencontroller, indem sie DNS nach einem SRV-Eintrag fragt, also sind die _msdcs-Locators die sicherheitskritischsten Einträge, die du besitzt. So veröffentlichst und signierst du sie richtig von einem Samba4-DC: BIND mit dlz_bind9, das das Verzeichnis liest, Inline-Signing, ein Hidden Primary, den Clients nie erreichen, und dynamische Client-Updates aus der Zone herausgehalten, die die Locators hält. Dann, wie du Windows- und Linux-Clients zwingst, die Signaturen wirklich zu prüfen, denn eine signierte Zone, die niemand validiert, verhält sich genau wie eine unsignierte.","title":"Samba4 und das Sichern von AD-Einträgen mit DNSSEC"},{"content":"Der Schacht, der alles aufnimmt Der Verkaufsspruch für einen Tri-Mode-Adapter ist wirklich gut, und man sollte ihn richtig aussprechen, bevor man ihn auseinandernimmt.\nKauf ein Gehäuse mit U.3-Backplane und einem Tri-Mode-Controller, und jeder Laufwerksschacht wird universell. Schacht 0 kann eine 24G-SAS-Platte halten, Schacht 1 ein billiges SATA-Startlaufwerk, Schacht 2 eine Gen4-NVMe-SSD, und der Adapter verhandelt, was auch auftaucht. Broadcom nennt das Silizium Tri-Mode SerDes; der Schachtstandard ist SFF-TA-1001, bekannt als U.3, der einen gemeinsamen Steckverbinder für SAS x1/x2, SATA und NVMe mit x1, x2 oder x4 festlegt. Die Verwaltungsseite ist SFF-TA-1005, Universal Backplane Management, und damit findet das Gehäuse heraus, mit was es eigentlich spricht, und treibt die richtigen Aktivitäts-LEDs.\nFür jeden, der Server ausschreibt, löst das ein echtes und ärgerliches Problem. Du musst das Speicherprotokoll nicht länger zum Zeitpunkt der Bestellung festlegen, keine zwei Gehäusevarianten führen und nicht entdecken, dass die NVMe-fähigen Schächte die vier links sind und deine Platten in die anderen zwanzig gewandert sind. Eine Teilenummer deckt den Bestand, und ein SAS-Bestand kann Platte für Platte auf NVMe umziehen statt Gehäuse für Gehäuse.\nNichts davon ist Marketing. Es ist der Grund, warum diese Adapter sich verkaufen, und es wäre albern, etwas anderes zu behaupten.\nAber die Flexibilität ist nicht kostenlos, und die Rechnung wird nicht in Pfund bezahlt. Sie wird in Queues bezahlt.\nWas mit der Platte tatsächlich passiert Eine NVMe-SSD ist ein PCIe-Endpunkt. In einem direkt verbundenen Server laufen ihre vier Lanes zum Root Complex der CPU — über einen Retimer oder einen PCIe-Switch, aber elektrisch und logisch ist sie ein Gerät am PCIe-Bus. Der Kernel zählt sie auf, bindet den nvme-Treiber, und ab da spricht der Treiber direkt mit den Registern der Platte.\nSteck dieselbe Platte hinter einen Tri-Mode-Adapter, und das stimmt nicht mehr.\nDie Lanes der Platte enden jetzt am Controller. Broadcoms Dokumentation nennt den zuständigen Block die PCIe device bridge, und das Wort Brücke leistet viel Arbeit: das ist kein durchlässiger Switch, der die Transaktionen deiner CPU an eine Platte weitergibt, die sie noch sehen kann. Der Adapter ist der PCIe-Endpunkt, den dein Host aufzählt. Die Platte ist ein Target auf der anderen Seite, und die Firmware des Controllers setzt jedes I/O neu auf.\nDirekt verbundenes NVMe gegen dieselben Platten hinter einem Tri-Mode-Adapter Direkt verbunden Hinter einem Tri-Mode-Adapter CPU-Root-Complex CPU-Root-Complex x4 x4 x4 x4 vier eigene Verbindungen etwa 7 GB/s je, parallel x8 Gen4 alles darunter teilt das Tri-Mode-Controller der einzige PCIe-Endpunkt, den der Host aufzählt NVMe NVMe NVMe NVMe nvme0n1 nvme1n1 nvme2n1 nvme3n1 NVMe NVMe NVMe NVMe sda sdb sdc sdd nvme-Treiber ein Queue-Paar je CPU-Kern, je Platte Bandbreite wächst mit jeder Platte mpt3sas-Treiber \u0026#8212; die Platten sind SCSI-Targets Queue-Tiefe 128 je, ein Tag-Pool zwischen ihnen Bandbreite endet am Adapter Dieselben vier Platten, zweimal verkabelt. Links besitzt jede Platte vier Lanes zum Root Complex. Rechts enden die Lanes am Adapter, und alles dahinter teilt einen x8-Uplink und einen Controller. Der Adapter gibt deine NVMe-Befehle also nicht durch. Er beendet sie und spricht in deinem Namen mit der Platte.\nWas die Frage aufwirft, welches Protokoll er mit dir spricht.\nDas Betriebssystem sieht nie eine NVMe-Platte Es spricht SCSI.\nSteck eine NVMe-SSD in einen Broadcom-Tri-Mode-HBA, und sie erscheint nicht als /dev/nvme0n1. Sie erscheint als /dev/sdb, gebunden an mpt3sas — denselben Treiber, der seit über einem Jahrzehnt LSI-SAS-Controller fährt. nvme list gibt nichts zurück. lsblk -o NAME,TRAN meldet den Transport als sas. Für jede Schicht des Speicherstapels über dem Treiber hast du eine SAS-Platte gekauft.\nDas ist kein Fehler und keine Firmware-Grenze, die auf Behebung wartet. Es ist der Entwurf. Alles als SCSI-Target zu zeigen ist genau wie ein Adapter drei Protokolle bedient: der Controller vereinheitlicht SAS, SATA und NVMe zu einem einzigen Gerätemodell, und der Host bekommt einen Treiber, einen Aufzählungsweg, einen Satz Werkzeuge. Die Flexibilität im Marketing und die SCSI-Darstellung in dmesg sind dieselbe Architekturentscheidung, von beiden Enden angesehen.\nDie Generationen 9500 und 9600 bringen einen Passthrough-Mechanismus mit, damit Hersteller-Werkzeuge die NVMe-Admin-Befehle einer Platte erreichen, und Broadcoms neuere Teile sind viel besser darin, Plattengesundheit zu zeigen, als die 9400 war. Aber das ist ein Nebenkanal für die Verwaltung. Der Datenweg — jedes Lesen und Schreiben, das deine Last absetzt — läuft weiter den SCSI-Stapel hinunter.\nUnd der SCSI-Stapel hat ein Queue-Modell, das Flash um zwanzig Jahre vorausgeht.\nDas Queue-Modell, das du gerade aufgegeben hast Das ist der Teil, der dich tatsächlich Leistung kostet, und es ist wert, genau zu sein, denn „NVMe ist schneller als SAS“ ist nicht der Grund.\nDie zentrale Entwurfsentscheidung von NVMe war keine schnellere Leitung. Sie war, nicht mehr vorzugeben, dass ein Speichergerät ein einzelnes serialisiertes Ding ist.\nDie Spezifikation erlaubt bis zu 65.535 I/O-Queue-Paare, und diese Zahl wird in jeder NVMe-Erklärung zitiert. Es ist die falsche Zahl, nach der man greift. Keine Platte setzt annähernd so viele um, jeder, der ein laufendes System tatsächlich angesehen hat, kann den Vergleich also wegwischen — und er hätte recht damit. Die echte Zahl ist kleiner, unspektakulär, und macht den Punkt besser.\nAlso hier eine echte Platte. Kein Unternehmensteil: eine SK-Hynix-OEM-SSD mit 256 GB, die Art, die in einem Mittelklasse-Laptop verlötet ist, in einer Maschine mit 16 Kernen.\n$ nproc 16 $ cat /sys/class/nvme/nvme0/queue_count 17 $ ls /sys/block/nvme0n1/mq | wc -l 16 $ cat /sys/block/nvme0n1/queue/nr_requests 1023 Siebzehn Queues: eine Admin-Queue und sechzehn I/O-Queues für sechzehn Kerne. Jede 1023 Befehle tief. Die Zuordnung ist eins zu eins — jede Hardware-Queue ist an genau eine CPU gebunden:\n$ cd /sys/block/nvme0n1/mq \u0026amp;\u0026amp; grep -H . */cpu_list 0/cpu_list:1 1/cpu_list:9 2/cpu_list:3 3/cpu_list:11 ... Eine CPU je Queue, ganz durch — Hardware-Queue 0 bedient Kern 1 und nichts sonst.\nDas ist es, was „NVMe hat viele Queues“ in der Praxis tatsächlich heißt. Nicht 65.535 — eine je Kern, wie viele Kerne du auch hast. Linux legt ein Queue-Paar je CPU an, bis zu dem, was der Controller gewährt, und Controller gewähren weit mehr, als ein typischer Server Kerne hat, in der Praxis ist die Kernzahl also die Zahl. Steck diese Platte in eine Kiste mit 64 Kernen, und du bekommst 64.\nDiese Aufteilung je Kern ist, woher die Leistung kommt:\nEin Kern reicht in seine eigene Queue ein. Keine Sperre, denn kein anderer Kern fasst sie an. Jede Queue bekommt ihren eigenen MSI-X-Vektor, an diesen Kern gebunden. Der Abschluss-Interrupt landet zurück auf dem Kern, der das I/O abgesetzt hat, wo die zugehörigen Cache-Zeilen schon liegen. Alle sechzehn Kerne können gleichzeitig unterwegs sein, ohne je um eine gemeinsame Struktur zu streiten. Die Parallelität wächst mit deiner Kernzahl, und die Arbeit keines Kerns steht je hinter der eines anderen in der Schlange. Eine billige Consumer-Platte macht das. Es ist das Mindeste.\nSieh jetzt an, was die Platte hinter dem Adapter bekommt. Die Zahlen unten sind keine Schätzungen — sie sind Konstanten im mpt3sas-Treiber im Mainline.\nDie Queue-Tiefe je Gerät wird aus ioc-\u0026gt;max_nvme_qd gesetzt, was der Treiber von dem nimmt, was die Controller-Firmware meldet, und sonst auf eine Voreinstellung zur Kompilierzeit in drivers/scsi/mpt3sas/mpt3sas_base.h zurückfällt:\n#define MPT3SAS_SATA_QUEUE_DEPTH\t32 #define MPT3SAS_SAS_QUEUE_DEPTH\t254 #define MPT3SAS_RAID_QUEUE_DEPTH\t128 #define MPT3SAS_NVME_QUEUE_DEPTH\t128 128. Ein Gerät, das Zehntausende offene Befehle kann, bekommt eine Queue-Tiefe von 128 — und beachte, dass sie flacher ist als die SAS-Voreinstellung von 254 zwei Zeilen darüber. Die eigenen Fähigkeiten der Platte gehen in die Entscheidung nie ein. Die Zahl kommt vom Controller.\nDie Zahl der Hardware-Queues ist schlimmer, und der Treiber ist offen darüber. Aus mpt3sas_scsih.c:\nshost-\u0026gt;nr_hw_queues = 1; if (shost-\u0026gt;host_tagset) { shost-\u0026gt;nr_hw_queues = ioc-\u0026gt;reply_queue_count - ioc-\u0026gt;high_iops_queues; ... dev_info(\u0026amp;ioc-\u0026gt;pdev-\u0026gt;dev, \u0026#34;Max SCSIIO MPT commands: %d shared with nr_hw_queues = %d\\n\u0026#34;, shost-\u0026gt;can_queue, shost-\u0026gt;nr_hw_queues); } Lies das genau, denn drei getrennte Dinge passieren hier.\nDie Voreinstellung ist eine Hardware-Queue. nr_hw_queues = 1. Multi-Queue passiert nur auf gen35-Controllern mit eingeschalteter host_tagset-Funktion, und selbst dann ist es, was die Commit-Geschichte des Treibers selbst als simulierte mehrere Hardware-Queues beschreibt — die Hardware des I/O-Controllers ist eine einzige Submission-Queue mit mehreren Reply-Queues, und blk-mq wird darüber gepasst.\nDie Zahl der Queues kommt vom Controller, nicht von der Kernzahl. Sie ist reply_queue_count minus die High-IOPS-Queues — die MSI-X-Vektorzuteilung des Adapters. Sie hat nichts damit zu tun, wie viele CPUs du hast, und sie wächst nicht, wenn du Platten hinzufügst. Das ist die genaue Umkehrung der Platte oben, wo die Zahl der Queues die Kernzahl war.\nUnd der Tag-Pool ist geteilt. host_tagset heißt genau, was es sagt: ein Tag-Pool für den ganzen Host-Adapter, und diese Protokollzeile sagt „shared“ laut heraus. Jede Platte an der Karte zieht aus demselben Satz Befehlsplätze. Ein Gehäuse mit vierundzwanzig Schächten hat vierundzwanzig Platten, die um die Tags eines Controllers streiten.\nStell die zwei nebeneinander. Diese Laptop-SSD hatte sechzehn eigene Queues von 1023, eine je Kern, die nur ihr selbst antwortete. Dieselbe Platte hinter dem Adapter bekommt einen Anteil an den Reply-Queues der Karte, 128 offene Befehle und dreiundzwanzig Nachbarn, die aus demselben Pool ziehen.\nNVMe-Queue-Paare je Kern gegen einen gemeinsamen Tag-Pool des Adapters Queues vervielfachen sich mit Kernen Platten teilen einen Pool Kern 0 Kern 1 Kern 2 Kern 3 SQ + CQ SQ + CQ SQ + CQ SQ + CQ 1023 tief 1023 tief 1023 tief 1023 tief NVMe SSD /dev/nvme0n1 ein Einreich- und Abschlusspaar je Kern eigener MSI-X-Vektor, Abschlüsse landen auf dem Kern keine Sperre, kein Streit über Kerne Kern 0 Kern 1 Kern 2 Kern 3 Tri-Mode-Controller Reply-Queues kommen aus den MSI-X-Vektoren der Karte, nicht aus deiner Kernzahl ein gemeinsamer Tag-Pool für jede Platte sda sdb sdc sdd qd 128 qd 128 qd 128 qd 128 und 20 weitere Schächte ziehen aus demselben Pool. 128 offene Befehle je Gerät, was die Platte auch kann Platten hinzufügen teilt eine feste Ressource Links: ein Queue-Paar je Kern, eigen und 1023 tief, wobei der Abschluss-Interrupt zurück auf dem einreichenden Kern landet — an der Platte oben gemessen. Rechts: jeder Kern in die Reply-Queues des Controllers getrichtert, aus einem gemeinsamen Tag-Pool ziehend, jede Platte bei 128 gedeckelt. Der Verlust ist also nicht, dass SCSI langsam ist. Modernes SCSI auf blk-mq ist in Ordnung. Der Verlust ist strukturell:\nQueues gehören dem Adapter, nicht der Platte. Platten hinzuzufügen teilt eine feste Ressource statt sie zu vermehren. Der Tag-Pool ist über den ganzen Host geteilt. Eine Platte unter schwerer Last kann die anderen aushungern, und zwar auf eine Weise, die einfach nicht passieren kann, wenn jede Platte ihre eigenen Queues hat. Die Tiefe je Gerät ist bei 128 gedeckelt, egal was die Platte durchhalten kann. Die Interrupt-Nähe ist geschwächt. Abschlüsse kommen auf der Reply-Queue an, die der Controller genutzt hat, nicht unbedingt auf dem Kern, der eingereicht hat. Bei einer Queue-Tiefe von 1 oder 2 — ein einzelner Prozess, der gelegentlich liest — merkt man nichts davon. Du wirst so oder so dieselbe Latenz messen, im Rauschen. Der Preis erscheint genau dort, wo du NVMe gekauft hast, um zu helfen: viele Kerne, die viele gleichzeitige I/Os absetzen. Je tiefer die Last, desto mehr von der Platte hast du bezahlt und kannst sie nicht erreichen.\nDer Uplink ist ein x8-Steckplatz Das Queue-Modell ist das feine Problem. Die Bandbreitendecke ist das offensichtliche, und du kannst sie aus Broadcoms eigenen Produktblättern ablesen, ohne einen Benchmark zu brauchen.\nDer HBA der 9500-Reihe ist eine x8-PCIe-Gen-4.0-Karte. Broadcoms veröffentlichte Zahlen dafür sind 13.700 MB/s bei sequentiellem Lesen mit 256K und 3 Mio. IOPS bei zufälligem Lesen mit 4K. Dasselbe Blatt sagt, sie unterstütze bis zu 32 NVMe-Geräte.\nStell die zwei Zahlen nebeneinander, und die Frage beantwortet sich selbst: wie viele Platten braucht es, bis der Adapter ausgeht?\nNicht viele, und jedes Jahr weniger. Eine Gen4-x4-SSD macht etwa 7 GB/s. Eine Gen5-x4-SSD macht etwa 14. Beides sind 2026 gewöhnliche Teile — Gen4 ist, wovon der Gebrauchtmarkt für U.2 voll ist, und Gen5 ist, was du neu bekommst.\nDecke Gen4-Platten, um sie zu erreichen Gen5-Platten, um sie zu erreichen HBA 9500 — 13.700 MB/s sequentiell 2 1 HBA 9500 — 3 Mio. IOPS (4K zufällig lesen) 3 1–2 eHBA 9600 — 6,4 Mio. IOPS (4K zufällig lesen) etwa 6 etwa 3 MegaRAID 9600 — 1,1 Mio. RAID-5-IOPS (4K zufällig schreiben) etwa 1 etwa 1 Lies die erste Zeile noch einmal. Eine einzelne Gen5-SSD erreicht die ganze sequentielle Decke eines HBA 9500. Eine Platte, in einer Karte, die für zweiunddreißig ausgelegt ist. Alles danach ist Kapazität. Nicht Leistung.\nUnd die letzte Zeile ist die, die eine Bestellung anhalten sollte: auf dem MegaRAID der aktuellen Generation liefert ein voll bestücktes Regal NVMe in RAID 5 etwa das, was eine gängige Platte allein macht.\nDie Platten verbinden sich nicht einmal mit x4 Es gibt eine zweite Bremse unter dem gemeinsamen Uplink, leicht zu übersehen, weil sie in einer Datentabelle sitzt und nicht in einer Schlagzeile.\nDells Handbuch zum PERC 12, das die H965i-Tri-Mode-Controller abdeckt, sagt:\nSupports drive speeds for NVMe drives are 8 GT/s (Gen 3) and 16 GT/s (Gen 4) at maximum x2 lane width.\nJede NVMe-Platte bekommt zwei Lanes, nicht vier. Vor jedem Streit um den Uplink, vor dem Tag-Pool, vor der SCSI-Übersetzung ist eine Gen4-Platte also schon auf etwa 3,5 GB/s herunter — die Hälfte von dem, was sie kann. Steck eine Gen5-Platte in diesen Schacht, und sie verhandelt auf Gen4 x2 herunter und liefert etwa ein Viertel ihrer angegebenen Bandbreite.\nEs ist wert, genau zu sein, was das ändert und was nicht. Es heißt nicht, dass der Adapter weiter reicht. Es braucht etwa vier auf x2 begrenzte Platten, um den Uplink der 9500 zu füllen, statt zwei, aber nur weil jede Platte halb so viel beiträgt. Der Engpass ist vom Uplink herunter zur Plattenverbindung gewandert. Was du insgesamt herausholen kannst, ist nicht besser geworden.\nDirekt verbunden hätten dieselben zweiunddreißig Platten jede ihren eigenen x4-Weg zum Root Complex, mit der Generation, die Platte und CPU verhandeln können.\nDie RAID-5-Zeile in dieser Tabelle verdient ihren eigenen Blick, denn es ist Broadcoms eigene Zahl, und sie ist ohne Beschönigung veröffentlicht. Aus dem Blatt zur 9600-Reihe:\n900K to 1.1M RAID 5 IOPS (4K RW)\nParitäts-RAID in der Controller-Firmware ist das Teuerste, was man von einer Tri-Mode-Karte verlangen kann, und das ist die aktuelle Generation dabei. Zu lesen wert, bevor jemand RAID 5 über vierundzwanzig NVMe-Platten ausschreibt und die Leistung von vierundzwanzig Platten erwartet.\nPlattenzahl gegen zwei Tri-Mode-Decken, eine x8-Gen4-Karte und eine x16-Gen5-Karte 0 15 30 45 60 75 90 Summe GB/s 1 2 3 4 5 6 NVMe-Platten Gen5 direkt \u0026#8212; etwa 14 GB/s je Gen4 direkt \u0026#8212; etwa 7 GB/s je für beide Karten unerreichbar PERC13, Gen5 x16 \u0026#8212; 52,5 GB/s gemessen HBA 9500, Gen4 x8 \u0026#8212; 13,7 GB/s 2 Gen4-Platten erreichen die 9500 \u0026#8212; 4 Gen5-Platten erreichen selbst eine PERC13 Zahlen von Herstellern und Tests, hier nicht gemessen. Die 9500 ist für 32 NVMe-Geräte ausgelegt, die PERC13 für 16. Beide Karten verbinden jede Platte zusätzlich nur mit x2, was diese Linien für Direktanbindung nicht tun. Wie viele Platten es braucht, bis der Adapter ausgeht, gegen zwei Decken. Zwei Gen4-Platten erreichen den HBA 9500; vier Gen5-Platten erreichen selbst eine PERC13. Die Karten sind für zweiunddreißig beziehungsweise sechzehn Geräte ausgelegt. Und eine x16-Karte? Der naheliegende Einwand gegen alles oben ist, dass die 9500 eine x8-Gen4-Karte ist und die Decke ein Artefakt einer schmalen Host-Verbindung. Gib dem Adapter sechzehn Lanes Gen5, und das Problem verschwindet.\nDas ist ein fairer Einwand, und er verdient das stärkste Beispiel statt eines Strohmanns. Nimm also Dells PERC13 H975i — die aktuelle Generation, und etwa so gut, wie Tri-Mode wird. Ihr Handbuch gibt „Gen 4 and Gen 5 PCIe x16 host interfaces“ an, und StorageReview hat gemessen: 52,5 GB/s und 12,5 Mio. IOPS je Controller, gegen bis zu sechzehn NVMe-Platten.\nDas sind ernste Zahlen, und sie ändern das Bild deutlich. Gegen die 13.700 MB/s und 3 Mio. IOPS der 9500 ist das etwa die vierfache Bandbreite und die vierfachen IOPS, über halb so viele Platten verteilt. Dell hat nicht bloß das Rohr verbreitert — sie haben auch die Verzweigung halbiert, und das Verhältnis der Überbuchung ist dadurch besser geworden. Besonders bei IOPS sind 12,5 Mio. über sechzehn Platten etwa 780K je Platte, und das kommt an das heran, was eine gängige Platte allein liefert. An diesem Punkt ist der Controller tatsächlich nicht das, was dich aufhält.\nAlle Ehre also, wo sie hingehört: eine moderne x16-Gen5-Tri-Mode-Karte ist ein viel besseres Stück Technik als eine x8-Gen4, und war Bandbreite dein einziger Einwand, beantwortet x16 ihn weitgehend.\nDrei Dinge behebt sie nicht.\nDie Platten verbinden sich weiter mit x2. Das ist das, was mich überrascht hat. Das PERC13-Handbuch, das einen Gen5-x16-Controller beschreibt, sagt weiterhin:\nSupports drive speeds for NVMe drives are 8 GT/s (Gen 3), 16 GT/s (Gen 4), and 32 GT/s (Gen 5) at maximum x2 lane width.\nEine breitere Host-Verbindung verbreitert die Plattenverbindungen dahinter nicht. Jede NVMe-Platte am neuesten, schnellsten Tri-Mode-RAID-Controller, den Dell verkauft, ist weiterhin mit zwei Lanes statt vier verbunden und gibt weiterhin die Hälfte ihrer Bandbreite auf, bevor irgendetwas anderes passiert.\nDas Queue-Modell bleibt völlig unberührt. Nichts im Queue-Abschnitt dieses Beitrags hängt von der Breite der Host-Verbindung ab. nr_hw_queues kommt aus der MSI-X-Reply-Queue-Zuteilung des Controllers; die Tiefe von 128 je Gerät ist eine Treiber- und Firmware-Konstante; der Tag-Pool ist über den ganzen Host geteilt, weil host_tagset das sagt. Verbreitere die Host-Verbindung auf x16, x32, was du willst — die Platten sind weiter SCSI-Targets, die sich die Queues der Karte teilen, es gibt weiter kein /dev/nvme0n1, und du kannst weiter keine Platte an eine VM durchreichen.\nUnd x16 stellt keine Bandbreite her — es verzweigt Lanes, die du schon hattest. Das ist das Argument, das die Sache tatsächlich entscheidet. Sechzehn Gen5-Lanes in eine PERC13 kaufen dir 52,5 GB/s, geteilt über sechzehn Schächte. Dieselben sechzehn Lanes direkt an vier Gen5-Platten mit x4 verdrahtet kaufen dir etwa 56 GB/s über vier Schächte — dieselbe Bandbreite aus denselben Lanes, nur dass jede Platte ihre vollen x4 bekommt, ihr eigenes Queue-Paar je Kern und einen echten nvme-Geräteknoten.\nDie ehrliche Beschreibung einer x16-Tri-Mode-Karte ist also nicht „ein schnellerer Adapter“. Sie ist ein Lane-Multiplexer: sie wandelt ein festes Lane-Budget in mehr Laufwerksschächte um und stellt dir das Queue-Modell für die Umwandlung in Rechnung. Ob der Handel gut ist, hängt von einer Sache ab. Schächte oder Parallelität.\nWas passiert, wenn du alle Schächte füllst Was zu dem Fall führt, auf den es tatsächlich ankommt, denn niemand kauft ein Gehäuse mit 24 Schächten, um vier Platten hineinzustecken.\nJenseits des Sättigungspunkts ist die Summenlinie flach. Platten hinzuzufügen fügt Kapazität hinzu, und nichts weiter — die Leistung je Platte fällt also mit 1/N. Diese Rechnung ist bei realistischen Bestückungen unbarmherzig:\nPlatten an einem HBA 9500 Summe Je Platte Anteil einer Gen4-Platte 2 13,7 GB/s 6,9 GB/s 98 % 12 13,7 GB/s 1,14 GB/s 16 % 24 13,7 GB/s 0,57 GB/s 8 % Sieh die letzte Zeile an. Vierundzwanzig NVMe-Platten hinter einem HBA 9500 liefern etwa 570 MB/s jede. Eine SATA-SSD macht rund 550. Du hast vierundzwanzig NVMe-Platten gekauft, für einen Tri-Mode-Controller bezahlt, um sie anzuschließen, und bist bei Bandbreite je Platte in SATA-Klasse angekommen.\nDie IOPS-Rechnung hat dieselbe Form: 3 Mio. über vierundzwanzig Platten verteilt sind 125K je Platte, gegen die 1 Mio., die eine gängige Gen4-Platte allein schafft — etwa ein Achtel von dem, was dir gehört.\nDie x16-Karte verbessert das deutlich, entkommt ihm aber nicht. Eine PERC13 mit ihren vollen sechzehn Platten sind 52,5 GB/s ÷ 16 = 3,3 GB/s je Platte, oder etwa 23 % einer Gen5-Platte — und das vor der x2-Verbindung, die es noch einmal halbiert.\nZwei Wirkungen bei hohen Plattenzahlen sind schlimmer, als die Teilung vermuten lässt:\nTag-Hunger geht über Geräte hinweg. Der gemeinsame Host-Tag-Pool heißt, dass eine einzelne Platte unter schwerer Last Plätze verbrauchen kann, die andere Platten brauchen. Vierundzwanzig Geräte, jedes nominell mit 128 offenen Befehlen erlaubt, wollen 3.072 zwischen sich, gezogen aus dem can_queue eines Controllers. Head-of-Line-Blocking zwischen getrennten Platten ist ein Fehlerfall, der einfach nicht existiert, wenn jede Platte ihre Queues besitzt. Wiederaufbauten treffen alles. Ein Paritäts-Wiederaufbau über ein bestücktes Regal sättigt den einen gemeinsamen Uplink, das Vordergrund-I/O zu jeder anderen Platte an der Karte verschlechtert sich also gleichzeitig. Mit Platten auf eigenen Lanes und Software-RAID streitet der Wiederaufbau um CPU, nicht um ein einzelnes Rohr. Wann nichts davon zählt Es gibt ein wichtiges Gegengewicht, und es ist der Grund, warum reichlich Tri-Mode-Server mit 24 Schächten völlig zufrieden laufen.\nDie Adapterdecke beißt nur, wenn etwas dahinter mehr aufnehmen kann, als sie liefert. Ein Server mit 2 × 25 GbE hat 6,2 GB/s Netz — er kann selbst einen HBA 9500 nicht füllen. Sind diese vierundzwanzig Platten eine Kapazitätsebene, die Dateien über diese Verbindung liefert, ist der Adapter nirgends in der Nähe des Engpasses, und die Rechnung je Platte oben ist ohne Belang.\nDer Moment, in dem es anfängt zu zählen, ist, wenn der Verbraucher schneller wird als die Karte: 100 GbE (12,5 GB/s) bringt dich allein auf die Höhe der ganzen sequentiellen Decke einer 9500, und lokale Lasten — Datenbanken, Kompilieren, Analytik, Virtualisierungs-Hosts mit beschäftigten Gästen — haben überhaupt kein Netz im Weg.\nDie Frage zu einem bestückten Regal ist also nicht „ist der Adapter langsam“, sondern „was wird das aufnehmen, und kann es mehr aufnehmen, als die Karte liefern kann?“ Ist die Antwort eine 25-GbE-Verbindung, hör auf, dir Sorgen zu machen. Ist die Antwort 100 GbE, NVMe-oF oder eine lokale Datenbank, ist die Karte dein Engpass, und die Plattenzahl macht es schlimmer.\nWas sonst noch verloren geht Über den Durchsatz hinaus heißt eine NVMe-Platte als SCSI-Platte zu zeigen, dass die NVMe-eigenen Teile deines Werkzeugkastens aufhören zu funktionieren:\nDirekt verbunden Hinter einem Tri-Mode-Adapter Geräteknoten /dev/nvme0n1 /dev/sdb Treiber nvme mpt3sas / mpi3mr nvme-cli Läuft Nichts, mit dem es sprechen kann Gesundheitsdaten NVMe-SMART-Log-Seiten Übersetzte SCSI-Log-Seiten Namespace-Verwaltung Ja Nein Firmware-Aktualisierungen nvme fw-download Hersteller-Werkzeug über den Controller Format / Sanitize NVMe Format NVM SCSI-Entsprechungen, wenn umgesetzt Hardware-Queues Ein Paar je Kern (16 auf der Maschine oben) Die Reply-Queues der Karte, von jeder Platte geteilt Queue-Tiefe 1023 je Queue 128 je Gerät Eine Folge erwischt Leute oft genug, um sie gesondert zu nennen: du kannst eine einzelne Platte nicht an eine virtuelle Maschine durchreichen. PCIe-Passthrough braucht, dass die Platte ein PCIe-Endpunkt mit eigener IOMMU-Gruppe ist, und hinter einem Tri-Mode-Adapter ist sie das nicht — das einzige PCIe-Gerät, das da ist, ist der Controller. Du kannst den ganzen Adapter durchreichen, mit jeder Platte daran, oder nichts. Sah dein Plan vor, bestimmte NVMe-Platten an bestimmte Gäste zu geben, hat die Backplane-Entscheidung diese Frage schon für dich beantwortet.\nWer will das also 2026 tatsächlich? Hier muss der Verkaufsspruch vom Anfang dieses Beitrags einer härteren Frage begegnen, denn die Welt, für die er entworfen wurde, ist größtenteils verschwunden.\nTri-Mode wurde ersonnen, als NVMe die teure Ebene war, die man einem SAS-Bestand hinzufügte. 2026 ist das umgekehrt: NVMe ist die Voreinstellung, U.2-Unternehmensplatten sind auf dem Gebrauchtmarkt reichlich und billig, und „SAS, SATA und NVMe gemischt in einem Gehäuse“ beschreibt immer weniger echte Installationen. Wer kauft es also?\nMeist niemand — absichtlich. Die ehrliche Antwort ist, dass die meisten Tri-Mode-Controller nicht gewählt wurden. Sie kamen an, weil der Serverhersteller einen ausliefert, und der Hersteller liefert einen aus, weil eine einzige U.3-Backplane-Variante ihm erlaubt, SAS-, SATA- und NVMe-Konfigurationen aus demselben Gehäuse zu verkaufen. Das ist ein Gewinn in der Lieferkette für den OEM. Für deine Leistung tut es nichts, und es wurde auch nie so verkauft.\nDrei der klassischen Begründungen halten nicht mehr gut:\n„Ich brauche gemischte Plattentypen.“ Selten im selben Gehäuse, und selbst wenn, ist Tri-Mode nicht der einzige Weg. Ein einfacher SAS-HBA für die sich drehenden Platten plus NVMe an den Root Complex verdrahtet gibt dir beides, ohne dass eines bestraft wird. Gemischter Bestand heißt nicht gemischter Controller.\n„Ich habe nicht genug PCIe-Lanes.“ Das war 2019 das echte Argument, auf Plattformen mit 40 Lanes und 24 Schächten. Ein Genoa- oder Turin-Epyc mit einem Sockel hat 128 Lanes. Vierundzwanzig Platten mit x4 sind 96. Die Knappheit, die es rechtfertigte, Platten hinter einem Controller zu bündeln, ist so gut wie weg, und wo sie es nicht ist, erledigt ein PCIe-Switch die Aufgabe, ohne das Protokoll zu beenden.\n„Die Schächte müssen universell sein.“ Das ist es wert, sorgfältig getrennt zu werden, denn es ist das Argument, mit dem am häufigsten das falsche Bauteil gerechtfertigt wird. U.3 ist ein Backplane-Standard, keine Controller-Anforderung. Eine U.3-Backplane kann direkt an die PCIe-Lanes der CPU verkabelt werden statt durch einen Tri-Mode-Controller, und Hersteller dokumentieren beide Topologien. Du kannst die universellen Schächte behalten und die Steuer löschen. Hast du einen Tri-Mode-Server geerbt, ist das Wertvollste, was du prüfen kannst, ob die Backplane direkt neu verkabelt werden kann.\nWas tatsächlich übrig bleibt:\nHardware-RAID bei Dichte, wo Vorschrift oder Plattform es verlangt — eine Prüfanforderung, eine Support-Matrix, eine Windows- oder ESXi-Installation ohne Softwareschicht, die die Aufgabe erledigt. Das ist der echte verbleibende Markt, es ist der eine Fall, in dem du das RAID-Werk kaufst und nicht die Anbindung, und auf heutigem Silizium ist es ein taugliches Produkt: sechzehn NVMe-Platten in Hardware-RAID 5 mit einem durch Supercap geschützten Cache, aus sechzehn Lanes, ist etwas, das Direktanbindung überhaupt nicht anbieten kann. Massenkapazität mit SAS-HDDs, wo £/TB noch entschieden den sich drehenden Platten gehört. Aber das ist die Aufgabe eines einfachen SAS-HBA, und eines billigeren. Sehr hohe Schachtzahlen und externe Gehäuse, wo SAS-Expander weiter und breiter reichen, als PCIe es wird. Lasten, die nie tief gehen. Sitzen deine Queue-Tiefen im einstelligen Bereich, merkt man nichts davon. Reichlich echte Systeme leben hier ganz zufrieden. Es gibt auch ein schlichtes betriebliches Argument — ein Gehäusetyp, ein Treiber, ein Ersatzteil im Regal —, und für einen Virtualisierungs-Host für allgemeine Zwecke ist das etwas Echtes wert. Rechne es bloß ehrlich gegen die Tatsache, dass laut der Tabelle oben eine Gen5-Platte die ganze sequentielle Decke der Karte erreichen kann.\nWann es das falsche Werkzeug ist Der Handel wird schlecht im Verhältnis dazu, wie viel Parallelität deine Last hat.\nCeph ist der klarste Fall. Ein Speicherknoten fährt eine OSD je Platte, jede mit ihren eigenen Thread-Pools, alle setzen gleichzeitig I/O ab — und dann treiben Clients eines ganzen Clusters sie gleichzeitig. Das ist der schlimmste Fall für den gemeinsamen Tag-Pool: vierundzwanzig Dienste streiten um die Befehlsplätze eines Controllers, jede Platte bei 128 offenen gedeckelt, alles durch einen x8-Uplink getrichtert. Steck diese Platten direkt an den Root Complex, und jede OSD bekommt ihre eigenen Queues, ihre eigenen Tags und ihre eigenen Lanes. Ein Ceph-Knoten voll NVMe sollte keinen Tri-Mode-Adapter im Datenweg haben.\nDieselbe Logik gilt für NVMe-oF-Targets, wo du Platten wieder herausgibst und jede Schicht der Serialisierung sich aufaddiert; für Datenbanken mit tiefem asynchronem I/O; und für alles, was auf io_uring oder SPDK gebaut ist, die es gerade dafür gibt, die Queues je Kern auszunutzen, die der Adapter dir gerade genommen hat.\nDie allgemeine Regel: je mehr Parallelität deine Software ausnutzen sollte, desto mehr stellt ein Tri-Mode-Adapter dir dafür in Rechnung.\nWie du herausfindest, was du hast Hast du einen Server geerbt und willst wissen, auf welcher Seite davon du stehst:\n# What is the transport? \u0026#34;nvme\u0026#34; is direct, \u0026#34;sas\u0026#34; means it went through a controller lsblk -o NAME,TRAN,MODEL,SIZE # Is there a tri-mode controller in the machine at all? lspci -nn | grep -Ei \u0026#39;sas|megaraid|serial attached\u0026#39; # Which driver claimed the disk? ls -l /sys/block/sdb/device/driver # Per-device queue depth — 128 is the mpt3sas NVMe default cat /sys/block/sdb/device/queue_depth # How many hardware queues does this device actually get? ls /sys/block/sdb/mq/ | wc -l ls /sys/block/nvme0n1/mq/ | wc -l # compare against a direct-attached drive # On a direct-attached drive, what did the controller actually grant? # One admin queue plus one I/O queue per core, so expect nproc + 1 cat /sys/class/nvme/nvme0/queue_count nproc # The driver says it out loud at load time dmesg | grep -i \u0026#39;nr_hw_queues\u0026#39; Das Letzte gibt die Zeile Max SCSIIO MPT commands: N shared with nr_hw_queues = M aus, die oben zitiert wurde. Ist nvme list auf einer Maschine leer, von der dir gesagt wurde, sie sei ganz NVMe-Flash, ist der Adapter der Grund.\nDie kurze Fassung Ein Tri-Mode-Adapter wandelt deine NVMe-Platten in SCSI-Platten um. Diese Umwandlung ist keine Nebenwirkung. Sie ist, wie eine Karte drei Protokolle bedient, und sie ist, was du kaufst.\nWas du aufgibst, ist bestimmt und messbar: Queue-Paare je Kern durch die gemeinsamen Reply-Queues eines Controllers ersetzt, eine Tiefe von 128 je Gerät, ein Tag-Pool auf jede Platte an der Karte verteilt, eine x2-Verbindung, wo die Platte x4 wollte, und ein gemeinsamer Uplink, wo jede Platte zuvor ihren eigenen Weg zum Root Complex hatte. Der Adapter hört auf, eine Verbindung zu sein, und wird zum Engpass, und auf heutiger Hardware wird er es schnell: zwei Gen4-Platten erreichen einen HBA 9500, vier Gen5-Platten erreichen selbst eine PERC13.\nEine breitere Host-Verbindung hilft — eine x16-Gen5-Karte hat etwa die vierfache Bandbreite und die vierfachen IOPS einer x8-Gen4 —, aber sie ändert die Form nicht. Sie kauft Schächte, nicht Parallelität: dieselben sechzehn Lanes direkt an vier Platten verdrahtet liefern dieselbe Bandbreite, ohne jede Queue-Steuer. Und sie rettet kein volles Regal. Vierundzwanzig Platten hinter einer 9500 bekommen etwa 570 MB/s jede, und das ist, was eine SATA-SSD macht.\n2019, als NVMe die Ebene war, die man einem SAS-Bestand hinzufügte, und Plattformen knapp an Lanes waren, war das ein vernünftiger Handel. 2026 ist er es meist nicht. NVMe ist die Voreinstellung, gebrauchte U.2-Platten sind billig, ein Epyc mit einem Sockel hat Lanes übrig, und der eine Vorteil, der noch steht — universelle Laufwerksschächte —, gehört der U.3-Backplane, nicht dem Controller. Du kannst sehr oft die Schächte behalten und die Steuer löschen, indem du die Backplane direkt an die CPU verkabelst.\nKauf also einen Tri-Mode-Adapter, wenn du sein RAID-Werk kaufst und eines brauchst. Kauf ihn nicht für die Flexibilität, und hast du einen in einem Gehäuse voll NVMe geerbt, geh und finde heraus, wie diese Backplane verkabelt ist.\n","permalink":"https://blogs.damiendye.uk/de/hardware/tri-mode-adapters-nvme-as-sas/","summary":"Ein Tri-Mode-Adapter lässt jeden Schacht SAS, SATA oder NVMe aufnehmen — echte Flexibilität, und der Grund, warum es U.3-Backplanes gibt. Was er nicht bewirbt, ist, dass deine NVMe-Platten aufhören, NVMe-Platten zu sein: sie kommen in Linux als SCSI-Platten an mpt3sas an, Queue-Tiefe 128, mit einem gemeinsamen Tag-Pool und einem x8-Uplink. Zwei Gen4-Platten sättigen die Karte. Eine einzelne Gen5 ist schon darüber. Ob dieser Handel 2026 noch aufgeht, und warum die universellen Schächte der Backplane gehören und nicht dem Controller.","title":"Tri-Mode-Adapter kaufen Flexibilität mit deinen NVMe-Queues"},{"content":"Die Annahme, die Ansible sonst machen darf Fast jedes Ansible-Modul, das du benutzt hast, arbeitet so: Ansible verbindet sich zu dem Host, der im Inventar steht, kopiert ein kleines Python-Programm dorthin, führt es aus und liest das Ergebnis zurück. Der Host ist das Ding, das geändert wird, und das Ding, das die Arbeit macht.\nEine virtuelle Maschine anzulegen bricht das auf die grundlegendste Weise. Den Host, den du baust, gibt es nicht. Er hat keine IP, keinen SSH-Dienst, kein Python und kein Betriebssystem. Es ist nichts da, zu dem man verbinden könnte.\ncommunity.proxmox ist also kein Konfigurationsagent. Es ist ein API-Client, der zufällig als Ansible-Collection ausgeliefert wird. Alles in diesem Beitrag folgt aus dieser einen Tatsache — wo die Tasks laufen, wie du Zugangsdaten hineinbekommst, warum ein zweiter Lauf nicht tut, was du erwartest, und warum --check dir nicht die Wahrheit sagt.\nDie Beispiele hier sind eingekürzt aus einem Playbook, das Windows- und Linux-VMs aus NetBox-Datensätzen baut: proxmox-create-vms.yml. Ich habe die Namen von Knoten, Speicher und Bridge der Lesbarkeit zuliebe verallgemeinert — das Echte liegt in diesem Repository.\nAlles, was ich unten über das Verhalten der Module behaupte, wurde gegen community.proxmox 1.6.0 geprüft, die Fassung, die ich installiert habe:\n$ ansible-galaxy collection list community.proxmox # /home/damien/.ansible/collections/ansible_collections Collection Version ----------------- ------- community.proxmox 1.6.0 Zuerst: die Collection ist umgezogen Liest du ein älteres Playbook oder eine ältere Antwort, hießen die Module community.general.proxmox_kvm. Sie wohnen jetzt in einer eigenen Collection, und dort findet die Entwicklung statt. Fassung 1.6.0 liefert 47 Module, die Ceph, SDN, Firewall, HA-Regeln und den Cluster-Beitritt abdecken, und nichts davon gab es in der Zeit von community.general.\nansible-galaxy collection install community.proxmox pip install \u0026#39;proxmoxer\u0026gt;=2.0\u0026#39; requests Die Python-Abhängigkeit ist nicht wahlfrei und nicht mitgeliefert: die Collection erklärt requirements: [\u0026quot;proxmoxer \u0026gt;= 2.0\u0026quot;, \u0026quot;requests\u0026quot;], und die müssen dort installiert sein, wo das Modul tatsächlich ausgeführt wird — und das ist, wie der nächste Abschnitt erklärt, nicht der Proxmox-Knoten.\nrequirements.yml, wenn du es lieber festnagelst:\n--- collections: - name: community.proxmox version: \u0026#34;\u0026gt;=1.6.0\u0026#34; Die Collection wird gegen ansible-core 2.17 bis 2.20 getestet. Deine community.general.proxmox_*-Tasks in community.proxmox.proxmox_* umzubenennen ist der größte Teil der Umstellung.\nJeder Proxmox-Task läuft auf localhost Zwei Zeilen am Kopf des Plays tragen die Last, und beide sehen aus, als würden sie etwas Nützliches abschalten:\n- name: Create Proxmox virtual machines hosts: \u0026#34;{{ target_hosts | default(\u0026#39;cluster_pve:\u0026amp;status_planned\u0026#39;) }}\u0026#34; gather_facts: false serial: 1 gather_facts: false ist keine Optimierung. Das Sammeln von Fakten verbindet sich zum Inventar-Host, und der Inventar-Host ist eine VM, die noch nicht gebaut ist. Lass es an, und das Play scheitert vor dem ersten Task.\nDann trägt jeder Proxmox-Task ein delegate_to: localhost:\n- name: Create Proxmox VM delegate_to: localhost register: created_vm community.proxmox.proxmox_kvm: api_user: \u0026#34;{{ proxmox_user }}\u0026#34; api_password: \u0026#34;{{ proxmox_password }}\u0026#34; api_host: \u0026#34;{{ proxmox_api_ip }}\u0026#34; name: \u0026#34;{{ inventory_hostname }}\u0026#34; node: \u0026#34;{{ proxmox_api_host }}\u0026#34; ... Der Inventar-Host ist jetzt bloß ein Name und ein Sack Variablen. inventory_hostname wird der Name der VM; seine Variablen beschreiben die Maschine, die du willst. Nichts verbindet sich dorthin. Der Task läuft auf dem Steuerknoten, der eine HTTPS-Sitzung zu api_host öffnet und eine VM-Definition abschickt.\nDu wirst das auch als local_action: geschrieben sehen, die ältere Schreibweise für dasselbe. Das Abbau-Playbook in jenem Repository nutzt sie durchgehend. Sie sind gleichwertig. delegate_to ist die heutige Schreibweise.\nDie Notluke zeigt auf den Knoten Manches muss wirklich auf einem Proxmox-Host passieren, und diese Tasks delegieren woandershin:\n- name: Fail if no ISO file exists for the OS delegate_to: \u0026#34;{{ proxmox_api_host }}\u0026#34; ansible.builtin.stat: path: \u0026#34;{{ iso | replace(\u0026#39;isos:\u0026#39;, \u0026#39;/mnt/pve/isos/template/\u0026#39;) }}\u0026#34; register: iso_file failed_when: not iso_file.stat.exists Das ist eine echte SSH-Verbindung zu einem echten Knoten, die einen echten Pfad auf gemeinsamem Speicher prüft, denn die API nimmt bereitwillig eine ISO-Angabe an, die auf keine Datei zeigt, und das willst du lieber jetzt erfahren als beim Start. Beachte die Zeichenketten-Operation, die eine PVE-Speicherangabe (isos:iso/debian.iso) in einen Dateisystempfad überführt. Die Speicherabstraktion steht stat nicht zur Verfügung.\nEin einzelnes Play hat also Tasks, die an drei verschiedenen Stellen ausgeführt werden, und sie zu verwechseln ist die häufigste Weise, wie diese Playbooks scheitern:\nWo jeder Task eines Proxmox-Bau-Playbooks tatsächlich ausgeführt wird Ansible-Steuerknoten delegate_to: localhost proxmox_kvm proxmox_vm_info proxmox_disk proxmox_access_acl jedes davon ist ein HTTPS-Client, kein Agent proxmoxer \u0026#8805; 2.0 + requests hier installiert, nicht am Knoten gather_facts: false Proxmox-Knoten \u0026#8212; pve1 pvedaemon, REST API auf Port 8006 qm, /etc/pve, Speicher die VM-Definition landet hier die VM, die du anlegst keine IP \u0026#183; kein SSH \u0026#183; kein Python kein Betriebssystem im Inventar ist sie nur ein Name und ein Sack Variablen API SSH qm set stat nichts, wohin man verbindet erst in einem späteren Play Drei Ausführungsorte in einem Play. Die Proxmox-Module berühren weder den Knoten noch den Gast — sie sind HTTPS-Clients, die neben dem Playbook laufen. Die qm-Notluke ist der einzige Teil, der SSH zu einem Hypervisor braucht. Zugangsdaten, und eine Voreinstellung, die sich bald ändert Die Auth-Optionen teilen alle Module der Collection über ein Dokumentationsfragment, sie sind also überall dieselben: api_host, api_user, und dann entweder api_password oder das Paar api_token_id / api_token_secret. Alle greifen auf Umgebungsvariablen zurück — PROXMOX_HOST, PROXMOX_USER, PROXMOX_PASSWORD, PROXMOX_TOKEN_ID, PROXMOX_TOKEN_SECRET, PROXMOX_VALIDATE_CERTS —, und das ist der saubere Weg, Geheimnisse ganz aus dem Play zu halten.\nEin API-Token ist die bessere Voreinstellung. Es ist eingegrenzt, es ist widerrufbar, ohne das Passwort eines Menschen zu ändern, und es kann genau die Rechte bekommen, die das Playbook braucht, statt der Rechte, die eine Person zufällig hat:\n- name: Create Proxmox VM delegate_to: localhost community.proxmox.proxmox_kvm: api_host: \u0026#34;{{ proxmox_api_ip }}\u0026#34; api_user: ansible@pve api_token_id: automation api_token_secret: \u0026#34;{{ proxmox_token_secret }}\u0026#34; validate_certs: true ca_path: /etc/ssl/certs/pve-cluster-ca.pem Setz validate_certs ausdrücklich, und zwar heute. Die eigene Dokumentation der Collection sagt es klar:\nCurrently defaults to false and changes default to true with community.proxmox 2.0.0.\nDas heißt, ein Playbook, das es nie erwähnt, prüft TLS gerade nicht und wird anfangen zu prüfen — und damit anfangen, gegen das selbst ausgestellte Zertifikat zu scheitern, das jede frische Proxmox-Installation mitbringt —, sobald jemand --upgrade laufen lässt. Diese Entscheidung trifft man besser mit Absicht, als sie mitten in einem Aufbau zu erleben. Behältst du das selbst ausgestellte Zertifikat, schreib validate_certs: false und nimm den Befund hin; hast du eine richtige Kette, zeig mit ca_path darauf. So oder so steht es geschrieben.\nDas kleinste taugliche Anlegen Kürz den produktiven Task auf das, was eine Maschine tatsächlich beschreibt, und es ist lesbar:\n- name: Create Proxmox VM delegate_to: localhost register: created_vm community.proxmox.proxmox_kvm: api_host: \u0026#34;{{ proxmox_api_ip }}\u0026#34; api_user: ansible@pve api_token_id: automation api_token_secret: \u0026#34;{{ proxmox_token_secret }}\u0026#34; validate_certs: true node: pve1 name: \u0026#34;{{ inventory_hostname }}\u0026#34; cores: \u0026#34;{{ vcpus | int }}\u0026#34; memory: \u0026#34;{{ memory }}\u0026#34; machine: q35 bios: ovmf ostype: l26 scsihw: virtio-scsi-single scsi: scsi0: \u0026#34;vmdata:32,format=qcow2,discard=on,ssd=1\u0026#34; sata: sata0: \u0026#34;isos:iso/debian-13-netinst.iso,media=cdrom\u0026#34; net: net0: \u0026#34;virtio,bridge=vmbr0\u0026#34; efidisk0: storage: vmdata format: raw efitype: 4m pre_enrolled_keys: true boot: \u0026#34;order=scsi0;sata0\u0026#34; agent: \u0026#34;enabled=1,fstrim_cloned_disks=1\u0026#34; onboot: true tags: - production Ein paar Dinge an dieser Form sind es wert, sie zu kennen, bevor du deine eigene schreibst.\nDie Geräteoptionen sind PVE-Syntax innerhalb von YAML. scsi, sata, net, virtio, ide sind alle als dict typisiert, mit Schlüsseln scsi0, net0 und so weiter, und die Werte sind die kommagetrennten Optionszeichenketten direkt aus man qm — \u0026lt;storage\u0026gt;:\u0026lt;size\u0026gt;,option=value für eine Platte, [model=]\u0026lt;enum\u0026gt;,option=value für eine NIC. Das Modul modelliert sie nicht; es leitet sie weiter. Wird etwas abgelehnt, steht die Antwort in der PVE-Optionsreferenz, nicht in der Ansible-Dokumentation.\nDu wirst diese auch als JSON-Zeichenkette statt als YAML-Abbildung sehen:\nnet: \u0026#39;{\u0026#34;net0\u0026#34;:\u0026#34;virtio,bridge={{ vlan_bridge }}\u0026#34;}\u0026#39; Beides funktioniert. Ansible wandelt die Zeichenkette für einen als dict typisierten Parameter um. Die JSON-Form existiert, weil es leichter ist, eine ganze Struktur in einem Jinja-Ausdruck zu erzeugen. Die Abbildungsform ist in sechs Monaten leichter zu lesen.\nboot hat zwei Generationen Syntax. Das Modul nimmt die alten Buchstaben, wo boot: \u0026quot;cdn\u0026quot; heißt „versuch Platte, dann CD-ROM, dann Netz“. Das heutige PVE will eine ausdrücklich geordnete Liste — boot: \u0026quot;order=scsi0;sata0;net0\u0026quot; —, die eindeutig sagt, welche Platte. Die alte Form läuft weiter. Die ausdrückliche ist die, die du in neuer Arbeit willst. Ein echter Fallstrick, tief in der Moduldokumentation begraben: Netzstart braucht seit PVE 8.3.5, dass rng0 gesetzt ist.\nnuma und numa_enabled sind verschiedene Parameter. numa_enabled ist der Schalter, der NUMA einschaltet. numa ist ein Dict, das eine Topologie beschreibt (cpus, hostnodes, memory, policy). numa: true zu setzen ist ein Typfehler, und es ist eine leicht verlorene Stunde. Interessiert dich, warum das alles zählt, behandelt NUMA-Ausrichtung auf Proxmox das Problem darunter.\nmachine: q35 und bios: ovmf sind die richtigen Voreinstellungen, keine Zierde — das Argument in voller Länge.\nvmid weglassen heißt, das Modul fragt die API nach der nächsten freien ID. Bequem, und der unmittelbare Grund für das Nächste.\nWarum serial: 1 „Hol die nächste verfügbare ID, dann leg eine VM damit an“ sind zwei API-Aufrufe mit einer Lücke in der Mitte. Zwei Arbeiter, die das gleichzeitig tun, können dieselbe freie ID lesen, und der Verlierer bekommt einen Fehler oder, schlimmer, eine Überraschung.\nserial: 1 macht die Anlege-Phase zu einem Host nach dem anderen. Es ist nicht schnell und muss es nicht sein. Der teure Teil des VM-Baus passiert, nachdem dieses Playbook übergeben hat. Das Gegenstück-Play, das die fertigen VMs startet, nutzt serial: 5, denn beim Starten gibt es keinen gemeinsamen Zähler, um den man sich streiten könnte.\nWillst du lieber die Parallelität, teile die VMID selbst aus deiner verlässlichen Quelle zu und übergib sie ausdrücklich. Dann gibt es kein Lesen-Ändern-Schreiben und kein Rennen.\nIdempotenz ist nicht, was du erwartest Das ist der Abschnitt, den man zweimal liest, denn proxmox_kvm verhält sich nicht wie ansible.builtin.package.\nname ist keine Identität. VM-Namen sind über einen Proxmox-Cluster hinweg nicht eindeutig, und das Modul sagt es. Mit state: present und ohne vmid steigt das Modul, wenn eine VM mit diesem Namen schon existiert, mit changed=false und msg: \u0026quot;VM with name \u0026lt;x\u0026gt; already exists\u0026quot; aus und tut nichts. Es vergleicht deine Parameter nicht mit der Wirklichkeit. Es konvergiert nicht. Es verweigert sich.\nupdate steht voreingestellt auf false. memory: in deinem Playbook zu ändern und neu zu laufen ist also wirkungslos. Die VM behält den Speicher, mit dem sie gebaut wurde, der Task meldet Erfolg, und nirgends sagt dir etwas, dass die zwei auseinandergelaufen sind.\nupdate: true verweigert die interessanten Parameter weiterhin. Aus der Moduldokumentation:\nBecause of the operations of the API and security reasons, I have disabled the update of the following parameters net, virtio, ide, sata, scsi. Per example updating net update the MAC address and virtio create always new disk…\nupdate_unsafe: true hebt diese Einschränkung auf, und die Warnung ist keine Show:\nUse this option with caution because an improper configuration might result in a permanent loss of data (for example disk recreated).\nDie Platte, von der du dachtest, du würdest sie vergrößern, kann also durch eine neue leere ersetzt werden. Greif nicht danach — die verweigerten Parameter haben ihre eigenen Module, und das ist der nächste Abschnitt.\nUnd --check deckt nichts davon ab. Die Collection erklärt Check-Mode-Unterstützung je Modul, und sie ist genau in die falsche Richtung ungleichmäßig:\nModul check_mode diff_mode proxmox_kvm keiner keiner proxmox_disk keiner keiner proxmox_template keiner keiner proxmox_snap voll keiner proxmox_nic voll keiner proxmox_pool voll keiner Die Trennung ist nicht „lesende Module können es, schreibende nicht“ — proxmox_nic legt Schnittstellen an und löscht sie und achtet den Check-Mode einwandfrei. Sie ist, dass die drei Module, die mit Speicher und VM-Lebenszyklus zu tun haben, es nicht tun. Ein --check-Lauf eines Bau-Playbooks überspringt das Anlegen der VM still und berichtet dann über eine Welt, in der die VM nie gemacht wurde, sodass jeder Task danach über den falschen Zustand nachdenkt. Auf einem Bau-Playbook ist --check kein Auffangnetz, und es dafür zu nehmen ist schlimmer, als es nicht laufen zu lassen.\nWas ein zweiter Lauf von proxmox_kvm tatsächlich tut zweiter Lauf \u0026#8212; state: present, und eine VM dieses Namens existiert das Modul vergleicht deine Parameter nie mit der laufenden VM update: false die Voreinstellung changed = false \u0026#8220;VM with name \u0026lt;x\u0026gt; already exists\u0026#8221; ändere memory im Play, lauf neu, und nirgends sagt es dir etwas update: true konvergiert das meiste cores, memory, tags, agent, onboot greifen net, virtio, ide, sata, scsi, efidisk0, tpmstate0 absichtlich verweigert nimm dafür proxmox_disk und proxmox_nic update_unsafe: true konvergiert alles die verweigerten Parameter greifen auch ein Plattenparameter kann die Platte neu anlegen dauerhafter Datenverlust ist das dokumentierte Risiko --check sagt dir nichts check_mode: none der Task wird übersprungen jeder spätere Task denkt dann über eine Welt nach, in der die VM nie angelegt wurde Zwei der vier konvergieren überhaupt etwas, und der, der Platten abdeckt, kann sie zerstören. Tor also selbst an der Existenz, und behandle das Anlegen als einmaliges Ereignis. Was ein zweiter Lauf tatsächlich tut. Zwei der vier Wege konvergieren überhaupt etwas, und der einzige, der Platten abdeckt, ist der, der sie zerstören kann. Also mach die Existenz zum Tor Angesichts all dessen ist das gangbare Muster, das Modul nicht länger um Idempotenz zu bitten und selbst zu entscheiden, ob gebaut wird. Das produktive Playbook macht es so:\n- name: Check if VM is present or manually built delegate_to: localhost community.proxmox.proxmox_vm_info: api_host: \u0026#34;{{ proxmox_api_ip }}\u0026#34; api_user: \u0026#34;{{ proxmox_user }}\u0026#34; api_password: \u0026#34;{{ proxmox_password }}\u0026#34; name: \u0026#34;{{ inventory_hostname }}\u0026#34; config: current register: existing_vm ignore_errors: true failed_when: (existing_vm.proxmox_vms | length) == 0 - name: Configure Proxmox VM when: existing_vm is failed block: - name: Create Proxmox VM ... proxmox_vm_info mit config: current gibt die VM und ihre laufende Konfiguration zurück, oder eine leere Liste. failed_when macht aus „leere Liste“ einen Fehlschlag, ignore_errors: true hindert diesen Fehlschlag daran, das Play zu beenden, und when: existing_vm is failed wird zu „die VM ist nicht da, bau sie“.\nEinen absichtlich fehlgeschlagenen Task als Wahrheitswert zu nutzen liest sich schlecht, und ich will das nicht anders darstellen. Die Alternative ist when: (existing_vm.proxmox_vms | default([]) | length) == 0, was ehrlich dazu steht, eine Längenprüfung zu sein, und kein ignore_errors braucht. Beides läuft. Die Fassung oben ist die, die produktiv ist, und ihr einziger echter Vorteil ist, dass das registrierte Ergebnis die vorhandene Konfiguration für spätere Tasks mitbringt.\nDer wichtige Teil ist die Form, nicht die Schreibweise: prüfen, dann verzweigen, und das Anlegen als einmaliges Ereignis behandeln. Die laufende Konfiguration einer VM ist ein anderes Problem als die Existenz einer VM, und dieses Modul ist nur im Zweiten gut.\nPlatten und NICs haben ihre eigenen Module Hier ist das, was ich oben übergangen habe, und es verändert das ganze Bild: die Parameter, die proxmox_kvm nicht aktualisieren will, sind keine Lücke in der Collection. Sie sind abgegeben. community.proxmox.proxmox_disk und community.proxmox.proxmox_nic legen genau die Dinge an, ändern sie und entfernen sie, die das Anlege-Modul nicht anfassen will — anhand derselben Namen scsi0 und net0, die du beim Bauen der VM benutzt hast.\nBeide sind besser erzogen als proxmox_kvm, und eines von ihnen ist das einzige Modul in diesem Ablauf, das man trocken laufen lassen kann.\nproxmox_nic — eine Schnittstelle anlegen, umtaggen oder entfernen - name: Move the VM\u0026#39;s primary NIC to a new bridge and VLAN delegate_to: localhost community.proxmox.proxmox_nic: api_host: \u0026#34;{{ proxmox_api_ip }}\u0026#34; api_user: ansible@pve api_token_id: automation api_token_secret: \u0026#34;{{ proxmox_token_secret }}\u0026#34; vmid: \u0026#34;{{ created_vm.vmid }}\u0026#34; interface: net0 bridge: vmbr1 tag: 120 model: virtio mtu: 1 queues: 4 firewall: true state: present interface ist die einzige nötige Option über die Auth hinaus — net[n], wobei n von 0 bis 31 geht —, und state: present oder absent gibt dir Anlegen und Entfernen. model steht voreingestellt auf virtio, was die richtige Antwort ist, solange ein Gast nicht damit überfordert ist.\nDer Grund, warum dieses Modul existiert, ist die MAC-Adresse. Erinnere dich, warum proxmox_kvm sich weigert, net zu aktualisieren: „updating net update the MAC address“. proxmox_nic behebt das ausdrücklich:\nWhen not specified this module will keep the MAC address the same when changing an existing interface.\nDu kannst also ein VLAN umtaggen, eine Bridge wechseln, die MTU ändern oder die Firewall einschalten, ohne dass sich die NIC-Identität des Gastes darunter ändert. Das zählt mehr, als es klingt: eine neue MAC macht DHCP-Reservierungen ungültig, bricht alles, was auf eine NIC lizenziert ist, und bringt den NetBox-Schnittstellendatensatz aus dem Tritt, den das Anlege-Playbook so sorgfältig geschrieben hat. Das ist das Modul, das eine Netzänderung am zweiten Tag langweilig macht.\nEin paar Optionen, die es wert sind, bevor du sie brauchst:\nrate ist in MB/s — Megabyte pro Sekunde, nicht Bit. Die Dokumentation ist ausdrücklich, und der Faktor-Acht-Fehler ist sehr leicht gemacht. link_down: true trennt die Schnittstelle, in der Dokumentation beschrieben als „like pulling the plug“. Ein sauberer Weg, eine verdächtige VM zu isolieren, ohne sie zu stoppen oder den Gast anzufassen. trunks nimmt eine Liste von VLAN-IDs zum Durchlassen, für einen Gast, der selbst taggt. mtu: 1 ist kein Tippfehler und keine MTU von 1 Byte — es heißt „erbe die MTU der Bridge“, und es gilt nur für virtio. queues setzt Multi-Queue, 0 bis 16. Bei allem, was echten Verkehr schiebt, lohnt es sich, das auf die vCPU-Zahl abzustimmen. Und es unterstützt den Check-Mode voll. --check auf einem proxmox_nic-Task sagt dir die Wahrheit, und das macht ihn zum einzigen Teil dieses Ablaufs, den du sicher üben kannst. Seine Meldungen sind auch richtig idempotent. Eine unveränderte Schnittstelle meldet Nic net0 unchanged on VM with vmid 103, statt eine Änderung zu behaupten.\nproxmox_disk — der ganze Lebenszyklus einer Platte proxmox_disk ist das größte der drei Module, und sein state macht fünf verschiedene Aufgaben:\nstate Was passiert Umkehrbar? present die Platte anlegen, oder Optionen an einer vorhandenen ändern entfällt resized vergrößern — PVE kann nicht schrumpfen, und die Dokumentation sagt, das von Hand zu machen nein detached wird unused[n]; das Volume und seine Daten bleiben ja moved den Speicher darunter wechseln, oder die Platte einer anderen VM geben Original bleibt, außer bei delete_moved absent aus dem Speicher darunter entfernt nein Der Abstand zwischen detached und absent ist das Auffangnetz, das proxmox_kvm dir nie gibt. Abtrennen ist eine Konfigurationsänderung; Löschen zerstört Daten. Zwei verschiedene Wörter, zwei verschiedene Folgen.\nEine zweite Platte an eine schon vorhandene VM hängen:\n- name: Add a data disk delegate_to: localhost community.proxmox.proxmox_disk: api_host: \u0026#34;{{ proxmox_api_ip }}\u0026#34; api_user: ansible@pve api_token_id: automation api_token_secret: \u0026#34;{{ proxmox_token_secret }}\u0026#34; vmid: \u0026#34;{{ created_vm.vmid }}\u0026#34; disk: scsi1 storage: vmdata size: 200 format: qcow2 iothread: true aio: io_uring discard: \u0026#34;on\u0026#34; ssd: true backup: true state: present create ist das Stellrad, das proxmox_kvm hätte haben sollen. Es steuert, was state: present tun darf:\nregular (die Voreinstellung) — die Platte anlegen, wenn sie fehlt, sonst ihre Optionen ändern. disabled — nur Optionen ändern und nie anlegen. Das ist das, wonach man greift, wenn man cache oder iothread an einer Platte ändert, die schon existieren muss. Es kann dich nicht überraschen, indem es wegen eines vertippten Schlüssels ein neues Volume herbeizaubert. forced — immer anlegen. Eine vorhandene Platte wird abgetrennt und unbenutzt liegen gelassen, nicht gelöscht. Das letzte Verhalten ist die wichtige Einzelheit. create: forced ist die zerstörerisch aussehende Möglichkeit, und sie zerstört dennoch nichts: das alte Volume überlebt als unusedN, und du kannst es wieder anhängen. Vergleich das mit proxmox_kvm plus update_unsafe, dessen dokumentierter Fehlerfall eine neu angelegte Platte ist. Ungefähr derselbe Vorgang, viel bessere Wirkungsweite.\nEine Platte vergrößern:\n- name: Grow the data disk by 100 GiB delegate_to: localhost community.proxmox.proxmox_disk: api_host: \u0026#34;{{ proxmox_api_ip }}\u0026#34; api_user: ansible@pve api_token_id: automation api_token_secret: \u0026#34;{{ proxmox_token_secret }}\u0026#34; vmid: \u0026#34;{{ created_vm.vmid }}\u0026#34; disk: scsi1 size: \u0026#34;+100G\u0026#34; state: resized Achte auf die Einheiten, denn size ändert mit state seine Bedeutung. Mit state: present ist es GiB als nackte Zahl (size: 200). Mit state: resized nimmt es ein Suffix — +100G, um zur aktuellen Größe zu addieren, oder 500G als absolutes Ziel. Ein Parameter, zwei Konventionen, und der Fehlschlag ist still, wenn du falsch rätst.\nEine Platte auf anderen Speicher verschieben, der Fall der Live-Migration eines einzelnen Volumes:\n- name: Move the disk to NVMe storage delegate_to: localhost community.proxmox.proxmox_disk: api_host: \u0026#34;{{ proxmox_api_ip }}\u0026#34; api_user: ansible@pve api_token_id: automation api_token_secret: \u0026#34;{{ proxmox_token_secret }}\u0026#34; vmid: \u0026#34;{{ created_vm.vmid }}\u0026#34; disk: scsi1 target_storage: nvme-pool bwlimit: 200000 delete_moved: true timeout: 3600 state: moved target_storage verschiebt innerhalb einer VM; target_vmid gibt die Platte einer anderen VM und verlangt denselben Speicher auf beiden. Sie schließen sich gegenseitig aus. delete_moved steht voreingestellt auf false, du endest also standardmäßig mit zwei Kopien und dem Original, das unbenutzt herumliegt — sicher, und ein guter Weg, einen Speicherpool zu füllen, wenn du nie zurückkommst.\ntimeout steht hier voreingestellt auf 600, gegen 30 in proxmox_kvm. Gleich aussehender Parameter, zwanzigfacher Unterschied, denn diese Vorgänge kopieren Daten. Setz ihn für große Abbilder oder langsamen Speicher höher — die Dokumentation sagt das für moved und für import_from.\nWas zu der Option führt, die dieses Modul zum Weg für V2V und Cloud-Abbilder macht:\nimport_from: \u0026#34;vmdata:9000/base-debian13.qcow2\u0026#34; import_from baut die Platte aus einem vorhandenen Volume, statt ein leeres zuzuteilen — \u0026lt;STORAGE\u0026gt;:\u0026lt;VMID\u0026gt;/\u0026lt;NAME\u0026gt;, oder \u0026lt;STORAGE\u0026gt;:import/\u0026lt;NAME\u0026gt; über das Import-Verzeichnis des Speichers ab PVE 9.x. Es schließt sich mit size gegenseitig aus, und nur root darf absolute Dateisystempfade nutzen.\nDer Rest der Parameterliste ist der Grund, Platten mit diesem Modul anzuhängen statt inline im Anlege-Aufruf: cache, aio, iothread, discard, ssd, backup, detect_zeroes, und die ganze Drosselfamilie — iops, iops_rd, iops_wr, ihre _max- und _max_length-Varianten, und die bps_*_max_length-Steuerung für Stöße. Nichts davon ist über proxmox_kvm nach dem Anlegen erreichbar.\nZwei Vorbehalte, beide aus der eigenen Dokumentation des Moduls:\nManche Optionsänderungen brauchen einen Neustart. „Some updates on options (like cache) are not being applied instantly and require VM restart.“ Ein grüner Task heißt, dass die Konfiguration geschrieben wurde, nicht dass die laufende VM sich anders verhält. Es unterstützt den Check-Mode nicht. check_mode: none, wie proxmox_kvm. Die Collection teilt sich also mitten durch: NIC-Änderungen kann man mit --check üben, Plattenänderungen nicht. Die Arbeitsteilung Um das zu tun Nimm Die VM anlegen proxmox_kvm, einmal, an der Existenz getort Kerne, Speicher, Tags, Agent, onboot ändern proxmox_kvm mit update: true Eine NIC anlegen, umtaggen, trennen oder entfernen proxmox_nic Eine Platte anlegen, vergrößern, verschieben, abtrennen oder entfernen proxmox_disk Momentaufnahme proxmox_snap (auch voller Check-Mode) Alles, was keines davon offenlegt qm set über SSH Eine Platte oder NIC über proxmox_kvm ändern nichts — dafür ist update_unsafe da, und deshalb solltest du es nicht nutzen Bau die VM mit einem knappen proxmox_kvm-Aufruf, dann häng die Platten und Schnittstellen mit ihren eigenen Modulen an. Es sind mehr Tasks, und es ist die Fassung, in der Änderungen am zweiten Tag einen Weg haben, der nicht über eine Option führt, deren dokumentiertes Risiko der Verlust einer Platte ist.\nWo das Modul aufhört proxmox_kvm hat eine riesige Parameterliste und deckt dennoch nicht alles ab, was qm kann. Statt zu warten, fällt das produktive Playbook auf die Kommandozeile des Knotens zurück:\n- name: Set RNG source and better SPICE quality delegate_to: \u0026#34;{{ proxmox_api_host }}\u0026#34; become: true ansible.builtin.command: cmd: \u0026gt;- /usr/sbin/qm set {{ created_vm.vmid }} --rng0 source=/dev/urandom --spice_enhancements videostreaming=all Daran ist nichts falsch. Es ist in keinem sinnvollen Sinn idempotent — qm set ist ein Schreiben und wird jeden Lauf changed melden —, aber es ist ausdrücklich, es ist lesbar, und es gibt nicht vor, etwas anderes zu sein. Bekommt ein Modul den Parameter später, löschst du den Task.\nAnderes braucht einen zweiten Durchgang durch das Modul mit update: true, weil es nicht im selben Aufruf gesetzt werden kann, der die VM anlegt:\n- name: Add SPICE-compatible USB device delegate_to: localhost community.proxmox.proxmox_kvm: api_host: \u0026#34;{{ proxmox_api_ip }}\u0026#34; api_user: \u0026#34;{{ proxmox_user }}\u0026#34; api_password: \u0026#34;{{ proxmox_password }}\u0026#34; node: \u0026#34;{{ proxmox_api_host }}\u0026#34; vmid: \u0026#34;{{ created_vm.vmid }}\u0026#34; usb: usb0: \u0026#34;spice,usb3=1\u0026#34; update: true when: spice_usb | default(false) Beachte, dass es vmid übergibt, nicht name. Sobald du die ID hast, nutz sie. Sie ist der einzige Bezeichner, den die API als eindeutig behandelt.\nUnd für die Dinge, die QEMU kann und für die PVE keine Option hat, gibt es args, das wortwörtlich an die QEMU-Kommandozeile weitergegeben wird:\nargs: \u0026gt;- -global scsi-hd.physical_block_size=4k -global scsi-hd.logical_block_size=4096 Das zeigt die virtuelle Platte als 4Kn statt 512e, und das zählt mehr, als es klingt — Blockgrößen, 4Kn und 512e. Das Modul beschriftet args mit „for experts only“, und der Grund ist, dass PVE es nicht prüft und ein falsches Flag die VM nicht starten lässt, mit einem Fehler, der von QEMU kommt und nicht von Proxmox.\nDer Cluster ist nicht sofort einig - name: Let registration complete on cluster ansible.builtin.pause: seconds: 5 when: created_vm.changed Ein pause in einem Playbook riecht meist, und dieses trägt Last. Der Anlege-Aufruf kehrt zurück, wenn die API die Definition angenommen hat, und das ist nicht dasselbe, wie dass jeder Knoten der Existenz der VM zustimmt — und der unmittelbar nächste Task will eine ACL auf /vms/\u0026lt;vmid\u0026gt; setzen. Fünf Sekunden Geduld sind billiger als eine Wiederholschleife um einen Fehler, der nur unter Last auftritt.\nDas Abbau-Playbook hat aus demselben Grund dieselbe Form: stoppen, warten, dann löschen.\nZurücklesen, was du gebaut hast proxmox_kvm dokumentiert drei Rückgabewerte: vmid, status und msg. In der Praxis willst du einen vierten, und der steht nicht in der Dokumentation.\n- name: Get MAC address of VM ansible.builtin.set_fact: primary_mac_addr: \u0026#34;{{ created_vm.mac.net0 }}\u0026#34; created_vm.mac ist echt — das Modul baut es in get_vminfo() und klatscht es ins Ergebnis —, aber es fehlt im dokumentierten RETURN-Block, was heißt, dass nichts verspricht, dass es weiter funktioniert. Es ist wert, genau zu wissen, wie es sich verhält, denn es hat zwei Fallstricke:\nEs erscheint nur, wenn das Modul die VM tatsächlich angelegt hat. mac wird nur auf dem Weg des Anlegens und Ausrollens zusammengesetzt. Nimm den Zweig „existiert schon“, und das Ergebnis hat vmid und msg und nichts weiter. Es enthält nur die Schnittstellen, die du übergeben hast. Der Code geht die Parameter durch, die du geliefert hast, sucht die heraus, die auf net[0-9] passen, und liest die gespeicherte Konfiguration jeder einzelnen aus der API zurück. Kein net-Parameter, kein mac-Schlüssel. Deshalb braucht das produktive Playbook beide Hälften, und die zweite ist hässlich:\n- name: Get MAC address of VM ansible.builtin.set_fact: primary_mac_addr: \u0026gt;- {{ created_vm.mac.net0 if created_vm is defined and created_vm.changed else ((existing_vm.proxmox_vms[0].config.net0 | split(\u0026#39;,\u0026#39;))[0] | split(\u0026#39;=\u0026#39;))[1] }} Existierte die VM schon, gibt es kein mac, die MAC muss also aus der rohen Konfigurationszeichenkette gegraben werden. net0 kommt von der API als virtio=AE:AE:5C:A8:89:85,bridge=vmbr0 zurück, also: an Kommas trennen, das erste Feld nehmen, an = trennen, die zweite Hälfte nehmen. Es ist Zeichenketten-Chirurgie an einer API-Antwort, und es ist der ehrliche Preis eines Moduls, dessen Rückgabeform davon abhängt, welchen Zweig es genommen hat.\nBrauchst du die MAC in beiden Fällen verlässlich, hol sie bedingungslos von proxmox_vm_info und wert eine Form aus statt zweier.\nEs aus einer verlässlichen Quelle antreiben Sieh die Zeile am Kopf des Plays noch einmal an:\nhosts: \u0026#34;{{ target_hosts | default(\u0026#39;cluster_pve:\u0026amp;status_planned\u0026#39;) }}\u0026#34; Das ist die eigentliche Architektur, und es ist klar zu sagen wert: die zu bauenden VMs sind keine Liste in einer Vars-Datei. Sie sind die Hosts in deinem Inventar, deren erfasster Status sagt, dass sie existieren sollen und noch nicht existieren.\nDas Inventar hier ist NetBox. Eine VM wird angefordert, indem ein NetBox-Datensatz mit dem Status planned angelegt wird, der CPU, Speicher, Platte, VLAN, Eigentümer und Plattform trägt. Das Playbook wählt die planned-Maschinen aus, baut sie, teilt eine IP zu, schreibt DNS und setzt den Datensatz dann auf staged — und ab dann passt dieser Host nicht mehr auf das Host-Muster des Plays, und ein Handler aktualisiert das Inventar, damit das nächste Play den neuen Zustand sieht:\nhandlers: - name: Refresh inventory ansible.builtin.meta: refresh_inventory Das Statusfeld ist ein Zustandsautomat, das Playbook ist ein Übergang darin, und das Ganze ist wiederholbar, weil ein Host, der schon weitergegangen ist, nicht mehr ausgewählt wird. Das ist eine viel bessere Eigenschaft als jede Menge Idempotenz auf Modulebene, und es ist der Grund, warum der Anlege-Task damit durchkommt, ein Einmalschuss zu sein.\ncommunity.proxmox liefert auch ein eigenes Inventar-Plugin mit, das ein Inventar aus dem Cluster baut — die richtige Wahl, wenn Proxmox die verlässliche Quelle ist. Hier ist es umgekehrt: NetBox ist maßgeblich, und Proxmox ist, wo seine Absicht Wirklichkeit wird. Das ist ein eigener Beitrag, und ich schreibe ihn gesondert.\nEs wieder wegnehmen Anlegen ohne Abbau ist ein halber Lebenszyklus, und der Weg zum Entfernen hat seinen eigenen Fallstrick — eine laufende VM kann man nicht löschen:\n- name: Force stop the VM if it is running delegate_to: localhost community.proxmox.proxmox_kvm: api_host: \u0026#34;{{ proxmox_api_ip }}\u0026#34; api_user: \u0026#34;{{ proxmox_user }}\u0026#34; api_password: \u0026#34;{{ proxmox_password }}\u0026#34; name: \u0026#34;{{ inventory_hostname }}\u0026#34; state: stopped force: true timeout: 10 - name: Allow the cluster to stop the VM before removing it ansible.builtin.pause: seconds: 10 - name: Remove the VM from the cluster delegate_to: localhost community.proxmox.proxmox_kvm: api_host: \u0026#34;{{ proxmox_api_ip }}\u0026#34; api_user: \u0026#34;{{ proxmox_user }}\u0026#34; api_password: \u0026#34;{{ proxmox_password }}\u0026#34; name: \u0026#34;{{ inventory_hostname }}\u0026#34; state: absent force: true timeout: 10 state: stopped ist ein sanftes Herunterfahren, und das Zusammenspiel mit timeout ist dokumentiert und wert, es sich zu merken: wird die Zeit mit force: true erreicht, wird die VM hart abgeschaltet; mit force: false scheitert der Task stattdessen. Zehn Sekunden sanftes Fenster, gefolgt vom Ziehen des Steckers, ist eine vernünftige Regel für eine Maschine, die abgebaut wird, und eine schlechte für alles andere.\nDer volle Abbau (proxmox-remove-vms.yml) wickelt dann den Rest des Datensatzes ab: DNS, die zugeteilte IP, die NetBox-Schnittstellen, die NetBox-VM und die alten Einträge in known_hosts. Es hüllt den Block in ignore_errors: true, was in einem Abbau vertretbar ist. Du entfernst Dinge, die schon weg sein können, und eine halb gelöschte Maschine ist schlimmer als ein lautes Protokoll.\nWas ich in einem frischen Aufbau ändern würde Nachdem ich den Modul-Quellcode gelesen habe und nicht bloß seine Dokumentation, vier Dinge:\nNimm ein API-Token, nicht api_user plus api_password. Eingegrenzt, widerrufbar, und es gehört nie einer Person. Setz validate_certs ausdrücklich, bevor 2.0.0 es dir unter den Füßen wegzieht. Teil die VMID selbst zu aus der verlässlichen Quelle. Es beseitigt das Rennen um Lesen-Ändern-Schreiben, lässt dich serial: 1 weglassen und gibt jedem späteren Task einen festen Bezeichner statt eines Namens, der nicht eindeutig ist. Leg die VM nackt an, dann häng ihre Platten und NICs mit proxmox_disk und proxmox_nic an. Mehr Tasks, aber jede Platte und jede Schnittstelle hat dann ein Modul, das sie später ändern kann — samt create: disabled für Änderungen nur an Optionen und state: detached statt Löschen — und keine Konfiguration, die nur über update_unsafe zu ändern ist. Hol die MAC von proxmox_vm_info an einer Stelle, damit eine Form auszuwerten ist statt einer Bedingung über einen dokumentierten und einen undokumentierten Rückgabewert. Und greif auf einem Bau-Playbook nicht nach --check. Das Modul, auf das es ankommt, kann es nicht achten.\nEin Trockenlauf, der immer ja sagt, ist schlimmer als kein Trockenlauf, denn du wirst ihm glauben.\nQuellen Dokumentation der Collection community.proxmox — die ganze Fläche von 47 Modulen community.proxmox auf GitHub — wo der Quellcode von oben liegt; plugins/modules/proxmox_kvm.py ist die Datei, die man liest, wenn die Dokumentation mehrdeutig ist Moduldokumentation von proxmox_kvm — die Parameterliste und die oben zitierten Warnungen zu update und update_unsafe Moduldokumentation von proxmox_vm_info — config: current und config: pending PVE-Optionsreferenz zu qm — die eigentliche Spezifikation für jede scsi[n]-, net[n]- und boot-Zeichenkette, die du durchgibst proxmoxer — der Python-Client, auf dem die Collection aufbaut damo2929/ansible-example — die Playbooks, aus denen diese Auszüge kommen, samt NetBox-gestütztem Inventar, DHCP-Erzeugung und Hypervisor-Aufbau ","permalink":"https://blogs.damiendye.uk/de/ansible/proxmox-create-vms-community-proxmox/","summary":"Die Collection community.proxmox ist ein API-Client und kein Konfigurationsagent, und das ändert die Form jedes Playbooks, das sie nutzt. Wo die Tasks tatsächlich laufen, warum proxmox_kvm sich verweigert statt zu konvergieren, warum Änderungen an Platten und NICs zu proxmox_disk und proxmox_nic gehören, und der undokumentierte Rückgabewert, den du am Ende brauchst.","title":"Proxmox-VMs mit Ansible anlegen — der Host, den du baust, existiert noch nicht"},{"content":"Die Frage, mit der jede Proxmox-Bewertung anfängt „Ist Proxmox wirklich für Unternehmen tauglich?“\nSie kommt in fast jedem Migrationsgespräch auf, und die Sorge darunter ist so gut wie nie die Weboberfläche. Niemand fürchtet ernsthaft, dass ein Browser-Dashboard seine Daten verdirbt. Was Leute fragen, ist, ob das Ding, das zwischen einer virtuellen Maschine und der Hardware steht — das Bauteil, das einen Mieter aus dem Speicher eines anderen Mieters heraushalten muss, für immer, ohne einen einzigen Fehler — ein ernstes Stück Technik ist oder ein Gemeinschaftsprojekt, das beliebt geworden ist.\nGenau davor sollte man nervös sein. Es zielt bloß auf die falsche Schicht, denn Proxmox VE enthält keinen Hypervisor.\nDer Hypervisor ist KVM. Er ist Teil von Linux, er ist seit 2007 da, und nutzt deine Organisation EC2, Google Cloud, Oracle Cloud, Alibaba Cloud, DigitalOcean oder Nutanix, dann fährst du ihn heute schon produktiv — du hast bloß nie darüber nachdenken müssen, weil jemand anders die Schichten darüber besaß.\nDieser Beitrag handelt davon, was dieses gemeinsame Fundament tatsächlich bedeutet. Beide Hälften davon: der Teil des Arguments, der wirklich hält, und der Teil, der in Hersteller-Folien überzogen wird.\nProxmox VE ist eine Verwaltungsschicht Virtualisierung auf Linux sind vier verschiedene Schichten, von vier verschiedenen Gruppen Menschen gebaut und gepflegt.\n1. Hardware-Virtualisierungserweiterungen. Intel VT-x mit EPT, oder AMD-V mit NPT. Silizium. Das ist, was einen Gast befähigt, seinen eigenen Kernel mit voller Geschwindigkeit und eigenen Seitentabellen zu fahren, ohne dass etwas Befehle nachbildet.\n2. KVM — der Hypervisor. Kernel-Module: kvm.ko für den architekturunabhängigen Kern, plus kvm-intel.ko oder kvm-amd.ko für die Herstellererweiterungen. Das ist das Bauteil, das die Isolationsgrenze besitzt. Es setzt die Kontrollstrukturen der virtuellen Maschine des Gastes auf, behandelt VM-Exits, verwaltet die Seitentabellen der zweiten Ebene und liefert Interrupts.\n3. Der VMM — der Virtual Machine Monitor, im User Space. Auf Proxmox VE ist das QEMU. Es baut das virtuelle Mainboard: Chipsatz, PCIe-Topologie, Platten, NICs, seriell, Firmware. KVM fährt die CPU; QEMU entscheidet, welche Hardware der Gast zu haben glaubt.\n4. Die Verwaltungsschicht. Das ist Proxmox VE: pve-manager und pveproxy für API und Oberfläche, qemu-server, um aus einer VM-Konfigurationsdatei eine QEMU-Kommandozeile zu machen, pve-container für LXC, pmxcfs auf Corosync für die replizierte Cluster-Konfiguration, pve-ha-manager für Fencing und Neustart, plus Firewall und SDN-Stapel.\nDiese vier Schichten gibt es auch auf der Plattform, von der du migrierst, und sie machen dieselben vier Aufgaben — vCenter ist Schicht 4, VMkernel ist Schicht 2 —, und ich komme auf diesen Vergleich zurück, sobald die Teile auf dem Tisch liegen.\nDieselben vier Schichten auf Proxmox VE und auf vSphere Proxmox VE VMware vSphere 4 \u0026#183; Verwaltung Proxmox VE pve-manager \u0026#183; pveproxy \u0026#183; qemu-server pmxcfs auf Corosync \u0026#183; pve-ha-manager \u0026#183; SDN vCenter Server eine eigene Appliance zu bemessen, lizenzieren, patchen und sichern 3 \u0026#183; Gerätemodell pve-qemu, im User Space das virtuelle Mainboard: Chipsatz, PCIe, Platten, NICs Upstream-QEMU + 78 Proxmox-Patches 2 \u0026#183; Hypervisor \u0026#183; die Isolationsgrenze KVM \u0026#8212; kvm.ko + kvm-intel.ko / kvm-amd.ko vCPU-Eintritt und -Exit \u0026#183; EPT/NPT \u0026#183; Interrupts Upstream-Linux, in einem Proxmox-Kernel-Build die VMX-Userworld, eine je VM Geräte-I/O, Momentaufnahmen, Fernkonsole User Space \u0026#8212; nicht im Kernel VMkernel, plus ein VMM je vCPU Gastbefehle und Speicher VMwares eigene Worte für VMkernel: \u0026#8220;a POSIX-like operating system\u0026#8221; 1 \u0026#183; Silizium Intel VT-x + EPT \u0026#183; AMD-V + NPT dasselbe Silizium Dieselben vier Schichten auf beiden Seiten. Proxmox schreibt Schicht 4, patcht Schicht 3 stark, baut den Kernel von Schicht 2 und nimmt KVM selbst von Upstream. VMware schreibt alle vier und lässt dich keine davon lesen. Was Proxmox tatsächlich pflegt Proxmox VE besitzt Schicht 4 ganz. Es wäre allerdings falsch zu sagen, es packe die Schichten 2 und 3 bloß ein, und das ist das häufigste Missverständnis dessen, was die Firma tut.\npve-qemu trägt zum Zeitpunkt des Schreibens 78 Patches gegen Upstream-QEMU in seiner Series-Datei:\nWas Proxmox QEMU hinzufügt: 78 Patches, maßstabsgetreu extra/ bitmap-mirror/ pve/ 78 Patches, maßstabsgetreu 26 6 46 Zurückportierte Upstream-Behebungen. Auffällig viele sind Sicherheits- behebungen im Gerätemodell: Stride-Prüfung in qxl und virtio-gpu, ein vom Gast auslösbarer intel_iommu-Abbruch, wiedereintretendes DMA in lsi53c895a. Sync-Modi für Dirty-Bitmaps bei drive-mirror. Proxmox' eigene Arbeit: savevm-async, das VMA-Format, der PBS-Blocktreiber, pbs-restore, alloc-track, Backup-Fleecing. Maßstabsgetreu aus debian/patches/series gezeichnet. Der größte Teil der Reihe ist Proxmox\u0026rsquo; eigene Arbeit, und sie sitzt vollständig in Schicht 3 — keiner dieser Patches berührt kvm.ko. Sie bauen auch ihren eigenen Kernel und pflegen Pakete oder Patches für den größten Teil des umgebenden Stapels — pve-edk2-firmware für OVMF, plus lxc, zfsonlinux, openvswitch, libiscsi, corosync-pve, lvm und ceph.\nDie echte Grenze ist also: ganz Schicht 4, erhebliche Arbeit in Schicht 3 und ein Kernel, den sie kompilieren. Was sie nicht getan haben, ist einen Hypervisor zu schreiben. Der KVM-Code von Schicht 2 ist Upstream-Linux.\nUnd nichts davon ist eine Kritik an Proxmox. Es ist eher der Grund, warum man einer Firma von der Größe Proxmox\u0026rsquo; die Aufgabe überhaupt zutrauen kann. Eine kleine Firma in Wien hat sich nicht hingesetzt und einen Hypervisor von Grund auf geschrieben; sie hat auf einem aufgebaut, für dessen Pflege Intel, AMD, Red Hat, Google, Amazon und IBM schon Ingenieure bezahlten, und ihre eigene Kraft in die Schicht darüber und in die Integrationsarbeit gesteckt, die diese Schicht braucht. Dort kann ein Team dieser Größe einen Unterschied machen, und die Patch-Reihe zeigt sie dabei.\nWas KVM tatsächlich ist KVM steht für Kernel-based Virtual Machine, und der Name ist genau: es ist eine Kernel-Funktion, kein Programm.\nLade die Module, und Linux gewinnt ein Zeichengerät, /dev/kvm, plus eine kleine Menge ioctl-Aufrufe darauf — KVM_CREATE_VM, KVM_CREATE_VCPU, KVM_SET_USER_MEMORY_REGION, KVM_RUN. Diese Schnittstelle ist die ganze Hypervisor-API. Alles, was einen Dateideskriptor öffnen und ioctl aufrufen kann, kann virtuelle Maschinen anlegen.\nGeschrieben wurde es von Avi Kivity bei Qumranet und in Linux 2.6.20 aufgenommen, veröffentlicht im Februar 2007 — vor neunzehn Jahren. Red Hat kaufte Qumranet 2008, und KVM ist seither in jeder Kernel-Veröffentlichung ausgeliefert, im üblichen Takt des Kernels von neun bis zehn Wochen. Es ist weit über x86 hinaus portiert worden: arm64, POWER, s390 auf IBM Z und RISC-V.\nDer wichtige Architekturpunkt ist, warum es klein ist.\nKVM hat keinen Scheduler, denn Linux hat einen. Eine vCPU ist ein gewöhnlicher Host-Thread, und der Completely Fair Scheduler legt ihn auf einen Kern wie jeden anderen Thread. Es hat keine Speicherverwaltung, denn Linux hat eine. Gast-RAM ist eine normale Abbildung im User Space, kann also ausgelagert, mit Hugepages hinterlegt oder mit derselben Maschinerie wie bei jedem anderen Prozess auf einen NUMA-Knoten gelegt werden. Es hat keinen Treiberstapel, keine Blockschicht, keinen Netzstapel und kein Dateisystem, denn Linux hatte all das schon, und es sind die, gegen die dein Hardware-Hersteller testet.\nDas ist das eigentliche Reife-Argument, und es ist viel stärker als eine Versionsnummer. Jede Verbesserung am NUMA-Balancing, jede Änderung an io_uring, jeder Netztreiber, jede neue Umgehung eines CPU-Errata, die in Linux landet, landet unter deinen virtuellen Maschinen, denn es gibt keinen eigenen Hypervisor-Kernel, in den es jemand portieren müsste.\nDas Typ-1-Argument zieht die Linie an der falschen Stelle Der Einwand, der darauf folgt, verlässlich, ist, dass KVM „nur ein Typ-2-Hypervisor“ sei. Er laufe auf einem Host-Betriebssystem, anders als ESXi, das auf blankem Blech läuft.\nDiese Einteilung ist drei Jahrzehnte älter als Hardware-Virtualisierung, und das, worum sie eine Linie ziehen wollte, liegt nicht mehr dort, wo alle es vermuten.\nWas tatsächlich passiert, wenn eine vCPU läuft QEMU ruft ioctl(vcpu_fd, KVM_RUN). Die Kontrolle geht an kvm.ko, das den CPU-Zustand des Gastes lädt und VMLAUNCH ausführt. Von diesem Befehl bis zum nächsten VM-Exit läuft der Gast direkt auf dem physischen Kern, im Gastmodus, mit seinen eigenen über EPT aktiven Seitentabellen, mit voller Hardware-Geschwindigkeit. Darunter ist nichts, das irgendetwas auslegt. Das „Host-Betriebssystem“ ist nicht im Weg. Es läuft auf diesem Kern nicht einmal.\nTut der Gast etwas, das behandelt werden muss, tritt die CPU zum Host aus — und landet in kvm.ko, im Kernel, auf genau der Privilegienstufe, die ESXis VMkernel einnimmt. Die meisten Exits werden dort aufgelöst und wieder betreten, ohne dass der User Space je beteiligt ist.\nDer Weg einer vCPU von QEMU in den Gastmodus, und wo ihre Exits enden User Space Kernel \u0026#8212; Ring 0 Host-Modus Gastmodus \u0026#8212; VMX non-root QEMU \u0026#8212; der vCPU-Thread ein gewöhnlicher Host-Thread je vCPU kvm.ko VM-Eintritt \u0026#183; Exit-Behandlung \u0026#183; EPT \u0026#183; Interrupts der Gast, auf dem physischen Kern eigener Kernel, eigene Seitentabellen über EPT mit voller Hardware-Geschwindigkeit ioctl(KVM_RUN) VMLAUNCH VM-Exit hier aufgelöst Exit in den User Space Nichts legt den Gast aus, und der Host läuft auf diesem Kern nicht. Wo ein Exit endet Im Kernel aufgelöst \u0026#183; EPT/NPT-Verletzung \u0026#183; Schreiben in den lokalen APIC \u0026#8212; mit APICv oft kein Exit \u0026#183; Interrupt zwischen Prozessoren, in Hardware gepostet \u0026#183; virtio-net-Türglocke, von vhost-net genommen Erreicht QEMU \u0026#183; Registerzugriff an nachgebildeter e1000 oder IDE \u0026#183; Schreiben in den PCI-Konfigurationsraum \u0026#183; alles, was nur QEMU beantworten kann Nur die zweite Liste zahlt ein Hin und Her im User Space, und es ist die Liste, die du mit virtio-Geräten verkleinerst und einem Maschinentyp, der keine Altgeräte trägt. Der Weg, den eine vCPU nimmt. Alles über der gestrichelten Linie ist ein Host-Thread; alles darunter ist der Gast auf blankem Silizium. Die einzigen Exits, die QEMU erreichen, sind die, die QEMU beantworten muss. ESXi hat dieselbe Aufteilung Sieh nun die Plattform an, die die Unterscheidung angeblich belegt.\nVMwares eigene Architekturdokumentation beschreibt VMkernel als „a POSIX-like operating system“, das „process creation and control, signals, file system, and process threads“ bereitstellt. Das ist ein Betriebssystem, nach der Beschreibung seines Autors. Und eine laufende VM auf ESXi ist kein Ding im Kernel — sie ist eine Gruppe von Userworld-Prozessen: ein VMM je virtuelle CPU, der die Befehle des Gastes virtualisiert und seinen Speicher verwaltet, und ein VMX-Prozess je VM, der das I/O zu den Geräten übernimmt, die nicht leistungskritisch sind, und mit dem Snapshot-Manager und der Fernkonsole spricht.\nLies das mit QEMU im Kopf. Ausführungskontext je vCPU im Kernel, Prozess je VM im User Space, der Geräte nachbildet und verwaltet. VMware hat es aus demselben Grund aufgeteilt wie alle anderen.\nHyper-V ist nicht anders. Microsofts Dokumentation ist ausdrücklich, dass der Virtual Machine Worker Process, vmwp.exe, „a user mode component of the virtualization stack“ ist, je VM gestartet, und dass alle nachgebildeten Geräte darin umgesetzt sind — laufend in der Root-Partition, und die ist Windows. Selbst Xen, die Architektur, auf die die Einteilung am besten passt, braucht ein Linux für allgemeine Zwecke in dom0, um zu funktionieren, und bekommt sein Gerätemodell für voll virtualisierte Gäste von QEMU.\nWo ist die Linie also? Das Kriterium war nie „nutzt es den User Space“. Goldbergs Einteilung von Anfang der 1970er fragt, ob der Hypervisor eine Anwendung ist, die auf einem bereits vorhandenen Betriebssystem läuft, das die Hardware schon besitzt und das Scheduling macht. Das ist ein Typ-2-Hypervisor, ein beherbergter: VMware Workstation, VirtualBox, Parallels Desktop, einfaches QEMU ohne Beschleunigung. Du installierst ein Betriebssystem für allgemeine Zwecke, dann installierst du darauf ein Programm, und dieses Programm bittet das Betriebssystem um Speicher und CPU-Zeit wie jedes andere Programm.\nDas ist nicht, was KVM ist. kvm.ko ist kein Programm auf Linux. Es ist Teil von Linux, es läuft auf derselben Privilegienstufe wie der Code, der die Hardware besitzt, und tritt ein Gast aus, landet er direkt dort. Unter dem Hypervisor gibt es kein Host-Betriebssystem. Der Kernel ist der Hypervisor. Proxmox VE liefert diesen Kernel als das System aus, genau so, wie ESXi VMkernel als das System ausliefert.\nUnd die Fassung „es braucht User Space, also ist es Typ 2“ lässt sich nicht retten, denn gleichmäßig angelegt erwischt sie alles. Keine VM läuft auf ESXi ohne ihren VMX-Prozess, keine auf Hyper-V ohne vmwp.exe, keine auf Xen als HVM-Gast ohne QEMU. Eine Prüfung, die jeden ausgelieferten Hypervisor in einen Eimer legt, unterscheidet nichts.\nKernel, der CPU- und Speichervirtualisierung besitzt Gerätemodell je VM im User Space Braucht ein vorhandenes Host-Betriebssystem? VMware ESXi VMkernel VMX je VM Nein Microsoft Hyper-V Hypervisor plus die Windows-Root-Partition vmwp.exe Nein Xen Xen-Hypervisor plus dom0-Linux QEMU, in dom0 oder einer Stub-Domain Nein KVM kvm.ko QEMU Nein VirtualBox, VMware Workstation der Kernel des Hosts, über einen installierten Treiber die Anwendung selbst Ja Vier Produkte, eine Form — und dann eine fünfte Zeile, die wirklich anders ist. Diese letzte Zeile ist, was „Typ 2“ beschreiben sollte, und es ist die einzige, in der etwas anderes die Hardware schon in der Hand hatte.\nDie Einteilung zieht also durchaus eine Linie. Sie zieht sie bloß nirgends in der Nähe der Stelle, die das Argument annimmt: KVM und ESXi sind auf derselben Seite davon. KVM Typ 2 zu nennen leiht ein Wort aus der VirtualBox-Kategorie und legt es auf etwas, das architektonisch in der ESXi-Kategorie liegt.\nDamit leistet das Etikett in einer Bewertung keine nützliche Arbeit, denn beide Produkte, zwischen denen du wählst, sitzen im selben Kasten. Was sich unterscheidet, ist nicht die Typnummer. Es ist, dass ein Hersteller auch den Kernel geschrieben hat und dich nicht hineinsehen lässt — eine Unterscheidung über Lizenz und Offenheit im Gewand eines Architekturdiagramms. Nutanix zeigt den Punkt kaufmännisch: es liefert denselben KVM-Code aus wie Proxmox und beschreibt AHV als Typ-1-Hypervisor auf blankem Blech. Derselbe Code, umgekehrtes Etikett, andere Marketingabteilung.\nEs steckt doch eine echte Sorge in dem Vorwurf, und sie verdient einen besseren Namen: ein Kernel für allgemeine Zwecke macht tausend Aufgaben, die ein zweckgebauter nicht macht, und das ist mehr Code und mehr Angriffsfläche neben der Isolationsgrenze. Das ist berechtigt und messbar, und ich komme am Ende darauf zurück.\nWo die Arbeit tatsächlich passiert Die eine Stelle, an der das Gefühl „es läuft auf einem Host-Betriebssystem“ einen echten Punkt hat, ist die Behandlung der Exits, und es lohnt sich, klar zu sein, welche Exits wohin gehen.\nDer Gast tut das Behandelt von Kosten Berührt eine Seite, die in EPT/NPT noch nicht abgebildet ist kvm.ko, im Kernel Ein Exit, Mikrosekunden Schreibt in seinen lokalen APIC Die CPU selbst, über APICv/AVIC Oft überhaupt kein Exit Sendet einen Interrupt zwischen Prozessoren Posted Interrupts in Hardware Oft kein Exit Sendet auf einer virtio-net-Queue mit vhost-net Kernel-Thread, kein Sprung in den User Space Eine Türglocke Liest ein Register an einem nachgebildeten e1000 oder IDE-Controller Ganz hinaus zu QEMU Exit plus Hin und Her im User Space Nur die letzte Zeile sieht überhaupt wie das Typ-2-Zerrbild aus — und es ist auch die Zeile, die du wegkonstruierst, indem du virtio-Geräte nutzt und keine nachgebildete Altgeräte-Hardware zeigst, die du nicht brauchst. Das ist dieselbe Begründung wie hinter Q35 statt i440fx: weniger abgefangene Registerzugriffe, weniger Altgeräte, die durchlaufen werden müssen.\nDas Host-Betriebssystem ist eine Funktion, kein Ballast Die andere Hälfte dieser Rechnung schafft es nie in das Argument, also hier ist sie: ein Proxmox-Knoten ist eine Maschine, an der du tatsächlich arbeiten kannst. Es ist Debian, das ganze Debian-Archiv ist also ein apt install entfernt.\nÜberwachung, die du schon fährst — ein Prometheus-Node-Exporter, smartmontools, dein vorhandener Agent — statt dessen, was die Appliance zu zeigen beschließt. Diagnose, wenn etwas langsam ist: fio, iperf3, nvme-cli, perf, bpftrace. Sicherungsagenten von jedem Hersteller, der eine Linux-Binärdatei ausliefert. Konfigurationsverwaltung, sodass der Hypervisor im selben Ansible-Inventar sitzt wie alles andere, statt ein Sonderfall zu sein. fwupd für Firmware, auf Hardware, deren Hersteller LVFS unterstützt. Nichts davon braucht ein Plugin-Format, ein signiertes Bündel oder den Segen eines Herstellers. Vergleich das mit dem ESXi-Modell, wo die Shell absichtlich eingeschränkt ist, Code von Dritten als VIB ankommt und es überhaupt keine Paketverwaltung gibt, nach der man greifen könnte.\nEs greift in den Speicherstapel hinein Überwachungsagenten sind die langweilige Fassung davon. Proxmox\u0026rsquo; eigene Speicherdokumentation listet die eingebauten Plugins — dir, NFS, CIFS, CephFS, ZFS, BTRFS, LVM, LVM-thin, iSCSI, FC/SAS, RBD, ZFS-über-iSCSI, PBS — und fügt dann einen Satz an, den man wörtlich nehmen sollte:\nyou may use all storage technologies available for Debian Linux\nDas ist eine Aussage darüber, wo die Grenze liegt, und der Mechanismus dahinter ist allgemein: hol ein Blockgerät auf jeden Knoten, leg LVM darauf, füg es als LVM-Speicher mit eingeschaltetem shared hinzu. Genau so arbeiten die unterstützten Wege über Fibre Channel und iSCSI, alles, was ein gemeinsames Blockgerät erzeugen kann, kann also denselben Weg nutzen.\nVier Transporte, ein Weg zu gemeinsamem Proxmox-Speicher der Transport was Linux dir gibt was Proxmox sieht Fibre Channel / SAS eingebautes Plugin iSCSI eingebautes Plugin NVMe/TCP oder RDMA kein Plugin \u0026#8212; nvme-cli ATA over Ethernet kein Plugin \u0026#8212; aoetools ein Blockgerät auf jedem Knoten /dev/sdX \u0026#183; /dev/nvme0n1 LVM-Volume-Group shared: 1 storage type: lvm Live-Migration über den Cluster Proxmox VE muss nur die zwei Kästen rechts erkennen. Alles links davon ist die Linux-Blockschicht, und die fragt nicht, wie das Gerät angekommen ist. Zwei dieser Transporte haben ein Proxmox-Plugin und zwei haben überhaupt nichts, und hinter dem zweiten Kasten macht es keinen Unterschied. Die LVM-Schicht ist die Stelle, an der eine gemeinsame LUN zu Cluster-Speicher wird, was sie auch geliefert hat. NVMe over TCP oder RDMA ist der Fall, den man kennen sollte, denn er ist schnell, aktuell und fehlt in dieser Plugin-Liste. nvme-tcp und nvme-rdma sind Host-Treiber im Linux-Baum — NVMe/TCP ist seit 5.0 im Mainline —, es gibt also nichts zu kompilieren. nvme-cli ist ein Debian-Paket (nvme discover, dann nvme connect), und nvmetcli konfiguriert das nvmet-Target im Kernel am anderen Ende. Ein verbundenes Namespace erscheint als /dev/nvmeXnY, und von da an ist es ein gewöhnliches Blockgerät.\nATA over Ethernet macht denselben Punkt vom anderen Ende des Spektrums — alt, obskur, als Plugin genauso nicht unterstützt. Der aoe-Treiber ist im Mainline; aoetools gibt dir aoe-discover und aoe-stat; vblade macht aus jeder Datei oder jedem Blockgerät auf einer anderen Maschine ein Target. Derselbe Weg, dasselbe Ergebnis.\nKeins von beiden ist eine Plugin-API, ein SDK oder ein Zertifizierungsprogramm. Es ist, was passiert, wenn die Speicherschicht des Hypervisors die Linux-Blockschicht ist.\nDie ehrlichen Vorbehalte, denn das liest sich wie ein Partytrick, bis es 3 Uhr morgens ist. Keiner der beiden Transporte ist ein getesteter Proxmox-Speichertyp, die Integration und ihre Fehlerfälle — Verhalten beim Wiederverbinden, Multipath, Zeitüberschreitungen unter Last — gehören also dir, und du musst sie testen, bevor etwas Wichtiges darauf wohnt. Und AoE ist ein nacktes Protokoll auf Schicht 2, nicht routbar und ohne Anmeldung, es gehört also auf ein abgetrenntes Speicher-VLAN und nirgendwo sonst. NVMe/TCP hat zumindest ein Modell für die Entdeckung und lässt sich routen, und das ist ein großer Teil davon, warum es das ist, nach dem man heute greift.\nWer sonst KVM fährt Hier kommt die Behauptung „du fährst es schon“ her. Jede Plattform unten fährt dasselbe Kernel-Modul.\nPlattform Wo du ihm begegnest Der KVM-Teil Der VMM im User Space Amazon EC2 (Nitro) Öffentliche Cloud KVM-Kernmodul Eigen — QEMU entfernt, Gerätemodell in den Nitro-Karten AWS Lambda, Fargate Serverless /dev/kvm Firecracker — ein minimaler MicroVM-Monitor in Rust Google Compute Engine Öffentliche Cloud KVM seit dem Start Googles eigener VMM, absichtlich nicht QEMU Alibaba Cloud ECS Öffentliche Cloud Vereinfachtes KVM (X-Dragon) Eigen, mit Netz und Speicher auf eine MoC-Karte ausgelagert Oracle Cloud (OCI) Öffentliche Cloud Oracle Linux KVM — derselbe Stapel, den Oracle auch vor Ort ausliefert QEMU-Abstammung DigitalOcean, Linode/Akamai, Vultr, Hetzner, OVHcloud, Scaleway, UpCloud Öffentliche Cloud Standard-KVM QEMU Nutanix AHV HCI vor Ort Standard-KVM QEMU mit libvirt und Open vSwitch OpenStack (Nova) Private Cloud Standard-KVM QEMU über libvirt — der voreingestellte und bestgetestete Treiber Apache CloudStack, OpenNebula, oVirt Vor Ort Standard-KVM QEMU über libvirt OpenShift Virtualization, SUSE Harvester Kubernetes Standard-KVM QEMU in einem Pod, über KubeVirt Proxmox VE Vor Ort Standard-KVM QEMU, mit LXC daneben für Container Alle behalten die Kernel-Hälfte und schreiben die User-Space-Hälfte neu Die Hyperscaler haben KVM nicht geforkt. Sie haben die Aufgabe von QEMU geforkt.\nAWS hat EC2 von Xen auf den Nitro-Hypervisor bewegt, der auf dem KVM-Kernmodul aufbaut, mit QEMU vollständig hinausgeworfen. Das Gerätemodell wohnt stattdessen in eigenen Nitro-Karten, und so bekommen sie Leistung, die von blankem Blech nicht zu unterscheiden ist. Jeder EC2-Instanztyp der aktuellen Generation fährt das. Getrennt davon fahren Lambda und Fargate Firecracker, einen zweckgebauten VMM in Rust, der mit demselben /dev/kvm spricht.\nGoogle hat jede Compute-Engine-VM seit dem Start von Compute Engine auf KVM gefahren und einen eigenen VMM im User Space geschrieben statt QEMU zu nutzen, ausdrücklich, um QEMUs riesiger Matrix aus Gästen, Geräten und Modi zu entgehen. Sie sind auch den anderen Weg gegangen und haben das Kernel-Modul im Upstream gehärtet, nachgebildete Geräte entfernt, die niemand brauchte, und die Menge der nachgebildeten Befehle verengt. Diese Arbeit ist in dem KVM, das du fährst.\nAlibaba hat mit X-Dragon dieselbe Form gemacht: ein abgemagerter KVM-Hypervisor mit der Netz- und Speichervirtualisierung auf eine FPGA-gestützte MoC-Karte ausgelagert.\nNutanix AHV ist KVM plus libvirt plus QEMU plus Open vSwitch plus Nutanix\u0026rsquo; Orchestrierung — von jedem kommerziellen Produkt auf dieser Liste der nächste Verwandte, den Proxmox VE hat. Eine andere Schicht 4, und eine sehr andere Rechnung.\nFünf Plattformen, fünf Gerätemodelle, ein KVM Amazon EC2Nitro Google CloudCompute Engine Alibaba CloudECS, X-Dragon NutanixAHV Proxmox VEauf Debian Verwaltung Gerätemodell Hypervisor Hardware EC2-Steuerebene Konsole und API je Instanzstunde GCE-Steuerebene Konsole und API je Instanzstunde ECS-Konsole und API je Instanzstunde Prism und AOS auf jedem Knoten je Knoten, je Jahr pve-manager pveproxy, HA, SDN auf jedem Knoten Abo wahlweise eigener VMM, überhaupt kein QEMU Geräte wohnen auf den Nitro-Karten Googles eigener VMM im User Space, absichtlich nicht QEMU vereinfachter VMM, Netz und Speicher ausgelagert auf eine MoC-Karte QEMU, libvirt und Open vSwitch QEMU, mit LXC daneben KVM \u0026#8212; kvm.ko, kvm-intel.ko / kvm-amd.ko die Isolationsgrenze, und es ist derselbe Code in jeder Spalte Intel VT-x + EPT \u0026#183; AMD-V + NPT Dasselbe Kernel-Modul in jeder Spalte. Was sich den Stapel hinauf ändert, ist das Gerätemodell, dann die Verwaltungsschicht, dann die Lizenzierung — und das ist auch die Reihenfolge, in der sich diese Plattformen tatsächlich unterscheiden. Proxmox VE behält QEMU mit Absicht Es ist verlockend, die Tabelle als Rangliste zu lesen, mit AWS und Google oben, weil sie QEMU ersetzt haben. Das ist die falsche Lesart, denn ihre Randbedingung ist nicht deine.\nAWS und Google fahren ein Hardware-Profil, in einem Maßstab, in dem ein einzelner Fehler in der Geräte-Nachbildung ein flottenweites Ereignis ist, und sie beherrschen jede Gast-Abbildgrenze, die ihnen wichtig ist. In dieser Welt ist QEMUs Breite fast nur Haftung, sie zu löschen ist also offensichtlich richtig.\nDu bist nicht in dieser Welt. Du hast ein Appliance-Abbild von 2013, das eine e1000 will. Du hast eine Windows-VM, deren Maschinentyp für den Rest ihres Lebens festgenagelt bleiben muss. Du hast eine GPU zum Durchreichen, einen nachgebildeten SAS-Controller, um ein Installationsprogramm zufriedenzustellen, einen UEFI-Variablenspeicher zu erhalten. QEMU ist genau das, was eine Plattform für allgemeine Zwecke zu all dem Ja sagen lässt.\nWas AWS Angriffsfläche nennt, nennst du eine Kompatibilitätsmatrix. Beide Beschreibungen sind zutreffend; der Unterschied ist, ob du deine Lasten wählen darfst.\nEs erklärt auch die Form dieser Patch-Reihe. AWS und Google haben Sicherung und Momentaufnahmen außerhalb des VMM gelöst, in ihren eigenen Speicherdiensten. Proxmox hatte keinen Speicherdienst, in dem sie es lösen konnten, also haben sie es in QEMU gelegt — und deshalb existieren savevm-async und der PBS-Blocktreiber als Patches und nicht als Produkte.\nUnd das ist aus einem praktischen Grund zu wissen wert: die Teile von Proxmox VE, die du am meisten vermissen würdest, sind die, die nicht Upstream sind. Deine VM-Konfigurationen sind einfacher Text und deine Plattenabbilder sind Standardformate, eine Maschine wird also umziehen. Aber eine Momentaufnahme samt RAM-Zustand und eine inkrementelle Kette des Proxmox Backup Servers hängen an Proxmox\u0026rsquo; QEMU-Fork. Das ist eine viel leichtere Abhängigkeit als ein geschlossener Hypervisor — der Fork ist öffentlich, AGPL, und du kannst jeden Patch darin lesen —, aber sie ist nicht null, und „keine Bindung auf Softwareebene“ sollte diese Fußnote tragen.\nAlso — ist es für Unternehmen tauglich? Die faule Form dieses Arguments funktioniert nicht, und das ist klar zu sagen wert. „AWS nutzt KVM, also ist Proxmox VE für Unternehmen tauglich“ ist ein Fehlschluss: es nimmt eine Behauptung über eine Schicht und legt sie still auf ein ganzes Produkt.\nHier ist die Fassung, die hält.\nGeteilt ist die Schicht, die am schwersten richtig zu machen und am gefährlichsten falsch zu machen ist. CPU- und Speichervirtualisierung und die Isolationsgrenze zwischen Mietern sind der Teil, in dem ein Fehler ein Einbruch und kein Ausfall ist. Dieser Code wird von Ingenieuren geprüft, die Amazon, Google, Red Hat, Intel, AMD, IBM und Alibaba bezahlen, und seine Fehler werden von den Läden gefunden, die die größten Flotten betreiben, die es gibt — meist, bevor der Kernel dich erreicht. Landet doch eine Lücke, mit der ein Gast entkommt, kommt die Behebung über die normale Kernel-Aktualisierung, die du sowieso einspielen wolltest. Du wartest nicht auf den Veröffentlichungstakt eines Herstellers für einen Hypervisor, den nur dieser Hersteller sehen kann.\nNicht geteilt ist alles über der Grenze. Was heißt, dass die Frage in zwei viel beantwortbarere zerfällt:\nIst die Verwaltungsschicht gut genug für die Art, wie du arbeitest? Kannst du dafür Unterstützung mit Bedingungen kaufen, mit denen du leben kannst? Beides lässt sich in einem Proof of Concept prüfen und in einen Vertrag schreiben. Keines verlangt Glauben an einen Hypervisor.\nDas ist eine viel bessere Lage als die, welche die ursprüngliche Frage annimmt — dass du einem neuartigen Hypervisor von einem kleinen Hersteller vertrauen sollst. Sollst du nicht. Der Proxmox-eigene Code ist eine Verwaltungsschicht, meist in Perl und zunehmend in Rust, plus diese Patch-Reihe gegen QEMU, und beachte, wo die Patches landen: im Gerätemodell und im Sicherungsweg, nicht an der Isolationsgrenze.\nEs ist auch wert zu wissen, was es kostet, wenn die Proxmox-eigene Schicht ausfällt. Die QEMU-Prozesse sind gewöhnliche eigenständige Prozesse auf dem Host, ein umkippender pveproxy hält also keine einzige virtuelle Maschine an. Das ist eine ganz andere Wirkungsweite als das Bauteil zu verlieren, das die Isolationsgrenze besitzt.\nWas „derselbe Hypervisor“ dir nicht kauft Hier hören Vertrauensdokumente von Herstellern meist auf, und das sagt dir etwas darüber, für wen sie geschrieben sind. Es ist die nützlichere Hälfte.\nEs kauft dir nicht die Verlässlichkeit von AWS. Nitros Verfügbarkeit hat sehr wenig mit KVM zu tun. Sie kommt von der Steuerebene, dem Netzgewebe, dem Speicherdienst, der Kapazitätsverwaltung und der betrieblichen Praxis darum herum. Die Verlässlichkeit deines Clusters kommt aus deinem Corosync-Quorum-Entwurf, deiner Fencing-Konfiguration, deiner Speicherwahl und deiner Netzredundanz. KVM hat zu keinem davon eine Meinung. Einen Hypervisor mit einem Hyperscaler zu teilen erbt nicht dessen Betrieb.\nEs kauft dir nicht Nitros Angriffsfläche, und hier landet die berechtigte Hälfte des Typ-2-Vorwurfs. Du fährst QEMU auf einem Kernel für allgemeine Zwecke, und historisch war QEMUs Gerätemodell die Stelle, an der die einprägsamen VM-Fluchten wohnten — VENOM, in einem nachgebildeten Floppy-Controller, den niemand nutzte, ist das kanonische Beispiel. Google konnte damals anmerken, dass Compute Engine genau deshalb nicht betroffen war, weil es QEMU nicht fährt. Du fährst es, die ausgleichenden Maßnahmen sind also deine: virtio statt nachgebildeter Hardware bevorzugen, keine Geräte zeigen, die du nicht brauchst, die AppArmor-Profile in Ruhe lassen, und QEMU mit derselben Disziplin patchen wie den Kernel. Proxmox\u0026rsquo; extra/-Patches sind sie dabei, genau das für dich zu tun, und es ist vernünftig zu prüfen, dass sie es weiter tun.\nEs macht das Verhalten von VMs zwischen Plattformen nicht übertragbar. Die Wahl des CPU-Modells, die Versionierung des Maschinentyps, die Kompatibilität für Live-Migration und das Verhalten der Uhr werden alle in den Schichten 3 und 4 entschieden, und sie unterscheiden sich überall. Ein Cluster mit gemischten CPU-Generationen wird dich weiter dafür bestrafen, den CPU-Typ auf host zu setzen, und Gastuhren laufen weiter auseinander, welches Logo auch auf der Plattform steht. Derselbe Hypervisor ist nicht dasselbe Verhalten.\nEs beantwortet nicht die Frage nach der Unterstützung — und die ist die, die den Einkauf tatsächlich interessiert, und das zu Recht. Proxmox VE ist AGPLv3 und im Produktivbetrieb kostenlos zu fahren. Das Abonnement kauft das für Unternehmen getestete Repository und Hersteller-Unterstützung, ab 120 € je Sockel und Jahr. Proxmox\u0026rsquo; eigene Unterstützung wird zu österreichischen Geschäftszeiten geleistet, Abdeckung rund um die Uhr kommt also von Partnern und nicht aus Wien. croit, wo ich arbeite, ist einer dieser Partner und deckt 24/7 an 365 Tagen im Jahr. Das ist eine kaufmännische Verhandlung und kein technisches Risiko — und dass es eine kaufmännische Verhandlung ist, ist der Sinn von allem oben.\nWas tatsächlich stattdessen zu bewerten ist Ist der Hypervisor erledigt, sollte ein Proof of Concept seine Zeit auf der Schicht verbringen, die wirklich Proxmox-VE-eigen ist:\nFencing und HA. Zieh einem Knoten mit laufenden HA-Gästen den Strom und nimm die Zeit für den Neustart. Dann mach es mit zwei Knoten und bestätige, dass die übrigen sich so verhalten, wie du es erwartest, wenn das Quorum verloren ist. Live-Migration über CPU-Generationen. Mit dem CPU-Modell, auf das du dich tatsächlich festlegen willst, nicht host. Sicherung und, wichtiger, Wiederherstellung. Wiederherstellungszeiten unter Last, nicht Sicherungszeiten. Niemandem wurde je für eine schnelle Sicherung gedankt. Das Rechtemodell. Ob du einem Anwendungsteam Konsole und Ein-Aus-Kontrolle über die eigenen VMs geben kannst und nichts weiter, feinkörnig genug, um einen Prüfer zufriedenzustellen. Die API. Alles, was die Weboberfläche tut, ist ein API-Aufruf; kann deine Automatisierung sie nicht antreiben, passt die Plattform nicht zu deiner Arbeitsweise. Der Aktualisierungsweg. Eine Aktualisierung auf eine neue Hauptversion auf dem PoC-Cluster, bevor 400 VMs darauf sind. Keine davon ist eine Frage über KVM. Das ist eher der Punkt.\nDer Hypervisor ist der erledigte Teil. Verbring den Proof of Concept mit den Teilen, die es nicht sind.\nQuellen KVM selbst\nKVM-API-Dokumentation — die /dev/kvm-ioctl-Schnittstelle, und die ist der ganze Vertrag des Hypervisors Veröffentlichungshinweise zu Linux 2.6.20 — die Veröffentlichung, in die KVM aufgenommen wurde, Februar 2007 Some KVM developments — LWN, Januar 2007, über KVM in den Tagen, nachdem es im Mainline landete Wie die anderen Hypervisoren gebaut sind\nInterpreting virtual machine monitor and executable failures — Broadcoms eigene Beschreibung einer laufenden ESXi-VM als „several processes or userworlds“, mit einem VMM je vCPU und einem VMX je VM The Architecture of VMware ESXi (PDF) — das Whitepaper, das VMkernel „a POSIX-like operating system“ nennt, mit Prozessen, Signalen, Dateisystem und Threads. Über einen Spiegel verlinkt, weil die ursprüngliche VMware-URL die Broadcom-Umstellung nicht überlebt hat, was für sich ein kleiner Kommentar zur Beständigkeit von Herstellern ist Hyper-V-Architektur — Microsoft über den Virtual Machine Worker Process als Bauteil im User Mode, einer je VM, in dem alle nachgebildeten Geräte wohnen The Nutanix Bible — AHV-Architektur — AHV beschrieben als KVM mit libvirt, QEMU und Open vSwitch Wer KVM fährt, und wie sie es verändert haben\n7 ways we harden our KVM hypervisor at Google Cloud — Google über den Betrieb von KVM ohne QEMU und die Härtung, die sie im Upstream gemacht haben Das AWS-Nitro-System — welche EC2-Instanztypen den Nitro-Hypervisor fahren ","permalink":"https://blogs.damiendye.uk/de/proxmox/kvm-the-hypervisor-inside-proxmox-ve/","summary":"„Ist Proxmox für Unternehmen tauglich?“ ist eine Frage über den Hypervisor, und Proxmox VE enthält keinen. Der Hypervisor ist KVM — dasselbe Kernel-Modul unter EC2, Google Cloud, Alibaba Cloud, Nutanix AHV und OpenShift Virtualization. Was Proxmox wirklich pflegt, warum das Typ-1-Argument auf die falsche Linie zielt, und was das gemeinsame Fundament dir nicht kauft.","title":"Proxmox VE ist kein Hypervisor — KVM ist einer, und du fährst ihn schon"},{"content":"Warum HDDs wieder auf der Karte stehen Jahrelang war der Rat einfach genug für einen Klebezettel: leg alles auf SSDs.\nDieser Rat war richtig, und er war auch billig. Beides stimmt jetzt nicht mehr ganz. Das Angebot an NAND ist knapper geworden, die Nachfrage aus der KI hat die Flash-Preise hochgeschoben, und NVMe mit hoher Kapazität ist für eine kostenbewusste Proxmox-Installation schwer zu rechtfertigen — die Art, die betriebsfähig und verlässlich sein muss und so billig, wie Ehrlichkeit es zulässt.\nHDDs für Unternehmen sind aus demselben Grund wieder interessant, aus dem sie es immer waren: Kapazität pro Pfund, und nichts sonst kommt heran.\nDer Haken ist, dass jeder, der VMs auf sich drehenden Platten betrieben hat, weiß, wie schlecht das ausgehen kann. Diese Erfahrung ist echt, und meist ist die Architektur schuld und nicht die Platten.\nDen Platten die Schuld zu geben ist allerdings leichter. Es ist auch falsch, und es ist teuer, denn es redet Leuten Flash ein, den sie nicht gebraucht hätten.\nAlles Folgende geht von Proxmox mit hyperkonvergenten Ceph-OSDs aus, denn dort beißen die Entscheidungen zum Layout tatsächlich.\nDas Problem ist Latenz, nicht Durchsatz Eine moderne Unternehmens-HDD bewegt große sequentielle Daten völlig in Ordnung. Das war nie der Engpass.\nEine Unternehmensplatte mit 7,2k min⁻¹ liefert irgendwo um 80 bis 100 IOPS bei zufälliger Arbeit, denn jede zufällige Operation wartet auf eine Kopfsuche und eine Umdrehung des Tellers. Diese Zahl hat sich in zwanzig Jahren kaum bewegt. Es ist Mechanik, nicht Elektronik. Eine Einsteiger-SSD für Unternehmen ist drei oder vier Größenordnungen davon entfernt.\nGib derselben Platte sequentielle Arbeit, und sie ist ein brauchbares Gerät. Die Rate der Operationen verdoppelt sich etwa, auf rund 200 IOPS, aber jede dieser Operationen trägt jetzt einen großen Block, weil der Kopf schon an der richtigen Stelle ist und weiterströmen kann. Du bekommst also echten Durchsatz, 150 bis 250 MB/s davon, zu einem Preis pro Terabyte, an den nichts anderes herankommt.\nDas ist die wichtige Ungleichheit, und sie heißt nicht „HDDs sind langsam“. Eine sich drehende Platte ist gut bei sequentieller Arbeit und hoffnungslos bei zufälliger, und die zwei Zahlen liegen nur deshalb nah beieinander, weil das Begrenzte die Zahl der Operationen ist und nicht die Byte.\nDas legt die ganze Aufgabe fest. Du versuchst nicht, die Platte schneller zu machen. Das kannst du nicht. Du versuchst dafür zu sorgen, dass sie ihre Zeit in dem Modus verbringt, in dem sie schon taugt, und den kleinen zufälligen Verkehr von ihr wegzuhalten. Damit ist alles Folgende diese eine Idee, zweimal angewandt.\nDas Problem ist, dass virtuelle Maschinen nicht die Last erzeugen, in der HDDs gut sind. Sie erzeugen Metadaten-Aktualisierungen, Journal-Schreibvorgänge, kleine synchrone Leerungen, Protokollierung, Hausarbeit des Dateisystems und Stöße zufälliger Aktivität von einem Dutzend Gästen gleichzeitig, die verschachtelt an der Platte eintreffen.\nHoffnungslos bei zufälliger Arbeit, wirklich gut bei sequentieller — in welchem Modus die Platte läuft, ist der ganze Entwurf Operationen pro Sekunde, ein Gerät — Balken nicht maßstäblich, denn drei Größenordnungen passen nicht 7,2k-HDD — zufällig 80–100 jede Operation wartet auf eine Suche und eine Drehung — hoffnungslos 7,2k-HDD — sequentiell ~200 und jede trägt einen großen Block: 150–250 MB/s echter Durchsatz NVMe für Unternehmen 100k+ keine bewegten Teile, also keine Suche zu bezahlen Was ein hyperkonvergenter Cluster der Platte tatsächlich schickt Metadaten der Gäste Journal-Schreiben und fsync Protokoll und Hausarbeit RocksDB Metadaten zufällige Stöße, viele Gäste große sequentielle Übertragungen Fünf dieser sechs sind klein und zufällig. Eines davon ist das, worin die Spindel gut ist. Das heißt nicht „HDDs sind langsam“. Eine sich drehende Platte ist wirklich gut bei sequentieller Arbeit und hoffnungslos bei zufälliger, und die zwei Zahlen liegen nur deshalb nah beieinander, weil die begrenzte Größe die Zahl der Operationen ist und nicht die Byte darin. Die Aufgabe ist also nicht, die Platte schneller zu machen, sondern sie im Modus zu halten, in dem sie schon taugt. Die Raten für zufällige und sequentielle Operationen liegen überraschend nah beieinander, denn begrenzt ist die Zahl der Operationen und nicht die Byte, die jede trägt. Sequentiell ist die Stelle, an der die Platte ihr Geld verdient; ein hyperkonvergenter Cluster schickt ihr von Natur aus die andere Art Arbeit. Ceph legt seine eigene Schicht darauf. Jeder Schreibvorgang trägt neben den Daten RocksDB-Metadaten-Aktualisierungen. Landet all das auf nackten Spindeln, verbringen die Platten ihre Zeit mit Suchen statt mit Liefern, und du bekommst das Symptom, das jeder Administrator kennt: hohes I/O-Warten, träge Gäste, ungleichmäßige Reaktion und ein Cluster, der sich weit langsamer anfühlt, als sein Datenblatt vermuten lässt.\nDie eigene Hardware-Empfehlung von Ceph ist unmissverständlich darüber, wohin das führt. Sie warnt, man solle „consider carefully the ostensible cost-per-gigabyte advantage of larger HDDs, and the concomitant limitations of IOPS per TB“ — den scheinbaren Vorteil größerer HDDs bei den Kosten pro Gigabyte und die damit einhergehenden Grenzen der IOPS pro TB sorgfältig bedenken —, und sagt, Platten über 8 TB seien „may be best suited for storage of large files / objects that are not at all performance-sensitive“, also am besten für große Dateien und Objekte, bei denen Leistung überhaupt keine Rolle spielt.\nDiese Rechnung lohnt sich, denn die Platten, die das überhaupt wirtschaftlich machen, sind große. 20 TB und mehr. Eine Platte mit 20 TB macht weiter ihre 80 bis 100 zufälligen IOPS, denn Kapazität kauft dir überhaupt keine Operationen. Sie bietet also etwa 4 bis 5 zufällige IOPS pro Terabyte, wo eine Platte mit 8 TB rund elf schafft und eine mit 2 TB vierzig.\nNach Cephs eigenem Maß liegt eine Spindel mit 20 TB also deutlich in dem Gebiet, auf das es dir sagt, keine leistungsempfindliche Arbeit zu legen.\nDas ist kein Argument dagegen, sie zu kaufen. Es ist der Grund, warum der Rest dieses Beitrags existiert. Der Entwurf unten ist genau das, was eine Spindel mit 20 TB für VM-Speicher tragfähig macht, indem er dafür sorgt, dass die kleine zufällige Arbeit sie nie erreicht.\nDie Metadaten von der Spindel wegholen Die wertvollste Änderung an einem Cluster auf HDDs ist, die Spindel nicht mehr Cephs Buchhaltung speichern zu lassen.\nBlueStore hält pro OSD drei Dinge: die Daten selbst auf block, die RocksDB-Metadatenbank auf block.db und das Write-Ahead-Log auf block.wal. Standardmäßig wohnen alle drei auf demselben Gerät. Leg block.db stattdessen auf NVMe, und eine große Menge kleines zufälliges I/O verlässt die Platte vollständig.\nCephs Hardware-Dokumentation sagt es klar: „HDD OSDs may see a significant write latency improvement by offloading WAL+DB onto an SSD“ — HDD-OSDs können eine deutliche Verbesserung der Schreiblatenz sehen, wenn man WAL und DB auf eine SSD auslagert.\nBlueStore-OSD-Layout: alles auf der Spindel gegen Metadaten auf NVMe Voreinstellung: ein Gerät hält alle drei Objektdaten-Schreibvorgänge RocksDB-Metadaten Eine 7,2k-HDD block block.db .wal Beide Ströme teilen ein Budget von 80 IOPS. Die Platte sucht bei jedem Schreibvorgang zwischen Daten und Metadaten. block.db auf NVMe: die Metadaten gehen Objektdaten-Schreibvorgänge RocksDB-Metadaten 7,2k-HDD block — nur Daten NVMe für Unternehmen block.db .wal Die Spindel macht jetzt eine Aufgabe. Nenn ein DB-Gerät, und das WAL geht mit. Bemiss\u0026#160;block.db\u0026#160;auf 1–2 % von\u0026#160;block\u0026#160;bei RBD-Lasten, oder 2,5 %, um bequem zu sitzen. Bemiss es zu klein, und RocksDB scheitert nicht — es fällt zurück auf die Spindel, und das ist das eine Ergebnis, das den gerade gekauften Flash verschwendet. Nützliche Größen springen bei etwa 3 GB, 30 GB und 300 GB, denn eine DB-Partition kann nur Größen voll nutzen, die den Summen der Ebenen von RocksDB entsprechen. Auf die nächste Stufe aufzurunden ist meist billig; abrunden bringt nichts. Links alles auf einer Spindel: Daten-Schreibvorgänge und RocksDB-Aktualisierungen konkurrieren um dieselben gut 80 IOPS. Rechts block.db auf NVMe: der Metadatenverkehr verlässt die Platte, und der Spindel bleibt das Eine, worin sie gut ist. Nimm hier richtige NVMe für Unternehmen, keinen Consumer-Flash. Der Grund sind nicht die Zahlen auf dem Titelblatt. Es ist gleichmäßige Latenz unter Dauerlast, und Schutz bei Stromverlust. Cephs Dokumentation ist direkt: „Enterprise-class SSDs are best for Ceph: they feature power loss protection (PLP)“, SSDs der Unternehmensklasse sind für Ceph am besten, denn sie haben Schutz bei Stromverlust, und „bargain client-class or off-brand SSDs are a false economy“, billige Client-SSDs oder solche ohne Namen sind Sparen am falschen Ende.\nSamsung PM9A3 und Micron 7450 Pro sind die Klasse, die hierher gehört. Unter Schreibdruck kümmert sich Ceph weit mehr um Gleichmäßigkeit als um Spitzenwerte, und genau das trennt eine Platte für Unternehmen von einer schnellen für Consumer.\nblock.db bemessen, und was Überlaufen kostet Bemiss es falsch, und der Nutzen verpufft still, denn wenn block.db voll wird, scheitert RocksDB nicht — es fällt zurück auf das langsame Gerät, genau dorthin, wo es ohne die NVMe gewesen wäre.\nDas ist das Schlechteste von beidem: du hast den Flash gekauft und suchst weiter auf der Spindel.\nDie aktuelle Empfehlung von Ceph:\nLast block.db als Anteil von block RBD / Block — VM-Platten 1 % bis 2 % RGW / Objekt mindestens 4 % Allgemeine Empfehlung beim Auslagern von WAL+DB mindestens 2,5 % VM-Speicher unter Proxmox ist die RBD-Zeile, 1–2 % sind also die ehrliche Planungszahl, und 2,5 % sind ein bequemer Platz.\nRechne das gegen eine Platte mit 20 TB, und die Zahlen holen deine Aufmerksamkeit:\nblock.db für eine OSD mit 20 TB Bei 1 % 200 GB Bei 2 % 400 GB Bei 2,5 % 500 GB Nimm das mit den RocksDB-Ebenenstufen weiter unten, und 300 GB pro OSD sind der sinnvolle Landeplatz. Die nützliche Stufe, die der Mitte des Bereichs am nächsten liegt.\nDas ändert, was das gemeinsame Metadatengerät eigentlich ist. Acht OSDs mit 20 TB wollen 2,4 TB NVMe zwischen sich; fünfzehn davon, Cephs angegebenes Maximum hinter einer NVMe, wollen 4,5 TB. Auf so großen Platten entscheidet die DB-Kapazität, wie viele OSDs hinter ein Gerät passen, nicht das Verhältnis. Dir gehen die Gigabyte weit früher aus als Cephs Segen.\nEs gibt noch einen Haken, der es wert ist, denn er macht intuitives Bemessen falsch. Die Ebenenstruktur von RocksDB heißt, dass eine DB-Partition nur Größen voll nutzen kann, die den Summen ihrer Ebenen entsprechen — historisch mit nützlichen Stufen um 3 GB, 30 GB und 300 GB, wobei Größen dazwischen nichts über die Stufe darunter hinaus bringen. 18 GB auf 30 GB aufzurunden ist in der Praxis oft kostenlos; sie auf 20 GB abzurunden bringt dir im schlimmsten Fall nichts über 3 GB hinaus.\nPrüf auf Überlaufen, nachdem der Cluster eine Weile gelaufen ist, nicht am ersten Tag. Es ist ein Problem, das langsam einsetzt.\nDu brauchst kein eigenes WAL-Gerät Das spart eine Partition und viel Gefummel.\nGibst du ein DB-Gerät an und kein ausdrückliches WAL-Gerät, legt Ceph das WAL automatisch mit der DB auf das schnelle Gerät. Die Dokumentation stellt fest, dass „whenever a DB device is specified but an explicit WAL device is not, the WAL will be implicitly colocated with the DB on the faster device“ — wann immer ein DB-Gerät angegeben ist und ein ausdrückliches WAL-Gerät nicht, wird das WAL stillschweigend mit der DB auf das schnellere Gerät gelegt.\n„DB und WAL auf NVMe legen“ ist also das richtige Ziel, aber es ist ein Argument und nicht zwei. Ein eigenes block.wal hat nur Sinn, wenn du eine dritte, schnellere Ebene hast, auf die es kann.\nDen Schreibcache der HDD abschalten Klein, unglamourös und leicht zu übersehen.\nCephs Dokumentation hält fest, dass die Leistung einer OSD „may be dramatically increased … by disabling this write cache“ auf HDDs, also drastisch steigen kann, wenn man diesen Schreibcache abschaltet. Der flüchtige Cache in der Platte sortiert Schreibvorgänge um und verzögert sie auf Weisen, die Cephs Leerungssemantik zuwiderlaufen, und ihn abzuschalten macht die Sache meist schneller statt langsamer.\nSobald bcache im Spiel ist, wird es Pflicht statt Empfehlung, und das ist der nächste Abschnitt.\nWährend du dabei bist: du brauchst keinen HBA mit RAID-Fähigkeit. Ceph sagt es direkt: „You do not need an RoC (RAID-capable) HBA.“ Gib den OSDs die Platten.\nEine Optane pro Spindel Die Metadaten von der Platte wegzuholen behebt den Dauerzustand. Es behebt keine Stöße, denn ein Stoß kleiner synchroner Schreibvorgänge muss weiter bestätigt werden, und die Spindel bestätigt weiter mit Spindelgeschwindigkeit.\nDafür ist bcache da, und was es hier funktionieren lässt, ist Optane.\nWorauf es ankommt, ist nicht Kapazität. Es ist das Verhalten unter Schreiblast. Gegen NAND bietet Optane sehr niedrige Latenz, sehr hohe Haltbarkeit und keine der Klippen der Speicherbereinigung, die die Leistung eines Schreibcaches auf SSD unvorhersehbar machen, sobald sie eine Weile im Einsatz war. Kleinen, stoßweisen, schreiblastigen Verkehr aufzunehmen ist das, worin es das Beste der Welt ist.\nDas Layout, auf das es ankommt: eine Optane pro HDD, jedes Paar sein eigenes bcache-Gerät. Nicht eine Optane, geteilt über ein Regal voll Platten.\nDrei Ebenen, zwei Modelle des Teilens: gepaarter Schreibcache, gemeinsames Metadatengerät Ein Proxmox-Knoten, drei OSDs Schreibvorgänge der Gast-VMs — klein, synchron, stoßweise Ceph-RocksDB-Metadaten bcache0 Optane Schreibcache HDD osd.0 block bcache1 Optane Schreibcache HDD osd.1 block bcache2 Optane Schreibcache HDD osd.2 block Eine Optane pro Spindel — gepaart, nie geteilt Ein Cache-Ausfall kostet genau eine OSD, und die baut Ceph im Alltag neu. Nötige Haltbarkeit hier: 30–100 DWPD. Nur Optane. Gemeinsame Unternehmens-NVMe block.db + stillschweigendes WAL, alle drei OSDs geschützt bei Stromverlust Geteilt, weil Metadaten klein sind Ceph sagt 4–5 HDDs pro SATA-SSD, nicht mehr als 15 pro NVMe. Verlier diese, und jede OSD dahinter geht mit. Unternehmens-NAND genügt — aber schnelle NVMe, keine billige. Beide Ebenen sind nötig, und sie sind nicht derselbe Kauf. Die Optane verkürzt die Bestätigung von Schreibvorgängen; sie tut nichts für die Metadaten-Lesevorgänge, die Ceph ständig absetzt, und schiebt die Metadaten-Schreibvorgänge nur auf. Lass die NVMe weg, und RocksDB ist zurück auf dem Teller. Jeder Schreibvorgang an eine OSD geht über ihr Cache-Gerät, und deshalb muss das eine Optane sein. Das Metadatengerät muss es nicht sein — aber eine schnelle NVMe schon: kleines Schreibvolumen, und trotzdem trägt es die Metadaten-Latenz jeder OSD dahinter. Drei Ebenen, zwei verschiedene Modelle des Teilens. Das DB-/WAL-Gerät ist über mehrere OSDs geteilt, weil das Schreibvolumen von RocksDB klein ist, aber es muss dennoch eine schnelle NVMe sein, denn es trägt die Metadaten-Latenz jeder einzelnen von ihnen. Der Optane-Schreibcache ist eins zu eins mit seiner Spindel gepaart, ein Cache-Ausfall kann also nur je eine OSD kosten. Die Paarung ist eine bewusste Wahl, und sie kauft zwei Dinge.\nKein Gerangel. Jede Spindel bekommt die Latenz und Queue-Tiefe einer ganzen Optane für sich, statt hinter den Stößen von sieben anderen OSDs zu warten.\nEin Fehlerbereich, den Ceph schon zu überleben weiß. Ein gemeinsamer Schreibcache hält schmutzige Daten für jede OSD dahinter, ihn zu verlieren verliert also alle auf einmal; eins zu eins gepaart kostet eine verlorene Optane genau eine OSD. Dieser Unterschied ist die wichtigste einzelne Folge dieses Entwurfs, und er bekommt seine eigene Behandlung unter was du aufgibst.\nDas muss Optane sein. Nicht NAND. Das Wort „Optane“ ist hier keine Markenvorliebe und kein Nice-to-have. Eine NAND-NVMe einzusetzen — wie teuer auch immer — baut etwas, das sich abnutzt, und der Grund ist Haltbarkeit.\nSieh, wo das Cache-Gerät sitzt. Weil dieser Entwurf die sequentielle Umleitung von bcache abschaltet — das sequential_cutoff=0 in der Regel unten —, geht jeder einzelne Schreibvorgang an diese OSD hindurch: nicht nur die Stöße, alles. Das macht den Cache zum Gerät mit dem höchsten Arbeitsanteil im Knoten, das das Schreibvolumen einer ganzen sich drehenden Platte über die Lebensdauer der Maschine aufnehmen soll.\nHaltbarkeit wird in Laufwerksschreibvorgängen pro Tag angegeben, und der Abstand ist nicht schrittweise:\nGerät Angegebene Haltbarkeit Optane P5800X 100 DWPD Optane P4800X 30 DWPD Schreibintensives Unternehmens-NAND, Oberklasse etwa 10 DWPD Unternehmens-NAND für gemischte Nutzung 3 DWPD oder weniger Gängiges Unternehmens-NAND — Klasse PM9A3, 7450 Pro etwa 1 DWPD Optane hat zwischen zehn- und hundertmal die Haltbarkeit des NAND, das du sonst dorthin legen würdest. Steck eine Platte mit 1 DWPD an die eine Stelle, die jeden Schreibvorgang des Clusters bekommt, und du hast keinen Cache gebaut, sondern einen Verbrauchsartikel.\nEs ist schlimmer, als die Tabelle vermuten lässt, denn NAND leidet innen an Schreibverstärkung und Optane nicht. Die angegebenen DWPD einer NAND-Platte sind, was sie an der Schnittstelle nimmt; was ihre Zellen tatsächlich aufnehmen, ist mehr. Optanes Zahl braucht kein solches Sternchen.\nWiederaufbauten sind die Stelle, an der das geprüft wird. Backfill schiebt Terabyte an Schreibvorgängen in einem gedrängten Zeitfenster durch die überlebenden Knoten, jedes Byte davon über ihre Cache-Geräte — ein Ereignis der Haltbarkeit, nicht bloß der Latenz, und es kommt genau dann, wenn du ein zweites Gerät am wenigsten ausfallen lassen willst.\nDie zwei Flash-Ebenen wollen also verschiedene Platten, aus verschiedenen Gründen:\nEbene Schreibvolumen Was das Gerät braucht DB/WAL klein — nur RocksDB Eine schnelle Unternehmens-NVMe. Niedrige Latenz, hohe zufällige IOPS, PLP. Unternehmens-NAND ist die richtige Technik; eine PM9A3 oder 7450 Pro ist der richtige Kauf Schreibcache alles davon PLP und Haltbarkeit im Bereich von Dutzenden DWPD. NAND ist zu jedem Preis die falsche Technik Eine Sorte Platte für beide Aufgaben zu kaufen ist der Fehler, den dieser Abschnitt verhüten soll — lies die erste Zeile aber nicht als Erlaubnis zu sparen, denn kleines Schreibvolumen ist keine kleine Anforderung.\nDas DB-/WAL-Gerät muss weiterhin wirklich schnelle NVMe sein, aus drei Gründen, die nichts damit zu tun haben, wie viele Byte darüber gehen.\nEs bedient jede OSD dahinter gleichzeitig, die Queue, die es sieht, sind also vier oder fünfzehn Sätze Metadatenverkehr, nicht der einer Platte.\nSeine Latenz landet direkt bei deinen Clients. RocksDB-Abfragen liegen auf dem kritischen Weg, um Objekte zu finden, fürs Peering und fürs Scrubbing, und sie sind kleine zufällige Lesevorgänge. Die Last, bei der der Abstand zwischen einer schnellen und einer mittelmäßigen NVMe am größten ist. Jede Mikrosekunde wird mit jeder OSD multipliziert, die davon abhängt.\nUnd Compaction ist stoßweise. RocksDB schreibt seine Ebenen periodisch neu und verwandelt gleichmäßiges Rühren in eine gebündelte Spitze von Lese- und Schreibvorgängen. Ein Gerät, das mit dem Durchschnitt zurechtkommt und an der Spitze hängt, lässt im selben Moment jede OSD dahinter hängen.\nCephs eigene Verhältnisse sind das Anzeichen. Es erlaubt dreimal so viele OSDs hinter einer NVMe wie hinter einer SATA-SSD, und das sagt die Schnittstelle und die Geräteklasse, nicht die Kapazität. Nimm NVMe.\nAlso: das Cache-Gerät muss Optane sein, das DB-/WAL-Gerät darf NAND sein, und keine der beiden Stellen ist die, an der du Geld sparst.\nWelche Optane: eine M10 mit 32 GB täte es oft Nichts davon heißt, die größte Optane sei die richtige. Das Gerät, das du brauchst, entscheidet deine Schreiblast — auch wenn der Gebrauchtmarkt es letztlich unabhängig davon für dich entscheidet. Die Rechnung zählt trotzdem, denn sie sagt dir, was du zu viel oder zu wenig kaufst.\nFang damit an, wofür der Cache da ist. Er hält einen Stoß, nicht eine Platte. Bei writeback_percent=40 gibt ein Gerät mit 32 GB etwa 13 GB schmutzigen Puffer, und das sind sehr viele kleine synchrone Schreibvorgänge.\nLass dich also vom Verhältnis nicht abschrecken. Ein Modul mit 32 GB vor einer Platte mit 20 TB sind 0,16 % davon, was absurd klingt, bis man sich erinnert, dass es ein Stoßdämpfer ist und kein Cache, der heiße Daten halten soll. Ein Gerät mit 375 GB vor derselben Platte sind 1,9 %, und das ist einfach mehr Luft, als du nutzen wirst.\nDas bringt das billige Ende des Bereichs ins Spiel. Hier ist das kleine Consumer-Modul gegen das Rechenzentrumsteil, denn der Abstand liegt nicht dort, wo Leute ihn erwarten:\nOptane Memory M10 32 GB Optane DC P4800X 375 GB Zufälliges Lesen, 4K 240.000 IOPS 550.000 IOPS Zufälliges Schreiben, 4K 65.000 IOPS vergleichbar mit Lesen Sequentielles Lesen 1.200 MB/s 2.400 MB/s Sequentielles Schreiben 290 MB/s 2.000 MB/s Typische Latenz — unter 10 µs Haltbarkeit 365 TBW 12,3 PBW — 30 DWPD Schnittstelle PCIe 3.0 x2, M.2 2280 PCIe 3.0 x4, U.2 oder Steckkarte Sieh zuerst auf die Zeile mit den Schreib-IOPS. Die kleine M10 macht 65.000 zufällige Schreibvorgänge pro Sekunde; die Spindel dahinter macht 80. Selbst die billigste Optane ist etwa 650-mal die Platte, die sie zwischenspeichert, auf der Leistungsachse ist das Argument also vorbei, bevor es anfängt. Die zusätzlichen IOPS des Rechenzentrumsteils haben nichts, wohin sie könnten, wenn eine 7,2k-Platte dahinter hängt.\nDie Zeile, die den Kauf entscheidet, ist die Haltbarkeit, und dort ist der Abstand 34×. In ein Tagesbudget über fünf Jahre Lebensdauer umgerechnet:\nGerät Tragbare Schreibvorgänge pro Tag über fünf Jahre M10 32 GB — 365 TBW etwa 200 GB/Tag P4800X 375 GB — 12,3 PBW etwa 6,7 TB/Tag Unter 200 GB Schreibvorgängen am Tag übersteht eine M10 mit 32 GB den ganzen Aufbau. Beim Doppelten davon bekommst du zweieinhalb Jahre. Bist du richtig schreiblastig, verdient das Rechenzentrumsteil seinen Preis — nicht wegen der IOPS, die du nicht nutzen kannst, sondern wegen des gut dreißigmal höheren Schreibens, das es verträgt.\nMiss also, statt zu raten. nvme smart-log auf einem vorhandenen Cache-Gerät gibt dir data_units_written; nimm eine Woche später eine zweite Probe, teile, und vergleiche mit dem angegebenen TBW dessen, was du in Erwägung ziehst. bcache führt seine eigenen Summen unter /sys/block/bcacheN/bcache/stats_total/, wenn du es lieber dort liest.\nZwei Vorbehalte zur M10. Ihre Zahlen für zufällige Zugriffe sind über eine Spanne von 8 GB angegeben und nicht über das ganze Gerät, auf einem Cache, den du weitgehend voll betreiben willst, behandle sie also als das optimistische Ende. Und es ist ein Consumer-Teil ohne PLP-Zusage für Unternehmen — Optanes Medium wird an seinem Platz beschrieben, ohne DRAM-Puffer im Schreibweg, und deshalb verhalten sich diese Module bei plötzlichem Stromverlust weit besser als Consumer-NAND, aber „verhält sich in der Praxis gut“ ist keine Spezifikation. Willst du die Zusage schriftlich, kauf ein Teil der DC-Reihe.\nDer Boden ist Bandbreite, nicht Kapazität — die Module mit 16 GB fallen weg Es gibt eine zweite Einschränkung, unabhängig von allem oben, und sie schließt das billigste Teil der Reihe aus.\nDer Cache muss sequentiell schneller sein als die Platte, sonst ist er eine Bremse. Die M10 mit 16 GB ist es nicht, und es ist das Modul, das dich am meisten verlocken wird, weil es fast nichts kostet:\nSequentielles Schreiben Optane Memory M10 16 GB 150 MB/s Optane Memory M10 32 GB 290 MB/s Optane DC P4800X 375 GB 2.000 MB/s Eine 7,2k-Unternehmens-HDD 150–250 MB/s Lies die erste und die letzte Zeile zusammen. Ein Modul mit 16 GB schreibt sequentiell etwa so schnell wie die sich drehende Platte, die es beschleunigen soll, und langsamer als eine gute. Es bleibt bei zufälliger Arbeit ungeheuer schneller — 35.000 zufällige Schreib-IOPS gegen die 80 der Platte —, aber auf einem sequentiellen Strom ist es bestenfalls ein Nullsummenspiel und schlimmstenfalls eine Decke unter dem, was die nackte Platte allein geschafft hat.\nUnd dieser Entwurf sorgt dafür, dass du diese Decke erreichst, denn die sequentielle Umleitung abzuschalten schickt alles durch den Cache und macht die eigene sequentielle Schreibbandbreite des Caches zur harten Decke für die ganze OSD. Bei der Wiederherstellung beißt es am härtesten: eine OSD mit 20 TB aufzufüllen ist etwa so sequentiell, wie diese Last je wird, und sie auf 150 MB/s zu begrenzen macht einen schon langsamen Wiederaufbau langsamer.\nDie M10-Reihe hat also einen Boden bei 32 GB, und es ist ein Boden der Bandbreite und nicht der Kapazität. Die Kapazitätsrechnung sagte, 32 GB seien reichlich; die Bandbreitenrechnung schließt 16 GB aus, egal wie wenig du speichern musstest. Beide Prüfungen müssen bestehen, und das billige Teil scheitert an der, die Leute nicht machen.\nWas du auch in Erwägung ziehst, stell seine Zahl fürs sequentielle Schreiben neben 250 MB/s, bevor du es kaufst.\nEin Produkt kaufen, das niemand mehr herstellt Optane ist abgekündigt. Intel hat das Geschäft 2022 abgewickelt, 559 Millionen Dollar Lagerbestand abgeschrieben und die Entwicklung beendet. Es gibt keine neue Produktion und keinen Nachschub; der Gesamtvorrat geht von hier an nur nach unten.\nWas eine naheliegende Frage aufwirft, denn es ist überraschend viel davon zu verkaufen. Zu verstehen, woher es kommt, sagt dir, was du kaufst.\nEs ist Lagerbestand aus Ersatzteilprogrammen von OEMs, der abgestoßen wird. Die drei großen Serverhersteller hielten Optane als Ersatzteile vor, um die Plattformen zu unterstützen, in denen sie es verkauft haben. Diese Plattformen sind aus dem Lebenszyklus und aus der Unterstützung gefallen, die Ersatzteile dahinter wurden also über Nacht toter Bestand — Lagerhallen voller Teile für Maschinen, die niemand mehr vertraglich reparieren muss. Dieser Bestand ist, was auf AliExpress und zu den Aufarbeitern fließt.\nZwei Folgen, und beide sind gute Nachrichten.\nViel davon ist unbenutzt und nicht ausgebaut. Ersatzteile lagen im Regal und warteten auf einen Ausfall, der nie kam, der Verschleißwert bei Ankunft ist also oft praktisch null — nicht „ein paar Jahre leichter Dienst“, sondern nie beschrieben. Prüf statt zu vertrauen: nvme smart-log gibt dir percentage_used und data_units_written, und bei echtem Ersatzteilbestand sollten die verblüffend niedrig sein. Alles mit echtem Verschleiß ist ein Ausbau, der als etwas anderes verkauft wird, wobei die Luft bei der Haltbarkeit auch dann heißt, dass eine gebrauchte Optane mehr Leben übrig haben kann als eine brandneue NAND-Platte derselben Kapazität.\nEs erklärt, welche Kapazitäten du finden wirst. OEM-Ersatzteile wurden für Server vorgehalten, das heißt Rechenzentrumsteile. Hier ist die ganze Reihe, und achte darauf, wo das Spitzenteil anfängt:\nTeil Kapazitäten Form Optane Memory M10 16, 32, 64 GB M.2 2280, Consumer Optane SSD 800P 58, 118 GB M.2 2280, Consumer Optane SSD P1600X 58, 118 GB M.2 2280, Rechenzentrumsteil für Start und Cache Optane SSD DC P4801X 100, 200, 375 GB M.2 110 mm oder U.2 Optane SSD DC P4800X 375 GB als Kleinstes, 750 GB, 1,5 TB U.2 oder Steckkarte Optane SSD P5800X 400 GB, 800 GB, 1,6 TB U.2 oder Steckkarte Theoretisch sind die kleinen M.2-Teile die elegante Antwort — die M10, die 800P, die P1600X und die P4801X mit 100 GB tun alle die Arbeit, und billig. In der Praxis hat der Markt sie nicht, denn niemand hat Desktop-Beschleunigermodule als Server-Ersatzteile eingelagert. Angeboten wird 375 GB und aufwärts, Hardware der P4800X-Klasse.\nPlane also damit, mehr Kapazität zu kaufen, als die Rolle braucht, denn das ist, was zu verkaufen ist. Es ist kein schlechtes Ergebnis. Ein Cache-Gerät zu groß zu kaufen bringt dich auf 30 DWPD und Latenz unter 10 µs, wenn deine Last einen Bruchteil von beidem verlangte, und für eine Spindel mit 20 TB, die du Jahre behalten willst, ist das die richtige Richtung zu irren. Es heißt, dass der Einstiegspreis höher ist, als die Rechnung vermuten lässt, und dass das Bemessen oben eine Prüfung gegen zu kleines Kaufen wird und keine Einkaufsliste.\nDrei Dinge, mit denen zu planen ist, denn das ist eine Abwicklung und keine Lieferkette:\nKauf deine Ersatzteile mit dem Aufbau. Ein endlicher Vorrat wird geräumt. Fällt in drei Jahren ein Gerät aus, wirst du keinen Ersatz bestellen, sondern jagen — kalkuliere die Ersatzteile also jetzt ein, solange der Bestand da ist.\nRechne mit OEM-Firmware und prüf das Namespace. Teile aus dem Ersatzteilprogramm eines Herstellers tragen oft dessen Firmware und können mit einer LBA-Größe oder Metadaten-Einstellungen ankommen, die zu dem passen, wofür sie eingelagert waren. Bestätige es mit nvme id-ns, bevor du darauf baust, und sei bereit, mit nvme format auf ein einfaches Format mit 4096 Byte zu gehen.\nEs gibt keine Garantie, keine Unterstützung und keine weiteren Firmware-Aktualisierungen. Intels eigener Support-Hinweis behandelt, was die Abwicklung für Geräte bedeutet, die schon im Einsatz sind, und das ist die Lage, in der alles ist, was du kaufst. Zu prüfen, dass das angekommene Teil das aus dem Angebot ist, liegt bei dir.\nbcache ersetzt das Auslagern von DB und WAL nicht Es lohnt sich, das ausdrücklich zu sagen, denn es ist die naheliegende Stelle, an der man Geld sparen will, und es geht nicht: du brauchst weiterhin block.db auf NVMe. Beide Schichten, nicht die eine oder die andere.\nDie Optane ist ein Schreibcache. Nichts weiter. Sie verkürzt den Weg zur Bestätigung von Schreibvorgängen, die zur Platte unterwegs sind, und sonst tut sie nichts.\nRocksDB schreibt nicht nur. Ceph liest seine Metadaten ständig — um Objekte zu finden, fürs Peering, um Scrubs zu beantworten —, und ein Schreibcache bietet einem Lesevorgang genau nichts, sobald die Daten aus ihm herausgeleert sind. Der Cache nimmt den Metadatenverkehr auch nicht weg; er schiebt ihn auf und bündelt ihn, jede RocksDB-Aktualisierung kommt also irgendwann doch an der Spindel an und konkurriert um dieselben Suchen. Und Compaction macht aus bescheidenem Rühren weit mehr Geräteverkehr als die Schreibvorgänge, die ihn verursacht haben.\nDie zwei Änderungen beheben also verschiedene Probleme, und keine ersetzt die andere:\nWas es behebt Was es nicht tut block.db auf NVMe Metadaten wohnen auf Flash — Lesen und Schreiben, dauerhaft weg von der Spindel nichts für einen Stoß von Gast-Schreibvorgängen Optane über bcache Latenz der Bestätigung bei Stößen von Daten-Schreibvorgängen nichts für Metadaten-Lesevorgänge; schiebt Metadaten-Schreibvorgänge nur auf Lass das Auslagern der DB weg und behalte die Optane, und RocksDB ist zurück auf dem Teller, mit seinen Lesevorgängen bei 80 IOPS bedient. Lass die Optane weg und behalte das Auslagern der DB, und der Dauerzustand ist anständig, aber Stöße bleiben mit Spindelgeschwindigkeit hängen.\nDie udev-Regel, Zeile für Zeile Die Stellräder von bcache wohnen in sysfs, und sysfs setzt sie jedes Mal zurück, wenn das Gerät registriert wird — also bei jedem Start. Sie gehören daher in eine udev-Regel und nicht in ein Skript, das sich jemand zu starten merken muss:\n# /etc/udev/rules.d/99-bcache.rules ACTION==\u0026#34;add|change\u0026#34;, SUBSYSTEM==\u0026#34;block\u0026#34;, KERNEL==\u0026#34;bcache*\u0026#34;, \\ ATTR{bcache/cache_mode}=\u0026#34;writeback\u0026#34;, \\ ATTR{bcache/sequential_cutoff}=\u0026#34;0\u0026#34;, \\ ATTR{bcache/congested_read_threshold_us}=\u0026#34;0\u0026#34;, \\ ATTR{bcache/writeback_rate}=\u0026#34;81920\u0026#34;, \\ ATTR{bcache/writeback_rate_minimum}=\u0026#34;20480\u0026#34;, \\ ATTR{bcache/writeback_percent}=\u0026#34;40\u0026#34; KERNEL==\u0026quot;bcache*\u0026quot; greift jedes bcache-Gerät des Knotens, eine Regel deckt also alle Paare ab. ACTION==\u0026quot;add|change\u0026quot; heißt, dass sie neu greift, wann immer ein Gerät erscheint oder wieder angehängt wird, und nicht nur beim Start.\nWas jede Einstellung tut, und warum:\ncache_mode=writeback — der ganze Sinn. Im voreingestellten writethrough wird ein Schreibvorgang erst bestätigt, wenn er die HDD erreicht, der Cache tut also nichts für die Schreiblatenz. In writeback bestätigt die Optane, und die Spindel holt später auf.\nsequential_cutoff=0 — standardmäßig erkennt bcache sequentielles I/O und leitet es ab 4 MB direkt am Cache vorbei, in der Annahme, die Platte dahinter komme mit sequentiellem gut zurecht. Null schaltet diese Umleitung ab, sodass alles zwischengespeichert wird. Auf einem hyperkonvergenten Knoten ist das richtig: was für ein bcache-Gerät sequentiell aussieht, hört am Teller auf sequentiell zu sein, sobald mehrere OSDs sich verschachteln, und du willst jeden Schreibvorgang mit Optane-Geschwindigkeit bestätigt haben, egal was. Es bringt allerdings eine Pflicht mit — ohne Umleitung wird die eigene sequentielle Schreibbandbreite des Cache-Geräts zur Decke für die ganze OSD, und das ist der Grund, warum die Module mit 16 GB wegfallen.\ncongested_read_threshold_us=0 — bcache beobachtet die Latenz seines eigenen Cache-Geräts und fängt an, den Cache zu umgehen, wenn es ihn für verstopft hält, voreingestellt bei 2000 µs fürs Lesen. Optane verstopft nicht so, wie NAND es tut, das ist also bcache, das ein Gerät zweitrangig überstimmt, das es falsch gemessen hat. Null schaltet die Beobachtung ab.\nwriteback_rate=81920 und writeback_rate_minimum=20480 — die Rate der Leerung im Hintergrund, in Sektoren pro Sekunde, also etwa 40 MB/s Ziel mit einem Boden von 10 MB/s. Ein PD-Regler bewegt die tatsächliche Rate dazwischen. Das Ziel liegt nahe an dem, was eine Spindel sequentiell aufnehmen kann, und der Boden hindert den Regler daran, die Leerung gegen null zu drosseln und schmutzige Daten unbegrenzt aufzustauen. Beides sind Startpunkte und keine Konstanten — wie man sie ändert steht unten.\nwriteback_percent=40 — wie viel des Caches bcache schmutzig liegen lässt, bevor es hart gegenhält, gegen eine Voreinstellung von 10. Vierzig gibt dir einen viel tieferen Stoßpuffer. Es heißt auch, dass bis zu 40 % dieser Optane die einzige Kopie von Daten im System halten, und das ist die Abwägung, und der Grund, warum das Layout mit einer pro Spindel zählt. Das ist der Wert, den man am ehesten noch einmal ansieht, wenn man eine echte Last beobachtet hat.\nDie Füll- und Leerungswerte später ändern Die 40 % und die zwei Raten oben sind die Werte, die hier laufen, keine allgemeinen Konstanten. Sie sind das Erste, was du bewegen willst, sobald du eine echte Last beobachtet hast, es lohnt sich also zu wissen, dass es zwei Stellen gibt, sie zu ändern, und die zwei verschiedene Dinge tun.\nsysfs ändert es jetzt. Die udev-Regel ändert es beim nächsten Start. Du willst beides, und in dieser Reihenfolge.\nLive ändern, auf einem Gerät:\necho 30 \u0026gt; /sys/block/bcache0/bcache/writeback_percent Oder über jedes Paar des Knotens:\nfor d in /sys/block/bcache*/bcache; do echo 30 \u0026gt; \u0026#34;$d/writeback_percent\u0026#34; done Die Leerungsrate geht genauso. Beide Werte sind in Sektoren pro Sekunde, das hier halbiert also Ziel und Boden:\nfor d in /sys/block/bcache*/bcache; do echo 40960 \u0026gt; \u0026#34;$d/writeback_rate\u0026#34; echo 10240 \u0026gt; \u0026#34;$d/writeback_rate_minimum\u0026#34; done Das wirkt sofort und hält genau so lange, bis das Gerät neu registriert wird. Die Kernel-Dokumentation ist ausdrücklich, dass diese Einstellungen „do not persist across reboot“, also über einen Neustart nicht bestehen bleiben — und das ist der ganze Grund, warum die udev-Regel existiert.\nBist du mit einem Wert zufrieden, bearbeite die Regel und lade sie neu, ohne neu zu starten:\nudevadm control --reload udevadm trigger --subsystem-match=block --action=change Hier verdient sich ACTION==\u0026quot;add|change\u0026quot; seinen Platz. Der Trigger feuert ein change-Ereignis an Geräte, die schon da sind, die Regel greift also auf einem laufenden Knoten neu, statt auf den nächsten Start zu warten. Hätte die Regel nur auf add gegriffen, würde dieser Befehl nichts tun.\nDann lies die Werte zurück, denn ein Tippfehler in einer udev-Regel scheitert still:\ngrep . /sys/block/bcache*/bcache/writeback_percent Wissen, in welche Richtung man sie bewegt Stell das nicht aus Grundsätzen ein — bcache legt offen, was du brauchst, im selben sysfs-Verzeichnis.\ndirty_data ist das, was man beobachtet: wie viele Daten gerade im Cache und nirgends sonst liegen. Die Dokumentation beschreibt es als „continuously updated unlike the cache set\u0026rsquo;s version, but may be slightly off“, also fortlaufend aktualisiert, anders als die Fassung des Cache-Sets, aber möglicherweise leicht daneben, und das genügt hier. Nimm über einen normalen Arbeitstag und ein Sicherungsfenster Proben.\ncache_hits, cache_misses und cache_hit_ratio sagen dir, ob der Cache genutzt wird, mit dem Vorbehalt, dass „a partial hit is counted as a miss“, ein Teiltreffer als Fehlschlag gezählt wird. bypassed zählt IO, das vollständig am Cache vorbeiging — mit sequential_cutoff=0 sollte das nahezu flach sein, eine wachsende Zahl heißt also, dass etwas noch darum herum läuft.\nAll das kommt als laufende Summen plus Fassungen, die über den letzten Tag, die letzte Stunde und die letzten fünf Minuten abklingen, und das macht die kurzen Fenster zum Aufspüren eines Problems weit nützlicher als den Wert über die Lebensdauer.\nVon dort aus:\nSymptom Stellrad Richtung Stöße hängen — Schreibvorgänge treffen mitten im Stoß Spindellatenz writeback_percent hoch, für einen tieferen Puffer Mehr Daten auf dem Cache ausgesetzt, als dir behagt writeback_percent herunter dirty_data bei normaler Arbeit an der Decke festgenagelt writeback_rate hoch — nicht der Puffer ist das Problem, das Abfließen ist es Leerung im Hintergrund konkurriert mit Gast-Lesevorgängen auf der Spindel writeback_rate herunter dirty_data steigt über Tage statt Stunden writeback_rate_minimum hoch, damit der Regler nicht auf ein Kriechen drosseln kann Sitzt dirty_data an der Decke festgenagelt, egal was du tust, ist keines der Stellräder die Antwort — der Cluster schreibt schneller, als die Spindeln aufnehmen können, und die ehrlichen Lösungen sind mehr Spindeln oder weniger Schreibvorgänge.\nEine Datei, die man in Ruhe lässt: writeback_running. Sie abzuschalten stoppt die Leerung ganz, und die Dokumentation sagt, es sei „only meant for benchmarking“, nur für Benchmarks gedacht. Auf einer produktiven OSD heißt es, dass schmutzige Daten sich anhäufen, bis der Cache voll ist, und nie abfließen.\nWas du aufgibst Die meisten Darstellungen dieses Entwurfs hören bei den guten Nachrichten auf. Das hier sind die Teile, die dir wirklich weh tun werden, und jeder einzelne ist es wert, vor dem Bauen gekannt zu werden statt danach.\nDie zwei zusätzlichen Geräte fallen sehr verschieden aus Die gemeinsame DB-/WAL-NVMe stirbt block.db für osd.0–2 weg osd.0 verloren osd.1 verloren osd.2 verloren Drei OSDs, ein Ereignis. Ein zusammenhängender Ausfall über den Knoten, und genau davor schützt Replikation nicht. Wähl das Verhältnis nach dem Wiederaufbau, den du aussitzen willst, nicht nach dem Preis pro OSD. Eine gepaarte Optane stirbt Optane für osd.0 weg Optane für osd.1 gut Optane für osd.2 gut osd.0 verloren osd.1 liefert osd.2 liefert Eine OSD, und Ceph macht das jeden Tag. Die Wirkung reicht so weit wie die Daten einer einzelnen Platte, und das ist der Ausfall, den ein replizierter Pool abfangen soll. Das ist das ganze Argument dafür, mehrere kleine Geräte zu kaufen statt eines großen. Dieselbe Art Verlust auf beiden Seiten — jedes Gerät hält Zustand, den es nirgends sonst gibt, die OSD wird also zerstört und nicht gestoppt und muss neu angelegt und aufgefüllt werden. Nur die Zahl unterscheidet sich, und genau das kauft die Paarung von einer pro Spindel. Beide zusätzlichen Geräte halten Zustand, den es nirgends sonst gibt, eines zu verlieren zerstört also die OSDs, die davon abhängen. Der Unterschied ist bloß, wie viele das sind: die gemeinsame DB-/WAL-NVMe nimmt jede OSD dahinter mit, während eine eins zu eins gepaarte Optane genau eine mitnimmt. Das ist, was die zusätzlichen Geräte kaufen. Eines der beiden Flash-Geräte zu verlieren zerstört die OSD. Nicht stoppt sie — zerstört sie. Beide Geräte halten Zustand, den es nirgends sonst gibt: block.db hält das RocksDB, das block erst Sinn gibt, und ein Writeback-Cache hält jeden noch nicht geleerten Schreibvorgang. Die Kernel-Dokumentation windet sich beim zweiten nicht: „In writeback mode you\u0026rsquo;ll lose data if something happens to your SSD“ — im Writeback-Modus verlierst du Daten, wenn deiner SSD etwas passiert. So oder so kommt die OSD nicht zurück, sie wird neu angelegt und aufgefüllt.\nEs ist also dieselbe Klasse Risiko, und darüber klar zu sein lohnt sich, statt den Cache als den unheimlichen zu behandeln. Die Optane ist kein gefährlicheres Gerät als die NVMe. Zwei Dinge trennen sie, und keines davon ist die Schwere pro OSD.\nDas erste ist die Wirkungsweite, und sie ist die ganze Rechtfertigung der Paarung. Eine Optane pro Spindel heißt, dass ein Cache-Ausfall eine OSD kostet — ein Verlust einer einzelnen Platte, genau das Ereignis, für dessen Abfangen ein replizierter Pool existiert, und das Ceph erledigt, ohne dass jemand geweckt wird. Das DB-/WAL-Gerät ist geteilt, es zu verlieren kostet also jede OSD dahinter auf einmal, und das ist ein zusammenhängender Ausfall, vor dem Replikation nicht schützt. Derselbe Ausfall, ein Gerät gegen fünf.\nDas zweite ist, wie sich der Ausfall zeigt, und das ist eine betriebliche Falle. Stirbt ein Cache im Writeback-Modus, hält das Gerät dahinter an und gibt I/O-Fehler zurück, und das ist in Ordnung — Ceph markiert die OSD als unten und macht weiter. Der schlechte Fall ist ein Neustart, bei dem das Gerät dahinter ohne seinen Cache hochkommt. Es sieht dann aus wie ein einbindbares Dateisystem, dem einfach jeder schmutzige Schreibvorgang fehlt, und das ist verdorben und nicht bloß veraltet. Ein fehlendes block.db scheitert laut, und die OSD weigert sich zu starten; ein fehlender Cache kann still scheitern und dich das Wrack einbinden lassen. Behandle ein bcache-Gerät ohne seinen Cache als nicht einbindbar, und lass es nie etwas hilfsbereit für dich einbinden.\nbcache sichert von sich aus kein Writeback zu, das gegen Stromverlust hält. Hier hört der Schreibcache der HDD auf, eine Optimierung zu sein, und wird zur Pflicht — schalte ihn ab, und betreibe einen Kernel, der neu genug für die FUA-Behandlung ist, damit synchrone Schreibvorgänge über den ganzen Stapel geachtet werden statt irgendwo in der Mitte zu früh bestätigt. Ein Cache-Gerät ohne Schutz bei Stromverlust verschärft das Problem, denn es kann Daten verlieren, die es schon als sicher gemeldet hat.\nUnd das macht das DB-/WAL-Verhältnis zur Zahl, auf die es ankommt. Ceph erlaubt 4–5 HDD-OSDs pro SATA-SSD und nicht mehr als 15 pro NVMe und warnt vor dem „balancing the risk of reducing costs by placing too many responsibilities into too few failure domains“, also dem Abwägen des Risikos, Kosten zu senken, indem man zu viel Verantwortung in zu wenige Fehlerbereiche legt. Anders als bei der Cache-Ebene gibt es hier keine Paarung, die das einhegen könnte — Teilen ist der Sinn des Geräts.\nAuf Platten mit 20 TB ist das das ganze Gespräch, denn der Wiederaufbau ist riesig. Eine ausgefallene OSD sind 20 TB aufzufüllen; bei den 150–250 MB/s, die eine Spindel durchhält, gedrosselt, damit die Wiederherstellung die Gäste nicht aushungert, schaust du auf gut mehr als einen Tag verminderten Betriebs für eine einzelne Platte. Verlier ein gemeinsames DB-Gerät, das fünf davon trägt, und es sind 100 TB zu bewegen.\nDas Verhältnis ist also nicht wirklich eine Kostenentscheidung. Es ist eine Entscheidung darüber, wie lange du bereit bist, vermindert zu fahren, und wie viel Wiederaufbauverkehr der Cluster tragen kann, während er noch VMs bedient.\nDer Entwurf hängt von einem Gerät ab, das niemand mehr herstellt. Das ist das eine ohne technische Antwort. Optane ist das richtige Teil für die Cache-Stelle, und nichts Aktuelles ersetzt es — NAND kann das Schreibvolumen nicht nehmen, und der CXL-gestützte Speicher, zu dem Intel geschwenkt ist, ist kein Ersatz für einen Block-Cache. Die Abmilderung ist also kaufmännisch statt raffiniert, sie steht weiter oben, und die ehrliche Zusammenfassung ist, dass diese Architektur irgendwo in der Zukunft ein Enddatum hat.\nNichts davon macht aus einem HDD-Cluster einen Cluster auf Flash. Dauerhafter zufälliger Schreibverkehr, der die Leerungsrate überholt, wird den Cache füllen, und sobald er voll ist, schreibst du mit Spindelgeschwindigkeit und zusätzlichen Schichten im Weg. Dieser Entwurf nimmt Stöße auf und entfernt den Overhead der Metadaten. Er stellt keine IOPS her.\nWas es zusammengenommen ist Drei Ebenen, jede macht das Eine, worin sie am besten ist — und alle drei sind nötig:\nOptane nimmt zufällige Schreibstöße auf, ein Gerät pro Spindel. Es muss Optane sein, denn jeder Schreibvorgang geht darüber, und die Haltbarkeit von NAND ist für diese Stelle falsch Eine schnelle Unternehmens-NVMe hält RocksDB und das WAL, geteilt über eine Handvoll OSDs in einem Verhältnis, das du bewusst gewählt und nicht hingenommen hast HDDs liefern die Massenkapazität, von Metadaten und Stößen befreit Der Sinn ist nicht, so zu tun, als wären sich drehende Platten Flash. Er ist, ihnen die Arbeit nicht mehr zu schicken, in der sie am schlechtesten sind, damit die Kapazität, für die du bezahlt hast, nutzbar ist.\nDas ist der ganze Trick, und es ist nichts Kluges daran. Leg jede Aufgabe auf das Gerät, das darin gut ist, und hör auf, doppelt für die zu zahlen, die es nicht sind.\nFür einen hyperkonvergenten Proxmox-Cluster, der Kapazität in vielen Terabyte ohne die Preise von reinem Flash braucht, ist das ein vertretbarer Entwurf. Richtig gebaut fühlt er sich weit schneller an als nackte HDDs, er fällt auf Weisen aus, mit denen Ceph umgehen kann, und das Geld geht dorthin, wo es das Ergebnis ändert.\nZwei verwandte Dinge, die es wert sind, daneben gelesen zu werden: die Arbeit an der Sektorgröße in 4Kn, 512e und 512n zählt sehr für das, was die Spindeln mit den Schreibvorgängen tun, die sie erreichen, und baust du das auf direkt verbundenen Knoten, behandelt das Mesh ohne Switch die Netzseite eines kleinen Ceph-Clusters.\nQuellen Ceph — Hardware Recommendations — die Warnung zu IOPS pro TB bei großen HDDs, „HDD OSDs may see a significant write latency improvement by offloading WAL+DB onto an SSD“, die Verhältnisse von 4–5 HDDs pro SATA-SSD und ≤15 pro NVMe, Schutz bei Stromverlust auf SSDs für Unternehmen, das Abschalten des HDD-Schreibcaches und dass man keinen RoC-HBA braucht Ceph — BlueStore Configuration Reference — block.db bei 1–2 % von block für RBD und mindestens 4 % für RGW, die allgemeine Empfehlung von 2,5 %, das Überlaufen zurück auf das Hauptgerät, die RocksDB-Ebenengrößen hinter den Stufen von 3/30/300 GB, und dass das WAL stillschweigend mit der DB zusammengelegt wird Linux-Kernel — bcache admin guide — die Cache-Modi, sequential_cutoff und seine Voreinstellung von 4 MB, die Voreinstellung von 2000 µs für Lese-Verstopfung, writeback_rate in Sektoren pro Sekunde, der PD-Regler von writeback_percent, die Zähler dirty_data / cache_hit_ratio / bypassed und ihre abklingenden Fassungen für Tag, Stunde und fünf Minuten, die Warnung, dass writeback_running „only meant for benchmarking“ ist, die Feststellung, dass diese Einstellungen „do not persist across reboot“, und „in writeback mode you\u0026rsquo;ll lose data if something happens to your SSD“ Intel — Daten der Optane Memory M10 32 GB — 365 TBW, 240.000 zufällige Lese- und 65.000 zufällige Schreib-IOPS bei 4K über eine Spanne von 8 GB, 1200/290 MB/s sequentiell, PCIe 3.0 x2 Intel — Daten der Optane Memory M10 16 GB — die 150 MB/s sequentielles Schreiben und 35.000 zufällige Schreib-IOPS, die dieses Teil beim sequentiellen Durchsatz unter eine sich drehende Platte setzen PC Perspective — Leistung der Optane SSD DC P4800X — 550K zufällige 4K-Lese-IOPS des Teils mit 375 GB, 2400/2000 MB/s sequentiell, typische Latenz unter 10 µs, und 12,3 PBW bei 30 DWPD ServeTheHome — Optane DC P4801X 100GB M.2 review — die Rechenzentrumsteile in M.2 mit kleiner Kapazität, für die Kapazitätsleiter StorageReview — Intel Optane SSD P5800X — die Angabe von 100 DWPD, die 30 DWPD der P4800X, und der Vergleich mit NAND-Platten für Unternehmen, die bei etwa 10 DWPD für schreibintensive Teile und 3 oder weniger für gemischte Nutzung enden Bcache — ArchWiki — die praktischen Fehlerfälle, darunter ein Gerät, das nach einem Neustart ohne seinen Cache hochkommt, und die Anforderungen an Stromsicherheit rund um den HDD-Schreibcache und FUA Intel — Optane business update — die Abwicklung, und was sie für Garantie und Unterstützung auf Geräten bedeutet, die schon im Einsatz sind, und das ist die Lage, in der alles auf dem Recyclermarkt schon ist ","permalink":"https://blogs.damiendye.uk/de/proxmox/hdd-backed-ceph-bcache-optane/","summary":"Die Preise für Flash machen alles auf NVMe schwer zu rechtfertigen, und HDDs für Unternehmen sind einen zweiten Blick wert. Erträgliche Latenz aus ihnen auf hyperkonvergentem Proxmox-Ceph zu holen heißt, RocksDB von der Spindel wegzuholen, jede Platte über bcache mit ihrer eigenen Optane zu paaren — Optane ausdrücklich, weil die Haltbarkeit von NAND für diese Aufgabe falsch ist — und ehrlich über die Fehlerfälle zu sein, die das einkauft.","title":"Proxmox-Ceph-Cluster auf HDDs schnell machen — Metadaten auf NVMe, eine Optane pro Spindel, und was es dich kostet"},{"content":"Warum das bis jetzt teuer war VDI — Virtual Desktop Infrastructure — liefert einen vollständigen Desktop aus einem Rechenzentrum oder aus der Cloud statt von dem Gerät vor dir. Ein Nutzer meldet sich von einem Laptop, einem Thin Client oder der eigenen Maschine an und bekommt einen bekannten Windows- oder Linux-Desktop, dessen Anwendungen, Dateien und Rechenarbeit alle zentral passieren.\nFür ein IT-Team ist daran reizvoll, dass Aktualisierung, Zugriffssteuerung und Datenschutz alle an einer Stelle passieren und Leute denselben Desktop von überall erreichen können.\nDas Hindernis war nie der Hypervisor. Es war die GPU.\nEine physische GPU zwischen mehreren Desktops zu teilen war NVIDIAs Gebiet, und NVIDIA verlangt Geld für die vGPU-Software, die das Teilen macht. Diese Lizenz ist der Grund, warum VDI mit hardwarebeschleunigter Grafik meist Sache von Häusern mit Konzernbudget war. Eine Jahresgebühr dafür zu zahlen, etwas anzuschalten, was das Silizium schon kann, ist schwer zu mögen.\nIntel hat die Rechnung mit der Arc-Pro-Reihe verändert. Diese Karten unterstützen das Teilen in Hardware über normales SR-IOV, und das ist eine PCIe-Funktion und kein Produkt. Damit gibt es keinen Lizenzserver, kein Abo und keine getrennte vGPU-Software zu kaufen.\nAlso habe ich mir eine Intel Arc Pro B50 besorgt, um zu sehen, wie sauber das mit Proxmox zusammengeht. Die kurze Antwort: der Mechanismus arbeitet genau wie versprochen, und dann kam Firmware in den Weg. Beide Hälften stehen unten.\nWie eine Karte zu mehreren wird: die physische Funktion auf dem Host, die virtuellen an die Gäste Intel Arc Pro Bxx 03:00.0 — physische Funktion Host-Treiber: xe 03:00.1 vfio-pci 03:00.2 vfio-pci 03:00.3 angelegt, wo unterstützt 03:00.4 angelegt, wo unterstützt Windows-Desktop 1 hardwarebeschleunigt Windows-Desktop 2 hardwarebeschleunigt Windows-Desktop 3 hardwarebeschleunigt Windows-Desktop 4 hardwarebeschleunigt An keiner Stelle ist eine vGPU-Lizenz beteiligt. SR-IOV ist eine PCIe-Fähigkeit, die die Karte entweder angibt oder nicht — diese gibt sie bei\u0026#160;[320]\u0026#160;an. Wie viele Funktionen sie anlegt, steht in der Firmware, denn jede bekommt eine feste Scheibe des Speichers der Karte: eine größere Scheibe heißt weniger Funktionen. Eine B50 mit 16 GB gibt zwei mit je 8 GB; die Karten mit 24 und 32 GB melden sieben. Die physische Funktion bleibt beim xe-Treiber des Hosts. Jede virtuelle Funktion ist ein PCIe-Gerät für sich, an vfio-pci gebunden und an einen Gast gegeben — dieselbe Passthrough-Maschinerie wie bei einer ganzen Karte, nur mehrfach. Das gestrichelte Paar hängt von der Karte ab: wie viele Funktionen jede anlegt, steht weiter unten. Der Elefant: du brauchst zuerst Windows Bevor irgendetwas davon geht, will die Karte eine Firmware-Aktualisierung. Intel liefert die im Windows-Treiberpaket aus.\nWas unangenehm ist, denn der Grund, warum du die Karte gekauft hast, ist, sie unter Proxmox zu betreiben.\nEs gibt einen Weg darum herum, der nichts als Proxmox braucht: bau eine Windows-VM, reich die ganze Karte an sie durch, lass Windows die Firmware aktualisieren, und gib die Karte dann an den Host zurück. Es ist eine Bootstrap-Schleife, und es lohnt sich, davon zu wissen, bevor du den Aufbau planst, und nicht danach.\nDie Windows-zuerst-Schleife mit einer vorübergehenden VM aufbrechen Der Haken: SR-IOV braucht aktuelle Firmware, und die Firmware kommt im Windows-Treiberpaket. 1 Karte im Host lspci → 03:00.0 2 Ganze Karte → Windows-VM hostpci0, Q35 + OVMF 3 Intel-Treiber installieren Firmware kommt mit 4 Host neu starten Karte startet neu durch Karte zurück an Proxmox 5 SR-IOV vorhanden lspci -v → [320] 6 tmpfiles.d beim Start numvfs, unbind, bind 7 VFs an die Gäste so viele, wie die Firmware zulässt Schritt 2 und 3 gibt es nur, um die Firmware zu aktualisieren. Die Windows-VM ist vorübergehend — sobald die Karte zurück auf dem Host ist, spielt sie keine Rolle mehr, und nichts am fertigen Aufbau hängt davon ab, dass Windows auf dem Hypervisor läuft. Die Karte kann kein SR-IOV, bis ihre Firmware aktuell ist, und die Firmware-Aktualisierung kommt als Windows-Treiber. Eine vorübergehende Windows-VM mit der ganzen Karte bricht die Schleife auf. Die Karte finden Auf dem Proxmox-Host mit lspci suchen:\nlspci Hier ist sie auf 03:00.0, gemeldet als Battlemage G21, das Silizium hinter der Arc Pro B50. Schreib die Adresse auf. Du brauchst sie mehrmals, und dazu gehört eine getrennte Audiofunktion auf 04:00.0.\nDie ganze Karte an eine Windows-VM durchreichen Füge die Karte einer Windows-VM als rohes PCI-Gerät hinzu. In der Hardware der VM ist das ein Eintrag PCI Device: 0000:03:00 mit pcie=1:\nEs lohnt sich zu bemerken, was diese VM sonst ist, denn nichts davon ist Zufall: Maschinentyp Q35, Firmware OVMF, VirtIO SCSI single und ein TPM für Windows 11. Q35 ist dafür besonders nicht optional. Eine durchgereichte GPU erscheint auf i440fx als altes PCI-Gerät, und das ist die falsche Form für einen modernen Grafiktreiber. Das steht in Immer Q35, nicht i440fx.\nStarte die VM und prüf, ob Windows die Karte sieht:\nSie erscheint als Microsoft Basic Display Adapter, weil noch kein Treiber installiert ist. Das ist der erwartete Zustand, und es genügt. Windows hat die Hardware gefunden.\nDie Firmware aktualisieren Hol den aktuellen Treiber von Intels Downloadseite für die Arc Pro B50. Zum Zeitpunkt des Schreibens war das Version 32.0.101.8306 (Q4.25), für Windows 11 und Windows 10 22H2:\nInstallier ihn, und lass die Firmware-Aktualisierung als Teil des Vorgangs laufen, statt vorher abzubrechen. Dieser Firmware-Schritt ist der ganze Grund für diesen Umweg.\nWenn er fertig ist, gib die Karte an den Host zurück und starte neu, damit sie sich unter Proxmox vollständig neu initialisiert.\nBestätigen, dass SR-IOV da ist Jetzt frag die Karte, was sie kann:\nlspci -v Die Zeile, auf die es ankommt:\nCapabilities: [320] Single Root I/O Virtualization (SR-IOV) Das ist das ganze Angebot in einer Zeile lspci-Ausgabe, ohne Lizenz daran.\nDrei andere Dinge in dieser Ausgabe sind es wert, gleich mitgelesen zu werden:\nKernel driver in use: xe — die Karte läuft auf Intels neuerem xe-Treiber statt auf i915, und der wird die virtuellen Funktionen anlegen. [420] Physical Resizable BAR und [220] Virtual Resizable BAR — die Karte kann veränderbare BARs, und ihre virtuellen Funktionen auch. Es lohnt sich zu wissen, was dich das an Adressraum kostet, wenn du mehrere davon durchreichst: siehe PCIe Resizable BAR und moderne GPUs. IOMMU group 13 — die Karte sitzt in einer eigenen Gruppe, und das willst du für sauberes Passthrough. Warum das zählt, steht in dem Beitrag über die IOMMU-Steuer. Die virtuellen Funktionen beim Start anlegen Virtuelle Funktionen bleiben nicht über Neustarts erhalten. Sie zu verlangen ist ein Schreibvorgang in sysfs, das muss also bei jedem Start passieren.\ntmpfiles.d ist ein ordentlicher Weg, das erklärend zu tun, statt ein Skript an eine Unit-Datei zu schrauben:\nDie Datei erledigt drei Aufgaben in dieser Reihenfolge.\nDie virtuellen Funktionen anlegen, indem die Anzahl in sriov_numvfs der physischen Funktion geschrieben wird:\nw /sys/devices/pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:01.0/0000:03:00.0/sriov_numvfs - - - - 4 Jede neue Funktion von xe lösen, denn der Host-Treiber beansprucht sie, sobald sie erscheinen, und ein Gast kann kein Gerät haben, das der Host hält:\nw /sys/bus/pci/drivers/xe/unbind - - - - 0000:03:00.1 w /sys/bus/pci/drivers/xe/unbind - - - - 0000:03:00.2 w /sys/bus/pci/drivers/xe/unbind - - - - 0000:03:00.3 w /sys/bus/pci/drivers/xe/unbind - - - - 0000:03:00.4 Sie an vfio-pci binden, und das macht sie zum Durchreichen verfügbar:\nw /sys/bus/pci/drivers/vfio-pci/bind - - - - 0000:03:00.1 w /sys/bus/pci/drivers/vfio-pci/bind - - - - 0000:03:00.2 w /sys/bus/pci/drivers/vfio-pci/bind - - - - 0000:03:00.3 w /sys/bus/pci/drivers/vfio-pci/bind - - - - 0000:03:00.4 Achte auf die Adressen: die physische Funktion ist 03:00.0, und die virtuellen kommen als .1 bis .4 hoch.\nEine Einzelheit zu w, die die Reihenfolge erklärt und dich beißt, wenn du sie falsch machst. systemd dokumentiert es so: „Write the argument parameter to a file, if the file exists“ — schreib den Argumentparameter in eine Datei, wenn die Datei existiert. sriov_numvfs existiert erst, wenn ein Treiber an die physische Funktion gebunden ist, und die Pfade der virtuellen Funktionen erst, wenn dieser Schreibvorgang passiert ist. Die Reihenfolge in der Datei ist also nicht Stil. Jede Zeile hängt davon ab, dass die vorige gewirkt hat.\nWarum zwei und nicht vier Der Treiber 32.0.101.8306 — der oben installierte — trägt die Grafik-Firmware BMG__21,1162, und das ist die Ausgabe, in der Intel SR-IOV auf Arc Pro erstmals offiziell freigegeben hat. Intels angegebene Voreinstellung für die B50 in dieser Ausgabe sind zwei virtuelle Funktionen, jede mit einem VF-Local-Memory-BAR von 8 GB.\nDamit ist die Zahl Rechnerei und keine Politik. Die B50 hat 16 GB. Bei 8 GB pro virtueller Funktion sind zwei alles, was hineingeht.\nEs gibt einen Haken, den man kennen sollte, wenn man nach einem Umweg sucht. Bevor es offizielle Unterstützung gab, haben manche Leute ältere Firmware betrieben, die auf einer B50 12 virtuelle Funktionen zeigte, und der Rückschritt auf Treiber 32.0.101.6979 stellt diese Zahl wieder her. Diese 12 teilten sich dieselben 16 GB, jede bekam also einen Bruchteil des Speichers, den meine bekommen. Intels Haltung ist, dass zwei bewusst gewählt wurde, damit jede Funktion genug Rechenleistung, Kapazität und Bandbreite für vorhersehbares Verhalten hat.\nDie Grenze lässt sich also verschieben, aber nicht von dir. Die maximale VF-Zahl und die Größe des VF-Local-Memory-BAR wohnen in der IFWI, es gibt kein öffentliches Werkzeug, eines von beiden zu ändern, und die unterstützte Antwort auf einem aktuellen Stand ist zwei.\nWie viele Desktops jede Karte hergibt Die B50 ist die kleine Karte der Familie, und ihre zwei Funktionen sind der Tiefpunkt der Familie. Ist die Zahl der Plätze das, worauf es dir ankommt, kauf weiter oben in der Reihe.\nDie ganze Battlemage-Arc-Pro-Reihe macht SR-IOV. Verschieden ist, wie viele Funktionen die Firmware herausschneidet, und das folgt dem Speicher:\nKarte Speicher VFs auf dem aktuell unterstützten Stand Anderswo gesehen Arc Pro B50 16 GB 2, je mit 8 GB VF-BAR — Intels dokumentierte Voreinstellung 12 auf Firmware vor der offiziellen, über Treiber 32.0.101.6979 Arc Pro B60 24 GB 7 gemeldet 24 auf einer frühen ASRock-Firmware, von einer späteren auf 7 gesenkt Arc Pro B60 Dual 2 × 24 GB 7 pro GPU — zwei GPUs, also 14 aus einem Slot wie oben; die zwei Hälften sind unabhängig Arc Pro B65 32 GB keine veröffentlichte Zahl gefunden — Arc Pro B70 32 GB 7 gemeldet, auf Firmware 8517 4 auf früherer Firmware Nur die Zeile zur B50 ist von Intel dokumentiert. Die Zahlen zu B60 und B70 sind, was Leute aus lspci melden, und sie haben sich mehr als einmal bewegt. Besonders die B60 ging in einer Firmware-Aktualisierung von 24 auf 7 herunter, dieselbe Art Verengung, die die B50 gesehen hat. Zur B65 scheint überhaupt niemand eine VF-Zahl veröffentlicht zu haben, behandle diese Zeile also als unbekannt und nicht als null.\nZwei Dinge folgen aus dieser Tabelle, und beide zählen mehr als jede einzelne Zahl darin.\nDie VF-Zahl ist eine Teilung des Speichers, keine Eigenschaft des Chips. Intels Regel ist, dass ein größeres VF-Local-Memory-BAR weniger Funktionen heißt. Deshalb gibt die Karte mit 16 GB zwei und die Karten mit 32 GB sieben: nichts an den Shadern der GPU entscheidet das.\nPrüf die Karte, die du kaufen willst, nicht die Familie. Die Anwesenheit von SR-IOV hat zwischen Platinenherstellern auf demselben Chip geschwankt — Sparkles B60 Blower kam zuerst ganz ohne sichtbare Fähigkeit und bekam sie erst nach einer Firmware-Aktualisierung per igsc. Frag nach der Ausgabe von lspci -v vom genauen Modell, oder plane eine Firmware-Aktualisierung ein, bevor du auf irgendetwas davon setzt.\nDie Dual B60 sind zwei Karten in einem Blech Maxsuns Arc Pro B60 Dual 48G Turbo ist die interessante für die Platzzahl, und was man verstehen muss, ist, dass die 48 GB kein gemeinsamer Pool sind.\nEs sind zwei B60-GPUs — zwei BMG-G21-Dies — auf einer Platine, mit je 24 GB GDDR6 daran verdrahtet, und ohne PCIe-Bridge-Chip dazwischen. Beide Dies hängen direkt an den x16-Goldfingern, mit je PCIe 5.0 x8.\nDas heißt, der Host muss den Slot für dich teilen. Die Karte braucht den primären x16-Slot als x8/x8 aufgeteilt, und die meisten Consumer-Platinen haben das nicht standardmäßig an. Es ist eine Firmware-Einstellung, nach der du suchen musst, in derselben Kategorie wie die IOMMU- und ACS-Einstellungen, die all das braucht.\nMach das richtig, und das Betriebssystem sieht zwei getrennte GPUs, jede mit ihrer eigenen physischen Funktion und ihrer eigenen SR-IOV-Fähigkeit. Du bekommst also zwei Sätze virtueller Funktionen aus einem Slot — 14 Plätze, wenn jedes Die sich wie eine einzelne B60 verhält — und die tmpfiles.d-Datei von oben verdoppelt sich, ein sriov_numvfs-Schreibvorgang pro Die.\nMach es falsch, und du siehst eine GPU, und die halbe Karte ist unsichtbar.\nEs lohnt sich, klar zu sagen, was die 48 GB nicht sind: ein Gast an einer virtuellen Funktion des ersten Die kommt nicht an den Speicher des zweiten. Das sind zwei Karten mit 24 GB in einem physischen Raum, und das ist genau, was du für VDI-Plätze willst, und genau, was du für ein großes Modell nicht willst.\nAlso: sind zwei Plätze genug, ist die B50 eine 70-W-Karte, die das kann. Willst du sieben, plane um eine B70. Willst du vierzehn und hast eine Platine, die aufteilt, bringt dich die Dual B60 in einem Slot dorthin.\nKann man KI auf einer virtuellen Funktion betreiben? Kurze Antwort: behandle es als nicht unterstützt. Längere Antwort, denn der Grund zählt, und er ist nicht der, den du erwarten würdest.\nDiese Karten werden als KI-Karten vermarktet, und das ist keine Verstellung. Die 128 XMX-Einheiten der B50 sind mit 170 TOPS Spitze angegeben, die B70 mit 367, und Intels Software-Geschichte ist echt — vLLM liefert auf Arc Pro der B-Reihe Modelle von 8B bis 120B aus, und IPEX-LLM und das SYCL-Backend von llama.cpp laufen beide darauf.\nAber sieh nach, wie jedes dieser Ergebnisse zustande kommt. vLLMs eigene Arc-Pro-Zahlen kommen aus einem Docker-Container auf Blech, auf Systemen mit vier und acht ganzen B60-Karten, die Tensor-Parallelität machen. Intels Beitrag erwähnt SR-IOV oder virtuelle Funktionen kein einziges Mal.\nDieses Muster hält überall, wo ich nachgesehen habe. Intel begrenzt die Anwendungsfälle für SR-IOV auf virtualisierte Fernarbeitsplätze, Grafikbeschleunigung im Gast-Betriebssystem und Medien-Encoding und -Decoding. Rechnen steht nicht auf dieser Liste, und ich konnte keinen einzigen veröffentlichten Fall finden, in dem jemand LLM-Inferenz in einer VM an einer virtuellen Funktion betreibt.\nWas Leute tatsächlich tun, ist vielsagend: sie betreiben das Modell in Docker auf dem Host und geben virtuelle Funktionen an VMs für Desktops. Eine Person, die beides gleichzeitig macht, berichtet bloß, dass „VRAM gets pretty tight“ — der VRAM wird ziemlich knapp.\nUnd das ist das eigentliche Problem, und es ist Rechnerei und keine Frage der Treiberunterstützung.\nEine virtuelle Funktion bekommt eine feste Scheibe lokalen Speichers — 8 GB auf der B50, in der Firmware festgelegt. Diese Scheibe ist die harte Decke für Gewichte plus KV-Cache in diesem Gast, und sie wächst nicht, weil die Karte mehr hat. Ein 8B-Modell in FP16 sind rund 16 GB Gewichte, bevor du irgendeinen Kontext dazunimmst, es passt also auf keinem Treiber in eine virtuelle Funktion einer B50. Quantisiere auf Q4, und ein 8B passt in etwa 4 GB und lässt ein paar GB für Kontext — was geht, aber weit von dem entfernt ist, was die Karte ungeteilt kann.\nDie zwei Lasten konkurrieren also um denselben Speicher, und die Teilung wird in der Firmware entschieden, bevor eine von beiden anfängt.\nIst KI die Aufgabe, teile die Karte nicht. Reich das Ganze an eine VM durch — dasselbe hostpci0-Passthrough, das oben in diesem Beitrag für die Firmware-Aktualisierung genutzt wurde — oder betreibe den Container auf dem Host und lass die Virtualisierung für diese Last weg. Beides gibt dem Modell alle 16 GB und das ganze XMX-Feld.\nIst VDI die Aufgabe, sind virtuelle Funktionen richtig, und erwarte hinter jeder Desktop-Grafik statt eines Inferenzservers. Hardwarebeschleunigte Desktops, Videowiedergabe und Encoding gehen. Dafür ist der Mechanismus dokumentiert.\nKlar gesagt: fehlende veröffentlichte Belege sind kein Beweis, dass es scheitert. Der xe-Treiber legt Rechenleistung über Level Zero und OpenCL offen, und es ist gut möglich, dass ein Gast an einer VF die sauber hochbringt. Aber nichts von Intel sagt, dass es geprüft ist, niemand scheint es gezeigt zu haben, und die Speicherdecke begrenzt den Gewinn, selbst wenn es geht. Darauf baut man keinen Plan.\nWas es trotzdem wert ist Zwei virtuelle Funktionen sind zwei hardwarebeschleunigte Windows-Desktops aus einer Karte, ohne vGPU-Lizenz, ohne Abo und ohne Lizenzserver. Auf einem Hypervisor, dessen Betrieb nichts kostet. Das genügt, um zu zeigen, dass der Weg funktioniert, und das ist die ehrliche Aufgabe einer B50. Sie ist das untere Ende der Reihe.\nFür eine echte VDI-Installation würde ich die Dual B60 vorsehen.\nVierzehn Funktionen aus einem Slot — wenn jedes Die sich wie eine einzelne B60 verhält — setzt sie bei der Platzzahl in dieselbe Gegend wie die NVIDIA-Karten, die für diese Arbeit verkauft werden, bei weit niedrigerem Preis und ohne etwas, das pro Nutzer zu lizenzieren wäre. Der letzte Teil ist der, der sich aufsummiert. NVIDIAs vApps, vPC und RTX vWS werden alle pro gleichzeitigem Nutzer lizenziert, entweder als Jahresabo oder als dauerhafte Lizenz, die zusammen mit einem fünfjährigen Abo für Unterstützung und Pflege gekauft werden muss. Jeder Platz ist eine Position, und sie kommt wieder. Auf der Intel-Seite gibt es keine entsprechende Position. Du kaufst die Karte.\nUnd der Mechanismus ist der Teil, der langfristig zählt. SR-IOV auf der GPU ist eine PCIe-Fähigkeit und keine Produktstufe, die tmpfiles.d-Datei wächst also einfach mit, was die Karte zulässt.\nDie Form ist ein sriov_numvfs-Schreibvorgang, dann ein Lösen und ein Binden pro Funktion — zwei Funktionen sind also fünf Zeilen, und die neun oben sind vier Funktionen, verlangt auf einer Karte, die zwei liefert. Sieben Funktionen sind fünfzehn Zeilen. Eine Dual B60 sind dreißig, denn jedes Die ist seine eigene physische Funktion und bekommt seinen eigenen sriov_numvfs-Schreibvorgang.\nNichts sonst ändert sich, wenn du es hochskalierst. An keiner Stelle dieser Datei erscheint ein Lizenzserver.\nQuellen Intel Support — warum die neueste Arc-Pro-B50-Firmware 2 SR-IOV-VFs zeigt — die maßgebliche Aussage: SR-IOV offiziell freigegeben ab Grafik-Firmware BMG__21,1162 im Treiber 32.0.101.8306, zwei VFs mit je 8 GB VF-Local-Memory-BAR auf der B50, und maximale VF-Zahl und BAR-Größe auf IFWI-Ebene festgelegt, ohne öffentliches Werkzeug, sie zu ändern Intel Community — „Why did the latest Intel Arc Pro B50 firmware nerf SR-IOV VFs from 12 to 2?“ — die Firmware mit 12 VFs vor der offiziellen, der Rückschritt auf 32.0.101.6979, der sie wiederherstellt, und Intels Begründung für die niedrigere Voreinstellung Level1Techs — B60-SR-IOV-Unterstützung in den Arc-Pro-Treibern — lspci-Meldungen aus dem Feld zur B60, die igsc-Firmware-Aktualisierung, die die Fähigkeit offenlegte, und woher die Zahlen 24 und dann 7 kommen Level1Techs — B50, B60 oder B70 für SR-IOV — die gemeldeten VF-Zahlen pro Karte und pro Firmware, Quelle für die B70-Zeilen ASRock — Intel Arc Pro B65 Creator 32GB — die Daten der B65: 32 GB GDDR6, 20 Compute Units, 160 XMX-Einheiten, 256 Bit, PCIe 5.0 MAXSUN — Arc Pro B60 Dual 48G Turbo — die eigene Aussage des Herstellers, dass die Karte „uses PCIe 5.0 x8 + x8 interfaces and runs efficiently on consumer platforms that support PCIe x16 lane bifurcation“ vLLM — Fast and affordable LLM serving on Intel Arc Pro B-Series — die KI-Geschichte dieser Karten, und die Tatsache, dass es eine Geschichte von Docker auf Blech über vier und acht ganze B60 ist, ohne jede Erwähnung von SR-IOV oder virtuellen Funktionen Linux-Kernel — Intel-Xe-Treiber — der Treiber, der laut lspci -v auf der Karte läuft tmpfiles.d(5) — der Zeilentyp w und seine Bedingung „if the file exists“, die die Reihenfolge oben vorgibt NVIDIA Virtual GPU Software Packaging, Pricing and Licensing Guide — die lizenzierte Alternative, die dieser Entwurf vermeidet: vApps, vPC und RTX vWS alle pro gleichzeitigem Nutzer verkauft, als Jahresabo oder als dauerhafte Lizenz samt fünf Jahren Unterstützung und Pflege Proxmox VE — PCI(e) Passthrough — die Anforderungen an Passthrough auf der Host-Seite ","permalink":"https://blogs.damiendye.uk/de/proxmox/licence-free-vdi-intel-arc-pro-sriov/","summary":"Intels Arc-Pro-Karten machen SR-IOV von sich aus, ohne vGPU-Lizenz zu kaufen — und damit wird ein lizenzfreies Windows-VDI auf Proxmox wirklich möglich. Der ganze Aufbau auf einer B50, das Windows-zuerst-Problem, warum die Firmware bei zwei virtuellen Funktionen abriegelt, und wie viele jede Karte der B-Reihe hergibt.","title":"Lizenzfreies Windows-VDI auf Proxmox mit einer Intel Arc Pro B50 — und die Firmware-Grenze, die es gestoppt hat"},{"content":"Der Switch, den du nicht kaufst Ein Proxmox-Cluster aus drei Knoten mit Ceph will ein schnelles Netz zwischen den Knoten. Die übliche Antwort ist ein 100-Gbit-Switch, und der übliche Einwand ist, was der kostet.\nFür drei Knoten gibt es eine andere Antwort: verkabele sie direkt im Dreieck miteinander und route darüber. Überhaupt kein Switch im Speicherweg.\nDas billigste Bauteil in jedem Entwurf ist das, das du nicht kaufst, und es ist das einzige, das nie ausfällt.\nDas bringt vier Dinge.\nDie Kosten des Switch verschwinden. Du brauchst Netzwerkkarten und drei Kabel, keinen Switch mit 100 oder 200 Gbit und der passenden Portzahl.\nDer Datenweg hat keinen einzelnen Ausfallpunkt. Ein Switch, der ausfällt oder neu startet, nimmt den ganzen Ost-West-Verkehr des Clusters mit. Knoten, die direkt miteinander verkabelt sind, ist es gleich, was mit einem Switch anderswo im Gebäude passiert.\nDer schwere Verkehr liegt auf eigenen Drähten. Live-Migration und Ceph-Replikation bleiben auf dem Mesh, statt mit Büro- und Verwaltungsverkehr zu konkurrieren.\nEs zu vergrößern ist Kabelarbeit, keine Frage des Portbudgets. Es gibt keine zentrale Kiste, die eine Decke für Bandbreite oder Portzahl setzt, das Fabric wächst also, solange jeder Server einen freien PCIe-Slot hat. OpenFabric routet von allein über neue Verbindungen.\nUnd eine ehrliche Grenze, denn sie zählt mehr als die vier Vorteile. Ein Full Mesh braucht ein Kabel zwischen jedem Knotenpaar. Drei Knoten sind drei Kabel. Vier sind sechs. Fünf sind zehn. Die Verkabelung wächst schneller als die Knotenzahl, und dieser Entwurf übersteht nichts über einen kleinen Cluster hinaus, ohne auf etwas Geswitchtes wie Leaf-Spine zu wechseln.\nDrei Knoten sind genau die Stelle, an der ein Full Mesh Sinn hat. Darüber hinaus lässt sich mit zwei Mesh-Ports pro Knoten noch ein Ring bauen — und der braucht eine Sache, die dieser Aufbau sonst vermeidet, siehe unten.\nWas gebaut wird Drei Proxmox-VE-Hosts, jeder mit zwei fest zugeordneten 100-Gbit-Schnittstellen, so ins Dreieck verkabelt, dass jeder Knoten zwei direkte Nachbarn hat.\nProxmox SDN erledigt das Routing. OpenFabric ist das Protokoll: es rechnet den besten Weg über das Mesh aus, und wenn ein Kabel gezogen wird oder eine Verbindung wegfällt, routet es über den verbleibenden Weg um. Niemand muss sich anmelden.\nDas Fabric wohnt in 10.10.10.0/24, reserviert für das Mesh und nichts anderes — nicht für die Verwaltung, nicht für Gäste, nicht für Speicheradressen, nicht für irgendetwas von außen.\nKnoten Mesh-Adresse Mesh-Schnittstellen mesh1 10.10.10.1/32 nic1, nic2 mesh2 10.10.10.2/32 nic1, nic2 mesh3 10.10.10.3/32 nic1, nic2 Jeder Knoten bekommt ein /32, keine Scheibe des Subnetzes. Das ist der Sinn eines gerouteten Mesh statt eines gebrückten. Die Adresse bezeichnet den Knoten, OpenFabric verkündet sie, und die zwei physischen Verbindungen sind bloß Wege, ihn zu erreichen. Proxmox legt eine Dummy-Loopback-Schnittstelle an, die sie hält.\nDas Dreieck aus drei Knoten, und auf welcher NIC jedes Kabel landet 2,5-Gbit-Switch Verwaltung + Client mesh1 10.10.10.1/32 mesh2 10.10.10.2/32 mesh3 10.10.10.3/32 DAC-01 nic1 ↔ nic1 DAC-03 nic2 ↔ nic2 DAC-02 mesh2 nic2 ↔ mesh3 nic1 nic0 nic0 nic0 Jeder Knoten erreicht die anderen zwei direkt, jeder Mesh-Sprung ist also ein Sprung. Die gestrichelten nic0-Linien sind der separate 2,5-Gbit-Verwaltungsweg — nie Teil des Fabric, und der Grund, warum du dich noch anmelden kannst, wenn das Mesh kaputt ist. Drei Kabel, sechs Ports und zwei Wege zu jedem Knoten. Zieh irgendein einzelnes Kabel, und jeder Knoten ist weiter erreichbar — die verbleibenden zwei Verbindungen bilden eine Kette, um die OpenFabric herumroutet. Die Verkabelung Aktive Glasfaser-DAC-Kabel, im Dreieck, mit Jumbo Frames auf beiden Mesh-Schnittstellen jedes Knotens.\nKabel Von Nach DAC-01 mesh1 nic1 mesh2 nic1 DAC-02 mesh2 nic2 mesh3 nic1 DAC-03 mesh3 nic2 mesh1 nic2 Aktive Glasfaser statt Kupfer-DAC, aus zwei Gründen, die eher mit dem Rack als mit dem Netz zu tun haben:\nKabelführung. Aktive Glasfaser-DACs sind dünner und weit biegsamer als Kupfer, sie lassen sich also sauber verlegen und stapeln sich nicht hinter den Servern. Luftstrom. Weniger Kabelmasse hinter dem Gehäuse heißt weniger Störung des Luftstroms von vorn nach hinten, und das zählt, wenn mehrere schnelle Verbindungen in denselben paar Höheneinheiten landen. Zwei Netze, nicht eines Das Mesh ist nicht das einzige Netz, und es darf nicht zu einem werden.\nJeder Knoten hat nic0 an einem 2,5-Gbit-Switch, Proxmox gegenüber als Brücke vmbr0 dargestellt. Die trägt die Weboberfläche, den Verwaltungszugang und den Client-Verkehr. Sie ist auch der Weg, den du beim Bauen des Fabric nutzt, und deshalb muss sie davon unabhängig sein.\nnic0 wird bewusst aus dem Fabric herausgelassen. Beim Anlegen der Fabric-Knoten werden nur nic1 und nic2 ausgewählt.\nDas Mesh trägt drei Dinge:\nCeph. Replikation, Wiederherstellung und Backfill von Knoten zu Knoten für den hyperkonvergenten Speicher. Virtuelles Client-Netz. VXLAN-gestützte VNets ziehen Gastnetze über alle drei Knoten und nutzen das geroutete Mesh als Unterlage. Corosync, als zweiter Weg. Der Verkehr für die Cluster-Mitgliedschaft läuft über das Verwaltungsnetz und das Mesh, das Quorum hängt also nicht davon ab, dass eines von beiden allein überlebt. Was auf dem Verwaltungsnetz reitet, was auf dem Mesh, und das Eine auf beiden 2,5-Gbit-Verwaltungsnetz nic0 → vmbr0 → Switch Proxmox-Weboberfläche Verwaltungszugang Verkehr zu Clients 100-Gbit-Mesh, geroutet nic1 + nic2 → direktes DAC, kein Switch Ceph-Replikation, Wiederherstellung, Backfill Virtuelle VXLAN-Client-Netze Live-Migration Corosync — beide Wege Die Cluster-Mitgliedschaft hängt nicht davon ab, dass ein Netz allein überlebt. Die Trennung ist der Entwurf. Die Verwaltung bleibt erreichbar, in welchem Zustand die 100-Gbit-Schnittstellen auch sind, und das macht es sicher, das Fabric aus der Weboberfläche zu bauen — und zurückzurollen. Corosync ist das Einzige auf beiden. Alles andere hat genau ein Zuhause — und der Verwaltungszugang ist der, der weiterlaufen muss, während du am anderen etwas änderst. Die Regel, die es wert ist, auf das Änderungsticket zu schreiben: Verwaltung und Client-Zugang bleiben jederzeit über den 2,5-Gbit-Switch verfügbar, in welchem Zustand die 100-Gbit-Schnittstellen auch sind.\nAlles über die Weboberfläche Dieser Aufbau geschieht vollständig in der Proxmox-Weboberfläche. Das ist eine bewusste Wahl, keine Grenze der Werkzeuge.\nBewusst nicht genutzt:\n/etc/network/interfaces von Hand bearbeiten. FRR-Konfigurationsdateien von Hand bearbeiten. vtysh als Baumethode. Proxmox erzeugt die darunterliegende Netz- und Routing-Konfiguration aus den SDN-Objekten, die du festlegst. Wenn etwas sich wirklich nicht in der Oberfläche setzen lässt, ist das es wert, als Voraussetzung genannt zu werden, statt es still auf der Kommandozeile zu richten. Der Nächste, der die Weboberfläche öffnet, wird nicht wissen, dass du das getan hast.\nAusgaben von der Kommandozeile erscheinen unten nur als Beleg, nie als Bauschritt.\nDer Aufbau 1. Öffne die Proxmox-Weboberfläche und geh auf Datacenter → SDN → Fabrics.\n2. Leg das Fabric an. Gib ihm einen Namen, das Mesh-Präfix und die Zeitgeber.\nHello- und CSNP-Intervalle von 1 bringen den Zustand so schnell wie möglich nach, wenn sich etwas ändert, und genau das willst du auf einem Fabric dieser Größe. Der Preis ist mehr Geplauder auf der Steuerebene. Auf drei Knoten mit je zwei Verbindungen belanglos, einen zweiten Gedanken wert, falls das Fabric je wächst.\n3. Füge jeden Knoten mit Add node hinzu. Gib ihm eine Adresse aus dem Mesh-Bereich und häkle die Schnittstellen an, die mitmachen.\nAchte darauf, was nicht angehäkelt ist: nic0 bleibt draußen, und vmbr0 behält die Verwaltungsadresse. Nutze Create another für die ersten zwei Knoten und Create beim letzten.\n4. Prüf das Ergebnis, bevor du es anwendest.\nDrei Knoten, drei Adressen, nic1, nic2 auf jedem, alle als new markiert — es ist noch nichts geschrieben.\n5. Wende die SDN-Konfiguration an.\nNeben Apply gibt es ein Dry-Run, wenn du erst sehen willst, was es vorhat.\nWissen, dass es geklappt hat Die Statusansicht sollte auf allen drei Knoten sowohl den Zonen- als auch den Fabric-Eintrag als ok zeigen, und keine ausstehenden Änderungen mehr.\nDann prüf das Fabric aus der Sicht eines Knotens selbst. Zuerst die Routen — jeder Knoten sollte ein /32 zu jedem anderen haben, und die Spalte Via sagt dir, welchen Nachbarn er dafür nutzt.\nDann die Nachbarn. Zwei, beide Up, auf einem Dreieck aus drei Knoten.\nDann die Schnittstellen, und dort zeigt sich die Gestalt der Sache: dummy_Mesh als Loopback, der die Router-Adresse hält, und nic1 und nic2 als Point-To-Point statt als Broadcast-Segmente.\nZum Schluss der Beweis von Ende zu Ende.\nKein Verlust, und Mittel von 0,134 ms und 0,141 ms. Beide Nachbarn sind einen direkten Sprung entfernt, und das ist, was ein Dreieck dir gibt.\nDie Prüfung, die es wert ist und die kein Bildschirmfoto zeigen kann: zieh ein Kabel und stell fest, dass alles weiter erreichbar ist. Das ist der ganze Grund, ein geroutetes Mesh statt zweier Punkt-zu-Punkt-Verbindungen zu wählen. Damit ist es die einzige Prüfung, auf die es ankommt.\nÜber drei Knoten hinaus: der Ring Ein Dreieck ist ein Full Mesh. Jeder Knoten hat ein direktes Kabel zu jedem anderen, jeder Sprung ist ein Sprung, und kein Knoten trägt je Verkehr, der nicht sein eigener ist.\nDiese Eigenschaft kaufen dir zwei Mesh-Ports pro Knoten bei drei Knoten, und genau die verlierst du bei vier. Nicht einen Teil davon. Alles. Ein Full Mesh aus vier Knoten braucht drei Ports pro Knoten. Mit zwei ist das Meiste, was du verkabeln kannst, ein Ring.\nEin Ring ändert das Verkehrsmodell. Nachbarknoten haben weiter ein direktes Kabel, aber Knoten auf gegenüberliegenden Seiten des Rings nicht — ihr Verkehr muss über einen Knoten dazwischen. Und dieser Knoten muss bereit sein, Pakete zwischen seinen zwei Mesh-Schnittstellen weiterzuleiten, und das tut Linux standardmäßig nicht. Der Kernel dokumentiert ip_forward als „Forward Packets between interfaces“ mit „Default: 0 (disabled)“ — also aus.\nEin Ring aus vier Knoten: gegenüberliegende Knoten haben kein Kabel, ein Knoten leitet also für sie weiter mesh1 10.10.10.1 mesh2 leitet weiter mesh3 10.10.10.3 mesh4 10.10.10.4 mesh1 → mesh3 kein Kabel dazwischen geht also über mesh2 Transitknoten leitet weiter zwischen nic1 und nic2 Full Mesh bei 4 Knoten 6 Kabel, 3 Ports pro Knoten kein Transit, kein Weiterleiten Ring: 4 Kabel, 2 Ports — und deshalb bist du hier Zwei der sechs Knotenpaare haben kein direktes Kabel. Ihren Verkehr trägt ein Nachbar, dessen Verbindungen damit die Ceph-Replikation anderer Knoten zusätzlich zur eigenen tragen — der Preis, den das Dreieck nicht hat. Zwischen mesh1 und mesh3 gibt es kein Kabel. Ihr Verkehr geht über mesh2 oder mesh4, und dieser Knoten leitet ihn nur weiter, weil das Weiterleiten auf den zwei Schnittstellen eingeschaltet ist, auf denen er ankommt. Schalte es für die Mesh-Schnittstellen ein, und nur für die:\n# /etc/sysctl.d/99-mesh-forwarding.conf net.ipv4.conf.nic1.forwarding = 1 net.ipv4.conf.nic2.forwarding = 1 sysctl --system Lies sie zurück, statt es anzunehmen:\nsysctl net.ipv4.conf.nic1.forwarding net.ipv4.conf.nic2.forwarding Die Einstellung pro Schnittstelle ist hier der richtige Umfang, und sie wirkt für sich. Das globale net.ipv4.ip_forward ist keine Voraussetzung. Die Entscheidung des Kernels über das Weiterleiten liest den Wert der empfangenden Schnittstelle:\n#define IN_DEV_FORWARD(in_dev) IN_DEV_CONF_GET((in_dev), FORWARDING) IN_DEV_CONF_GET gibt die Einstellung dieses Geräts zurück, kein UND mit der globalen. Also leiten nic1 und nic2 Transitverkehr für das Fabric weiter, während nic0 und vmbr0 genau das bleiben, was sie sein sollen: Host-Schnittstellen, die nicht routen. Den globalen Schalter anzuwerfen würde jede Schnittstelle der Kiste zum Router machen, auch die, die zu deinem Büronetz zeigt. Das braucht dieser Entwurf nicht.\nEine Sache über den globalen IPv4-Schalter, obwohl du ihn nicht setzt: net.ipv4.ip_forward ist ein Massensetzer, und deshalb warnt die Kernel-Dokumentation, dass eine Änderung daran „resets all configuration parameters to their default state“ — alle Konfigurationsparameter auf ihren Vorgabezustand zurücksetzt. Wenn irgendetwas anderes auf dem Host ihn je schreibt, überschreibt es diese Werte pro Schnittstelle. Gut zu wissen, bevor du einen Nachmittag damit verbringst, warum der Transit aufgehört hat.\nIPv6 ist die Ausnahme, und die einzige Stelle, an die der globale Schalter gehört. Die Kernel-Dokumentation sagt es direkt unter conf/all/forwarding:\nEnable global IPv6 forwarding between all interfaces. IPv4 and IPv6 work differently here; the force_forwarding flag must be used to control which interfaces may forward packets.\nAuf Deutsch: globales IPv6-Weiterleiten zwischen allen Schnittstellen einschalten; IPv4 und IPv6 arbeiten hier verschieden, und mit dem Flag force_forwarding wird gesteuert, welche Schnittstellen Pakete weiterleiten dürfen.\nEs gibt also kein IPv6-Gegenstück zum sauberen Vorgehen pro Schnittstelle von oben. Trägt das Fabric IPv6, schaltest du das Weiterleiten global ein und begrenzt es dann mit force_forwarding, dokumentiert als „Enable forwarding on this interface only — regardless of the setting on conf/all/forwarding“, also Weiterleiten nur auf dieser Schnittstelle, unabhängig von der Einstellung unter conf/all/forwarding. Beachte, dass dasselbe Überschreiben umgekehrt gilt: conf.all.forwarding auf 0 zu setzen setzt force_forwarding auf jeder Schnittstelle zurück.\nDer Aufbau oben lässt das IPv6-Präfix des Fabric leer, davon gilt hier also nichts — es zählt nur, wenn du eines hinzufügst.\nAchte darauf, was das Weiterleiten nicht ändert: OpenFabric hat das /32 jedes Knotens schon verkündet und den Weg über den Ring schon ausgerechnet. Weiterleiten ist die fehlende Erlaubnis, nicht der fehlende Verstand. Die Routing-Tabelle war die ganze Zeit richtig. Der Kernel hat sich bloß geweigert, als Router zu handeln.\nWas der Ring gegenüber dem Dreieck kostet:\nTransitverkehr. Auf einem Ring aus vier Knoten überqueren die zwei diagonalen Paare einen Knoten dazwischen, ihr Verkehr verbraucht also die Bandbreite dieses Knotens zusätzlich zu seiner eigenen. Ceph merkt das zuerst, weil Replikation von allen zu allen läuft und nicht von Nachbar zu Nachbar. Ein zusätzlicher Sprung Latenz auf diesen Wegen, obendrauf auf die üblichen Werte unter einer Millisekunde eines Entwurfs ohne Switch. Weniger Luft für Ausfälle. Eine kaputte Verbindung macht aus einem Ring eine Kette: noch vollständig verbunden, aber mit längeren Wegen und mehr Transit. Ein zweiter Bruch teilt den Cluster. Ein Dreieck verträgt einen Bruch ganz ohne Transit. Und es wird auf eine Weise schlimmer, die leichter zu zeichnen als zu beschreiben ist. Nimm einen fünften Knoten dazu, und die Hälfte aller Knotenpaare im Cluster hängt davon ab, dass jemand anderes weiterleitet:\nEin Ring aus fünf Knoten: die Hälfte der Knotenpaare hängt jetzt davon ab, dass jemand anderes weiterleitet mesh1 mesh2 mesh3 mesh4 mesh5 Kabel — direkt, ein Sprung kein Kabel — ein Nachbar leitet weiter Fünf Knoten, je zwei Ports 10 Knotenpaare insgesamt 5 haben ein direktes Kabel 5 nicht, sie gehen über Nachbarn Jeder Knoten leitet jetzt Verkehr weiter, der nicht sein eigener ist. Stattdessen ein Full Mesh? 10 Kabel und 4 Ports pro Knoten — zwei NICs mehr in jedem Server, und dort hört der Entwurf auf. Bei drei Knoten geht nichts über Transit. Bei vier zwei Paare. Bei fünf die Hälfte — und ein einziger Bruch verlängert jeden Weg. Zehn Knotenpaare, fünf Kabel. Die gestrichelten Linien sind Paare ohne Kabel zwischen sich — jedes davon ist Ceph-Verkehr, der über die Verbindungen eines Dritten reitet. Das Full Mesh, das das vermeiden würde, will vier Ports pro Server. Das ist die echte Decke dieses Entwurfs, und es ist nicht das Routing-Protokoll. OpenFabric kommt gut zurecht. Es ist, dass die Ports pro Knoten festliegen, und deshalb macht über drei Knoten hinaus jede neue Kiste mehr von deinem Verkehr zum Transit eines anderen.\nUnd die ehrliche Anmerkung, denn für einen Aufbau, der bis hierher nur über die Weboberfläche lief, zählt sie: ein sysctl ist keine Handlung in der Weboberfläche. Nach der Regel von oben ist das damit eine Voraussetzung, die genannt werden muss, und nicht etwas, das man still auf der Kommandozeile richtet — schreib es ins Runbook, denn der Nächste, der das SDN-Fenster öffnet, sieht ein gesundes Fabric und keinen Hinweis darauf, dass ein Ring von einer Datei in /etc/sysctl.d abhängt.\nRückbau Der Rückbau ist der Aufbau in umgekehrter Richtung, in derselben Oberfläche: lösche die SDN-Objekte, die für das Mesh angelegt wurden, wende die Konfiguration an und stell fest, dass der Verwaltungszugang unberührt ist.\nDieser letzte Schritt ist der Grund, warum nic0 und der 2,5-Gbit-Switch da sind. Wenn das Zurückrollen des Mesh dich die Weboberfläche kosten könnte, war der Entwurf falsch, bevor du angefangen hast.\nBevor du anfängst Der Verwaltungszugang ist wirklich unabhängig vom Mesh. Prüf es, nimm es nicht an. Alle drei Knoten sind gesund, bevor irgendeine SDN-Änderung kommt. Knotennamen, Schnittstellennamen und Verkabelung sind aufgeschrieben, denn wenn nic1 auf einem Host nic2 auf einem anderen ist, wird das ein schlechter Nachmittag. Jumbo Frames sind auf beiden Mesh-Schnittstellen gesetzt, und die MTU rechnet den Overhead von VXLAN auf der Unterlage mit ein. Der Mesh-Bereich ist reserviert und wird nirgends sonst genutzt. Quellen Proxmox VE — Software-Defined Network — die Dokumentation zu SDN Fabrics. Fabrics „provide automated routing between nodes in a cluster“, OpenFabric ist „based on IS-IS and optimized for the spine-leaf topology common in data centers“, jeder Knoten braucht eine eigene Router-ID, und „a dummy \u0026rsquo;loopback\u0026rsquo; interface with the router-id is automatically created“ Proxmox VE — Cluster Manager — das Netz für Corosync und redundante Links, hinter dem Entwurf mit zwei Wegen für die Mitgliedschaft Proxmox VE — Deploy Hyper-Converged Ceph Cluster — die Netzerwartungen eines hyperkonvergenten Clusters Linux-Kernel — IP sysctl documentation — ip_forward und seine Vorgabe 0, die Steuerung forwarding pro Schnittstelle und die Warnung, dass eine Änderung am globalen Schalter die Konfiguration pro Schnittstelle zurücksetzt ","permalink":"https://blogs.damiendye.uk/de/proxmox/proxmox-routed-mesh-sdn-openfabric/","summary":"Drei Proxmox-Knoten direkt im Dreieck miteinander verkabelt, mit OpenFabric-Routing über das Mesh und Ceph plus VXLAN-Client-Netzen obendrauf. Vollständig in der Weboberfläche gebaut, und ehrlich darüber, wo der Entwurf aufhört zu skalieren.","title":"Ein Proxmox-Mesh ohne Switch mit SDN OpenFabric — Ceph und Client-Netze ohne 100-G-Switch"},{"content":"Das Problem mit kopierten Boot-Zeilen Such nach Proxmox-Tuning, und du findest eine einzige lange GRUB_CMDLINE_LINUX-Zeile, als Einheit vorgestellt, ohne Hinweis darauf, welches Flag wohin gehört.\nDas zählt mehr, als es klingt. Der Hypervisor und der Gast lösen entgegengesetzte Probleme.\nDer Host will bestimmten Zugriff auf echte Hardware: Verhalten der IOMMU, PCIe-Link-Zustände, physische Ruhezustände. Der Gast will aufhören, überhaupt so zu tun, als hätte er Hardware — seine Timer sind Näherungen, seine Ruhezustände Erfindung, und seine Hänger sind meist der Scheduler eines anderen. Damit kann dasselbe Flag auf einer Seite richtig sein, auf der anderen sinnlos und gelegentlich schädlich.\nUnten steht, wohin jedes tatsächlich gehört.\nWohin jedes Kernel-Boot-Flag gehört Nur Host hier wohnt echte Hardware iommu=pt amd_iommu=pgtbl_v2 pcie_acs_override=… pcie_aspm=off pci=pcie_bus_perf → pcie_bus_safe bei USB4 processor.max_cstate=1 + intel_idle.max_cstate auf Intel amd_pstate=disable setz auch einen Governor Der Gast hat keine PCIe-Links, keine C-States und kein cpufreq. Nur Gast aufhören, Hardware zu spielen cpuidle.off=1 Ruhezustände im Gast sind Erfindung nmi_watchdog=0 eine weggenommene vCPU löst ihn aus softlockup_panic=0 der Hänger war Schuld des Hosts Lass kvm-clock in Ruhe. Erzwing nicht tsc oder hpet — die Zähler sind nicht deine. Auf dem Host bedeuten diese drei alle etwas anderes, und zwei davon kosten dich etwas Echtes. Beide — andere Gründe gleiches Flag, eigene Entscheidung mitigations=off Host: Lecks Gast zu Host Gast: Prozess-Isolation default_hugepagesz + hugepages Host: unterlegt Gast-RAM Gast: unterlegt eine Anwendung wähle eine Schicht, nicht beide watchdog_thresh / nowatchdog Host: Lärm, den du annahmst Gast: war nie vertrauenswürdig „Beide“ heißt nicht, dass du es an beiden Stellen setzen sollst. Es heißt, die Entscheidung muss zweimal fallen. Keines — die tun nichts amd_iommu=on keine gültige Option; der Kernel protokolliert „Unknown option - 'on'“ und macht weiter consoleblank=0 schon die Kernel-Vorgabe Enthält eine kopierte Boot-Zeile eines von beiden, wurde sie nie gegen /proc/cmdline geprüft — die billigste Prüfung, die es gibt, und die, die auch den Fehler mit dem falschen Bootloader auffängt. Die Flags, die im Umlauf sind, sortiert. Zwei der beliebtesten tun auf keiner Seite etwas, und die Watchdog-Zeile ist eine echte Ermessensfrage und keine Regel. Zuerst: bearbeitest du überhaupt die richtige Datei? Eine Proxmox-Installation auf ZFS-Root startet mit systemd-boot, wo /etc/default/grub von niemandem gelesen wird. Sie zu bearbeiten und neu zu starten erzeugt keine Änderung und keinen Fehler. Das ist eine ärgerliche Stunde.\nproxmox-boot-tool status # tells you which bootloader is in use # systemd-boot: edit /etc/kernel/cmdline, then proxmox-boot-tool refresh # GRUB: edit /etc/default/grub, then update-grub So oder so: prüfen statt annehmen.\ncat /proc/cmdline Und auf der GRUB-Seite nimm GRUB_CMDLINE_LINUX_DEFAULT, nicht GRUB_CMDLINE_LINUX. Letzteres gilt für jeden Boot-Eintrag, den Rettungseintrag eingeschlossen — und die Rettung ist genau der Moment, in dem du Standardverhalten willst und nicht abgeschaltete Mitigations und festgenagelte C-States.\nDie Host-Zeile IOMMU und Passthrough iommu=pt amd_iommu=pgtbl_v2 pcie_acs_override=downstream,multifunction iommu=pt versetzt die IOMMU in den Passthrough-Modus: Geräte, die VMs zugewiesen sind, werden übersetzt, Geräte des Hosts selbst umgehen die Übersetzung. Es ist echt und wird in arch/x86/kernel/pci-dma.c behandelt, das iommu_set_default_passthrough(true) aufruft. Der Kernel dokumentiert es als gleichwertig mit iommu.passthrough=1.\namd_iommu=on gibt es nicht. Das ist der am häufigsten kopierte nicht existierende Parameter in Proxmox-Anleitungen. Das parse_amd_iommu_options() des Kernels nimmt fullflush, force_enable, off, force_isolation, pgtbl_v1, pgtbl_v2, irtcachedis, nohugepages und v2_pgsizes_only. Alles andere landet hier:\npr_notice(\u0026#34;Unknown option - \u0026#39;%s\u0026#39;\\n\u0026#34;, str); AMD-Vi ist standardmäßig an, wenn die Firmware es angibt. Sieh in dein eigenes Protokoll, und du findest, dass der Parameter nie die Arbeit getan hat, die man ihm zuschrieb:\ndmesg | grep -i \u0026#34;AMD-Vi\\|Unknown option\u0026#34; amd_iommu=pgtbl_v2 ist gültig — es wählt das v2-Format für DMA-Seitentabellen, das die Struktur der CPU-Seitentabellen mitnutzt statt AMDs eigener. Zwei Dinge dazu: die Dokumentation begrenzt es auf die DMA-API, also die Gerätedomänen des Hosts selbst und nicht die VFIO-Domänen für Passthrough; und es scheitert sicher, mit einer Protokollzeile, auf die du prüfen solltest:\nif (amd_iommu_pgtable == PD_MODE_V2) { if (!amd_iommu_v2_pgtbl_supported()) { pr_warn(\u0026#34;Cannot enable v2 page table for DMA-API. Fallback to v1.\\n\u0026#34;); amd_iommu_pgtable = PD_MODE_V1; } } Es lohnt sich also, das auf einem Knoten mit schwerem IO auf der Host-Seite zu messen, und es lohnt sich zu prüfen, dass du es wirklich bekommen hast.\npcie_acs_override=downstream,multifunction ist der Patch von Proxmox außerhalb des Kernel-Baums. Er teilt IOMMU-Gruppen auf, indem er eine Isolation behauptet, die die Hardware nicht angibt, und genau das macht Passthrough auf Consumer-Platinen möglich. Es heißt aber auch, dem Kernel etwas Unwahres über die Topologie zu erzählen. In Ordnung auf einer Kiste, deren Gästen du so viel traust wie dem Host. Sonst nicht in Ordnung. Mehr zum Warum steht in dem Beitrag über die IOMMU-Steuer.\nLatenz und Zittern pcie_aspm=off processor.max_cstate=1 amd_pstate=disable pcie_aspm=off hält PCIe-Links aus Zuständen geringer Leistung heraus, damit ein eintreffendes IO nie darauf wartet, dass einer aufwacht. Es kostet ein paar Watt pro Link und nimmt einen Latenzausläufer weg, der schwer zu diagnostizieren ist. Siehe PCIe-ASPM und Passthrough.\nprocessor.max_cstate=1 begrenzt die ACPI-Ruhe auf C1. Achte auf den Treiber: das ist das Stellrad von processor/acpi_idle, auf Intel brauchst du also zusätzlich intel_idle.max_cstate=1, weil intel_idle Vorrang hat. Auf AMD ist dieses hier das richtige.\nEs gibt ein echtes Gegenargument. Tiefer Schlaf auf ruhenden Kernen ist das, was dem Paket thermischen und Leistungsspielraum gibt, die beschäftigten Kerne hochzutakten, alles bei C1 festzunageln kann also deine Spitzenfrequenz für einen Thread senken und gleichzeitig den Verbrauch im Ruhezustand heben. Auf einem latenzempfindlichen Host ist der Handel meist gut. Auf einem Host, der Durchsatz jagt, vielleicht nicht. Miss es, statt es zu erben.\namd_pstate=disable fällt auf acpi-cpufreq zurück. Es lohnt sich, die dokumentierten Alternativen zu kennen, bevor man danach greift: passive (der Treiber verlangt eine Leistungsstufe), active (der EPP-Treiber, der zu Leistung oder Effizienz neigt) und guided. active mit Neigung zur Leistung oder passive samt Governor performance bringt oft dieselbe Latenz und behält die feinere Steuerung von CPPC. Und wenn du es abschaltest, setz bewusst einen Governor — auf acpi-cpufreq mit schedutil zu landen kann ein Rückschritt sein.\nSpeicher default_hugepagesz=1G hugepages=64 default_hugepagesz=1G allein reserviert nichts. Der Kernel dokumentiert es als Festlegung von „the size of the default HugeTLB page… the default hugetlb size used for shmget(), mmap() and mounting hugetlbfs“ — also der Größe der voreingestellten HugeTLB-Seite: eine Einheit, keine Zuweisung. Die Zuweisung kommt von hugepages=, dokumentiert als „Number of HugeTLB pages to allocate at boot“, die Zahl der beim Start zuzuweisenden Seiten.\nDas zählt bei 1 GiB weit mehr als bei 2 MiB, weil zusammenhängende 1-GiB-Bereiche praktisch nicht zu bekommen sind, sobald der Host gelaufen ist und den Speicher zersplittert hat. Der Start ist deine einzige verlässliche Gelegenheit.\nDann muss der Gast mitmachen (hugepages: 1024 in der VM-Konfiguration). Reservierte Seiten, die niemand nutzt, sind nur Speicher, den du nicht zurückbekommst, und du verlierst Ballooning und KSM auf den VMs, die sie nutzen.\nDer Handel mit der Sicherheit mitigations=off Das ist nicht ein Schalter. Der Kernel klappt es in eine Liste auf, und auf einem Hypervisor sind das die Einträge, auf die es ankommt:\nl1tf=off mds=off mmio_stale_data=off kvm.nx_huge_pages=off gather_data_sampling=off retbleed=off spec_rstack_overflow=off nospectre_v2 nopti indirect_target_selection=off Die Zusammenfassung des Kernels selbst lautet „improves system performance, but it may also expose users to several CPU vulnerabilities“ — es verbessert die Leistung des Systems, kann Nutzer aber auch mehreren CPU-Schwachstellen aussetzen. L1TF, MDS und MMIO Stale Data sind speziell Lecks vom Gast zum Host und vom Gast zum Gast, und kvm.nx_huge_pages ist die Mitigation gegen iTLB-Multihit in KVM selbst.\nVertretbar auf einer Kiste mit einem Mandanten, in der jeder Gast so viel Vertrauen hat wie der Host. Nicht vertretbar dort, wo Gäste nicht vertrauenswürdig sind oder verschiedenen Mandanten gehören. Und beachte, dass es sich mit pcie_acs_override stapelt: zwei unabhängige Isolationszusagen, in derselben Zeile entfernt. Es lohnt sich, das mit Absicht zu tun statt durch Erbschaft.\nPCIe über USB4 ändert zwei davon Kommen deine PCIe-Geräte über USB4 oder Thunderbolt — eine externe GPU oder ein NVMe-Gehäuse —, ändern sich zwei der Antworten von oben.\nMPS-Tuning ist nicht mehr kostenlos Auf festen Slots ist pci=pcie_bus_perf ein kleiner kostenloser Gewinn. Der Kernel beschreibt es so:\nSet device MPS to the largest allowable MPS based on its parent bus. Also set MRRS (Max Read Request Size) to the largest supported value… for best performance.\nAlso: die MPS eines Geräts auf den größten anhand seines übergeordneten Busses zulässigen Wert setzen, und die MRRS ebenfalls auf den größten unterstützten Wert, für die beste Leistung.\nDer Haken ist, dass es Bridges beim Start konfiguriert, aus der beim Start vorhandenen Topologie. Über USB4 ist Hot-Plug der normale Fall, und ein später hinzugefügtes Gerät kann eine kleinere MPS können als die, auf die die Bridge schon gesetzt wurde.\nDer Kernel sagt das Stille laut, während er eine andere Politik anpreist:\npcie_bus_peer2peer — Set every device\u0026rsquo;s MPS to 128B, which every device is guaranteed to support… This also guarantees that hot-added devices will work.\nAlso: die MPS jedes Geräts auf 128 B setzen, was jedes Gerät garantiert kann — und das stellt auch sicher, dass im Betrieb hinzugefügte Geräte funktionieren.\nNur eine Politik trägt diese Zusicherung, und es ist die, die alles auf 128 Byte festnagelt — genau das, dem MaxPayloadSize-Tuning entkommen will. Für eine Hot-Plug-Topologie ist pcie_bus_safe (der größte Wert, den alle Geräte unter dem Root Complex können) oder einfach tune_off stehen zu lassen der sicherere Anfang. Der Switch im Tunnel begrenzt die erreichbare MPS ohnehin, die Decke war also nie deine, sie zu heben.\nWarum Hot-Plug die Antwort auf die MPS-Politik ändert Beim Start konfiguriert\u0026#160;pcie_bus_perf\u0026#160;die Bridge aus dem, was es sehen kann Bridge — MPS 512 Gerät A · 512 Gerät B · 512 beim Start vorhanden im Betrieb dazu · nur 256 passt nicht nichts neu verhandelt In einem Gehäuse passiert das nie — die Topologie beim Start ist die Topologie für immer. An einem USB4-Port ist es der Normalfall. Die vier Politiken, und welche der Kernel für Hot-Plug sicher nennt pcie_bus_tune_off die BIOS-Werte in Ruhe lassen pcie_bus_safe größter Wert, den alle Geräte unter dem Root Complex können pcie_bus_perf größter Wert, den der übergeordnete Bus zulässt, pro Gerät — plus MRRS pcie_bus_peer2peer 128 B überall — \"guarantees that hot-added devices will work\" Nur eine Politik trägt diese Zusicherung, und es ist die, die die Payload-Größe wegwirft, für die du getunt hast. Die Bridge wird einmal konfiguriert, beim Start, aus den damals vorhandenen Geräten. Alles danach muss mit der Entscheidung leben — was in einem Gehäuse in Ordnung ist und an einem Port nicht. Der Sicherheitsstapel wird ernst Externes PCIe heißt, dass jemand ein DMA-fähiges Gerät in deinen Hypervisor stecken kann. Die Thunderbolt-Dokumentation des Kernels ist da direkt:\n…the connected devices can be DMA masters and thus read contents of the host memory without CPU and OS knowing about it. There are ways to prevent this by setting up an IOMMU but it is not always available for various reasons.\nAlso: die angeschlossenen Geräte können DMA-Master sein und damit den Inhalt des Host-Speichers lesen, ohne dass CPU und Betriebssystem davon wissen; es gibt Wege, das mit einer IOMMU zu verhindern, aber die ist aus verschiedenen Gründen nicht immer verfügbar.\nDie IOMMU ist die Verteidigung. Zähl jetzt, was die Host-Zeile mit ihr macht. iommu=pt gibt Geräten des Hosts unübersetzte Identitätsdomänen, pcie_acs_override behauptet eine Isolation, die nicht da ist, und mitigations=off schaltet die Mitigations zur Gast-Isolation ab. Jedes ist allein vertretbar. Zusammen, auf einer Maschine mit einem körperlich erreichbaren USB4-Port, stapeln sie sich.\nPrüf, wo du stehst:\ncat /sys/bus/thunderbolt/devices/domain*/security # none | user | secure | dponly | usbonly none neben dieser Boot-Zeile ist eine offene Tür. Sind die Ports für Leute erreichbar, denen du kein Root geben würdest, wäre iommu=pt das Erste, was ich überdenken würde.\nDie Gast-Zeile Das sind die, die in die VM gehören, und drei davon bedeuten hier etwas anderes als auf dem Host.\nnmi_watchdog=0 softlockup_panic=0 cpuidle.off=1 cpuidle.off=1 schaltet das cpuidle-Subsystem ab. In einem Gast ist das nahe an kostenlos: die Ruhezustände des Gasts sind Emulation, und es gibt keinen physischen Kern, den man schlafen legen könnte, das Rahmenwerk bringt dir also nur Aufwachlatenz. Auf dem Host ist dasselbe Flag ein echter Handel um Strom und Boost-Spielraum, und es überlappt mit processor.max_cstate=1. Nur auf der Gast-Seite.\nsoftlockup_panic=0 verhindert, dass ein Soft Lockup den Gast in eine Panik schickt. Das schützt in einer VM wirklich, denn ein Soft Lockup dort ist häufig nicht die Schuld des Gasts. Eine weggenommene vCPU sieht genau aus wie eine Aufgabe, die nicht abgeben will. Das ist derselbe Mechanismus, der dahintersteht, warum der Uhr einer VM nicht zu trauen ist. Prüf aber, ob du es brauchst. Auf den meisten Bauten ist es schon 0.\nsysctl kernel.softlockup_panic nmi_watchdog=0 ist das interessante, und es verdient mehr als eine Regel.\nDie Watchdog-Frage Es gibt zwei Melder, die eine Schwelle teilen:\nwatchdog_thresh= — Set the hard lockup detector stall duration threshold in seconds. The soft lockup detector threshold is set to twice the value. A value of 0 disables both. Default is 10 seconds.\nAlso: setzt die Schwelle für die Hängedauer des Hard-Lockup-Melders in Sekunden; die Schwelle des Soft-Lockup-Melders wird auf das Doppelte gesetzt; 0 schaltet beide ab; Vorgabe sind 10 Sekunden.\nEin Hard Lockup (nmi_watchdog) schlägt an, wenn eine CPU überhaupt keine Timer-Interrupts mehr annimmt. Ein Soft Lockup schlägt an, wenn eine Aufgabe eine CPU doppelt so lange belegt, ohne abzugeben.\nIn einem Gast ist es richtig, den Hard-Lockup-Melder abzuschalten. Eine weggenommene vCPU kann ihn ohne eigene Schuld auslösen, und die Arbeit des Melders mit Leistungszählern erzeugt VM-Exits für ein Signal, das nichts als Lärm war.\nAuf dem Host ist es eine Ermessensfrage, und sie hängt davon ab, welchem Lärm du tatsächlich nachjagst. Überbuchung hungert Gäste aus, nicht den Host-Kernel — die physischen CPUs des Hosts nehmen weiter Interrupts an, wie voll die VMs auch sind. Der Protokolllärm, den ein beschäftigter Hypervisor wirft, sind also überwiegend Meldungen zu Soft Lockups und RCU-Hängern, nicht Berichte über Hard Lockups per NMI. Ist das der Lärm, wird nmi_watchdog=0 ihn nicht abstellen, und softlockup_panic=0 auch nicht — das stoppt die Panik, nicht die Meldungen.\nDie zielgenauen Stellräder sind:\nwatchdog_thresh=30 # hard 30s, soft 60s — scale to taste nowatchdog # honest single flag: disables both detectors sysctl -w kernel.soft_watchdog=0 # runtime, keeps hard-lockup detection Es gibt einen eigenen und besseren Grund, den Hard-Lockup-Melder auf einem beschäftigten Host abzuschalten, und er hat nichts mit Lärm zu tun: er verbraucht pro CPU einen Leistungszähler der Hardware. Deshalb nimmt der Parameter rNNN, um ein rohes Perf-Ereignis einzustellen. Machst du Profiling über die PMU oder betreibst du eine absichtlich überbuchte Kiste, in der du Latenzschwankung als Preis der Dichte schon angenommen hast, ist es ein vernünftiger Handel, diesen Zähler zurückzugeben — und kleine Hänger, für die du bewusst unterschrieben hast, sind keine Vorfälle.\nTriff die Wahl bloß aus diesem Grund und nicht wegen des Lärms, denn nur einer von beiden stimmt.\nconsoleblank=0 tut nichts. Der Kernel dokumentiert die Abschaltzeit der Konsole als „A value of 0 disables the blank timer. Defaults to 0.“ — 0 schaltet den Abschalt-Timer ab, und die Vorgabe ist 0. Es ist schon aus. Harmlos, aber es ist der zweite verbreitete Parameter ohne Wirkung, und ihn mitzuschleppen lässt eine Zeile überlegt aussehen, wenn sie kopiert ist.\nKurzübersicht: wohin jedes Flag gehört Flag Host Gast Anmerkungen iommu=pt ja nein Der Host besitzt die IOMMU. Im Gast nur relevant bei geschachteltem Passthrough mit vIOMMU amd_iommu=pgtbl_v2 ja nein DMA-API-Domänen des Hosts. Prüf, dass du v2 bekommen hast und nicht den v1-Rückfall amd_iommu=on — — Keine gültige Option. Der Kernel protokolliert „Unknown option - \u0026lsquo;on\u0026rsquo;“ pcie_acs_override=… ja nein Proxmox-Patch, nur Host-Topologie. Schwächt die Isolation von Entwurf her pcie_aspm=off ja nein In einem Gast gibt es keine echten PCIe-Links; der Host besitzt den physischen Link pci=pcie_bus_perf ja nicht verlässlich Der Host setzt die MPS auf der Leitung. Nimm stattdessen pcie_bus_safe, wenn Geräte über USB4 kommen processor.max_cstate=1 ja nein Echte Ruhezustände gehören dem Host. Auf Intel intel_idle.max_cstate=1 ergänzen amd_pstate=disable ja nein Gäste steuern die CPU-Frequenz nicht cpuidle.off=1 mit Vorsicht ja Im Gast kostenlos. Auf dem Host kostet es Boost-Spielraum und überlappt mit max_cstate nmi_watchdog=0 Ermessen ja Im Gast richtig. Auf dem Host: wegen des PMU-Zählers, nicht wegen des Lärms softlockup_panic=0 nein ja Hänger im Gast kommen oft vom Scheduler des Hosts. Meist schon die Vorgabe consoleblank=0 — — Wirkungslos. Die Kernel-Vorgabe ist schon 0 mitigations=off beide beide Auf beiden gültig, mit anderer Risikorechnung: Lecks vom Gast zum Host auf dem Host, Prozess-Isolation im Gast default_hugepagesz + hugepages= beide beide Host: er unterlegt VM-Speicher. Gast: eine Last in der VM, die sie will. Andere Zwecke, gleiche Flags watchdog_thresh= / nowatchdog beide beide Host: Hänger ruhigstellen, die du angenommen hast. Gast: dem Melder war nie zu trauen Drei gehören wirklich auf beide Seiten, und es lohnt sich, genau zu sein, dass „beide“ nicht „aus demselben Grund“ heißt:\nmitigations=off geht es auf dem Host um Lecks vom Gast zum Host und vom Gast zum Gast. Im Gast geht es um Prozess-Isolation in dieser VM. Du kannst es vernünftig an einer Stelle abschalten und an der anderen nicht. Hugepages unterlegen auf dem Host den Gast-Speicher; im Gast unterlegen sie eine Anwendung. Sie zweimal für denselben Speicher zu reservieren ist Verschwendung, entscheide also, welche Schicht sie will. Watchdog-Tuning ist auf dem Host eine Lärmentscheidung und im Gast eine Richtigkeitsentscheidung. Alles andere gehört auf eine Seite oder die andere, und zwei davon sind überhaupt keine Wahl.\nDie zwei Zeilen Host, auf einer AMD-Kiste mit Passthrough und einem Mandanten:\nGRUB_CMDLINE_LINUX_DEFAULT=\u0026#34;quiet amd_iommu=pgtbl_v2 iommu=pt pcie_acs_override=downstream,multifunction pcie_aspm=off pci=pcie_bus_perf default_hugepagesz=1G hugepages=64 processor.max_cstate=1 amd_pstate=disable mitigations=off\u0026#34; Tausch pci=pcie_bus_perf gegen pcie_bus_safe, wenn etwas über USB4 kommt. Lass mitigations=off weg, wenn nicht alle Gäste deine sind. Auf Intel ersetzt intel_iommu=on die AMD-Flags, und intel_idle.max_cstate=1 kommt zur C-State-Grenze dazu.\nLinux-Gast:\nGRUB_CMDLINE_LINUX_DEFAULT=\u0026#34;quiet nmi_watchdog=0 softlockup_panic=0 cpuidle.off=1\u0026#34; Und lass kvm-clock im Gast in Ruhe — erzwing nicht tsc oder hpet. Die paravirtuelle Uhr gibt es genau deshalb, weil die Zähler nicht deine sind. Das ist das ganze Argument in dem Beitrag über die Zeit in VMs.\nWas man löschen sollte Hast du eine Zeile aus einem Forumsbeitrag geerbt, sind diese zwei das Erste, was rausfliegt, denn sie kosten dich nichts und beweisen, dass die Zeile nie geprüft wurde:\namd_iommu=on — keine gültige Option; der Kernel protokolliert „Unknown option - \u0026lsquo;on\u0026rsquo;“ und macht weiter consoleblank=0 — schon die Vorgabe Und prüf den Rest nach einem Neustart gegen /proc/cmdline. Jedes Flag auf dieser Zeile sollte eines sein, für das du einen Grund nennen kannst.\nKannst du nicht sagen, was ein Flag tut, ist es kein Tuning. Es ist Aberglaube. Und es wird von jemandem in den nächsten Aufbau kopiert, der dir vertraut.\nQuellen Linux-Kernel — die Kommandozeilenparameter des Kernels — mitigations=, default_hugepagesz=, hugepages=, watchdog_thresh=, nowatchdog, consoleblank=, processor.max_cstate=, amd_pstate=, amd_iommu= und die pci=pcie_bus_*-Politiken Linux-Kernel-Quelltext — drivers/iommu/amd/init.c — parse_amd_iommu_options() und die Prüfung der v2-Seitentabellenfähigkeit, die auf v1 zurückfällt Linux-Kernel-Quelltext — arch/x86/kernel/pci-dma.c — iommu=pt, das iommu_set_default_passthrough() aufruft Linux-Kernel — Thunderbolt — Sicherheitsstufen, und angeschlossene Geräte als DMA-Master Proxmox VE — System Administration — proxmox-boot-tool status und das Bearbeiten der Kernel-Kommandozeile für systemd-boot gegenüber GRUB ","permalink":"https://blogs.damiendye.uk/de/proxmox/kernel-boot-flags-host-guest/","summary":"Die meisten Proxmox-Tuning-Zeilen, die du im Netz findest, sind ein Klumpen Kernel-Flags. Die Hälfte gehört auf den Hypervisor, die Hälfte in den Gast, zwei der beliebtesten tun überhaupt nichts, und ein paar bedeuten etwas anderes, je nachdem auf welcher Seite der Grenze sie landen.","title":"Zwei Boot-Zeilen — welche Kernel-Flags auf einen Proxmox-Host gehören und welche in den Gast"},{"content":"Warum du eines wollen würdest QEMU kann einen echten NVMe-Controller emulieren — kein paravirtuelles Gerät, das einen Treiber braucht, den du mitbringst, sondern einen PCIe-NVMe-Controller, den ein Gast als normale SSD erkennt und mit der NVMe-Unterstützung ansteuert, die er schon hat.\nDas ist der ganze Reiz, und er ist mehr wert, als er klingt.\nLinux hat seit Jahren einen eingebauten nvme-Treiber. Windows liefert stornvme seit Windows 8.1 und Server 2012 R2. Ein Gast startet also, zählt einen PCIe-NVMe-Controller auf, lädt seinen eigenen Treiber und findet eine Platte. Kein VirtIO-ISO, keine Treiber-Einspeisung bei der Installation, und kein Bildschirm „keine Laufwerke gefunden“ mitten im Windows-Installationsprogramm.\nWer je vor diesem Bildschirm gesessen hat, mit eingebundenem VirtIO-ISO und einem Installationsprogramm, das trotzdem darauf beharrt, es gäbe keine Platten, wird den Reiz sofort sehen.\nDer zweite Grund ist, dass es sich bis nach oben wie NVMe verhält. nvme-cli funktioniert. Namespaces sind echt. LBA-Formate, Metadaten-Byte und Schutzinformationen sind alle einstellbar. Das macht es zu einem sehr guten Ort, um die Handgriffe zu üben, die du auf Hardware mit Daten darauf nicht üben solltest.\nWie man eines hinzufügt Proxmox hat dafür kein Häkchen in der GUI und keinen Konfigurationsschlüssel. Es ist ein rohes QEMU-Gerät, es kommt also in args: in /etc/pve/qemu-server/\u0026lt;vmid\u0026gt;.conf.\nDie QEMU-Dokumentation gibt das minimale Paar: ein unterlegtes Laufwerk ohne Schnittstelle und den Controller, der es verbraucht. Direkt in /etc/pve/qemu-server/\u0026lt;vmid\u0026gt;.conf geschrieben, ohne Anführungszeichen:\nargs: -drive file=/var/lib/vz/images/100/nvm.img,if=none,id=nvmidentifier -device nvme,serial=LAB-NVME-01,drive=nvmidentifier if=none zählt: es sagt QEMU, das Laufwerk nicht an einen voreingestellten Controller zu hängen, denn die Zeile -device nvme wird es beanspruchen. Das id= am Laufwerk und das drive= am Gerät müssen übereinstimmen. Diese Paarung ist es, die die zwei Hälften verbindet.\nDas serial= ist Pflicht; QEMU weigert sich, die VM ohne eines zu starten. Wähl etwas, das du wiedererkennst, denn es ist genau das, was der Gast in nvme list und smartctl zurückmeldet, und „welches dieser vier gleichen virtuellen Laufwerke ist welches“ ist eine Frage, die du irgendwann stellen wirst.\nAnführungszeichen: der Teil, der alle erwischt Ob du diese Zeichenkette in Anführungszeichen setzt, hängt davon ab, wo du sie tippst, und es verdreht zu bekommen ist der häufigste Grund, warum eines davon beim ersten Versuch nicht geht.\nProxmox speichert den Wert von args: und teilt ihn später mit Text::ParseWords::shellwords. In der Konfigurationsdatei werden Anführungszeichen also beachtet und entfernt. Eine vollständig eingefasste Zeichenkette wird zu einem einzigen Argument:\n# WRONG in the config file — collapses to one argv element QEMU cannot parse args: \u0026#34;-drive file=…,if=none,id=nvmidentifier -device nvme,serial=…,drive=nvmidentifier\u0026#34; Durch shellwords gelaufen gibt das genau ein Element. Ohne Anführungszeichen gibt dieselbe Zeile die vier, die QEMU wirklich braucht: -drive, ihren Parameterklumpen, -device, seinen Parameterklumpen.\nAuf der Kommandozeile ist es umgekehrt, denn dort setzt du für deine Shell in Anführungszeichen und nicht für Proxmox. Hier sind die Anführungszeichen nötig, und was in der Konfiguration landet, ist der Wert ohne sie:\nqm set 100 --args \u0026#34;-drive file=/var/lib/vz/images/100/nvm.img,if=none,id=nvmidentifier -device nvme,serial=LAB-NVME-01,drive=nvmidentifier\u0026#34; Beides ist richtig. Sie sind bloß nicht austauschbar. Baust du die Zeile mit qm set, prüf das Ergebnis danach mit qm config 100, und du wirst sie nackt gespeichert sehen. Das ist die Form, die die Konfigurationsdatei will.\nLeg das unterlegte Abbild zuerst an, wenn es nicht existiert:\nqemu-img create -f raw /var/lib/vz/images/100/nvm.img 32G Mehr als ein Namespace Für alles jenseits einer einzelnen Platte trenn den Controller von seinen Namespaces:\n-device nvme,id=nvme-ctrl-0,serial=deadbeef -drive file=nvm-1.img,if=none,id=nvm-1 -device nvme-ns,drive=nvm-1 Namespace-Kennungen werden von 1 aufwärts automatisch vergeben. Das ist die Aufstellung, die das Gerät zum Lernen wirklich nützlich macht, denn Namespace-Verwaltung ist der Teil von NVMe, an den die meisten Leute nie kommen.\nEin 4Kn-Namespace, virtuell Das Namespace nimmt die üblichen Eigenschaften zur Blockgröße, und QEMU leitet die LBA-Datengröße direkt daraus ab. hw/nvme/ns.c berechnet den Formatexponenten als ds = 31 - clz32(ns-\u0026gt;blkconf.logical_block_size). Das gibt dir also ein richtiges 4-K-natives Namespace:\n-device nvme-ns,drive=nvm-1,logical_block_size=4096,physical_block_size=4096 Das Namespace-Gerät nimmt außerdem ms für Metadaten-Byte pro LBA, mset für erweiterte LBAs und pi und pif für Art und Wächterformat der Schutzinformationen.\nDas ist ein vollständiges Labor für alles in dem Beitrag über 4Kn und 512e — logische Blöcke von 512 gegen 4096 Byte, Formate mit Metadaten, T10-PI — auf einem Gerät, das du so oft zerstören kannst, wie du willst.\nPrüfen, dass es gelandet ist Im Gast:\nlsblk -o NAME,MODEL,SIZE,LOG-SEC,PHY-SEC nvme list nvme id-ns -H /dev/nvme0n1 | grep -i \u0026#34;lbaf\\|data size\u0026#34; Du solltest ein echtes NVMe-Namespace sehen, mit den Blockgrößen, die du verlangt hast.\nWas du aufgibst Drei Dinge, und die ersten zwei sind keine Abwägungen bei der Leistung. Es sind entfernte Fähigkeiten. Kenne sie, bevor du irgendetwas auf das Gerät legst.\nWas Proxmox verwaltet, und wovon ein über args angehängtes Gerät außen steht In der VM-Konfiguration, als Platte scsi0: local-zfs:vm-100-disk-0,iothread=1 Proxmox besitzt das Volume und weiß, dass es da ist In vzdump-/PBS-Sicherungen enthalten ja PVE-Snapshots ja Live-Migration ja Größe ändern und Platte verschieben in der GUI ja In der Speicheransicht gezählt ja Über args: angehängt -device nvme,drive=nvm1,serial=… ein rohes QEMU-Gerät — PVE weiß nichts davon In Sicherungen enthalten nein PVE-Snapshots nein Live-Migration nein Größe ändern und verschieben nein In der Speicheransicht gezählt nein Nur eines dieser Neins meldet sich. Die Live-Migration scheitert mit einem Fehler, weil QEMU das Gerät als nicht migrierbar markiert. Die Sicherung gelingt einfach ohne die Platte darin — und deshalb gehört das in dein Runbook und nicht bloß in dein Gedächtnis. Proxmox verwaltet, was in der VM-Konfiguration als Platte steht. Ein über args angehängter Controller liegt außerhalb davon, jede Funktion, die auf der Speicherschicht aufbaut, gilt für ihn also einfach nicht. 1. Live-Migration ist aus Das ist keine Grenze von Proxmox und kein Versehen. QEMU erklärt das Gerät im Gerätemodell selbst für nicht migrierbar. Aus hw/nvme/ctrl.c in QEMU 10.2:\nstatic const VMStateDescription nvme_vmstate = { .name = \u0026#34;nvme\u0026#34;, .unmigratable = 1, }; Drei Zeilen, und die mittlere ist die ganze Geschichte. Der Controller hat keinen Migrationszustand, QEMU weist die Migration also ab, statt sie zu versuchen. Das ist das richtige Scheitern. Du bekommst einen Fehler, keinen Gast, der auf einem anderen Knoten mit einer verwirrten Platte weiterläuft.\nEs gibt einen zweiten, unabhängigen Grund, warum es nicht gehen kann: Proxmox weiß nicht, dass die Platte existiert. Selbst wenn QEMU den Gerätezustand bewegen könnte, würde nichts in der Migrationslogik von PVE dafür sorgen, dass das unterlegte Volume auf dem Ziel verfügbar ist.\nEs lohnt sich aber, das zu beobachten: der Entwicklungszweig von QEMU hat das pauschale Flag durch eine Funktion nvme_set_migration_blockers() ersetzt, die Migration erlaubt und sie nur für bestimmte Funktionen sperrt. Mehr als ein Namespace zum Beispiel, wo der Kommentar festhält „we don\u0026rsquo;t handle this in migration code yet“, das sei im Migrationscode noch nicht behandelt. Das ist in keiner Ausgabe bis einschließlich 10.2 erschienen, es hilft dir also heute nicht, aber diese Einschränkung sieht danach aus, als würde sie weicher. Prüf deine eigene QEMU-Version, statt einem Beitrag zu trauen.\n2. Proxmox-Sicherungen werden es nicht sehen vzdump und der Proxmox Backup Server sichern die Volumes, die in der VM-Konfiguration als Platten erscheinen — scsi0, virtio0 und so weiter. Eine über args: angehängte Platte ist keine davon. Es ist ein rohes QEMU-Gerät, von dem PVE nichts weiß.\nDie Sicherung läuft also, meldet Erfolg und enthält das Gerät nicht.\nDieser Fehlerfall ist schlimmer als ein Fehler, denn nichts sagt es dir. Dasselbe gilt auf ganzer Linie: keine PVE-Snapshots, keine Größenänderung der Platte aus der GUI, kein Move Disk, keine Buchung in der Speicheransicht. Hast du das Volume über PVE angelegt und dann abgehängt, räumt PVE es vielleicht auch nicht auf. Ein Waisenkind, das darauf wartet, später jemanden zu verwirren.\nSollen Daten auf einem davon leben, sichere sie im Gast, und schreib irgendwo auf, dass der Hypervisor sie nicht abdeckt.\n3. Es ist nicht schneller als VirtIO SCSI Das überrascht Leute, denn „NVMe“ liest sich wie eine Leistungsfunktion. Hier ist es keine.\nVirtIO SCSI und VirtIO Block sind paravirtuell: der Treiber im Gast und der Hypervisor teilen einen Ringpuffer, der für genau diese Aufgabe entworfen ist, und der Gast weiß, dass er mit einem Hypervisor redet.\nDer emulierte NVMe-Controller ist von Entwurf her das Gegenteil. Er zeigt echte NVMe-Register, der Gast programmiert ihn also, als wäre er Hardware. Jeder Schreibvorgang auf eine Türklingel ist ein MMIO-Zugriff, der in den Hypervisor fällt. Korrekt, und pro IO teurer, als einen Deskriptor auf einen Ring zu legen.\nEin gemeinsamer Ring gegen emulierte Register Gast │ Hypervisor VirtIO SCSI — paravirtuell Treiber im Gast weiß, dass es eine VM ist gemeinsamer Ring beide Enden verstehen ihn Block-Schicht des Hosts 1 Hinweis Ein Deskriptor kommt auf den Ring, und der Host wird benachrichtigt. Der Ring liegt mit Absicht über der Grenze. Emuliertes NVMe — echte Register Treiber im Gast hält sich für Hardware NVMe-Register Türklingeln, Queues, MMIO Block-Schicht des Hosts jede Türklingel fällt hinein Abfangen + Emulieren, pro IO Der Gast tut genau, was er mit einem physischen Controller täte, und das ist der Punkt — sein eigener Treiber läuft unverändert. Deshalb ist es auch eine Funktion für Kompatibilität und nicht für Leistung. Interrupt-Zusammenfassung ist nicht unterstützt und aus: korrektes Verhalten von Hardware, zum Preis, Hardware zu emulieren. Der paravirtuelle Weg ist ein Ring, den Gast und Host beide verstehen. Der emulierte Weg lässt den Gast Register ansteuern, und jeder Schreibvorgang auf eine Türklingel fällt hinein — genaues Verhalten von Hardware, zum Preis der Hardware-Emulation. QEMUs eigene Dokumentation ist über die rauen Kanten des Geräts auch offen: die Zusammenfassung von Interrupts „is not supported and is disabled by default“, sie ist nicht unterstützt und aus, und die Zählwerte in der SMART-/Health-Log-Seite „are reset when the device is power cycled“, sie werden beim Aus- und Einschalten des Geräts zurückgesetzt.\nNichts davon macht es absolut gesehen langsam. Es ist völlig brauchbar. Es heißt bloß, dass du es nie in der Hoffnung auf mehr Durchsatz als VirtIO SCSI wählen solltest. Wähl es wegen des Treibers, oder wegen der NVMe-Semantik.\nWo es seinen Platz wirklich verdient Einen Gast ohne VirtIO-Medium installieren. Ein Windows-Installationsprogramm, das keine VirtIO-SCSI-Platte sieht, sieht eine NVMe-Platte, denn der Treiber ist schon im Abbild. Installiere darauf, und entscheide dann, ob du danach auf VirtIO wechselst. Appliances und Abbilder, die dir nicht gehören. Alles, was als festes Abbild ausgeliefert wird, dem VirtIO-Treiber fehlen und das du lieber nicht neu bauen willst. Lernen und Laborarbeit. nvme format --lbaf, Namespaces anlegen und anhängen, Metadaten und Schutzinformationen — die Handgriffe, die auf echter Hardware zerstörend und herstellerabhängig sind, sind hier kostenlos. Das ist der sicherste Weg, das Muskelgedächtnis aufzubauen, bevor du ein Laufwerk anfasst, auf das es ankommt. Die Topologie eines anderen nachbauen. Suchst du einen Fehler im NVMe-Aufbau eines Kunden, ist ein emulierter Controller mit passenden Namespaces und Blockgrößen eine viel schnellere Schleife, als sich dessen Hardware zu leihen. Was man produktiv stattdessen nimmt Für eine VM, die Leistung, PVE-Funktionen und ein ruhiges Leben braucht: VirtIO SCSI single, mit iothread=1, discard=on und ssd=1, auf cache=none. Das ist die Anordnung, die Live-Migration, Sicherungen, Snapshots und die Speicheransicht alle am Laufen hält.\nFür eine VM, die die letzten Prozent braucht und diese Funktionen bewusst aufgeben kann, ist die Antwort kein emuliertes NVMe-Gerät. Es ist echtes Passthrough, mit seinen eigenen harten Abwägungen, behandelt in dem Beitrag über die IOMMU-Steuer.\nDas emulierte NVMe-Gerät sitzt in keinem der beiden Lager. Damit ist es ein Werkzeug für Kompatibilität und fürs Labor, und darin ist es sehr gut.\nNimm es für die Aufgabe, in der es gut ist, und es wird dich nicht enttäuschen. Verlang von ihm eine Leistungsfunktion, und es enttäuscht dich sehr schnell.\nQuellen QEMU — NVMe Emulation — die Syntax von -drive/-device nvme, nvme-ns für mehrere Namespaces, die Namespace-Parameter ms/mset/pi/pif und die angegebenen Grenzen bei Interrupt-Zusammenfassung und SMART-Zählung QEMU-Quelltext — hw/nvme/ctrl.c — die Deklaration nvme_vmstate mit .unmigratable = 1 in der Ausgabe 10.2 QEMU-Quelltext — hw/nvme/ns.c — das Namespace, das sein LBA-Format aus logical_block_size ableitet Proxmox VE — Backup and Restore — was vzdump abdeckt, und die Sicherungsoptionen pro Volume, die es für Platten gibt, die PVE verwaltet Proxmox VE — Qemu/KVM Virtual Machines — VirtIO SCSI, iothread, discard und die unterstützten Plattenoptionen ","permalink":"https://blogs.damiendye.uk/de/proxmox/virtual-nvme-proxmox/","summary":"QEMU kann einen echten NVMe-Controller emulieren, der Gast nutzt also seinen eigenen eingebauten NVMe-Treiber, ohne VirtIO-Medium. Es ist auch von Entwurf her nicht migrierbar, für Proxmox-Sicherungen unsichtbar und nicht schneller als VirtIO SCSI. Hier steht, wie man eines hinzufügt und wann es sich lohnt.","title":"Ein virtuelles NVMe-Gerät in Proxmox — und die drei Dinge, die du aufgibst"},{"content":"Die Annahme, die jede Uhr macht Die Uhr eines Computers arbeitet, indem sie etwas Regelmäßiges zählt und darauf vertraut, dass es weiterzählt. Ein Quarz schwingt, ein Zähler steigt, und Software rechnet aus, wie viel Zeit vergangen ist.\nVirtualisierung zerbricht den Teil mit dem Vertrauen.\nDie KVM-Dokumentation des Kernels zur Zeitmessung bringt das Problem in einen Satz: „the virtual operating system does not run with 100% usage of the CPU, despite the fact that it may very well make that assumption“ — das virtuelle Betriebssystem läuft nicht mit 100 % der CPU, obwohl es genau das durchaus annehmen kann. Alles Weitere folgt daraus.\nDeine vCPU läuft nicht immer Eine vCPU ist ein Thread auf dem Host. Sie läuft, wenn der Scheduler des Hosts es sagt.\nWenn sie nicht läuft, ist der Gast nicht bloß unbeschäftigt — er ist abwesend. Er kann nicht zählen, er kann keinen Timer-Interrupt bedienen, und er hat keine Möglichkeit zu wissen, wie lange er weg war. Der Host führt das als Steal Time, was der ehrliche Name für „Zeit, die dir passiert ist statt für dich“ ist.\nTimer-Interrupts sind die Stelle, an der das am meisten weh tut. Ein Gast, der einen periodischen Tick verlangt, verlangt vom Host, Interrupts mit einer festen Rate zuzustellen, und der Host kann das nicht immer leisten. Wieder aus der Kernel-Dokumentation: „the host virtualization engine may not be able to deliver the proper number of interrupts per second, and so guest time may fall behind“ — die Virtualisierung des Hosts kann die richtige Zahl an Interrupts pro Sekunde vielleicht nicht liefern, und dann fällt die Gast-Zeit zurück.\nWarum die Timer-Ticks eines Gasts aufhören, gleichmäßig zu liegen Blech — die CPU gehört immer dir läuft Timer-Ticks, gleichmäßig — sie zu zählen gibt dir die Zeit In einer VM — die vCPU ist ein Thread auf dem Scheduler eines anderen läuft weggenommen weggenommen Ticks, die in den Lücken fällig waren, kommen spät, im Schwung oder gar nicht Der Gast sieht die gestrichelten Abschnitte nicht. Von innen hat die Uhr einfach weniger Ticks erzeugt als sie sollte — weshalb die Kernel-Dokumentation sagt, Gast-Zeit könne „may fall behind“, also zurückfallen, wenn der Host die verlangten Interrupts nicht liefern kann. Der Host nennt die gestrichelten Bereiche Steal Time. Der Gast nennt sie überhaupt nicht, denn er war nicht da. Die eigene Sicht des Gasts ist die untere Reihe: Ticks, die zu spät kommen, Ticks, die im Schwung kommen, und Lücken, die er nicht erklären kann. Er misst genauso den Scheduler des Hosts wie den Lauf der Zeit. Je höher die Tick-Rate, desto schlimmer, und ein überbuchter Host macht es noch schlimmer. Deshalb verdirbt ein beschäftigter Host auch die Zeitmessung ruhiger Gäste. Sie stehen alle in derselben Schlange für dieselben physischen Kerne.\nDie Zähler sind auch nicht deine Wenn periodische Ticks unzuverlässig sind, ist die naheliegende Antwort, stattdessen einen Zähler zu lesen. Das hat seine eigenen Probleme.\nDer TSC ist der schnelle, und die Kernel-Dokumentation ist unmissverständlich: „The TSC is a CPU-local clock in most implementations… the TSCs of different CPUs may start at different times“ — der TSC ist in den meisten Umsetzungen eine CPU-lokale Uhr, und die TSCs verschiedener CPUs können zu verschiedenen Zeiten losgelaufen sein. Seine Rate kann mit den Energiezuständen des Prozessors schwanken, und auf älteren Teilen hält er ganz an, wenn der Kern ruht. Eine vCPU, die zwischen physischen Kernen wandert, kann daher einen Zähler lesen, der dem widerspricht, den sie eine Mikrosekunde vorher gelesen hat.\nDie Alternativen sind auf andere Weise schlechter. Der HPET, der PIT und der ACPI-PM-Timer sind alle emulierte Geräte, jedes Lesen fällt also in den Hypervisor. Korrekt, und teuer genug, dass ein Gast, der die Uhr in einer engen Schleife liest, es merkt.\nDeshalb gibt es paravirtuelle Uhren. Auf KVM lässt kvm-clock den Host seine eigene Zeitmessung in eine gemeinsame Struktur schreiben, die der Gast direkt liest: kein Hineinfallen, kein Zählen, keine Annahme, dass der Gast wach war. Und deshalb solltest du die Clocksource des Gasts in Ruhe lassen, statt tsc oder hpet zu erzwingen, weil ein Forumsbeitrag sagte, das sei schneller.\nMigration, Snapshots und Suspend Live-Migration, Wiederherstellung eines Snapshots und Suspend/Resume machen mit der Uhr eines Gasts alle dasselbe: sie halten sie an und starten sie woanders wieder.\nWas der Gast sieht, ist kein Weglaufen, es ist eine Stufe. Die Uhr hatte einen Wert, und jetzt hat sie einen anderen, mit nichts dazwischen. Auf einen Host zu migrieren, dessen TSC mit anderer Frequenz läuft, kommt obendrauf.\nStufen sind wichtig, weil die Software, die Uhren korrigiert, dafür gebaut ist, Weglaufen zu korrigieren, nicht Teleportation.\nDas ist kein KVM-Problem Es ist verlockend, all das als Schwäche von KVM zu lesen. Ist es nicht.\nJeder Hypervisor liefert eine paravirtuelle Uhr, weil jeder Hypervisor dasselbe strukturelle Problem hat: KVM hat kvm-clock, Hyper-V hat seine Reference-TSC-Seite, VMware hat einen Pseudo-Leistungszähler plus Abgleich über die Tools, Xen hat seine pvclock. Das sind vier unabhängige Umsetzungen eines Behelfs.\nDer eigene Schluss der Kernel-Dokumentation ist, dass es hier keine perfekte Lösung gibt. Nur Abwägungen zwischen Genauigkeit, Leistung und Komplexität.\nWenn du es lieber von einem Anbieter als von Kernel-Entwicklern hörst: Microsofts Grenze der Unterstützung für hochgenaue Zeit ist bemerkenswert offen. Um auf einem virtualisierten Windows-System 50 ms Genauigkeit zu behaupten, lautet eine der genannten Bedingungen, dass „the one-day average CPU utilization of the host must not exceed 90%“ — die über einen Tag gemittelte CPU-Auslastung des Hosts darf 90 % nicht übersteigen. Für 1 ms muss der Host unter 80 % bleiben.\nLies das noch einmal: die Genauigkeit der Uhr des Gasts ist dokumentiert als abhängig davon, wie beschäftigt der Host ist. Das ist keine Windows-Eigenart, es ist dieselbe Physik, die die Kernel-Dokumentation beschreibt, niedergeschrieben als Grenze der Unterstützung.\nDie drei Schichten der Zeitmessung im Gast, und welche der Gast wirklich besitzt Abgleich der Wanduhr wie viel Uhr es wirklich ist NTP über das Netz Zittern, Asymmetrie, Stratum ptp_kvm hypercall fragt den Host direkt Paravirtuelle Uhr der Host veröffentlicht seine eigene Zeitmessung Jeder Hypervisor bringt eine mit, weil sie alle dieses Problem haben: kvm-clock Hyper-V-TSC-Seite VMware pseudo-perf Xen pvclock vier unabhängige Umsetzungen eines Behelfs Hardware-Zähler in einer VM nicht deine TSC HPET PIT ACPI-PM-Timer CPU-lokal und mit schwankender Rate, oder emuliert — jedes Lesen fällt also in den Hypervisor Der Gast besitzt oben seine Wahl. Die Mitte ist der Hypervisor, der ihm eine Uhr leiht, die die ganze Zeit lief. Drei Schichten, und der Gast besitzt wirklich nur die obere. Die paravirtuelle Uhr jedes Hypervisors gibt es, um dieselbe fehlende Zusage in der Schicht darunter zu umgehen. Warum NTP im Gast das falsche Werkzeug ist NTP ist gut in dem, wofür es entworfen wurde: eine Maschine mit einem echten Schwinger, der etwas zu schnell oder zu langsam läuft, korrigiert dadurch, dass die Umlaufzeit zu einem entfernten Server gemessen und die lokale Uhr sanft nachgezogen wird.\nJede dieser Annahmen wackelt in einer VM.\nDer lokale Schwinger ist nicht etwas falsch, er ist zeitweise abwesend. Die Messung der Umlaufzeit macht ein Prozess, der zwischen dem Lesen der Uhr und dem Senden des Pakets vom Scheduler weggenommen werden kann, was die Messung selbst verdirbt. Und die Korrekturen, die nach einer Migration nötig sind, sind Stufen, mit denen ein nachziehendes Verfahren schlecht zurechtkommt oder die es ganz ablehnt.\nchrony kommt hier weit besser zurecht als ntpd. Es zieht schneller nach, verträgt Stufen und ist ehrlich über seine eigene Unsicherheit. Aber es löst noch immer das falsche Problem: Zeit über ein Netz von einem Stratum-2-Server 20 ms weit zu holen, während die richtige Zeit im Hypervisor auf der anderen Seite einer einzigen Speichergrenze liegt.\nWas du in der Praxis bekommst, ist ein Gast, der meistens richtig liegt, gelegentlich Dutzende oder Hunderte Millisekunden daneben, und nie richtig sagen kann, welches von beidem gerade gilt.\nWas Versatz tatsächlich kaputt macht Niemand kümmert sich um Uhren um ihrer selbst willen. Man kümmert sich, wenn etwas aufhört zu funktionieren.\nKerberos und Active Directory Kerberos ist von Entwurf her zeitabhängig, weil die Gültigkeit eines Tickets als Zeitfenster ausgedrückt ist.\nDie Dokumentation zu krb5.conf von MIT bestimmt clockskew als „the maximum allowable amount of clockskew in seconds that the library will tolerate before assuming that a Kerberos message is invalid“ — den größten zulässigen Uhrenversatz in Sekunden, den die Bibliothek verträgt, bevor sie eine Kerberos-Nachricht für ungültig hält —, und die Voreinstellung sind 300 Sekunden, also fünf Minuten.\nÜberschreite das, und die Anmeldung wird nicht schlechter, sie scheitert. Da die Anmeldung an Active Directory Kerberos ist, heißt das Domänenanmeldungen, net use, Verbindungen zum SQL Server, Exchange, Dateifreigaben — alles. Fünf Minuten klingen großzügig, bis ein Gast nach der Wiederherstellung eines Snapshots rückwärts springt.\nTLS Ein Zertifikat trägt ein Gültigkeitsfenster: notBefore und notAfter. Ein Gast, dessen Uhr nachläuft, weist ein Zertifikat ab, das heute Morgen ausgestellt wurde, weil es nach seinem Kenntnisstand noch nicht gültig ist. Ein Gast, dessen Uhr vorläuft, weist eines ab, das noch nicht wirklich abgelaufen ist.\nDieselbe Rechnung regiert die Frische von OCSP und CRL, die Ansprüche nbf und exp in einem JWT und TOTP-Codes für die Mehrfaktoranmeldung, die in Fenstern von 30 Sekunden leben. Eine Uhr, die 45 Sekunden daneben liegt, ist ein Anmeldeausfall mit einer sehr verwirrenden Fehlermeldung.\nCeph Ceph-Monitore kümmern sich darum mehr als fast alles andere im Stapel, weil ihr Konsens davon abhängt.\nDie Gesundheitsprüfung MON_CLOCK_SKEW schlägt an, wenn „the clocks on hosts running Ceph Monitor daemons are not well-synchronized“ — die Uhren auf Hosts mit Ceph-Monitor-Diensten nicht gut abgeglichen sind. Genauer: wenn der Versatz mon_clock_drift_allowed übersteigt. Der Rat der Dokumentation ist, mit ntpd oder chrony gegen mehrere Quellen abzugleichen, und sie hält fest, dass besonders der Abgleich der Monitore untereinander zählt.\nDu kannst mon_clock_drift_allowed hochsetzen, aber die Dokumentation ist klar, dass es „significantly below the mon_lease interval“ bleiben muss, also deutlich unter dem mon_lease-Intervall. Damit ist es ein kleines Budget, und es dafür auszugeben, ein Zeitproblem des Hypervisors zu übertapezieren, ist kein guter Handel.\nAlles Übrige Protokolle über Hosts hinweg passen nicht mehr zusammen, was aus der Zeitachse eines Vorfalls Rätselraten macht. Datenbank-Replikation und verteilter Konsens — etcd, Galera, alles mit Leader-Leases — werden unglücklich. Fenster für Sicherungen und Überwachung laufen aus dem Takt mit dem, was sie beobachten sollten.\nWindows-Gäste laufen anders aus dem Takt Windows verdient eine eigene Anmerkung, weil sein Zeitdienst mit anderen Zielen gebaut wurde, und das merkt man.\nMicrosoft sagt klar, dass Versionen vor Windows 10 1607 / Server 2016 „can\u0026rsquo;t guarantee highly accurate time“ — hochgenaue Zeit nicht zusichern können. Was der Windows-Zeitdienst in diesen Ausgaben lieferte, war „the necessary time accuracy to satisfy Kerberos version 5 authentication requirements“ — die Genauigkeit, die Kerberos Version 5 zum Anmelden braucht — und „loosely accurate time“, also lose genaue Zeit, für Maschinen in einem gemeinsamen AD-Forest. Enger als das war „outside of the design specification… and weren\u0026rsquo;t supported“ — außerhalb der Entwurfsvorgaben und nicht unterstützt.\nMit anderen Worten: älteres Windows zielt darauf, im Fünf-Minuten-Fenster von Kerberos zu bleiben, nicht darauf, richtig zu liegen. Was in Ordnung ist, bis etwas in deinem Bestand es besser braucht. Eine virtualisierte Windows-Kiste, die 90 Sekunden daneben liegt, meldet sich fröhlich an und schreibt dabei Protokolle, die zu nichts passen.\nWindows 10 und Server 2016 und neuer können 1 s, 50 ms oder sogar 1 ms — aber nur unter den oben zitierten Bedingungen, samt der Grenzen für die CPU-Auslastung des Hosts. Microsoft hält außerdem fest, dass „anything that introduces network asymmetry, such as a one-way satellite connection or high CPU load on the target system, will negatively influence accuracy“ — alles, was Asymmetrie ins Netz bringt, etwa eine einseitige Satellitenverbindung oder hohe CPU-Last auf dem Zielsystem, verschlechtert die Genauigkeit. Eine umkämpfte vCPU ist hohe CPU-Last auf dem Zielsystem unter anderem Namen.\nFür Windows gibt es kein ptp_kvm. Was du stattdessen hast:\nHyper-V-Uhren-Enlightenments. Proxmox zeigt die Windows-Gästen schon. PVE::QemuServer::CPUConfig setzt hv_time neben hv_vapic, hv_spinlocks, hv_relaxed und hv_synic. hv_time ist die paravirtuelle Uhr und das Windows-seitige Gegenstück zu kvm-clock. Das ist für VMs vom Typ Windows standardmäßig an; es gibt nichts einzuschalten. Der QEMU-Gast-Agent. Mit installiertem Agenten kann der Host seine Zeit nach einem Resume oder der Wiederherstellung eines Snapshots in den Gast schieben, und das deckt genau den Stufenfall ab, mit dem NTP am schlechtesten zurechtkommt. Wähle eine Autorität. Der klassische Fehlerfall von Windows in einer VM sind zwei Zeitquellen, die sich streiten: Abgleich vom Host in den Gast und Abgleich über die Domänenhierarchie, die beide dieselbe Uhr in verschiedene Richtungen korrigieren. Lass bei einem Gast in der Domäne die Domänenhierarchie gewinnen und hör auf, dem Host Zeit hineinschieben zu lassen. Bei einem eigenständigen Gast ist Abgleich vom Host in Ordnung. Nie beides. Willst du genau wissen, was dein Hypervisor einer bestimmten VM über die Zeit erzählt, frag ihn, statt zu raten:\n# Everything Proxmox actually passes to QEMU for this VM, including -rtc and CPU flags qm showcmd \u0026lt;vmid\u0026gt; --pretty Die Lösung auf QEMU/KVM: ptp_kvm Für Linux-Gäste auf KVM gibt es eine richtige Antwort, und sie lautet nicht „mehr NTP-Server“.\nptp_kvm lässt den Gast den Host direkt über einen Hypercall nach der Zeit fragen — KVM_HC_CLOCK_PAIRING auf x86 und ein entsprechender Firmware-Aufruf auf arm64. Der Kernel zeigt das als PTP-Hardware-Uhr, aus dem Userspace sieht es also aus wie jede andere Präzisionsuhr, und chrony kann sie als Referenzuhr nutzen.\nDie Eigenschaften, auf die es ankommt:\nKein Netz. Kein Zittern, keine Asymmetrie, kein Stratum, keine Pakete. Der Weg ist eine Speichergrenze. Unter einer Mikrosekunde. Die Genauigkeit wird vom Hypercall begrenzt, nicht von einem Umlauf durch ein Rechenzentrum. Es umgeht den kaputten Teil. Der Gast zählt nichts und schätzt keinen Umlauf. Er liest einen Wert, den der Host mit einer Uhr berechnet hat, die die ganze Zeit lief. NTP über das Netz gegen ptp_kvm über eine Speichergrenze chrony gegen Netz-Pools Gast Uhr hält dauernd an Netz Zittern, Asymmetrie Stratum-2-Server Dutzende ms weit den Umlauf misst die Uhr, die korrigiert wird — und dem messenden Prozess kann mitten in der Messung der Kern weggenommen werden chrony gegen ptp_kvm Gast liest /dev/ptp_kvm Host-Uhr hat nie angehalten Hypercall KVM_HC_CLOCK_PAIRING eine Speichergrenze, kein Netz unter 1 µs Keine Pakete, kein Stratum, keine Asymmetrie, und nichts wird geschätzt. Der Gast rechnet nicht aus, wie viel Uhr es ist — es wird ihm gesagt, vom einzigen Beteiligten, der die ganze Zeit wach war. Beide Wege enden damit, dass der Gast seine Uhr stellt. Einer davon misst einen Netzumlauf mit einer Uhr, die dauernd anhält; der andere fragt den Hypervisor. Umsetzung Wende das auf jede Linux-VM an, die den Treiber hat. Der Host-Hypervisor braucht sein eigenes funktionierendes NTP oder PTP. ptp_kvm gibt dem Gast die Zeit des Hosts, er erbt also den Fehler des Hosts.\n1. Das Kernel-Modul beim Start laden.\n# /etc/modules-load.d/ptp_kvm.conf ptp_kvm 2. Ihm einen stabilen Namen geben und chrony lesen lassen.\n# /etc/udev/rules.d/90-ptp-kvm.rules ACTION==\u0026#34;add\u0026#34;, SUBSYSTEM==\u0026#34;ptp\u0026#34;, ATTR{clock_name}==\u0026#34;kvm\u0026#34;, SYMLINK+=\u0026#34;ptp_kvm\u0026#34;, GROUP=\u0026#34;chrony\u0026#34;, MODE=\u0026#34;0660\u0026#34; Der Symlink zählt, weil die Numerierung der PTP-Geräte nicht stabil ist. /dev/ptp0 kann bei einem Start die Uhr einer NIC sein und beim nächsten die KVM-Uhr. Über clock_name zu greifen holt jedes Mal die richtige.\n3. chrony darauf zeigen lassen, und die Pools entfernen.\nBearbeite /etc/chrony/chrony.conf auf Debian und Ubuntu oder /etc/chrony.conf in der RHEL-Familie. Lösche die pool-Zeilen und nutze:\nrefclock PHC /dev/ptp_kvm poll 2 stratum 1 delay 0.0004 Die Pools zu entfernen ist keine optionale Ordnungsliebe. Sie stehen zu lassen heißt, chrony zu bitten, eine lokale Referenz unter einer Mikrosekunde mit Internet-Servern Dutzende Millisekunden weit in Einklang zu bringen, und die Internetquellen können die Antwort nur verschlechtern.\n4. Neu starten und prüfen.\nsystemctl restart chronyd # or chrony, on Debian/Ubuntu Prüfen # The symlink exists and points at the KVM clock ls -l /dev/ptp_kvm cat /sys/class/ptp/ptp*/clock_name # chrony should be using PHC0 as its selected source chronyc sources -v # and the offset should be microseconds, not milliseconds chronyc tracking In chronyc sources erscheint die PHC-Referenzuhr als #* PHC0, sobald sie gewählt ist. Das # markiert eine lokale Hardware-Referenz statt eines Netz-Partners, und das * markiert sie als die genutzte. Siehst du sie aufgeführt, aber nicht gewählt, hat chrony sie nicht angenommen: prüf die Rechte am Gerät und dass die Gruppe chrony in der udev-Regel zu dem Nutzer passt, unter dem chrony auf deiner Distribution tatsächlich läuft.\nVorbehalte Der Host muss richtig liegen. Das bringt den Gast dazu, mit dem Host übereinzustimmen, was nur nützt, wenn der Host mit der Wirklichkeit übereinstimmt. Gib den Hypervisoren echtes NTP oder PTP. Jeder Gast braucht es. Ein Bestand, in dem die Hälfte der VMs ptp_kvm nutzt und die andere Hälfte Internet-Pools, ist ein Bestand mit zwei Zeitautoritäten. Live-Migration ist in Ordnung, und das ist der Punkt. Nach der Migration liest der Gast die Uhr seines neuen Hosts. Solange die Hosts miteinander übereinstimmen, sieht der Gast nie eine Stufe. Nur KVM. Es ist ein KVM-Hypercall. Geschachtelte oder fremde Hypervisoren zeigen das Gerät nicht, und die udev-Regel greift einfach nicht. Das ist ein sauberes Scheitern statt einer stillen falschen Antwort. Was man nicht tun sollte Erzwing die Clocksource nicht. Lass kvm-clock in Ruhe. tsc oder hpet auf der Kernel-Kommandozeile des Gasts zu erzwingen tauscht eine paravirtuelle Uhr, die für genau diese Lage entworfen wurde, gegen einen Zähler, der dir nie gehörte. Lass ntpdate oder hwclock nicht aus cron laufen. Das ist eine Stufe nach Zeitplan, und genau das hassen Datenbanken und Kerberos. Behalte die Pools nicht „als Rückfall“. Mit einer funktionierenden Referenzuhr sind sie kein Rückfall, sie sind eine zweite Meinung aus schlechterer Quelle. Setz nicht mon_clock_drift_allowed hoch und nenn es behoben. Du hast dann einen Teil eines Budgets ausgegeben, das für die Wirklichkeit im Netz da ist, um ein Problem zu vertragen, für das es eine bekannte Lösung gibt. Der letzte Punkt ist es wert, klar gesagt zu werden: die Schwelle zu weiten ist nicht, die Uhr zu richten. Es ist, den Alarm zu verschieben, damit er aufhört zu gehen.\nQuellen Linux-Kernel — KVM timekeeping — warum Gast-Zeit zurückfällt, das Problem des TSC als lokale Uhr und der Schluss, dass es nur Abwägungen gibt Linux-Kernel — PTP_KVM — die Hypercall-Schnittstelle hinter dem PTP-Uhren-Gerät Linux-Kernel — KVM x86 hypercalls — KVM_HC_CLOCK_PAIRING, die x86-Seite davon chrony — chrony.conf — die refclock-Direktive und die Optionen des PHC-Treibers MIT Kerberos — krb5.conf — clockskew und die Voreinstellung von 300 Sekunden Microsoft — support boundary for high accuracy time — die Genauigkeitsziele und die Bedingungen zur CPU-Auslastung des Hosts für virtualisierte Systeme Ceph — health checks — MON_CLOCK_SKEW, mon_clock_drift_allowed und der Zusammenhang mit mon_lease ","permalink":"https://blogs.damiendye.uk/de/proxmox/vm-time-ptp-kvm/","summary":"Die Uhr einer virtuellen Maschine steht auf einer Annahme, die Virtualisierung zerbricht: dass die CPU weiterzählt. Warum Gast-Zeit auf jedem Hypervisor wegläuft, was der Versatz tatsächlich kaputt macht — Kerberos, TLS, Ceph, Windows — und wie ptp_kvm es auf QEMU/KVM richtig löst.","title":"Der Uhr einer VM ist nicht zu trauen — und die ptp_kvm-Lösung für QEMU/KVM"},{"content":"Drei Weisen, wie sich ein Laufwerk darstellen kann Ein Laufwerk hat zwei Blockgrößen, und der Unterschied zwischen ihnen ist die ganze Geschichte.\nDer physische Sektor ist das, womit das Medium tatsächlich arbeitet — die kleinste Einheit, die das Laufwerk ohne Zusatzarbeit lesen oder schreiben kann. Der logische Block ist das, womit das Laufwerk dem Host sagt, dass es arbeitet — die Einheit, die der Host adressiert.\nEs gibt drei Kombinationen in der Welt.\n512n — natives 512. Beide Größen sind 512 Byte. Das ist die alte Welt: Festplatten von vor 2010, und nichts, was du heute neu in einer erwähnenswerten Größe kaufen würdest.\n512e — Emulation von 512 Byte. Der physische Sektor ist 4096 Byte, aber das Laufwerk meldet logische Blöcke von 512 Byte und übersetzt in der Firmware. Das gibt es aus einem Grund: Kompatibilität mit Betriebssystemen, Bootloadern und Anwendungen, die für immer 512 angenommen haben. Als Technik vernünftig genug, und die Wurzel so gut wie allen Ärgers, der folgt.\n4Kn — natives 4K. Beide Größen sind 4096 Byte. Das Laufwerk sagt die Wahrheit, der Host adressiert es in der Einheit, die das Medium nutzt, und es sitzt keine Übersetzungsschicht dazwischen.\n512n, 512e und 4Kn: was der Host adressiert gegen das, womit das Medium arbeitet obere Reihe = logisch, was der Host adressiert · untere Reihe = physisch, womit das Medium arbeitet 512n 512512 512512 512512 512512 1:1, und ehrlich — aber überholt. Nichts Neues kommt mehr so. 512e 8 × 512 B logisch — was dem Host gesagt wird ein physischer Sektor von 4096 B — was wirklich da ist die Firmware übersetzt, bei jedem Zugriff Der Host adressiert etwas, das nicht da ist. Schreibvorgänge, die keinen Sektor füllen, kosten extra. 4Kn ein logischer Block von 4096 B ein physischer Sektor von 4096 B nichts zu übersetzen Das Laufwerk sagt die Wahrheit, nichts danach kann also mit einer falschen Zahl entscheiden. 512e ist der interessante Fall: der Host adressiert etwas, das nicht existiert, und die Firmware hält die Fiktion bei jedem Zugriff aufrecht. Was 512e bei jedem fehlausgerichteten Schreibvorgang tut Lesen ist in allen drei Fällen billig. Das Laufwerk liest den 4-K-Sektor und gibt die 512-Byte-Scheibe zurück, die du wolltest.\nSchreiben ist die Stelle, an der die Fiktion teuer wird.\nSchreibt der Host einen einzelnen logischen Block von 512 Byte, kann das Laufwerk keine 512 Byte schreiben. Das Medium hat keine solche Einheit. Also tut es stattdessen dies:\nDen ganzen physischen Sektor von 4096 Byte lesen. Die 512 Byte neue Daten einmischen. Den ganzen Sektor von 4096 Byte zurückschreiben. Das ist ein Read-Modify-Write, und es macht aus einem kleinen Schreibvorgang ein Lesen plus ein Schreiben. Auf einer sich drehenden Platte heißt das warten, bis der Teller wieder herumkommt. Eine volle Umdrehung bei 7.200 min⁻¹ sind etwa 8 ms, mit denen du nicht gerechnet hast. Auf Flash sind die Kosten anderer Art, und sie verschwinden nicht, wenn der Schreibvorgang fertig ist. Das hat weiter unten seinen eigenen Abschnitt.\nDer Read-Modify-Write-Aufschlag, und was Fehlausrichtung daraus macht 4Kn — ausgerichteter 4-KB-Schreibvorgang 4 KB neue Daten füllen den Sektor 1 Schreibvorgang nichts vorher zu lesen 512e — einen logischen Block von 512 B schreiben 1. den ganzen physischen Sektor lesen 4096 B gelesen 2. die 512 B einmischen nur so viel hat sich wirklich geändert 3. den ganzen Sektor zurückschreiben 4096 B geschrieben 1 Lesen + 1 Schreiben eine Umdrehung auf einer Platte; eine programmierte Seite auf Flash 512e — fehlausgerichteter 4-KB-Schreibvorgang (der teure) ein 4-KB-Schreibvorgang, um einen halben Sektor verschoben physischer Sektor n physischer Sektor n+1 2 Read-Modify-Writes bei jedem Schreibvorgang, für immer Moderne Partitionierungswerkzeuge richten standardmäßig am physischen Sektor aus, das ist also meist aus einer alten Installation oder einem Abbild geerbt und nicht frisch angelegt. Es behebt sich nicht selbst. Ein an 4 K ausgerichteter Schreibvorgang über 4 K braucht überhaupt kein Lesen. Alles andere schon — und ein Schreibvorgang, der über eine Sektorgrenze liegt, braucht zwei. Fehlausrichtung ist die Fassung davon, die am härtesten beißt. Beginnt eine Partition an einem ungeraden 512-Byte-Versatz — der Klassiker ist die alte Konvention mit 63 Sektoren —, dann liegt jeder 4-K-Schreibvorgang des Dateisystems über zwei physischen Sektoren. Das ist nicht ein Read-Modify-Write, sondern zwei, bei jedem einzelnen Schreibvorgang, für immer, bis jemand das Laufwerk neu partitioniert.\nSchreibverstärkung auf Flash Auf einer Festplatte kostet dich der Read-Modify-Write eine Umdrehung, und dann ist es vorbei. Auf Flash kostet er dich Lebensdauer, und das ist eine Rechnung, die du einmal bezahlst und weiter bezahlst.\nSchreibverstärkung ist das Verhältnis von dem, was wirklich in das NAND geschrieben wurde, zu dem, was der Host schreiben wollte. Ein Verhältnis von 1,0 hieße, das Laufwerk hat genau geschrieben, was es bekommen hat. Es ist nie 1,0, denn Flash kann nicht an derselben Stelle überschreiben: das Laufwerk programmiert eine frische Seite, markiert die alte als veraltet, und die Speicherbereinigung lagert später die überlebenden Seiten um, damit ein ganzer Block gelöscht werden kann. Diese Umlagerungen sind auch Schreibvorgänge.\n512e legt darauf eine vermeidbare Schicht, und der Grund ist eine Einzelheit, die klar gesagt werden sollte: die Übersetzungsschicht des Laufwerks bildet in Einheiten von rund 4 KB ab, egal welche logische Blockgröße es angibt. Ein Laufwerk, das Blöcke von 512 Byte meldet, führt innen weiter Einheiten von 4 KB.\nEin Schreibvorgang von 512 Byte vom Host wird also im Laufwerk: die 4-KB-Abbildungseinheit lesen, die 512 Byte einmischen, eine neue 4-KB-Einheit programmieren. 4096 Byte erreichen das NAND, damit 512 Byte sich ändern konnten. Achtmal der Schreibvorgang, für diesen Schreibvorgang.\nFehlausrichtung ist pro Schreibvorgang weniger dramatisch und in der Summe schlimmer. Ein 4-KB-Schreibvorgang, der über zwei Abbildungseinheiten liegt, schmutzt beide, es werden also 8 KB für 4 KB Daten programmiert. Das sind 2× Verstärkung bei jedem einzelnen Schreibvorgang, dauerhaft, bis die Partitionstabelle stimmt.\nWarum ein fehlausgerichteter Schreibvorgang verdoppelt, was das NAND erreicht von oben nach unten: was der Host schrieb → die 4-KB-Abbildungseinheiten des Laufwerks → was das NAND erreichte 512e — 4-KB-Schreibvorgang, fehlausgerichtet 4 KB vom Host Einheit n Einheit n+1 4 KB neu geschrieben 4 KB neu geschrieben 8 KB geschrieben für 4 KB — WAF 2× bei jedem Schreibvorgang, bis die Partitionstabelle stimmt 4Kn — 4-KB-Schreibvorgang, ausgerichtet 4 KB vom Host Einheit n 4 KB geschrieben 4 KB für 4 KB — WAF ≈ 1× der Boden, vor der Speicherbereinigung Keine Seite entkommt der Speicherbereinigung: das Laufwerk muss weiter umlagern, was in einem Block noch lebt, bevor es ihn löschen kann, und diese Arbeit wächst mit dem, was geschrieben wurde. 4Kn schafft die Verstärkung nicht ab — es nimmt den Teil weg, den du für nichts bezahlt hast. Der Host hat in beiden Fällen dieselben 4 KB verlangt. Links landen sie über zwei Abbildungseinheiten, beide werden also neu geschrieben — und die Speicherbereinigung wird später bewegen, was darin noch lebt. Die Folgewirkungen sind es, die das wichtig machen, statt bloß unordentlich zu sein:\nMehr NAND-Schreibvorgänge heißen, dass die Speicherbereinigung öfter läuft, und ihre Umlagerungen sind selbst Verstärkung. Ein SLC-Schreibcache füllt sich früher, das Laufwerk fällt also früher in seinen langsameren Dauerzustand, und der Durchsatz beim Dauerschreiben sinkt. Programmier-/Löschzyklen werden im Verhältnis zu dem verbraucht, was das NAND erreichte, nicht zu dem, was der Host schickte. Verdopple die Verstärkung, und du hast die Lebensdauer des Laufwerks für dieselbe Arbeit halbiert. Angaben zur Haltbarkeit — TBW, DWPD — sind gegen die Schreibvorgänge des Hosts angegeben. Verstärkung frisst diesen Spielraum still auf, und das Laufwerk nutzt sich vor der Garantierechnung ab, die du beim Kauf gemacht hast. Direkte und synchrone Schreibvorgänge sind der schlimmste Fall Die meiste Zeit verbirgt der Page-Cache all das. Der Kernel sammelt kleine Schreibvorgänge, führt sie zusammen und schickt IO von 4 KB oder mehr an das Laufwerk, der Read-Modify-Write passiert also nie.\nZwei Flags nehmen diesen Schutz weg, und Anwendungen, denen Dauerhaftigkeit wichtig ist, setzen beide.\nO_DIRECT umgeht den Page-Cache. Es steht nun nichts mehr zwischen der Anwendung und dem Laufwerk, das einen 512-Byte-Schreibvorgang zu etwas Sektorgroßem zusammenführen könnte.\nO_SYNC oder O_DSYNC verlangt, dass der Schreibvorgang auf beständigem Medium liegt, bevor der Aufruf zurückkommt. Das hindert das Laufwerk daran, den Schreibvorgang in einen flüchtigen Puffer aufzunehmen und ihn später mit seinen Nachbarn zusammenzuführen.\nNimm beides zusammen, und jeder 512-Byte-Schreibvorgang ist ein vollständiger Read-Modify-Write-Durchlauf, der jetzt fertig werden muss, für sich, ohne etwas, worauf er sich verteilen ließe. Dort nähert sich die Verstärkung auf einem 512e-Laufwerk ihren theoretischen 8×, und es ist genau das Muster, das ein Commit-Log einer Datenbank, ein ZFS-ZIL oder ein Ceph-BlueStore-WAL erzeugt.\nSchutz bei Stromverlust ist das, was das auf Hardware für Unternehmen rettet. Ein Laufwerk mit PLP kann einen synchronen Schreibvorgang bestätigen, sobald er in einem kondensatorgestützten DRAM-Puffer liegt, was beständig ist, und intern trotzdem zusammenführen, bevor es NAND programmiert. Ein Consumer-Laufwerk ohne PLP muss den Flash erreichen, bevor es antworten darf, und zahlt also die vollen Kosten pro Schreibvorgang. Ein weiterer Grund, warum PLP für diese Art Arbeit nicht optional ist.\nIn Proxmox entscheidet der Cache-Modus, welches davon du bekommst:\ncache=none ist O_DIRECT — die Voreinstellung von PVE und die richtige Wahl für HA komplett auf Flash. Der Page-Cache des Hosts ist aus dem Weg, die Schreibmuster des Gasts erreichen das Laufwerk also so, wie der Gast sie abgeschickt hat. cache=directsync ist O_DIRECT plus O_DSYNC — jeder Schreibvorgang synchron. Es ist eine Nischeneinstellung für Laufwerke, die nur ein Datenbank-Log tragen, und für allgemeine Arbeit unbrauchbar. Auf einem 512e-Gerät als Unterlage ist cache=directsync mit einem Gast, der in Datensätzen von 512 Byte committet, ungefähr die ineffizienteste Anordnung, die zu haben ist: kein Zusammenführen im Host, kein Zusammenführen im Laufwerk, und ein Read-Modify-Write pro Commit.\nUnd hier ist der Teil, der 4Kn strukturell macht statt bloß vorzuziehen. O_DIRECT verlangt, dass Versatz, Länge und Puffer an der logischen Blockgröße des Laufwerks ausgerichtet sind. Auf einem 512e-Laufwerk sind das 512 Byte, ein direkter Schreibvorgang von 512 Byte ist also erlaubt, und das Laufwerk bezahlt still dafür. Auf 4Kn ist der logische Block 4096, der kleinste direkte Schreibvorgang, den der Kernel annimmt, ist also 4 KB. Das krankhafte Muster hört auf, etwas zu sein, das du vermeiden musst, und wird etwas, das der Stapel nicht ausdrücken kann.\nOverhead auf dem Medium Die zweiten Kosten sind strukturell, und sie sind der Grund, warum Advanced Format überhaupt existiert.\nEin Sektor ist nicht bloß seine Daten. Auf einer Festplatte trägt jeder eine Synchronisationsmarke, damit der Kopf weiß, wo der Sektor beginnt, eine Lücke, damit aufeinanderfolgende Sektoren nicht ineinanderlaufen, eine Adressmarke und ein ECC-Feld, um Lesefehler zu korrigieren.\nMit Sektoren von 512 Byte zahlst du all das achtmal für jede 4 K Daten. Mit einem 4-K-Sektor zahlst du es einmal.\nDas hat zwei Folgen, und die zweite zählt mehr als die erste:\nEin Teil des Tellers, der Overhead war, wird nutzbare Kapazität. Das war die erklärte Absicht der Branche beim Übergang zu Advanced Format, im niedrigen einstelligen Prozentbereich. Das ECC-Feld kann bei gleichem Gesamt-Overhead viel größer sein. Ein starker Code, der 4096 Byte schützt, korrigiert weit mehr als acht schwache Codes, die je 512 Byte schützen. Als die Flächendichte stieg, hörte das auf, eine Annehmlichkeit zu sein, und wurde der einzige Weg, die Fehlerraten erträglich zu halten. Der Overhead pro Sektor fällt bei 512 Byte achtmal an und bei 4 K einmal Sektoren von 512 Byte — dieselben 4 KB Daten 8 Sektoren × (Sync + Daten + ECC + Lücke) 8 × der Overhead pro Sektor, und acht kleine ECC-Felder Ein Sektor von 4096 Byte — dieselben Daten 1 × der Overhead, und ein viel größeres ECC-Feld Sync-Marke, Adressmarke, Lücke ECC deine Daten Nicht maßstäblich — die Overhead-Felder sind übertrieben, damit sie überhaupt zu sehen sind. Die zurückgewonnene Kapazität war ein niedriger einstelliger Prozentwert wert. Das stärkere ECC ist der Grund, warum die Branche wirklich umgestiegen ist. Acht Sätze Synchronisationsmarken, Lücken und ECC, oder einer. Der zurückgewonnene Platz ist der kleine Gewinn; das stärkere ECC ist der Grund, warum die Branche umgestiegen ist. Flash hat keine Synchronisationsmarken und keine Lücken aus der Drehung, aber dieselbe Logik gilt eine Ebene höher: NAND wird in Seiten programmiert, Seiten sind weit größer als 512 Byte, und die Abbildungstabellen des Laufwerks haben einen Eintrag pro adressierbarer Einheit. Kleinere logische Blöcke heißen mehr Metadaten, um dieselbe Kapazität zu führen.\nOverhead im Host: Befehle und Interrupts Die dritten Kosten sind die, die Leute übersehen, denn sie fallen überhaupt nicht auf dem Laufwerk an.\nDie logische Blockgröße setzt den Boden dafür, wie klein ein IO sein kann. Auf einem Laufwerk mit logischen 512 Byte darf ein Dateisystem oder eine Anwendung 512 Byte schreiben, und jeder davon ist ein vollständiges IO: ein Befehl gebaut und eingereicht, ein Schreibvorgang auf die Türklingel, ein Eintrag in der Completion Queue und ein Interrupt, der sagt, dass es fertig ist.\nJedes davon hat feste Kosten, denen es gleich ist, wie viele Daten beteiligt waren. Bewege 4 KB als acht Befehle über 512 Byte, und du zahlst diese Kosten achtmal. Bewege sie als einen 4-K-Befehl, und du zahlst sie einmal.\nDie logische Blockgröße setzt den Boden für die IO-Größe, und jeder Befehl hat feste Kosten Logische Blöcke von 512 B — eine Anwendung darf 512 B schreiben aus 4 KB Daten werden 8 Befehle 512 B512 B 512 B512 B 512 B512 B 512 B512 B 8 × Einreichung + Türklingel 8 × Fertigmeldung 8 × Gelegenheit für Interrupt 8 × die festen Kosten pro Befehl für genau dieselben 4 KB Daten Logische Blöcke von 4 KB — 4 KB ist der Boden ein Befehl über 4 KB 1 × Einreichung, 1 × Fertigmeldung, 1 × Interrupt 1 × die festen Kosten Das hilft nur dort, wo wirklich kleines IO abgeschickt wird: ein Befehl kann viele Blöcke beschreiben, ein 1-MB-Schreibvorgang ist also so oder so ein Befehl. Dieselben 4 KB Daten. Das Laufwerk ist hier nicht der Engpass — es sind die Kosten pro Befehl und pro Fertigmeldung im Host. Zwei ehrliche Einschränkungen, denn hier wird das Argument meist überzogen.\nFür großes IO ändert die logische Blockgröße nichts an der Zahl der Befehle. Ein einzelner Befehl kann viele Blöcke beschreiben, ein sequentieller Schreibvorgang über 1 MB ist also ein Befehl, ob die Blöcke 512 Byte oder 4 K groß sind. Die Einsparung ist nur dort echt, wo kleines IO abgeschickt wird.\nWo kleines IO abgeschickt wird, ist die Wirkung allerdings nicht subtil: jede dieser acht Anforderungen ist eine, die der Kernel bauen, einplanen und abschließen muss, jede mit ihrem eigenen MSI-X-Interrupt und ihrem eigenen Übergang vom Nutzer- in den Kernbereich, und bei hohen Queue-Tiefen kommt so ein Interrupt-Sturm zustande. In einer VM ist es noch schlimmer, denn jeder dieser Interrupts ist außerdem ein Kontextwechsel im Gast.\nUnd moderne NVMe-Controller fassen Interrupts zusammen, die Zahl der Interrupts ist also nicht einfach die Zahl der Befehle. Die Arbeit fürs Einreichen und Abschließen pro Befehl bleibt aber, und bei ein paar hunderttausend IOPS sind die CPU-Kosten pro Befehl ein messbarer Bruchteil eines Kerns. Das ist dieselbe Rechnung wie bei Posted Interrupts in der Passthrough-Reihe — kleine feste Kosten, mit einer sehr großen Zahl multipliziert.\n4Kn, Sektor-Metadaten und Hardware-RAID Auf ein Format von 4096 + 0 zu gehen hat eine Folge, die Leute erwischt, und sie trifft geradewegs Hardware-RAID.\nManche RAID-Controller und Speicher-Arrays nutzen überhaupt keine einfachen Sektoren von 512 oder 4096 Byte. Sie formatieren Laufwerke auf eine erweiterte Größe — 520 oder 528 Byte, oder die 4-K-Gegenstücke wie 4104, 4160 und 4224 —, denn diese zusätzlichen Byte pro Sektor sind der Ort, an dem der Controller seine eigenen Metadaten hält. Das sind Schutzinformationen nach T10-PI/DIF oder Integritätsdaten des Herstellers, direkt bei den Daten gespeichert, die sie beschreiben.\nEin Format von 4096 + 0 hat keinen Platz dafür. Der Sektor ist Daten, von Anfang bis Ende, und das ist genau der Sinn, ihn zu wählen.\nEin Controller, der Metadaten innen drin will, hat also drei Möglichkeiten, und keine ist kostenlos:\nDas Laufwerk abweisen. Es zurück auf ein erweitertes Format formatieren und die 4Kn-Arbeit, die du gerade gemacht hast, zunichte machen. Seine Metadaten woanders auf dem Laufwerk halten. Die dritte ist die, bei der Flash dich bestraft. Metadaten, die getrennt von den Daten geschrieben werden, die sie beschreiben, sind ein zweiter Schreibvorgang, an einem anderen Versatz, in einer anderen Abbildungseinheit. Eine weitere programmierte NAND-Seite für jede, die du wirklich schreiben wolltest. Das ist die Verstärkung aus dem Abschnitt oben, absichtlich wieder eingeführt, um Integritäts-Metadaten zu tragen, die das Laufwerk für nichts innen hätte halten können, wenn du es in einem erweiterten Format gelassen hättest.\nDu kannst nicht beides haben. Entweder trägt der Sektor die Metadaten des Controllers, oder er trägt nur deine Daten.\nWeshalb Flash die Argumente für Hardware-RAID ziemlich untergraben hat Der Rest davon ist Ermessen und kein Mechanismus, nimm es also so.\nEin Hardware-RAID-Controller ist Firmware-RAID auf einem eigenen Prozessor. Die „Hardware“ ist eine CPU, etwas DRAM und eine Batterie. Keine grundlegend andere Art, Parität zu rechnen. Was er dir früher gebracht hat, war ein batteriegestützter Schreibcache und das Auslagern der Paritätsrechnung, und auf Flash sind beide Argumente stark geschwächt. NVMe für Unternehmen hat schon einen eigenen Cache mit Schutz bei Stromverlust, und der Controller wird zur Bandbreitendecke vor Geräten, von denen jedes mehrere Gigabyte pro Sekunde sättigen kann.\nEr kostet dich außerdem Dinge, die du jetzt aktiv willst:\nDer Zustand der Geräte verschwindet. SMART-Einzelheiten, Verschleißanzeigen und die Herstellerprotokolle, mit denen du die Schreibverstärkung ausrechnen kannst, liegen alle hinter einer undurchsichtigen Abstraktion. Keine Prüfsummen von Ende zu Ende. Ein Controller prüft Parität, und das erkennt ein fehlendes Laufwerk, nicht eine falsche Antwort eines vorhandenen. ZFS und Ceph bilden Prüfsummen über die Daten selbst und können dir sagen, welche Kopie falsch ist — stille Verfälschung, die ein Controller direkt durchlässt. Damit löst der Controller das falsche Problem. Hersteller-Metadaten auf den Laufwerken binden das Array an eine Controller-Familie, und das ist seine eigene Art Unzuverlässigkeit, wenn der Controller das ist, was ausfällt. Paritäts-RAID macht seinen eigenen Read-Modify-Write bei Schreibvorgängen über Teilstreifen, obendrauf auf alles in den Abschnitten oben. Für Ceph ist das nicht einmal eine Vorliebe. Proxmox\u0026rsquo; eigene Empfehlung für hyperkonvergente Aufbauten ist, dass Platten im HBA- oder Durchreichmodus zu zeigen sind, nicht hinter einem RAID-Controller, und ZFS will aus denselben Gründen genau dasselbe.\nDie Anordnung, die aus all dem folgt, ist also: ein HBA statt eines RAID-Controllers, Laufwerke auf 4Kn mit null Metadaten formatiert, und Redundanz plus Prüfsummen von ZFS oder Ceph erledigt, die dir wirklich sagen können, wenn ein Laufwerk gelogen hat. Braucht etwas in deinem Bestand wirklich ein erweitertes Sektorformat, ist das ein bewusstes Entweder-oder, das zu klären ist, während die Laufwerke noch leer sind. Nicht etwas, das man entdeckt, nachdem die OSDs gebaut sind.\nWo 512e tatsächlich beißt Es wäre unehrlich zu behaupten, 512e ruiniere ein modernes System, denn meist tut es das nicht.\nEin aktueller Linux-Stapel liest die physische Sektorgröße, richtet Partitionen daran aus — parted und sfdisk tun das inzwischen beide von allein — und nutzt Dateisystemblöcke von 4 K. In dieser Aufstellung schickt der Host an 4 K ausgerichtetes 4-K-IO, das Laufwerk braucht nie einen Read-Modify-Write, und 512e kostet dich nahezu nichts.\nDie Probleme sind bestimmte:\nFehlausgerichtete Partitionen, meist aus einer alten Installation oder einem geklonten Abbild geerbt. Zwei Read-Modify-Writes bei jedem Schreibvorgang. ZFS mit ashift=9 auf einem 512e-Laufwerk, weil ZFS den gemeldeten 512 geglaubt hat. Jeder Datensatz-Schreibvorgang wird zu einem Read-Modify-Write, und du kannst ashift nachträglich nicht ändern — der Pool muss neu gebaut werden. Anwendungen, die Datensätze von 512 Byte schreiben mit O_DIRECT und dabei das Zusammenführen des Page-Cache umgehen. Manche Datenbanken und viel eigene Software tun das. Alles, was der logischen Größe traut, die echte zu sein. Das ist der eigentliche Schaden der Emulation: sie gibt eine Zahl heraus, die falsch ist, und Dinge weiter unten entscheiden damit. 4Kn nimmt die ganze Kategorie weg. Das Laufwerk kann nicht über eine Sektorgröße lügen, die es nicht hat.\nEs lohnt sich aber, über die Größe des Preises geradeheraus zu sein. Seagates eigene Empfehlung ist, dass 4Kn klar der Mühe wert ist, wenn der Stapel vollständig auf 4 K optimiert ist und du jede IOPS zählst — eine getunte Ebene komplett auf Flash etwa. Darunter, auf einem richtig ausgerichteten modernen Linux, ist der Leistungsunterschied bei ausgerichtetem IO oft klein. Das andere Argument ist Gleichmäßigkeit im Bestand: ein durchgehend 4Kn-Bestand hat keine Überraschungen mit gemischten Formaten, und niemand muss sich merken, welche Laufwerke lügen.\nDie meisten Laufwerke lassen sich umstellen — wenn der Hersteller es zulässt Das ist der Teil, der übersehen wird: 512e ist oft eine Formateinstellung und keine Eigenschaft der Hardware. Sehr viele SAS- und SATA-Laufwerke für Unternehmen und die meisten NVMe für Unternehmen kommen mit gemeldeten 512 Byte und lassen sich bereitwillig auf 4Kn umformatieren.\nAlles Folgende vernichtet jedes Byte auf dem Gerät. Es gibt keine Umstellung an ihrem Platz.\nNVMe — nvme-cli Sieh zuerst nach, was der Namespace kann:\n# Lists each LBA format and marks which one is in use nvme id-ns -H /dev/nvme0n1 | grep -i \u0026#34;lbaf\\|data size\u0026#34; Du willst ein Format mit Data Size 4096 und Metadata Size 0, als bestes markiert und derzeit nicht in Gebrauch. Dann wende es an:\n# -l/--lbaf selects the LBA format index from the list above nvme format /dev/nvme0n1 --lbaf=1 --force Die Größe der Metadaten zählt genauso wie die der Daten. Manche Werksformate halten zusätzliche Byte pro Sektor frei — 520 oder 4160 —, um Schutz-Metadaten nach T10-PI/DIF von Ende zu Ende zu tragen. Verbraucht nichts in deinem Stapel das, ist es Füllmaterial auf jedem Sektor, wähle also das Format ohne Metadaten und werde es los. Versehentlich ein Format mit Metadaten zu wählen gibt dir außerdem ein Laufwerk, das sich anders verhält als das, das du erzeugen wolltest, und eine Änderung der Sektorgröße mit einer Änderung an PI zu verbinden kann eine langsame vollständige Formatierung erzwingen statt einer schnellen.\nFür die Laufwerke eines ganzen Hosts nimm eine Schleife. Sie braucht shopt -s extglob für die erweiterten Globs und wählt nur Formate, die 4096/0 sind und nicht in Gebrauch:\nshopt -s extglob for dev in /dev/nvme+([0-9])n+([0-9]); do # Skip anything that is not actually there [ -e \u0026#34;$dev\u0026#34; ] || continue # An LBA format with 4096-byte data, 0-byte metadata, marked Best, not in use lbaf=$(nvme id-ns -H \u0026#34;$dev\u0026#34; \\ | grep -P \u0026#39;(?=.*Metadata Size: 0)(?=.*Data Size: 4096)(?=.*Best)(?!.*in use)\u0026#39; \\ | awk \u0026#39;{found=$3} END {print (found != \u0026#34;\u0026#34; ? found : -1)}\u0026#39;) if [ \u0026#34;$lbaf\u0026#34; != \u0026#34;-1\u0026#34; ]; then echo \u0026#34;Formatting $dev using LBA Format: $lbaf\u0026#34; nvme format --force --lbaf=\u0026#34;$lbaf\u0026#34; \u0026#34;$dev\u0026#34; else echo \u0026#34;Skipping $dev: no matching LBA format found.\u0026#34; fi done Zwei Dinge darin leisten mehr, als sie aussehen.\nDas Glob greift Namespaces — nvme0n1, nvme12n3 — und greift bewusst keine Partitionen wie nvme0n1p1, denn das Muster endet nach den Ziffern hinter dem n. Das ist der Unterschied zwischen einen Namespace neu zu formatieren und mit einem laufenden System etwas Unwiederbringliches zu tun.\nUnd die Auswahl stellt nur ein Laufwerk um, das wirklich anbietet, was du verlangt hast. Alles andere fällt auf -1 durch und wird übersprungen, und das deckt drei getrennte Fälle ab:\nDas Laufwerk bietet nur 512. Es existiert kein Format mit 4096 Byte, es gibt also nichts, worauf umzustellen wäre, und die Schleife lässt es in Ruhe. Sie versucht es nicht, und sie scheitert nicht auf halbem Weg. Das Laufwerk ist schon 4Kn. Das Format 4096/0 ist das in Gebrauch, und (?!.*in use) schließt es aus — ein zweiter Durchlauf über denselben Host tut also nichts. Kein sinnloses Neuformatieren jedes Laufwerks. Die einzigen 4096-Formate tragen Metadaten. Ein Format 4096 + 8 erfüllt Metadata Size: 0 nicht, die Schleife wird dir also nicht still ein T10-PI-Laufwerk geben, das du nicht wolltest. Anders gesagt: sie scheitert geschlossen. Wenn sie unsicher ist, überspringt sie.\nEine Anmerkung zur Portabilität: diese Lookaheads brauchen den PCRE-Modus -P von GNU grep. Auf einem System, wo grep etwas anderes ist, greift das Muster nichts und jedes Laufwerk wird übersprungen. Ärgerlich, aber es irrt zumindest in die sichere Richtung.\nLies die Schleife trotzdem, bevor du sie laufen lässt. Wo sie greift, formatiert sie ohne weitere Rückfrage neu. nvme format --force fragt nicht zweimal. Sie gehört in die Bereitstellung, auf eine Maschine, deren Laufwerke nichts enthalten, nie auf einen Host mit einer lebenden OSD, einem Pool oder einer VM-Platte.\nAuf FreeBSD ist das Gegenstück nvmecontrol, wo -f der Formatindex ist:\nnvmecontrol format -f 1 nvme0ns1 SAS und SATA — openSeaChest Seagates openSeaChest läuft auf mehreren Plattformen, ist offener Quelltext und funktioniert auch auf Laufwerken anderer Hersteller.\n# Find the handle openSeaChest_Format --scan # Ask the drive which sector sizes it will accept openSeaChest_Format -d /dev/sg1 --showSupportedFormats # Convert. The confirmation string is deliberately hard to type by accident. openSeaChest_Format -d /dev/sg1 --setSectorSize 4096 \\ --confirm this-will-erase-data-and-may-render-the-drive-inoperable Diese Bestätigungsformel ist nicht meine Dramatik. Es ist die wörtliche Zeichenkette, die das Werkzeug verlangt, und der Teil „may render the drive inoperable“, das Laufwerk unbrauchbar machen, ist echt. Eine Formatierung auf niedriger Ebene, die von einem Stromausfall unterbrochen wird, kann ein Laufwerk hinterlassen, das erst wieder formatiert werden muss, bevor es überhaupt läuft.\nDarunter unterscheidet sich der Vorgang je Transport: SAS und SCSI nutzen Format Unit, SATA nutzt Set Sector Configuration Ext — den Weg der schnellen Formatierung — und NVMe nutzt NVM Format. Bei einem SAS-Laufwerk kannst du Format Unit direkt ansteuern, und beachte, dass diese Option die kürzere Bestätigungsformel nimmt:\nopenSeaChest_Format -d /dev/sg1 --formatUnit 4096 --poll \\ --confirm this-will-erase-data Zwei verschiedene Optionen, zwei verschiedene Bestätigungsformeln — verdreh sie, und das Werkzeug weigert sich.\nWo das Laufwerk schnelle Formatierung kann, ändert sich die Sektorgröße in Sekunden statt Stunden; das Laufwerk macht seine Integritäts- und Hintergrundarbeit danach, und deine echten Daten darauf zu schreiben verkürzt diese Hintergrundzeit. Eine vollständige Formatierung schreibt von Anfang bis Ende Nullen und kann auf einer großen sich drehenden Platte viele Stunden bis Tage dauern.\nopenSeaChest_Format -d /dev/sg1 --setSectorSize 4096 --fastFormat \\ --confirm this-will-erase-data-and-may-render-the-drive-inoperable SCSI — sg_format Für alles, was SCSI spricht, macht sg3_utils dieselbe Arbeit:\n# --size requires --format; expect hours on a large spinning disk sg_format --format --size=4096 /dev/sdb # Fast format where the drive supports it — seconds instead of hours sg_format --format --size=4096 --ffmt=1 /dev/sdb sg_format gibt dir 15 Sekunden Countdown, bevor es sich festlegt, und --quick überspringt den. Seine Dokumentation warnt außerdem vor einem bestimmten Fehlerfall, den man kennen sollte: gelingt die Änderung der Blockgröße, aber die Formatierung scheitert danach, kann das Laufwerk in einem Zustand „format corrupt“ landen und braucht eine weitere Formatierung, um sich zu erholen.\nBevor du etwas umstellst Prüf den Startweg. Ein 4Kn-Laufwerk als Startgerät braucht UEFI und ein Betriebssystem, das es kann. Modernes Linux ist in Ordnung. Älteres Windows nicht, und manche Hardware-RAID-Controller weisen 4Kn noch komplett ab. Mach es, bevor das Laufwerk etwas enthält. Nachträglich heißt: leerräumen, umstellen, zurückspielen. Mach eines, dann prüf. Stell ein einzelnes Laufwerk um, bestätige die gemeldeten Größen, dann mach den Rest. Rechne mit Stunden auf einer sich drehenden Platte ohne schnelle Formatierung. Fang keine Formatierung auf niedriger Ebene auf einer Maschine an, die du bald zurückbrauchst. Prüfen, was du hast # LOG-SEC is what the host addresses, PHY-SEC is what the medium uses lsblk -o NAME,MODEL,SIZE,LOG-SEC,PHY-SEC # The same, from sysfs cat /sys/block/sda/queue/logical_block_size cat /sys/block/sda/queue/physical_block_size # SMART states both, and this is the clearest 512e signature there is smartctl -a /dev/sda | grep -i \u0026#34;sector size\u0026#34; 512 bytes logical, 4096 bytes physical ist ein 512e-Laufwerk. Übereinstimmende Zahlen heißen nativ — 512n, wenn beide 512 sind, 4Kn, wenn beide 4096 sind.\nUnd prüf, dass die Partitionen wirklich passen:\nparted /dev/sda align-check optimal 1 ZFS, Ceph und virtuelle Platten ZFS — setz ashift=12 ausdrücklich beim Anlegen eines Pools und verlass dich nicht auf die gemeldete Größe des Laufwerks, denn auf 512e wird es dir 9 sagen und falsch liegen. Es lässt sich später nicht ändern.\nCeph — die minimale Zuweisungsgröße von BlueStore sollte auf Flash 4 KB sein. Modernes Ceph stellt 4096 voreingestellt ein, aber ältere Bauten stellten höher ein — rund 16 KB auf SSD und 64 KB auf HDD —, und das passt schlecht zu RBD-VM-Platten, denn die schicken viele kleine zufällige Schreibvorgänge über 4 KB, und ein 4-KB-Schreibvorgang, der in einer Zuweisungseinheit von 16 oder 64 KB landet, verstärkt sowohl den Schreibvorgang als auch verschwendet den Rest als Füllung. Es liegt fest, wenn die OSD angelegt wird, muss also vor dem Anlegen oder Neubauen gesetzt werden:\nceph config set global bluestore_min_alloc_size_ssd 4096 # new or rebuilt OSDs only Es gibt ein passendes bluestore_min_alloc_size_hdd. Bestehende OSDs behalten, womit sie gebaut wurden, es zu ändern heißt also, sie neu zu bauen.\nVirtuelle Platten — ein Gast sieht, was der Hypervisor zeigt, nicht das darunterliegende Laufwerk, ein 4Kn-Laufwerk unter einer VM gibt dem Gast also weiter Blöcke von 512 Byte, solange du nichts anderes sagst. Den Stapel von Ende zu Ende auf 4 K zu halten heißt, QEMU zu sagen, 4 K zu zeigen, und das ist in Proxmox eine rohe Argumentzeile in /etc/pve/qemu-server/\u0026lt;vmid\u0026gt;.conf:\nargs: -global scsi-hd.physical_block_size=4k -global scsi-hd.logical_block_size=4096 Diese Zeile ist es, die QEMU für diese Platten wirklich auf 4Kn zwingt — -global wendet es auf jedes scsi-hd-Gerät der VM an, dem Gast werden also 4096 für logische und physische Blockgröße gesagt, und er partitioniert und richtet entsprechend aus.\nSetz die ganze Zeichenkette nicht in Anführungszeichen. Proxmox liest args: mit Text::ParseWords::shellwords, und daher fällt dies:\nargs: \u0026#34;-global scsi-hd.physical_block_size=4k -global scsi-hd.logical_block_size=4096\u0026#34; zu einem einzigen Argument zusammen — die Anführungszeichen werden beachtet und entfernt, und QEMU bekommt eine lange unlesbare Option statt vier. Ohne Anführungszeichen teilt sich dieselbe Zeile in -global, scsi-hd.physical_block_size=4k, -global, scsi-hd.logical_block_size=4096, und das willst du. Es ist ein leichter Fehler, denn Anführungszeichen sind auf einer Kommandozeile der richtige Instinkt, und der Fehlerfall — eine VM, die nicht startet und über die Option klagt — zeigt nicht auf die Anführungszeichen zurück.\nMach das vor der Installation des Gast-Betriebssystems. Die Blockgröße einer Platte unter einem schon installierten System zu ändern kann es unstartbar machen, denn Partitionslayout und Bootloader wurden für Sektoren von 512 Byte geschrieben. Beachte außerdem, dass args: eine Notluke für Fachleute außerhalb der Verwaltung durch die GUI ist, und das Zusammenspiel mit Live-Migration und Snapshots ist es wert, gegen die aktuelle Proxmox-Dokumentation nachgeprüft zu werden.\nWenn der Gast 512 sagt und der Host 4 K Das ist der Fall, den man richtig verstehen sollte, denn das ist, was du standardmäßig bekommst, nachdem du die ganze Arbeit oben gemacht hast.\nQEMU zeigt dem Gast logische Blöcke von 512 Byte, solange man nichts anderes sagt, was auch das Gerät darunter ist. Du kannst also jedes Laufwerk im Host auf 4Kn umstellen, und den VMs darauf werden weiterhin 512 gesagt — und sie werden es glauben.\nDer Gast partitioniert dann auf Grenzen von 512 Byte, weil er darf, und schickt IO von 512 Byte, weil er darf. Aber das Gerät im Host hat jetzt wirklich einen logischen Block von 4096 Byte, und es nimmt keinen Schreibvorgang über 512 Byte an. Irgendetwas muss die beiden in Einklang bringen, und dieses Etwas ist der Host: QEMU liest die umgebenden 4 KB, mischt die 512 Byte des Gasts ein und schreibt das Ganze zurück.\nDu hast die Emulation nicht entfernt. Du hast sie aus der Firmware des Laufwerks in deinen Hypervisor verlegt, wo sie CPU des Hosts und einen Zwischenpuffer kostet statt Zyklen des Laufwerks.\nMit cache=none ist das auch kein sanfter Aufschlag. O_DIRECT gegen ein 4Kn-Gerät verlangt an 4 KB ausgerichtete Versätze und Längen, ein Schreibvorgang des Gasts unter 4 K kann also nicht einfach durchgereicht werden — die Ausrichtung muss in QEMU zurechtgebogen werden, bevor das IO überhaupt abgeschickt wird.\nUnd der Fall der Fehlausrichtung kommt eine Schicht höher zurück. Ein Gast, der auf Granularität von 512 Byte partitioniert ist, setzt seine 4-KB-Dateisystem-Schreibvorgänge auf Versätze, die über zwei 4-KB-Blöcke des Hosts liegen, jeder davon wird also zu zwei Read-Modify-Writes auf dem Host. Dasselbe Versagen wie eine fehlausgerichtete Partition auf einem nackten 512e-Laufwerk, nur passiert es jetzt in einer VM, wo niemand danach sucht.\nDie Regel ist also: ist der Host 4Kn, zeig dem Gast auch 4 K, und tu es, bevor das Betriebssystem darauf kommt.\nDie Ausnahme ist die Unterstützung im Gast, und das ist der ganze Grund, warum 512e existiert:\nLinux-Gäste kommen mit 4Kn ohne Aufhebens zurecht. Windows unterstützt 4Kn für Datenlaufwerke ab Windows 8 und Server 2012, und von 4Kn zu starten will UEFI. Alles Ältere — Windows 7 und davor — kann 4Kn überhaupt nicht. Für die ist eine virtuelle Platte, die 512 zeigt, der Preis, sie zu betreiben, und der Host wird das in Einklang bringen. Wenn das zählt, halte diese Gäste auf Speicher, wo es dich am wenigsten kostet, und nicht auf deiner schnellsten Ebene. Prüf im Gast, was der Gast tatsächlich bekommen hat:\nlsblk -o NAME,LOG-SEC,PHY-SEC 512 dort auf einem 4Kn-Host heißt, dass das Zurechtbiegen von oben bei jedem fehlausgerichteten Schreibvorgang passiert.\nQuellen OpenZFS — Workload Tuning — ashift, warum 2^ashift das kleinstmögliche IO auf einem vdev ist, und die Beobachtung, dass „many devices misreport their sector sizes“, viele Geräte ihre Sektorgrößen also falsch melden nvme-format-Handbuchseite — --lbaf, --namespace-id, --ses und --force sg_format-Handbuchseite — --size mit --format, die Option für schnelle Formatierung und die Warnung zu „format corrupt“ openSeaChest — Seagates Laufwerkswerkzeuge in offenem Quelltext, samt --setSectorSize und --showSupportedFormats openSeaChest-Wiki — Format, Fast Format, And Sector Sizes — welcher Transport welchen Befehl nutzt, und wann schnelle Formatierung gilt nvmecontrol(8) — das Gegenstück auf FreeBSD Dokumentation der Linux-Block-Schicht — wie der Kernel logische und physische Blockgrößen abbildet ","permalink":"https://blogs.damiendye.uk/de/proxmox/block-sizes-4kn-512e/","summary":"512e-Laufwerke zeigen Sektoren von 512 Byte, die sie nicht haben, und die Firmware macht den Unterschied bei jedem fehlausgerichteten Schreibvorgang wieder gut. Was das auf dem Medium, im Host und an Schreibverstärkung kostet — warum direkte synchrone Schreibvorgänge der schlimmste Fall sind — und wie man einen ganzen Bestand auf 4Kn bringt.","title":"4Kn, 512e und 512n — warum natives 4K gewinnt, und was die Emulation kostet"},{"content":"Was ein BAR ist, und warum GPUs daraus herausgewachsen sind Jedes PCIe-Gerät legt ein oder mehrere Base Address Register offen. Ein BAR sagt dem System, wie viel Adressraum das Gerät haben will, und die Firmware bildet ihn in die Speicherkarte des Hosts ab. Ist er abgebildet, erreicht die CPU den Speicher des Geräts mit gewöhnlichen Lade- und Speicherbefehlen.\nDie Größe eines BAR war früher im Silizium festgelegt. Die Firmware las sie beim Einschalten, und damit war das Gespräch beendet.\nDas war in Ordnung, solange BARs klein waren. Eine Netzwerkkarte will ein paar Dutzend Kilobyte für ihre Register. Ein NVMe-Controller will 16 KB bis 64 KB.\nGrafikkarten haben die Sache gesprengt. Eine moderne Karte hat 8, 12, 16 oder 24 GB Videospeicher, und das Naheliegende ist, alles abzubilden, damit die CPU überall hineinschreiben kann. Feste BARs konnten das nicht ausdrücken, also wurde ein kleines Fenster zur Übereinkunft — üblich 256 MB —, das der Treiber über den Framebuffer verschiebt und stückweise durchkopiert. Es funktioniert. Es ist bloß eine dämliche Menge Buchhaltung, um an Speicher zu kommen, den du schon gekauft und eingebaut hast.\nEin festes Fenster zeigt eine Scheibe auf einmal; Resizable BAR bildet alles ab Festes BAR — ein Fenster von 256 MB 24 GB VRAM, als Scheiben gezeichnet das Fenster Der Treiber verschiebt das Fenster und kopiert hindurch, eine Scheibe auf einmal. Die Scheiben sind Beispiel, nicht maßstäblich. Resizable BAR — alles davon dieselben 24 GB, einmal abgebildet ein BAR deckt alles ab Die CPU schreibt dorthin, wohin sie will. Kein Fenster, das zu bewegen wäre. Das Fenster von 256 MB ist weniger eine Bandbreitengrenze als eine Buchhaltungssteuer: der Treiber verbringt seine Zeit damit, das Fenster zu bewegen, statt Daten. Was Resizable BAR ändert Resizable BAR ist eine PCIe-Fähigkeit, mit der die Größe eines BAR verhandelt statt festgelegt wird. Das Gerät gibt an, welche Größen es kann, und die Firmware oder das Betriebssystem programmiert eine davon.\nFür eine GPU heißt das, dass der ganze Framebuffer auf einmal abgebildet werden kann. Der Treiber hört auf, durch ein Fenster zu blättern, und schreibt dorthin, wohin er schreiben will. Der Kernel meldet die Fähigkeit als Physical Resizable BAR, und sie ist herstellerneutral. Eine AMD-Karte arbeitet damit auf einer Intel-Plattform und umgekehrt.\nWas die drei Hersteller tatsächlich tun Das Interessante ist, dass die Hersteller sich nicht einig sind, wie viel es ausmacht.\nDrei Hersteller, eine Fähigkeit, drei verschiedene Haltungen Intel Arc / Arc Pro ZWINGEND “Required to get a good experience with Arc” Aus werden die Bildzeitspitzen, die schon da waren, größer. Plattformen: Core der 10. Gen und neuer, meiste Ryzen 3000, alle Ryzen 5000. NVIDIA PROFIL PRO SPIEL Ab der RTX-30-Reihe, März 2021 “A few percent, up to 12%” — und manche Titel werden langsamer, der Treiber schaltet es also nur dort ein, wo es schneller war. Brauchte VBIOS- und SBIOS-Update. AMD Radeon SMART ACCESS MEMORY Dieselbe Fähigkeit, verkauft unter einem Markennamen Kam mit RX 6000 und Ryzen 5000 als Paarfunktion, aber die Fähigkeit ist normales PCIe und wirkt herstellerübergreifend. Lückenhafter bei Vega und Polaris. Die Fähigkeit ist in allen drei Fällen dieselbe — verschieden ist, ob der Hersteller sie als Voraussetzung, als gezielt anzuwendende Optimierung oder als Produktmerkmal behandelt. Dieselbe Fähigkeit, drei verschiedene Haltungen. Intel behandelt sie als Voraussetzung; NVIDIA liefert sie nur für getestete Spiele eingeschaltet; AMD verkauft sie als Funktion. Intel Arc und Arc Pro — Intel nennt es zwingend Intel ist der Nachdrückliche. Ihre Hinweise sagen, Resizable BAR sei „required to get a good experience with Intel® Arc™ hardware“ — nötig, um mit Intel-Arc-Hardware eine gute Erfahrung zu bekommen. Das ist für ein Plattformmerkmal ungewöhnlich starke Sprache, und sie zeigt, wie der Arc-Treiber gebaut ist, nicht eine Marketing-Entscheidung.\nAuf der Symptomseite beschreibt Intel die Wirkung des Abschaltens nicht in Durchschnitten, sondern in Gleichmäßigkeit: mit „ReBAR off“ werde es „generally result in spikes that were already there getting bigger“ — Spitzen, die schon da waren, werden größer. Das ist ein Argument über die Stabilität der Bildzeiten, und es hat dieselbe Form wie die Wirkung von ASPM auf Latenzausläufer. Der Durchschnitt verbirgt sie.\nIntel führt Intel-Core-Prozessoren der 10. Generation und neuer, die meisten Ryzen der 3000er-Reihe und alle Ryzen-5000-CPUs als unterstützte Plattformen und behandelt es als BIOS-Funktion des Mainboards, die du selbst einschalten musst.\nFür Arc und Arc Pro ist die praktische Folge einfach. Hast du eine Arc-Karte in eine Maschine gesteckt und die Leistung ist enttäuschend oder ungleichmäßig, prüf das, bevor du irgendetwas anderes prüfst. Damit ist es auf diesen Karten weniger ein Stellrad als eine Voraussetzung.\nNVIDIA — ab Ampere, und nur wo es hilft NVIDIA hat die Unterstützung für Karten und Laptops der GeForce-RTX-30-Reihe im März 2021 nachgeliefert. Damit es lief, brauchte es ein passendes VBIOS, eine passende CPU und Platine, eine Aktualisierung der Platinen-Firmware und einen aktuellen Treiber. Die RTX 3060 kam damit; die 3060 Ti, 3070, 3080 und 3090 konnten eine Firmware-Aktualisierung brauchen.\nNVIDIAs eigene Einordnung der Leistung ist erfreulich unglamourös. Sie fanden, dass „some titles benefit from a few percent, up to 12%“ — manche Titel profitieren um wenige Prozent, bis zu 12 % —, während „there are also titles that see a decrease in performance“, es also auch Titel gibt, bei denen die Leistung sinkt.\nIhre Antwort darauf ist die Einzelheit, die man kennen sollte: statt es global anzulassen, testet NVIDIA Titel vorab und schaltet Resizable BAR über Profile pro Spiel nur dort ein, wo es als Gewinn gemessen wurde. Auf einer NVIDIA-Karte hat „ist ReBAR an?“ also eine Antwort pro Anwendung, und ein Benchmark, der nichts zeigt, kann einfach ein Titel sein, den der Treiber in Ruhe gelassen hat.\nAMD — Smart Access Memory ist dasselbe AMDs Markenname dafür ist Smart Access Memory, eingeführt zusammen mit der Radeon-RX-6000-Reihe und den Ryzen-5000-CPUs. Das Marketing legt eine Paarung aus AMD-CPU und AMD-GPU nahe, und so wurde es auch gestartet, aber die Fähigkeit darunter ist die normale PCIe-Fähigkeit. Schalte Resizable BAR in der Firmware mit einer Radeon-Karte in einer Intel-Maschine ein, und du bekommst dieselbe Funktion ohne den Markennamen.\nRadeon-Pro-Karten der W-Reihe können es auch. Auf älteren Architekturen — Vega und Polaris — ist die Unterstützung lückenhafter, und dort wohnt auch der Ärger mit der Virtualisierung.\nResizable BAR und KI-Arbeit Hier wird die Funktion missverstanden, deshalb lohnt es sich, klar zu sagen, was sie anfasst.\nResizable BAR ändert, wie die CPU an den GPU-Speicher kommt. Das ist der Übertragungsweg — Modellgewichte bereitstellen, Batches hineinschieben, Ergebnisse zurücklesen. Es fasst die Speicherbandbreite der GPU selbst nicht an, und es macht keine Matrixmultiplikation schneller.\nDie ehrliche Zusammenfassung ist also, dass es das Laden und Füttern eines Modells betrifft, nicht die Arithmetik. Bei einem großen Modell ist die Kopie vom Host zum Gerät beim Laden ein echter Kostenposten, und ein BAR in voller Größe lässt die CPU direkt in den Gerätespeicher schreiben, statt durch ein Bullauge von 256 MB zu pendeln. Für den Dauerzustand eines Inferenzlaufs — wo die Gewichte schon liegen und die Arbeit rechengebunden ist. Erwarte nichts.\nDrei Punkte lohnen sich.\nArc Pro für KI erbt Intels Urteil. Wenn Intel sagt, die Karte braucht Resizable BAR für eine gute Erfahrung, gilt das für eine Karte mit oneAPI oder PyTorch genauso wie für eine mit einem Spiel. Arc- und Arc-Pro-Karten, die Inferenz machen, sollten es eingeschaltet haben, Punkt.\nBei NVIDIA ist die Zahl, die du willst, BAR1. BAR1 ist das für den Host sichtbare Fenster auf den Gerätespeicher, und darüber laufen Host-abgebildete Allokationen und GPUDirect RDMA:\n# How much device memory is actually host-visible nvidia-smi -q | grep -A3 \u0026#34;BAR1 Memory Usage\u0026#34; Eine Rechenzentrumskarte ist mit einem großen BAR1 gebaut. Auf einer Desktop-Karte ist Resizable BAR das, was dieses Fenster groß statt winzig macht. Machst du RDMA direkt von einer NIC in den GPU-Speicher, ist das keine Feinheit.\nVerwechsle das nicht mit der Anforderung von ROCm. AMDs Systemanforderungen für ROCm verlangen CPUs mit PCIe-Atomics — „modern CPUs after the release of 1st generation AMD Zen CPU and Intel™ Haswell“ — und sagen nichts über BAR-Größen. Das sind zwei verschiedene Plattformanforderungen, die im selben BIOS-Menü wohnen, und Leute werfen sie ständig zusammen. Prüf die, die du wirklich brauchst.\nDer Fehlerfall, der KI-Aufbauten am härtesten trifft, ist überhaupt keine Leistungsfrage, und er steht weiter unten: mehrere GPUs mit großem BAR in einer Maschine können den Adressraum leerlaufen lassen.\nWas es zum Funktionieren braucht Vier Dinge, und alle auf Firmware-Ebene:\nResizable BAR eingeschaltet in der Mainboard-Firmware. Oft standardmäßig aus. Above 4G Decoding eingeschaltet. Ein BAR von 24 GB passt nicht unter die 4-GB-Linie, die Plattform muss also bereit sein, Adressraum darüber zu vergeben. Schalte das auch ohne GPU ein. Es kostet nichts. UEFI-Start, mit CSM aus. Der Kompatibilitätsmodus und große BARs verstehen sich nicht. Aktuelle Firmware und Treiber, besonders auf den Platinen und Karten aus dem Übergang 2020–2021, wo die Unterstützung per Aktualisierung statt zum Start kam. Ein großes BAR passt nur über 4 GB, und das Fenster des Gasts muss groß genug sein, es zu halten Wo ein vergrößertes BAR tatsächlich wohnen kann System-RAM 0 32-Bit-MMIO-Loch 4 GB 64-Bit-MMIO hoch GPU 0 24 GB BAR GPU 1 — 24 GB GPU 2 — 24 GB GPU 3 — 24 GB Voll, und insgesamt nur 4 GB breit Ein BAR von 24 GB kann hier nicht hin. Eines von 256 MB kaum. Nur mit Above 4G Decoding nutzbar Eine Firmware-Einstellung. Auf manchen Platinen aus, und ohne sie wird ein großes BAR nie zugewiesen. Jede Karte braucht hier oben ihren eigenen Platz Vier Karten mit 24 GB wollen 96 GB 64-Bit-MMIO zugewiesen, plus alles andere am Bus. Nicht jede Firmware einer Consumer-Platine macht das mit. Das Anzeichen: mit zwei Karten gut, mit vier kommt eine nicht hoch, und dmesg meldet keinen Platz für das BAR. Nicht maßstäblich: der 64-Bit-Bereich ist weitaus größer als die 4 GB darunter, was ziemlich genau der Punkt ist. Above 4G Decoding ist es, was den oberen Bereich überhaupt nutzbar macht — und jede Karte braucht ihren eigenen Platz dort oben, und genau dort laufen KI-Aufbauten mit mehreren GPUs an die Wand. Wie man es unter Linux prüft Ob die Karte die Fähigkeit hat, und welche Größen sie anbietet:\n# Substitute your card\u0026#39;s address from lspci lspci -vvs 0000:XX:00.0 | grep -A6 \u0026#34;Physical Resizable BAR\u0026#34; Der Kernel legt das auch in sysfs offen, eine Datei pro veränderbarem BAR:\ncat /sys/bus/pci/devices/0000:XX:00.0/resource1_resize Dieser Wert ist eine Bitmaske der möglichen Größen, keine Größe. Bit 0 heißt 1 MB, Bit 1 heißt 2 MB, Bit 2 heißt 4 MB, und die Größe für ein Bit ist 2 ^ (Bit + 20). 00000000000001c0 hat also die Bits 6, 7 und 8 gesetzt, das BAR kann demnach 64 MB, 128 MB oder 256 MB sein.\nUm zu sehen, was tatsächlich gilt, lies die zugewiesenen Regionen:\nlspci -vvs 0000:XX:00.0 | grep -i Region Eine Karte, die mit ihrem ganzen Framebuffer abgebildet läuft, zeigt eine Region in der Größe ihres VRAM statt einer von 256 MB.\nVon Hand vergrößern Du kannst die Bitposition selbst schreiben:\n# bit 7 -\u0026gt; 2 ^ (7 + 20) = 128MB echo 7 \u0026gt; /sys/bus/pci/devices/0000:XX:00.0/resource1_resize Die Bedingungen daran sind streng und es lohnt, sie zu lesen, bevor du es an einer Maschine versuchst, die dir am Herzen liegt. Jeder Treiber muss zuerst vom Gerät gelöst werden. Nachbargeräte unter derselben übergeordneten Bridge müssen möglicherweise sanft entfernt werden. Auf einem VGA-Gerät reißt das Schreiben eines Größenwerts die Konsolentreiber der unteren Ebene ab. Alles, was die resourceN-Dateien in sysfs offen hält, muss loslassen.\nDie Kernel-Dokumentation ist über das Ergebnis auch unmissverständlich: Erfolg ist nicht garantiert. Das Vergrößern scheitert, wenn kein Adressraum für das größere BAR da ist. Was dich direkt zurück zu Above 4G Decoding bringt.\nWenn es schiefgeht dmesg sagt, es kann das BAR nicht zuweisen. Meldungen in der Form BAR 0: no space for [mem size ...] heißen, dass die Zuweisung gescheitert ist, nicht dass die Karte kaputt ist. Above 4G Decoding ist das Erste, was man prüft.\nMehrere GPUs, und eine kommt nicht hoch. Das ist der Fehlerfall bei mehreren GPUs und in KI-Kisten. Vier Karten mit BARs von 24 GB brauchen 96 GB an 64-Bit-MMIO-Raum, plus alles andere, und nicht jede Firmware einer Consumer-Platine macht das mit. Das Symptom ist, dass die Maschine mit zwei Karten läuft und mit vier umfällt.\nDie Leistung ist gesunken. Bei NVIDIA kann das der Schluss des Treibers selbst sein, denn sie schalten es genau deshalb pro Titel ein, weil manche Lasten zurückfallen. Bei den anderen: messen statt annehmen, und zwar in beide Richtungen.\nEs hat sich überhaupt nichts geändert. Das wahrscheinlichste Ergebnis bei einer Last, die nie vom Fenster der CPU in den VRAM begrenzt war.\nEine GPU mit großem BAR an eine VM durchreichen Erwähnenswert, weil es Leute überrascht: ein Gast erbt die Speicherkarte des Hosts nicht. Die Firmware der VM baut ihr eigenes 64-Bit-MMIO-Fenster, und die Voreinstellung von OVMF ist weit kleiner, als eine moderne GPU braucht, die Karte kommt also entweder nicht hoch oder fällt auf ein kleines BAR zurück. Das ist ein Proxmox- und QEMU-Thema und kein GPU-Thema, und es wohnt in dem Beitrag über die IOMMU-Steuer neben den Anforderungen an den Maschinentyp aus Immer Q35, nicht i440fx.\nQuellen Intel — Resizable BAR and Intel Arc Graphics — Intels eigene Aussage, dass es auf Arc für eine gute Erfahrung nötig ist, und die Liste der unterstützten Plattformen NVIDIA — Resizable BAR support for GeForce RTX 30 Series — die Anforderungen, die gemessene Spanne und der Ansatz mit Profilen pro Spiel AMD — Smart Access Memory — AMDs Markenname und die Plattformpaarung Linux-Kernel-ABI sysfs-bus-pci — resourceN_resize — die Bitmaske, die Größe als 2 ^ (Bit + 20) und die Bedingungen zum Lösen der Treiber ROCm-Systemanforderungen — die Anforderung an PCIe-Atomics, die mit dieser hier verwechselt wird ","permalink":"https://blogs.damiendye.uk/de/proxmox/pcie-resizable-bar/","summary":"Resizable BAR lässt die CPU den ganzen Framebuffer einer GPU abbilden, statt durch ein Fenster von 256 MB zu schielen. Intel nennt es für Arc zwingend, NVIDIA schaltet es pro Spiel ein, AMD verkauft es als Smart Access Memory — und für KI-Arbeit ändert es die Übertragung, nicht die Rechnerei.","title":"PCIe Resizable BAR und moderne GPUs — Intel Arc, NVIDIA und AMD"},{"content":"Das Problem Das kam bei einem Kundenprojekt auf, in dem wir eine Proxmox-VE-Installation mit NVMe-Passthrough für eine latenzempfindliche Last entworfen haben. Der Kunde hatte vor dem Gespräch selbst gemessen. Auf dem Host meldete fio gegen das NVMe-Laufwerk 700K zufällige Lese-IOPS mit einer Completion-Latenz unter 10 µs. In der VM, mit demselben Laufwerk und demselben Test, bekamen sie etwa die Hälfte davon.\nDas Naheliegende hatten sie schon geprüft. Das Laufwerk hatte sich nicht geändert. Die Firmware hatte sich nicht geändert. Der PCIe-Slot war nicht umgezogen. Sie fingen an sich zu fragen, ob Passthrough überhaupt der falsche Ansatz sei.\nWar es nicht. Was sie sahen, ist die IOMMU-Steuer. Sie erwischt Leute, weil dir niemand davon erzählt, bevor du dich auf den Passthrough-Entwurf festgelegt hast. Die gute Nachricht ist, dass der größte Teil des Overheads zurückzuholen ist, sobald man versteht, woher er kommt.\nGenauer hingesehen Die Probleme, die gelöst werden mussten Einer VM direkten Zugriff auf ein physisches PCIe-Gerät zu geben klingt geradeheraus. In der Praxis ist es eines der härteren Probleme der Systemvirtualisierung. Einiges, was auf Blech von allein funktioniert, wird gefährlich, wenn ein Gerät zwischen Host und Gast geteilt wird.\nDMA-Isolation Das ist das grundlegende Problem.\nPCIe-Geräte gehen zum Lesen und Schreiben von Speicher nicht über die CPU. Sie nutzen Direct Memory Access. Sie schreiben direkt auf physische RAM-Adressen. Auf Blech ist das in Ordnung. Das Gerät und das Betriebssystem vertrauen einander.\nUnter Virtualisierung hat die Gast-VM ihre eigene Sicht auf den physischen Speicher. Die Adressen, die der Treiber im Gast dem NVMe-Controller gibt, sind physische Adressen des Gasts. Sie zeigen nicht auf dieselben Stellen im Host-RAM. Nutzt das Gerät sie direkt, liest und schreibt es den falschen Speicher. Das verdirbt den Host, andere VMs oder beides.\nSchlimmer noch: ein böswilliger oder fehlerhafter Treiber im Gast könnte das Gerät absichtlich so programmieren, dass es per DMA in jeden Teil des Host-Speichers schreibt. Das ist im Ergebnis Root-Zugriff auf die ganze Maschine, ohne je einen Hypervisor-Fehler ausgenutzt zu haben.\nDie Lösung ist die IOMMU — eine Übersetzungseinheit in Hardware (Intel VT-d, AMD-Vi), die zwischen jedem PCIe-Gerät und dem Hauptspeicher sitzt. Sie hält ihre eigenen Seitentabellen, getrennt von denen der CPU. Jede DMA-Anforderung des Geräts läuft durch die IOMMU, die physische Gast-Adressen in physische Host-Adressen übersetzt und jeden Zugriff außerhalb der dem Gast zugewiesenen Speicherbereiche blockt.\nOhne die IOMMU ist sicheres Passthrough unmöglich. Mit ihr ist das Gerät eingehegt.\nGerätegruppen Die IOMMU isoliert nicht einzelne Geräte. Sie isoliert Gruppen.\nDie PCIe-Spezifikation legt Access Control Services (ACS) fest, die regeln, ob Geräte am selben Bus direkt miteinander reden können — DMA von Gerät zu Gerät —, ohne über den Root Complex zu gehen, wo die IOMMU sitzt. Teilen zwei Geräte einen PCIe-Switch, der ACS nicht durchsetzt, kann ein Gerät per DMA in den Speicherbereich des anderen schreiben und die IOMMU komplett umgehen.\nDer Kernel fasst Geräte, die einander möglicherweise ohne IOMMU-Durchsetzung erreichen können, zu einer einzigen IOMMU-Gruppe zusammen. Teilt dein NVMe-Controller eine Gruppe mit einem anderen Gerät, bricht das Isolationsmodell, wenn du nur das NVMe durchreichst. Das andere Gerät der Gruppe könnte weiterhin als Seitenkanal um die IOMMU herum dienen.\nHardware auf Server-Niveau mit ordentlicher ACS-Unterstützung an jeder Bridge und jedem Switch gibt jedem Gerät meist seine eigene Gruppe. Consumer- und Workstation-Platinen werfen mehrere Geräte oft zusammen, weil der PCIe-Root-Complex ACS nicht an jedem Port umsetzt.\nProxmox trägt einen Kernel-Patch — pcie_acs_override —, der dem Kernel sagt, jedes Gerät als isoliert zu behandeln, egal was die Hardware an ACS kann. In der Praxis funktioniert es, aber es belügt den Kernel über die Hardware-Topologie. Auf einem produktiven System sind saubere Gruppen, die von echtem Hardware-ACS getragen werden, immer vorzuziehen.\nInterrupt-Zustellung Wenn ein NVMe-Controller auf Blech eine IO-Operation fertigstellt, feuert er einen MSI-X-Interrupt direkt an die CPU. Die CPU behandelt ihn in ein paar hundert Nanosekunden.\nUnter Virtualisierung muss dieser Interrupt den Gast erreichen, nicht den Host. Der naive Weg ist, jeden Interrupt im Hypervisor abzufangen, einen VM-Exit auszulösen, den Interrupt in den Gast einzuspeisen und weiterzumachen. Das geht, aber jeder VM-Exit kostet 5–20 µs. Bei hohen IOPS — hunderttausenden Interrupts pro Sekunde — ist der Overhead erheblich.\nDie Lösung in Hardware heißt Posted Interrupts. Intels APICv und AMDs AVIC erlauben es der IOMMU, den Interrupt direkt in die virtuelle APIC-Seite des Gasts zu schreiben, ganz ohne VM-Exit. Der Gast sieht den Interrupt, als käme er von Hardware auf Blech. Der Overhead fällt auf ein paar hundert Nanosekunden.\nNicht jede Plattform unterstützt Posted Interrupts. Ältere CPUs, manche Workstation-Chipsätze und manche BIOS-Versionen legen die Fähigkeit nicht offen. Fehlt sie, geht jeder Interrupt über den langsamen Weg, und es gibt keinen Ausweg in Software.\nGeräte-Reset Wenn eine VM herunterfährt oder abstürzt, muss das durchgereichte Gerät in einen sauberen, bekannten Zustand zurückkehren. Sonst kann es keiner anderen VM zugewiesen und nicht vom Host zurückgeholt werden.\nAuf Blech fährt das Betriebssystem den Gerätetreiber geordnet herunter. Beim Passthrough kann der Gast abstürzen, der Nutzer die VM hart stoppen oder der Hypervisor den Prozess töten. Das Gerät könnte mitten in einer Übertragung stecken, mit DMA-Operationen unterwegs.\nPCIe legt dafür den Function Level Reset (FLR) fest — einen Weg, eine einzelne Gerätefunktion zurückzusetzen, ohne den Rest des Busses anzufassen. NVMe-Controller können FLR meist und kommen gut damit zurecht. GPUs sind dabei notorisch schlecht, aber das ist ein anderer Beitrag.\nIst FLR nicht möglich, bleibt als Rückfall ein Secondary Bus Reset, der alles hinter dieser PCIe-Bridge zurücksetzt. Hängen an der Bridge andere Geräte, werden die alle mit zurückgesetzt. Im schlimmsten Fall ist ein vollständiger Neustart des Hosts der einzige Weg, das Gerät zurückzuholen.\nOverhead durch Adressübersetzung Die IOMMU löst das Sicherheitsproblem. Damit ist sie nicht optional. Aber sie schafft ein Leistungsproblem.\nJede DMA-Operation läuft nun durch eine zusätzliche Stufe der Adressübersetzung. Die IOMMU hat ihren eigenen TLB — den IOTLB —, und wenn er trifft, ist der Overhead klein. Wenn er nicht trifft, muss die IOMMU ihre Seitentabellen ablaufen, und das schlägt jeder betroffenen IO-Operation echte Latenz auf.\nDas ist die IOMMU-Steuer. Der Rest dieses Beitrags handelt davon, zu verstehen, woher sie kommt, und sie klein zu halten.\nJeder DMA geht durch die IOMMU: ein Treffer ist billig, ein Fehlschlag läuft die Seitentabellen ab Gast-VM NVMe-Treiber gibt physische Gast-Adressen heraus NVMe-Controller schreibt Speicher direkt — ohne CPU DMA IOMMU IOTLB eigene Seitentabellen übersetzen, erlauben, abweisen Host-Speicher die Seiten dieser VM die Übersetzung landet hier Host und andere VMs von Entwurf her unerreichbar Ohne die IOMMU würde der Controller Gast-Adressen direkt ins Host-RAM schreiben und verderben, was auch dort liegt. Treffer im IOTLB — die Übersetzung liegt im Cache und kostet fast nichts. Fehlschlag im IOTLB — die IOMMU läuft ihre Seitentabellen ab, und diese Latenz landet auf diesem IO. Das ist die Steuer. Nichts erreicht den Speicher, ohne hier durchzugehen. Das ist die Sicherheitszusage, und die Übersetzung, die sie leistet, ist der Preis. BAR-Abbildung und Adressraum Jedes PCIe-Gerät legt ein oder mehrere Base Address Register (BARs) offen, die die internen Register und den Speicher des Geräts in den MMIO-Adressraum des Hosts abbilden. Die Host-CPU greift über diese Abbildungen auf das Gerät zu. Damit Passthrough funktioniert, muss der Hypervisor diese Abbildungen dem Gast richtig zeigen.\nFrüher waren BAR-Größen beim Start durch das BIOS festgelegt und passten in das alte 32-Bit-MMIO-Fenster unter 4 GB. Das ging, solange BARs klein waren. Moderne GPUs haben das Bild geändert. Ein Framebuffer von 24 GB braucht ein BAR von 24 GB, und das passt nicht in einen 32-Bit-Adressraum.\nResizable BAR (ReBAR) — vermarktet auch als AMD Smart Access Memory (SAM) — ist eine PCIe-Fähigkeit, mit der die BAR-Größe nach dem Start neu verhandelt werden kann. Für GPUs ist das eine große Sache. Statt über ein Fenster von 256 MB auf den Framebuffer zuzugreifen und stückweise durchzublättern, bildet der Host den ganzen VRAM auf einmal ab.\nFür NVMe ist die unmittelbare Wirkung geringer. BARs von NVMe-Controllern sind für den Registersatz des Controllers (BAR0) typisch 16 KB bis 64 KB. Die NVMe-Spezifikation legt einen Controller Memory Buffer (CMB) fest, der ein größeres BAR für Submission Queues im Host-Speicher offenlegen kann, aber die meisten Laufwerke setzen ihn nicht um. ReBAR ändert den NVMe-Durchsatz nicht so, wie es das bei GPUs tut.\nWichtig ist es im Zusammenhang mit NVMe-Passthrough wegen der geteilten PCIe-Umgebung. Reichst du ein NVMe-Laufwerk zusammen mit einer GPU auf demselben Host durch, braucht das vergrößerte BAR der GPU Adressraum oberhalb der 4-GB-Grenze. Das BIOS, die IOMMU und die virtuelle PCIe-Topologie müssen das alle hergeben. Verteilt man den Adressraum falsch, kommen Geräte nicht hoch, und das NVMe-Passthrough scheitert mit allem anderen.\nVerwundbarkeit bei Stromausfall Bei einer virtuellen Platte kümmern sich Hypervisor und Speicherschicht um Schreibreihenfolge und Konsistenz nach einem Absturz. Beim Passthrough redet der Gast direkt mit dem Flash. Verliert der Host mitten im Schreiben den Strom, entscheidet allein, was die Firmware des NVMe-Controllers mit ihrem Schreibcache tut — oder nicht tut —, ob du Daten verlierst.\nEnterprise-NVMe-Laufwerke tragen Kondensatoren für den Schutz bei Stromverlust (PLP), die den Schreibcache bei einem Ausfall sicher leeren. Consumer-Laufwerke ohne PLP tun das möglicherweise nicht. Beim Passthrough gibt es kein Netz vom Hypervisor zwischen Gast und Hardware.\nFür produktive Arbeit ist ein Enterprise-Laufwerk mit PLP nicht optional.\nBetriebliche Abwägungen Passthrough nimmt auch Fähigkeiten weg, die virtuelle Platten bieten.\nEin durchgereichtes Gerät ist physisch an einen bestimmten Host geschraubt. Die VM kann nicht live migriert werden, solange das Gerät angehängt ist. In einem Proxmox-Cluster mit HA heißt ein Knotenausfall, dass die VM ausfällt und auf einem anderen Knoten kalt startet. Es gibt keine reibungslose Übernahme.\nDas Laufwerk ist außerdem für vzdump und den Proxmox Backup Server unsichtbar. Es wird nicht in Snapshots der VM oder geplante Sicherungen aufgenommen. Eine eigene Sicherungsstrategie — im Gast, auf Dateisystemebene oder in der Anwendung — muss stehen, bevor die Last live geht.\nWie VFIO-Passthrough tatsächlich arbeitet Reichst du ein PCIe-Gerät an eine VM durch, gibt der Hypervisor dem Gast direkte Kontrolle über die MMIO-Register des Geräts. Der Treiber im Gast redet mit dem NVMe-Controller, als liefe er auf Blech. Dieser Teil ist nahe an native. MMIO-Registerzugriffe laufen über Extended Page Tables (EPT bei Intel, NPT bei AMD) und kommen meist ohne VM-Exit durch.\nDer DMA-Weg ist die Stelle, an der die Kosten auftauchen. Jede DMA-Operation läuft für die Adressübersetzung durch die IOMMU, und wie oben beschrieben hat diese Übersetzung einen Preis. Besonders wenn der IOTLB nicht trifft.\nWarum die Benchmarks schlechter aussehen als die Wirklichkeit Hier gehen die meisten Leute beim Testen falsch vor.\nIn einem Proxmox-Forum-Thread, der zu diesem Beitrag geführt hat, haben Nutzer fio mit iodepth=1 laufen lassen. Bei dieser Queue-Tiefe schickt fio ein IO ab, wartet, bis es fertig ist, und schickt dann das nächste. Der Test misst nichts als die Latenz pro IO. Jede Mikrosekunde IOMMU-Overhead zeigt sich in voller Höhe.\nDie Zahlen aus diesem Thread erzählen die Geschichte klar. Auf Blech lag die Completion-Latenz im Mittel bei etwa 10 µs. In der VM lag sie im Mittel bei etwa 28 µs. Diese zusätzlichen ~18 µs pro IO sind der Overhead der IOMMU-Übersetzung. Bei iodepth=1 halbiert das den Durchsatz direkt, denn der Durchsatz ist 1 / Latenz, wenn nur ein IO unterwegs ist.\nZieh die Queue-Tiefe auf 32 oder 64 hoch — so sind NVMe-Laufwerke gedacht —, und das Bild ändert sich. Mit mehreren IOs unterwegs verteilt sich der IOMMU-Overhead auf alle. Der Controller arbeitet Fertigmeldungen ab, während neue Übersetzungen laufen. Der Durchsatz kommt bis auf wenige Prozent an den Blechwert zurück.\nPraktisch heißt das Folgendes. Läuft deine Arbeit bei Queue-Tiefen über 4, ist der Durchsatzaufschlag der IOMMU wahrscheinlich zu vernachlässigen. Das deckt die meisten Datenbank-, Virtualisierungs- und Speicherlasten ab. Ist deine Arbeit bei niedrigen Queue-Tiefen latenzempfindlich — bestimmte Echtzeitanwendungen, synchrone Metadaten-Operationen —, wirst du sie spüren.\nDer IOMMU-Aufschlag ist mehr ein Effekt der Queue-Tiefe als eine Decke für den Durchsatz Durchsatz der VM als Anteil des Blechwerts hier drin leben realistische Lasten 0% 25% 50% 75% 100% der Benchmark, den alle laufen lassen iodepth=1 misst reine Latenz pro IO, also zeigen sich 10 µs gegen 28 µs in voller Höhe wenige Prozent Abstand 1 2 4 8 16 32 64 Queue-Tiefe (fio iodepth) Veranschaulichung aus den 10 µs / 28 µs des Beitrags selbst. Dieselbe Hardware, derselbe Test, derselbe Overhead — nur die Queue-Tiefe ändert sich. Der Overhead ist an jedem Punkt dieser Kurve derselbe. Was sich ändert, ist bloß, wie viele IOs unterwegs sind, um ihn darauf zu verteilen. Lass deine Benchmarks bei realistischen Queue-Tiefen laufen, bevor du zum Schluss kommst, Passthrough sei zu langsam:\n# Bare metal baseline — run on the host before binding to vfio-pci fio --name=randread --ioengine=libaio --direct=1 --bs=4k \\ --iodepth=32 --numjobs=4 --rw=randread --size=1G \\ --filename=/dev/nvme0n1 --runtime=30 --time_based \\ --group_reporting # Same test inside the VM after passthrough fio --name=randread --ioengine=libaio --direct=1 --bs=4k \\ --iodepth=32 --numjobs=4 --rw=randread --size=1G \\ --filename=/dev/nvme0n1 --runtime=30 --time_based \\ --group_reporting Vergleiche die clat-Perzentile (Completion Latency) und die IOPS-Zahlen. Bei iodepth=32 mit vier Jobs sollte der Abstand im einstelligen Prozentbereich liegen, nicht bei 50 %.\nNUMA-Ausrichtung Das hat seinen eigenen Beitrag. Siehe NUMA-Ausrichtung auf Proxmox VE — warum sie zählt und wie man sie richtig hinbekommt.\nDie kurze Fassung: auf Systemen mit mehreren Sockeln ist jedes PCIe-Gerät an einen bestimmten Sockel verdrahtet. Sitzt das NVMe-Laufwerk auf NUMA-Knoten 1 und sind die vCPUs der VM auf Knoten 0 gepinnt, überquert jede DMA-Fertigmeldung die Verbindung zwischen den Sockeln. Das kostet 50–100 ns pro Operation. Bei hohen IOPS liegt der Durchsatzunterschied zwischen ausgerichtetem und fehlausgerichtetem NUMA bei 20–30 %.\nPrüf mit cat /sys/bus/pci/devices/0000:XX:00.0/numa_node und pinn dann die vCPUs der VM mit dem Parameter affinity in der VM-Konfiguration auf Kerne des gleichen Knotens. Auf Systemen mit einem Sockel ist das kein Thema.\nPCIe Active State Power Management (ASPM) Das hat seinen eigenen Beitrag. Siehe PCIe-ASPM, und warum du es für Passthrough abschalten solltest.\nDie kurze Fassung: ASPM erlaubt PCIe-Links, in Zustände mit geringer Leistung zu gehen, wenn sie unbeschäftigt sind. Beim Passthrough steuert der Host weiterhin den physischen Link, aber der Gast besitzt das Gerät. Schickt der Gast IO ab, während der Link schläft, schlägt die Aufwachzeit als Latenz auf. Das Symptom ist eine weite Streuung in deinen clat-Perzentilen. Das p99 kann 5- bis 10-mal höher liegen als der Durchschnitt, während das Mittel gut aussieht.\nSchalte es auf dem Host mit pcie_aspm=off in der Kernel-Kommandozeile ab. Füge außerdem disable_idle_d3=1 zu den Modul-Optionen von vfio-pci hinzu, wenn dein NVMe-Controller Probleme mit der Rückkehr aus Energiezuständen hat. Die Samsung 990 EVO Plus ist ein bekannter Übeltäter.\nMaxPayloadSize (MPS) Das hat seinen eigenen Beitrag. Siehe PCIe MaxPayloadSize — ein kostenloser Leistungsgewinn beim Passthrough.\nDie kurze Fassung: PCIe-Geräte übertragen Daten in Transaction Layer Packets. Der virtuelle Root Complex von QEMU liefert standardmäßig höchstens 128 Byte Payload. Die meisten Geräte können 256 oder 512 Byte. pci=pcie_bus_perf in der Kernel-Kommandozeile des Hosts setzt MPS auf das Maximum, das der übergeordnete Bus jedes Geräts zulässt. Es ist eine kleine Verbesserung des Durchsatzes — niedriger einstelliger Prozentbereich —, aber sie ist kostenlos und ohne Nachteil.\nResizable BAR und das MMIO-Fenster Das oben beschriebene Problem der BAR-Abbildung hat praktische Schritte sowohl im BIOS als auch auf der VM-Seite.\nSchalte zuerst „Above 4G Decoding“ im BIOS ein. Damit können BARs in Adressraum oberhalb der 4-GB-Grenze abgebildet werden, was für jedes Gerät mit großen BARs nötig ist. Schalte es selbst dann ein, wenn du nur NVMe durchreichst. Es hat keinen Nachteil und erspart Ärger, wenn später eine GPU oder ein anderes Gerät mit großem BAR dazukommt.\nIst ReBAR im BIOS vorhanden, schalte das auch ein. Es wirkt sich auf die NVMe-Leistung nicht direkt aus, erlaubt aber GPUs auf demselben Host, ihre volle Framebuffer-Abbildung zu nutzen.\nAuf der VM-Seite braucht der virtuelle Q35-Root-Complex von QEMU ein 64-Bit-MMIO-Fenster, das groß genug ist, damit der Gast vergrößerte BARs sieht. Standardmäßig weist OVMF ein recht kleines Fenster zu. Für Passthrough mit nur NVMe ist das in Ordnung. NVMe-BARs passen bequem. Hat die VM aber sowohl ein NVMe als auch eine GPU durchgereicht, vergrößere das MMIO-Fenster:\nargs: -fw_cfg name=opt/ovmf/X-PciMmio64Mb,string=65536 Das sagt OVMF, 64 GB 64-Bit-MMIO-Raum zuzuweisen, genug für die meisten GPU-Framebuffer neben dem kleinen BAR des NVMe-Controllers.\nDie ReBAR-Unterstützung von QEMU wird besser, ist aber noch nicht reibungslos. Manche AMD-GPUs (Vega und neuer) lösen mit eingeschaltetem ReBAR unter QEMU Treiberfehler aus (Code 43 unter Windows). Trifft dich das, schalte ReBAR im BIOS als ersten Schritt ab. NVMe-Passthrough ist so oder so nicht betroffen.\nWas Resizable BAR auf der GPU-Seite des Zauns tut, und warum Intel es auf Arc für zwingend hält, während NVIDIA es pro Spiel einschaltet, steht in PCIe Resizable BAR und moderne GPUs.\nInterrupts behandeln Das oben beschriebene Problem der Interrupt-Zustellung hat einen praktischen Schritt. Posted Interrupts (APICv bei Intel, AVIC bei AMD) sind vielleicht nicht standardmäßig eingeschaltet.\nPrüfen, ob sie aktiv sind:\n# Intel — look for \u0026#34;Posted-Interrupts\u0026#34; in dmesg dmesg | grep -i \u0026#34;posted\u0026#34; # AMD — check AVIC support dmesg | grep -i \u0026#34;avic\u0026#34; Abgefangene Interrupt-Zustellung gegen Posted Interrupts Keine Posted Interrupts — die Fertigmeldung nimmt den Umweg NVMelöst MSI-X aus Hypervisorfängt ihn ab einspeisenin den Gast Gast macht weiterbehandelt ihn VM-Exit VM-Entry 5–20 µs pro Interrupt Bei ein paar hunderttausend IOPS ist das kein Rundungsfehler — es ist der beherrschende Kostenposten. Posted Interrupts (Intel APICv / AMD AVIC) — direkt hinein NVMelöst MSI-X aus IOMMUschreibt ihn direkt virtuelle APIC-Seite des Gasts der Gast sieht einfach einen Interrupt kein Exit kein Exit ~100er ns Es gibt keinen Ausweg in Software: Posted Interrupts sind eine Fähigkeit der Hardware. Sie sind aber nicht immer standardmäßig an, prüf also darauf, bevor du den langsamen Weg für unvermeidlich hältst. Vier Schritte und zwei VM-Exits, oder ein Schreibvorgang in die APIC-Seite des Gasts. Bei hohen IOPS hört der Unterschied auf, akademisch zu sein. Schalte auf AMD-EPYC-Systemen AVIC im KVM-Modul ein, wenn es nicht schon an ist:\n# /etc/modprobe.d/kvm.conf options kvm_amd avic=1 Auf Intel-Systemen ist APICv mit Posted Interrupts meist automatisch an, wenn VT-d aktiv ist.\nUnterstützt deine Plattform keine Posted Interrupts, gibt es keinen Ausweg in Software. Es ist eine Fähigkeit der Hardware. Aber es lohnt sich, nachzusehen, ob sie wirklich an ist, bevor du annimmst, der langsame Weg sei unvermeidlich.\nInterrupt-Affinität und Queue-Ausrichtung NVMe-Controller nutzen mehrere Paare aus Submission- und Completion-Queue. Typisch eines pro CPU-Kern. Passen die vCPUs der VM nicht zu den physischen Kernen, die die NVMe-Interrupts behandeln, müssen Fertigmeldungen per Interprozessor-Interrupt über Kerne hinweg. Das kostet Latenz.\nPrüfe im Gast, wie viele IO-Queues der NVMe-Treiber angelegt hat und wie sie abgebildet sind:\n# List NVMe IO queues cat /proc/interrupts | grep nvme # Check affinity for irq in $(grep nvme /proc/interrupts | awk \u0026#39;{print $1}\u0026#39; | tr -d \u0026#39;:\u0026#39;); do echo \u0026#34;IRQ $irq: $(cat /proc/irq/$irq/smp_affinity_list)\u0026#34; done Idealerweise sollte der Interrupt jeder NVMe-IO-Queue auf die vCPU gebunden sein, die in diese Queue einreicht. Die meisten modernen NVMe-Treiber machen das von allein. Es lohnt sich aber nachzusehen, besonders wenn du vCPUs von Hand gepinnt oder die Zahl der vCPUs unter die Queue-Zahl des Controllers gesenkt hast.\nImmer Q35, nicht i440fx Das verdient seinen eigenen Beitrag. Siehe Immer Q35, nicht i440fx.\nDie kurze Fassung: i440fx zeigt einen flachen, alten PCI-Bus. Q35 zeigt einen richtigen PCIe-Root-Complex. Durchgereichte Geräte erscheinen auf i440fx als altes PCI, und das zerbricht die MSI-X-Interrupt-Zustellung über mehrere Queues. NVMe-Controller brauchen MSI-X für ihre Architektur mit einer Queue pro Kern. Ohne sie laufen alle IO-Fertigmeldungen durch einen einzigen Interrupt, und du bekommst bei hohen IOPS einen Engpass, den kein Kernel-Tuning behebt.\nIn Proxmox 8.x und neuer ist Q35 die Voreinstellung für neue VMs. Machst du Passthrough auf einer älteren VM, die noch i440fx ist, stell sie um. RHEL 10 hat i440fx formell für überholt erklärt, und das übrige KVM-Umfeld folgt.\nAlles zusammengenommen Hier eine Übersicht der Tuning-Schritte nach Wirkung geordnet.\nDie Tuning-Schritte nach Wirkung geordnet, und was jeder wirklich ändert nach Wirkung geordnet was es ändert 1 NUMA-Ausrichtung 20–30 % Durchsatz auf einer Kiste mit mehreren Sockeln. Nichts sonst auf dieser Liste kommt heran. DURCHSATZ 2 ASPM aus Nimmt die Aufwachlatenz aus dem Ausläufer. Der Durchschnitt rührt sich kaum; p99 schon. LATENZZITTERN 3 Realistische Queue-Tiefen Ändert nichts an der Maschine. Hält dich vom falschen Schluss aus iodepth=1 ab. DIE MESSUNG 4 Posted Interrupts (APICv / AVIC) µs auf ns pro Interrupt — aber nur, wenn die Plattform es hat. Prüfen, nicht annehmen. KOSTEN PRO INTERRUPT 5 MaxPayloadSize — pci=pcie_bus_perf Niedrige einstellige Prozente. Kostenlos, ohne Nachteil — setz es, erwarte aber nichts. OVERHEAD AUF DER LEITUNG 6 vfio-pci disable_idle_d3 Hält einen zickigen Controller davon ab, in D3 zu sterben. Kauft Verlässlichkeit, nicht Geschwindigkeit. VERLÄSSLICHKEIT Gereiht, bewusst nicht als Balken gezeichnet: sie teilen keine Einheit, ein Balkendiagramm würde also zu einem Vergleich einladen, den es nicht gibt. Arbeite diese Liste von oben nach unten ab, nicht quer. Der erste Eintrag ist auf einer Maschine mit mehreren Sockeln mehr wert als der ganze Rest zusammen. NUMA-Ausrichtung — sorge dafür, dass das NVMe-Laufwerk und die vCPUs der VM auf demselben NUMA-Knoten sitzen. Das allein kann auf Systemen mit mehreren Sockeln 20–30 % Durchsatzunterschied ausmachen.\nASPM aus — pcie_aspm=off in die Kernel-Kommandozeile des Hosts. Beseitigt Latenzzittern durch Wechsel der PCIe-Link-Energiezustände.\nRealistische Queue-Tiefen — teste mit iodepth=32 oder höher, nicht mit iodepth=1. Der IOMMU-Overhead, der bei niedrigen Queue-Tiefen dominiert, verteilt sich bei realistischen Tiefen.\nPosted Interrupts — prüfe, ob APICv (Intel) oder AVIC (AMD) aktiv ist. Senkt den Overhead pro Interrupt von Mikrosekunden auf Nanosekunden.\nMPS optimieren — pci=pcie_bus_perf in die Kernel-Kommandozeile des Hosts. Setzt MaxPayloadSize auf das Maximum, das die Topologie hergibt.\nEnergieverwaltung von vfio-pci — disable_idle_d3=1 ergänzen, wenn dein NVMe-Controller beim Passthrough Probleme mit Energiezuständen hat.\nEine kombinierte Kernel-Kommandozeile für einen Proxmox-Knoten mit NVMe-Passthrough auf einem AMD-EPYC-System sähe etwa so aus:\nGRUB_CMDLINE_LINUX_DEFAULT=\u0026#34;quiet amd_iommu=on iommu=pt pcie_aspm=off pci=pcie_bus_perf\u0026#34; Für Intel:\nGRUB_CMDLINE_LINUX_DEFAULT=\u0026#34;quiet intel_iommu=on iommu=pt pcie_aspm=off pci=pcie_bus_perf\u0026#34; Wann Passthrough sich nicht lohnt Bevor du diesen Weg gehst, lohnt die Frage, ob du NVMe-Passthrough überhaupt brauchst.\nVirtIO-SCSI und VirtIO-BLK mit einer virtuellen Platte auf NVMe sind schon sehr effizient. Der Overhead gegenüber Passthrough liegt bei der Latenz typisch bei 5–10 %. Der Unterschied im Durchsatz ist für die meiste Arbeit zu vernachlässigen.\nPassthrough ist sinnvoll, wenn das Gast-Betriebssystem das Gerät direkt verwalten soll. Dazu gehören SMART-Überwachung, Firmware-Aktualisierungen, Steuerung von TRIM und Discard und bestimmte NVMe-Funktionen wie Reservierungen. Es ist auch sinnvoll für latenzempfindliche Arbeit, bei der schon ein paar Mikrosekunden zählen. Bestimmte Datenbank-Engines und Echtzeit-Datenannahme fallen darunter.\nFür alles andere wiegen die betrieblichen Abwägungen von oben — keine Live-Migration, keine Anbindung an Snapshots und Sicherungen — den kleinen Leistungsgewinn meist auf.\nEs ist nichts Kluges daran, den härteren Weg zu wählen, wenn der leichtere die Arbeit tut.\nDeine Änderungen prüfen Prüf nach den Tuning-Schritten, ob alles wie erwartet läuft:\n# Host side — confirm IOMMU is in passthrough mode dmesg | grep -i iommu # Confirm ASPM is disabled lspci -vv | grep -i \u0026#34;ASPM Disabled\u0026#34; # Check MPS on the NVMe controller lspci -vv -s XX:00.0 | grep MaxPayload # Inside the VM — run the fio comparison fio --name=randread --ioengine=libaio --direct=1 --bs=4k \\ --iodepth=32 --numjobs=4 --rw=randread --size=1G \\ --filename=/dev/nvme0n1 --runtime=30 --time_based \\ --group_reporting Vergleiche die Ergebnisse aus der VM mit deiner früheren Grundlinie auf Blech. Bei iodepth=32 solltest du einen Durchsatz innerhalb von 5 % des Blechwerts sehen. Die Mittelwerte der Completion-Latenz sollten innerhalb von 10–15 µs der Host-Zahlen liegen. Ist der Abstand noch groß, prüf zuerst die NUMA-Ausrichtung. Sie ist der am häufigsten übersehene Punkt. Und sie kostet nichts als eine Änderung in der Konfiguration, was sie zur besten Sorte übrig gebliebenes Problem macht.\nQuellen PCI-Dokumentation des Linux-Kernels — Optionen zum Tuning von MPS und MRRS — die maßgebliche Quelle für pcie_bus_perf, pcie_bus_safe und verwandte Parameter Proxmox VE Administration Guide — PCI(e) Passthrough — die offizielle Proxmox-Dokumentation zur Konfiguration von VFIO-Gerätedurchgriff Proxmox-Forum — NVMe Passthrough Performance — die Diskussion aus der Gemeinschaft, die zu diesem Beitrag geführt hat ","permalink":"https://blogs.damiendye.uk/de/proxmox/pcie-passthrough-performance-the-iommu-tax/","summary":"Warum PCIe-Geräte Durchsatz verlieren, wenn man sie über VFIO an eine VM durchreicht, und die praktischen Schritte, die den größten Teil davon zurückholen.","title":"PCIe-Passthrough-Leistung auf Proxmox VE — die IOMMU-Steuer und wie man sie klein hält"},{"content":"Was NUMA ist NUMA steht für Non-Uniform Memory Access, also ungleichmäßigen Speicherzugriff. Auf einem System mit einem Sockel greift jeder CPU-Kern über denselben Speichercontroller auf den ganzen Arbeitsspeicher des Systems zu. Die Zugriffszeit ist gleich, egal welcher Kern fragt und wo die Daten im physischen Speicher liegen.\nAuf einem System mit mehreren Sockeln hat jeder CPU-Sockel seinen eigenen Speichercontroller und seine eigene Bank RAM. Ein Kern auf Sockel 0 kommt schnell an das RAM, das an Sockel 0 hängt — das ist lokaler Speicher. Er kommt auch an das RAM an Sockel 1, aber diese Anforderung muss über die Verbindung zwischen den Sockeln (Intel UPI, AMD Infinity Fabric). Das ist entfernter Speicher, und der ist langsamer.\nDer Kernel nennt jeden Sockel samt seinem lokalen Speicher einen NUMA-Knoten. Ein AMD-EPYC-System mit zwei Sockeln hat mindestens zwei NUMA-Knoten. Manche EPYC-Prozessoren zeigen vier NUMA-Knoten pro Sockel (einen pro CCD), was auf einer Platine mit zwei Sockeln acht Knoten ergibt.\nDer Leistungsunterschied zwischen lokalem und entferntem Speicherzugriff ist nicht subtil. Lokaler Zugriff liegt bei etwa 80–100 ns. Entfernter Zugriff liegt bei etwa 130–200 ns. Das sind 50–100 % Aufschlag pro Speicheroperation. Für sich genommen ist das eine sehr kleine Zahl. Bei jedem Speicherzugriff über die Lebensdauer der VM bezahlt, hört sie auf, klein zu sein.\nWarum es für Virtualisierung zählt Wenn Proxmox eine VM anlegt, weist es vCPUs und RAM zu. Standardmäßig können diese vCPUs auf jedem physischen Kern auf jedem Sockel eingeplant werden. Das RAM der VM kann aus dem Speicherpool jedes NUMA-Knotens kommen.\nLegt der Scheduler eine vCPU auf Sockel 0 und liegt das RAM der VM auf Sockel 1, überquert jeder Speicherzugriff dieser vCPU die Verbindung zwischen den Sockeln. Springen die vCPUs zwischen den Sockeln — und das tun sie, wenn sie nicht angepinnt sind —, wird das Zugriffsmuster ein Durcheinander. Manche Zugriffe sind lokal, manche entfernt, und die Leistung der VM zittert entsprechend.\nFür allgemeine Lasten — ein Webserver, ein Fileserver, eine Desktop-VM — ist das oft erträglich. Der Overhead ist da, verteilt sich aber über viele Operationen und dominiert nicht.\nFür IO-lastige Arbeit — Datenbanken, Storage-Server, alles mit schwerem Disk- oder Netzwerk-IO — wächst der Aufschlag zusammen. Jede DMA-Fertigmeldung, jede Interrupt-Zustellung, jedes Kopieren eines Puffers geht über den Speicher. Überqueren diese Zugriffe die Sockel, summiert sich der Overhead schnell.\nWarum es beim Passthrough zählt PCIe-Geräte sind physisch an einen bestimmten CPU-Sockel verdrahtet. Jeder Sockel hat seinen eigenen PCIe-Root-Complex. Das NVMe-Laufwerk in Slot 3 hängt vielleicht an den PCIe-Lanes von Sockel 0. Die GPU in Slot 5 vielleicht an denen von Sockel 1.\nWenn ein Gerät DMA macht, landen die Daten im Speicher, der an dem NUMA-Knoten hängt, auf den die IOMMU sie abbildet. Kommt das RAM der VM aus dem lokalen Knoten des Geräts, geht der DMA-Schreibvorgang direkt in den lokalen Speicher. Liegt das RAM auf dem anderen Knoten, überquert jede DMA-Operation die Verbindung zwischen den Sockeln.\nFür ein NVMe-Laufwerk mit hunderttausenden IOPS summieren sich diese 50–100 ns pro Operation. Bei iodepth=32 mit zufälligen 4-KB-Lesezugriffen kann der Durchsatzunterschied zwischen ausgerichtetem und fehlausgerichtetem NUMA 20–30 % betragen. Und das, bevor du auf IOMMU-Overhead, ASPM, MPS oder irgendwas anderes geschaut hast.\nFehlausgerichtetes NUMA schickt jeden DMA über die Verbindung zwischen den Sockeln, ausgerichtetes hält ihn lokal Fehlausgerichtet — die VM auf Knoten 0, das Laufwerk auf Knoten 1 NUMA-Knoten 0 Kerne 0–15 RAM 128 GB VM: vCPUs auf 0–15 gepinnt, RAM von hier NUMA-Knoten 1 Kerne 16–31 RAM 128 GB NVMe — Root Complex 1 UPI / IF jeder DMA überquert die Verbindung — 130–200 ns Ausgerichtet — vCPUs, RAM und Laufwerk alle auf Knoten 1 NUMA-Knoten 0 Kerne 0–15 RAM 128 GB frei für andere VMs NUMA-Knoten 1 Kerne 16–31 RAM 128 GB NVMe — Root Complex 1 VM: affinity 16-31, numa0 hostnodes=1, policy=bind ungenutzt 80–100 ns Bei iodepth=32 mit zufälligen 4-KB-Lesezugriffen sind es zwischen diesen beiden 20–30 % Durchsatz — und das, bevor IOMMU-Overhead, ASPM oder MPS ins Spiel kommen. Auf einem System mit einem Sockel gibt es keinen zweiten Knoten und keine Verbindung dazwischen, also gilt hiervon nichts. Beide Male dieselbe Hardware. Der einzige Unterschied ist, auf welchen Knoten die VM gepinnt wurde — und ob der DMA des Laufwerks die Verbindung überqueren muss, um an den Speicher der VM zu kommen. Dasselbe gilt für Netzwerkkarten, GPUs und jedes andere durchgereichte Gerät. Der DMA-Verkehr des Geräts sollte im lokalen Speicher landen, und die vCPUs, die diesen Verkehr verarbeiten, sollten auf demselben Knoten sitzen.\nWie du deine Topologie prüfst Herausfinden, auf welchem NUMA-Knoten ein Gerät sitzt # Replace 0000:XX:00.0 with your device\u0026#39;s PCI address from lspci cat /sys/bus/pci/devices/0000:XX:00.0/numa_node Das gibt die Nummer des NUMA-Knotens zurück. Kommt -1 zurück, konnte der Kernel den Knoten nicht bestimmen. Das passiert manchmal bei Geräten hinter bestimmten PCIe-Switches. Verfolge in diesem Fall die PCIe-Topologie mit lspci -tv von Hand und ordne den Root Port dem Sockel zu.\nDas ganze NUMA-Layout ansehen numactl --hardware Das zeigt dir jeden NUMA-Knoten, wie viele CPU-Kerne darauf sitzen, wie viel Speicher daran hängt und die Distanz (die relativen Kosten) zwischen den Knoten.\nBeispielausgabe von einem EPYC-System mit zwei Sockeln:\navailable: 2 nodes (0-1) node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 node 0 size: 131072 MB node 1 cpus: 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 node 1 size: 131072 MB node distances: node 0 1 0: 10 32 1: 32 10 Die Knoten-Distanztabelle von numactl --hardware lesen Die Distanztabelle von\u0026#160;numactl --hardware Zwei Sockel, 2 NUMA-Knoten pro Sockel. Relative Kosten, keine Nanosekunden. Kn. 0 Kn. 1 Kn. 2 Kn. 3 Kn. 0 Kn. 1 Kn. 2 Kn. 3 10 16 32 32 16 10 32 32 32 32 10 16 32 32 16 10 Sockel 0 Sockel 1 10 — der Knoten selbst, lokaler Speicher 16 — derselbe Sockel, der andere Knoten 32 — über die Verbindung zwischen den Sockeln Pinn eine VM und ihr Gerät in eine einzige 10, und lass ihren Speicher nie auf einer 32 landen. Eine Platine mit 2 Knoten zeigt nur 10 und 32; die 16er kommen erst, wenn ein Sockel mehrere Knoten zeigt. Die Zahlen sind relative Kosten, keine Nanosekunden. Halte eine VM und ihr Gerät innerhalb einer einzigen 10, und lass ihren Speicher nie auf einer 32 landen. Die Distanztabelle nennt dir die relativen Kosten. 10 ist lokal. 32 ist entfernt. Höhere Zahlen heißen mehr Sprünge. Bei EPYC-Aufbauten mit vier Knoten pro Sockel haben manche Knotenpaare eine Distanz von 32 und andere von 16, je nachdem, auf welchem CCD sie sitzen.\nGeräte den Knoten zuordnen # List all PCI devices and their NUMA nodes for dev in /sys/bus/pci/devices/*; do node=$(cat \u0026#34;$dev/numa_node\u0026#34; 2\u0026gt;/dev/null) echo \u0026#34;$(basename $dev) node=$node $(lspci -s $(basename $dev) 2\u0026gt;/dev/null | cut -d\u0026#39; \u0026#39; -f2-)\u0026#34; done Das gibt dir ein vollständiges Bild davon, welche Geräte auf welchen Knoten sitzen. Halte Ausschau nach deinen NVMe-Controllern, Netzwerkkarten und allen GPUs, die du durchreichst.\nWie man eine VM in Proxmox ausrichtet vCPUs auf den richtigen Knoten pinnen In der Konfigurationsdatei der VM (/etc/pve/qemu-server/\u0026lt;vmid\u0026gt;.conf):\nnuma: 1 affinity: 0-15 # Adjust to match cores on the correct NUMA node Der Parameter affinity pinnt die vCPUs der VM auf bestimmte physische Kerne. Setz ihn auf den Bereich der Kerne, die auf demselben NUMA-Knoten sitzen wie dein durchgereichtes Gerät.\nSitzt dein NVMe auf Knoten 1 und hat Knoten 1 die Kerne 16–31, dann setz affinity: 16-31. Braucht die VM nur 8 vCPUs, pinn auf eine Teilmenge: affinity: 16-23.\nSpeicher vom richtigen Knoten zuweisen numa: 1 in der VM-Konfiguration sagt Proxmox, der VM eine NUMA-Topologie zu zeigen. QEMU wird dann versuchen, den Speicher der VM von dem NUMA-Knoten zu nehmen, auf den die vCPUs gepinnt sind.\nFür ausdrückliche Kontrolle kannst du die NUMA-Topologie in der VM-Konfiguration setzen:\nnuma0: cpus=0-7,hostnodes=0,memory=16384,policy=bind Das sagt QEMU, den ersten NUMA-Knoten der VM (aus Sicht des Gasts Knoten 0) an den NUMA-Knoten 0 des Hosts zu binden, mit den Kernen 0–7 und 16 GB Speicher. Das policy=bind stellt sicher, dass der Speicher strikt von diesem Knoten kommt und nicht auf andere Knoten ausweicht, wenn der lokale Pool unter Druck steht.\nDas Pinnen prüfen Nachdem die VM gestartet ist, prüfen, ob die vCPUs wirklich dort laufen, wo du sie erwartest:\n# Find the QEMU process pgrep -a qemu | grep \u0026lt;vmid\u0026gt; # Check CPU affinity of the process taskset -cp \u0026lt;pid\u0026gt; # Or check per-vCPU thread affinity for tid in $(ls /proc/\u0026lt;pid\u0026gt;/task/); do echo \u0026#34;Thread $tid: $(taskset -cp $tid 2\u0026gt;/dev/null)\u0026#34; done Häufige Fehler Überhaupt nicht pinnen Setzt du affinity nicht, können die vCPUs der VM auf jedem Kern eingeplant werden. Der Scheduler des Kernels wird sie zum Lastausgleich zwischen den Knoten verschieben. Jedes Mal, wenn eine vCPU von einem Knoten auf einen anderen wandert, werden alle Daten, mit denen sie im Cache des alten Knotens gearbeitet hat, entfernt.\nFür allgemeine VMs ist das hinnehmbar. Für Passthrough-VMs mit schwerem IO nicht.\nAuf den falschen Knoten pinnen Prüfe den NUMA-Knoten des Geräts, bevor du pinnst. Nimm nichts an. Auf manchen Mainboards passt die physische Numerierung der Slots nicht auf einleuchtende Weise zur Zuordnung der NUMA-Knoten. Prüf es immer mit cat /sys/bus/pci/devices/.../numa_node.\nEinen Knoten überbuchen Pinnst du zu viele VMs auf denselben NUMA-Knoten, werden die Kerne dieses Knotens überbucht und der lokale Speicherpool geht zu Ende. Wenn der Speicher auf den entfernten Knoten überläuft, hast du das Schlechteste von beidem: gepinnte vCPUs mit entferntem Speicher.\nVerteile deine VMs im Gleichgewicht über die Knoten. Hast du zwei NUMA-Knoten und vier VMs, verteile sie gleichmäßig.\nDie Speicherzuweisung vergessen vCPUs zu pinnen, ohne auch die Speicherzuweisung zu steuern, bringt dir die Hälfte des Nutzens. Die vCPUs sitzen auf dem richtigen Knoten, der Speicher vielleicht nicht. Nutze policy=bind oder mindestens numa: 1, damit QEMUs Zuweisung dem CPU-Pinning folgt.\nSysteme mit einem Sockel Auf einem System mit einem Sockel sitzt alles auf NUMA-Knoten 0. Es gibt nur einen Speichercontroller und einen Satz PCIe-Lanes. NUMA-Ausrichtung ist kein Thema.\nDu kannst numa: 1 trotzdem in der VM-Konfiguration setzen — es schadet nicht —, aber es hilft auch nicht. Ein Sockel, ein Speichercontroller, nichts auszurichten. Spar die Mühe für eine Kiste, die zwei hat. Damit gelten die hier beschriebenen Leistungsgewinne nur für Systeme mit mehreren Sockeln, bei denen es die Verbindung zwischen den Sockeln überhaupt gibt.\nQuellen Proxmox VE Administration Guide — CPU and NUMA Configuration — die offizielle Dokumentation zu vCPU-Pinning und NUMA-Optionen NUMA-Dokumentation des Linux-Kernels — Referenz zur Speicherpolitik im Kernel AMD EPYC 7003 Series — BIOS \u0026amp; Workload Tuning Guide (Dokument 58002) — AMDs Dokumentation zu NUMA pro Sockel und zur CCD-/CCX-Topologie ","permalink":"https://blogs.damiendye.uk/de/proxmox/numa-alignment-proxmox/","summary":"Auf Systemen mit mehreren Sockeln verliert eine VM, deren vCPUs auf einem NUMA-Knoten und deren durchgereichtes Gerät auf einem anderen sitzt, 20–30 % Durchsatz, bevor du sonst irgendwo hingeschaut hast.","title":"NUMA-Ausrichtung auf Proxmox VE — warum sie zählt und wie man sie richtig hinbekommt"},{"content":"Was ASPM macht PCIe Active State Power Management (ASPM) erlaubt PCIe-Links, in Zustände mit geringer Leistung zu gehen, wenn sie unbeschäftigt sind. Die PCIe-Spezifikation legt mehrere Link-Zustände fest:\nL0 ist der voll aktive Zustand. Der Link steht, beide Enden sind versorgt, Daten können sofort fließen.\nL0s ist ein leichter Ruhezustand. Der Link fährt teilweise herunter. Die Rückkehr nach L0 dauert je nach Hardware etwa 1–4 µs. Beide Enden können unabhängig voneinander in L0s gehen.\nL1 ist ein tieferer Ruhezustand. Beide Enden des Links fahren gemeinsam herunter. Die Rückkehr nach L0 dauert länger — typisch 2–32 µs, manchmal mehr. Die genaue Rückkehrzeit hängt vom Gerät, der PCIe-Generation und der Plattform ab.\nL1.1 und L1.2 sind Unterzustände von L1, eingeführt mit PCIe 3.0. Sie senken die Leistung weiter, indem sie die PLL-Taktreferenz abschalten. Die Rückkehr aus L1.2 kann 32–100 µs dauern. Für ein Speichergerät ist das kein Rundungsfehler. Das ist etwa so lang wie der Lesezugriff, den du überhaupt machen wolltest.\nJe tiefer der Link schläft, desto länger wartet das nächste IO Link-Zustand Rückkehrzeit nach L0 — die Latenz, die ein IO zahlt, wenn es jetzt eintrifft L0 voll aktiv — Daten fließen sofort keine L0s leichte Ruhe, jedes Ende für sich 1–4 µs L1 tiefe Ruhe, beide Enden zusammen 2–32 µs L1.1 / L1.2 PCIe-3.0-Unterzustände — PLL-Takt aus 32–100 µs Balken maßstäblich gegen den schlimmsten Fall von 100 µs. Tieferer Schlaf spart mehr Leistung und kostet mehr beim Aufwachen. Die Balken sind die Rückkehrzeiten, maßstäblich gegen den schlimmsten Fall von 100 µs gezeichnet. Tieferer Schlaf spart mehr Leistung und kostet mehr, wenn der Verkehr wieder anläuft. Die Idee ist geradeheraus. Ist ein PCIe-Link ein paar Mikrosekunden unbeschäftigt, versetze ihn in einen Zustand mit geringerer Leistung. Läuft der Verkehr wieder an, wecke ihn auf. Spare in der Zwischenzeit ein wenig Strom.\nAuf einem Laptop oder einem Desktop, der die meiste Zeit nichts tut, spart ASPM echten Strom. Ein paar Watt pro Link, aufsummiert über alle PCIe-Geräte im System. Auf einem Server mit IO-lastiger Arbeit sind die Links selten lang genug unbeschäftigt, dass ASPM sinnvoll greift.\nWarum es beim Passthrough Probleme macht Auf Blech verhandeln das Betriebssystem und der Gerätetreiber die Energieverwaltung miteinander. Der NVMe-Treiber weiß, wann der Link gleich unbeschäftigt wird und wann er gleich neues IO abschickt. Das PCIe-Subsystem des Kernels stimmt die Wechsel der Link-Zustände mit dem Treiber ab. Alles läuft im Gleichtakt.\nUnter VFIO-Passthrough bricht diese Abstimmung zusammen.\nDer Host-Kernel steuert weiterhin den physischen PCIe-Link. Die Gast-VM besitzt das Gerät über VFIO, aber sie steuert den Link selbst nicht. Das PCIe-Subsystem des Hosts sieht den Link unbeschäftigt werden — denn aus Sicht des Hosts nutzt ihn kein Treiber auf der Host-Seite. Es versetzt den Link in einen Zustand mit geringer Leistung. Wenn der Gast IO abschickt, braucht das Gerät den Link zurück in L0. Die Rückkehrzeit taucht als zusätzliche Latenz auf dieser IO-Operation auf.\nDas Ergebnis ist ungleichmäßige Latenz. Die meisten IOs werden mit normaler Geschwindigkeit fertig. Manche brauchen viel länger, weil sie auf einen Link treffen, der in L1 oder L1.2 liegt und erst aufwachen muss. Das zeigt sich als weite Streuung in deinen clat-Perzentilen (Completion Latency). Der Durchschnitt sieht vielleicht in Ordnung aus. Das p99 ist vielleicht 5- bis 10-mal höher.\nDas ist schwer zu erkennen, weil die Zahlen für den Durchsatz in Ordnung aussehen können. Du siehst das Problem nur, wenn du auf die Latenz am Ausläufer schaust. Viele Benchmarks heben sie nicht hervor, solange du keine Perzentile anforderst.\nASPM lässt den Durchschnitt unberührt und zerstört den Ausläufer ASPM an pcie_aspm=off Completion-Latenz (µs) 0 30 60 90 120 3× schlechter bei p99 — und 7× der eigene Durchschnitt ASPM an pcie_aspm=off p50 p90 p99 p99.9 p99.99 Durchschnitt und p50 sind in beiden Durchläufen identisch — nur der Ausläufer trennt sie. Die Zahlen zeigen das Muster, sie sind keine Messungen an einem bestimmten Laufwerk. Dasselbe Laufwerk mit und ohne ASPM. p50 ist identisch, ein Benchmark, der nur den Durchschnitt zeigt, meldet also überhaupt kein Problem; der Schaden liegt komplett hinter p90, wo sich die IOs sammeln, die auf einen schlafenden Link getroffen sind. Der VFIO-eigene Haken Es gibt hier einen Haken, der über das einfache Problem „Host und Gast streiten um den Link-Zustand“ hinausgeht.\nIst ein Gerät auf dem Host an vfio-pci gebunden, weiß der Host-Kernel, dass das Gerät im Passthrough-Modus ist. Aber die ASPM-Politik gilt auf Ebene des Links, nicht auf Ebene des Geräts. Die ASPM-Politik des Hosts gilt weiterhin für den physischen Link, weil der Host weiterhin die PCIe-Topologie besitzt.\nVFIO fängt ASPM-Wechsel nicht ab und überschreibt sie nicht. Es reicht den BAR-Bereich und die Interrupts des Geräts durch, aber die Energieverwaltung des Links bleibt in der Hand des Hosts. Der Gast hat keinen Weg, dem Host zu sagen „halte diesen Link in L0“.\nDer Gast besitzt das Gerät, der Host besitzt weiterhin den Link — und es gibt keinen Kanal dazwischen Gast-VM NVMe-Treiber besitzt das Gerät, schickt das IO ab Host-Kernel PCIe-Subsystem ASPM-Politik vfio-pci D-Zustands-Politik kein Weg zu sagen „Link in L0 halten“ physischer PCIe-Link — in L1, schlafend das entscheidet der Host, nicht der Gast Host sieht keinen Treiber, also lässt er den Link schlafen Gast schickt IO ab und erwartet L0 dieses IO wartet, bis der Link aufwacht — 2–32 µs, aus L1.2 bis zu 100 µs VFIO reicht BAR-Bereich und Interrupts durch. Die Energieverwaltung des Links gehört nicht dazu. Die meisten IOs treffen den schlafenden Link gar nicht, deshalb bewegt sich nur der Ausläufer. Die Trennung, die es verursacht: der Gast besitzt das Gerät und schickt das IO ab, der Host besitzt den Link und entscheidet, wann er schläft, und nichts verbindet die beiden. Manche neuere Hardware und manche Kernel-Versionen kommen damit besser zurecht als andere. Damit ist der sicherste Weg, ASPM ganz aus dem Bild zu nehmen.\nWie man es abschaltet Füge pcie_aspm=off zur Kernel-Kommandozeile des Hosts hinzu:\n# Edit /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT=\u0026#34;quiet pcie_aspm=off\u0026#34; # Update GRUB and reboot update-grub reboot Das verhindert, dass der Host irgendeinen PCIe-Link in einen Zustand mit geringer Leistung versetzt. Es gilt global. Jedes PCIe-Gerät auf dem Host, nicht nur das durchgereichte.\nNach dem Neustart prüfen:\n# Should show \u0026#34;ASPM Disabled\u0026#34; for all devices lspci -vv | grep -i \u0026#34;ASPM\u0026#34; Was es an Strom kostet ASPM abzuschalten erhöht den Stromverbrauch im Ruhezustand. Jeder PCIe-Link, der sonst in L1 wäre, bleibt in L0 und zieht ein paar hundert Milliwatt mehr. Über ein System mit zehn oder fünfzehn PCIe-Geräten kommen so 2–5 Watt im Ruhezustand zusammen.\nFür einen Server im Rechenzentrum sind 2–5 Watt ein Rundungsfehler auf der Stromrechnung. Für ein Homelab sind sie ein Bruchteil dessen, was CPU und Speicher ziehen. Für einen Laptop zählen sie. Aber VFIO-Passthrough würdest du auf einem Laptopakku auch nicht machen.\nDer Handel ist klar. Ein paar Watt im Ruhezustand gegen unvorhersehbare Latenzspitzen auf deinen durchgereichten Geräten. Auf jedem System mit Passthrough sollte ASPM aus sein.\nProbleme mit Energiezuständen auf Geräteebene ASPM steuert den Energiezustand des PCIe-Links. Geräte haben auch ihre eigene Energieverwaltung — die PCIe-D-Zustände (D0 bis D3).\nIst ein Gerät in D3 (vollständig heruntergefahren), schläft nicht nur der Link. Das Gerät selbst hat angehalten. Unter VFIO-Passthrough kann der vfio-pci-Treiber des Hosts das Gerät in D3 versetzen, wenn die VM nicht läuft oder wenn die Energiepolitik des Hosts das Gerät für unbeschäftigt hält.\nManche NVMe-Controller kommen mit dem Wechsel von D3 zurück nach D0 nicht sauber zurecht. Sie kommen nicht sauber wieder, der Gast verliert das Gerät, und der einzige Ausweg ist ein Neustart der VM oder manchmal ein Neustart des Hosts.\nDie Samsung 990 EVO Plus ist ein bekannter Übeltäter. Die Lösung ist die Modul-Option disable_idle_d3 für vfio-pci:\n# /etc/modprobe.d/vfio.conf options vfio-pci disable_idle_d3=1 Das verhindert, dass vfio-pci ein gebundenes Gerät im Ruhezustand in D3 versetzt. Wie pcie_aspm=off ist es eine globale Einstellung. Jedes an vfio-pci gebundene Gerät bleibt in D0. Beim Passthrough ist das meist genau, was du willst, denn dort sollte der Gast das Einzige sein, was den Energiezustand des Geräts steuert.\nDie Option disable_idle_d3 hat mit ASPM nichts zu tun. ASPM steuert den Link. D3 steuert das Gerät. Beide können unabhängig voneinander Probleme machen. Für eine saubere Passthrough-Konfiguration schalte beide ab.\nASPM pro Gerät steuern Willst du ASPM nicht global abschalten — vielleicht hast du andere PCIe-Geräte auf dem Host, die von der Stromsparfunktion profitieren —, kannst du ASPM pro Link über sysfs steuern:\n# Find the link\u0026#39;s ASPM policy cat /sys/bus/pci/devices/0000:XX:00.0/link/l1_aspm # Disable ASPM for a specific link echo 0 \u0026gt; /sys/bus/pci/devices/0000:XX:00.0/link/l1_aspm Das ist zielgenauer, aber über Neustarts und Kernel-Aktualisierungen hinweg weniger verlässlich. Für die meisten Passthrough-Aufbauten ist das globale Kernel-Flag pcie_aspm=off einfacher und vorhersehbarer.\nWenn ASPM nicht das Problem ist Nicht jedes Latenzzittern ist ASPM.\nSind deine clat-Perzentile durchgehend hoch (nicht nur am Ausläufer), liegt das Problem eher an Overhead der IOMMU-Übersetzung, an NUMA-Fehlausrichtung oder an einer MPS-Fehlanpassung. ASPM erzeugt speziell ein zweigipfliges Muster — die meisten IOs sind schnell, ein paar sind langsam —, weil es nur die IOs trifft, die zufällig eintreffen, während der Link in einem Zustand mit geringer Leistung liegt.\nPrüf auf ASPM zuerst, wenn du siehst:\np99-Latenz 5-mal oder mehr über dem Durchschnitt ungleichmäßige fio-Ergebnisse zwischen Durchläufen Latenz, die unter Dauerlast besser wird und bei stoßweiser Arbeit schlechter Ist die Latenz unabhängig vom Lastmuster durchgehend schlecht, schau woanders. ASPM ist es wert, früh ausgeschlossen zu werden, weil es billig zu testen ist. Es ist aber nicht die Antwort auf jeden langsamen Link, und ihm hinterherzujagen, wenn die Zahlen nicht zum Muster passen, ist ein Nachmittag, den du nicht zurückbekommst.\nQuellen PCI-Dokumentation des Linux-Kernels — ASPM-Parameter — Kernel-Quelltext zu pcie_aspm=off und verwandten Optionen Proxmox-Forum — PCI Passthrough NVMe Unable to Change Power State — Thread aus der Gemeinschaft zu disable_idle_d3 für Samsung-NVMe-Controller Proxmox-VE-Wiki — PCI(e) Passthrough — die offizielle Dokumentation zur Passthrough-Konfiguration ","permalink":"https://blogs.damiendye.uk/de/proxmox/pcie-aspm-passthrough/","summary":"Active State Power Management spart auf unbeschäftigten PCIe-Links ein paar Watt. Unter VFIO-Passthrough erzeugt es Latenzzittern, das schwer zu diagnostizieren und leicht zu beheben ist.","title":"PCIe-ASPM, und warum du es für Passthrough abschalten solltest"},{"content":"Was MPS ist PCIe-Geräte übertragen Daten in Paketen namens Transaction Layer Packets (TLPs). Jedes TLP hat einen Header und eine Payload. Die maximale Größe dieser Payload ist die MaxPayloadSize (MPS).\nMPS wird beim Link-Training zwischen einem Gerät und seiner vorgelagerten Bridge verhandelt. Der verhandelte Wert ist der kleinere von dem, was das Gerät kann, und dem, was die Bridge zulässt. Jede Bridge und jeder Switch auf dem Weg zwischen Gerät und Root Complex hat seine eigene MPS-Fähigkeit. Die endgültige MPS eines Geräts wird von der engsten Stelle der Kette bestimmt.\nÜbliche MPS-Werte sind 128, 256 und 512 Byte. Manche Geräte können 1024 oder sogar 4096 Byte, aber in der Praxis sind 256 oder 512 typisch für NVMe-Controller und Netzwerkkarten. GPUs können oft 256 Byte.\nWarum es zählt Größere MPS heißt weniger Pakete für dieselbe Datenmenge. Ein 4-KB-IO braucht bei MPS 128 32 TLPs. Dieselbe Übertragung braucht bei MPS 512 8 TLPs.\nJedes TLP trägt Protokoll-Overhead — Header, CRC, Framing. Weniger TLPs heißt weniger Protokoll-Overhead pro übertragenem Byte. Bei hohem Durchsatz ist dieser Unterschied messbar. Nicht dramatisch. Aber echt. Und es ist derselbe Overhead, der bei jedem Paket anfällt.\nMPS wirkt sich auch darauf aus, wie gut der PCIe-Link genutzt wird. Kleinere Payloads heißen, dass der Link mehr Zeit mit Headern statt mit Daten verbringt. Größere Payloads verschieben das Verhältnis zu den nützlichen Daten.\nDieselben 4 KB Payload kosten 32 Paket-Header bei MPS 128 und 8 bei MPS 512 MPS 128 — eine 4-KB-Übertragung wird zu 32 TLPs 32 Header × ≈24 B —\u0026#160;≈16 % der Bytes auf der Leitung sind Protokoll-Overhead MPS 512 — dieselben 4 KB werden zu 8 TLPs 8 Header × ≈24 B —\u0026#160;≈4 % der Bytes auf der Leitung sind Protokoll-Overhead Header, Sequenznummer, CRC und Framing Payload Beide Streifen tragen dieselben 4 KB. Größere Payloads bewegen nicht mehr Daten — sie verbrauchen weniger Link, um sie zu beschreiben. Der Gewinn ist gemessen klein. Beide Streifen tragen dieselben 4 KB. Die gefüllten Balken sind die Header pro Paket — bei MPS 128 sind es 32, bei MPS 512 nur 8. Die Wirkung auf die Latenz ist geringer als die auf den Durchsatz. Ein einzelner 4-KB-Lesezugriff zeigt zwischen MPS 128 und 512 keinen Latenzunterschied, der das Messen wert wäre, denn die TLPs laufen in einer Pipeline. Fährt man aber hohe IOPS mit vielen gleichzeitigen Übertragungen, summiert sich der geringere Overhead größerer MPS.\nDas Problem beim Passthrough Auf Blech setzt das BIOS die MPS während des POST anhand der PCIe-Topologie. Ein modernes Server-BIOS setzt MPS meist auf das Maximum, das die Topologie hergibt, üblicherweise 256 oder 512 Byte.\nUnter QEMU hat der Root Complex des virtuellen Q35-Chipsatzes seine eigene MPS-Fähigkeit. Standardmäßig gibt er eine niedrige MPS an. Die Standard-MPS-Politik des Linux-Kernels (pcie_bus_default) setzt die MPS jedes Geräts auf die seiner übergeordneten Bridge, was in einer virtuellen Topologie der Standardwert des QEMU-Root-Complex ist. Oft 128 Byte.\nDamit läuft ein Gerät, das 512-Byte-Payloads könnte, mit 128, weil der virtuelle Root Complex die Obergrenze gesetzt hat.\nMPS wird von der engsten Stelle auf dem Weg gesetzt, und unter QEMU ist das der virtuelle Root Complex Blech — das BIOS setzt MPS aus der echten Topologie NVMekann 512 PCIe-Switchlässt 512 zu Root Complexlässt 512 zu MPS = 512 B der kleinste auf dem Weg In eine VM durchgereicht — der virtuelle Root Complex ist jetzt die engste Stelle NVMekann 512 Virtueller QEMU-Q35-Root-Complex gibt standardmäßig 128 an MPS = 128 B Gerätefähigkeit ungenutzt Host-Kernel mit\u0026#160;pci=pcie_bus_perf NVMekann 512 jedes Gerät auf das Maximum seines Busses MRRS passend erhöht MPS = 512 B auf dem Host setzen, nicht im Gast MPS ist der kleinste Wert auf dem Weg. Ein Gerät durchzureichen schiebt den virtuellen Root Complex in diesen Weg, und dessen vorsichtiger Standardwert wird zur Obergrenze für alle. Wie man es behebt — auf der Host-Seite Sag dem Kernel, er soll die MPS auf das Maximum setzen, das der übergeordnete Bus jedes Geräts hergibt:\n# Add to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub pci=pcie_bus_perf Das setzt die MPS jedes Geräts auf den größten Wert, den sein übergeordneter Bus zulässt. Es setzt außerdem die MRRS (Max Read Request Size) entsprechend. Der Kernel-Quelltext sagt, er stelle sicher, dass die MPS eines Geräts nicht größer ist als die des übergeordneten. Das hält die Kette konsistent und holt gleichzeitig die besten Übertragungsgrößen heraus.\nNach dem Neustart die neue MPS prüfen:\n# Check MPS on a specific device lspci -vv -s XX:00.0 | grep -i \u0026#34;MaxPayload\u0026#34; Du solltest MaxPayload 256 bytes oder MaxPayload 512 bytes sehen statt der voreingestellten 128.\nDie anderen Kernel-Optionen Der Kernel bietet vier MPS-Politiken, jede über den Boot-Parameter pci= gesetzt:\npcie_bus_tune_off — MPS überhaupt nicht anfassen. Nimm, was das BIOS gesetzt hat. Auf Blech mit einem guten BIOS ist das oft in Ordnung. Unter QEMU ist das BIOS OVMF oder SeaBIOS, und die optimieren MPS möglicherweise nicht.\npcie_bus_default — der Kernel-Standard. Setzt die MPS jedes Geräts auf die seiner vorgelagerten Bridge. Vorsichtig und sicher, holt aber nicht die Leistung heraus.\npcie_bus_safe — setzt MPS auf den größten Wert, den alle Geräte im System können. Nützlich für geschlossene Systeme, in denen du alle Geräte kennst und nichts im Betrieb dazugesteckt wird. Etwas forscher als der Standard.\npcie_bus_perf — setzt MPS pro Gerät auf den größten Wert, den der übergeordnete Bus zulässt. Jedes Gerät bekommt die beste MPS, die seine lokale Topologie hergibt. Das ist die richtige Wahl für Passthrough, weil es jeden Weg für sich optimiert.\npcie_bus_peer2peer — setzt MPS überall auf 128 Byte. Jedes Gerät redet in der kleinsten gemeinsamen Größe. Wird genutzt, wenn Geräte direkt per DMA miteinander reden müssen (GPU zu GPU, GPU zu NIC über RDMA). Für gewöhnliches Passthrough nicht nützlich.\npcie_bus_perf ist der richtige für Passthrough.\nWie man es behebt — auf der Gast-Seite Du kannst pci=pcie_bus_perf auch in der Boot-Konfiguration des Gast-Kernels setzen. Ob das praktisch etwas bewirkt, hängt davon ab, wie QEMU die virtuelle PCIe-Topologie darstellt. Der virtuelle Root Complex begrenzt, was der Gast verhandeln kann.\nIm Test ist die Host-Seite die, die hält. Der Host besitzt das physische Gerät, und seine MPS-Einstellung bestimmt die tatsächliche TLP-Größe auf der Leitung. Die Einstellung des Gasts fasst nur die virtuelle Topologie in der VM an, und ob das echtes Verhalten ändert, hängt davon ab, wie QEMU den PCIe-Weg für dieses Gerät darstellt.\nSetz es auf dem Host. Es zusätzlich im Gast zu setzen schadet nicht, aber verlass dich nicht darauf allein.\nWas MRRS ist Die Max Read Request Size (MRRS) ist verwandt, aber etwas anderes. MPS begrenzt, wie viele Daten ein Gerät in einem TLP senden kann. MRRS begrenzt, wie viele Daten ein Gerät in einer Leseanforderung anfordern kann.\nEin Gerät mit MRRS 4096 kann eine einzelne 4-KB-Leseanforderung stellen. Die Antwort kommt in mehreren TLPs zurück, jedes höchstens so groß wie die MPS. Höhere MRRS heißt, dass das Gerät mehr Daten pro Transaktion anfordern kann, was die Zahl der Leseanforderungs-TLPs auf dem Bus senkt.\nMRRS bemisst die Anforderung, MPS bemisst jedes Paket der Antwort NVMe-Controller MRRS 4096 B Hauptspeicher über den Root Complex 1 × Leseanforderung — „schick mir 4 KB“ MRRS begrenzt, wie viel eine Anforderung verlangen darf 8 × Completion-TLP — je 512 B MPS begrenzt, wie groß jedes Paket der Antwort sein darf Eine Anforderung, viele Pakete.\u0026#160;pci=pcie_bus_perf\u0026#160;hebt beide, sie müssen also nicht getrennt eingestellt werden. Die beiden sind leicht zu verwechseln: MRRS begrenzt, wie viel ein Gerät in einer Anforderung verlangen darf, MPS begrenzt, wie groß jedes Paket der Antwort sein darf. pci=pcie_bus_perf setzt sowohl MPS als auch MRRS auf ihre optimalen Werte. Du musst sie nicht getrennt einstellen.\nWirkung gegenüber anderem Tuning Der MPS-Unterschied zwischen 128 und 512 Byte hat eine geringere Wirkung auf die Leistung als NUMA-Ausrichtung oder ASPM. Typisch ist eine Verbesserung des Durchsatzes im niedrigen einstelligen Prozentbereich. In Latenz-Benchmarks bei geringer Queue-Tiefe wirst du sie nicht sehen.\nAber sie ist kostenlos. Ein Kernel-Parameter, kein Nachteil, kein Kompatibilitätsrisiko. Es gibt keinen Grund, das auf einem System mit Passthrough nicht zu setzen.\nEs kostet nichts, und die Hardware hast du schon bezahlt. Dann nimm auch, was du gekauft hast.\nQuellen PCI-Kconfig des Linux-Kernels — Optionen zum Tuning von MPS und MRRS — maßgebliche Quelle für alle vier MPS-Politiken Linux Plumbers Conference 2017 — MPS vs MRRS (PDF) — Sinan Kayas Vortrag über die MPS-/MRRS-Behandlung im Kernel ","permalink":"https://blogs.damiendye.uk/de/proxmox/pcie-maxpayloadsize/","summary":"Der virtuelle Root Complex von QEMU liefert standardmäßig 128 Byte TLP-Payload. Die meisten Geräte können 256 oder 512. Ein Kernel-Parameter behebt das.","title":"PCIe MaxPayloadSize — ein kostenloser Leistungsgewinn beim Passthrough"},{"content":"Was i440fx und Q35 sind Jede virtuelle Maschine unter QEMU hat einen virtuellen Chipsatz. Er legt das ganze virtuelle Mainboard fest — die PCI-/PCIe-Bus-Topologie, die Southbridge, den Interrupt-Controller, das, was das Gast-Betriebssystem sieht, wenn es beim Start die Hardware aufzählt.\nQEMU bietet zwei Möglichkeiten: i440fx und Q35.\ni440fx emuliert den Intel 440FX — Codename Natoma, 1996 als Chipsatz für den Pentium Pro und später den Pentium II erschienen. Er zeigt einen flachen PCI-Bus ohne eigene PCIe-Unterstützung. Er war der erste QEMU-Maschinentyp und ist lange die Voreinstellung gewesen. Eine anständige Laufzeit für einen Chipsatz, der für den Pentium Pro entworfen wurde.\nQ35 emuliert den Intel Q35 Express, im Juni 2007 für die Core-2-Generation erschienen, gepaart mit der Southbridge ICH9. Er gibt dem Gast einen richtigen PCIe-Root-Complex und einen modernen Interrupt-Controller. Durchgereichte Geräte erscheinen als echte PCIe-Geräte mit der richtigen Topologie.\nBeide sind virtuell. Keiner wirkt sich auf die tatsächliche Hardware aus, die der Host nutzt. Der Unterschied liegt darin, was das Gast-Betriebssystem sieht.\nDer flache PCI-Bus von i440fx gegen den PCIe-Root-Complex von Q35 i440fx — ein flacher PCI-Bus Intel 440FX “Natoma” — Pentium Pro / Pentium II, 1996 vCPU PCI-Bus 0 NVMeals altes PCI NIC nur INTx IDE alt AudioAttrappe MSI-X nicht verfügbar — nur INTx-Interrupts Kein AER — PCIe-Fehler für den Gast unsichtbar Kein ACS — schwächere IOMMU-Isolation Ein geteilter Bus — eine IOMMU-Gruppe Q35 — PCIe-Root-Complex Intel Q35 Express + ICH9 — Core-2-Zeit, Juni 2007 vCPU PCIe-Root-Complex Root Port Root Port Root Port NVMeMSI-X NIC Multi-Queue GPU AER + ACS MSI-X — ein Interrupt-Vektor pro Queue AER — der Gast sieht PCIe-Fehler und behandelt sie ACS — DMA von Gerät zu Gerät gesteuert Jeder Slot kann seine eigene IOMMU-Gruppe halten Jeder Unterschied, der folgt, kommt hierher: i440fx hängt jedes Gerät an einen gemeinsamen Bus, während Q35 jedem Slot seinen eigenen Root Port unter einem PCIe-Root-Complex gibt. Warum Q35 für Passthrough zählt Geräte, die an eine i440fx-VM durchgereicht werden, erscheinen als alte PCI-Geräte, egal was sie tatsächlich sind. Der Gast sieht sie als „richtig schnelle PCI-Geräte“ statt als PCIe-Geräte. Manche Treiber kommen damit gut zurecht. Andere erwarten PCIe und verhalten sich falsch oder laden gar nicht, wenn sie es nicht finden.\nDer PCIe-Root-Complex von Q35 ändert das Bild in mehrerer Hinsicht.\nMSI-X MSI-X (Message Signalled Interrupts — Extended) setzt PCIe voraus. Unter i440fx fällt MSI-X entweder auf alte INTx-Interrupts zurück oder funktioniert überhaupt nicht.\nFür NVMe zählt das sehr. NVMe-Controller sind für ihre Architektur mit mehreren Queues auf MSI-X angewiesen. Jedes IO-Queue-Paar bekommt seinen eigenen Interrupt-Vektor. Ohne MSI-X laufen alle IO-Fertigmeldungen durch einen einzigen Interrupt, und das erzeugt bei hohen IOPS einen Engpass.\nEs zählt auch für moderne Netzwerkkarten und GPUs. Jedes Gerät, das mehrere Interrupt-Vektoren nutzt, um die Last über CPU-Kerne zu verteilen, braucht MSI-X.\nINTx trichtert jede NVMe-Fertigmeldung durch einen Interrupt; MSI-X gibt jeder Queue ihren eigenen Vektor i440fx — INTx: eine Leitung für jede Queue Queue 0 Queue 1 Queue 2 Queue 3 1 × INTx vCPU 0 Fertigmeldungen reihen sich — eine Decke bei hohen IOPS Q35 — MSI-X: ein Vektor pro Queue Queue 0 Queue 1 Queue 2 Queue 3 4 × MSI-X-Vektoren vCPU 0 vCPU 1 vCPU 2 vCPU 3 jede Queue wird auf ihrem eigenen Kern fertig Mit INTx kommen die Fertigmeldungen jeder Queue auf einer Interrupt-Leitung an und landen auf einer vCPU. Mit MSI-X trägt jede Queue ihren eigenen Vektor und wird auf ihrem eigenen Kern fertig. AER (Advanced Error Reporting) PCIe-AER lässt den Gast Gerätefehler richtig erkennen und behandeln, statt stillschweigend zu scheitern. Unter i440fx sieht der Gast Fehler auf PCIe-Ebene überhaupt nicht.\nBei produktiver Arbeit mit einem durchgereichten Gerät ist stilles Verschlucken von Fehlern ein Problem. AER gibt dem Treiber im Gast die Möglichkeit, Hardwarefehler zu protokollieren, zu melden und teilweise auszubügeln, die sonst unbemerkt blieben, bis Daten verdorben sind.\nACS (Access Control Services) ACS steuert DMA von Gerät zu Gerät auf demselben Bus. Es ist Teil des Isolationsmodells der IOMMU. Es verhindert, dass ein Gerät per DMA in den Speicherbereich eines anderen schreibt, ohne über die IOMMU zu gehen.\nUnter i440fx unterstützt die virtuelle Bus-Topologie ACS überhaupt nicht. Das zerbricht einfaches Passthrough nicht, aber es schwächt die Isolation, die die IOMMU dir geben soll.\nWie IOMMU-Gruppen gezeigt werden Die PCIe-Hierarchie von Q35 heißt, dass jeder virtuelle Slot im Gast in seiner eigenen IOMMU-Gruppe sitzen kann. i440fx wirft alles auf einen gemeinsamen Bus, was die IOMMU-Konfiguration auf der Gast-Seite schwierig macht.\nDas ist wichtig für geschachtelte Virtualisierung, wo der Gast selbst saubere IOMMU-Gruppen braucht. Und es ist wichtig für vIOMMU, das es nur auf Q35 gibt.\nvIOMMU Wenn du willst, dass der Gast selbst IOMMU-Fähigkeit hat — für geschachteltes Passthrough, für DPDK oder für bestimmte Sicherheitsaufbauten —, braucht das den Maschinentyp Q35.\nDie vIOMMU-Emulation lässt den Gast seine eigene IOMMU betreiben, und das ist nützlich für:\ngeschachteltes VM-Passthrough (eine VM in einer VM mit Gerätezugriff) DPDK-Netzwerkbetrieb im Userspace, wo die Anwendung IOMMU-Schutz braucht Sicherheitsaufbauten, die DMA-Isolation im Gast verlangen Warum Q35 auch abseits von Passthrough zählt Selbst wenn du kein Passthrough machst, ist Q35 für moderne Arbeit die bessere Wahl.\nOVMF-Firmware (UEFI) Die Kombination aus Q35 und OVMF gibt dem Gast eine moderne UEFI-Startumgebung samt Secure Boot. i440fx kann OVMF nutzen, aber die Kombination ist schlechter getestet, und manche Funktionen arbeiten nicht richtig.\nWindows 11 verlangt UEFI mit Secure Boot. Microsofts Hardwareanforderungen schreiben es vor. Windows Server 2025 läuft mit UEFI am besten. Q35 mit OVMF ist für beide der unterstützte Weg.\nBetreibst du eine VM mit Windows 11 oder Server 2025 auf i440fx mit SeaBIOS, kämpfst du gegen die Strömung. Es geht vielleicht heute. Dort läuft das Umfeld aber nicht hin.\nAHCI Q35 bringt über die Southbridge ICH9 eine eigene AHCI-Emulation mit (Advanced Host Controller Interface). i440fx nutzt für Startlaufwerke die ältere IDE- oder LSI-SCSI-Emulation.\nFür VirtIO-Speicher zählt das nicht. VirtIO umgeht den Speichercontroller des Chipsatzes komplett. Nutzt du aber SATA-Emulation für ein Gast-System, dem zur Installationszeit VirtIO-Treiber fehlen, ist AHCI auf Q35 viel schneller als IDE auf i440fx.\nIDE fängt jeden Registerzugriff ab; AHCI baut Befehle im RAM des Gasts und läutet einmal an der Türklingel Grenze zwischen Host und Hypervisor — jede Überquerung kostet einen VM-Exit i440fx — IDE: jeder Registerzugriff fällt hinein IDE-Treiber im Gast Port-I/O, ein Zugriff auf einmal 5 × VM-Exit für einen Befehl PIIX3 IDE 1 Befehl unterwegs Kein NCQ — der nächste Befehl wartet, bis der vorige fertig ist IRQ 14/15, pegelgesteuertes INTx — weitere Exits zum Maskieren und Bestätigen Q35 — AHCI: im RAM gebaut, eine Türklingel AHCI-Treiber im Gast Befehlsliste im Gast-RAM — frei 1 × VM-Exit AHCI HBA (ICH9) bis zu 32 in der Queue (NCQ) Befehle in der Queue werden außer der Reihe fertig — die Platte sortiert für kürzere Suchwege um MSI-X — keine geteilte Leitung zu bestimmen, kein EOI-Lauf IDE wird Register für Register über alte I/O-Ports programmiert, und jeder Zugriff fällt in den Host. AHCI lässt den Gast den Befehl in seinem eigenen Speicher bauen und einmal an einer Türklingel läuten. Der Overhead, den i440fx trägt und Q35 nicht Der Abstand bei AHCI liegt nicht bloß daran, dass ein Controller neuer ist. Er liegt daran, dass i440fx den Gast bei fast jeder Interaktion den Hypervisor bezahlen lässt, und Q35 überwiegend nicht.\nAbgefangene Registerzugriffe. IDE wird über alte x86-I/O-Ports programmiert. Der Gast schreibt die Sektorenzahl, dann die LBA-Register, dann das Befehlsregister. Jeder Schreibvorgang trifft einen eigenen Port. Jeder dieser Zugriffe wird vom Host abgefangen und emuliert, und jedes Abfangen ist ein VM-Exit für ein paar Mikrosekunden. Einen IDE-Befehl abzuschicken kostet daher mehrere Exits, bevor überhaupt Daten fließen.\nAHCI läuft umgekehrt. Der Gast baut eine Befehlstabelle in seinem eigenen RAM — kein Abfangen, denn er schreibt bloß in Speicher — und macht dann einen MMIO-Schreibvorgang auf ein Türklingel-Register, damit der Controller sie holt. Ein Befehl kostet etwa einen Exit statt fünf oder sechs.\nKein Befehls-Queueing. IDE schickt einen Befehl ab und wartet, bis er fertig ist. AHCI unterstützt NCQ, also können bis zu 32 Befehle offen sein, und das Laufwerk darf sie außer der Reihe fertigstellen, um Sucharbeit zu sparen. Damit verteilen sich die restlichen Kosten pro Befehl über eine Queue statt einzeln anzufallen.\nDer alte Interrupt-Weg. Der IDE-Controller im PIIX3 meldet die Fertigstellung auf den festen alten IRQs 14 und 15, zugestellt als pegelgesteuertes INTx. Ein pegelgesteuerter Interrupt muss bestätigt und wieder freigegeben werden, und weil INTx-Leitungen geteilt werden, muss der Gast außerdem herausfinden, welches Gerät ihn ausgelöst hat. Jeder dieser Schritte ist wieder ein Abfangen. MSI-X, das Q35 braucht, ist ein einfacher Speicherschreibvorgang ohne geteilte Leitung, die zu bestimmen wäre, und ohne Bestätigungslauf. Auf Hardware mit Posted Interrupts kann es den Gast ganz ohne Exit erreichen.\nEine größere Fläche alter Geräte. i440fx zeigt seine alten Plattformgeräte immer, den IDE-Controller eingeschlossen, ob die VM sie nutzt oder nicht. Sie belegen PCI-Slots, sie werden bei jedem Start aufgezählt und angetastet, und Treiber im Gast können sie abfragen. Q35 zeigt einen kleineren, moderneren Satz. Weniger, was der Host vorhalten muss, weniger, was der Gast ablaufen muss.\nNichts davon zeigt sich in einer VM mit VirtIO, und deshalb ist der Unterschied leicht zu übersehen. Er zählt während der Installation, bei Appliance-Abbildern ohne VirtIO-Treiber und bei jedem Gast, der für sein Startlaufwerk noch emuliertes SATA oder IDE nutzt.\nWeniger virtuelle Geräte, sauberere Topologie i440fx kommt mit alter virtueller Hardware, die Q35 weglässt. Eine Attrappe von einer Soundkarte. Ein alter IDE-Controller. Keines von beiden tut etwas Nützliches, aber beide verbrennen virtuelle PCI-Slots und können Software im Gast verwirren, die sie zu nutzen versucht.\nQ35 zeigt einen saubereren Satz virtueller Hardware, der näher an dem liegt, was ein moderner physischer Server hergeben würde.\nQ35 wirft die alten Plattformgeräte weg, die i440fx in virtuellen PCI-Slots hält i440fx alte Geräte halten die Slots Alter IDE-Controller Diskettencontroller (FDC) Alte PIIX3-Funktionen Weitere alte Plattformgeräte frei frei durch AHCI ersetzt von Q35 weggeworfen Q35 weniger Geräte, Slots bleiben übrig ICH9 AHCI (SATA) PCIe-Root-Ports frei für ein durchgereichtes NVMe frei für eine NIC frei für eine GPU frei Der alte IDE-Controller wird ersetzt und nicht entfernt — alles andere geht in den Müll und lässt Slots frei für die Geräte, die du wirklich durchreichen willst. Die Richtung, in die es geht RHEL 10 hat i440fx für überholt erklärt Red Hat hat den Maschinentyp i440fx in RHEL 10 formell für überholt erklärt. Das zeigt die Richtung für das ganze KVM-Umfeld. Wenn Red Hat etwas für überholt erklärt, heißt das, sie testen es nicht mehr als erstklassigen Weg und werden Fehler, die daran hängen, nicht beheben.\nDas QEMU-Projekt selbst diskutiert die Abkündigung von i440fx seit Jahren. Der Tenor ist, dass zwei Chipsatz-Wege eine Last sind. Q35 ist derjenige, der auf moderne Hardware passt.\nProxmox ist nicht mitgegangen Proxmox VE legt neue VMs weiterhin als i440fx an. Der Maschinentyp im Anlegen-Assistenten liest sich als „Default (i440fx)“, und dabei bleibt es, solange du es nicht änderst. Q35 ist ein Auswahlfeld weiter, aber es ist eine Wahl, die du bei jeder VM, die du baust, bewusst treffen musst.\nGenau deshalb gibt es diesen Beitrag. Die Voreinstellung ist der Chipsatz von 1996, und nichts im Assistenten sagt dir, dass die Wahl etwas ausmacht.\nEine bestehende VM umstellen Hast du eine bestehende VM auf i440fx, kannst du in den Hardware-Einstellungen oder direkt in der Konfiguration auf Q35 umstellen:\nmachine: q35 Das ist im Grunde ein Tausch des virtuellen Mainboards. Beim nächsten Start andere Hardware.\nLinux kommt damit meist ohne Weiteres zurecht. Der Kernel zählt die Geräte neu auf und lädt die richtigen Treiber. Schnittstellennamen werden sich ändern, weil die virtuelle NIC von einem PCI-Bus auf einen PCIe-Bus wandert. Nennt deine Netzkonfiguration sie beim Namen (etwa eth0, ens18), passe sie vor dem Neustart an, sonst verlierst du den Netzzugang.\nWindows ist weniger nachsichtig. Der Chipsatzwechsel heißt andere virtuelle Hardware-IDs für den Speichercontroller, den Netzwerkadapter und andere Plattformgeräte. Windows braucht möglicherweise eine Neuinstallation der Treiber. In manchen Fällen ist eine Neuinstallation der sauberste Weg. Älteres Windows ist der üblichste Fall.\nFreeBSD und Abkömmlinge (OPNsense, pfSense) kommen mit dem Wechsel meist zurecht, aber teste es vorher.\nTeste in allen Fällen an einer VM ohne Produktivlast, bevor du etwas umstellst, worauf es ankommt.\nWann i440fx noch gebraucht wird Eine Handvoll Fälle braucht i440fx noch.\nAlte Gast-Betriebssysteme, die älter sind als UEFI — Windows XP, Windows 2000 und Ähnliches dieses Jahrgangs —, starten unter Q35 möglicherweise nicht. Diese Systeme erwarten die alte PCI-Topologie und das SeaBIOS, die i440fx bietet.\nBestimmte Appliance-Abbilder sind ausschließlich gegen i440fx gebaut und getestet. Unterstützt der Anbieter nur i440fx, nimmst du das, bis er nachzieht.\nFür alles andere — neue Linux-VMs, modernes Windows, jede Arbeit mit Passthrough — nimm Q35. Es ist nichts zu gewinnen, wenn man aus Gewohnheit an einem Chipsatz von 1996 festhält.\nQuellen Proxmox-VE-Wiki — PCI(e) Passthrough — die offizielle Proxmox-Dokumentation, die Q35 als empfohlenen Maschinentyp für Passthrough nennt QEMU Q35 Chipset Specification (PDF) — das ursprüngliche QEMU-Entwurfsdokument zu Q35 Proxmox-Forum — Diskussion Q35 gegen i440fx — Diskussion aus der Gemeinschaft über die praktischen Unterschiede ","permalink":"https://blogs.damiendye.uk/de/proxmox/q35-not-i440fx/","summary":"Die beiden virtuellen QEMU-Chipsätze sind nicht austauschbar. Q35 liefert eine richtige PCIe-Topologie, auf die Passthrough, modernes Windows und das ganze KVM-Umfeld angewiesen sind.","title":"Immer Q35, nicht i440fx — warum das auf Proxmox VE zählt"},{"content":"Ich bin Damien Dye.\nPresales Engineer für Europa und APAC bei croit GmbH, einem Gründungsmitglied der Ceph Foundation und offiziellem Proxmox Gold Partner.\nGut zwanzig Jahre davon waren der bezahlte Teil: Microsoft-Plattformen, Linux, Unternehmensanwendungen, Virtualisierung, Netzwerk, Storage und Sicherheit. Der bezahlte Teil ist nicht das Ganze. Ich baue und zerlege Dinge seit Mitte der Neunziger und fahre Linux seit 1999 richtig, Jahre bevor irgendwer das für bezahlenswert hielt, und ich zähle diese Jahre mit, weil man an Technik, die einem selbst gehört, genauso viel lernt wie an Technik, die ein anderer versichert hat.\nSouth Yorkshire, du bekommst es also direkt. Wenn etwas funktioniert, sage ich dir warum. Wenn nicht, sage ich dir das auch, und zwar lieber, bevor du das Geld ausgegeben hast, als danach.\nDie frühen Jahre Ich nehme Computer auseinander, seit ich acht bin. Meine erste Maschine war ein Atari STfm mit 512K RAM.\nMein erster PC kam mit zwölf, mit Windows 3.11, und von dort ging es durch die ganze Reihe: 95, 95b, 95c, 98, 98SE und dann Windows 2000.\nDas war kein Benutzen von Software. Das war Herausfinden, was sich von einer Version zur nächsten änderte, was dabei kaputtging und wie man ein Ding zum Laufen bringt, das lieber nicht möchte.\nDER WEG DURCH WINDOWS — 3.11 \u0026#8594; 10 3.11 95 98 2000 XP XP64-Bit Vista64-Bit 764-Bit 8.1 10 Meine erste Internetverbindung war ein 56k-Einwahlmodem bei Freeserve — einem der ersten kostenlosen Provider in Großbritannien. Ich wechselte zu ADSL, sobald es 2001 verfügbar war, über Demon Internet. Dann 2008 zu VDSL und schließlich 2017 zu FTTP bei Zen Internet — dort kam natives IPv6 an. Da fing das mit dem Netzwerk an, und es ist ein weiter Weg zu den 100GbE-Fabrics, die ich heute entwerfe. Aber die Neugier war dieselbe.\nDas lokale Netz fing noch früher an, und rauer. Mein erstes LAN war 10BASE2 — dünnes Koaxkabel, BNC-Stecker und ein 50-Ohm-Abschlusswiderstand an jedem Ende, alle Maschinen an einem gemeinsamen 10-Mbit-Bus. Ich brachte zwei PCs darüber zum Reden und hängte einen 5-Port-Hub dazu, als mehr Maschinen auftauchten. Aus dem Hub wurde später ein Switch — ein echter Fortschritt, weil jeder Port seine eigene Kollisionsdomäne bekam, statt dass sich alles um gemeinsames Koax stritt. Danach kam WLAN, sobald es bezahlbar war: 802.11b mit 11 Mbit, auf Orinoco-Gold-PCMCIA-Karten in den Laptops. Koaxbus, gemeinsamer Hub, geswitchtes Ethernet, WLAN — jeden Schritt davon habe ich von Hand durchgearbeitet.\nIch habe außerdem vollständig unbeaufsichtigte Windows-XP-Installationen gebaut. Die nutzten die alten DriverPacks für die Treibereinbindung und eigene Skripte für automatische Anwendungsinstallationen. Von blankem Blech bis zum fertig konfigurierten System, ohne die Tastatur anzufassen. Das war Automatisierungsdenken Jahre bevor ich je von Ansible gehört hatte — und es lief auf Windows, nicht auf Linux.\nLinux finden Mit Linux habe ich mit fünfzehn angefangen, auf SuSE 6. Ich bin direkt auf die Distributionen zugegangen, bei denen man verstehen musste, was darunter passiert.\nÜber die Weihnachtsferien 2001 baute ich nach dem Buch Linux From Scratch ein komplettes System. Jedes Paket von Hand übersetzt. Jede Abhängigkeit verstanden. Jede Konfigurationsentscheidung bewusst getroffen.\n2002 war ich bei Gentoo. Gentoo läuft nach demselben Prinzip: Du baust das ganze System aus dem Quelltext, du verstehst, was jedes USE-Flag tut, und wenn etwas kaputtgeht, weißt du genau, wo du nachsehen musst.\nLINUX — DER WEG DURCH DIE DISTRIBUTIONEN SuSE6–7.2 Mandrake Gentoo Ubuntu RHEL Fedora Andere Plattformen erkunden Ich bin nie bei einer Architektur geblieben.\nVon 2001 bis 2007 hatte ich ein DEC-Alpha-System. Die Alpha war der 64-Bit-RISC-Prozessor der Digital Equipment Corporation, 1992 vorgestellt — eine echte 64-Bit-Maschine, mehr als ein Jahrzehnt bevor x86 2003 mit AMD64 nachzog. Sie lief unter Tru64 UNIX, OpenVMS, Windows NT und Linux, und eine Zeit lang war sie ungefähr das Schnellste, was man auf einen Schreibtisch stellen konnte. Über Diskussionen in der Community brachte ich USB und FireWire darauf zum Laufen. Ich habe sogar hinten einen PCMCIA-auf-ISA-Adapter eingebaut, damit dieselben PC Cards, die ich in den Laptops nutzte — die Orinoco Gold darunter —, auch im Alpha-Desktop liefen. Auf einer Plattform, auf der nichts garantiert funktionierte, keine Kleinigkeit.\nIch habe BeOS ausprobiert. Es ging Multithreading und Multimedia völlig anders an als alles andere zu der Zeit.\nAn der Universität haben ein Kumpel und ich ausrangierte Sun-SPARC-Workstations gerettet und Gentoo darauf gebaut. SPARC war die RISC-Architektur von Sun Microsystems, 1987 eingeführt — der Motor hinter den Sun-Workstations und -Servern, die in den Neunzigern einen großen Teil der Unix-Welt trugen, meist unter Solaris. Ein aus dem Quelltext gebautes Linux auf dieser Hardware zum Laufen zu bringen, war der ganze Sinn der Sache. Warum auch nicht, wenn die Technik dasteht und man wissen will, ob es geht.\nIch habe außerdem Linux auf ARM und ARM64 gebaut und damit gearbeitet, auf Raspberry Pis und Odroids. Und ich habe Windows auf ARM64 gefahren.\nFährst du dasselbe Betriebssystem auf x86, Alpha, SPARC, ARM und ARM64, dann folgen dir die Annahmen von der einen Plattform nicht auf die nächste — Bytereihenfolge, Ausrichtung, Seitengrößen, Treiberunterstützung und Eigenheiten der Toolchain verschieben sich alle unter dir. Das zählt heute mehr denn je, wo ARM64 im Rechenzentrum neben x86 sitzt, und es ist das Denken, das einen gemischt-architektonischen Ceph- oder Proxmox-Bestand ehrlich hält.\nMit IPv6 habe ich ebenfalls früh experimentiert. Ich hatte Zugang zum 6bone — dem experimentellen IPv6-Testnetz. Das 6bone war ein weltweites Testbett, das ab 1996 lief, um IPv6 zu entwickeln und auszurollen, bevor das produktive Internet dafür bereit war. Es trug IPv6 überwiegend über IPv4-Tunnel, nutzte den eigenen Adressbereich 3ffe::/16 und wurde am 6. Juni 2006 bewusst abgeschaltet, als natives IPv6 reif genug war, um allein zu stehen. Ich fuhr sowohl den Linux-IPv6-Stack als auch den IPv6-Stack von Microsoft Research für Windows XP. Ich habe das Ganze durch. Angefangen mit IPv6-in-IPv4-Tunneln. Weiter zu 6to4 (RFC 3056) für automatisches Tunneln. Dann zu vollem nativem IPv6, als ich zu einem anständigen Provider wechselte — Zen Internet. Die meisten Leute haben IPv6 nicht angefasst, bis ihr Arbeitgeber sie dazu zwang. Ich hatte zu dem Zeitpunkt schon jeden Übergangsmechanismus durch, auf Linux und auf Windows, weil ich verstehen wollte, wohin sich Netzwerk entwickelt. Deshalb fühlt sich IPv6 heute natürlich an und nicht wie etwas nachträglich Angeschraubtes. Inzwischen laufen neunzig Prozent meines Verkehrs über natives IPv6. Ich nutze eine Browser-Erweiterung namens IPvFoo, die mir zeigt, was jede Verbindung verwendet und ob Seiten gemischte Protokolle oder nur IPv4 ausliefern. Alte Gewohnheit — ich sehe lieber, was wirklich passiert, statt es anzunehmen.\nIPv6 — ZWEI JAHRZEHNTE, EXPERIMENT BIS KRITISCH Vom Teststack zu Hause zur Produktion in nationalem Maßstab 6bone — das experimentelle IPv6-Testbett Linux- und Microsoft-Research-IPv6-Stack nebeneinander gefahren IPv6-in-IPv4-Tunnel IPv6 über das IPv4-Internet, von Hand konfiguriert 6to4 (RFC 3056) Automatisches Tunneln — kein Broker zu pflegen Natives IPv6 Ende zu Ende zu Hause über FTTP · Zen Internet · 2017 Nominet — kritische nationale Infrastruktur IPv6 produktiv für die .uk-Registry · F5-Loadbalancer über IPv4 und IPv6 Heute laufen rund 90 % meines Verkehrs über natives IPv6. Lernen durch Machen Alles, was ich technisch kann, habe ich gelernt, indem ich es versucht habe. Dinge gebaut, kaputtgemacht, herausgefunden warum, wieder gebaut.\nDas Studium war Business Studies und Computer Network Engineering an der Sheffield Hallam, und es gab mir das eine, was Selbststudium nicht gibt — wie ein Unternehmen tatsächlich funktioniert, wie aus einer technischen Entscheidung ein kaufmännisches Ergebnis wird und wie man ein System nach dem Problem denkt, das es für den löst, der dafür bezahlt. Das hat jede Rolle seitdem geprägt.\nDie technischen Fähigkeiten kamen aber vom Tun, nicht vom Studieren. Produktionsprobleme kommen nicht mit einer Leseliste. Etwas von Grund auf durchdenken zu können ist mehr wert als ein Zertifikat an der Wand, und es läuft nicht ab.\nWoher Open Source kommt Als Microsofts Führung Open Source Anfang der 2000er als „einen Krebs“ bezeichnete, steckte ich schon tief in Linux. Systeme von Grund auf gebaut. Gentoo gefahren. In Communities beigetragen.\nDiese Art von Feindseligkeit gegenüber Leuten, die Wissen teilen und gemeinsam etwas bauen, hat mich nicht abgeschreckt. Sie hat mich tiefer hineingetrieben. Wenn die Antwort einer Firma auf gemeinschaftliche Entwicklung ist, sie eine Krankheit zu nennen, sagt das mehr über die Firma als über die Software. Ich bin tiefer in Open Source eingestiegen und habe es zu meiner ersten Wahl gemacht, statt diese Haltung zu stützen.\nÜber die Jahre hat das Praktische das Prinzipielle eingeholt. Proprietäre Plattformen funktionieren gut genug, bis der Hersteller die Lizenzierung ändert, gekauft wird oder entscheidet, dass dein Anwendungsfall es nicht wert ist. Dann sitzt du fest. Deine Daten, deine Abläufe und das Know-how deines Teams hängen alle an einer Plattform, die du nicht mehr kontrollierst. Die Übernahme von VMware durch Broadcom ist das jüngste und sichtbarste Beispiel, aber bei weitem nicht das einzige.\nDasselbe Denken gilt für die Cloud. Frag, was du eigentlich mietest, und die Antwort lautet: Kapazität, die du hättest besitzen können, auf einem Zähler, der nie stehenbleibt. Die versprochenen Vorteile — Beweglichkeit, Elastizität, weniger Verwaltung — kommen selten in der Form an, die der Pitch beschrieb, und die Kosten wachsen Jahr für Jahr auf eine Weise, wie es eigene Technik nicht tut. Als solches konnte ich jedes Mal, wenn mich jemand darum gebeten hat, zeigen, dass Open Source auf gut entworfener Hardware mehr Gegenwert, mehr Kontrolle und weniger Überraschungen bringt. Keine modische Position. Aber eine, die ich mit Zahlen unterlegen kann.\nEine Laufbahn aufbauen Meine Laufbahn begann 2005 bei einem Präzisionsgießerei-Hersteller in Worksop. IT-Techniker, Teil eines kleinen Teams, Betreuung von rund fünfzig Nutzern.\nDiese erste Rolle deckte eine ordentliche Breite ab. Pflege des Manusoft-ERP-Systems und der Dokumentenarchivierung. Linux- und Windows-2003-Serveradministration. Crystal-Reports-Entwicklung für Entscheidungen in Produktion und Instandhaltung. TK-Anlagenadministration. CAD/CAM-Systemintegration und Verwaltung computergestützter Roboterfertigung. Beschaffung von Hard- und Software. Schulung von Endanwendern und Support direkt am Arbeitsplatz.\nIch habe außerdem vom ersten Tag an automatisiert. Ich habe das Active Directory der Firma aktualisiert und VB-Skripte geschrieben, die je nach Gruppenmitgliedschaft automatisch Laufwerke verbanden, Drucker zuwiesen und Software verteilten. Das war 2006 — richtige Infrastrukturautomatisierung in meiner ersten beruflichen Rolle.\nDas ist Fertigungs-IT. Wenn die Linie wegen etwas stillsteht, das du betreust, lernst du schnell, dass Zuverlässigkeit keine Vorliebe ist, und die Leute neben der Maschine sagen dir das auch selbst. Es war auch das erste Mal, dass ich Linux und Windows im selben Gebäude beruflich gefahren habe, und das ist seitdem das Muster geblieben.\nVon dort ging ich in den technischen Support an vorderster Linie. First und Second Level, an einem eigenen Desk für einen großen multinationalen Kunden. Windows-Desktops, Active Directory, Exchange 2007, Cisco VPN, Cisco Call Manager, ITIL-basierte Ticketverwaltung auf Remedy. Diese ITIL-Disziplin — Change Management, Problem Management, strukturierte Prozesse — ist mir seitdem in jede Rolle gefolgt. Ich habe früh auch die Linux- und Windows-Welt überbrückt — Services for Unix konfiguriert und Citrix-Zugriffe auf Unix-NFS-Freigaben gelöst.\nSelbst an diesem Desk habe ich über die Stellenbeschreibung hinaus gebaut. Ich schrieb eine Schnittstelle, die Benutzerkonten direkt aus den HR-Daten in Agresso anlegte und deaktivierte — das Active-Directory-Konto, die Gruppenmitgliedschaften, die Office-Communicator-Konfiguration, das Exchange-Postfach und die Aliase. Das ist Systemintegration von einem First-Level-Platz aus, was so nicht in der Stellenbezeichnung stand.\nEiner der Kunden, die ich an diesem Desk betreute, hat mich später beim nächsten Unternehmen eingestellt.\nAls Nächstes ein global tätiges Kommunikationsunternehmen, ICT und Sicherheit. Dort fing die Anwendungsentwicklung richtig an. In zweieinhalb Jahren habe ich sechs eigenständige interne Systeme gebaut oder daran mitgearbeitet. Ein eigenes webbasiertes Angebotswerkzeug. Auftragsschnittstellen zwischen Salesforce und Agresso. Ein SharePoint-Stammdatenkatalog, gespeist aus Salesforce und Agresso. Ein eigenes Web-Projektmanagementsystem mit Schnittstellen zu MSPE und Agresso für die Finanzverarbeitung. Und eine Migration von einer angepassten Salesforce-Service-Cloud-Anwendung zu ServiceNow mit vollständiger ITIL-Prozessumsetzung. Ich schrieb außerdem SQL-Schnittstellenarchitektur für Unternehmensanwendungen und optimierte die MS-SQL-Leistung. Ich administrierte IIS und Windows Server 2008 Terminal Services und verantwortete das Unternehmensdatenmodell. Verzeichnisdienste — Active Directory und LDAP — wurden hier zu einer Kernkompetenz, die mich durch jede spätere Rolle begleitet hat.\nIch habe außerdem ein landesweites Windows-7-Ablöseprogramm geleitet und die gesamte britische Nutzerschaft in drei Wochen auf neue HP-Technik gebracht, wobei 95 % angaben, überhaupt keine Störung ihrer Arbeit erlebt zu haben. Drei Wochen ist die Art Zahl, die nur herauskommt, wenn die Vorbereitung ordentlich gemacht wurde, und die Vorbereitung ist die unglamouröse Hälfte, nach der hinterher niemand fragt.\nDann kam die Führung. Ein Halbleiter-Designhaus mit einem kleinen Team von Ingenieuren über mehrere Länder verteilt. Das zog mehrere Fäden auf einmal zusammen. Ich entwickelte auf der Force.com-Plattform — Trigger, Visualforce-Seiten, eigene Controller —, um Financial-Force-Buchhaltung und PSA-Systeme weltweit zu integrieren. Gleichzeitig baute ich zwei getrennte PXE-Boot-HPC-Cluster. Einen für die britisch-europäische Entwicklung und einen für die chinesische. Beide mit Red Hat und NFS-Root-Dateisystemen, um konsistente, zu 100 % wiederholbare plattenlose Rechenfarmen zu schaffen. Ich setzte ZFS auf Linux mit Dell-PowerVault-Technik für vereinheitlichten Storage ein. Ich ersetzte alte isolierte Sicherheitsumgebungen durch ein Windows Server Active Directory mit nativem Kerberos und LDAP für Single Sign-on über Linux und Windows. Ich stabilisierte die internationale Anbindung, indem ich ein einheitliches Netz mit OpenVPN-Tunneln durch schwierige Betriebsbedingungen nach China baute.\nEinen guten Teil dieser Rolle war ich der Einzige, der das alles abdeckte: die Linux-Rechenfarmen, den Windows-Support, die Salesforce-Entwicklung und den Nutzersupport über mehrere Zeitzonen, unter SoC-Design-Lasten auf fortgeschrittenen Technologieknoten. Einer der Ingenieure, die mir berichteten, ist später Salesforce-Entwickler geworden, und das zähle ich als das bessere Ergebnis dieser Jahre.\nDanach ein richtiger Tiefgang in Linux. Third-Level-Support bei Pulsant, einem Cloud- und Hosting-Anbieter, quer über den ganzen Stack. RHEL, CentOS, Ubuntu. MySQL-Clustering mit Galera, MongoDB-Sharding, HAProxy mit SNI und SSL-Terminierung, Apache, PostgreSQL, PHP-FPM-Tuning für leistungsstarken E-Commerce, Postfix-Mail, BIND und PowerDNS für DNS-Hosting, Varnish fürs Web-Caching, Squid fürs Proxy-Caching. IPTables, IPset und Cisco ASA für Firewalling und DoS-Schutz. Linux-Serveroptimierung für Netzwerk und Storage. CPanel-Fehlersuche, Entwicklung von SolarWinds-Monitoring-Templates und New-Relic-Administration. Alles auf VMware 5.5 mit vCloud Director darunter.\nEs war auch nicht nur Support. Ich habe dort ein Galera-Datenbankreplikationsprodukt entworfen und es vom Konzept über den Prototyp bis zu einem Dienst gebracht, für den Kunden bezahlt haben. Das war keine Laborübung. Es wurde an echten Lasten echter zahlender Kunden gebaut und bewiesen, und das gibt ein Hosting-Anbieter nicht leichtfertig aus der Hand.\nThird Level lehrt dich, was es heißt, die letzte Eskalationsstufe zu sein. Wenn es bei dir ankommt, wird es hinter dir niemand mehr richten.\nDann Nominet — die Registry hinter jedem .uk-Domainnamen. DNS in nationalem Maßstab. Die Infrastruktur muss vierundzwanzig Stunden am Tag bombenfest sein, jeden Tag, ohne Ausfallzeit und mit Rufbereitschaft außerhalb der Geschäftszeiten. VMware 5.5 und 6, HP-3par-Storage mit Fibre-Channel-Zoning auf Brocade, RHEL 6 und 7 mit Puppet verwaltet, F5-Loadbalancer über IPv4 und IPv6, Postfix-Mail und ein Zabbix-Aufbau, den ich als Ersatz für das alternde VMware-Hyperic-Monitoring gebaut habe. Ich habe außerdem ServiceNow eingeführt und angepasst, mit Workflows, Anwendungsverteilung und Linux-Knotenerkennung für Konfigurationsverwaltung und Inventar. Ich habe geholfen, Prozesse für die Auslagerung des Service Desks außerhalb der Geschäftszeiten zu entwerfen und aufzubauen, um die Rufbereitschaft zu entlasten.\nBei Nominet war ich am Ende der Erste, den man fragte, ob es um Linux, Unix, ServiceNow oder etwas ging, das niemand einordnen konnte, und ich habe Wert darauf gelegt, mit etwas zurückzukommen, das funktionierte, statt mit etwas, das gut klang. Das ist die Art Ort, an dem du lernst, dass der langweilige, disziplinierte Umgang mit Infrastruktur der ist, der den Kontakt mit einem Dienstagmorgen überlebt.\nNach Nominet ging ich quer durch Infrastruktur und Hosting. VMware 6.7, Zerto für Disaster Recovery, Dell-Compellent- und Nexsan-Storage mit Brocade-Fibre-Channel-Zoning, Citrix Cloud mit FSLogix-Profilverwaltung neben Azure. Ich habe auch dort Zabbix-Monitoring eingeführt und die Templates und Skripte von Grund auf entworfen.\nDann Einzelhandel. Ein kleines Team geführt, die VMware-6.7-Administration von einem Dritten wieder ins Haus geholt, Zabbix-Monitoring ausgerollt (wieder einmal als Ersatz für einen gescheiterten Versuch), die Betriebssystemverteilung um PXE und Chocolatey neu gebaut, das Netz mit Fortinet-Technik erneuert und die Hardwarebeschaffung geordnet.\nDann die Rolle, die alles verändert hat. Beim UK Centre for Ecology \u0026amp; Hydrology habe ich das Science-Computing-Team geleitet — vier direkt Berichtende — und die Infrastruktur von Grund auf neu gebaut. Eine private Cloud aus 7 Proxmox-VE-Knoten mit hyperkonvergentem Ceph-Storage auf doppeltem 100Gb-Switching. Ein HPC-Cluster aus 8 Knoten auf HDR InfiniBand mit Slurm, mit SR-IOV für den VM-Zugriff auf die Fabric und EasyBuild für Softwarebauten. Migration von GPFS zu reinem NVMe-Ceph-Storage. Ansible mit Netbox als Wahrheitsquelle für alles — Patchverwaltung, Kontrolle der Konfigurationsdrift, Anbindungen an Cloudflare, PowerDNS und Active Directory. OSPF-Dynamikrouting für die Cloud-Netze. Lokale Repository-Spiegel für maximale Verteilgeschwindigkeit und Konsistenz. Neuausrollung der HPC-Umgebung von CentOS 7 auf Rocky 9. Cloudflare für DNS (samt DNSSEC), DDoS-Schutz und Zero-Trust-Fernzugriff. Dazu gehörte die Migration von 25 autoritativen DNS-Zonen von selbst gehostetem BIND 9 zu Cloudflare in zwei Arbeitstagen. Mehrere Registries wurden aktualisiert, und das Ganze wurde mit Ansible und Let\u0026rsquo;s Encrypt integriert.\nAlles auf Open-Source-Werkzeugen, knappes Budget, bewusst so gebaut, dass wir der Broadcom-und-VMware-Lizenzfalle entgehen, bevor sie zuschnappte. Das hat die Diskussion erledigt. Open-Source-Infrastruktur in dieser Größenordnung ist nicht bloß machbar — sie ist besser, und ich habe den Cluster und die Rechnungen, um das zu sagen.\nDie andere Hälfte dieser Aufgabe waren die vier Leute im Team. Wissenschaftlern ist egal, wie der Storage heißt. Ihnen zählt, ob der Job heute Nacht durchläuft, und ob die Person, die sie fragen, die Antwort erklären kann, ohne dass sie sich dumm vorkommen.\nWie alles zusammenkommt Der Wechsel in den Presales bei croit war kein Richtungswechsel. Es war alles, was an einem Ort zusammenlief.\nFertigungs-IT Zuverlässigkeit ist Pflicht, wenn die Produktion daran hängt Support an vorderster Linie Zuhören, erklären und geduldig bleiben lernen Anwendungsentwicklung Systeme bauen, die echte Geschäftsprobleme lösen Globale IT-Leitung Die Technik tragen und die Leute trotzdem entwickeln Tiefes Linux-Engineering Die letzte Eskalationsstufe — dahinter ruft niemand mehr an Kritisches DNS bei Nominet Infrastruktur und Disziplin in nationalem Maßstab Infrastruktur \u0026amp; Hosting VMware, Storage und Disaster Recovery im großen Maßstab Science Computing (UKCEH) Neu gebaut auf Proxmox VE + Ceph + HPC, durchweg Open Source Presales bei croit Das System entwerfen, es verteidigen, ehrlich dazu stehen Fertigungs-IT hat mir beigebracht, dass Zuverlässigkeit in dem Moment aufhört, eine Vorliebe zu sein, in dem die Produktion daran hängt. Support an vorderster Linie hat mir beigebracht, zuerst zuzuhören. Anwendungsentwicklung hat mir beigebracht, Systeme zu bauen, die ein Geschäftsproblem lösen und nicht ein interessantes. Ein globales Team zu führen hat mir beigebracht, die technische Last zu tragen und trotzdem die Leute um mich herum zu entwickeln, was schwerer ist als jede Hälfte für sich. Third-Level-Linux hat mir gezeigt, wie sich die letzte Eskalationsstufe anfühlt. Zwanzig Jahre Windows und Linux nebeneinander haben mir gezeigt, wie sich Plattformen unter Last wirklich verhalten, im Unterschied dazu, wie es im Datenblatt steht. VMware, das ich ab 2008 in fast jeder Rolle gefahren habe, hat mir gezeigt, wie Unternehmensvirtualisierung im Großen aussieht — und was passiert, wenn sich der kaufmännische Boden unter einer Plattform verschiebt, auf der der ganze Bestand sitzt. Storage und Netzwerk haben mir gezeigt, wo die harten Probleme wohnen. Sicherheit zieht sich durch alles, von Firewalls und VPNs damals bis zu DNSSEC, Zero Trust und Härtung heute. Nominet hat mir Disziplin beigebracht.\nSetz das alles zusammen, und du bekommst Presales. Du entwirfst das System, dann verteidigst du den Entwurf, und du bleibst ehrlich dabei, was es nicht können wird, weil gleich jemand auf dein Wort hin echtes Geld ausgibt.\nBei croit heißt das, mit Häusern in Europa und Asien-Pazifik zu arbeiten, die ihre Virtualisierung und ihren Storage neu denken. Die Gespräche drehen sich meist darum, VMware zugunsten von Proxmox VE mit Ceph zu verlassen. Die Lasten, die dabei herüberkommen, sind überwiegend Windows, die plattformübergreifende Erfahrung ist also nicht von gestern. Sie ist das, was ich heute mache.\nWoran mir liegt, ist die Ehrlichkeit. Was ich jemandem vorlege, muss das sein, was in seinem Gebäude funktioniert, in seiner Größenordnung, mit den Beschränkungen, die er tatsächlich hat, und wenn seine vorhandene Technik den Job schon größtenteils erledigt, dann sage ich ihm genau das.\nDER STACK, DEN ICH HEUTE ENTWERFE \u0026amp; BAUE Automatisierung \u0026amp; Wahrheitsquelle Ansible · NetBox · Let's Encrypt Compute Proxmox VE — KVM-Maschinen + LXC-Container Storage Ceph — RBD-Block · CephFS · reines NVMe Netzwerk 25/100GbE-Fabric · BGP / OSPF · natives IPv6 Fundament Open Source, auf Hardware, die dir gehört Storage Storage war immer wieder die Stelle, an der die schwersten Probleme saßen. Das war kein bewusster Karriereplan — es hat sich einfach so ergeben.\nDie Faszination fing früh an. In den Neunzigern träumte ich von Iomega-Zip- und -Jaz-Disks — 100 MB und dann ein ganzes Gigabyte auf einer einzigen Wechselkassette, als die Disketten, die alle anderen herumreichten, gerade 1,44 MB fassten. Das war teure Technik, also blieben sie jahrelang ein Wunsch statt ein Besitz. Als ich endlich ein USB-Zip-Laufwerk hatte, waren gerade die USB-Sticks aufgetaucht — und das Format, das ich so lange gewollt hatte, war schon auf dem Weg hinaus. Eine frühe Lektion darüber, wie schnell sich Storage bewegt und wie schnell aus dem Muss von heute der Schubladenkram von morgen wird.\nOptisch gehörte zur selben Geschichte. 1998 hatte ich ein HP-CD-RW-Laufwerk mit vierfacher Geschwindigkeit, und es war ein Prachtstück. Es konnte Scheiben lesen und wiederbeschreiben, die spätere, schnellere Laufwerke schlicht verweigerten — so verdiente es sich seinen Platz als Rettungslaufwerk noch lange, nachdem es hätte in Rente gehen sollen.\nAngefangen hat es beim Anschluss. Ich habe mit Storage-Hardware quer durch alles gearbeitet. IDE, mehrere SCSI-Generationen, SATA, SAS und NVMe auf der direkt angeschlossenen Seite. ATA over Ethernet und iSCSI auf der Netzwerkseite. HP 3par, Dell Compellent, Dell PowerVault, Nexsan — jedes mit eigenen Eigenheiten und Fehlerbildern.\nVon dort ging es den Stack hinauf. Clustered LVM hat mir gezeigt, wie sich gemeinsamer Storage verhält, wenn mehrere Knoten gleichzeitig zugreifen müssen — und was passiert, wenn Locking und Fencing nicht stimmen. ZFS hat mir gezeigt, was passiert, wenn man Datenintegrität auf Dateisystemebene wirklich durchdenkt. GPFS hat mir parallele Dateisysteme im großen Maßstab gezeigt. Ceph hat mir gezeigt, wie sich verteilte Systeme im Fehlerfall anders verhalten.\nÜber die Jahre wurde aus „der Mensch, der auch den Storage macht“ „der Mensch, den man ruft, wenn der Storage ordentlich entworfen werden muss“.\nNetzwerk Netzwerk war von Anfang an dabei. Es ist keine Nebenfähigkeit — es ist eine Kernfähigkeit. TCP/IP, DHCP und DNS spannen sich über jede einzelne Rolle, die ich ab McKenna hatte.\nBei Nominet zu arbeiten hieß, an der Infrastruktur hinter der britischen Domain-Registry zu arbeiten. Das ist DNS in nationalem Maßstab. Benennung, Auflösung, Delegierung und die Erwartung, dass es jedes Mal funktioniert.\nIch habe autoritative Zonen auf BIND 9 gefahren, DNSSEC konfiguriert, F5-Loadbalancer für IPv4 und IPv6 aufgesetzt und später DNS-Bestände mit API-Automatisierung und Let\u0026rsquo;s-Encrypt-Anbindung zu Cloudflare migriert. Ich habe PXE-Boot-DNS-Infrastruktur für Clusterausrollungen in Großbritannien und in China gebaut. Ich verstehe DNS von beiden Seiten. Selbst gehostet, wo dir jeder Fehler gehört. Und verwaltet, wo du einem Anbieter vertraust und dieses Vertrauen durch Monitoring prüfen musst.\nÜber DNS hinaus zieht sich Netzwerk durch jede Rolle, die ich hatte. VLANs, Bonding, LACP, Fibre-Channel-Zoning mit Brocade, Firewalling mit Fortinet und Cisco ASA, IPTables und IPset. 25GbE- und 100GbE-Fabric-Entwurf, BGP, OSPF-Dynamikrouting, MTU-Verwaltung, IPv6-Architektur. VPN-Tunnel — von OpenVPN über schwierige internationale Strecken bis zu WireGuard und cloudflared für modernen sicheren Zugang. Samba war ebenfalls über mehrere Rollen hinweg eine berufliche Fähigkeit und hat Linux-Dateifreigaben und Windows-Domänenintegration überbrückt, lange bevor ich die AD-Implementierung im Alpha-Stadium getestet habe.\nEin Ceph-Cluster ist eine Netzwerkanwendung. Die Leistungsgrenze des Storage wird vom Netz darunter gesetzt. Die Fehlerbilder sind Netzwerkfehlerbilder. Das lernst du nicht aus einem Lehrbuch. Das lernst du beim Fehlersuchen um zwei Uhr nachts.\nLinux Ich arbeite seit über zwei Jahrzehnten quer durch die RHEL-, Debian-, SUSE- und Fedora-Familien. Beruflich heißt das RHEL und CentOS für laufende Dienste, Ubuntu für Anwendungshosting, Rocky für HPC sowie Gentoo und Fedora für den privaten Gebrauch. Ich habe LinkedIns Linux-Skill-Assessment bestanden.\nDie Tiefe kam von Problemen, für die es keine Stack-Overflow-Antwort gibt, und dort lernt man das PCI-Subsystem richtig statt vom Hörensagen: IOMMU-Gruppen, ACS, VFIO, SR-IOV, Resizable BAR und was die DMA-Übersetzung dich still und leise kostet, und Kernel-Bootparameter als Stellschrauben, die das Verhalten der Maschine ändern, statt als Liste zum Abschreiben aus einem Wiki, weil irgendein Blog schrieb, es habe dort geholfen.\nStorage- und Virtualisierungsprobleme lassen sich fast immer auf eine Schicht zurückführen, in die niemand geschaut hat. Dort wohnt mein Linux-Wissen.\nWindows Linux ist heute das, womit ich meine Zeit verbringe, aber die Windows-Seite ist genauso real und war in jedem Job dabei, den ich hatte. Windows Server, Active Directory, LDAP, Exchange, IIS, Microsoft SQL Server. Nichts davon ist eine Altlast, die ich abgelegt hätte.\nEs zählt auf Gastebene, und dort hören die meisten auf zu schauen. Wenn eine Windows-Last auf KVM läuft, ist der Mensch, der dir sagen kann, wie sich dieser Gast unter einer bestimmten CPU-Topologie verhält, und eine Leistungsbeschwerde auf einen Microsoft-Patch statt auf den Hypervisor zurückführen kann, der Mensch, der Jahre auf beiden Seiten des Zauns verbracht hat. Die meisten VM-Leistungsdebatten, die ich erlebt habe, wurden dadurch gewonnen, dass jemand den Gast kannte, nicht den Wirt.\nDie Leute, die ich betreut habe, reichen von Professoren und Vorständen bis zum Team, das sich um die Gebäude kümmert. Die Aufgabe ist jedes Mal dieselbe. Herausfinden, was sie wirklich brauchen, es zum Laufen bringen und es so erklären, dass sie sich für die Frage nicht dumm vorkommen.\nVMware VMware ist die Plattform, mit der ich beruflich groß geworden bin, über sieben Rollen ab 2008, und ich habe den ganzen Stack davon gefahren: ESXi, vCenter, vSAN, vSphere-Clustering, vMotion. Ich weiß, was sie gut kann. Ich weiß, wo nicht. Und ich habe zugesehen, wie die Broadcom-Übernahme die kaufmännische Wirklichkeit unter Häusern neu geschrieben hat, die ihren gesamten Bestand darauf gebaut hatten, was etwas anderes ist, als darüber zu lesen.\nDu kannst niemandem von einer Plattform herunterhelfen, auf der du nie richtig gearbeitet hast. Als solches kann ich ihnen sagen, was sie aufgeben, was sie bekommen und welcher Teil der Migration schlimmer wird, als man ihnen erzählt hat.\nAutomatisierung Automatisierungsdenken begann 2006 in meiner ersten beruflichen Rolle. VB-Skripte bei McKenna, um AD-Laufwerksverbindungen, Druckerzuweisung und Softwareverteilung zu automatisieren. Dann HR-zu-AD-Provisionierungswerkzeuge bei BT Engage IT. Dann PXE-Boot-Systeme für plattenlose Rechencluster bei Sondrel. Dann Puppet bei Nominet. Dann Chocolatey-Paketierung und PXE-Neuaufbau bei einem Einzelhändler. Dann ServiceNow-Workflow-Anpassung über mehrere Rollen hinweg.\nHeute ist es Ansible mit Netbox als Wahrheitsquelle. Nicht weil sie gerade angesagt sind, sondern weil Infrastruktur, die sich nicht aus Code neu bauen lässt, keine Infrastruktur ist, der du trauen kannst.\nDokumentation ist dasselbe Argument. Wissen, das nur in jemandes Kopf lebt, ist ein einzelner Ausfallpunkt, und es geht um fünf Uhr mit allen anderen aus dem Gebäude. Genau wie eine Platte ohne Redundanz dahinter, und mit demselben Ernst zu behandeln.\nMonitoring Mein Monitoring-Hintergrund begann mit SolarWinds bei Pulsant, wo ich Monitoring über den Hosting-Bestand in der Breite gefahren habe. Zabbix kam später und hat sich eine eigene Erwähnung verdient, weil ich es seitdem fast überall eingeführt habe. Angefangen hat es bei Nominet, wo ich die Ausschreibung und die Tests geleitet und uns dann auf Zabbix umgestellt habe, um das alternde VMware-Hyperic-Setup abzulösen, und es gewann, weil es wirklich verständlich war und nicht bloß ein weiteres Ding mit Nagios darunter. Danach habe ich es bei einer Hosting- und Infrastrukturplattform von Grund auf eingeführt, im Einzelhandel einen gescheiterten Versuch ersetzt und damit bei UKCEH einen HPC-Cluster aus 8 Knoten überwacht.\nJedes Mal habe ich die Monitoring-Templates selbst entworfen und die Skripte selbst geschrieben. Als ich 2018 die Zabbix-Prüfungen zum Specialist und Professional ablegte, hatte ich es schon seit Jahren ausgerollt.\nKommunikation Arbeit in kritischer Infrastruktur bringt dir bei, präzise zu sein. Arbeit im Presales bringt dir bei, klar zu sein. Das eine hängt mit dem anderen zusammen, ist aber nicht dasselbe.\nPräzise zu sein bringt nichts, wenn die zuhörende Person dem Gedankengang nicht folgen kann, also musste ich lernen, dieselbe Erklärung zweimal zu liefern: einmal für die Ingenieurin, die die CRUSH-Map sehen will, und einmal für die Person, die unterschreiben muss, warum das Budget die Zahl ist, die es ist. Ich vereinfache nichts ins Kindliche. Ich mache nur jeden Schritt im Gedankengang sichtbar und lasse sie mich unterbrechen, wo sie wollen.\nJahre mit Endanwendern haben mir eine andere Art Geduld beigebracht. Die Leute, die sich für die Klügsten im Raum halten, verhalten sich meist am hilflosesten. Die, die mit „ich bin nicht sehr technisch“ anfangen, hören in der Regel zu, folgen den Schritten und haben es in zehn Minuten erledigt. Und die, die dir sagen, sie wüssten genau, was sie tun, haben es in der Regel schlimmer gemacht, bevor sie zum Hörer gegriffen haben.\nDer Hintergrund in Geschäftssystemen hilft hier mehr, als man denkt, weil ich immer in beide Richtungen übersetzen musste. SQL-Architektur für eine Betriebsleiterin, ein Storage-Entwurf für einen CTO, oder neben jemandem am eigenen Schreibtisch sitzen und ihm das zeigen, was ihm nie gezeigt wurde. Jedes Mal dieselbe Fähigkeit.\nCommunity Wissen zu teilen zieht sich durch die ganze Laufbahn.\nIch war in den Gentoo-Foren aktiv, als ich Systeme aus dem Quelltext baute und verstehen musste, warum eine USE-Flag-Kombination einen Compile zerlegte. Ich habe in den Samba-Foren beigetragen, als ich Dateifreigabe- und Domänenintegrationsprobleme zwischen Linux und Windows durchgearbeitet habe. Das ging über bloßes Fragen hinaus. Ich habe einen Samba-basierten Active-Directory-Domänencontroller gebaut, während die AD-Unterstützung noch im Alpha-Stadium war. Ich habe ihn gegen Windows 2000, XP und Vista getestet und in die Community zurückgemeldet.\nHeute bin ich aktiver Beiträger in den Proxmox-Community-Foren als DamienDye. Ich helfe bei NVMe-Passthrough-Leistung, Windows-VM-Tuning, Ceph-Fehlersuche und Cluster-Netzwerk.\nDie Technologien ändern sich. Das Prinzip nicht. Wenn ich ein Problem gelöst habe, ist nichts damit gewonnen, darauf sitzen zu bleiben, und irgendwer wird in sechs Monaten um zwei Uhr nachts froh sein, dass es aufgeschrieben ist.\nIch habe außerdem die Angewohnheit, mich tiefer in Probleme einzugraben, als die Aufgabe streng genommen verlangt. Ich habe eine selbstgebaute Platine für NVMe-Power-Loss-Protection entworfen, weil ich genau verstehen wollte, warum FTL-Korruption auf Hardwareebene entsteht. Ich habe Protokolle für selbst gehostete E-Mail untersucht, weil ich JMAP vom RFC an verstehen wollte, statt einem Anbieter einfach zu vertrauen. Ich habe diesen Blog gebaut, weil ordentliches Aufschreiben die Art ist, wie man die Lücken im eigenen Verständnis findet.\nCommunity abseits der Tastatur Nicht alles davon waren Foren.\n2018 war ich einer der Gründer der Longford Park Community Association in Banbury, in der Siedlung, in der ich wohne. Vier Bauabschnitte, ein Gemeindezentrum, das in den Plänen stand, und nichts, was es hätte betreiben können. Also hat eine Handvoll Anwohner etwas aufgebaut.\nIch habe zuerst den IT-Teil gemacht, weil das war, was ich zu geben hatte. Die Domain lpca.org.uk ging im Januar 2018 online, und dahinter habe ich die Website, die Mailsysteme und die Ausschusslisten gebaut und die Datenschutzerklärung geschrieben.\nIch war von Anfang an im Ausschuss und von Dezember 2018 bis Februar 2020 dessen Vorsitzender. Vierzehn Monate, und die Dinge, auf die es wirklich ankam, sind alle in dieser Zeit gelandet. Wir haben es am 11. Februar 2019 als gemeinnützig registrieren lassen, Nummer 1181953. Ich habe den gewerblichen Mietvertrag für das Gebäude geregelt. Dann haben wir das Zentrum eröffnet.\nDafür war der Vorsitz da. Nicht für Tagesordnungen und Protokolle. Dafür, ein Gebäude zu öffnen, in das ein paar hundert Haushalte hineingehen können. Freiwillige aus der Nachbarschaft betreiben es bis heute über die Bauabschnitte 1 bis 4 — drei Räume, eine Küche und ein Parkplatz, stundenweise vermietet an jeden aus der Siedlung, der sie haben will.\nEhrenamtliche Ausschüsse laufen auf gutem Willen, und guter Wille ist kein Governance-Modell. Also habe ich Leute an der Satzung gemessen, mich selbst eingeschlossen. Ich habe gefragt, warum wir von außen rekrutieren, wenn die Satzung sagt, bindet die Anwohner ein, und ich habe einen Rundbrief gestoppt, der in jedem Spam-Ordner der Siedlung gelandet wäre. Nicht um schwierig zu sein. Eine Anwohnervereinigung, die die Anwohner nicht erreichen kann, ist an der einzigen Aufgabe, die sie hat, bereits gescheitert, und ich habe die Links zur Behebung gleich mit der Beschwerde geschickt.\nDas Zentrum ist weiterhin offen, und ich bin nicht mehr im Ausschuss, und so gehört es sich. Was nur funktioniert, solange du danebenstehst und es hältst, war nie ordentlich gebaut.\nDiese Seite Dieser Blog ist eine statische Hugo-Seite mit dem Theme PaperMod. Er läuft auf Cloudflare Workers und liefert die gebaute Seite als statische Assets aus.\nIch schreibe hier über die Infrastruktur, mit der ich täglich arbeite: Proxmox VE, Ceph, Ansible, Netbox, Zertifikate und was ich mir in der Woche sonst angesehen habe. Es ist zum Benutzen geschrieben, mit den Befehlen und den Zahlen darin, denn ein Beitrag, dem du an der Tastatur nicht folgen kannst, ist Dekoration. Kein Marketinggerede. Wenn etwas raue Kanten hat, sagt der Beitrag das.\nKontakt Du findest mich auf LinkedIn oder in den Proxmox-Foren.\nWenn du Ceph oder Proxmox für dein Haus anschaust und ein ordentliches Gespräch darüber willst statt eines Pitches, schreib mir. Bring die Last, die Beschränkungen und das Budget mit, das du tatsächlich hast. Ich sage dir, was es leisten wird, was nicht, und wenn die ehrliche Antwort lautet, dass du behalten solltest, was du hast, und es ordentlich konfigurieren, dann bekommst du auch diese Antwort.\n","permalink":"https://blogs.damiendye.uk/de/about/","summary":"Damien Dye — Presales Engineer, Infrastruktur-Spezialist und Open-Source-Verfechter.","title":"Über mich"}]