Resumen
- El hecho de infraestructura más claro de TEAMFELNULL actualmente es una conexión operativa de 25 Gbps para AS58790 en INIXP en Tokio; esto es capacidad de borde de red, no prueba de 25 Gbps de tráfico de clientes, inventario de servidores, almacenamiento o capacidad de nube vendible.
- Cuatro listados de instalaciones en Tokio hacen que el banco de pruebas sea físicamente plausible, pero no establecen cuatro racks independientes, cuatro despliegues alimentados, dominios de falla separados, ni ningún derecho a la resiliencia anunciada por los operadores de centros de datos subyacentes.
- La superficie de servicio pública es una comunidad de servidores de juegos, proyectos de software y un bot de Discord, mientras que los términos comerciales, garantías de soporte, copias de seguridad, objetivos de restauración, protecciones de facturación y exportación de datos alojados permanecen sin documentar; los usuarios deben tratar el entorno como un banco de pruebas educativo a menos que la evidencia privada demuestre más.
Un puerto de 25 Gbps, cuatro nombres de instalaciones y un silencio importante
El número más fuerte asociado a TEAMFELNULL es 25 Gbps. Aparece en elregistro actual de PeeringDB para AS58790, donde se muestra “SERVER-G TestBed TeamFelNull” con una conexión operativa a Japan Community IX, o INIXP. Lapágina propia de PeeringDB del exchangerepite la entrada de 25 Gbps junto a AS58790, con una dirección IPv4 y una IPv6 del exchange. Unavista de Internet Society Pulse de la misma membresía del exchangecaracteriza la red como educativa o de investigación e igualmente reporta un puerto de 25 Gbps. Estos registros son inusualmente concretos para una huella pública tan pequeña.
También son fáciles de malinterpretar. La velocidad de un puerto es la tasa nominal de una conexión de intercambio. No es una medición de tráfico sostenido, un compromiso de cliente disponible, ni el rendimiento de las máquinas detrás del enrutador. No dice nada sobre cuántos servidores físicos están instalados, cuánto almacenamiento está sano, cuánta potencia de rack se ha reservado, o si algún host puede aceptar otra máquina virtual. PeeringDB explícitamente deja sin divulgar el nivel de tráfico de AS58790, la proporción de tráfico y el alcance geográfico.
Reporta hechos de familia de direcciones e interconexión, pero no carga vendida, curva de utilización ni compromiso de nivel de servicio.
El mismo perfil enumera cuatro instalaciones, todas en Tokio: AT TOKYO CC1/CC2, Equinix TY8, NTT DATA Otemachi Building y Otemachi Place West Tower. Eso crea un esbozo convincente de una red metropolitana. Sin embargo, sigue siendo un esbozo. Un listado de instalación en una base de datos de interconexión puede reflejar un puerto físico, una conexión cruzada, acceso a través de otra parte, o un servicio entregado de forma remota. No revela, por sí mismo, un servidor propiedad de TEAMFELNULL, un rack completo alquilado, un circuito de alimentación, o una réplica de almacenamiento en cada lugar.
El registro no publica identificadores de puerto, cantidades de racks, consumo de energía, contrapartes de arrendamiento ni números de serie de servidores.
Esa distinción es el centro de la historia. TEAMFELNULL tiene suficiente evidencia de red visible para mostrar que AS58790 no es meramente un nombre en una página web abandonada. No tiene suficiente evidencia operativa pública para respaldar una lectura convencional de proveedor de nube. Un cliente de nube compra la porción utilizable de una cadena: cómputo, memoria, almacenamiento, energía, refrigeración, rutas de red, hardware de reemplazo, mano de obra de soporte, continuidad de facturación y una forma de recuperar o migrar. La cifra de 25 Gbps describe solo un eslabón de esa cadena.
Por lo tanto, el silencio es más importante que el número destacado. Ninguna página pública revisada para este perfil ofrece un catálogo actual de planes de VPS, metal desnudo o alojamiento gestionado bajo el nombre TEAMFELNULL. Ninguna establece un tiempo de actividad garantizado, tiempo de respuesta de soporte, punto de recuperación, tiempo de recuperación, política de piezas de repuesto, límite de copia de seguridad, formato de exportación de datos, período de aviso de mantenimiento o regla de compensación. Esa ausencia no prueba que esos arreglos no existan de forma privada.
Significa que un posible usuario no puede derivarlos de la evidencia pública y no debe tratar una etiqueta de puerto de intercambio como un sustituto.
El nombre describe un banco de pruebas, no un proveedor de nube convencional
La identidad pública de AS58790 contiene su etiqueta de advertencia más útil: “TestBed”. PeeringDB lo clasifica como una red educativa/de investigación y lo coloca bajo la organización SERVER-G Group, con TeamFelNull como nombre alternativo. Lapágina de inicio pública de TeamFelNulldescribe una comunidad que ejecuta servidores de Minecraft modificados de temporada, juega, desarrolla modificaciones y adapta software de código abierto. Es un relato de experimentación y disfrute compartido, no un discurso de ventas dirigido a empresas que mueven cargas de trabajo de producción.
El lenguaje del grupo más amplio refuerza esa lectura. Lapágina del grupo SERVER-Gdice que proporciona entornos para jugar, aprender y desarrollar a largo plazo. Llama a AS63800 la red central y describe a TeamFelNull como un grupo socio que recibe recursos de red y servidor para desarrollo, operaciones y juego. Esa redacción es importante porque separa al menos tres cosas que de otro modo pueden difuminarse: el grupo paraguas, la actividad de backbone de AS63800 y el banco de pruebas de TeamFelNull asociado con AS58790. Los registros públicos muestran afiliación y soporte de recursos; no revelan un contrato que transfiera la propiedad de racks, enrutadores o servidores a TeamFelNull.
Lahistoria pública de AS63800 de SERVER-Gllama al backbone una red sin fines de lucro construida para aprender tecnología de Internet. Su cronología es franca sobre la experimentación: obtener recursos de direcciones, encontrar proveedores ascendentes, probar exchanges comunitarios, cambiar conectividad y construir herramientas de monitoreo de rutas. Lapágina de acerca del grupodice que su ubicación principal de actividad es Tokio y establece propósitos que incluyen conectividad, aprendizaje, construcción y desarrollo técnico. Esas páginas conciernen a AS63800 y SERVER-G Group, no a un balance corporativo documentado por separado para AS58790. Ayudan a explicar el entorno alrededor de TEAMFELNULL, pero no prueban que cada activo o política de AS63800 pertenezca al banco de pruebas.
Este límite importa cada vez que la palabra “grupo” se confunde con una garantía legal u operativa. El sitio público de TEAMFELNULL usa “TeamFelNull” y “FelNull”; los registros de enrutamiento usan “TeamFelNull”, “SERVER-G Group” y “SERVER-G TestBed TeamFelNull”. Los términos del bot describen a FelNull como una organización. Ninguna de las páginas revisadas identifica un registro de empresa de alojamiento convencional, un nombre legal de contratación para servicios de infraestructura, una dirección de facturación, o la parte que debería créditos de servicio a un cliente. Sería inseguro inferir esos detalles solo de la marca.
Incluso ladescripción del backbone de SERVER-Gtraza una línea entre la actividad comunitaria y el uso comercial limitado. Dice que la red es liderada por estudiantes y básicamente sin fines de lucro, cita limitaciones financieras y señala que algún uso de direcciones ayuda a financiar actividades y operaciones. También dice que esas direcciones comerciales no se propagan ni se utilizan desde AS63800. Eso es evidencia de un contexto económico mixto, no evidencia de que AS58790 ofrezca un producto de alojamiento comercial estándar. Hace que la aclaración a nivel de contrato sea más necesaria: ¿quién factura, quién posee el hardware, qué red transporta el servicio y quién sigue siendo responsable cuando una parte falla?
Un banco de pruebas puede ser técnicamente competente y útil. Puede proporcionar conectividad real, alojar servicios valiosos y enseñar a los operadores lecciones que los proveedores pulidos ocultan. Pero su asignación de riesgo es diferente. El soporte informal puede ser rápido cuando los voluntarios están disponibles y lento cuando el estudio, el trabajo o la vida intervienen. El hardware puede comprarse de forma oportunista. Las rutas de red pueden cambiar a medida que cambian los patrocinios o las relaciones comunitarias. Los usuarios que entienden ese trato pueden encontrarlo completamente apropiado.
Los usuarios que asumen continuidad empresarial porque vieron “25G” y cuatro nombres de instalaciones estarían comprando una promesa que el registro público no hace.
Lo que TeamFelNull realmente pone frente a los usuarios
Los servicios más visibles son específicos y orientados a la comunidad. El sitio de TeamFelNull presenta servidores de Minecraft de temporada, desarrollo de software y pequeños proyectos públicos. Supágina del bot de voz de Discordanuncia múltiples instancias de un bot de texto a voz, mientras que supágina de Reversiofrece una actividad de juego para Discord. Estas son superficies de usuario reales: las personas se conectan, envían contenido, esperan que el estado persista por algún período y notan cuando el servicio desaparece. Son mejor evidencia de un propósito operativo que una afirmación genérica de “nube”.
Lostérminos y aviso de privacidaddel bot proporcionan una vista rara del límite de datos. Dicen que los identificadores de usuario, servidor y canal pueden almacenarse para mantener el servicio funcionando; los nombres de usuario, apodos y mensajes pueden recopilarse para generar voz y conservarse solo durante el período necesario. El aviso promete medidas de protección razonables pero renuncia a la seguridad completa, permite que el servicio o los términos cambien sin previo aviso y renuncia a la responsabilidad por daños. Esas disposiciones se aplican a ese bot, no automáticamente a cada servicio de servidor o red, pero revelan el estilo del único contrato de usuario público localizado aquí: amplia discreción operativa, garantía limitada y ningún compromiso de restauración cuantificado.
El lado del software está documentado más completamente que el lado alojado. Untutorial del lanzador de TeamFelNullexplica un lanzador de juego personalizado y describe el escaneo antivirus durante su proceso de construcción. Elsitio de documentación de SERVER-Gse centra en ese lanzador, instalación y manejo de instancias de juego. Esto muestra un grupo capaz de producir instrucciones para los usuarios. El contraste es revelador: existe orientación pública para el software cliente, mientras que las páginas equivalentes para el aprovisionamiento de máquinas virtuales, durabilidad del almacenamiento, copia de seguridad del servidor, manejo de abusos, estado de incidentes y finalización de cuenta no son visibles.
Un listado histórico no oficial deservidores de Minecraft de Japónregistra un “TeamFelNull-24h-Server”, enviado en 2019, con un tiempo de actividad registrado muy bajo y un estado que indicaba que estaba caído. Esa entrada no puede establecer el estado de AS58790 en 2026. Puede describir una máquina, dirección y período de operación diferentes, y las sondas de terceros pueden fallar por muchas razones. Es útil solo como una señal de mercado: el nombre TeamFelNull se ha asociado a un servidor de juego público, y al menos un endpoint antiguo no permaneció continuamente accesible. Se necesitarían monitoreo actual, un archivo de incidentes o una declaración del operador para conectar esa historia al banco de pruebas de hoy.
Los servicios públicos también exponen diferentes patrones de dependencia. Un servidor de juego necesita cómputo, memoria, almacenamiento, software compatible con la versión y una ruta estable; un bot de voz depende adicionalmente de Discord y motores de voz fuera del control de TeamFelNull. Un lanzador puede seguir siendo utilizable en la computadora de una persona incluso si el servidor comunitario desaparece, pero las descargas, los paquetes de mods o las dependencias de autenticación pueden no. Agrupar todo esto en “alojamiento” oculta quién controla qué falla.
TEAMFELNULL puede operar la aplicación y algunos servidores mientras SERVER-G u otra parte controla el enrutamiento, una instalación controla la energía y las plataformas externas controlan la identidad y la distribución.
Por eso, la “capacidad orientada al cliente” debe interpretarse de manera estricta aquí. Hay evidencia de que los recursos se ponen a disposición de los usuarios y comunidades socias. No hay un recuento público de clientes que pagan, instancias activas, servidores gestionados, volúmenes de almacenamiento o núcleos reservados. La imagen operativa correcta es un conjunto de aplicaciones comunitarias respaldadas por una red educativa, con un grupo no cuantificado de recursos físicos y virtuales. Cualquier declaración más fuerte necesita un inventario actual y los contratos que conectan ese inventario con la identidad de red.
Donde el sistema físico puede tocar Tokio
El rastro de instalaciones de AS58790 es enteramente metropolitano. Las páginas de instalaciones individuales de PeeringDB listan el banco de pruebas enAT TOKYO CC1/CC2,Equinix TY8,NTT DATA Otemachi BuildingyOtemachi Place West Tower. Estos registros corroboran los cuatro nombres en el perfil de red, pero su precisión termina en la presencia. No muestran qué edificio en una etiqueta de campus combinado se usa, si la conexión es física o extendida remotamente, o si hay cómputo instalado junto al puerto de red.
Las instalaciones subyacentes son sustanciales.El propio relato de AT TOKYOdice que CC1 tiene 140,000 metros cuadrados de área total de piso y describe múltiples alimentaciones eléctricas, UPS, generación de emergencia y monitoreo las 24 horas en todas sus instalaciones. Laespecificación de Equinix TY8da una dirección en Tokio, 40,418 pies cuadrados de espacio, redundancia de energía N+1 y redundancia de refrigeración N+20 por ciento. Latabla de cobertura operativa de Equinixdice que TY8 tiene cobertura en sitio 24/7.
En Otemachi Place, ladescripción del sitio New Otemachi de BroadBand Toweranuncia una potencia de rack estándar de 6 kVA, líneas duales de 200 voltios y 30 amperios, generadores N+1 capaces de funcionar hasta 72 horas sin repostaje, múltiples opciones de conectividad y soporte remoto. Supágina de servicios de redseparada ofrece soporte de diseño y operación para enrutadores, redes de almacenamiento y conexiones en la nube. Esas son capacidades del operador de la instalación disponibles en el edificio. No muestran que TEAMFELNULL compre un rack completo, dos circuitos, manos remotas o cualquier servicio particular de BroadBand Tower.
Este es el límite de propiedad en términos prácticos. El operador de la instalación controla la carcasa del edificio, la toma de servicios públicos, los generadores, la planta de refrigeración, el control de acceso y las condiciones bajo las cuales los técnicos llegan a un rack. Un cliente de coubicación controla solo lo que ha contratado: quizás un gabinete, un rack fraccional, una conexión cruzada o un puerto entregado de forma remota. El operador de red controla su configuración de enrutador y anuncios de direcciones. El grupo de aplicaciones controla el software y el estado del usuario en la medida en que tiene acceso.
El diseño resiliente de una instalación no puede compensar una sola fuente de alimentación en un servidor cliente, una conexión cruzada impaga, un disco fallado sin reemplazo o una base de datos de aplicación sin restauración probada.
Por lo tanto, la afirmación geográfica es tanto más fuerte como más estrecha que “global”. Los servicios pueden ser accesibles desde todo el mundo, y las rutas de Internet son globales por naturaleza. La evidencia física revisada aquí apunta a Tokio, Japón. No establece racks operados por la empresa en Europa, América del Norte, otras áreas metropolitanas de Asia ni siquiera Osaka. Tampoco cuatro nombres en Tokio crean necesariamente protección contra un desastre metropolitano, una falla común de proveedor ascendente o un solo error administrativo.
La localidad de datos para la infraestructura visible debe tratarse como centrada en Tokio hasta que un registro de activos actual demuestre lo contrario.
Para los usuarios, esa localidad tiene dos consecuencias. Primero, la latencia dependerá de la distancia a Tokio y de la ruta ascendente seleccionada; la palabra “global” no puede borrar la física. Segundo, es probable que los arreglos de gobierno para el acceso físico, la energía y cualquier dato almacenado sean japoneses en la práctica, incluso si los usuarios remotos se conectan desde otro lugar. El aviso público del bot no indica dónde está alojada su base de datos, y los listados de instalaciones no vinculan una aplicación particular a un edificio particular.
Un usuario que necesite garantía de residencia necesitaría detalles escritos de colocación, replicación y subcontratista en lugar de una ciudad inferida de los registros de enrutamiento.
Por qué cuatro registros de instalaciones no equivalen a cuatro sitios independientes
La redundancia comienza con la independencia, no con el conteo. Cuatro nombres de instalaciones pueden representar cuatro dominios de falla, pero también pueden representar un enrutador alcanzado a través de varias telas de interconexión, un servicio extendido entre edificios, conexiones cruzadas inactivas, o registros mantenidos para acceso planificado. PeeringDB es una valiosa base de datos de la industria, pero las entradas de red e instalación son contribuidas por los participantes.
El registro de AS58790 dice que su información de instalación se actualizó en febrero de 2026, lo que respalda la actualidad; todavía no expone las órdenes de circuito subyacentes ni la ocupación del rack.
La geografía misma invita a la precaución. Dos listados están en Otemachi, uno es una etiqueta de campus de AT TOKYO que cubre CC1/CC2, y uno es Equinix TY8 en Shinagawa. La entrada de PeeringDB de Otemachi Place señala una interconexión óptica con NTT DATA Otemachi Building. Ese enlace puede ser útil operativamente, pero también significa que dos nombres en una base de datos pueden ser alcanzables a través de una extensión física en lugar de dos despliegues de TEAMFELNULL separadamente alimentados. No debe inferirse una ruta exacta de esa posibilidad.
El registro establece una interconexión disponible entre los edificios, no la ruta o topología de AS58790.
La conexión INIXP añade otra capa. El exchange está presente en varias instalaciones de Tokio y Osaka, pero el listado de AS58790 no publica una ubicación de puerto en su perfil de red. Una conexión de intercambio de 25 Gbps podría entregarse en un sitio y transportarse a través de una red socia o circuito metropolitano. Sin una carta de autorización, registro de conexión cruzada, diagrama a nivel de dispositivo y declaración de diversidad de circuito, la entrega física sigue siendo desconocida. Las dos direcciones de exchange prueban una conexión lógica; no localizan el puerto de conmutación con suficiente precisión para mapear un cable.
La resiliencia de cómputo verdaderamente multisitio requeriría más evidencia. Como mínimo, un inventario actual mostraría servidores o almacenamiento alimentados en al menos dos sitios; la replicación tendría una dirección y rezago conocidos; la conmutación por error de DNS o enrutamiento tendría un desencadenante probado; los usuarios sabrían qué servicios pueden reiniciarse en otro lugar; y el diseño de recuperación evitaría un plano de gestión compartido. Nada en las páginas públicas establece que los entornos de Minecraft, los datos del bot de Discord o los servicios de desarrollo estén replicados entre instalaciones.
Es posible que lo estén. No está demostrado.
La misma precaución aplica a la diversidad de proveedor ascendente. Un enrutador puede escuchar múltiples rutas mientras que todo el tráfico de clientes aún depende de un proveedor de transporte, un punto final de túnel, una cola metropolitana o una autoridad de configuración. La historia pública de SERVER-G describe múltiples relaciones a lo largo del tiempo y la retirada de algunos exchanges comunitarios en el extranjero en diciembre de 2024. Su política de interconexión permite explícitamente túneles GRE, SIT y WireGuard, así como conexiones en exchanges.
Los túneles son herramientas legítimas para un banco de pruebas, pero un vecino BGP lógicamente separado sobre el mismo circuito de acceso subyacente no es diversidad física.
Una declaración rigurosa de redundancia identificaría la capa en la que existe la independencia. Sesiones BGP separadas protegen contra una falla de vecino solo si otra ruta utilizable permanece. Alimentaciones de energía de instalación separadas protegen un rack solo si el servidor tiene fuentes de alimentación duales conectadas correctamente. Edificios separados protegen aplicaciones solo si existen datos actuales en ambos y los operadores pueden redirigir a los usuarios. Contactos de soporte separados protegen la recuperación solo si más de una persona tiene credenciales y acceso físico.
La evidencia pública de TEAMFELNULL confirma ninguna de esas combinaciones de extremo a extremo, por lo que cuatro etiquetas de instalación deben leerse como alcance de interconexión, no continuidad de servicio de cuatro sitios.
Capacidad: el único número duro está en el borde del exchange
La capacidad no es un número. Es una pila de límites, y el límite activo más bajo gobierna el servicio. El puerto de exchange de 25 Gbps es capacidad de red lógica instalada en una interconexión. PeeringDB etiqueta la conexión como operativa, lo que es más fuerte que un plan futuro. Pero el rendimiento utilizable podría ser menor debido a los límites de reenvío del enrutador, la política del proveedor ascendente, la congestión, el transporte entre un rack y el exchange, el tamaño de los paquetes, los ataques o los cuellos de botella de la aplicación.
La capacidad vendida podría ser aún menor—o inexistente si el banco de pruebas no está vendiendo ancho de banda.
El espacio de direcciones es otro tipo de capacidad. PeeringDB enumera cinco prefijos IPv4 y 50 prefijos IPv6 para AS58790, mientras quela vista general de AS de Cloudflare Radaridentifica la red en Japón y expone vistas de tráfico cuando existen suficientes observaciones. Unavista de enrutamiento separada de Cloudflarepresenta espacio de direcciones anunciado, conexiones, estado RPKI y actividad BGP. Los conteos de prefijos describen granularidad de enrutamiento, no servidores. Un /24 puede numerar 256 direcciones IPv4, pero una dirección puede estar sin usar, identificar un enrutador, asignarse virtualmente o servir a muchos dominios detrás de un host.
Los conjuntos de datos de terceros ilustran por qué una fecha y definición deben viajar con cada número. Lapágina de IPinfo para AS58790actualmente enumera dos bloques /24—44.30.37.0/24 y 44.30.62.0/24—junto con varios proveedores ascendentes observados y un puñado de direcciones que respondieron a sondas. Unavista de CIDR Reporttambién muestra dos anuncios /24 y 512 direcciones IPv4 originadas en su vista de colector. Esas observaciones respaldan el enrutamiento IPv4 actual, pero ninguna nos dice cuántas máquinas existen o si una respuesta provino de cómputo cliente.
Otros agregadores entran en conflicto. Unapágina de registro reflejadareproduce el nombre AS de JPNIC y un rango IPv6 2401:d20:1020::/44 pero no reporta ningún rango IPv4. Lapágina AS de IP2Locationmuestra un /24 y un IPv6 /46, mientras que lapágina de IPGeolocationreporta cero rutas a pesar de reproducir la identidad AS. Estas no son instantáneas equivalentes; las fechas de recolección, la visibilidad de rutas y los métodos de clasificación difieren. La contradicción es evidencia sobre los límites de los datos del agregador, no una razón para promediar los números.
Ninguna fuente pública revisada declara núcleos de CPU, memoria, nodos de metal desnudo, máquinas virtuales, capacidad de disco, redundancia de almacenamiento, energía reservada, consumo promedio de energía o unidades de rack libres. Ninguna fuente separa la capacidad diseñada de la capacidad instalada, alimentada, operativa y utilizable por el cliente. Las cifras a nivel de instalación no pueden llenar el vacío. Los 40,418 pies cuadrados de Equinix en TY8 pertenecen a la instalación, no a AS58790.
La especificación de rack estándar de 6 kVA de BroadBand Tower es una característica de producto disponible, no prueba de un rack o derecho de TEAMFELNULL.
La capacidad económicamente significativa es la que puede sobrevivir a una falla mientras honra los compromisos. Si un servicio necesita 16 núcleos y 64 GB de memoria, un host de repuesto cuenta solo si es compatible, está alimentado, conectado y no ya reservado. Si el almacenamiento está replicado, la segunda copia cuenta solo si es reciente y recuperable de forma independiente. Si 25 Gbps llegan a un exchange pero el servidor tiene una interfaz de 1 Gbps, la aplicación no tiene 25 Gbps. Hasta que TEAMFELNULL publique o proporcione privadamente esas cifras de capa inferior, su capacidad de alojamiento vendible sigue siendo desconocida.
La historia del proveedor ascendente es real pero no está documentada limpiamente
AS58790 es visible como origen, y varias vistas públicas ven rutas que lo alcanzan. Eso es evidencia operativa significativa. IPinfo enumera Hurricane Electric, SDCC Japan-West Area y SERVER-G Group como proveedores ascendentes o pares, mientras que su traza de sonda de junio de 2026 a 44.30.37.1 atravesó redes japonesas antes de llegar a AS58790. La vista de colector de CIDR Report mostró AS38074 directamente adyacente a AS58790 para los dos /24 visibles. La página de enrutamiento de Cloudflare proporciona otro punto de vista en vivo. Juntas, estas fuentes respaldan la accesibilidad, pero no coinciden en un gráfico de proveedor estable.
Hay varias razones benignas. BGP se observa desde colectores particulares en momentos particulares. Una relación que parece un proveedor ascendente desde una ruta puede ser un par, una ruta de servidor de rutas o un servicio transportado a través de otra red. IPv4 e IPv6 pueden usar diferentes proveedores. Una sesión puede estar configurada pero inactiva, selectiva o visible solo desde algunas ubicaciones. El registro de exchange de PeeringDB muestra la conexión INIXP, pero marca a AS58790 como que no usa el servidor de rutas allí.
Eso significa que la presencia sola no revela qué sesiones bilaterales transportan realmente tráfico de producción.
La historia más amplia de SERVER-G es informativa pero no puede asignarse simplemente a AS58790. Registra relaciones de AS63800 con Vultr, Hurricane Electric, SDCC y otras redes en varias fechas, junto con retiradas y adiciones posteriores. Lapolítica de interconexión de AS63800requiere números AS globales, tamaños de prefijo mínimos, ROAs, registros IRR y contactos de PeeringDB; también dice que algo de inestabilidad se tolera porque la red es experimental. Esas son políticas declaradas para AS63800. Sugieren la cultura que rodea al banco de pruebas, no una promesa vinculante de tiempo de actividad para AS58790.
La pregunta de propiedad se encuentra dentro de la pregunta de enrutamiento. PeeringDB coloca a AS58790 bajo SERVER-G Group y usa felnull.dev como su sitio web. La página pública del grupo dice que AS63800 es la red central y proporciona a TeamFelNull recursos. Por lo tanto, es razonable ver a AS58790 como un banco de pruebas de TeamFelNull respaldado por SERVER-G. No es razonable asumir que TeamFelNull posee cada contrato de proveedor ascendente, cada conexión cruzada o los recursos de direcciones que origina. Un cliente necesita saber qué parte puede renovar, cancelar o reconfigurar cada dependencia.
La diversidad de rutas también tiene un componente de plano de control. Si una persona, una configuración de enrutador o un conjunto de credenciales controla cada sesión, múltiples proveedores ascendentes no protegen contra un filtro de ruta erróneo o una retirada accidental. Una fuga de ruta, origen inválido, autorización de ruta vencida o filtro demasiado amplio puede hacer que servidores saludables sean inalcanzables.
Las vistas públicas muestran que el enrutamiento existe; no publican control de cambios, acceso fuera de banda, copias de seguridad de configuración, enrutadores duales, reversión automática ni un rol de operaciones de red 24 horas.
Lo que resolvería el problema es específico y modesto: cartas o facturas actuales que establezcan tránsito y transporte activos; una topología que muestre qué conexiones son físicas, virtuales o en túnel; evidencia de colector para ambas familias de direcciones; registros de autorización de ruta válidos; y una prueba de conmutación por error que demuestre que el tráfico sigue siendo utilizable cuando se retira la ruta principal. Hasta entonces, la evidencia del proveedor ascendente merece una confianza media como instantánea y una confianza baja como garantía de redundancia.
Energía, hardware y manos son la superficie de control oculta
Los registros de red tienden a dominar porque son públicos. Sin embargo, la mayoría de las fallas de alojamiento se resuelven en una capa mucho menos visible: alguien encuentra la fuente de alimentación, el disco, el módulo de memoria, el óptico, el ventilador o el cable fallido y lo reemplaza. TEAMFELNULL no publica ningún inventario de hardware, política de ciclo de vida o stock de repuestos. Un puerto de 25 Gbps puede permanecer perfectamente saludable mientras un servidor de aplicación individual está fuera de línea por falta de un componente compatible.
La resiliencia de la instalación ayuda solo hasta la entrega al cliente. AT TOKYO anuncia múltiples alimentaciones, UPS, generadores y monitoreo 24 horas. Equinix anuncia energía N+1 en TY8 y cobertura operativa las 24 horas. BroadBand Tower anuncia alimentaciones de rack duales, generación N+1 y soporte remoto en New Otemachi. Esos controles reducen el riesgo a nivel de edificio para los clientes que los compran y usan correctamente. No revelan si el equipo de AS58790 tiene fuentes de alimentación duales, si ambas alimentaciones están contratadas, si el soporte remoto está autorizado, o qué tan rápido puede TeamFelNull aprobar el trabajo.
La mano de obra de soporte es en sí misma capacidad. Lapágina de contactode TeamFelNull dirige las consultas a Discord. Eso puede ser conveniente para una comunidad, pero no proporciona una escala de severidad pública, compromiso de tiempo de respuesta, escalación telefónica, rol de guardia nombrado o canal alternativo si Discord no está disponible. Las páginas de SERVER-G proporcionan correo electrónico o Discord para interconexión, pero no hay un escritorio de incidentes público que prometa específicamente restauración para servicios alojados. Cuando una máquina falla a las 03:00, la diferencia entre “alguien puede notarlo” y “un técnico autorizado debe responder en 30 minutos” es el servicio.
La falla de existencias de hardware es especialmente importante para un banco de pruebas pequeño. Los grandes proveedores distribuyen piezas de repuesto y personal en muchos servidores; un operador comunitario puede tener máquinas únicas compradas en diferentes momentos. Sin una lista de compatibilidad y reemplazos almacenados, una placa base fallida puede convertir un intercambio de rutina en adquisición, viaje y reconstrucción. Ninguna evidencia pública dice si los servidores usan unidades de arranque reflejadas, almacenamiento intercambiable en caliente, gestión fuera de banda, interfaces de red duales o imágenes estandarizadas.
Sería incorrecto asumir un diseño empresarial robusto o hardware improvisado.
Los contratos de facturación y proveedores pueden crear la misma interrupción sin ningún equipo roto. Un pago de coubicación atrasado, recurso patrocinado vencido, acuerdo de transporte cancelado, problema de renovación de dominio o lista de acceso a instalaciones modificada puede desconectar un servicio saludable. La declaración de SERVER-G sobre limitaciones financieras hace que esta dependencia valga la pena examinar, pero no prueba ninguna dificultad actual. La evidencia requeriría contratos actuales, fechas de renovación, partes responsables y un plan de reserva o sucesión.
En su ausencia, la continuidad financiera es simplemente desconocida.
Los usuarios se ven afectados de manera diferente. Un jugador puede perder el acceso a un mundo de temporada; un desarrollador puede perder un servicio de compilación; una comunidad de Discord puede perder la salida de voz; un proyecto patrocinado puede perder una dirección o ruta. El costo puede ser inconveniencia más que ingresos, pero la pérdida de datos aún puede ser personal e irreversible. El estándar de resiliencia correcto debe seguir el uso prometido.
Un mundo de prueba puede tolerar tiempo de inactividad si se les dice a los usuarios; una base de datos que recopila identificadores o un mundo comunitario de larga duración necesita copia de seguridad, retención y reglas de restauración incluso cuando no hay dinero de por medio.
La falla comienza con la ambigüedad antes de llegar al rack
La primera ruta de falla no es necesariamente técnica. Es ambigüedad sobre lo que se prometió. Si los usuarios escuchan “recursos de servidor” y ven nombres de centros de datos, pueden asumir copias de seguridad, hosts de repuesto y recuperación gestionada. Si los operadores significan acceso de mejor esfuerzo para jugar y aprender, ambos lados pueden comportarse razonablemente y aún así chocar después de una interrupción. La reducción de riesgo más rápida es una descripción de servicio simple que diga qué está alojado, quién lo opera, qué es de mejor esfuerzo, qué tiene copia de seguridad y qué deben copiar los usuarios por sí mismos.
En el rack, la secuencia es familiar. Una alimentación eléctrica o fuente de alimentación falla; un puerto de conmutador, óptico o tarjeta de red se cae; un disco o controlador corrompe el estado; la protección de refrigeración apaga el hardware; o el trabajo programado requiere un reinicio. El monitoreo de la instalación puede identificar alarmas ambientales, pero la recuperación de la aplicación sigue siendo responsabilidad del cliente a menos que se hayan comprado servicios gestionados. Ninguna de las páginas públicas vincula a TEAMFELNULL con un paquete de soporte remoto particular, tienda de repuestos o ventana de mantenimiento.
En la capa de red, un puerto de exchange, circuito metropolitano, punto final de túnel, sesión de proveedor ascendente o anuncio de ruta puede fallar. Las cuatro entradas de instalación no revelan si esos elementos son diversos. Un puerto INIXP de 25 Gbps es una ruta útil, pero el exchange se describe a sí mismo como de mejor esfuerzo sin términos de servicio divulgados en su listado público. La interconexión bilateral en un exchange no es lo mismo que tránsito completo a Internet, y una conexión de exchange no puede alcanzar todos los destinos sin pares adecuados o un proveedor ascendente.
Por lo tanto, un servicio orientado al usuario puede fallar para algunas redes mientras sigue siendo accesible desde otras.
En la capa de aplicación, las actualizaciones crean sus propias ventanas de reparación. TeamFelNull trabaja con Minecraft modificado y lanzadores personalizados, donde las versiones del servidor y del cliente deben alinearse. Una actualización fallida puede dejar a los usuarios varados incluso cuando el enrutamiento y el hardware están saludables. La documentación del lanzador muestra atención a la instalación y migración, pero no hay un cronograma público para el mantenimiento del servidor, reversión, compatibilidad de base de datos o retención de mundos antiguos.
El estado de la aplicación es a menudo la parte más difícil de reconstruir porque una máquina nueva no puede recrear la historia perdida.
Las plataformas externas agregan dependencias correlacionadas. El bot de voz depende de Discord para identidad, eventos y acceso de usuario, y puede depender de uno o más motores de voz. Una interrupción o cambio de política en esos servicios puede hacer que el bot no esté disponible sin ninguna falla en AS58790. El contacto también depende de Discord, por lo que el servicio y su canal de soporte público principal pueden fallar juntos. Una página de estado en un dominio alojado de forma independiente, más escalación por correo electrónico, separaría esas rutas.
La población afectada no está cuantificada. La página de inicio invita a una comunidad; la página del bot muestra múltiples instancias de bot; el listado de juego antiguo registra un endpoint público. Ninguno da usuarios activos actuales, sesiones pico o el número de proyectos dependientes. Eso impide una estimación numérica de impacto. El impacto cualitativo es claro: el acceso comunitario, los identificadores almacenados, el estado del juego, la distribución de software y los recursos patrocinados pueden todos ser interrumpidos. Un plan de incidentes veraz nombraría estas clases sin reclamar un conteo de clientes que no ha sido divulgado.
La recuperación y portabilidad se detienen en el límite de la aplicación
La recuperación tiene dos preguntas separadas: ¿puede el operador restaurar el servicio, y puede el usuario irse? El registro público no responde ninguna para cómputo alojado. No hay frecuencia de copia de seguridad publicada, período de retención, copia fuera del sitio, prueba de restauración, punto de recuperación o tiempo de recuperación para los servidores de TeamFelNull. Tampoco hay una exportación documentada para una máquina virtual, base de datos, mundo de juego, registro de cuenta o volumen alojado. Un usuario no puede saber si un disco fallido significa minutos de reversión, días de reconstrucción o pérdida permanente.
Hay una excepción estrecha y útil en el lado del cliente. La documentación del lanzador proporciona unprocedimiento de exportación de instanciaque crea un ZIP a partir de archivos locales seleccionados, y unaguía de migración del lanzadorseparada explica cómo copiar carpetas de instancia local entre versiones. Estas instrucciones mejoran la portabilidad para el entorno cliente de un jugador. No exportan mundos del lado del servidor, bases de datos de bot, credenciales, DNS, direcciones IP ni máquinas virtuales.
Ese límite es fácil de pasar por alto. Un jugador puede preservar mods y configuración pero aún así perder el mundo compartido. Un administrador de bot puede retener una comunidad de Discord pero perder preferencias almacenadas. Un desarrollador puede mantener el código fuente pero perder artefactos de compilación o secretos de despliegue. Un usuario de red puede mantener una imagen de aplicación pero no puede retener direcciones si los derechos de recursos pertenecen a otra parte. Cada capa necesita su propio método de exportación y restauración.
La recuperación multisitio es igualmente no probada. La lista de instalaciones ofrece lugares plausibles desde los cuales se podría construir resiliencia, pero ninguna evidencia pública mapea un servicio a dos sitios vivos o reporta rezago de replicación. Incluso si existe una segunda máquina, la conmutación por error exitosa requiere datos actuales, secretos, enrutamiento, DNS, capacidad y personas autorizadas. Un respaldo en frío sin una restauración probada puede tomar más tiempo que reparar el primario. Una réplica en caliente que comparte la misma cuenta administrativa puede fallar durante un compromiso.
La escalación de soporte debería ser parte del diseño de recuperación, no una ocurrencia tardía. El contacto solo por Discord puede funcionar durante el uso comunitario ordinario, pero un evento grave necesita una ruta independiente, una persona responsable, autorización de la instalación y una regla de decisión para gastar dinero en piezas o transporte. La sucesión también importa: más de un operador de confianza debería poder renovar dominios, acceder a enrutadores, contactar instalaciones y descifrar copias de seguridad. Ninguna página pública establece esa cobertura, por lo que sigue siendo una pregunta más que una acusación.
El paquete de portabilidad mínimamente creíble sería simple: una lista de datos propiedad del usuario; formatos de exportación; límites de copia de seguridad y retención; momento de eliminación; aviso antes del cierre planificado; un procedimiento para obtener la copia más reciente; y una prueba que demuestre que la copia puede restaurarse en otro lugar. Para servicios de juego, eso puede ser un archivo mundial más un manifiesto de versión. Para un bot, puede ser una exportación estructurada de configuración y confirmación de eliminación. Para un servidor virtual, puede ser una imagen de disco estándar y un registro de configuración.
Sin esos compromisos, los usuarios deben mantener sus propias copias siempre que sea técnicamente posible.
La localidad de datos está centrada en Tokio, pero los datos de aplicación siguen sin mapear.
La evidencia de enrutamiento e instalación apunta a Japón, especialmente Tokio. AS58790 está registrado con una identidad japonesa en conjuntos de datos de enrutamiento, las instalaciones de interconexión listadas están en Tokio, y las direcciones IPv4 observadas están generalmente geolocalizadas en Japón. Eso respalda una evaluación física centrada en Tokio. No prueba que cada byte de datos de aplicación permanezca en Tokio, porque las dependencias de software, las copias de seguridad, la entrega de contenido y los servicios de terceros pueden cruzar fronteras.
El bot es el ejemplo más claro. Sus términos dicen que los identificadores pueden almacenarse y los mensajes pueden procesarse para generación de voz, pero no nombran una ubicación de alojamiento, proveedor de base de datos, proveedor de voz o jurisdicción de copia de seguridad. Discord en sí mismo es una plataforma externa. La presencia de instalaciones de AS58790 no puede responder dónde almacena Discord los datos o dónde se procesa una solicitud de voz. Una afirmación de residencia de datos requeriría documentación a nivel de aplicación, no meramente un código de país de sistema autónomo.
Los servicios de juego y desarrollo tienen una incertidumbre similar. Un proceso de servidor puede ejecutarse en una máquina en Tokio mientras las descargas de mods provienen de otra plataforma, el código fuente reside en un repositorio global y las copias de seguridad—si las hay—están en otro lugar. Por el contrario, una dirección originada por AS58790 podría alcanzar equipo entregado remotamente a través de otra red. La geolocalización IP es una estimación, no prueba de un rack.
IPinfo advierte explícitamente que la ubicación registrada o inferida no siempre equivale al uso real, y el desacuerdo entre agregadores de enrutamiento muestra qué tan rápido se desvían las clasificaciones.
Esto importa incluso para un servicio comunitario. Los usuarios pueden preocuparse por el acceso legal, la eliminación, la respuesta a violaciones o simplemente la latencia de una dependencia lejana. El aviso de privacidad público da categorías amplias de datos recopilados y un concepto de retención necesaria, pero no una duración de retención fija o ubicación. También permite cambios sin previo aviso. Esos términos pueden ser proporcionales a un bot gratuito, pero no cumplen con la necesidad de un comprador de soberanía o localidad contratada.
Por lo tanto, la etiqueta de área de servicio “Global” debe leerse como alcance, no huella. Un sitio web, servidor de juego o bot de Discord puede atender a personas internacionalmente desde Tokio. Eso no convierte a TEAMFELNULL en un proveedor multirregión. El registro físico respalda un clúster metropolitano; el registro de aplicación no mapea los flujos de datos. Cualquier organización con requisitos de residencia debe pedir un mapa de datos específico del servicio que nombre el host principal, réplicas, copias de seguridad, procesadores externos y ruta de eliminación.
También hay una compensación de resiliencia. Mantener todas las copias en Tokio puede simplificar la localidad pero exponerlas a una interrupción metropolitana. Replicar en el extranjero puede mejorar la recuperación ante desastres pero cambiar la jurisdicción y latencia. Ninguna opción es inherentemente correcta. El problema es que la evidencia pública actual no revela la elección. Una respuesta confiable indicaría dónde reside cada copia, por qué, con qué frecuencia se actualiza y quién puede recuperarla.
Lo que los clientes deberían exigir—y el veredicto de diligencia debida
La primera solicitud debería ser un cronograma de activos y servicios, no un mapa de red brillante. Debería identificar la parte contratante, el servicio ofrecido, si hay pago involucrado, y el recurso exacto: núcleos, memoria, almacenamiento, espacio de direcciones, ancho de banda y soporte. Debería distinguir recursos dedicados de compartidos y declarar qué cantidades están instaladas, alimentadas, operativas, reservadas y aún disponibles. Un puerto de exchange nominal de 25 Gbps pertenece al cronograma, pero solo como un componente de interconexión.
La segunda solicitud debería mapear la responsabilidad. ¿Qué organización posee o alquila cada servidor? ¿Cuál tiene la cuenta de instalación, circuito de transporte y acuerdo de proveedor ascendente? ¿Quién controla los enrutadores de AS58790, DNS, credenciales de aplicación y facturación? ¿Qué instalación puede aceptar una solicitud de soporte de qué persona nombrada? La afiliación de SERVER-G y TeamFelNull es visible, pero las transferencias no lo son. Una tabla de responsabilidad de una página eliminaría gran parte de la incertidumbre actual.
La tercera solicitud debería ser una topología respaldada por evidencia. Debería mostrar instalaciones con precisión a nivel de ciudad, evitar exponer detalles sensibles del rack, y marcar circuitos físicos, circuitos virtuales y túneles de manera diferente. Debería identificar colas metropolitanas compartidas y dependencias de gestión, además del sitio que aloja cada servicio crítico. Una prueba de conmutación por error debería demostrar qué sucede cuando se retira un proveedor ascendente, puerto de exchange, enrutador, servidor o sitio. La presencia de marketing sola no es un resultado de prueba.
La cuarta solicitud debería cubrir energía y reparación. Los usuarios necesitan saber si los servidores tienen fuentes de alimentación duales, si se usan ambas alimentaciones de la instalación, si hay repuestos disponibles, y si el soporte remoto está contratado. El documento debería incluir aviso de mantenimiento, niveles de severidad, objetivos de respuesta y un canal de escalación independiente. El soporte de mejor esfuerzo puede ser aceptable si se declara claramente; el riesgo proviene de dejar a los usuarios inferir cobertura empresarial de las capacidades de los operadores de instalaciones.
La quinta solicitud debería cubrir datos. Debería declarar frecuencia de copia de seguridad, retención, cifrado, prueba de restauración, exportación de usuario, eliminación y lo que está excluido. Debería nombrar plataformas externas y la localidad de las copias primarias y de respaldo. Para mundos de juego de larga duración o bases de datos comunitarias, el operador debería proporcionar una exportación reciente antes del cierre planificado. Para servicios experimentales, la regla honesta más simple puede ser “sin copia de seguridad; mantenga su propia copia”, siempre que los usuarios puedan hacerlo realmente.
Finalmente, el usuario debería pedir prueba operativa actual en lugar de marca histórica. Elementos útiles incluyen un historial de estado reciente, observaciones de ruta fechadas, una atestación de inventario, un aviso de incidente de muestra y un registro de restauración exitosa. Ninguno necesita revelar secretos. Juntos mostrarían que existe capacidad por debajo del puerto de exchange y que la recuperación es más que una intención. Si esos elementos no están disponibles, la clasificación racional sigue siendo banco de pruebas educativo, y las cargas de trabajo deben elegirse en consecuencia.
El veredicto: banco de pruebas útil, plataforma de alojamiento no probada.
TEAMFELNULL SERVER-G Group tiene más sustancia de lo que su escasa huella corporativa sugiere inicialmente. AS58790 tiene una identidad actual en PeeringDB, una conexión operativa de 25 Gbps en INIXP, actualizaciones recientes de instalaciones y rutas globalmente visibles. TeamFelNull mantiene proyectos públicos, términos de usuario y documentación. SERVER-G describe una red educativa continua y reconoce abiertamente su carácter liderado por estudiantes, mayormente sin fines de lucro y sus limitaciones financieras. Estas son señales de actividad, no un registro vacío.
La evidencia aún se queda corta en el punto donde un servicio alojado se vuelve confiable. Cuatro listados de instalaciones no prueban cuatro despliegues. Un puerto de 25 Gbps no prueba rendimiento de servidor o capacidad de repuesto. Los anuncios de direcciones no cuentan máquinas. La resiliencia de la instalación no pasa automáticamente a través de un diseño de rack desconocido. Múltiples proveedores ascendentes observados no prueban transporte físicamente diverso. Las exportaciones de juegos del lado del cliente no protegen los datos del lado del servidor. El contacto por Discord no crea una garantía de respuesta.
El grado de evidencia de red apropiado es débil, no negativo. “Negativo” ignoraría la conexión de exchange viva, las rutas y los servicios públicos. “Medio” implicaría que la cadena operativa está suficientemente descrita para evaluar capacidad y recuperación. No lo está. La evidencia más fuerte está en el borde lógico; la más débil está donde los usuarios sufren pérdida: inventario de hardware, derecho de energía, durabilidad de almacenamiento, mano de obra de soporte, contratos, copias de seguridad y migración.
Para pasatiempo, aprendizaje y uso comunitario explícitamente de mejor esfuerzo, ese puede ser un trato perfectamente sensato. Los bancos de pruebas pequeños crean espacio para aprender BGP, ejecutar juegos especializados y construir herramientas sin la economía de una nube comercial. Su valor no debe medirse solo por papeleo empresarial. La condición esencial es el consentimiento informado: los usuarios deben saber que la infraestructura experimental puede cambiar, que el soporte puede depender de un equipo pequeño y que necesitan sus propias copias recuperables.
Para cargas de trabajo pagadas o consecuentes, la verificación privada es necesaria antes de la confianza. El operador necesitaría mostrar la asignación de recursos, la contraparte legal, los arreglos activos de instalación y proveedor ascendente, el diseño multisitio o de restauración, y los términos de portabilidad de datos. Un comprador debería probar la recuperación, no solo la conectividad. Si esas pruebas existen, la evaluación pública puede mejorarse.
Hasta entonces, TEAMFELNULL se entiende mejor como una red educativa centrada en Tokio con servicios comunitarios reales y un borde de exchange impresionante—no como una nube multisitio documentada.
Esa conclusión respeta ambos lados de la evidencia. No convierte la falta de divulgación en una afirmación de falla, y no convierte un enrutador bien conectado en un rack de cómputo resiliente. El puerto visible de 25 Gbps es el comienzo de la pregunta de capacidad. Para los usuarios de TEAMFELNULL, los hechos decisivos permanecen detrás de él: qué máquinas están alimentadas, qué datos pueden restaurarse, qué ruta sobrevive y quién actuará cuando se abra la ventana de reparación.