Resumen

  • El 21 de agosto de 2026 a las 04:38:32 UTC, el objeto aut-num de AS210328 en RIPE registró su última modificación: la política pasó a importar y anunciar hacia AS48693, sustituyendo la política original de 2021 hacia AS12695 que aún muestran espejos desactualizados.
  • El 24 de agosto de 2026 a las 05:53:28 UTC, el certificado del único ROA localizado que cubría 185.218.138.0/24 —asignado al asID 205997, no a AS210328— quedó revocado y su validación marcada como fallida, dejando ese prefijo sin cobertura ROA válida.
  • Tres de los cuatro espejos del ecosistema aún describen estados anteriores: IPTrace conserva la política de 2021 hacia AS12695 y cuenta cero prefijos; PeeringDB reporta cero prefijos en un registro voluntario actualizado por última vez en 2022-07-27; e IPinfo clasifica el ASN como "Inactive".
  • Los coleccionistas de rutas observan otra cosa: tres prefijos IPv4 originados (77.91.65.0/24, 185.136.15.0/24 y 185.218.138.0/24), dos con ROA RPKI válidos de longitud máxima 24 y una topología solo de upstream con tres proveedores (AS202425, AS201814, AS48693), sin pares ni redes downstream observados.
  • Las afirmaciones comerciales del propio operador —peering físico directo con Yandex, Sberbank y Rostelecom, y reventa de recursos en la nube— carecen de corroboración independiente en ninguna fuente de enrutamiento o registro localizada en esta investigación.

Tres capas que cuentan historias distintas

Para entender qué es realmente AS210328, hay que separar tres capas de evidencia que frecuentemente se mezclan en la conversación pública: la capa registral, la capa de enrutamiento observado y la capa comercial declarada por el propio operador. Ninguna capa sustituye a las otras, y la divergencia entre ellas no se resuelve por decreto: se documenta.

En la capa registral, la identidad está bien establecida. El objeto aut-num AS210328, con as-name ALMAZ y organización ORG-ZA238-RIPE, se creó el 27 de diciembre de 2021 y fue modificado por última vez el 21 de agosto de 2026 a las 04:38:32 UTC. La organización ORG-ZA238-RIPE se llama AO ALMAZ, con país RU y número de registro 1196501003357; el contacto de abuso está registrado bajo el dominio propio y las observaciones del objeto remiten al mismo dominio. El registrador patrocinador es ORG-DNJ1-RIPE, con mnt-ref DN-MNT, FREENET-MNT y RETN-MNT.

Estos valores provienen de un espejo del whois de RIPE, no de la base de datos en vivo, por lo que deben tratarse como observaciones fechadas con posible desfase ([5]).

En la capa de enrutamiento, los coleccionistas independientes coinciden en lo esencial. Hurricane Electric atribuye AS210328 a AO ALMAZ, con tres prefijos IPv4 originados —77.91.65.0/24, 185.136.15.0/24 y 185.218.138.0/24—, dos anunciados, dos con ROA RPKI válidos, 512 direcciones IPv4 originadas, 717 rutas AS observadas y una longitud media de camino de 5.319 ([1]). ping.pe reporta el mismo trío de prefijos bajo el origen "ALMAZ - AO ALMAZ", con estado RPKI VALID para los dos primeros y NOT-FOUND para el tercero ([2]).

La consola de rpki-client lista exactamente dos ROAs para AS210328, ambos con maxlen 24 y ambos del repositorio RPKI de RIPE, lo que implica que AS210328 no tiene ROA para 185.218.138.0/24 ([3]).

La topología observada es otra cosa todavía: los tres vecinos observados por Hurricane Electric —AS202425 (IPV), AS201814 (MEVSPACE sp. z o.o.) y AS48693 (Rices Privately owned enterprise)— son relaciones del tipo upstream, sin pares ni downstream observados ([1]). Es importante ser preciso aquí: los "pares" que aparecen en coleccionistas de rutas se infieren de caminos AS observados, no de relaciones contractuales de peering. Aun con esa cautela, el patrón es coherente entre fuentes: una red que se alimenta exclusivamente de tránsito superior.

