Invitoume a esta publicación .
Citoo aquí:
hoxe ás 18:53
Hoxe quedei satisfeito co provedor. Xunto coa actualización do sistema de bloqueo de sitios, prohibiuse o seu correo mail.ru. Levo chamando ao soporte técnico dende a mañá, pero non poden facer nada. O provedor é pequeno e, aparentemente, os provedores de maior rango o bloquean. Tamén notei unha desaceleración na apertura de todos os sitios, quizais instalaron algún tipo de DLP torto? Anteriormente non había problemas de acceso. A destrución de RuNet está ocorrendo xusto ante os meus ollos...
O caso é que parece que somos ese mesmo provedor :)
E de feito, Case adiviñei a causa dos problemas con mail.ru (aínda que nos negamos a crer en tal cousa durante moito tempo).
O que segue dividirase en dúas partes:
- as razóns dos nosos problemas actuais con mail.ru e a emocionante procura para atopalos
- a existencia de ISP nas realidades actuais, a estabilidade da RuNet soberana.
Problemas de accesibilidade con mail.ru
Ai, é unha historia bastante longa.
O feito é que para implementar os requisitos do estado (máis detalles na segunda parte), compramos, configuramos e instalamos algúns equipos, tanto para filtrar recursos prohibidos como para implementar subscritores.
Hai tempo, por fin reconstruímos o núcleo da rede de forma que todo o tráfico de subscritores pasase por este equipo estrictamente na dirección correcta.
Hai uns días activamos o filtrado prohibido (mentres deixabamos funcionando o sistema antigo) - todo parecía ir ben.
A continuación, gradualmente comezaron a habilitar NAT neste equipo para diferentes partes dos abonados. Polo que se ve, todo parecía ir ben.
Pero hoxe, unha vez habilitado o NAT no equipo para a seguinte parte de abonados, desde a mesma mañá atopámonos con un número decente de queixas por falta de dispoñibilidade ou dispoñibilidade parcial. e outros recursos do Grupo Mail Ru.
Comezaron a comprobar: algo nalgún lado ás veces, ocasionalmente envía en resposta a solicitudes exclusivamente ás redes mail.ru. Ademais, envía un TCP RST incorrectamente xerado (sen ACK), obviamente artificial. Este é o que parecía:
Por suposto, os primeiros pensamentos foron sobre o novo equipo: DPI terrible, non confías nel, nunca sabes o que pode facer; despois de todo, TCP RST é algo bastante común entre as ferramentas de bloqueo.
Asunción Tamén expuxemos a idea de que alguén "superior" está a filtrar, pero inmediatamente descartámola.
En primeiro lugar, temos ligazóns ascendentes suficientemente sensatas para non ter que sufrir así :)
En segundo lugar, estamos conectados con varios en Moscova, e o tráfico a mail.ru pasa por eles, e non teñen nin responsabilidades nin ningún outro motivo para filtrar o tráfico.
A seguinte metade do día dedicouse ao que se adoita chamar chamanismo: xunto co vendedor de equipos, polo que lles damos as grazas, non se rendiron :)
- o filtrado desactivouse por completo
- Desactivouse o NAT mediante o novo esquema
- o PC de proba colocouse nunha piscina illada separada
- O enderezo IP cambiou
Pola tarde, asignouse unha máquina virtual que se conectaba á rede segundo o esquema dun usuario habitual, e os representantes do vendedor tiveron acceso a ela e aos equipos. O chamanismo continuou :)
Ao final, o representante do vendedor afirmou con confianza que o hardware non tiña absolutamente nada que ver con iso: os primeiros veñen de algún lugar máis alto.
NotaNeste punto, alguén pode dicir: pero foi moito máis doado facer un vertedoiro non desde o PC de proba, senón desde a estrada por riba do DPI?
Non, desafortunadamente, facer un vertedoiro (e incluso só duplicar) 40+gbps non é nada trivial.
Despois disto, pola noite, non quedaba máis que facer máis que volver á suposición dunha estraña filtración nalgún lugar superior.
Busquei por que IX pasa agora o tráfico ás redes MRG e simplemente cancelei as sesións bgp. E velaquí! - Todo volveu inmediatamente á normalidade 🙁
Por unha banda, é unha mágoa que todo o día estivese na procura do problema, aínda que se solucionou en cinco minutos.
Por outra banda:
- Na miña memoria isto é algo sen precedentes. Como xa escribín arriba - IX realmente non ten sentido filtrar o tráfico de tránsito. Normalmente teñen centos de gigabits/terabits por segundo. Simplemente non podía imaxinar algo así ata hai pouco.
— unha coincidencia de circunstancias incriblemente afortunada: un novo hardware complexo no que non se confía especialmente e do que non está claro o que se pode esperar — adaptado especificamente para bloquear recursos, incluídos os RST TCP
O NOC desta bolsa de internet está buscando actualmente un problema. Segundo eles (e creo que eles), non teñen ningún sistema de filtración especialmente despregado. Pero, grazas ao ceo, a procura posterior xa non é o noso problema :)
Este foi un pequeno intento de xustificarme, entendelo e perdoade :)
PD: Non nomeo deliberadamente o fabricante de DPI/NAT ou IX (de feito, nin sequera teño ningunha queixa especial sobre eles, o principal é entender o que foi)
A realidade de hoxe (así como a de onte e a de antonte) dende o punto de vista dun provedor de Internet
Pasei as últimas semanas reconstruíndo significativamente o núcleo da rede, realizando unha morea de manipulacións "con ánimo de lucro", co risco de afectar significativamente o tráfico de usuarios en directo. Tendo en conta os obxectivos, resultados e consecuencias de todo isto, moralmente todo é bastante difícil. Especialmente - unha vez máis escoitar fermosos discursos sobre protexer a estabilidade do Runet, a soberanía, etc. etcétera.
Nesta sección, tentarei describir a "evolución" do núcleo de rede dun ISP típico nos últimos dez anos.
Hai dez anos.
Neses tempos benditos, o núcleo dunha rede de provedores podería ser tan sinxelo e fiable como un atasco:
Nesta imaxe moi, moi simplificada, non hai troncais, aneis, enrutamento ip/mpls.
A súa esencia é que o tráfico de usuarios finalmente chegou ao cambio de nivel do núcleo, desde onde foi , desde onde, por regra xeral, volve á conmutación do núcleo e, a continuación, "saía" - a través dunha ou máis pasarelas de fronteira a Internet.
Este esquema é moi, moi sinxelo de reservar tanto en L3 (enrutamento dinámico) como en L2 (MPLS).
Podes instalar N+1 de calquera cousa: acceder a servidores, interruptores, bordos e, dun xeito ou doutro, reservalos para a conmutación automática por fallo.
Despois duns anos Quedou claro para todos en Rusia que era imposible vivir así máis: era urxente protexer aos nenos da influencia perniciosa de Internet.
Había unha necesidade urxente de buscar formas de filtrar o tráfico de usuarios.
Aquí hai diferentes enfoques.
Nun caso non moi bo, ponse algo "na brecha": entre o tráfico de usuarios e Internet. Analízase o tráfico que pasa por este “algo” e, por exemplo, envíase un paquete falso cunha redirección cara ao abonado.
Nun caso un pouco mellor -se o volume de tráfico o permite- podes facer un pequeno truco cos teus oídos: enviar para filtrar só o tráfico procedente dos usuarios só a aqueles enderezos que hai que filtrar (para iso, podes tomar os enderezos IP). especificado alí desde o rexistro, ou resolver adicionalmente os dominios existentes no rexistro).
Nun tempo, para estes efectos, escribín un sinxelo - aínda que nin sequera me atrevo a chamalo así. É moi sinxelo e non moi produtivo; con todo, permitiunos a nós e a decenas (se non centos) doutros provedores non desembolsar de inmediato millóns en sistemas industriais DPI, pero deu varios anos adicionais.
Por certo, sobre o DPI de entón e actualPor certo, moitos dos que compraron os sistemas DPI dispoñibles naquel momento xa os tiraran. Ben, non están deseñados para iso: centos de miles de enderezos, decenas de miles de URL.
E ao mesmo tempo, os produtores nacionais subiron moi fortemente a este mercado. Non falo do compoñente hardware -todo está claro para todos aquí, pero o software -o principal que ten DPI- é quizais hoxe, se non o máis avanzado do mundo, certamente a) desenvólvese a pasos axigantados, e b) ao prezo dun produto en caixa, simplemente incomparable cos competidores estranxeiros.
Gustaríame estar orgulloso, pero un pouco triste =)
Agora todo parecía así:
Nun par de anos máis xa todos tiñan auditores; Cada vez había máis recursos no rexistro. Para algúns equipos máis antigos (por exemplo, Cisco 7600), o esquema de "filtrado lateral" simplemente quedou inaplicable: o número de rutas en 76 plataformas limítase a algo así como novecentas mil, mentres que o número de rutas IPv4 só hoxe achégase ás 800. mil. E se tamén é ipv6... E tamén... canto hai? 900000 enderezos individuais na prohibición de RKN? =)
Alguén pasou a un esquema con espello de todo o tráfico backbone a un servidor de filtrado, que debería analizar todo o fluxo e, se se atopa algo malo, enviar RST en ambas direccións (remitente e destinatario).
Non obstante, canto máis tráfico, menos aplicable é este esquema. Se hai un mínimo atraso no procesamento, o tráfico reflectido simplemente pasará sen ser detectado e o provedor recibirá un informe correcto.
Cada vez son máis os provedores que se ven obrigados a instalar sistemas DPI de distintos graos de fiabilidade nas autoestradas.
Hai un ou dous anos segundo os rumores, case todo o FSB comezou a esixir a instalación real de equipos (anteriormente, a maioría dos provedores xestionaban coa aprobación das autoridades Plan SORM - un plan de medidas operativas en caso de necesidade de atopar algo nalgún lugar)
Ademais dos cartos (non precisamente desorbitados, pero aínda millóns), SORM requiriu moitas máis manipulacións coa rede.
- SORM necesita ver os enderezos de usuarios "grises" antes da tradución nat
- SORM ten un número limitado de interfaces de rede
Polo tanto, en particular, tivemos que reconstruír en gran medida unha parte do núcleo, simplemente para recoller o tráfico de usuarios aos servidores de acceso nalgún lugar nun só lugar. Para reflectilo en SORM con varias ligazóns.
É dicir, moi simplificado, foi (esquerda) vs converteuse (dereita):
Agora A maioría dos provedores tamén requiren a implementación de SORM-3, que inclúe, entre outras cousas, o rexistro de emisións nat.
Para estes efectos, tamén tivemos que engadir equipos separados para NAT ao diagrama anterior (exactamente o que se comenta na primeira parte). Ademais, engade nunha determinada orde: xa que SORM debe "ver" o tráfico antes de traducir enderezos, o tráfico debe ir estrictamente do seguinte xeito: usuarios -> cambio, núcleo -> servidores de acceso -> SORM -> NAT -> conmutación, núcleo - > Internet. Para iso, tivemos que literalmente "xirar" os fluxos de tráfico na outra dirección para lucro, o que tamén era bastante difícil.
En resumo: nos últimos dez anos, o deseño básico dun provedor medio volveuse moitas veces máis complexo e os puntos adicionais de fallo (tanto en forma de equipos como en forma de liñas de conmutación únicas) aumentaron significativamente. En realidade, a propia esixencia de "ver todo" implica reducir este "todo" a un punto.
Creo que isto pódese extrapolar de xeito bastante transparente ás iniciativas actuais para soberanizar o Runet, protexelo, estabilizalo e melloralo :)
E Yarovaya aínda está por diante.
Fonte: www.habr.com