Me levou a esta postagem .
Cito aqui:
hoje em 18: 53
Fiquei satisfeito com o fornecedor hoje. Junto com a atualização do sistema de bloqueio de sites, seu mailer mail.ru foi banido, estou ligando para o suporte técnico desde manhã, mas eles não podem fazer nada. O provedor é pequeno e, aparentemente, provedores de classificação superior o bloqueiam. Notei também uma lentidão na abertura de todos os sites, talvez tenham instalado algum tipo de DLP torto? Anteriormente não havia problemas de acesso. A destruição do RuNet está acontecendo bem diante dos meus olhos...
O fato é que parece que somos o mesmo fornecedor :)
E de fato Quase adivinhei a causa dos problemas com mail.ru (embora por muito tempo nos recusemos a acreditar nisso).
O que se segue será dividido em duas partes:
- as razões dos nossos problemas atuais com mail.ru e a emocionante busca para encontrá-los
- a existência do ISP nas realidades de hoje, a estabilidade do RuNet soberano.
Problemas de acessibilidade com mail.ru
Ah, é uma longa história.
O fato é que para atender às exigências do estado (mais detalhes na segunda parte), adquirimos, configuramos e instalamos alguns equipamentos - tanto para filtragem de recursos proibidos quanto para implementação assinantes.
Há algum tempo, finalmente reconstruímos o núcleo da rede de forma que todo o tráfego de assinantes passasse por este equipamento estritamente na direção certa.
Há alguns dias ativamos a filtragem proibida (deixando o sistema antigo funcionando) - tudo parecia estar indo bem.
Em seguida, eles gradualmente começaram a habilitar o NAT neste equipamento para diferentes partes dos assinantes. Pelo que parece, tudo também parecia correr bem.
Mas hoje, tendo habilitado o NAT nos equipamentos para a próxima parcela de assinantes, desde a manhã nos deparamos com um número razoável de reclamações sobre indisponibilidade ou disponibilidade parcial e outros recursos do Grupo Mail Ru.
Eles começaram a verificar: algo em algum lugar às vezes, ocasionalmente envia em resposta a solicitações exclusivamente às redes mail.ru. Além disso, ele envia um TCP RST gerado incorretamente (sem ACK), obviamente artificial. Isto é o que parecia:
Naturalmente, os primeiros pensamentos foram sobre o novo equipamento: DPI terrível, não há confiança nele, nunca se sabe o que ele pode fazer - afinal, TCP RST é algo bastante comum entre as ferramentas de bloqueio.
Suposição Também apresentamos a ideia de que alguém “superior” está filtrando, mas descartamos imediatamente.
Em primeiro lugar, temos uplinks suficientemente sensatos para não termos que sofrer assim :)
Em segundo lugar, estamos ligados a vários em Moscou, e o tráfego para mail.ru passa por eles - e eles não têm responsabilidades nem qualquer outro motivo para filtrar o tráfego.
A metade do dia seguinte foi dedicada ao que se costuma chamar de xamanismo - junto com o vendedor do equipamento, pelo qual agradecemos, eles não desistiram :)
- a filtragem foi completamente desativada
- NAT foi desativado usando o novo esquema
- o PC de teste foi colocado em um pool isolado separado
- Endereçamento IP alterado
À tarde, foi alocada uma máquina virtual que se conectou à rede de acordo com o esquema de um usuário regular, e representantes do fornecedor tiveram acesso a ela e ao equipamento. O xamanismo continuou :)
No final, o representante do fornecedor afirmou com segurança que o hardware não tinha absolutamente nada a ver com isso: os primeiros vêm de algum lugar mais alto.
NotaNesse ponto, alguém pode dizer: mas foi muito mais fácil fazer um dump não do PC de teste, mas da rodovia acima do DPI?
Não, infelizmente, fazer um dump (e até mesmo espelhar) de mais de 40 gbps não é nada trivial.
Depois disso, à noite, não havia mais nada a fazer senão voltar à suposição de uma estranha filtração em algum lugar acima.
Eu olhei por qual IX o tráfego para as redes MRG está passando agora e simplesmente cancelei as sessões BGP para ele. E - vejam só! - tudo voltou imediatamente ao normal 🙁
Por um lado, é uma pena que tenhamos passado o dia inteiro à procura do problema, embora este tenha sido resolvido em cinco minutos.
Por outro lado:
- na minha memória isso é algo sem precedentes. Como já escrevi acima - IX realmente não faz sentido filtrar o tráfego de trânsito. Eles geralmente têm centenas de gigabits/terabits por segundo. Eu simplesmente não conseguia imaginar seriamente algo assim até recentemente.
— uma coincidência de circunstâncias incrivelmente feliz: um novo hardware complexo que não é particularmente confiável e do qual não está claro o que pode ser esperado — adaptado especificamente para bloquear recursos, incluindo TCP RSTs
O NOC desta central de internet está atualmente procurando um problema. Segundo eles (e acredito neles), não possuem nenhum sistema de filtragem especialmente implantado. Mas, graças a Deus, a busca adicional não é mais problema nosso :)
Esta foi uma pequena tentativa de me justificar, por favor, entenda e perdoe :)
PS: Deliberadamente não menciono o nome do fabricante do DPI/NAT ou IX (na verdade, nem tenho nenhuma reclamação especial sobre eles, o principal é entender o que era)
A realidade de hoje (bem como de ontem e de anteontem) do ponto de vista de um provedor de Internet
Passei as últimas semanas reconstruindo significativamente o núcleo da rede, realizando uma série de manipulações “com fins lucrativos”, com o risco de afetar significativamente o tráfego de usuários ativos. Considerando os objetivos, resultados e consequências de tudo isso, moralmente é tudo muito difícil. Especialmente - mais uma vez ouvindo belos discursos sobre a proteção da estabilidade do Runet, da soberania, etc. e assim por diante.
Nesta seção, tentarei descrever a “evolução” do núcleo da rede de um ISP típico nos últimos dez anos.
Dez anos atrás.
Naqueles tempos abençoados, o núcleo de uma rede de provedores poderia ser tão simples e confiável quanto um engarrafamento:
Nesta imagem muito simplificada, não há troncos, anéis, roteamento ip/mpls.
Sua essência é que o tráfego do usuário, em última análise, chega à troca no nível do kernel - de onde foi para , de onde, via de regra, de volta à comutação central e depois “para fora” - através de um ou mais gateways de fronteira para a Internet.
Esse esquema é muito, muito fácil de reservar tanto em L3 (roteamento dinâmico) quanto em L2 (MPLS).
Você pode instalar N+1 de qualquer coisa: servidores de acesso, switches, fronteiras - e de uma forma ou de outra reservá-los para failover automático.
Depois de alguns anos Tornou-se claro para todos na Rússia que era impossível continuar a viver assim: era urgente proteger as crianças da influência perniciosa da Internet.
Havia uma necessidade urgente de encontrar maneiras de filtrar o tráfego de usuários.
Existem diferentes abordagens aqui.
Num caso não muito bom, algo é colocado “na lacuna”: entre o tráfego dos usuários e a Internet. O tráfego que passa por esse “algo” é analisado e, por exemplo, um pacote falso com redirecionamento é enviado ao assinante.
Em um caso um pouco melhor - se os volumes de tráfego permitirem - você pode fazer um pequeno truque com seus ouvidos: enviar para filtragem apenas o tráfego originado de usuários apenas para os endereços que precisam ser filtrados (para fazer isso, você pode pegar os endereços IP especificado lá no registro ou, adicionalmente, resolver os domínios existentes no registro).
Certa vez, para esses fins, escrevi um simples - embora eu nem me atreva a chamá-lo assim. É muito simples e não muito produtivo - no entanto, permitiu que nós e dezenas (senão centenas) de outros fornecedores não desembolsássemos milhões imediatamente em sistemas DPI industriais, mas nos deu vários anos adicionais de tempo.
A propósito, sobre o DPI então e atualAliás, muitos que adquiriram os sistemas DPI disponíveis no mercado naquela época já os haviam jogado fora. Bem, eles não foram projetados para isso: centenas de milhares de endereços, dezenas de milhares de URLs.
E ao mesmo tempo, os produtores nacionais têm ascendido muito fortemente a este mercado. Não estou falando do componente de hardware - tudo está claro para todos aqui, mas o software - a principal coisa que o DPI tem - é talvez hoje, se não o mais avançado do mundo, então certamente a) está se desenvolvendo aos trancos e barrancos, eb) ao preço de um produto embalado - simplesmente incomparável com os concorrentes estrangeiros.
Gostaria de ficar orgulhoso, mas um pouco triste =)
Agora tudo ficou assim:
Em mais alguns anos todos já tinham auditores; Havia cada vez mais recursos no registro. Para alguns equipamentos mais antigos (por exemplo, Cisco 7600), o esquema de “filtragem lateral” simplesmente tornou-se inaplicável: o número de rotas em 76 plataformas é limitado a algo como novecentas mil, enquanto o número de rotas IPv4 hoje se aproxima de 800. mil. E se também for ipv6... E também... quanto custa? 900000 endereços individuais na proibição de RKN? =)
Alguém mudou para um esquema com espelhamento de todo o tráfego do backbone para um servidor de filtragem, que deve analisar todo o fluxo e, caso algo ruim seja encontrado, enviar RST nas duas direções (remetente e destinatário).
No entanto, quanto mais tráfego, menos aplicável é este esquema. Se houver o menor atraso no processamento, o tráfego espelhado simplesmente passará despercebido e o provedor receberá um relatório fino.
Cada vez mais fornecedores são forçados a instalar sistemas DPI com vários graus de confiabilidade nas rodovias.
Um ou dois anos atrás segundo rumores, quase todo o FSB passou a exigir a própria instalação dos equipamentos (anteriormente, a maioria dos provedores gerenciava com a aprovação das autoridades Plano SORM - um plano de medidas operacionais em caso de necessidade de encontrar algo em algum lugar)
Além do dinheiro (não exatamente exorbitante, mas ainda milhões), o SORM exigia muito mais manipulações na rede.
- SORM precisa ver endereços de usuários “cinza” antes da tradução nat
- SORM tem um número limitado de interfaces de rede
Portanto, em particular, tivemos que reconstruir fortemente uma parte do kernel - simplesmente para coletar o tráfego do usuário para servidores de acesso em algum lugar em um só lugar. Para espelhar no SORM com vários links.
Ou seja, muito simplificado, era (esquerda) vs tornou-se (direita):
Agora A maioria dos provedores também exige a implementação do SORM-3 – que inclui, entre outras coisas, o registro de transmissões nat.
Para isso, também tivemos que adicionar equipamentos separados para NAT ao diagrama acima (exatamente o que é discutido na primeira parte). Além disso, adicione em uma determinada ordem: como o SORM deve “ver” o tráfego antes de traduzir os endereços, o tráfego deve ocorrer estritamente da seguinte forma: usuários -> comutação, kernel -> servidores de acesso -> SORM -> NAT -> comutação, kernel - >Internet. Para fazer isso, tivemos que literalmente “virar” os fluxos de tráfego na outra direção para obter lucro, o que também foi bastante difícil.
Em resumo: nos últimos dez anos, a concepção central de um fornecedor médio tornou-se muitas vezes mais complexa e os pontos adicionais de falha (tanto na forma de equipamento como na forma de linhas de comutação únicas) aumentaram significativamente. Na verdade, a própria exigência de “ver tudo” implica reduzir esse “tudo” a um ponto.
Acho que isso pode ser extrapolado de forma bastante transparente para as iniciativas atuais para soberanizar o Runet, protegê-lo, estabilizá-lo e melhorá-lo :)
E Yarovaya ainda está à frente.
Fonte: habr.com