Una respuesta detallada al comentario, así como un poco sobre la vida de los proveedores en la Federación Rusa

Muéveme a esta publicación, aquí hay un comentario .

Lo traigo aquí:

kaleman hoy a las 18:53

Hoy estuve satisfecho con el proveedor. Junto con la actualización del sistema de bloqueo del sitio, recibió un correo de mail.ru bajo la prohibición. Por la mañana solicito asistencia técnica, no pueden hacer nada. El proveedor es pequeño, y aparentemente los proveedores ascendentes lo están bloqueando. También noté una desaceleración en la apertura de todos los sitios, ¿quizás algún tipo de curva DLP colgada? Anteriormente, no había problemas con el acceso. La destrucción de Runet va justo delante de mis ojos ...

El hecho es que, al parecer, somos el mismo proveedor :(

De hecho, kaleman casi adivinó la causa de los problemas con mail.ru (aunque durante mucho tiempo nos negamos a creer en tal cosa).

Además se dividirá en dos partes:

1. las causas de nuestros problemas hoy con mail.ru y una búsqueda emocionante para encontrarlos
2. la existencia de ISP en las realidades de hoy, la estabilidad del runet soberano.

Problemas con la disponibilidad de mail.ru

Oh, esa es una historia bastante larga.

El hecho es que para implementar los requisitos del estado (con más detalle en la segunda parte), compramos, configuramos e instalamos algunos equipos, tanto para filtrar recursos prohibidos como para realizar transmisiones NAT de suscriptores.

Hace algún tiempo, finalmente reconstruimos el núcleo de la red para que todo el tráfico de suscriptores pasara a través de este equipo en la dirección correcta.

Hace unos días activamos el filtrado de contenido prohibido (dejando al mismo tiempo el antiguo sistema funcionando), todo parecía funcionar bien.

Además, gradualmente comenzó a incluir NAT para diferentes partes de suscriptores en este equipo. En apariencia, también todo parece haber ido bien.

Pero hoy, después de encender el equipo NAT para la siguiente parte de los suscriptores, por la mañana nos encontramos con un número decente de quejas sobre la falta de disponibilidad o la disponibilidad parcial de mail.ru y otros recursos del Grupo Mail Ru.

Comenzaron a verificar: algo en alguna parte a veces , ocasionalmente envía TCP RST en respuesta a solicitudes exclusivamente a redes mail.ru. Además, envía un TCP RST artificial generado incorrectamente (sin ACK), obviamente. Algo así se veía:







Naturalmente, los primeros pensamientos fueron sobre nuevos equipos: un DPI terrible, no hay confianza en él, nunca se sabe lo que puede hacer: TCP RST es algo bastante común entre las herramientas de bloqueo.

La suposición de kaleman de que alguien está filtrando "superior", también lo planteamos, pero luego lo descartamos.

En primer lugar, tenemos suficientes enlaces ascendentes sanos para no sufrir así :)

En segundo lugar, estamos conectados a varios IXs en Moscú, y el tráfico a mail.ru los atraviesa precisamente, y no tienen ningún deber ni ningún otro motivo para filtrar el tráfico.

La siguiente mitad del día se gastó en lo que generalmente se llama chamanismo, junto con el vendedor de equipos, por lo que agradecen, no se dieron por vencidos :)

• el filtrado fue completamente deshabilitado
• NAT se desconectó de acuerdo con el nuevo esquema
• la PC de prueba se movió a un grupo aislado separado
• Direccionamiento IP cambiado

Por la tarde, se asignó una máquina virtual que fue a la red de acuerdo con el esquema de un usuario común, y los representantes del proveedor tuvieron acceso a ella y a su equipo. El chamanismo continuó :)

Al final, el representante del vendedor declaró con confianza que la pieza de hardware no tenía absolutamente nada que ver con eso: los primeros provenían de algún lugar más alto.


Después de eso, en la noche, no había nada más que hacer sino volver a la suposición de un extraño filtrado en algún lugar arriba.

Miré a través del tráfico IX que ahora se dirige a las redes de los IWG y simplemente le pagué sesiones bgp. Y, ¡he aquí! - todo volvió inmediatamente a la normalidad :(

Por un lado, es lamentable que haya pasado todo el día buscando el problema, aunque se resolvió en cinco minutos.

Por otro lado:

- En mi memoria esto es algo sin precedentes. Como escribí anteriormente, IX realmente no tiene sentido filtrar el tráfico de tránsito. Por lo general, tienen cientos de gigabits / terabits por segundo. Solo hasta el último no podía imaginarlo seriamente.

- Un conjunto de circunstancias increíblemente exitoso: un nuevo hardware complejo, que no tiene mucha confianza y del que no está claro qué esperar - agudizado justo bajo el bloqueo de recursos, incluidos los TCP RST

Actualmente, el NOC de este intercambio de Internet está buscando un problema. Según ellos (y les creo) no tienen un sistema de filtración especialmente desarrollado. Pero, gracias al cielo, la búsqueda adicional ya no es nuestro problema :)

Fue un pequeño intento de justificarnos, por favor, comprenda y perdone :)

PD: intencionalmente no nombro al fabricante de DPI / NAT, ni IX (de hecho, ni siquiera tengo quejas especiales contra ellos, lo principal es entender qué era)

La realidad actual (así como ayer y anteayer) desde el punto de vista del proveedor de Internet

