02 Emre Erim atuando como Medyabim Data Center

Resumo

Os registros públicos da RIPE conferem à Medyabim uma identidade jurídica e de rede consistente.O registro RDAP da RIPE para AS44922nomeia MEDYABIM-AS, lista Emre Erim como contato administrativo e técnico, e inclui ORG-MIH2-RIPE com o nome «Emre Erim atuando como Medyabim Data Center»;o registro de organização da RIPEexibe o país TR, o status LIR, um endereço em Bursa e informações de contato.
A superfície de roteamento atual é real, mas estreita.A visão geral AS do RIPEstatmarca AS44922 como anunciado, enquantoo status de roteamentomostrava um prefixo IPv4, nenhum prefixo IPv6, 256 endereços IPv4 e um vizinho observado no instantâneo verificado.A visualização de prefixos anunciadoslistava apenas 37.247.116.0/24 como atual.
O controle positivo mais forte é a segurança da origem da rota para o /24 atual.A validação RPKI do RIPEstat para 37.247.116.0/24 via AS44922retornou válido, com uma ROA autorizando AS44922 e um comprimento máximo /24.
As próprias páginas da Medyabim comercializam uma pegada operacional mais ampla do que a superfície de roteamento atual do AS44922 prova.A página do data centerdeclara hardware dedicado pronto nos racks da Medyabim, longa experiência com servidores Linux DirectAdmin, opções de servidor na Turquia e no exterior, capacidade total de saída de 50 Gbit/s, caminhos de provedores nomeados como Turk Telekom e Superonline, e monitoramento de tráfego do cliente.A página de colocationdeclara continuidade de serviço de 99% com largura de banda, suporte 24/7, posicionamento atrás de um firewall, uma porta de reinicialização gratuita e cinco endereços IP.
As garantias públicas permanecem incompletas. As páginas oficiais não publicam fontes de alimentação duplas, tempo de operação do gerador, topologia de resfriamento, supressão de incêndio, salas de reunião de operadoras, janelas de manutenção, resultados de failover medidos, certificação da instalação ou perfil atual do PeeringDB. O domínio da Medyabim resolve para 185.7.83.213, enquanto o RIPEstat mostra que 185.7.83.0/24 é atualmente anunciado pela DATAFOREST em vez de AS44922, de modo que os mapas de dependência do lado do cliente devem separar a marca Medyabim, sua borda AS44922, o espaço de endereçamento alocado e as superfícies de serviço anunciadas por terceiros.

A questão útil não é se a Medyabim existe

Existe uma categoria de perfis de hospedagem regionais onde o primeiro dever é provar que a empresa é mais do que uma linha em um diretório. A Medyabim não é tão fraca. O registro público contém uma pessoa física nomeada, um nome comercial, um registro de organização RIPE, um sistema autônomo, recursos de endereçamento alocados, páginas oficiais de serviço, um endereço de contato em Bursa e ofertas de produtos funcionais.

O problema é diferente: o registro público prova a identidade e uma borda de roteamento limitada, enquanto a linguagem de marketing da empresa pede aos clientes que acreditem em uma história de capacidade de data center mais ampla.

A fonte de identidade mais sólida é a RIPE.O registro RDAP para AS44922nomeia o sistema autônomo MEDYABIM-AS e lista a organização «Emre Erim atuando como Medyabim Data Center». Ele também lista Emre Erim como contato administrativo e técnico, com um endereço em Bursa e um número de telefone.O registro REST de organização da RIPE para ORG-MIH2-RIPEcarrega o mesmo nome comercial, o país TR, o tipo LIR, o endereço de Bursa, telefone, fax, referências do mantenedor Medyabim e uma data de criação em março de 2008. Isso é muito mais sólido do que uma entrada de diretório de hospedagem extraída da web.

A própriapágina de contatoda Medyabim ancora independentemente o endereço operacional público. Ela descreve «Medyabim Data Center ve Internet Hizmetleri» e fornece Kükürtlü Mahallesi, Oulu Caddesi, Oylum Sitesi F Blok Kat 3 No 13, Osmangazi, Bursa, com números de telefone e o e-mail público[email protected]. Este endereço corresponde de perto ao endereço da RIPE. Isso importa porque a entidade não é apresentada como uma etiqueta de nuvem sem rosto. Suas evidências públicas apontam para um operador baseado em Bursa cujos registros de recursos de rede e site comercial são pelo menos mutuamente consistentes.

A página de história da empresa adiciona uma autodescrição. Apágina sobreda Medyabim diz que a empresa opera desde 2000 em torno de serviços de Internet, produtos de software e sistemas baseados em Linux prontos para uso; diz que depois se concentrou em registro de domínios, hospedagem web, servidores dedicados, gerenciamento de servidores e consultoria; e diz que a partir de 2006, construiu um data center em Bursa, com recursos próprios, com capacidade para mais de 500 servidores para seus próprios servidores e os de empresas de hospedagem web. Isso não é uma prova independente de racks instalados ou capacidade elétrica, mas é uma afirmação operacional específica e verificável.

