Evgeny (m3chman) wrote,
Evgeny
m3chman

Попытаюсь рассказать «эволюцию» ядра сети типичного интернет-провайдера за последний десяток лет.

Десяток лет назад.

В те благословенные времена ядро провайдерской сети могло быть простым и надёжным, как пробка.

Суть в том, что трафик пользователей в конечном итоге приходил в коммутацию уровня ядра — откуда шёл в BNG, откуда, как правило — обратно в коммутацию ядра, и далее «на выход» — через один или несколько border gateway's в интернет.

Подобная схема очень-очень легко резервируется как на L3 (динамической маршрутизацией), так и на L2 (MPLS).

Можно поставить N+1 чего угодно: серверов доступа, коммутаторов, бордеров — и так или иначе их зарезервировать для автоматического фэйловера.

Через несколько лет всем в России стало понятно, что так дальше жить нельзя: необходимо срочно защитить детей от тлетворного влияния сети.

Возникла необходимость срочно изыскивать способы фильтровать пользовательский трафик.

Тут есть разные подходы.

В не очень хорошем случае — что-то ставится «в разрез»: между пользовательским трафиком и интернетом. Проходящий через это «что-то» трафик подвергается анализу и, например, в сторону абонента отправляется поддельный пакет с редиректом.

В немного лучшем случае — если обьёмы трафика позволяют — можно сделать небольшой финт ушами: отправлять на фильтрацию только исходящий от пользователей трафик только на те адреса, которые необходимо фильтровать (для этого можно либо брать из реестра указанные там IP-адреса, либо дополнительно резолвить имеющиеся в реестре домены).

В своё время для этих целей я написал простенький мини-dpi — хотя даже язык не поворачивается его так называть. Он очень простой и не очень производительный — однако и нам, и десяткам (если не сотням) других провайдеров он позволил не выкладывать сразу миллионы на промышленные DPI-системы, а дал несколько дополнительных лет времени.


Ещё через пару лет у всех уже стояли ревизоры; ресурсов в реестре становилось всё больше и больше. Для некоторого старого оборудования (например, cisco 7600) становилась просто неприменимой схема с «фильтрацией сбоку»: число маршрутов на 76 платформах ограничено чем-то около девятиста тысяч, в то время, как число только IPv4-маршрутов сегодня уже подбирается к 800 тысячам. А если ещё и ipv6… А ещё и… сколько там? 900000 отдельных адресов в бане ркн? =)

Кто-то переходил на схему с зеркалированием всего магистрального трафика на фильтрующий сервер, который должен анализировать весь поток и при нахождении чего-то нехорошего слать в обе стороны (отправителю и получателю) RST.

Однако чем больше трафика, тем менее применима подобная схема. При малейшей задержке в обработке — зеркалированный трафик просто незаметно пролетит вникуда, а провайдеру прилетит протокол о штрафе.

Всё больше и больше провайдеров вынуждено ставить DPI-системы разной степени надёжности в разрез магистралей.

Год-два назад по слухам, практически у всех ФСБ стало требовать реальную установку оборудования СОРМ (ранее большая часть провайдеров обходилась согласованием с органами плана СОРМ — планом оперативных мероприятий на случай необходимости что-то где-то найти)

Помимо денег (не так, чтобы прямо уж совсем заоблачных, но всё же — миллионов), СОРМ у многих потребовал очередных манипуляций с сетью.

СОРМу необходимо видеть «серые» адреса пользователей, до nat-транслирования
У СОРМа ограниченное число сетевых интерфейсов

Поэтому нам, в частности, пришлось здорово перестроить кусок ядра — просто для того, чтобы собрать где-то в одном месте трафик пользователей к серверам доступа. Для того, чтобы несколькими линками отзеркалировать его в СОРМ.

Сейчас у большинства провайдеров требуют внедрения также и СОРМ-3 — который включает в себя, в том числе, и логирование нат-трансляций.

В этих целях в схему выше нам пришлось добавить ещё и отдельное оборудование для NAT`а (как раз то, о котором идёт речь в первой части). Причём добавить в определённом порядке: поскольку СОРМ должен «видеть» трафик до транслирования адресов — трафик должен идти строго следующим образом: пользователи -> коммутация, ядро -> серверы доступа -> СОРМ -> НАТ -> коммутация, ядро -> интернет. Для этого нам пришлось, буквально, «разворачивать» потоки трафика в другую сторону наживую, что тоже было довольно непросто.

Итого: за десяток лет схема ядра среднего провайдера усложнилась в разы, а дополнительных точек отказа (как в виде оборудования, так и в виде единых коммутационных линий) — значительно прибавилось. Собственно, само по себе требование «видеть всё» подразумевает сведение этого «всего» в одну точку.

Думается мне, это вполне прозрачно можно экстраполировать на текущие инициативы по суверенизации рунета, его защите, стабилизации и улучшению :)

А впереди ещё Яровая.

src: //habr.com/ru/post/444274/
Tags: internet, runet, russia
Subscribe

  • (no subject)

    ".. Благодаря успешности операции "Пандемия" в США был проведен государственный переворот фашистского толка. Изменение выборного законодательства под…

  • (no subject)

    ".. А люди уже приучены именно к новостной повестке и подаче, поэтому процессы, выходящие по своим временным параметрам и по своей "амплитуде" за…

  • (no subject)

    Почему Россия, мало по малу, превратилась в главного врага постлиберального Запада? Потому, что контрэлите был удобен именно такой враг, чтобы на…

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 0 comments