Uma resposta detalhada ao comentário, bem como um pouco sobre a vida dos provedores na Federação Russa

Mova-me para este post. Este aqui é um comentário .

Eu o trago aqui:

kaleman hoje às 18:53

Hoje fiquei satisfeito com o provedor. Junto com a atualização do sistema de bloqueio de sites, ele recebeu uma correspondência mail.ru sob a proibição. De manhã, puxo o suporte técnico, eles não podem fazer nada. O provedor é pequeno e, aparentemente, os fornecedores upstream o estão bloqueando. Também notei uma desaceleração na abertura de todos os sites, talvez algum tipo de curva DLP pendurada? Anteriormente, não havia problemas com o acesso. A destruição de Runet vai bem diante dos meus olhos ...

O fato é que, ao que parece, somos o próprio provedor :(

De fato, kaleman quase adivinhou com a causa dos problemas com o mail.ru (embora por um longo tempo nos recusássemos a acreditar nisso).

Além disso será dividido em duas partes:

1. as causas dos nossos problemas hoje com mail.ru e uma emocionante busca para encontrá-los
2. a existência de ISP nas realidades de hoje, a estabilidade do runet soberano.

Problemas com a disponibilidade do mail.ru

Oh, essa é uma história bastante longa.

O fato é que, para implementar os requisitos do estado (em mais detalhes na segunda parte), adquirimos, configuramos e instalamos alguns equipamentos - tanto para filtrar recursos proibidos quanto para realizar transmissões de assinantes NAT .

Algum tempo atrás, finalmente reconstruímos o núcleo da rede para que todo o tráfego de assinantes passasse por esse equipamento na direção certa.

Alguns dias atrás, ativamos a filtragem de conteúdo proibido (ao mesmo tempo em que deixava o sistema antigo funcionar) - tudo parecia correr bem.

Além disso - gradualmente começou a incluir para diferentes partes dos assinantes NAT neste equipamento. Na aparência - tudo também parece ter corrido bem.

Mas hoje, depois de ligar o equipamento NAT para a próxima parte de assinantes, de manhã, encontramos um número decente de reclamações sobre a indisponibilidade ou disponibilidade parcial do mail.ru e outros recursos do Mail Ru Group.

Eles começaram a verificar: algo em algum lugar, às vezes , envia o TCP RST em resposta a solicitações exclusivamente às redes mail.ru. Além disso, ele envia um TCP RST artificialmente gerado (sem ACK), obviamente artificial. Algo parecido com isto:







Naturalmente, os primeiros pensamentos foram sobre novos equipamentos: um DPI terrível, não há confiança nele, você nunca sabe o que pode fazer - o TCP RST é uma coisa bastante comum entre as ferramentas de bloqueio.

A suposição de kaleman de que alguém está filtrando "superior", também propomos - mas depois descartamos.

Em primeiro lugar, temos uplinks sensatos suficientes para não sofrermos assim :)

Em segundo lugar, estamos conectados a vários IXs em Moscou, e o tráfego para mail.ru passa precisamente por eles - e eles não têm nenhum dever ou outro motivo para filtrar o tráfego.

A metade do dia seguinte foi gasta com o que geralmente é chamado xamanismo - junto com o fornecedor do equipamento, pelo qual eles agradecem, eles não desistiram :)

• a filtragem foi completamente desativada
• O NAT foi desconectado de acordo com o novo esquema
• PC de teste foi movido para um pool isolado separado
• Endereço IP alterado

À tarde, foi alocada uma máquina virtual que foi para a rede de acordo com o esquema de um usuário comum, e os representantes do fornecedor tiveram acesso a ela e ao equipamento. Xamanismo continuou :)

No final, o representante do fornecedor afirmou com confiança que o hardware não tinha absolutamente nada a ver com isso: os rsts vinham de algum lugar mais alto.


Depois disso, à noite, não havia mais nada a fazer senão voltar à suposição de uma estranha filtragem em algum lugar acima.

Examinei o tráfego IX agora para as redes dos IWGs e apenas paguei sessões bgp. E eis que eis! - tudo imediatamente voltou ao normal :(

Por um lado, é lamentável que o dia inteiro tenha sido gasto procurando o problema, embora tenha sido resolvido em cinco minutos.

Por outro lado:

- na minha memória isso é algo sem precedentes. Como escrevi acima - IX, não há realmente sentido em filtrar o tráfego de trânsito. Eles geralmente têm centenas de gigabits / terabits por segundo. Eu só até o último não podia imaginar isso seriamente.

- um conjunto de circunstâncias incrivelmente bem-sucedido: um novo hardware complexo, que não tem muita confiança e do qual não está claro o que esperar - aguçado apenas sob o bloqueio de recursos, incluindo TCP RSTs

Atualmente, o NOC dessa troca de internet está procurando um problema. Segundo eles (e eu acredito neles), eles não têm um sistema de filtragem especialmente desenvolvido. Mas, graças ao céu, a busca adicional não é mais o nosso problema :)

Foi uma pequena tentativa de justificar a nós mesmos, por favor, entenda e perdoe :)

PS: Eu intencionalmente não nomeio o fabricante do DPI / NAT, nem o IX (eu, de fato, não tenho nenhuma reclamação especial contra eles, o principal é entender o que era)

Hoje (assim como ontem e anteontem) a realidade do ponto de vista do provedor de Internet