A questão, portanto, não é «existe uma Medyabim?». A questão é «em quais partes da capacidade comercializada pela Medyabim um cliente pode confiar quando a energia, o resfriamento, o roteamento, o suporte ou a dependência upstream falham?». Para um comprador de data center ou colocation, a identidade é apenas a primeira porta. O teste mais difícil é a capacidade recuperável: o hardware, a energia dos racks, o resfriamento, a fibra, o roteamento e os processos humanos que permanecem disponíveis durante uma falha.

AS44922 é visível, mas sua superfície de rota pública atual é pequena

O RIPEstat confirma que AS44922 é anunciado.O endpoint de visão geral ASetiqueta o titular «MEDYABIM-AS Emre Erim atuando como Medyabim Data Center» e marca o recurso como anunciado no instantâneo verificado. Essa é a conclusão de rede positiva. A Medyabim tem uma borda de sistema autônomo pública que o sistema de roteamento pode ver.

A escala dessa borda é modesta.O endpoint de status de roteamentodo RIPEstat mostrava um prefixo IPv4, 256 endereços IPv4, zero prefixo IPv6 e um vizinho observado.O endpoint de prefixos anunciadoslistava 37.247.116.0/24 como anúncio atual de AS44922.O endpoint de vizinhos ASNmostrava um único vizinho esquerdo observado, AS16276.A visão geral AS do RIPEstat para AS16276identifica esse vizinho como OVH SAS.

Isso não significa que a Medyabim tenha apenas 256 clientes, um único rack ou um único serviço. O BGP público não vê VLANs privadas, estoque de revendedores, hospedagem fornecida por endereços de provedor, inventário de servidores, interconexões de clientes ou superfícies web terceirizadas. Mas isso significa que a borda visível de AS44922 não é um backbone público amplo, com múltiplos prefixos e múltiplos vizinhos no momento da verificação. Se um comprador avalia a Medyabim como uma dependência de data center, o mapa BGP público por si só não prova resiliência multioperadora.

A visualização de consistência de roteamento AS do RIPEstattorna a lacuna mais nítida. Ela listava 37.247.116.0/24 como presente tanto no BGP quanto no whois/IRR da RIPE. Ela também listava 37.247.117.0/24 e 2a03:400::/32 como presentes no whois/IRR mas não no BGP no momento da verificação. A mesma visualização de consistência mostrava antigos pares import/export whois AS9121 e AS53667 não vistos no BGP, enquanto AS16276 era visto no BGP mas não na política de import/export whois. Esse é um tipo normal de deriva em registros de roteamento mais antigos, mas é exatamente por isso que um cliente deve solicitar diagramas atuais em vez de confiar em texto de política de registro histórico.

O controle positivo é o RPKI. A rota atual de AS44922, 37.247.116.0/24, passoua verificação de validação RPKI do RIPEstatcomo válida. Isso importa porque a autorização de origem de rota é um dos poucos controles públicos que um comprador de hospedagem pode verificar sem ver documentos de instalação privados. Uma ROA válida não prova energia, resfriamento ou failover. Isso mostra que a origem AS44922 visível atualmente não é deixada como uma reivindicação de origem de rota desconhecida na camada de validação pública.

A conclusão de rota é, portanto, estreita e útil. AS44922 é real. Sua rota IPv4 visível atual é RPKI válida. Sua superfície upstream observada é fina. Suas evidências IPv6 não são atualmente anunciadas. Seus registros de política de roteamento públicos são evidências públicas limitadas para provar diversidade de operadoras ou failover. Um cliente não deve tratar isso como uma rede fantasma, nem como uma rede de data center resiliente comprovada.

IPv6 e evidências de prefixos dormentes exigem degradação

A Medyabim tem evidências de registro IPv6. O registro de pesquisa da RIPE para2a03:400::/32mostra uma alocação 2a03:400::/29 sob TR-MEDYABIM-20110107 e uma entrada route6 para 2a03:400::/32 com origem AS44922. Isso parece sólido até compararmos com a visibilidade de roteamento atual.

O endpoint de visão geral de prefixo do RIPEstat para 2a03:400::/32marcava o prefixo como não anunciado no momento da verificação.A visualização de status de roteamentorelatava nenhuma origem atual, zero pares RIS o vendo, e um último evento visto para AS44922 em 1º de abril de 2026. Isso não é por si só uma conclusão de falha. Alguns clientes podem não comprar serviço IPv6; alguns operadores podem ter planos IPv6 dormentes; alguns blocos de endereços são mantidos para uso futuro. Mas isso muda o que pode ser provado publicamente. Um provedor de data center cujas páginas oficiais atuais comercializam serviços de hospedagem e servidor, mas cuja borda AS visível atualmente não tem nenhum anúncio IPv6, deve ser questionado sobre suporte IPv6, sua indisponibilidade, disponibilidade seletiva ou fornecimento através de outro provedor.

