Me inspirou a fazer este post .
Vou trazê-lo aqui:
hoje às 18:53
Hoje fiquei contente com o provedor. Junto com a atualização do sistema de bloqueio de sites, o provedor bloqueou o serviço de email mail.ru. Esta manhã estou contatando o suporte técnico, mas não conseguem resolver nada. O provedor é pequeno e aparentemente está bloqueado por provedores maiores. Também notei uma lentidão na abertura de todos os sites, pode ser que alguma DLP estranha tenha sido aplicada? Antes não havia problemas de acesso. A destruição da Runet está acontecendo bem diante dos meus olhos...
A questão é que, parece, somos esse provedor 🙁
E de fato, quase adivinhei a causa dos problemas com o mail.ru (embora tenhamos demorado a acreditar nisso).
A continuação será dividida em duas partes:
- as razões dos nossos problemas de hoje com o mail.ru e uma busca fascinante por eles
- a existência de ISPs nas realidades atuais, a estabilidade da Runet soberana.
Problemas de acessibilidade do mail.ru
Oh, essa é uma história longa.
A questão é que, para implementar os requisitos do governo (detalhes na segunda parte), adquirimos, configuramos e instalamos alguns equipamentos — tanto para filtrar recursos proibidos, quanto para realizar dos assinantes.
Há algum tempo, finalmente reestruturamos o núcleo da rede de maneira que todo o tráfego dos assinantes passasse por esse equipamento estritamente na direção correta.
Há alguns dias, ativamos a filtragem de conteúdos proibidos (ao mesmo tempo em que mantivemos o sistema antigo ativo) — à primeira vista, tudo correu bem.
Em seguida, começamos a ativar gradualmente o NAT para diferentes grupos de assinantes nesse equipamento. À primeira vista, também estava tudo aparentemente bem.
Mas hoje, ao ativar o NAT para mais um grupo de assinantes — desde a manhã nos deparamos com um número considerável de reclamações sobre a inacessibilidade ou acesso parcial e outros recursos do Mail Ru Group.
Começamos a investigar: algo em algum lugar às vezes, de forma esporádica enviava em resposta a requisições especificamente para redes do mail.ru. Além disso — estava enviando um TCP RST gerado incorretamente (sem ACK), claramente artificial. Aproximadamente assim foi:
Naturalmente, os primeiros pensamentos foram sobre o novo equipamento: terrível DPI, nenhuma confiança nele, quem sabe o que ele pode aprontar — já que TCP RST é algo bastante comum entre os meios de bloqueio.
Suposição sobre alguém 'superior' filtrando, também fizemos — mas logo descartamos.
Primeiro, temos uplinks bastante razoáveis para não sofrer com isso 🙂
Em segundo lugar, estamos conectados a vários em Moscovo, e o tráfego até mail.ru passa exatamente por eles — e estes não têm obrigações nem qualquer outro motivo para filtrar o tráfego.
A próxima metade do dia foi gasta no que geralmente chamam de xamã — junto com o fornecedor de equipamentos, pelo que lhe agradecemos, não desistimos 🙂
- a filtragem foi totalmente desconectada
- NAT foi desativado segundo um novo esquema
- o PC de teste foi colocado em um pool isolado
- a endereçamento IP foi alterada
Na segunda metade do dia, foi alocada uma VM que acessava a rede como um usuário comum, e tanto a ela quanto ao equipamento foi dado acesso a representantes do fornecedor. O xamanismo continuou 🙂
No final, o representante do fornecedor afirmou com confiança que o equipamento não tinha nada a ver com isso: os rst's vinham de algum lugar mais alto.
NotaNeste ponto, alguém pode afirmar: mas seria muito mais fácil capturar um dump não do PC de teste, mas da rota antes do DPI?
Não, infelizmente, capturar um dump (e até mesmo apenas espelhar) 40+gbps não é trivial.
Depois disso, já à noite — não restava nada a fazer a não ser voltar à suposição de uma filtragem estranha em algum lugar acima.
Eu verifiquei por qual IX o tráfego está passando até as redes MRG e simplesmente cancelei as sessões bgp. E — oh maravilha! — tudo imediatamente se normalizou 🙁
Por um lado — é uma pena que a busca pelo problema levou o dia todo, embora poderia ter sido resolvido em cinco minutos.
Por outro lado:
— na minha memória, isso é algo sem precedentes. Como já escrevi acima — para os IX's realmente não faz sentido filtrar o tráfego de trânsito. Geralmente, eles têm centenas de gigabits / terabits por segundo. Eu simplesmente não poderia imaginar seriamente algo assim até o último momento.
— uma coincidência incrivelmente favorável: novo equipamento complicado, ao qual não se tem muita confiança e do qual não se sabe o que esperar — projetado exatamente para bloquearem recursos, inclusive com TCP RST's.
Atualmente, o NOC deste internet exchange está buscando o problema. Segundo eles (e eu acredito neles), não há nenhum sistema de filtragem especialmente implantado. Mas, graças ao céu, a próxima busca já não é nosso problema 🙂
Esta foi uma pequena tentativa de justificar-me, pedimos que entendam e perdoem 🙂
P.S.: eu intencionalmente não cito nem o fabricante de DPI/NAT, nem o IX (na verdade, não tenho reclamações especiais contra eles, o principal é entender o que aconteceu)
A realidade de hoje (assim como a de ontem e antes de ontem) do ponto de vista de um provedor de internet
As últimas semanas passei substancialmente reestruturando o núcleo da rede, realizando várias manipulações 'ao vivo', com o risco de impactar significativamente o tráfego de usuários ativo. Considerando os objetivos, resultados e consequências de tudo isso — moralmente, tudo isso é bastante pesado. Especialmente ao ouvir novamente os discursos idealistas sobre a proteção da estabilidade da Runet, soberania, etc.
Nesta seção, tentarei descrever a 'evolução' do núcleo da rede de um provedor 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 simples e confiável como uma rolha:
Nesta imagem muito, muito simplificada, estão ausentes as autopistas, anéis, roteamento IP/MPLS.
A essência disso é que o tráfego dos usuários, no final das contas, chegava à comutação de nível de núcleo — de onde seguia para , de onde, como regra, — voltava à comutação do núcleo, e depois 'para fora' — através de um ou mais gateways de borda para a internet.
Esse esquema é muito, muito facilmente redundante tanto no L3 (roteamento dinâmico) quanto no L2 (MPLS).
É possível colocar N+1 de qualquer coisa: servidores de acesso, switches, bordas — e de uma forma ou outra, reservá-los para failover automático.
Após alguns anos todos na Rússia perceberam que não se podia continuar assim: era necessário urgentemente proteger as crianças da influência corruptora da rede.
Surgiu a necessidade urgente de encontrar maneiras de filtrar o tráfego dos usuários.
Existem diferentes abordagens.
No pior dos casos — algo é instalado 'em corte': entre o tráfego do usuário e a internet. O tráfego que passa por esse 'algo' é analisado e, por exemplo, um pacote falso é enviado ao assinante com redirecionamento.
Em um cenário um pouco melhor — se os volumes de tráfego permitirem — é possível fazer um pequeno truque: enviar para filtragem apenas o tráfego de saída dos usuários para aqueles endereços que precisam ser filtrados (para isso, pode-se retirar do registro os IPs indicados ou resolver adicionalmente os domínios existentes no registro).
Na época, escrevi uma solução simples — embora nem mesmo consiga chamá-lo assim. É muito simples e não muito eficiente — no entanto, tanto para nós quanto para dezenas (se não centenas) de outros provedores, permitiu que não gastássemos milhões em sistemas DPI industriais de imediato, e nos deu alguns anos a mais.
Falando nisso, sobre os DPI de então e os atuaisVale a pena mencionar que muitos que adquiriram os sistemas DPI disponíveis no mercado até aquele momento — já os descartaram. Eles não foram feitos para isso: centenas de milhares de endereços, dezenas de milhares de URLs.
Ao mesmo tempo, o mercado levantou muito os fabricantes nacionais. Não estou falando da parte de hardware — isso é claro para todos, mas o software — o principal que existe no DPI — possivelmente, hoje se não é o mais avançado do mundo, é com certeza a) evolui a passos largos, e b) em termos de preços de caixa — simplesmente incomparável com os concorrentes estrangeiros.
Gostaria de me orgulhar, mas é um pouco triste =)
Agora tudo parecia assim:
Depois de mais alguns anos todos já tinham revisores; os recursos no registro estavam cada vez mais numerosos. Para alguns equipamentos antigos (por exemplo, cisco 7600), o esquema de "filtragem lateral" tornava-se simplesmente inutilizável: o número de rotas na plataforma 76 está limitado a cerca de novecentas mil, enquanto o número de rotas IPv4 hoje já se aproxima de 800 mil. E se também for ipv6... E ainda... quantos lá? 900000 endereços separados banidos pelo rkn? =)
Alguns migraram para um esquema de espelhamento de todo o tráfego da rede tronco para um servidor de filtragem, que deve analisar todo o fluxo e, ao encontrar algo errado, enviar em ambas as direções (para o remetente e o destinatário) RST.
No entanto, quanto mais tráfego, menos aplicável se torna tal esquema. Com qualquer atraso mínimo no processamento — o tráfego espelhado simplesmente passará despercebido, e o provedor receberá um aviso de penalidade.
Cada vez mais provedores são obrigados a implementar sistemas DPI de vários níveis de confiabilidade nas conexões principais.
Um ou dois anos atrás reza a lenda que quase todos os serviços de segurança exigiram a instalação real de equipamentos (anteriormente, a maioria dos provedores contornava isso negociando com as autoridades o plano SORM — um plano de ações operacionais para o caso de ser necessário encontrar algo em algum lugar)
Além do custo (não é que sejam valores exorbitantes, mas ainda assim — milhões), o SORM exigiu uma série de manipulações com a rede para muitos.
- O SORM precisa visualizar os endereços 'cinzas' dos usuários, antes da tradução NAT
- O SORM tem um número limitado de interfaces de rede
Portanto, tivemos que reestruturar bastante uma parte do núcleo — simplesmente para coletar em um único lugar o tráfego dos usuários para os servidores de acesso. Para poder espelhar isso no SORM através de várias conexões.
Ou seja, de forma bastante simplificada, era (à esquerda) vs tornou-se (à direita):
Agora a maioria dos provedores também está sendo exigida a implementação do SORM-3 — que inclui, entre outras coisas, o registro de traduções NAT.
Para esses fins, tivemos que adicionar também um equipamento separado para NAT na diagrama acima (que é exatamente o mencionado na primeira parte). E adicionar em uma ordem específica: uma vez que o SORM deve 'ver' o tráfego antes da tradução de endereços — o tráfego deve seguir rigorosamente esta ordem: usuários -> comutação, núcleo -> servidores de acesso -> SORM -> NAT -> comutação, núcleo -> internet. Para isso, tivemos que literalmente 'reverter' os fluxos de tráfego na prática, o que também não foi nada fácil.
Em resumo: em uma década, o esquema do núcleo de um provedor médio se complicou enormemente, e o número de pontos de falha adicionais (tanto na forma de equipamentos quanto na forma de linhas de comutação únicas) aumentou consideravelmente. De fato, a exigência de 'ver tudo' implica em centralizar esse 'tudo' em um único ponto.
Acredito que isso pode ser claramente extrapolado para as iniciativas atuais de soberania da internet russa, sua proteção, estabilização e melhoria 🙂
E ainda tem a Lei Yarovaya pela frente.
Fonte: habr.com
