JuniorG

Eu recebi o mesmo e-mail, no lowendtalk tem um pessoal conversando sobre isso.

Na prática, não possível anunciar blocos menores que /24. E para isso você precisaria ter um ASN e contratar trânsito IP, o que não é possível em conexões residenciais comuns como banda larga. Ou seja, se a ideia é montar algo barato, está bem longe do objetivo. Como já foi mencionado por outros, usar colocation em um DC acaba sendo mais viável. Agora, se o objetivo for apenas estudar, testar ou montar algo do tipo “sim, funciona e fui eu que fiz”, aí vale sim a pena. Nesse caso, você pode alugar um bloco pequeno (/29, /28 etc.) de qualquer provedor e fazer o roteamento até sua casa via túnel (como GRE ou WireGuard). Isso permitiria alocar IPs públicos às suas VPSs locais, é uma ótima maneira de aprender mais sobre redes, roteamento e infraestrutura.

Pelo que entendi, você utiliza um servidor dedicado para virtualização, e um dos seus clientes, que possui uma VPS, está enviando SPAM, o que está afetando a reputação dos seus IPs. Caso essas VPSs não sejam gerenciadas por você, uma forma simples e eficaz de mitigar o problema é bloquear a saída na porta 25 (SMTP) por padrão. Você pode então liberar essa porta manualmente apenas para clientes confiáveis, que não apresentem esse tipo de comportamento.

Realmente, por curiosidade, fui verificar onde está anunciado o IP 140.233.176.81 e notei que vários IPs do mesmo bloco possuem rDNS configurado com domínios listados pelo @chuvadenovembro Ao consultar o bloco completo 140.233.176.0/24, é possível ver que praticamente todos os IPs possuem PTR apontando para domínios .com.br. https://i.imgur.com/ZfJxS0p.png https://ipinfo.io/AS215026/140.233.176.0/24 Um detalhe interessante é que o bloco está com mnt-by: IPXO-MNT, indicando que provavelmente foi alugado via IPXO. A IPXO costuma ser bastante rígida quanto ao uso dos IPs para envio de spam, geralmente encerram o contrato após poucas denúncias. Sobre a empresa atualmente responsável (AS215026) por anunciar o bloco 140.233.176.0/24, se não estiver diretamente envolvida no abuso, no mínimo está sendo omissa. Se alguém tiver evidências de spam relacionado, vale a pena enviar uma denúncia: abuse@ walehost.com <= Empresa que está anunciando os blocos IPXO Abuse Report: https://www.ipxo.com/report-abuse/ <= Se a acima não resolver.

Fiz um projeto nesse estilo e vou compartilhar com você. Na parte física: No roteador da operadora (banda larga), coloquei em modo bridge para usar um Mikrotik RB5009 como roteador de borda. Uso um Juniper EX3300 para dividir as VLANs entre alguns servidores. Tenho um Dell T330 rodando Proxmox com algumas VMs, um Dell R630 que uso para testes, e mais um servidor Xeon "xing-ling". Na parte lógica: Como não posso usar a internet banda larga para anunciar IPs, configurei um túnel entre o Mikrotik de casa e o roteador de borda no datacenter. Esse roteador no DC tem BGP com as operadoras de trânsito e é quem anuncia os IPs. Através desse túnel, estou transportando um bloco /27 até minha casa para usar nos servidores. Além disso, os servidores estão conectados ao Juniper, que faz a separação por VLANs. Também passo várias VLANs para o T330, pois estou dedicando uma VLAN para algumas VMs (apenas para testes). Dentro do Proxmox, ainda tenho uma VM rodando CHR, que funciona como um segundo roteador interno. Resumo: Mesmo usando uma banda larga residencial, consigo atribuir IPs públicos diretamente às VMs e servidores internos. Ainda tenho vVLAN separada exclusiva para o gerenciamento do IDRAC separando da VLAN publica, Uso esse ambiente como um laboratório real para testar qualquer mudança antes de aplicar no DC em produção. Conselho: Use nobreak em tudo! No ano passado, perdi uma placa-mãe de um Dell R630 por estar ligado direto na energia. Equipamentos: o que comentei, um roteador Mikrotik (barato e fácil de usar) e um switch gerenciável.

Mesmo sendo uma mudança de data center físico, hoje em dia é totalmente possível montar uma estrutura que permita migração de VPS online, sem gerar downtime. Por exemplo, dá pra configurar um túnel entre os dois data centers e criar um ambiente temporário onde as redes dos dois lados se comuniquem. Com isso, o provedor pode mover as VMs uma a uma, mantendo IP, MAC e conectividade durante a migração. Isso é algo comum quando se quer evitar indisponibilidade para o cliente final.