O quadro de prefixos IPv4 dormentes também é misto. O resultado da pesquisa RIPE para37.247.117.0/24mostra NET-MEDYABIM-DC5 e uma entrada de rota RIPE com origem AS44922 criada em junho de 2025. No entanto, a verificação de consistência do RIPEstat não a viu no BGP atual. Isso pode representar capacidade reservada, migração planejada, rota recentemente retirada, faixa de backup ou simplesmente espaço de endereçamento não utilizado. As evidências públicas não podem escolher entre essas explicações.

A distinção importante é entre capacidade alocada e capacidade operacional. Uma alocação RIPE, uma entrada de rota ou uma atribuição de endereço pode mostrar controle administrativo ou preparação. Isso não prova que a faixa de endereços atende clientes hoje, é acessível através de múltiplos operadores, ou pode ser ativada durante uma falha.

Um comprador que precisa de capacidade recuperável deve perguntar à Medyabim quais prefixos estão em produção, quais estão reservados, quais estão migrados para outras origens, quais são voltados para o cliente, quais são reservados para gerenciamento, e quais são cobertos por processos DDoS, firewall e RPKI testados.

As próprias páginas de serviço da Medyabim são concretas, mas não publicam resiliência das instalações

Apágina do data centerda Medyabim é mais detalhada do que uma página inicial de hospedagem genérica. Ela indica que os modelos de servidores dedicados são entregues após validação do pagamento e que o hardware está pronto nos racks da Medyabim. Ela diz que a Medyabim tem mais de 15 anos de experiência com servidores dedicados Linux e usa ativamente o DirectAdmin desde 2003. Ela diz que a empresa atende com seu próprio hardware de servidor baseado na Turquia, enquanto os serviços de servidores dedicados podem ser escolhidos na Turquia ou no exterior conforme a demanda. Ela também descreve uma «capacidade de linha elevada» e alta disponibilidade como razão para oferecer rapidamente hardware de servidor real.

A mesma página faz uma grande declaração de conectividade. Ela diz que as principais conexões de Internet do data center foram escolhidas para fornecer acesso rápido da Turquia e do mundo, nomeia Türk Telekom, Superonline, Level3, Tinet, Lambdanet, Cogent Communications, AMS-IX e ECIX Duesseldorf, e declara uma capacidade total de saída de linha de 50.000 Mbit, ou 50 Gbit/s. Ela diz que os clientes de servidores dedicados podem entrar em um painel de gerenciamento de rede para monitorar seu próprio tráfego 24/7 e diz que o data center usa hardware de rede Foundry Networks e HP Procurve.

Essas são evidências úteis, mas devem ser lidas como texto de marketing e operacional publicado pela empresa, não como uma auditoria de operador ao vivo. A página não divulga quais dos provedores nomeados são transportadores físicos atuais, quais são provedores de trânsito, quais são relações de peering ou rota, quais são opções de trânsito históricas, quais suportam os serviços turcos, e quais suportam o posicionamento no exterior. Ela não mostra sala de reunião de instalação, entrada de fibra diversificada, mapa de interconexão ou inventário de portas ao vivo.

O BGP público no momento da verificação mostrava um vizinho AS44922 observado, não um mapa publicamente visível de cada nome de provedor na página.

A página é ainda mais enxuta sobre engenharia das instalações. Ela não publica fontes de alimentação duplas, capacidade de UPS, duração da bateria, duração de combustível do gerador, redundância de resfriamento, classe de supressão de incêndio, carga no piso, densidade de rack, camadas de segurança física, regras de janela de manutenção ou exercícios de recuperação de desastres. Essas omissões não provam que os controles não existem. Muitos pequenos provedores não publicam esses detalhes. Mas um cliente avaliando a resiliência de um data center não deve assumir esses controles a partir da palavra «data center».

Apágina de colocationda Medyabim adiciona afirmações operacionais voltadas ao cliente. Ela diz que a Medyabim oferece uma garantia de disponibilidade ou continuidade de serviço de 99% com largura de banda para seu serviço de colocation; diz que empresas com servidores no data center da Medyabim podem receber suporte empresarial 24/7; diz que as estatísticas de tráfego podem ser observadas online; diz que os servidores estão atrás de um firewall; diz que uma porta de reinicialização gratuita será atribuída; diz que a conexão atribuída é dedicada e não limitada; e diz que cinco endereços IP são atribuídos gratuitamente para servidores no data center.

Essas são reivindicações de serviço reais, e elas especificam as perguntas que os compradores devem fazer antes de confiar no serviço. Uma promessa de continuidade de serviço de 99% não é a mesma coisa que um SLA de alta disponibilidade moderno, e 99% ainda pode permitir uma quantidade significativa de tempo de inatividade em um ano. Uma porta de reinicialização só é útil se a distribuição de energia, o acesso remoto, as credenciais do console e os procedimentos de suporte sobreviverem ao incidente. O posicionamento do firewall pode proteger os clientes, mas também pode se tornar um gargalo compartilhado.