La secuencia fechada de agosto de 2026

El mecanismo que este artículo reconstruye —y que no estaba registrado como una sola secuencia en la cobertura previa— es temporal y verificable pieza por pieza:

  • 27 de diciembre de 2021: se crean AS210328 y ORG-ZA238-RIPE en RIPE según los espejos de whois; los espejos obsoletos conservan la política aut-num original hacia AS12695 ([5], [6]).
  • 2 de enero de 2022: última actualización de la información de peering público del registro 19111 de PeeringDB (el registro completo se actualizó por última vez el 27 de julio de 2022) ([0]).
  • 18 de febrero de 2026: comienza la validez del ROA del asID 205997 que cubre 185.218.138.0/24 ([4]).
  • 21 de agosto de 2026, 04:38:32 UTC: última modificación del aut-num AS210328; la política pasa a importar desde AS48693 accept ANY y exportar hacia AS48693 announce AS210328 ([1], [5]).
  • 24 de agosto de 2026, 05:53:28 UTC: el certificado del ROA del asID 205997 sobre 185.218.138.0/24 es revocado; su validación pasa a "Failed", dejando el prefijo en disputa sin ROA válido que lo cubra ([4]).
  • 19 de septiembre de 2026: fecha de captura de las diez instantáneas de fuente en las que se basa este paquete de hechos ([0]–[9]).

Ninguna fuente localizada establece una relación causal entre el cambio de política del 21 de agosto y la revocación del 24. Solo las fechas están observadas. La separación de tres días es un hecho; su interpretación es una pregunta abierta que este artículo deja formulada en lugar de resolverla.

El prefijo en disputa: 185.218.138.0/24

El tercer prefijo concentra la mayor parte de la fricción en la evidencia. La página de detalle del ROA muestra que el único ROA localizado que cubre 185.218.138.0/24 con maxlen 24 fue emitido al asID 205997 —no a AS210328— con validez del 18 de febrero de 2026 al 1 de julio de 2027, y que su validación ahora falla porque el certificado fue revocado el 24 de agosto de 2026 ([4]). Una síntesis previa de BTW registró que ese prefijo se encuentra en estado multi-origen (MOAS) entre AS209630, AS205997 y AS210328, y que el registrante del prefijo —Vlad Cojuhari— difiere del registrante del AS de origen, AO ALMAZ ([9]).

Los descriptores de prefijo en Hurricane Electric asignan 185.136.15.0/24 y 185.218.138.0/24 a Vlad Cojuhari, y 77.91.65.0/24 a IP-FI-FotonTel ([1]).

El resultado neto tras el 24 de agosto es un prefijo anunciado por tres sistemas autónomos, sin ROA válido para ninguno de ellos según los datos capturados, y con una discrepancia de titularidad entre la capa de prefijo y la capa de AS. Para un operador que vende el servicio "BGP ANNOUNCEMENTS" como producto comercial, esta es la parte de su propia huella de red donde la evidencia está más lejos de las buenas prácticas de seguridad de enrutamiento.

El ecosistema de espejos que no se ha puesto al día

