Me impulsó a esta publicación .
Lo cito aquí:
hoy en 18: 53
Estoy satisfecho con el proveedor hoy. Junto con la actualización del sistema de bloqueo de sitios, su mailer mail.ru fue prohibido. He estado llamando al soporte técnico desde la mañana, pero no pueden hacer nada. El proveedor es pequeño y aparentemente los proveedores de mayor rango lo bloquean. También noté una desaceleración en la apertura de todos los sitios, ¿tal vez instalaron algún tipo de DLP corrupto? Anteriormente no había problemas de acceso. La destrucción de RuNet está ocurriendo ante mis ojos...
El caso es que parece que somos ese mismo proveedor :)
Y de hecho Casi adiviné la causa de los problemas con mail.ru (aunque durante mucho tiempo nos negamos a creer en tal cosa).
Lo que sigue se dividirá en dos partes:
- las razones de nuestros problemas actuales con mail.ru y la apasionante búsqueda para encontrarlos
- la existencia de ISP en las realidades actuales, la estabilidad de la RuNet soberana.
Problemas de accesibilidad con mail.ru
Oh, es una historia bastante larga.
El hecho es que para implementar los requisitos del estado (más detalles en la segunda parte), compramos, configuramos e instalamos algunos equipos, tanto para filtrar recursos prohibidos como para implementar suscriptores.
Hace algún tiempo, finalmente reconstruimos el núcleo de la red de tal manera que todo el tráfico de suscriptores pasara a través de este equipo estrictamente en la dirección correcta.
Hace unos días activamos el filtrado prohibido (mientras dejamos el sistema anterior en funcionamiento); todo pareció ir bien.
Luego, gradualmente comenzaron a habilitar NAT en este equipo para diferentes partes de suscriptores. Por lo que parece, todo también pareció ir bien.
Pero hoy, después de habilitar NAT en el equipo para la siguiente parte de suscriptores, desde la mañana nos encontramos con un número decente de quejas sobre indisponibilidad o disponibilidad parcial. y otros recursos de Mail Ru Group.
Comenzaron a comprobar: algo en alguna parte. a veces, ocasionalmente envía en respuesta a solicitudes exclusivamente a las redes mail.ru. Además, envía un TCP RST generado incorrectamente (sin ACK), obviamente artificial. Esto es lo que parecía:
Naturalmente, lo primero que pensé fue en el nuevo equipo: terrible DPI, no hay confianza en él, nunca se sabe lo que puede hacer; después de todo, TCP RST es algo bastante común entre las herramientas de bloqueo.
Suposición También planteamos la idea de que alguien “superior” está filtrando, pero la descartamos inmediatamente.
En primer lugar, tenemos enlaces ascendentes lo suficientemente cuerdos como para no tener que sufrir así :)
En segundo lugar, estamos conectados con varios en Moscú, y el tráfico a mail.ru pasa por ellos, y no tienen responsabilidad ni ningún otro motivo para filtrar el tráfico.
La siguiente mitad del día la dedicamos a lo que normalmente se llama chamanismo; junto con el vendedor del equipo, por lo que les agradecemos, no se dieron por vencidos :)
- el filtrado estaba completamente deshabilitado
- NAT se deshabilitó usando el nuevo esquema
- la PC de prueba se colocó en un grupo aislado separado
- Dirección IP cambiada
Por la tarde se asignó una máquina virtual que se conecta a la red según el esquema de un usuario habitual y se dio acceso a ella y al equipo a representantes del proveedor. El chamanismo continuó :)
Al final, el representante del proveedor afirmó con confianza que el hardware no tenía absolutamente nada que ver con esto: los primeros vienen de algún lugar superior.
NotaEn este punto, alguien podría decir: ¿pero fue mucho más fácil realizar un volcado no desde la PC de prueba, sino desde la autopista por encima del DPI?
No, desafortunadamente, realizar un volcado (e incluso simplemente duplicar) más de 40 gbps no es nada trivial.
Después de esto, por la noche, ya no quedaba más remedio que volver a la suposición de una extraña filtración en algún lugar arriba.
Miré a través de qué IX pasa ahora el tráfico a las redes MRG y simplemente cancelé las sesiones bgp. Y ¡he aquí! - todo volvió inmediatamente a la normalidad 🙁
Por un lado, es una pena que hayamos pasado todo el día buscando el problema, aunque se solucionó en cinco minutos.
Por otro lado:
- En mi memoria esto es algo sin precedentes. Como ya escribí arriba - IX realmente No tiene sentido filtrar el tráfico de tránsito. Suelen tener cientos de gigabits/terabits por segundo. En serio, no podía imaginar algo como esto hasta hace poco.
— una coincidencia de circunstancias increíblemente afortunada: un nuevo hardware complejo en el que no se confía especialmente y del que no está claro qué se puede esperar — diseñado específicamente para bloquear recursos, incluidos TCP RST
El NOC de este intercambio de Internet está actualmente buscando un problema. Según ellos (y yo les creo), no tienen ningún sistema de filtración especialmente implementado. Pero, gracias a Dios, seguir buscando ya no es problema nuestro :)
Este fue un pequeño intento de justificarme, por favor comprendan y perdonen :)
PD: deliberadamente no nombro al fabricante de DPI/NAT o IX (de hecho, ni siquiera tengo ninguna queja especial sobre ellos, lo principal es entender qué era)
La realidad de hoy (así como la de ayer y anteayer) desde el punto de vista de un proveedor de Internet
He pasado las últimas semanas reconstruyendo significativamente el núcleo de la red, realizando un montón de manipulaciones "con fines de lucro", con el riesgo de afectar significativamente el tráfico de usuarios en vivo. Considerando los objetivos, resultados y consecuencias de todo esto, moralmente es bastante difícil. Especialmente, una vez más escuchando hermosos discursos sobre la protección de la estabilidad de Runet, la soberanía, etc. etcétera.
En esta sección intentaré describir la “evolución” del núcleo de red de un ISP típico durante los últimos diez años.
Hace diez años.
En aquellos tiempos benditos, el núcleo de una red de proveedores podía ser tan simple y confiable como un atasco de tráfico:
En esta imagen muy, muy simplificada, no hay troncales, anillos ni enrutamiento ip/mpls.
Su esencia es que el tráfico de usuarios finalmente llegó al nivel del kernel cambiando, desde donde fue a , desde donde, por regla general, se regresa al núcleo y luego se "sale", a través de una o más puertas de enlace fronterizas a Internet.
Un esquema de este tipo es muy, muy fácil de reservar tanto en L3 (enrutamiento dinámico) como en L2 (MPLS).
Puede instalar N+1 de cualquier cosa: acceder a servidores, conmutadores, fronteras y, de una forma u otra, reservarlos para conmutación por error automática.
Después de unos años Para todos en Rusia quedó claro que ya era imposible vivir así: era urgente proteger a los niños de la influencia perniciosa de Internet.
Existía una necesidad urgente de encontrar formas de filtrar el tráfico de usuarios.
Hay diferentes enfoques aquí.
En un caso no muy bueno, algo se pone “en la brecha”: entre el tráfico de usuarios e Internet. Se analiza el tráfico que pasa a través de este "algo" y, por ejemplo, se envía al suscriptor un paquete falso con una redirección.
En un caso ligeramente mejor, si el volumen de tráfico lo permite, puede hacer un pequeño truco con sus oídos: enviar para filtrar solo el tráfico que proviene de los usuarios a aquellas direcciones que necesitan ser filtradas (para hacer esto, puede tomar las direcciones IP especificado allí desde el registro, o además resolver los existentes dominios en el registro).
En un momento, para estos fines, escribí un sencillo - aunque ni siquiera me atrevo a llamarlo así. Es muy simple y poco productivo; sin embargo, nos permitió a nosotros y a docenas (si no cientos) de otros proveedores no desembolsar millones de inmediato en sistemas DPI industriales, pero nos dio varios años adicionales de tiempo.
Por cierto, sobre el DPI de entonces y el actual.Por cierto, muchos de los que compraron los sistemas DPI disponibles en el mercado en aquel momento ya los habían desechado. Bueno, no están diseñados para esto: cientos de miles de direcciones, decenas de miles de URL.
Y al mismo tiempo, los productores nacionales han entrado con mucha fuerza en este mercado. No me refiero al componente de hardware: aquí todo está claro para todos, pero el software, lo principal que tiene DPI, es quizás hoy en día, si no el más avanzado del mundo, ciertamente a) se está desarrollando a pasos agigantados, yb) al precio de un producto en caja, simplemente incomparable con el de los competidores extranjeros.
Me gustaría estar orgulloso, pero un poco triste =)
Ahora todo se veía así:
En un par de años más todos ya tenían auditores; Cada vez había más recursos en el registro. Para algunos equipos más antiguos (por ejemplo, Cisco 7600), el esquema de "filtrado lateral" simplemente se volvió inaplicable: el número de rutas en 76 plataformas está limitado a algo así como novecientas mil, mientras que el número de rutas IPv4 hoy en día se acerca a 800. mil. Y si también es ipv6… Y además… ¿cuánto hay? ¿900000 direcciones individuales en la prohibición de RKN? =)
Alguien cambió a un esquema que refleja todo el tráfico de la red troncal a un servidor de filtrado, que debería analizar todo el flujo y, si se encuentra algo malo, enviar RST en ambas direcciones (remitente y destinatario).
Sin embargo, cuanto más tráfico, menos aplicable es este esquema. Si hay el más mínimo retraso en el procesamiento, el tráfico reflejado simplemente pasará desapercibido y el proveedor recibirá un informe de multa.
Cada vez más proveedores se ven obligados a instalar sistemas DPI de distintos grados de confiabilidad en las carreteras.
Hace un año o dos Según los rumores, casi todo el FSB comenzó a exigir la instalación real de equipos. (anteriormente, la mayoría de los proveedores gestionaban con la aprobación de las autoridades plan SORM - un plan de medidas operativas en caso de que sea necesario encontrar algo en alguna parte)
Además del dinero (no exactamente exorbitante, pero sí millones), SORM requirió muchas más manipulaciones con la red.
- SORM necesita ver direcciones de usuario "grises" antes de la traducción nat
- SORM tiene un número limitado de interfaces de red
Por lo tanto, en particular, tuvimos que reconstruir en gran medida una parte del kernel, simplemente para recopilar el tráfico de los usuarios a los servidores de acceso en algún lugar de un solo lugar. Para reflejarlo en SORM con varios enlaces.
Es decir, muy simplificado, fue (izquierda) versus se convirtió (derecha):
Ahora La mayoría de los proveedores también requieren la implementación de SORM-3, que incluye, entre otras cosas, el registro de transmisiones nat.
Para estos fines, también tuvimos que agregar equipos separados para NAT al diagrama anterior (exactamente lo que se comenta en la primera parte). Además, agregue en un orden determinado: dado que SORM debe "ver" el tráfico antes de traducir direcciones, el tráfico debe ir estrictamente de la siguiente manera: usuarios -> conmutación, kernel -> servidores de acceso -> SORM -> NAT -> conmutación, kernel - >Internet. Para hacer esto, tuvimos que literalmente "girar" los flujos de tráfico en la otra dirección para obtener ganancias, lo cual también fue bastante difícil.
En resumen: en los últimos diez años, el diseño central de un proveedor promedio se ha vuelto mucho más complejo y los puntos de falla adicionales (tanto en forma de equipos como en forma de líneas de conmutación únicas) han aumentado significativamente. En realidad, la exigencia misma de “verlo todo” implica reducir ese “todo” a un punto.
Creo que esto se puede extrapolar de manera bastante transparente a las iniciativas actuales para soberanizar Runet, protegerlo, estabilizarlo y mejorarlo :)
Y Yarovaya todavía está por delante.
Fuente: habr.com