Cinco endereços IP podem ser suficientes para uma hospedagem simples, mas isso não diz nada sobre a portabilidade da sub-rede roteada ou failover. A página dá aos clientes elementos para perguntar, não uma prova completa de resiliência.

O site oficial prova a extensão da oferta, não a capacidade recuperável

A extensão da oferta pública é ampla.A página de pacotes de hospedagem webda Medyabim anuncia pacotes de hospedagem com espaço web, tráfego, FTP, MySQL, webmail, DirectAdmin, SSL opcional, produtos de backup de e-mail, um serviço IP adicional por servidor, um serviço de backup de servidor de 300 GB, transferência FTP 24/7 ilimitada, backups automáticos semanais e mensais, estatísticas avançadas, filtro antispam e um relatório de transferência. Suapágina de revendaoferece pacotes de revenda com espaço web, cotas de e-mail POP3, tráfego mensal, bancos de dados MySQL, painel de controle turco, webmail, controle DNS opcional, opções SSL, filtros antispam e relatórios de tráfego.

A página VDSexplica servidores dedicados virtuais como servidores logicamente separados em hardware físico e lista as funcionalidades dos pacotes VDS.A página de informações do painel de controlediz que o DirectAdmin é instalado nos servidores quando o servidor está no DC da Medyabim, descreve um gerenciamento proativo de servidores, configuração de segurança e monitoramento de listas negras de spam, e diz que PHP, MySQL, Linux, ionCube e DirectAdmin são instalados e configurados em todos os servidores.

Juntas, essas páginas mostram que a Medyabim vende uma pilha clássica de pequeno provedor: domínios, hospedagem compartilhada, hospedagem de revenda, VDS, servidores dedicados, colocation, armazenamento de e-mail, SSL, backup e suporte gerenciado Linux/DirectAdmin. Essa mistura cria dois tipos de dependências. Uma é física: racks, energia, resfriamento, uplinks, firewall, portas de reinicialização, servidores sobressalentes e acesso de técnico. A outra é administrativa: portal do cliente, faturamento, status da conta, tickets de suporte, controle de domínios, DNS, e-mail e processos de backup.

A oferta pública não diz ao comprador quais dependências estão no mesmo domínio de falha. Um cliente pode comprar um pacote de hospedagem web cujo site, e-mail, backups, DNS e acesso a tickets dependem todos dos mesmos sistemas do provedor. Um revendedor pode depender do painel de controle e dos sistemas de e-mail da Medyabim mesmo que os clientes finais vejam apenas a marca do revendedor. Um comprador de servidor dedicado pode ter reinicialização remota, mas ainda precisaria de um técnico se a máquina não inicializar, se um controlador de disco falhar, ou se a política do firewall bloquear o acesso de recuperação.

Um cliente de colocation pode possuir o servidor, mas ainda depende do edifício, energia, uplink, firewall e resposta de suporte da Medyabim.

É por isso que a capacidade instalada não é suficiente. A afirmação da página sobre mais de 500 servidores e a declaração da página do data center de capacidade de saída de 50 Gbit/s descrevem uma escala possível. A capacidade recuperável pergunta o que acontece depois que um fornecimento de energia, caminho de UPS, switch, firewall, uplink, caminho de autenticação ou canal de suporte desaparece. As páginas públicas não respondem a isso.

A própria superfície DNS da Medyabim aponta para fora do AS44922

Um dos controles mais reveladores é o próprio domínio da Medyabim. Uma consulta DNS pública para medyabim.com.tr mostrou que o apex e o nome www resolvem para 185.7.83.213, que mail.medyabim.com.tr também resolve para 185.7.83.213, que os servidores de nomes são ns1.medyabim.com e ns2.medyabim.com, e que um registro SPF referencia 37.247.112.0/24 e 185.7.83.0/24. Esses fatos de DNS devem ser tratados como evidências adjacentes às operações porque mostram como a Medyabim apresenta sua própria superfície de serviço à Internet.

O RIPEstat então muda a interpretação.A visão geral de prefixo para 185.7.83.0/24mostrava o prefixo anunciado por AS58212, eo endpoint de status de roteamento para 185.7.83.0/24listava a origem atual AS58212, enquanto notava que o prefixo tinha sido visto pela primeira vez a partir de AS44922 em 2012 e tinha sido visto pela última vez no instantâneo verificado a partir de AS58212.A visão geral AS do RIPEstat para AS58212identifica essa origem como DATAFOREST dataforest GmbH. Da mesma forma,a visão geral de prefixo para 37.247.112.0/24mostrava a origem atual AS29141, e suavisão geral AS para AS29141identifica Bradler & Krantz GmbH & Co. KG.