Estranho... eles estão mudando de data center físico ou é apenas uma migração de bare metal onde a VPS está alocada? Aqui, em casos de urgência, até fazemos migração durante o dia, mas sempre com a VPS online, de forma que o cliente final nem percebe. Só desligamos o VPS quando realmente não é possível migrar online, e mesmo assim, programamos para a madrugada, com downtime mínimo, geralmente de poucos minutos. Uma janela de até 12h em horário comercial é bem fora do padrão atual.

Onde você comprou? Consegue devolver? Vejo muitos vendedores no eBay, especialmente da China, vendendo drives "novos" mas não confio que realmente sejam novos, pois costumam ser modelos antigos. Geralmente eu compro HDDs e SSDs usados e sempre evito aqueles com dados do SMART zerados, pois isso pode indicar dados fake. Para mim, é melhor pegar um drive com 20~30 mil horas de uso e 1~2% de desgaste mas com os dados reais do que investir em um drive fraudado com SMART zerado e que pode estar no fim da vida útil.

E quando a HE não tem problemas??

Preciso migrar aproximadamente 500 contas do cPanel para o DirectAdmin e estou buscando alguém com experiência nesse processo. Interessados, por favor, me enviem uma mensagem privada com orçamento e detalhes sobre a experiência na migração.

Depende de quanto você paga do Dedicado e o valor do Cloud, mas acho que o maior problema é o custo da licença cPanel. Estou nessa de vender a carteira de clientes cPanel ou migrar tudo pra DA, o valor da licença cpanel está inviável.

De onde estão partindo os emails que vocês estão recebendo? Também estou recebendo emails falsos do cloudflare e paypal, na maioria dos casos estão partindo de outlook.com Exemplo dos remetentes que verifiquei hoje: 40.107.241.96 40.107.22.95

- Possibilidade de script malicioso: O VPS pode estar comprometido com algum malware ou script malicioso que está sendo usado para realizar os ataques. - Amplificação ou spoofing de IP: Verifique se o VPS do cliente está sendo usado como um vetor de amplificação de ataques ou está permitindo tráfego com spoofing de IPs. Serviços como DNS, NTP ou Memcached mal configurados podem ser utilizados para amplificação. - Problema no hypervisor ou outra VM: Pode haver um problema no hypervisor onde outra VM, acidentalmente ou maliciosamente, está utilizando o mesmo IP do VPS. Verifique a configuração das interfaces de rede e o isolamento entre as VMs. - Domínio de broadcast ou conflito de IPs: Apesar de improvável na infraestrutura da OVH, vale investigar a possibilidade de colisões no domínio de broadcast, onde outro servidor esteja utilizando o IP do VPS. Essa possibilidade é menos comum, mas não impossível. Acho que seria válido fazer uma captura de pacotes na interface de rede do VPS e analisar os pacotes capturados no Wireshark.

Sobre o não te atender? Mas foi algum problema não resolvido ou foi entregue alguma configuração diferente a contratada?

Não tinha me atentado a isso. Li algumas reclamações e algumas são do tipo "PIX contestado", o que acaba resultando no bloqueio geral da conta. Como mencionei no meu outro tópico e repeti aqui: "O MED está sendo utilizado para aplicar fraudes/golpes". Se antes já era perigoso receber uma contestação de cartão de crédito, hoje é ainda mais arriscado lidar com uma contestação de PIX no Cora. No caso do cartão, apenas o valor em questão é bloqueado. Além disso, com a verificação 3DS, as contestações de cartões se tornaram mais difíceis. Já no PIX, basta o cliente clicar em "contestar" para gerar todo esse transtorno para a empresa recebedora. Segundo o Banco Central (https://www.bcb.gov.br/meubc/faqs/p/o-que-e-e-como-funciona-o-mecanismo-especial-de-devolucao-med), o MED deveria ser utilizado apenas para casos de fraudes. Acredito que deveria haver uma consequência para quem denuncia fraude de forma indevida. Caso a fraude não seja comprovada, o denunciante deveria ser responsabilizado por falsa denúncia ou algo semelhante. Se continuarmos nesse cenário onde o "cliente" pode contestar qualquer PIX sem consequência, ele vai continuar abusando do sistema. Enquanto isso, as empresas que tentam trabalhar de forma legítima acabam pagando por conta de um sistema falho (MED).