Pasé las últimas semanas, reconstruyendo significativamente el núcleo de la red, realizando un montón de manipulaciones "ganancias", con el riesgo de afectar significativamente el tráfico de usuarios en vivo. Dados los objetivos, resultados y consecuencias de todo esto, moralmente, todo esto es bastante difícil. Especialmente, una vez más escuchando los magníficos discursos sobre la protección de la estabilidad de Runet, la soberanía, etc. etc.

En esta sección trataré de contar la "evolución" de la red central de un proveedor de servicios de Internet típico en los últimos diez años.

Hace diez años

En esos tiempos bendecidos, el núcleo de la red de proveedores podría ser tan simple y confiable como un embotellamiento:



En esta imagen muy, muy simplificada, no hay carreteras, anillos, enrutamiento ip / mpls.

Su esencia es que el tráfico de usuarios finalmente llegó a la conmutación a nivel de kernel, desde donde fue a BNG , desde donde, por regla general, a la conmutación de kernel y luego "para salir", a través de una o más puertas de enlace fronterizas a Internet.

Tal esquema se reserva muy, muy fácilmente tanto en L3 (enrutamiento dinámico) como en L2 (MPLS).

Puede poner N + 1 cualquier cosa: acceder a servidores, conmutadores, huéspedes, y de alguna manera reservarlos para la conmutación por error automática.

Después de unos años, se hizo evidente para todos en Rusia que era imposible vivir así: era urgentemente necesario proteger a los niños de la influencia nociva de la red.

Había una necesidad urgente de encontrar formas de filtrar el tráfico de usuarios.

Hay diferentes enfoques.

En un caso no tan bueno, algo se pone "en el corte": entre el tráfico de usuarios e Internet. Se analiza el tráfico que pasa por este "algo" y, por ejemplo, se envía un paquete de redireccionamiento falso al lado del suscriptor.

En un caso un poco mejor, si el volumen de tráfico lo permite, puede hacer una pequeña finta con sus oídos: envíe solo tráfico saliente de los usuarios a las direcciones que necesitan ser filtradas (para esto puede tomar las direcciones IP especificadas allí desde el registro, o adicionalmente resolver las existentes) dominios en el registro).

En un momento, para estos propósitos, escribí un mini-dpi simple, aunque incluso el idioma no se atreve a llamarlo así. Es muy simple y no muy productivo; sin embargo, nos permitió a nosotros, y a docenas (si no cientos) de otros proveedores, no gastar de inmediato millones en sistemas DPI industriales, sino que dimos varios años adicionales de tiempo.


Ahora se veía así:



Después de un par de años , todos ya tenían auditores; los recursos en el registro se hicieron cada vez más. Para algunos equipos antiguos (por ejemplo, cisco 7600), el esquema de "filtrado lateral" simplemente se volvió inaplicable: el número de rutas en 76 plataformas se limitó a algo así como alrededor de novecientos mil, mientras que el número de rutas IPv4 hoy ya se está acercando a 800 mil. Y si también ipv6 ... Y también ... ¿cuánto hay? 900,000 direcciones individuales en el baño RCN? =)

Alguien cambió a un esquema que refleja todo el tráfico principal al servidor de filtrado, que debería analizar todo el flujo y enviar algo RST a ambos lados (remitente y destinatario) cuando encuentra algo malo.

Sin embargo, cuanto más tráfico, menos aplicable será este esquema. A la menor demora en el procesamiento, el tráfico reflejado simplemente pasará desapercibido y el proveedor recibirá un excelente informe.

Cada vez más proveedores se ven obligados a colocar sistemas DPI de diversos grados de confiabilidad en el contexto de las carreteras.

Hace un año o dos, según los rumores, casi todos los FSB comenzaron a exigir la instalación real de equipos SORM (anteriormente, la mayoría de los proveedores lograron coordinar el plan SORM con las autoridades, un plan de medidas operativas en caso de necesidad de encontrar algo en algún lugar)

Además del dinero (no tan alto como el cielo, pero aún así millones), SORM requirió muchas más manipulaciones de red para muchos.

• SORM necesita ver las direcciones "grises" de los usuarios, antes de la transmisión nat
• SORM tiene un número limitado de interfaces de red

Por lo tanto, en particular, tuvimos que reconstruir fríamente una parte del núcleo, solo para recopilar el tráfico de usuarios para acceder a los servidores en algún lugar en un solo lugar. Para reflejarlo con varios enlaces en SORM.

Es decir, muy simplificado, fue (a la izquierda) vs se convirtió (a la derecha):



Ahora , la mayoría de los proveedores también requieren la introducción de SORM-3, que incluye, entre otros, el registro de transmisiones NAT.

Para estos fines, tuvimos que agregar equipos separados para NAT en el circuito anterior (solo el que se discute en la primera parte). Y para agregar en un cierto orden: dado que SORM debe "ver" el tráfico antes de la traducción de la dirección, el tráfico debe ir exactamente de la siguiente manera: usuarios -> conmutación, kernel -> servidores de acceso -> SORM -> NAT -> conmutación, núcleo -> Internet. Para hacer esto, tuvimos que literalmente "desplegar" flujos de tráfico en la otra dirección, lo que también fue bastante difícil.

Total: a lo largo de una docena de años, el circuito central del proveedor principal se ha vuelto más complejo a veces, y los puntos adicionales de falla (tanto en forma de equipo como en forma de líneas de conmutación individuales) han aumentado significativamente. En realidad, el requisito de "ver todo" en sí mismo implica la reducción de este "todo" a un punto.

Me parece que esto se puede extrapolar de manera bastante transparente a las iniciativas actuales sobre la soberanización de Runet, su protección, estabilización y mejora :)

Y adelante está Yarovaya.