Isso não significa que a Medyabim deturpa seu serviço. O espaço de endereçamento pode ser atribuído, alugado, migrado, roteado por provedores de trânsito, hospedado no exterior ou usado para serviços legados. Os resultados de pesquisa da RIPE para Medyabim mostram vários blocos de endereços rotulados Medyabim, incluindo 37.247.115.0/24, 37.247.118.0/24, 185.7.82.0/24 e 185.7.83.0/24, alguns dos quais são atualmente atribuídos pelo roteamento público a outros ASNs de origem. A conclusão correta não é um escândalo; é um mapeamento de dependências.

Se a web, o e-mail ou as superfícies de DNS da Medyabim dependem de prefixos atualmente anunciados por outras redes, então os clientes precisam saber quais partes do seu serviço estão no AS44922, quais partes estão em espaço de endereçamento de origem externa, e quais partes estão no exterior. Isso importa para a análise de falhas. Se o AS44922 tiver um problema, o site público ou e-mail de suporte da Medyabim ainda pode estar acessível através de outro provedor. Se o caminho de origem externa tiver um problema, a superfície da marca Medyabim pode falhar mesmo que a rota Bursa AS44922 permaneça ativa.

Se um cliente compra um posicionamento «Turquia» mas o suporte, backup, DNS ou dependência de e-mail estão em outro lugar, o cliente precisa que isso seja destacado no design do serviço.

O ponto mais amplo é que DNS e BGP contam histórias diferentes. O domínio da marca pode estar online enquanto a borda AS é estreita. Um titular RIPE pode ter faixas de endereços alocados atualmente não anunciadas por seu próprio ASN. Um provedor pode vender hospedagem enquanto depende de origens de rota de terceiros para partes de sua própria pilha. Nenhum desses fatos é desqualificante. Todos significam que a análise de falhas deve ser precisa.

O silêncio no PeeringDB importa porque o site nomeia muitos caminhos

PeeringDB é um diretório voluntário, portanto a ausência de uma entidade de rede não é prova de que uma rede carece de interconexão. No entanto, isso importa para a Medyabim porque a página oficial do data center nomeia muitas relações de conectividade e uma declaração de capacidade total de saída de 50 Gbit/s.Uma consulta à API do PeeringDB para ASN 44922não retornou nenhuma entidade de rede no momento da pesquisa. Isso remove uma fonte pública que poderia de outra forma mostrar presença de exchange, presença de instalação, política de peering, ratios de tráfego, prefixos informativos e locais de interconexão autorrelatados.

Sem um perfil no PeeringDB, um comprador fica com os registros RIPE/RDAP, observações BGP do RIPEstat, as próprias páginas da Medyabim, DNS e linguagem contratual. Isso é factível, mas não é suficiente para provar acesso diversificado a salas de reunião de operadoras. O BGP público mostrava AS16276 como o vizinho observado atual. A página do data center da Medyabim nomeia Turk Telekom, Superonline, Level3, Tinet, Lambdanet, Cogent, AMS-IX e ECIX Duesseldorf. Este artigo não pode reconciliar essas camadas em uma topologia física atual a partir apenas de evidências públicas.

A pergunta correta de fornecimento não é se cada provedor nomeado é falso. É se o serviço de produção atual tem mais de um caminho provisionado independentemente e se esses caminhos são significativamente diversificados. Existem vários provedores de trânsito pagantes ativos para o serviço do cliente, ou apenas um upstream visível? Alguns nomes são históricos? Algumas rotas são entregues através de um provedor upstream, um revendedor ou uma interconexão remota? A instalação de Bursa tem entradas de fibra diversificadas? Os caminhos turcos e europeus são fisicamente separados?

Quanto tráfego o caminho sobrevivente pode suportar durante uma falha? O caminho do firewall é redundante, e o caminho da porta de reinicialização é independente do roteamento de produção do cliente?

As evidências públicas não podem responder a essas perguntas. Elas podem identificar a necessidade de fazê-las. Uma declaração de 50 Gbit/s é uma hipótese de capacidade até que haja evidência de portas atuais, contratos, margem de utilização e failover. Logotipos ou textos de provedores nomeados não são equivalentes a diversidade de rotas. Um único vizinho AS observado não é prova de mono-hospedagem, mas é suficiente para exigir confirmação direta.

O contrato de serviço transfere o risco ao cliente

Ocontrato de serviçoda Medyabim é importante porque mostra como as promessas técnicas públicas encontram o risco contratual. O contrato estipula que a Medyabim fornecerá os serviços solicitados após pagamento e aceitação, mas também coloca a responsabilidade sobre os clientes por credenciais de conta, conteúdo hospedado, conformidade legal, impostos e uso do serviço. Mais importante para a resiliência, ele diz que as obrigações de backup e armazenamento de dados do cliente pertencem ao cliente, salvo indicação em contrário no texto do contrato, enquanto diz que a Medyabim faz backup e mantém regularmente os dados dos clientes, mas não é responsável por erros, perdas ou danos resultantes de interrupções de serviço ou perda de dados.