La divergencia entre fuentes no es un detalle técnico: define lo que un lector sin acceso a consultas en vivo creería sobre esta red. Tres espejos cuentan historias distintas de la misma capa registral y de visibilidad:

  • IPTrace muestra el nombre ALMAZCLOUD con el sitio almazcloud.network, fecha de registro 2021-12-27 y fecha de actualización 2021-12-28, reproduce una política aut-num antigua de importar desde AS12695 con admin-c/tech-c DUMY-RIPE, y cuenta cero prefijos IPv4, cero IPv6 y cero redes de peering, junto con tres instalaciones en Moscú (M9, IXcellerate MOS1 y Berzarina Data Center) ([6]).
  • PeeringDB, en su registro 19111, lista AS210328 como ALMAZCLOUD, organización AO ALMAZ, nombre largo "ALMAZ (DIAMOND) CLOUD NETWORK", tipo NSP, alcance regional, nivel de tráfico 10-20 Gbps, política general restrictiva, cero prefijos IPv4 e IPv6, las mismas tres instalaciones moscovitas, y el sitio almazcloud.network ([0]).
  • IPinfo clasifica AS210328 como "Inactive" con cero prefijos, según lo registrado por una síntesis previa de BTW ([9]).

Frente a ellos, los coleccionistas de rutas observan entre dos y tres prefijos activos ([1], [2]). PeeringDB es un registro voluntario y autogestionado: documenta la declaración de huella del operador, no demuestra la operación de un servicio, y su marca temporal de 2022 significa que no puede corroborar el peering actual ([0], [8]). La lección metodológica es general: cuando un objeto RIPE cambia y los espejos no lo siguen, la "verdad" que ve el público depende de qué espejo consulte, y ninguna instantánea de búsqueda sustituye a la consulta directa de la base de datos en vivo.

Lo que el operador vende y lo que la red muestra

La capa comercial declarada es la más elaborada. El propio sitio de almazcloud.network se presenta como DIAMOND (en ruso, ALMAZ), proveedor de servicios en la nube, con cinco productos con precios: CLOUD CONNECT desde 499 USD al mes por puerto físico de 10G; BGP ANNOUNCEMENTS desde 99 USD al mes por prefijo; NO-BGP GRE TUNNEL desde 99 USD al mes por 100 Mbps; CORPORATE CLOUD VPN desde 9 USD al mes por usuario; y CLOUD RESELLING desde 99 USD al mes por nube conectada.

El sitio anuncia además una "conexión física directa de peering con Yandex, Sberbank, ROSTELECOM, Selected y otros proveedores de nube conocidos" y la reventa de recursos de Yandex, Sberbank y Rostelecom ([7]).

Ninguna fuente de enrutamiento o registro localizada en esta investigación corrobora las sesiones de peering con esas redes ni la entrega de servicios a clientes. Los coleccionistas observan solo tres upstreams y ningún par o downstream ([1], [2]). Esto no prueba que los servicios no existan: prueba que la evidencia pública disponible hoy no los verifica.

Un análisis previo de BTW sobre los límites de la evidencia lo formuló con precisión: las capas de registro, enrutamiento, DNS, sitio web y certificados responden preguntas distintas y ninguna, por sí sola, prueba la operación de un servicio en la nube; la ausencia de huella observada tampoco prueba que la red esté inactiva o que el servicio no exista ([8]).

Qué verificaría la siguiente etapa

La pregunta operativa no es retórica: hay condiciones observables concretas cuya aparición verificaría o falsificaría las afirmaciones del operador. Reconsultar los objetos RIPE aut-num y ORG-ZA238-RIPE directamente para detectar cambios posteriores al 21 de agosto de 2026. Revalidar RPKI para 185.218.138.0/24 y comprobar si se emitió algún ROA de cobertura para AS210328, AS205997 o AS209630 después de la revocación del 24 de agosto. Vigilar el registro 19111 de PeeringDB ante cualquier actualización posterior a 2022 y a los coleccionistas de rutas ante cualquier par o downstream recién observado.

Y comprobar los puntos finales DNS, TLS y HTTP del dominio bajo el marco de límites de evidencia ya establecido ([0]–[9]).

Mientras esas condiciones no se observen, la posición correcta frente a AS210328 es la que dictan los datos fechados: identidad registral corroborada, dos prefijos con ROA válidos, un prefijo en disputa sin ROA después del 24 de agosto, topología solo de upstream y afirmaciones comerciales sin corroboración independiente. Fuentes