Вторая часть исследования NetFlow и странных деградаций доступа. Первая часть была про то, как мы вообще научились видеть массовый silent SYN-drop на публичных CGNAT и искать внутри «шумных» абонентов. После неё нашлось несколько новых кусков документации и полевых исследований, которые заставили заметно усложнить модель.
В первой части у нас получилась довольно удобная картинка.
Есть публичный NAT. За ним сидят десятки или сотни абонентов. В какой-то момент часть нормальных ресурсов перестаёт открываться. На edge NetFlow одновременно растёт доля незавершённых TCP-сессий, коротких flows и повторных SYN. RST почти нет.
Мы назвали этот профиль silent_syn_drop и начали искать, кто внутри CGNAT создаёт особенно много новых соединений, destination и портов.
На тот момент это уже было сильно полезнее, чем классическое:
«Пинг идёт, значит у нас всё нормально».
Но почти сразу появилась следующая проблема.
Одинаковая снаружи “тишина” может возникать по совершенно разным причинам.
И вот здесь началась вторая часть исследования.
Сначала важная поправка к первой части
Вчера мы много говорили про short3 — долю flows, в которых было не больше трёх пакетов.
Эта метрика действительно оказалась очень полезной. Когда клиент отправляет SYN, не получает нормального ответа и соединение умирает, NetFlow часто оставляет именно крошечную запись.
Но теперь стало понятно, что опасно превращать short3 в магическую кнопку:
short3 высокий = ТСПУ
Так не работает.
Короткий flow может появиться из-за:
- SYN без ответа;
- RST;
- обычного сканирования;
- отказа сервера;
- P2P;
- firewall;
- timeout;
- mid-flow блокировки после уже установленного TCP;
- и ещё десятка совершенно нормальных причин.
Поэтому во второй части мы начали смотреть не на одну метрику, а на форму события.
И оказалось, что открытые источники довольно хорошо раскладываются минимум на четыре разных класса механизмов.
Четыре разных механизма вместо одного «ТСПУ блокирует»
Для себя мы сейчас используем такую рабочую модель.
| Класс |
Что происходит |
Что может увидеть NetFlow |
| A. Списки ЦСУ / protocol block |
DPI сначала распознаёт протокол, потом ЦСУ формирует IP+port list |
RST или silent SYN-drop, изменение через минуты |
| B. AS/CIDR + whitelist + mid-flow |
направление попадает под ограничение, отдельные домены разрешаются |
TCP устанавливается, потом поток обрывается примерно на первых килобайтах |
| C. Session-state / «сибирская» |
решение зависит от количества соединений к одному направлению/SNI и TLS fingerprint |
первые соединения живут, следующие замирают; характерный burst по destination |
| D. Protocol capacity |
не полный block, а вероятностный drop пакетов |
деградация, retransmit, длинные/рваные flows вместо чистого бинарного отказа |
Это уже совсем другая картина.
То есть вопрос:
«Как выглядит блокировка ТСПУ в NetFlow?»
на самом деле поставлен неправильно.
Правильнее:
«Какой именно класс ограничения мы сейчас наблюдаем?»
Класс A: почему отсутствие RST оказалось вполне нормальным
В первой части мы упоминали реконструкцию документации ТСПУ tspu-docs.
После публикации мы внимательнее прошлись по разделу настройки DPI и нашли очень полезную деталь.
Для блокировки распознанных протоколов там отдельно описан параметр:
send RST off
Причём в тексте прямо сказано, что в проекте он должен быть выключен.
Логика понятная даже без знания внутренностей ТСПУ.
Если фильтр отвечает приложению TCP Reset:
SYN →
← RST
клиент немедленно понимает, что соединение не получилось, и может тут же попробовать снова.
Получается очень бодрый генератор новых сессий:
SYN → RST
SYN → RST
SYN → RST
SYN → RST
...
Если же Reset не отправлять, картина другая:
SYN →
тишина
timeout
Клиент тоже ретраит, но медленнее.
И это практически один в один похоже на то, что мы видели ещё в июне в Wireshark и потом в сентябре на NetFlow: много SYN, много незавершённых flow, RST около нуля.
То есть наш silent_syn_drop перестал выглядеть как «какая-то странность конкретной площадки» и получил вполне разумное архитектурное объяснение.
Но дальше оказалось ещё интереснее.
Ignore сегодня, block через 5–15 минут
В той же открытой реконструкции описана двухстадийная логика протокольной фильтрации.
Сначала DPI-лист работает в режиме распознавания:
behavior = ignore
То есть сессия пока проходит, но факт распознавания логируется.
Дальше:
DPI
↓
протокольные логи
↓
SPFS
↓
ЦСУ
↓
анализ и очистка ложных срабатываний
↓
IP + port
↓
block
Для тестовой зоны в документации указан полный цикл порядка 5–15 минут.
Это очень хорошо объясняет ещё одну вещь, которую раньше было неудобно интерпретировать.
Одно и то же направление может сначала прекрасно работать, а потом внезапно перестать.
Не потому, что «DPI долго думал над одним пакетом», а потому что первая стадия вообще могла ничего не блокировать.
Для нашего исследования это означает, что особенно интересен не момент, когда connect-check уже красный.
Интереснее 10–20 минут перед ним.
Именно там надо искать изменение:
uniq_dst
uniq_dst_port
SYN/sec
flows/sec
burst к конкретному destination
То есть мы немного поменяли идеологию.
Первая часть была в основном про след уже случившейся проблемы.
Вторая всё больше становится про прелюдию.
Класс B: те самые 16 КБ — и почему это не short3
Следующая находка оказалась особенно полезной, потому что она заставила нас не путать две совершенно разные вещи.
В феврале 2026 на Habr вышел большой полевой разбор ограничений на зарубежных CDN и хостинговых сетях.
Наблюдаемый эффект там описывался примерно так:
TCP connect OK
TLS OK
начало передачи данных OK
примерно 16 КБ STOP
То есть соединение не умирает на SYN.
Оно успевает установиться и передать кусок данных.
По данным автора, ограничения затрагивали целые AS, но внутри них работал белый список отдельных доменов. Из-за этого мог открываться основной сайт, но не грузиться соседний CDN, картинки, обновления или игровые ресурсы на том же хостинге.
Для пользователя выглядит особенно издевательски:
страница вроде начала открываться — и зависла.
Это уже совсем не тот класс, который мы ловили через чистый syn_no_ack.
И здесь важна терминология.
short3 — это число пакетов
У нас:
short3 = packets <= 3
«16 КБ» — это объём до mid-flow cut
Такой flow вполне может содержать:
10 пакетов
20 пакетов
30 пакетов
в зависимости от MSS, ACK, TLS и направления учёта.
Поэтому нельзя сказать:
«16K-блок = short3».
Нет.
Но он всё равно может увеличивать долю коротких по байтам и времени сессий.
После этой находки в нашей модели явно появились отдельные признаки:
bytes_per_flow
packets_per_flow
duration
midflow_10_20k
То есть short3 остаётся хорошей метрикой для half-open/silent класса, а диапазон условно 10–20 КБ становится отдельной охотой за mid-flow cut.
Это, пожалуй, одна из самых полезных поправок ко вчерашнему тексту.
Почему история с 16 КБ важна оператору
Она показывает, насколько плохо обычные проверки описывают реальную доступность.
Например:
ping host OK
tcp/443 connect OK
TLS handshake OK
HTTP headers OK
скачивание FAIL после первых KB
Любой мониторинг, который заканчивается на TCP connect, скажет:
всё прекрасно.
А реальное приложение не работает.
Это ещё одна причина, почему в connect-check у нас есть не только connect, но и реальные HTTP/HTTPS операции, скачивание канареек и разные классы сервисов.
Класс C: «сибирская блокировка»
А потом мы вернулись к статье, которую раньше читали скорее как любопытную особенность отдельных операторов.
И оказалось, что она очень хорошо ложится на нашу историю с fan-out и количеством соединений.
В конце 2025 года исследователь описал эффект, который получил название «сибирская блокировка».
В исходном наблюдении примерно 12 TLS-соединений с SNI к одному серверу за короткий промежуток приводили к тому, что новые соединения с тем же отпечатком переставали устанавливаться примерно на две минуты.
Причём TLS без SNI этим эффектом тогда не затрагивался.
Это уже принципиально другая логика.
Не:
IP плохой → drop
а скорее:
кто + куда + сколько раз + какой TLS profile
То есть фильтр хранит состояние.
К июню порог стал заметно жёстче
В июньском исследовании 2026 года описывается уже более агрессивный вариант похожего механизма.
Условие выглядело так:
- направление относится к «подозрительной» сети/AS;
- TLS fingerprint входит в интересующий набор;
- используется один SNI;
- за последние 60 секунд происходит более трёх быстрых попыток;
- задержка между ними порядка 350–400 мс или меньше.
После этого новые TLS-попытки к направлению могут «замораживаться» примерно на 120 секунд.
Особенно любопытно, что автор отдельно проверял TCP-порт: по его наблюдениям, конкретный номер порта для этого класса ограничения роли не играл.
Это важный момент.
Мы изначально много смотрели на классические порты:
22
443
500
4500
1194
51820
...
Они всё ещё полезны для понимания поведения абонента.
Но session-rate механизм может быть вообще port-agnostic.
То есть считать только dst_port недостаточно.
Нужны:
src
nat_ip
dst_ip
временное окно
число новых TCP sessions
А SNI в обычном NetFlow у нас, разумеется, нет.
Очень забавная эволюция: 12 → 4
Если положить рядом два полевых исследования, получается интересная картинка.
Конец 2025:
~12 быстрых TLS-соединений
Июнь 2026:
4-е быстрое соединение уже может стать лишним
В актуальной конфигурации проекта dpi-checkers для теста Siberian тоже используется:
siberian-conn-count: 4
Это не означает, что «федеральный порог ТСПУ теперь официально равен четырём».
Такого вывода делать нельзя.
Полевые параметры отличаются между операторами, площадками и датами.
Но нам как оператору сам принцип гораздо интереснее конкретной цифры:
несколько быстрых соединений к одному destination — это отдельный класс сигнала.
И тут наш uniq_dst оказался недостаточен
До этого мы много смотрели на fan-out:
один inside → 500 разных dst
Это хорошо ловит сканеры, P2P и заражённых клиентов.
Но Siberian-подобная логика может сработать на прямо противоположном поведении:
один inside
↓
ОДИН dst
↓
много быстрых новых sessions
То есть старый показатель:
uniq_dst высокий
может вообще не загореться.
После этого у нас появились отдельные кандидаты:
burst_3_dst
burst_4_dst
rate_per_dst
new_tcp_per_dst
Смысл очень простой.
Нас теперь интересует не только:
«Сколько разных серверов трогает клиент?»
но и:
«Сколько раз он за короткое окно стучится в один и тот же сервер?»
Три TCP нормально, четвёртый — уже нет
В более свежей полевой дискуссии конца августа встретилось ещё более жёсткое наблюдение: два соединения проходят, а на третьем/следующем handshake уже появляется тишина.
Пока мы относим это к категории кандидатов, а не установленной нормы.
Причины простые:
- это полевой единичный замер;
- неизвестен точный cooldown;
- неизвестно, одинаково ли работает на разных площадках;
- нет смысла объявлять универсальный порог по одному наблюдению.
Но для NetFlow hunt это очень хороший повод поставить пассивный датчик на burst-3 / burst-4.
Не блокировать.
Просто наблюдать.
Мы поставили такой наблюдатель прямо на MikroTik
NetFlow хорош тем, что позволяет смотреть сеть массово.
Но для очень коротких временных burst в несколько сотен миллисекунд минутный агрегат уже грубоват.
Поэтому мы добавили на edge отдельный observe-only слой.
Логика примерно такая:
если один source быстро создаёт
3–4 новых TCP к одному destination
→ записать событие
→ ничего не блокировать
MikroTik отдаёт событие в syslog, а дальше мы связываем его с NetFlow:
MikroTik burst event
+
NetFlow src/nat/dst
↓
ClickHouse
↓
кто / какой NAT / какой destination / что было потом
Так появился ещё один важный принцип проекта:
firewall здесь работает не как цензор, а как осциллограф.
Сначала измеряем.
Потом уже решаем, есть ли вообще что ограничивать.
Класс D: оказывается, фильтр умеет не только «разрешить/запретить»
Ещё одна новая находка в документации — protocols capacity.
В открытом описании это шкала от 0 до 100:
0 = полный block
100 = полный pass
1–99 = вероятностный drop
То есть фильтр может не уничтожать сессию целиком, а просто терять часть пакетов распознанного протокола.
Для TCP это даёт совершенно другую внешнюю картину.
Не обязательно:
SYN → тишина
Вместо этого может быть:
handshake OK
часть data OK
loss
retransmit
ещё loss
приложение еле ползёт
И опять пользователь говорит:
«Интернет какой-то мёртвый».
А ping продолжает ходить.
Из этого следует неприятный вывод: бинарный FAIL/OK тоже не всегда достаточно описывает проблему.
Нужны ещё время выполнения, объём переданных данных и профиль retransmission — последние уже лучше смотреть PCAP, а не одним NetFlow.
Вчера у нас был один silent-drop. Сегодня — уже четыре класса
Если сильно упростить, сейчас карта выглядит так.
┌──────────────┐
│ жалоба / CC │
└──────┬───────┘
│
┌─────────────────┼─────────────────┐
│ │ │
▼ ▼ ▼
SYN не живёт TCP живёт, первые sessions
handshake data обрывается живут, потом freeze
│ │ │
▼ ▼ ▼
silent / RST ~10–20 KB per-dst burst
class A class B class C
│
└───────────┐
▼
случайный loss
class D
Это гораздо полезнее, чем пытаться втиснуть всё в один tspu_score.
Что теперь означают наши метрики
syn_no_ack
Хороший признак того, что новая TCP-сессия не развивается.
Сильнее всего связан с классом A и некоторыми stateful freeze.
short3
Хороший массовый индикатор очень коротких flows.
Но сам по себе не говорит, почему flow короткий.
midflow_10_20k
Новая отдельная гипотеза для класса B.
Ищем соединения, которые успели передать не ноль, а небольшой устойчивый объём и затем закончились/зависли.
burst_3/4_dst
Кандидат на класс C.
Особенно если затем по этому destination у того же egress меняется success rate.
rst_pct
Не выкидываем.
RST-heavy класс у нас уже встречался, просто он оказался не главным.
flows_sec / SYN_sec / uniq_dst
Остаются хорошими показателями общей «шумности» и поиском inside-вкладчиков.
И здесь CGNAT снова делает всё интереснее
Siberian-подобный механизм особенно неприятно выглядит рядом с CGNAT.
Пусть у нас за одним публичным адресом 180 клиентов.
Каждый делает совершенно нормальные четыре HTTPS-соединения.
Для пользователя это ничего необычного.
Но снаружи мы имеем один общий egress.
В зависимости от того, по какому ключу middlebox хранит state, shared IP потенциально может усиливать частоту наблюдаемых сессий.
Мы пока не утверждаем, что конкретная реализация суммирует разных CGNAT-inside именно так.
Для этого у нас нет внутренней телеметрии фильтра.
Но именно поэтому публичный NAT остаётся главной единицей нашего эксперимента.
Мы смотрим:
public NAT
↓
симптом
↓
какие inside дали вклад
а не наоборот.
Что показал сегодняшний эксперимент с «шумными» inside
После первой части мы попробовали аккуратно проверить ещё одну практическую гипотезу.
Если внутри CGNAT есть несколько источников, которые дают очень большой fan-out, scan/amp-профиль и поток новых сессий — можно ли убрать именно этот шум, не отключая абонента полностью?
Для этого сделали soft quarantine.
Не бан.
Не drop all.
А частичные ограничения на явно аномальную новую активность, при сохранении established и обычного пользовательского трафика.
На пилотном сегменте после применения к небольшой группе самых заметных culprits получили примерно:
общий flows/sec: 530 → 383 (-28%)
SYN/sec: 101 → 62 (-39%)
У нескольких конкретных host-scan профилей fan-out упал на десятки процентов.
У одного источника число destination сократилось примерно:
224 → 79
То есть сама идея «найти шумный inside и подрезать именно шум» работает технически.
Но дальше произошло как раз самое интересное.
Публичный NAT не «очистился» мгновенно
Несмотря на заметное снижение flows и SYN, через несколько минут общий egress всё ещё выглядел как проблемный:
short3 ~82%
cc_healthy ~35–36%
То есть:
снизили шум ≠ мгновенно восстановили доступность.
Это очень хороший результат, даже несмотря на то, что он не такой эффектный.
Он означает, что простая причинная модель:
слишком много SYN
↓
block
↓
урезали SYN
↓
сразу unblock
слишком примитивна.
У состояния может быть cooldown.
Может работать загруженный IP+port list.
Может быть другой класс ограничения.
Может существовать несколько шумных inside сразу.
Может быть вообще внешний rate-limit/CDN reputation, а не ТСПУ.
Именно поэтому мы не делаем автоматический вывод «виновник найден» по одному score.
А потом мы получили очень полезный контрпример
И вот здесь новая фактура заставила нас ещё раз поправить собственную модель.
На одном из публичных SNAT наш NetFlow-детектор уверенно показывал silent_syn_drop:
short3 ~80–82%
syn_no_ack ~21%
RST ~1%
То есть по нашим прежним правилам адрес выглядел очень знакомо: много коротких flows, заметная доля незавершённых SYN, почти нет RST.
За тем же SNAT действительно нашлись шумные insides. Один из них выглядел как выраженный port-scan профиль.
Казалось бы, вот он — ещё один «проблемный NAT».
Но мы запустили свежий connect-check с реального CPE за этим egress и получили:
FAIL 2
WARNING 55
OK 464
То есть массовой пользовательской деградации не было.
Из действительно красного — один captive-check и 502 у «Ведомостей». Это вообще не похоже на тот случай, где у клиента разваливается половина Интернета.
Получился очень хороший отрицательный результат.
silent_syn_drop на публичном NAT не равен «абонент заблокирован».
Он означает другое:
на этом egress сейчас есть сетевой профиль, похожий на тот, который мы уже видели около проблемных событий.
Но это пока только риск пула.
Пользовательский impact надо подтверждать отдельно.
После этого мы окончательно развели два слоя.
Слой A — AT RISK
NetFlow говорит:
silent profile
short flows
syn_no_ack
burst/fan-out
шумные insides
Это повод открыть NAT и посмотреть, что с ним происходит.
Слой B — IMPACT
Есть независимая фактура:
connect-check массово красный
жалоба абонента
labeled event
контрольный сервис реально не работает
И только когда эти слои сходятся, можно говорить о подтверждённой деградации, а не просто о «грязном» egress.
Схематично теперь так:
NetFlow anomaly
│
▼
AT RISK
│
┌──────┴──────┐
│ │
CC healthy CC broken
│ │
▼ ▼
наблюдаем IMPACT
дальше расследуем
Это, пожалуй, самая полезная калибровка за сегодняшний день.
Потому что хороший детектор должен уметь не только находить подозрительное, но и не объявлять аварией то, что аварией не является.
И на масштабе всего CGNAT-флота всё оказалось ещё менее линейно
На локальном пилоте soft-quarantine действительно красиво уменьшал SYN и fan-out отдельных culprits.
Но когда ту же идею начали смотреть сразу на большом наборе CGNAT, картинка стала менее фотогеничной и зато более полезной.
В одном из контрольных срезов примерно через час после применения soft-q:
silent NATs: 68 → 83
avg triage: 17.6 → 18.7
sum flows/sec
по silent NAT: 4377 → 3277
То есть суммарный поток в проблемном классе снизился примерно на четверть, а количество NAT с silent-профилем при этом не уменьшилось.
Более того, в коротком окне после применения был красивый провал нагрузки, а потом часть трафика отскочила обратно.
Это ещё раз показывает: нельзя использовать soft-quarantine как лабораторную кнопку
ограничили culprit → значит ТСПУ обязан сразу отпустить IP
Нет.
Мы меняем только то, что контролируем сами — форму исходящего трафика.
А дальше на результат могут влиять:
- TTL внешнего state;
- уже сформированный IP+port list;
- другой шумный inside;
- session-rate state;
- CDN/WAF reputation;
- вообще другой механизм деградации;
- или просто наши собственные слишком широкие критерии
silent.
Именно последний пункт новый connect-check как раз очень хорошо подсветил.
Поэтому KPI soft-quarantine теперь тоже другой.
Не:
«сколько NAT перестали называться silent».
А в первую очередь:
сколько шума убрали
какие culprits перестали fan-out'ить
упал ли SYN/new-conn rate
изменилась ли реальная доступность у клиентов
Это намного скучнее красивого зелёного индикатора «ТСПУ снят».
Зато это уже нормальная инженерия.
Зато теперь у нас появился нормальный эксперимент
Следующий шаг уже можно поставить вполне научно.
Берём публичный NAT с подтверждённым connect-check fail.
Фиксируем:
T0
Дальше:
1. baseline до события
2. per-dst burst
3. fan-out и SYN вклад каждого inside
4. soft remediation culprits
5. CC каждые N минут
6. NetFlow AFTER
7. время восстановления
И повторяем это на нескольких NAT.
После десятка таких экспериментов можно будет уже сравнивать:
класс A: восстановление через X
класс B: восстановление через Y
класс C: cooldown около Z
Сейчас таких данных ещё мало.
Но теперь хотя бы понятно, что именно измерять.
Что мы перестали делать после сегодняшних находок
Мы больше не пытаемся сделать одну формулу вида:
TSPU_SCORE = 0.87
и объявить её истиной.
Вместо этого хотим выдавать оператору классификацию:
A: half-open / silent
B: mid-flow ~16K
C: per-dst session freeze
D: degradation/loss
+ threat context
Причём один NAT может одновременно попасть в несколько классов.
Например, noisy inside может провоцировать session-rate историю, а параллельно часть destination уже находится в списках L3/L4.
Для пользователя это всё сольётся в одну жалобу:
«Не открывается половина Интернета».
Для NOC это должны быть разные сценарии расследования.
Самая важная находка второй части
Наверное, она даже не техническая.
Мы всё время искали «механизм блокировки» в единственном числе.
А его, похоже, просто нет.
Есть набор разных механизмов, которые могут работать одновременно:
DPI protocol recognition
центральные IP+port lists
L3/L4 block на Eco Highway
AS/CIDR ограничения
domain whitelist
mid-flow cut
session-rate state
TLS fingerprint
probabilistic protocol degradation
И у каждого немного другой сетевой почерк.
Поэтому лучший детектор — не тот, который громче всех пишет:
ТСПУ!!!
а тот, который спокойно говорит:
на этом egress:
- TCP handshake массово не завершается;
- RST нет;
- short3 84%;
- burst к одному dst вырос;
- CC expected_block=0 падает;
- основной вклад дают 3 inside;
- началось 7 минут назад.
Это уже информация, с которой инженер может работать.
Куда идём дальше
Следующая итерация у нас теперь довольно очевидная.
Нужно одновременно накапливать четыре типа labeled events и не смешивать их:
- half-open / silent;
- RST-heavy;
- mid-flow 10–20 KB;
- per-destination burst/freeze.
А рядом держать контрольные NAT, где похожий трафик есть, а проблемы нет.
И только после этого имеет смысл строить пороги.
Пока все цифры вроде 4 соединения, 16 КБ, 5–15 минут — это не универсальные константы ТСПУ.
Это наблюдаемые параметры конкретных механизмов в конкретных исследованиях.
Именно так мы их и будем использовать.
Не как инструкцию.
Как подсказку, куда направить измерительный прибор.
Вместо заключения
Вчера картина была довольно простой:
много SYN
+
нет ACK
+
короткие flows
=
похоже на silent drop
Сегодня она стала сложнее.
И это хорошо.
Теперь мы знаем, что похожая пользовательская жалоба может означать совершенно разные вещи:
соединение не установилось вообще
соединение оборвалось после ~16 КБ
первые три соединения прошли, следующие замёрзли
протокол просто теряет часть пакетов
Пинг во всех четырёх случаях может быть зелёным.
Поэтому наша исходная идея не изменилась.
Просто измерительный контур стал умнее.
Мы не пытаемся смотреть внутрь чёрного ящика.
Мы смотрим на его тень.
Но теперь уже знаем, что у этой тени несколько разных форм.
Источники и материалы
Первая часть исследования — «Пинг есть. TCP — не очень: как мы учимся видеть след ТСПУ по NetFlow»: https://articles.clr58.ru/netflow-tspu
Предыстория — «Две недели “интернета нет” при зелёных пингах»:
https://articles.clr58.ru/dve-nedeli-net-interneta
Наш connect-check:
https://github.com/cooler58/connect-check
Открытая реконструкция архитектуры ТСПУ:
https://github.com/DanielLavrushin/tspu-docs
send RST off и protocols capacity:
https://github.com/DanielLavrushin/tspu-docs/blob/main/chapters/17.md
Двухстадийная схема ignore → ЦСУ → IP+port, цикл ~5–15 минут:
https://github.com/DanielLavrushin/tspu-docs/blob/main/chapters/08.md
Habr — «РКН и “сибирская блокировка”»:
https://habr.com/ru/articles/1010336/
Habr — «О схеме ограничений РКН в июне 2026-го»:
https://habr.com/ru/articles/1044396/
Habr — белые списки AS и эффект ~16 КБ:
https://habr.com/ru/articles/997088/
dpi-checkers:
https://github.com/hyperion-cs/dpi-checkers
Дисклеймер. Это эксплуатационное исследование сетевых симптомов на стороне оператора связи. Мы не имеем доступа к внутренним решениям ЦСУ/ТСПУ и не утверждаем, что конкретный flow, IP или абонент был обработан конкретным правилом. Полевые статьи и открытая реконструкция документации используются для формирования проверяемых гипотез. Материал не является инструкцией по обходу ограничений.
#network #monitoring #netflow