Passei as últimas semanas, reconstruindo significativamente o núcleo da rede, realizando várias "ganhos" de manipulação, com o risco de afetar significativamente o tráfego de usuários ao vivo. Dados os objetivos, resultados e consequências de tudo isso - moralmente, tudo isso é bastante difícil. Especialmente - mais uma vez ouvindo os discursos magnânimos sobre a proteção da estabilidade de Runet, soberania etc. etc.

Nesta seção, tentarei contar a “evolução” da rede principal de um provedor de serviços de Internet típico nos últimos dez anos.

Dez anos atrás.

Naqueles tempos abençoados, o núcleo da rede do provedor poderia ser tão simples e confiável quanto um engarrafamento:



Nesta imagem muito, muito simplificada, não há rodovias, anéis, roteamento ip / mpls.

Sua essência é que o tráfego do usuário finalmente chegou à comutação no nível do kernel - de onde foi para o BNG , de onde, via de regra, de volta à comutação do kernel e depois "para sair" - através de um ou mais gateways de fronteira para a Internet.

Esse esquema é muito, muito facilmente reservado tanto no L3 (roteamento dinâmico) quanto no L2 (MPLS).

Você pode colocar qualquer coisa N + 1: acessar servidores, comutadores, pensionistas - e de alguma forma reservá-los para failover automático.

Depois de alguns anos, ficou claro para todos na Rússia que era impossível viver assim: era urgentemente necessário proteger as crianças da influência prejudicial da rede.

Havia uma necessidade urgente de encontrar maneiras de filtrar o tráfego do usuário.

Existem abordagens diferentes.

Em um caso não tão bom, algo é colocado "no corte": entre o tráfego de usuários e a Internet. O tráfego que passa por esse "algo" é analisado e, por exemplo, um pacote de redirecionamento falso é enviado para o lado do assinante.

Em um caso um pouco melhor - se o volume de tráfego permitir - você pode fazer uma pequena simulação com os ouvidos: envie apenas o tráfego de saída dos usuários para os endereços que precisam ser filtrados (para isso, você pode pegar os endereços IP especificados no registro ou resolver os existentes. domínios no registro).

Ao mesmo tempo, para esses fins, escrevi um mini-dpi simples - embora até o idioma não se atreva a chamá-lo assim. É muito simples e não muito produtivo - no entanto, permitiu a nós, e dezenas (se não centenas) de outros fornecedores, não gastar imediatamente milhões em sistemas industriais de DPI, mas com vários anos adicionais.


Agora ficou assim:



Depois de alguns anos , todos já tinham auditores; recursos no registro tornaram-se cada vez mais. Para alguns equipamentos antigos (por exemplo, Cisco 7600), o esquema de "filtragem lateral" simplesmente se tornou inaplicável: o número de rotas em 76 plataformas foi limitado a algo em torno de novecentos mil, enquanto o número de rotas IPv4 hoje já se aproxima de 800 mil. E se também ipv6 ... E também ... quanto existe? 900.000 endereços individuais no banho RCN? =)

Alguém mudou para um esquema que espelhava todo o tráfego principal para o servidor de filtragem, que deveria analisar todo o fluxo e enviar algo RST para os dois lados (remetente e destinatário) quando encontrar algo ruim.

No entanto, quanto mais tráfego, menos aplicável esse esquema. No menor atraso no processamento, o tráfego espelhado simplesmente passa despercebido e o provedor recebe um relatório fino.

Cada vez mais fornecedores são forçados a colocar sistemas DPI com graus variados de confiabilidade no contexto das rodovias.

Há um ou dois anos, segundo os rumores, quase todos os FSBs começaram a exigir a instalação real do equipamento SORM (anteriormente, a maioria dos fornecedores conseguia coordenar o plano SORM com as autoridades - um plano de medidas operacionais em caso de necessidade de encontrar algo em algum lugar)

Além do dinheiro (não tão diretamente no alto, mas ainda milhões), o SORM exigia muito mais manipulações de rede para muitos.

• O SORM precisa ver os endereços "cinza" dos usuários, antes da transmissão nat
• O SORM possui um número limitado de interfaces de rede

Portanto, em particular, tivemos que reconstruir um pedaço do kernel de maneira legal - apenas para coletar o tráfego do usuário para acessar servidores em algum lugar do mesmo lugar. Para espelhá-lo com vários links no SORM.

Ou seja, muito simplificado, foi (à esquerda) vs se tornou (à direita):



Agora , a maioria dos fornecedores também exige a introdução do SORM-3 - o que inclui, mas não está limitado a, o registro de transmissões de NAT.

Para esses propósitos, tivemos que adicionar equipamentos separados para NAT no circuito acima (apenas o discutido na primeira parte). E para adicionar em uma certa ordem: como o SORM deve "ver" o tráfego antes da tradução do endereço - o tráfego deve ser exatamente o seguinte: usuários -> comutação, kernel -> servidores de acesso -> SORM -> NAT -> comutação, núcleo -> Internet. Para fazer isso, tivemos que literalmente "implantar" os fluxos de tráfego na outra direção, o que também foi bastante difícil.

Total: mais de uma dúzia de anos, o circuito principal do fornecedor se tornou mais complexo às vezes, e pontos adicionais de falha (tanto na forma de equipamento quanto na forma de linhas de comutação únicas) aumentaram significativamente. Na verdade, a exigência de "ver tudo" em si implica a redução desse "tudo" a um ponto.

Parece-me que isso pode ser extrapolado de maneira bastante transparente para as iniciativas atuais sobre a soberania do Runet, sua proteção, estabilização e aprimoramento :)

E adiante está Yarovaya.