Essa combinação é comum em contratos de hospedagem, mas é pesada de consequências. As páginas de hospedagem públicas podem anunciar backups automáticos semanais e mensais, serviços de backup opcionais, relatórios de tráfego e suporte gerenciado. O contrato de serviço ainda pode limitar a responsabilidade do provedor se o cliente não tiver comprado ou configurado o processo correto de backup e restauração.

Um cliente deve, portanto, perguntar o escopo exato do backup, retenção, testes de restauração, tempo de restauração, isolamento do backup e se os backups estão na mesma instalação, rede do provedor, plano de controle da conta ou domínio de falha.

O mesmo contrato dá à Medyabim direitos de suspensão por problemas de pagamento, conteúdo ilegal, spam e outras violações contratuais. Isso é esperado para um provedor de hospedagem protegendo sua rede. Isso também significa que a continuidade do serviço depende do status administrativo, bem como dos sistemas físicos. Um cliente pode perder o serviço devido a não pagamento, tratamento de abuso, incidente de spam, bloqueio de conta, credenciais perdidas ou disputa de suporte, mesmo quando os racks e as rotas estão saudáveis.

Para cargas de trabalho críticas, faturamento, contatos de abuso e procedimentos de escalonamento são controles operacionais, não detalhes administrativos.

Apágina de ajuda do sistema de suportee apágina de ajuda onlineda Medyabim mostram uma postura de suporte orientada a tickets. A página do data center diz que o suporte telefônico está disponível durante o horário comercial, das 09:00 às 18:00, e fora desse horário, os clientes podem entrar em contato com o provedor através de um sistema de tickets e suporte por e-mail 24/7. A página de colocation diz que empresas com servidores no data center da Medyabim podem receber suporte empresarial 24/7. Essas declarações devem ser convertidas em procedimentos de incidente antes que um cliente confie no serviço: quem pode ligar, quem pode abrir tickets de emergência, se há escalonamento telefônico fora do horário comercial, e como o provedor distingue incidentes de reinicialização, rede, hardware, firewall, DNS e abuso.

Energia e resfriamento são os maiores pontos cegos públicos

A missão desta investigação é um exame da infraestrutura do data center, e a principal dependência física é energia, resfriamento, acesso a sala de reunião de fibra, operações da instalação e licenças locais. As páginas públicas da Medyabim fornecem algumas afirmações do tipo instalação, mas não detalhes técnicos suficientes para sustentar um alto nível de confiança em resiliência. A página sobre diz que a empresa construiu um data center em Bursa com capacidade para mais de 500 servidores com seus próprios recursos.

A página do data center diz que o hardware está pronto nos racks da Medyabim e que a empresa usa seu próprio hardware de servidor. A página de colocation diz que os servidores estão atrás de um firewall, têm estatísticas de tráfego e recebem uma porta de reinicialização gratuita.

Essas declarações ainda deixam a instalação física quase não observada. Não há afirmação pública de fontes de alimentação duplas. Não há topologia de UPS publicada ou duração da bateria. Não há número de geradores, capacidade de combustível ou contrato de reabastecimento. Não há design de redundância de resfriamento. Não há detalhe sobre detecção de fumaça, incêndio ou vazamento de água. Não há planta baixa ou certificação da instalação. Não há declaração sobre entradas de fibra diversificadas ou design de sala de reunião. Não há política de janela de manutenção distinguindo trabalhos planejados, de emergência e solicitados pelo cliente.

Não há histórico de incidentes públicos mostrando recuperação medida.

Para um pequeno provedor de Bursa, parte desse silêncio é compreensível. Publicar muitos detalhes da instalação pode criar risco de segurança. Pequenos operadores também podem contar com instalações upstream, salas alugadas, arranjos de energia de qualidade de escritório, ou posicionamentos mistos de servidores locais e no exterior. Mas o risco para o cliente permanece o mesmo. Uma declaração de «capacidade para mais de 500 servidores» não é equivalente a capacidade elétrica utilizável após a falha de um caminho de distribuição. Uma declaração de «alta disponibilidade» não é equivalente a tempo de operação testado do gerador.

Uma «porta de reinicialização» não substitui acesso ao console remoto, discos sobressalentes, procedimentos de hot swap ou disponibilidade de técnico.

O teste prático consiste em separar quatro capacidades. Capacidade instalada é o que o provedor construiu ou diz poder hospedar. Capacidade vendida é o que os clientes já estão usando. Capacidade utilizável é o que resta após a carga normal, limites térmicos, reservas de energia, manutenção e superassinatura. Capacidade recuperável é o que resta após uma falha de componente. As páginas públicas geralmente descrevem a capacidade instalada. Os clientes precisam de capacidade utilizável e recuperável.

