Resumo
- O Departamento de Telecomunicações da Índia registrou a CLOUDNET INTERNET SERVICE PRIVATE LIMITED como titular de uma autorização de serviço de Internet categoria B para Tamil Nadu, válida a partir de 10 de abril de 2023. Páginas de dados corporativos vinculam o mesmo endereço e dados de contato a uma empresa de Chennai constituída em 2021. Isso estabelece uma identidade regulada de ISP, e não um portfólio de produtos de computação em nuvem.
- AS150069 estava ativo em 10 de julho de 2026, anunciando
103.21.6.0/23, as duas rotas componentes/24e2001:df1:66c0::/48. O agregado IPv4 era visível desde outubro de 2022 e a rota IPv6 desde novembro de 2022. A autorização de rota atual era válida conforme o RPKI, e os registros eram mantidos recentemente. - Os coletores de rotas públicos mostraram apenas um vizinho imediato para AS150069: AS132774 da Niss Internet Services Private Limited. Isso constitui evidência de um único caminho de roteamento externo visível, e não prova que a Cloudnet não tenha interconexão privada ou circuito de backup. Também não é evidência de diversidade física de roteamento, failover automático ou capacidade excedente.
- IPinfo caracteriza AS150069 como um ISP de consumo com um ritmo diurno-noturno pronunciado e relata apenas um domínio hospedado no espaço de endereçamento. Esses são sinais úteis, não números auditados de clientes ou produtos. Nenhum catálogo de serviços, localização de data center, inventário de racks, oferta de VM, oferta bare-metal, serviço de armazenamento, compromisso de disponibilidade, política de backup ou procedimento de migração públicos da Cloudnet foi encontrado.
- Portanto, o rebaixamento responsável é passar de um suposto operador de nuvem para um pequeno ISP de Tamil Nadu atualmente roteado, cuja pegada comercial e rede física exatas permanecem não divulgadas. Sua resiliência depende da infraestrutura de acesso local, equipamentos de agregação alimentados, conexão com a Niss, conectividade upstream da Niss e mão de obra de suporte. Seriam necessárias evidências de cargas de trabalho hospedadas reais antes de discutir a Cloudnet como provedor de nuvem.
A hipótese da nuvem falha na primeira pergunta sobre o produto
A palavra "Cloudnet" pode fazer muito trabalho se deixada solta. Ela combina dois elementos de vocabulário de rede da moda, e a empresa controla recursos de numeração da Internet. Nenhum dos dois mostra que um cliente pode comprar uma máquina virtual, um banco de dados gerenciado, um bucket de armazenamento, um servidor bare-metal ou mesmo uma conta de hospedagem web comum. A distinção é importante porque um serviço de nuvem tem obrigações de falha e recuperação que um provedor de acesso pode nunca ter assumido.
O documento público mais sólido específico da empresa não é um catálogo de nuvem. É alista de autorizações de serviço de Internet do Departamento de Telecomunicações em 31 de janeiro de 2025. A entrada identifica a CLOUDNET INTERNET SERVICE PRIVATE LIMITED, número de licençaDS-11/401/2022-DS-III, categoria B, área de serviço Tamil Nadu, com data de vigência 10 de abril de 2023. O contato autorizado, endereço registrado e número de telefone correspondem aos registros corporativos e de Internet.
Apágina de serviços de Internet do Departamentoexplica o que significa a categoria B. É a autorização para fornecer serviço de Internet em uma área de serviço licenciada, definida como um círculo de telecomunicações ou área metropolitana. Ocompêndio de licenças unificadasdescreve acesso à Internet, IPTV e formas específicas de telefonia pela Internet dentro da autorização. A licença é uma prova material de que a Cloudnet pode operar como ISP em Tamil Nadu. Ela não certifica que a empresa construiu cobertura estadual, e não transforma uma autorização de acesso em evidência de hospedagem de TI.
Os registros de rede apontam na mesma direção.A visão geral do IPinfo para AS150069classifica a rede como ISP de consumo e encontra um ritmo de atividade diário pronunciado do tipo associado a pessoas usando uma conexão durante as horas de vigília. Relata um domínio hospedado, contra 512 endereços IPv4. O número de domínios hospedados tem limitações de medição: um domínio pode se esconder atrás de uma rede de entrega de conteúdo, um endereço pode hospedar muitos nomes, um serviço privado pode não ser detectável e os clientes de acesso podem executar servidores. Mesmo com essas ressalvas, um domínio observado não é evidência afirmativa de um parque de hospedagem.
A pegada pública da Cloudnet não fornece preços ou especificações para computação, armazenamento, backup, colocation ou infraestrutura gerenciada. Nenhum endereço de data center é nomeado. Nenhum fornecedor de servidor, número de racks, design elétrico, certificação, zona de disponibilidade, portal do cliente, acordo de nível de serviço, adendo de processamento de dados, histórico de incidentes, objetivo de recuperação ou formato de exportação é descrito. Uma empresa pode vender privadamente sem documentar cada serviço na web aberta, mas o ônus da prova não se inverte.
Na ausência de um produto e de uma superfície operacional, a alegação "nuvem" deve ser abandonada, não embelezada.
Isso deixa uma história diferente e mais fundamentada. A Cloudnet tem um sistema autônomo ativo, uma autorização de ISP de Tamil Nadu, uma pequena alocação IPv4, uma alocação IPv6 e uma dependência upstream visível. Esses são os ossos de uma rede de acesso. A infraestrutura física por trás deles é amplamente desconhecida, o que torna a resiliência mais difícil de avaliar, mas não torna a rede imaginária.
Uma empresa de Chennai e uma autorização de Tamil Nadu
Agregadores de empresas identificam a CLOUDNET INTERNET SERVICE PRIVATE LIMITED pelo número de identificação corporativaU64120TN2021PTC142654.A página da empresa no Toflerdata sua constituição em 8 de abril de 2021, indica um capital social autorizado de ₹1 milhão e um capital integralizado de ₹100.000, e nomeia Logasundari e Gopikrishnan como diretores.O registro do ZaubaCorpfornece o mesmo CIN, o registro em Chennai e o endereço de Kottivakkam, embora alguns campos de data em seus resumos sejam inconsistentes e não devam ser tratados como substitutos de um arquivamento atual.
O endereço é particularmente útil para a resolução de identidade. A lista de licenças coloca a empresa no terceiro andar do lote 11/236A, Vivekanandar Third Street, Kottivakkam, Chennai.O registro APNIC de AS150069usa o nome legal abreviado, CLOUDNET INTERNET SERVICE PVT LTD, e seu papel administrativo repete o mesmo endereço e número de telefone. Oregistro da alocação IPv4eo da alocação IPv6carregam o mesmo nome de rede,CNISPL, e a mesma cadeia de contatos. Não se trata simplesmente de empresas similares compartilhando um nome genérico; os registros convergem para uma única empresa.
Essa convergência também exclui vários homônimos. Uma outra Cloudnet Broadband Services Private Limited aparece em documentos de licença mais antigos de Haryana, e a Cloudnet Communications Private Limited aparece em tabelas de assinantes. Outras empresas em outros lugares usam Cloud Net ou Cloudnet como nome comercial. Eles não devem ser usados para preencher lacunas no catálogo de serviços, número de clientes ou histórico desta empresa. A âncora de identidade aqui é a licença de Tamil Nadu, o CIN, o endereço de Kottivakkam e AS150069.
A lista do DoT de 2025 é evidência de uma autorização naquela data de relatório. Não é um certificado de operação diária para julho de 2026. Por outro lado, as rotas ativas e os objetos de registro da Internet mantidos recentemente fornecem evidências técnicas muito mais frescas. Portanto, a empresa não deve ser descrita como meramente registrada ou historicamente licenciada. Seu sistema autônomo carregava um anúncio visível globalmente no momento da observação.
O endereço ainda não responde à questão de onde o equipamento de rede está localizado. Uma sede pode ser um escritório administrativo, um ponto de presença, ambos ou nenhum. O registro IPv4 inclui coordenadas13.427804, 80.14154212, mas a geolocalização de registro é um metadado fornecido pelo operador, não um levantamento de sala de roteadores. IPinfo coloca vários endereços ou roteadores observados dentro e ao redor de Chennai e Nagari, enquanto suas sondas recentes alcançaram endereços que responderam de pontos de vista na região de Chennai. Essa geolocalização é probabilística. Ela não pode identificar um terminal de linha óptica, provar a propriedade de um caminho de fibra ou estabelecer que um cliente é atendido em uma rua específica.
A declaração geográfica defensável é, portanto, estreita. A Cloudnet está autorizada para a área de serviço de Tamil Nadu, registrada em Chennai e opera um espaço de endereçamento que medidas independentes associam à Índia e à região de Chennai. As evidências públicas não mapeiam sua pegada comercial dentro de Tamil Nadu, não mostram que atende toda Chennai, nem divulgam um ponto de presença além do endereço registrado.
AS150069 fornece evidências operacionais atuais
Um sistema autônomo é uma unidade de política de roteamento, não uma empresa inteira. No entanto, AS150069 é a evidência mais clara de que a Cloudnet opera algo atualmente.A visão geral AS do RIPEstatrelatou o ASN como anunciado em 10 de julho de 2026. Suaresposta de prefixos anunciadoslistou o agregado IPv4103.21.6.0/23, as duas rotas mais específicas103.21.6.0/24e103.21.7.0/24, e o prefixo IPv62001:df1:66c0::/48.
O agregado IPv4 contém 512 endereços.O status de roteamento atualmostrou AS150069 como a única origem visível para o/23, visto por 326 dos 327 pares IPv4 participantes. Também mostrou os dois/24sob o agregado. Respostas de status separadas para103.21.6.0/24e103.21.7.0/24registraram a mesma origem e visibilidade. Não era um traçado visível por um único observador.
A linha do tempo é substancial.O histórico de roteamento para o/23começa o anúncio do agregado da Cloudnet em outubro de 2022 e continua até a data da pesquisa. Os dois/24apareceram pela primeira vez em dezembro de 2022. Sua visibilidade caiu fortemente durante um período começando em março de 2025, enquanto o/23abrangente permanecia amplamente visível, depois retornou à visibilidade ampla em maio de 2026. Isso é uma mudança na granularidade da rota e na propagação, não evidência de que o serviço do cliente parou. O tráfego endereçado aos dois blocos ainda podia seguir o agregado abrangente quando uma rota mais específica não era visível.
IPv6 não é apenas uma reserva de registro.O status de roteamento para2001:df1:66c0::/48mostrou AS150069 anunciando o prefixo para todos os 321 pares IPv6 participantes em 10 de julho. A rota foi vista pela primeira vez em novembro de 2022. O objeto de rota APNIC foi modificado em 8 de julho de 2026, dois dias antes da observação, e o registro de contato associado também foi atualizado em junho. Essas datas mostram administração contínua dos recursos. Elas não nos dizem quanto tráfego de cliente usa IPv6 nem quantos usuários o recebem.
A distinção entre capacidade instalada e utilizável é essencial. Um/23é um pool de endereços, não uma compra de largura de banda. Quinhentos e doze endereços IPv4 não significam 512 clientes, servidores, portas ou megabits. Um provedor pode usar endereços para interfaces de roteador, pools NAT de nível de operador, circuitos empresariais, infraestrutura ou inventário de reserva. Uma residência pode usar vários endereços públicos; muitas residências podem compartilhar um endereço. O número quase incompreensivelmente maior de endereços digitais dentro de um/48IPv6 é ainda menos útil como medida de capacidade.
Três anúncios IPv4 simultâneos também não triplicam a rede. O/23e seus dois/24componentes cobrem o mesmo espaço de endereçamento. Anúncios mais específicos podem apoiar política de roteamento, engenharia de tráfego ou transição operacional, mas os dados de roteamento visíveis não revelam qual propósito se aplica. Contar o agregado e os componentes como 1.024 endereços IPv4 exclusivos seria contar duas vezes os mesmos 512 endereços.
As rotas atuais suportam uma rede real e ativa. Elas não mostram a tecnologia de acesso do assinante, número de portas, trânsito agregado, uso de pico, contenção, backhaul, capacidade de cache ou velocidade do serviço. Essas quantidades determinam se uma conexão vendida é utilizável no pico noturno. Nenhuma pode ser calculada a partir do ASN.
Um vizinho imediato é o limite externo visível
Avisão de vizinhos AS do RIPEstatencontrou um único vizinho imediato em 10 de julho de 2026: AS132774. APNIC identifica esse ASN comoNiss Internet Services Private Limited, uma rede de Tamil Nadu registrada em Tirunelveli. Avisão AS150069 do relatório CIDRmostra independentemente a mesma adjacência e nenhum ASN downstream.
Os coletores de rotas veem a topologia, não os contratos. Um AS imediatamente anterior à Cloudnet nos caminhos observados é compatível com a Niss fornecendo trânsito, roteamento gerenciado ou outra forma de alcance upstream. Isso não revela preço, largura de banda comprometida, condições de burst, conexão física, fornecedor de fibra, aviso prévio, obrigação de restauração ou se a Cloudnet compra o serviço diretamente. O rótulo comercial "upstream" é uma inferência razoável aqui, mas o resultado público é estritamente um vizinho BGP externo visível.
A distinção se torna importante ao discutir redundância. Um único vizinho visível é evidência contra a afirmação de diversidade upstream demonstrada publicamente. Não é evidência de que a Cloudnet tem apenas um cabo. A Cloudnet poderia ter dois circuitos fisicamente separados em roteadores Niss diferentes enquanto ainda apresenta o mesmo caminho ASN. Poderia ter uma sessão de backup que estava inativa no momento da observação. Poderia receber uma rota padrão em uma conexão não visível pelos coletores. Inversamente, múltiplas sessões BGP para um único provedor poderiam convergir em um único conduíte, edifício, roteador ou domínio de energia.
O número de sessões e a diversidade física são coisas diferentes.
A Niss em si tem uma topologia mais ampla. Suaentrada PeeringDBlista peering NIXI Chennai e instalações em Chennai e Tirunelveli, enquantobgp.toolslista vários upstreams para AS132774. Esses são fatos auto-declarados e observados sobre a Niss, não propriedades herdadas pela Cloudnet. Um pacote da Cloudnet pode se beneficiar das opções da Niss após chegar a AS132774, mas o fato de a Niss ter vários upstreams não prova que a Cloudnet tem dois meios independentes de alcançar a Niss.
Avisão em tempo real do RIPEstat para o/23colocou repetidamente AS132774 imediatamente antes de AS150069 nos caminhos coletados. Muitos caminhos passavam então por AS9498 da Bharti Airtel além da Niss. Isso indica a cadeia visível naquele momento: Cloudnet, Niss, depois redes de trânsito maiores. Isso não significa que a Cloudnet tem um contrato direto com a Airtel, e não estabelece onde a conexão física ocorre.
Esse limite cria um mecanismo de falha claro. Se a única conexão ativa da Cloudnet para a Niss falhar, ou se uma sessão de roteamento for retirada sem alternativa funcional, todos os endereços da Cloudnet roteados globalmente podem se tornar inacessíveis mesmo que a fibra do cliente e os switches locais permaneçam energizados. Se a conexão com a Niss permanecer ativa, mas sua capacidade comprometida for exaurida, os usuários podem ver congestionamento em vez de uma falha total. Se um filtro de rota ou autorização estiver incorreto, uma família de endereços ou comprimento de prefixo pode falhar enquanto outros continuam.
A recuperação depende de fatos que não são públicos: se a Cloudnet tem um segundo circuito; se ele termina em equipamento de borda diferente; se esse circuito segue um caminho separado; se o failover é automático; se o backup tem capacidade suficiente para o pico normal; se IPv4 e IPv6 são ambos transportados; e qual empresa detém a primeira resposta. Um diagrama com duas linhas não provaria nada disso a menos que identificasse pontos comuns físicos e contratuais.
A rede física começa onde o BGP para de explicar
BGP pode mostrar que AS150069 torna um bloco de endereços acessível. Não pode mostrar o cabo das instalações do cliente até o primeiro equipamento ativo. Entre esses pontos podem estar um terminal de rede óptica, fibra de derivação, um acoplador, fibra de distribuição aérea ou subterrânea, um terminal de linha óptica, agregação Ethernet, backhaul alugado, painéis de conexão, fontes de alimentação e refrigeração. As evidências públicas não identificam quais desses elementos a Cloudnet usa ou possui.
A autorização de categoria B da empresa permite o serviço na área de serviço licenciada de Tamil Nadu; não certifica um design de acesso específico. A Cloudnet poderia operar fibra até a casa, Ethernet empresarial, links sem fio, serviço através de operadoras de cabo locais ou uma mistura. Nenhum mapa de cobertura, folha de planta, especificação de rede óptica, registro de torre ou parceria de cabo local pública foi encontrado. A presença de dois endereços IP que responderam navarredura recente do IPinfomostra que endpoints responderam a medições, não como a última milha foi construída.
Esse limite de propriedade desconhecida muda quem repara uma falha. Um cabo de derivação do cliente cortado pode ser de responsabilidade da Cloudnet ou de uma operadora local. Uma falha de fibra de alimentação pode exigir uma equipe de postes, um empreiteiro civil ou o proprietário da fibra alugada. Uma falha de agregação pode exigir ópticas de reposição, um switch, uma placa OLT ou uma fonte de alimentação. Uma falha de backhaul pode depender de outra operadora. O cliente vê um serviço indisponível, enquanto o reparo atravessa várias organizações.
A energia cria sua própria cadeia. O equipamento do cliente precisa de eletricidade. Armários de rua, sites sem fio, terminais de linha óptica, switches de agregação e roteadores de borda precisam de eletricidade. O fato de uma sede ter energia não diz nada sobre um nó de distribuição remoto. Um UPS pode cobrir uma interrupção curta, mas tem autonomia finita e baterias que envelhecem. Um gerador só ajuda se estiver instalado, abastecido, mantido e conectado ao local afetado. Nenhuma declaração pública da Cloudnet dá autonomia de backup, cobertura de gerador, manutenção de bateria, alimentações duais ou arquitetura elétrica do local.
O inventário de hardware é importante para uma rede pequena porque a peça que falha pode ser barata, mas operacionalmente específica. Um módulo óptico de reposição pode restaurar um link rapidamente se for compatível e estiver disponível. Uma placa de linha, fonte de alimentação ou chassi de acesso que falha pode levar mais tempo se precisar ser encomendado. Os backups de configuração devem estar atualizados e utilizáveis no equipamento de reposição. O registro público não contém dados sobre tempo médio de reparo, política de estoque, lista de fornecedores ou janela de manutenção.
A mão de obra de suporte é, portanto, parte da capacidade. Uma rede pode ter largura de banda não utilizada e ainda estar indisponível porque nenhum técnico pode alcançar um corte, nenhum engenheiro pode alterar uma rota ou nenhum contato autorizado pode escalar com um upstream. Os registros de registro e licença da Cloudnet publicam uma única cadeia de contato administrativo, mas esses registros não descrevem um centro de operações de rede com pessoal, cobertura de campo 24 horas, sistema de tickets ou escala de escalada. Seria errado transformar um número de contato em uma promessa de nível de serviço.
A questão da localização física deve permanecer em aberto. Kottivakkam é um local de sede registrada. As coordenadas do registro sugerem outro ponto no norte de Tamil Nadu, e medições de terceiros associam endereços a Chennai, Nagari e outros rótulos de Tamil Nadu. Os bancos de dados de geolocalização IP podem refletir o registro do endereço, locais de usuários inferidos ou viés de medição. Não há evidência de que a Cloudnet tenha um rack em um data center nomeado ou possua equipamento em um local específico.
Faturamento, suporte e contratos podem interromper uma rede intacta
Nem toda falha de serviço começa com um cabo cortado. Um provedor de acesso deve identificar clientes, autorizar sessões, emitir faturas, aceitar pagamentos, aplicar mudanças de plano e distinguir uma conta inadimplente de uma falha de rede. Dependendo do design, a autenticação pode depender de um banco de dados de assinantes, servidor RADIUS, gateway de rede de banda larga, sistema de gerenciamento de rede óptica ou plataforma de um revendedor. O registro público não divulga quais desses elementos a Cloudnet usa. Estabelece que a administração do cliente é uma camada operacional separada do BGP.
Essa distinção é fácil de ver de fora. AS150069 pode permanecer visível globalmente enquanto uma conta é incapaz de se conectar. Um pagamento creditado no razão errado, uma credencial expirada, um servidor de autenticação com falha ou uma flag de suspensão incorreta podem se apresentar como uma falha no roteador do cliente. O pessoal de campo pode encontrar níveis ópticos saudáveis e um caminho upstream intacto, mas o serviço permanece indisponível até que o controle da conta seja corrigido. Um coletor de rotas não registrará nada disso.
A continuidade do faturamento também é importante durante um incidente maior. Os clientes precisam de um canal acessível para relatar falhas e determinar se um pagamento, dispositivo ou falha de área é responsável. O pessoal precisa de registros de conta e rede atualizados. Se a mesma falha de energia, servidor ou conectividade derrubar tanto o serviço de acesso quanto seus sistemas de suporte, o diagnóstico fica mais lento.
Os contatos regulatórios e de registro publicados pela Cloudnet não revelam se ela tem uma plataforma de atendimento ao cliente separada, registros fora do local, roteamento telefônico de emergência ou um processo manual testado.
O contrato de atacado com o vizinho visível é outro ponto de controle possível. Uma fibra e um roteador podem estar tecnicamente saudáveis enquanto uma disputa com o provedor, um pedido expirado, uma fatura não paga, um limite de capacidade ou uma autorização de rota expirada interrompe o serviço. Não há evidência de que tal disputa tenha ocorrido entre a Cloudnet e a Niss. O ponto é estrutural: onde o alcance depende de outra operadora, a continuidade dos negócios pertence à avaliação de resiliência tanto quanto as ópticas e a energia.
A falha de contrato com o provedor se torna mais consequente quando não há alternativa comprovada. Trocar de upstream exige mais do que pedir uma linha. O novo provedor deve alcançar um ponto de conexão, aceitar as rotas da Cloudnet, aplicar filtros, transportar IPv4 e IPv6, suportar autorizações de rota válidas e fornecer capacidade suficiente. O tráfego do cliente pode precisar de novas rotas padrão, caminhos DNS ou política de endereço. Se a migração for apressada após o término de um serviço existente, a rede pode ficar offline mesmo que a Cloudnet ainda controle seu ASN e prefixos.
Mover clientes de acesso individuais levanta um problema de migração diferente. Se a Cloudnet parar de atender uma área ou transferir assinantes para outra operadora, a continuidade depende da propriedade da fibra de derivação e do equipamento do cliente, portabilidade dos registros de conta, avisos prévios, reembolsos e capacidade do provedor substituto de fornecer serviço. O BGP público pode não mostrar nenhuma mudança se os endereços e a origem permanecerem os mesmos, ou uma grande mudança se os clientes forem renumerados. Nenhum desses resultados explica sozinho quem assumiu a obrigação de varejo.
Para um serviço hospedado genuíno, a migração seria ainda mais difícil: os clientes precisariam de exportação de dados, imagens de máquina, controle de DNS e tempo para reconstruir. Essa é uma das razões pelas quais a suposição não fundamentada de nuvem não pode ser tratada levianamente. Ela implica obrigações de custódia e saída de dados que estão ausentes das evidências.
Para a rede de acesso que é efetivamente visível, as questões imediatas são mais simples, mas ainda sem resposta: quem possui o relacionamento com o assinante, quem pode restaurar a autenticação, quem escala com a Niss e como um cliente é movido se esse relacionamento terminar.
Capacidade instalada não é capacidade comercial
Não há lista de preços ou tabela de velocidades pública da Cloudnet para comparar com a rede. Mesmo que houvesse, a velocidade de acesso anunciada ainda seria apenas a borda externa da questão de capacidade. Um plano de assinante de 100 Mbps não reserva 100 Mbps em cada switch de agregação, backhaul e link de trânsito a toda hora. Os provedores compartilham capacidade assumindo que os clientes não exigirão todos sua taxa máxima simultaneamente.
As quantidades operacionais relevantes estão ausentes. A Cloudnet não publica número de assinaturas ativas, mix de velocidades, trânsito comprometido, capacidade de peering, design de backhaul, utilização de portas, throughput de pico, taxa de sobrescrição ou histórico de congestionamento. O pool IPv4 de 512 endereços não preenche essas lacunas. NAT de nível de operador pode permitir que muito mais de 512 dispositivos de cliente compartilhem o pool; serviços profissionais estáticos podem consumir vários endereços por conta; e IPv6 altera o cálculo de endereçamento sem adicionar um único bit de capacidade de trânsito por si só.
O Cloudflare Radar exibiu umapopulação estimada para AS150069da ordem de algumas centenas, a estimativa exibida variando entre instantâneos e subpáginas. Essas estimativas usam sinais de tráfego e medição, não o sistema de faturamento do provedor. Elas indicam uma pequena população de usuários observável e reforçam a interpretação de ISP de consumo, mas não devem ser citadas como um registro de assinantes. Uma assinatura pode atender uma residência ou empresa com muitas pessoas, enquanto alguns usuários podem não aparecer nas medições subjacentes.
A mesma cautela se aplica ao desempenho medido.A página de qualidade da Internet do Cloudflare para AS150069agrega testes de velocidade disponíveis e observações de rede. Uma medição tirada de um endereço que responde pode mostrar que um caminho funcionou em um determinado momento e local. Ela não pode certificar a velocidade do plano para cada assinante, quantificar a frequência de falhas em toda a pegada de acesso ou revelar se a linha testada é representativa. Amostras pequenas são particularmente vulneráveis a mudanças de composição.
Osregulamentos de qualidade de 2024 da TRAIestabelecem referências e obrigações de relatórios para provedores de acesso e banda larga, incluindo fornecimento de serviço, desempenho de rede, reparo de falhas e tratamento de reclamações. Orelatório trimestral de desempenho de dezembro de 2024explica que seu resumo de desempenho de banda larga publicado cobria provedores com mais de 10.000 assinantes. A Cloudnet não é identificada no resumo público como um desses grandes provedores. Essa omissão não estabelece seu tamanho nem a isenta das obrigações aplicáveis; significa que o resumo nacional não pode ser usado como evidência de desempenho específico da Cloudnet.
A capacidade utilizável é o que resta após contenção, falha e política. Se um caminho de backup transporta apenas uma fração do tráfego normal, a redundância nominal ainda pode produzir congestionamento severo. Se os específicos IPv4 são retirados, mas o agregado permanece, o alcance pode continuar com engenharia de tráfego modificada. Se IPv6 falha enquanto IPv4 permanece ativo, os usuários podem experimentar atrasos e falhas específicas de aplicativos em vez de desconexão total. Uma declaração de capacidade crível exigiria medições de pico para ambas as famílias de endereços, não o tamanho dos prefixos alocados.
Um serviço de nuvem exigiria um conjunto diferente de evidências
Um provedor de acesso e um provedor de nuvem podem compartilhar roteadores, endereços e pessoal, mas vendem promessas diferentes. O serviço de acesso transporta o tráfego de um cliente para outros sistemas. A hospedagem de TI mantém o aplicativo, os dados ou o servidor de um cliente em funcionamento na infraestrutura própria ou alugada do provedor. A segunda promessa introduz questões que o registro de AS150069 não pode responder.
A primeira é o ativo. Uma oferta crível de servidor virtual deve identificar uma plataforma de computação ou pelo menos divulgar as características de CPU, memória, armazenamento, rede e localização. Bare-metal deve identificar classes de servidores e condições de provisionamento. Colocation deve identificar a instalação, energia do rack e arranjos de mão remota. Hospedagem gerenciada deve definir quais tarefas operacionais o provedor executa. Nenhum hardware específico da empresa encontrado aqui descreve qualquer um desses produtos.
A segunda é a localização. "Hospedado na Índia" ou "hospedado em Chennai" exigiria evidência da instalação onde os dados e a computação residem. Um ASN registrado na Índia não localiza um servidor. O tráfego pode ser roteado através de uma rede indiana para equipamento em outra instalação ou jurisdição; inversamente, a Cloudnet pode usar infraestrutura indiana de terceiros que não aparece em seu próprio espaço de endereçamento. O país de registro e a residência dos dados são afirmações distintas.
A terceira é o controle. Se a Cloudnet revendesse máquinas virtuais de outro provedor, a Cloudnet poderia controlar o faturamento e o suporte enquanto o provedor subjacente controlava os racks, hypervisors, energia e peças. Se a Cloudnet alugasse colocation, poderia possuir servidores, mas não os sistemas do prédio. Se operasse sua própria sala, ainda poderia depender de proprietários e operadores. Os clientes precisam saber quem pode restaurar a energia, substituir um disco, recuperar um backup e aprovar acesso de emergência. Nenhum documento público traça esse limite.
A quarta é a redundância. Um serviço de nuvem pode replicar dados através de discos, hosts, racks, salas, prédios ou regiões, cada um protegendo contra uma falha diferente. Duas cópias em um único host não sobrevivem à falha do host. Dois hosts em um rack podem compartilhar uma unidade de distribuição de energia. Dois racks em um prédio podem compartilhar energia elétrica, refrigeração e fibra upstream. Dois prédios ainda podem depender de um único conduíte metropolitano ou plano de controle. Sem uma arquitetura divulgada e um caminho de restauração testado, a palavra "nuvem" não diz nada sobre o domínio de falha.
A quinta é a saída. Um cliente se recuperando de uma falha do provedor precisa de uma imagem exportável, dump de banco de dados, cópia de objeto, controle de DNS e tempo e largura de banda suficientes para se mudar. A rescisão de contrato, disputa de faturamento ou falência do negócio pode ser tão disruptiva quanto uma falha de hardware se as credenciais ou dados estiverem bloqueados em uma única conta. Nenhuma condição da Cloudnet foi encontrada descrevendo devolução de dados, exclusão, assistência à migração, retenção de backups ou suspensão de conta.
Não são alegações de que a Cloudnet não tem as capacidades. São as perguntas mínimas que as evidências públicas deveriam responder antes de atribuir essas capacidades. Uma oferta privada, contrato ou especificação técnica poderia mudar a conclusão para um cliente específico. Até que tais evidências apareçam, AS150069 deve ser lido como evidência de operação de rede, não um produto de nuvem.
RPKI é uma higiene de roteamento útil, não resiliência em si
A Cloudnet tomou uma medida concreta de segurança de roteamento. Avalidação do RIPEstat para o agregado IPv4encontrou uma autorização de origem de rota válida cobrindo AS150069 e permitindo anúncios até/24. As rotas componentes são, portanto, válidas sob a mesma autorização. Avalidação para o/48IPv6também era válida.
RPKI ajuda outras redes a rejeitar um anúncio de origem que conflita com a autorização assinada. Reduz uma classe de erro ou sequestro de roteamento. Não verifica cada AS no caminho, não criptografa o tráfego, não impede um corte de fibra, não fornece um segundo upstream, não impede congestionamento e não mantém um roteador energizado. Uma rota válida pode levar a serviço indisponível se a rede de origem não tiver um caminho funcional para o cliente.
A combinação atual é, no entanto, significativa: recursos registrados, origens IPv4 e IPv6 ativas, objetos de rota e autorizações de origem válidas. Mostra mais maturidade operacional do que um nome de empresa dormente. Também aguça a questão de resiliência porque a topologia visível permanece estreita. Um alcance corretamente autorizado através de um único vizinho observado continua sendo um único vizinho observado.
Os anúncios IPv4 mais específicos adicionam outra complicação operacional. Durante o período em que os/24tiveram baixa visibilidade, o agregado/23permaneceu amplamente visível. Anunciar tanto o agregado quanto os específicos pode preservar uma rota de cobertura se um específico desaparecer. Isso também pode ser usado para política ou mitigação. Os coletores públicos não podem revelar o design pretendido, e o agregado não cria um segundo caminho físico. Redundância de roteamento e redundância de circuito não devem ser confundidas.
IPv6 também merece uma conclusão limitada. O/48foi anunciado globalmente por anos e seu objeto de rota foi atualizado recentemente. Isso suporta roteamento IPv6 ativo na borda da rede. Isso não prova que todo cliente de varejo recebe um prefixo IPv6, que o equipamento do cliente o suporta, ou que o pessoal de suporte soluciona problemas de ambos os protocolos igualmente. Seria necessária uma divulgação específica do provedor ou medição do lado do cliente para estabelecer a profundidade da implantação.
As pessoas afetadas são provavelmente clientes de acesso, não cargas de trabalho hospedadas
O ritmo diário do IPinfo, a licença de ISP e a ausência de catálogo de hospedagem apontam para uma rede de acesso. As estimativas de usuários observados do Cloudflare e os endereços que responderam na região de Chennai suportam essa direção. Elas não revelam nomes, localizações exatas ou tipos de clientes. A população provavelmente afetada é, portanto, condicional: residências, pequenas empresas ou usuários institucionais que recebem conectividade através de AS150069 ou através do serviço de acesso da Cloudnet.
Para uma residência, uma falha interrompe e-mail, streaming, trabalho remoto, educação, pagamentos e dispositivos conectados. Para uma pequena empresa, a mesma falha pode parar aplicativos em nuvem, autorização de cartão, contato com fornecedores e comunicações com clientes. Uma empresa usando um endereço estático da Cloudnet também pode perder o alcance de entrada para uma câmera, endpoint VPN ou serviço auto-hospedado. Esses são mecanismos, não afirmações de que uma organização nomeada compra o serviço da Cloudnet.
A dependência se estende além do titular da conta. Uma operadora local ou revendedor pode colocar clientes atrás do espaço roteado da Cloudnet. Nenhum ASN a jusante era visível, mas arranjos de varejo a jusante não exigem um ASN separado. Se a Cloudnet fornece capacidade para outra empresa de acesso, uma falha na fronteira Cloudnet-Niss pode afetar usuários que não reconhecem nenhum dos dois nomes de empresa. O roteamento público não pode contar esses arranjos.
Falhas diferentes produzem sintomas diferentes. Um derivação cortada afeta uma única instalação. Uma falha de acoplador ou porta de acesso afeta um grupo. Uma falha de agregação ou backhaul afeta uma área mais ampla. A perda da conexão com a Niss pode afetar toda a pegada roteada. Uma falha de DNS ou autenticação pode deixar os links ativos enquanto as sessões falham. Erros de faturamento ou sistema de conta podem desconectar um indivíduo sem qualquer falha de rede. O registro público não identifica quais sistemas a Cloudnet opera ela mesma.
A recuperação deve ser medida a partir da borda do cliente. Restaurar um anúncio BGP não é suficiente se a fibra de alimentação ainda estiver cortada. Reparar a fibra não é suficiente se a autenticação estiver fora. Energizar um switch não é suficiente se a sessão upstream ainda estiver indisponível. Um relato de incidente sólido identificaria a camada com falha, o operador responsável, horários de início e restauração, área afetada, solução alternativa e se a capacidade foi totalmente restaurada.
A ausência de uma página pública de incidentes ou histórico de status de serviço impede um julgamento de desempenho. O silêncio não prova confiabilidade perfeita, e relatos dispersos de usuários não estabeleceriam uma taxa em toda a rede sem verificação. As evidências atuais suportam o mapeamento da cadeia de falha, não a avaliação da disponibilidade histórica da Cloudnet.
O que estabeleceria uma imagem operacional mais sólida
O primeiro item ausente é uma descrição de serviço atual orientada ao cliente. Para serviço de acesso, deve nomear cobertura, tecnologia de acesso, velocidades dos planos, contenção ou regras de uso justo, condições de instalação, contato de falha e objetivos de serviço. Para qualquer serviço hospedado, deve especificar características de computação, armazenamento, rede, backup e migração. Um logotipo e uma promessa genérica de serviço rápido não seriam suficientes.
O segundo é um mapa de rede física e contratual em um nível de abstração apropriado. A Cloudnet não precisa publicar rotas sensíveis ao nível da rua. Poderia divulgar o número de pontos de presença ativos, as cidades ou áreas de serviço que cobrem, se o backhaul é próprio ou alugado, e se os circuitos upstream terminam em sites separados e seguem caminhos diversos. A chave é identificar domínios de falha comuns sem expor segredos operacionais.
O terceiro é evidência de capacidade. Medidas úteis incluem tráfego total e de pico, utilização de portas, trânsito comprometido e em burst, capacidade de failover, saturação de nós de acesso e adoção de clientes IPv4/IPv6. Um instantâneo deve ter uma data. Capacidade de design, interfaces instaladas, capacidade ligada e throughput disponível para o cliente devem ser relatados separadamente.
O quarto é evidência de recuperação. A Cloudnet poderia declarar autonomia de energia de backup por classe de site, política de peças de reposição, propriedade de escalada, janelas de manutenção e desempenho de restauração recente. Uma afirmação de resiliência se torna crível quando uma falha foi testada: retirada de rota, perda de upstream, corte de energia, substituição de hardware e restauração de configuração. O resultado deve mostrar se o serviço efetivamente falhou e quanta capacidade permaneceu.
O quinto é uma corroboração topológica independente. Um segundo vizinho visível fortaleceria o caso de diversidade de roteamento, mas ainda exigiria evidência de caminho físico. Um circuito de backup para o mesmo AS pode ser valioso se entrar em uma instalação diferente e evitar conduítes comuns. Inversamente, dois nomes de provedor podem compartilhar a mesma operadora de última milha. Contratos, locais de conexão e pesquisas de rota resolvem o que o BGP sozinho não pode.
O sexto é evidência de qualquer alegação de nuvem. Um nome de instalação ou site verificável independentemente, condições do cliente, especificações de infraestrutura, declaração de localização de dados, arquitetura de backup, matriz de responsabilidade de segurança e procedimento de saída moveriam a discussão de inferência para análise de produto. Um único domínio hospedado ou servidor respondendo do/23não provaria uma plataforma de nuvem comercial.
Até que esses elementos existam, a evidência mais sólida da Cloudnet continua sendo sua identidade regulada de ISP e seu roteamento ativo. As incógnitas não são lacunas decorativas. São os lugares exatos onde o serviço pode falhar: linha de acesso, energia de agregação, backhaul, conexão com a Niss, trânsito downstream, escalada de suporte e restauração do cliente.
Uma rede pequena e ativa, com uma história mais estreita do que seu nome
CLOUDNET INTERNET SERVICE PVT LTD não é uma casca corporativa vazia. Ela tem uma autorização de serviço de Internet categoria B de Tamil Nadu, uma identidade consistente em Chennai em registros públicos, um sistema autônomo ativo, uma alocação IPv4 de 512 endereços, um/48IPv6 anunciado e autorizações de origem de rota válidas. Suas rotas são visíveis desde 2022, e seus dados de registro foram mantidos pouco antes da data de observação.
As mesmas evidências estabelecem um limite firme. Um único vizinho de roteamento imediato era visível. Nenhum material público estabeleceu diversidade upstream ou física, pegada de acesso mapeada, largura de banda instalada, autonomia de energia de backup, desempenho de reparo de campo ou operação de suporte com pessoal. Mais importante, nada estabeleceu um serviço comercial de nuvem, VPS, bare-metal, colocation, armazenamento ou hospedagem gerenciada.
Isso não é um resultado decepcionante. É um resultado mais útil. O nome não mais obscurece a superfície operacional que pode realmente ser observada. A Cloudnet parece transportar tráfego de acesso em Tamil Nadu através de AS150069 e Niss Internet Services. Sua resiliência será determinada por infraestrutura comum: cabos, eletrônica alimentada, backhaul, configuração de rota, peças de reposição e pessoas capazes de restaurá-los.
O grau de evidência de rede é Baixo para uma avaliação completa de infraestrutura, apesar de fortes evidências de que o ASN está ativo. O roteamento é visível; o sistema físico e comercial por trás não é. Um grau mais forte exigiria evidência de onde os clientes se conectam, como o tráfego sai, o que falha, como a capacidade se comporta sob estresse e quem repara cada camada. Qualquer futura alegação de serviço de nuvem deve começar um passo antes, provando que há um serviço hospedado a ser avaliado.