As evidências públicas atuais da Medyabim não podem resolver essa questão. Elas podem apenas estabelecer a demanda por evidências: diagramas de energia, tempo de vida útil de UPS e gerador, design de resfriamento, política de densidade de rack, controles de incêndio e água, diversidade de entrada de operadora, histórico de manutenção, procedimento de assistência remota, política de peças sobressalentes e pelo menos um exercício documentado de failover ou restauração.

Quem é afetado quando a Medyabim falha

Os usuários afetados não são apenas os titulares de conta diretos da Medyabim. Um provedor que vende domínios, hospedagem, pacotes de revenda, VDS, servidores dedicados, colocation, armazenamento de e-mail e backups pode estar sob muitos serviços downstream. Um pacote de revenda pode suportar dezenas ou centenas de pequenos sites cujos proprietários podem não saber que a Medyabim existe. Um servidor dedicado pode hospedar um aplicativo empresarial, um banco de dados, um portfólio de agência, um serviço de e-mail ou uma loja online.

Um cliente de colocation pode possuir o hardware, mas depende da Medyabim para energia, acesso ao rack, caminho do firewall, monitoramento de tráfego e controle de reinicialização.

O caminho de falha também não é unidimensional. Um evento de energia pode derrubar servidores mesmo que as rotas upstream estejam saudáveis. Um evento de resfriamento pode forçar um desligamento ou reduzir a densidade de rack permitida. Uma falha de firewall único pode isolar muitos clientes de uma só vez. Uma falha de provedor upstream único pode afetar AS44922 se nenhum caminho alternativo estiver ativo para o prefixo envolvido. Uma falha de suporte ou ticket pode retardar a recuperação mesmo que a instalação esteja intacta.

Uma falha de DNS ou e-mail em espaço de endereçamento de origem externa pode tornar a Medyabim mais difícil de contatar enquanto o tráfego de produção em outro lugar ainda funciona. Uma suspensão contratual ou por abuso pode remover o serviço sem defeito físico.

É por isso que a descoberta de DNS importa. Se o domínio público da marca e o serviço de e-mail usam 185.7.83.213 sob um prefixo atualmente anunciado pela DATAFOREST, e se o SPF referencia um prefixo 37.247.112.0/24 atualmente anunciado pela Bradler & Krantz, então os clientes não devem assumir que a «rede Medyabim» significa um AS, uma cidade, uma instalação ou uma jurisdição. O serviço pode ser mais resiliente porque alguns componentes estão fora do AS44922. Também pode ser mais complexo porque a propriedade de incidentes atravessa fronteiras de provedores.

As pessoas que precisam de respostas são as equipes de fornecimento, agências web, operadores de revenda, proprietários de pequenas empresas, administradores de sistemas, responsáveis por conformidade e respondedores de incidentes. Elas precisam saber se um serviço hospedado pela Medyabim tem um segundo caminho, um teste de restauração recente, um canal de suporte fora da banda, backups atuais, acesso a transferência de domínio, exportação de DNS, continuidade de e-mail e autorização de origem de rota. Essas perguntas não são hostis.

Elas são o trabalho mínimo necessário para transformar um relacionamento de hospedagem em uma dependência de infraestrutura que pode sobreviver a um dia ruim.

O que os clientes devem pedir à Medyabim para provar

Primeiro, peça um mapa de rede atual. Ele deve identificar AS44922, 37.247.116.0/24, prefixos AS44922 reservados ou dormentes como 37.247.117.0/24, planos IPv6 para 2a03:400::/32 ou a alocação mais ampla, e serviços de clientes roteados sob AS29141, AS58212 ou outras origens. Ele deve identificar se AS16276 é o único provedor upstream ativo para a rota AS44922, se outros provedores estão ativos através de acordos privados ou não observados, e se os nomes de provedores na página do data center são atuais, históricos, indiretos ou específicos do produto.

Segundo, peça resiliência das instalações. A resposta deve incluir fontes de alimentação, design de UPS, duração da bateria, tempo de operação do gerador, redundância de resfriamento, limites de densidade de rack, segurança física, controles de incêndio e água, janelas de manutenção, disponibilidade de assistência remota, política de peças sobressalentes e o que a declaração de continuidade de colocation de 99% realmente cobre. Se o serviço for em Bursa, pergunte quais dependências de edifício e utilidades existem. Se o serviço for no exterior, pergunte qual país, instalação, provedor e condições legais se aplicam.

Terceiro, peça evidências de failover no nível do cliente. A Medyabim deve ser capaz de mostrar o que acontece quando um provedor upstream falha, um firewall falha, um servidor perde energia, um disco falha, o cliente não consegue acessar o portal, a fila de suporte está ocupada, a conta é sinalizada por abuso, ou o cliente precisa de uma migração de emergência. As páginas públicas mencionam monitoramento de tráfego, backups, portas de reinicialização e tickets. O comprador precisa saber como essas ferramentas se comportam durante uma falha.

Quarto, peça controles sobre dados e saída. A página de hospedagem menciona backups automáticos semanais e mensais, backup opcional, produtos de backup de e-mail e um serviço de backup de servidor. O contrato de serviço limita a responsabilidade da Medyabim por interrupções de serviço e perda de dados, salvo indicação em contrário no contrato. Os clientes devem exigir testes de restauração, escopo do backup, retenção, status fora do local, criptografia, controle de acesso, processo de exportação, processo de transferência de domínio, exportação de DNS e continuidade de e-mail.

Quinto, peça prova de que o suporte pode ser contatado quando o site ou e-mail habitual está indisponível. A página de contato fornece números de telefone e e-mails. A página do data center descreve suporte telefônico durante o horário comercial e suporte por ticket/e-mail fora do horário. Clientes críticos devem exigir um escalonamento de emergência nomeado, contatos autenticados, um procedimento telefônico fora da banda e uma maneira de autorizar assistência remota sem depender apenas do portal normal.

Um dossiê de evidências razoável não precisaria revelar plantas baixas sensíveis. A Medyabim poderia fornecer um anexo específico do cliente indicando qual instalação atende a carga de trabalho, quais prefixos e ASNs de origem são usados, quais serviços de DNS e e-mail estão envolvidos, quais provedores upstream estão ativos, quais componentes são pontos únicos de falha, e quais serviços estão fora da Turquia. Poderia fornecer um diagrama unifilar expurgado separando servidores de clientes, firewall compartilhado, controlador de reinicialização, destino de backup, portal de suporte, DNS autoritativo e site público.

Poderia também fornecer datas recentes para testes de gerador, manutenção de UPS, manutenção de resfriamento, testes de failover upstream, testes de restauração de backup e mudanças de origem de rota. Esses artefatos responderiam à questão operacional sem expor nomes de clientes ou configurações de segurança sensíveis.

O mesmo anexo deve distinguir hospedagem padrão de colocation e servidores dedicados. Na hospedagem compartilhada, o comprador depende das escolhas de plataforma e da política de backup da Medyabim. Na hospedagem de revenda, os clientes downstream podem depender da Medyabim mesmo quando compram de outra marca. Para servidores dedicados, o comprador pode controlar o sistema operacional, mas não o rack, roteador, caminho de energia ou peças sobressalentes. Em colocation, o comprador pode possuir o servidor, mas ainda depende da Medyabim para o edifício, energia, acesso a suporte e borda de rede.

Essas diferenças determinam quem age primeiro durante uma falha.

Avaliação das evidências

A Medyabim recebe uma classificação pública de evidências de rede Média, com degradação para evidências de instalação e resiliência. A camada de identidade é sólida para um pequeno provedor: os registros RDAP da RIPE e de organização da RIPE vinculam AS44922 e ORG-MIH2-RIPE a Emre Erim atuando como Medyabim Data Center, e o endereço de Bursa corresponde à página de contato da Medyabim. A camada de rota AS44922 atual também é real: o RIPEstat marca o AS como anunciado, lista 37.247.116.0/24 como atual, mostra visibilidade IPv4 RIS completa no instantâneo verificado, e valida a rota sob RPKI.

A classificação não pode ser Alta porque as evidências operacionais se afinam imediatamente depois. O RIPEstat mostrava apenas um /24 IPv4 atual, nenhum anúncio IPv6 atual e um vizinho AS44922 observado. O PeeringDB não retornou nenhuma entidade de rede para AS44922. A visualização de consistência do RIPEstat mostrava uma entrada de rota IPv4 e uma entrada route6 que não estavam atuais no BGP. A própria superfície DNS da Medyabim aponta para espaço de endereçamento atualmente anunciado por outras redes.

As páginas oficiais da Medyabim publicam afirmações de serviço úteis, mas não publicam as evidências de energia, resfriamento, sala de reunião de operadora, manutenção e failover necessárias para confiar na capacidade comercializada do data center sob estresse.

A conclusão prática não é rejeitar a Medyabim. As evidências suportam um verdadeiro operador de hospedagem e data center baseado em Bursa com registros RIPE de longa data, uma borda AS visível, páginas de serviço oficiais e uma oferta concreta ao cliente. A conclusão também não é aceitar as alegações de mais de 500 servidores e 50 Gbit/s como prova de resiliência. Os clientes devem tratar essas alegações como hipóteses a serem validadas através de diagramas de operador atuais, evidências de instalação, mapeamento de prefixos, verificações RPKI, testes de restauração e procedimentos de suporte específicos do contrato.

A pegada pública da Medyabim é mais forte onde nomeia identidade, serviços e uma rota atual. É mais fraca onde um cliente mais precisa de evidências durante uma falha: fontes de alimentação, resfriamento, diversidade física de fibra, redundância ativa de operadora, IPv6 atual, escalonamento de suporte, backups, saída e recuperação testada. É exatamente aí que a devida diligência deve se concentrar antes de colocar cargas de trabalho críticas atrás da marca.