ртк мск , где-то после 5-6 когда начались проблемы с работой обходов, и начали активно вертеть по нескольку раз в день коробку тспу или еще какую приблцдц у прова , решил я для подбора стратегий для GBDPI запустить в очередной раз чекер - проработал он минут 5 и… отрубились все соединения в сети . Я перезагрузил комп , роутер , попробовал заходить на сайты - нифига.. Где-то через минут 15 все заработало. Я радостно решил продолжить подбор стратегий через чекер и … через 5-минут все повторилось. ( Не буду утомлять , если кратко ,на следующий день я использовал по очереди два других роутера , вначале первый проработал на подборе почти 50 минут , затем соединения легли и повторялся сценарий как и с первым роутером , при подборе стратегий чекером , сеть стала отрубаться через 5 минут. При запуске третьего роутера он в первый раз проработал при подборе где-то 1 час 25 мин и далее с ним стало происходить то же , что и с предыдущими двумя. У соседа с квартиры рядом тот же провайдер , с ним попробовали у него на его роутере подбирать стратегии чекером , после 2-х часов - сценарий стал как и у меня , 5 минут где-то работает перебирая стратегии чекером , потом отвал сети на 15-минут , восстановление работы сети , но при попытка снова запустить чекер , через 5 мин. отвал - “охлаждение на 15 мин” - работоспособность сети возвращается , но если снова активно “чекать” то все повторяется по-кругу. Есть подозрение что блок идет по Ip адресу абонентского оборудования на 15 минут. Вот для чего похоже РКН нужен доступ к идентификаторам клиентского оборудования (((
Интересно, какое количество одновременных сессий генерирует блокчек? Другими словами, насколько увеличивается количество записей в таблице NAT-трансляций у провайдера? Дело в том, что на одном подключении к РТ несколько лет назад у меня была проблема, что если количества клиентских TCP-подключений оказывалось больше 150-200, новые просто рубились. Выглядело это именно как пишут выше (“отрубились все соединения в сети”). Хотя UDP при этом продолжал работать.
Если не задана переменная PARALLEL, то одну.
Конечно, есть таймауты в любом NAT. Они зависят от фазы tcp. SYN, ESTABLISHED, TIME_WAIT, …
Если ТСПУ рубит соединение, то мне видится тут 2 варианта.
Если ТСПУ находится до NAT, соединение застревает в фазе established, поскольку FIN/RST от клиента после блокировки до NAT уже не доходит. И эта фаза самая долгая по таймауту.
Очень долгая.
В linux вот такая : net.netfilter.nf_conntrack_tcp_timeout_established = 432000
5 суток
В провайдерском CGNAT вряд ли так долго, но все равно долго.
В отличие от UDP, где обычно за 5 минут уже все заканчивается.
Но еще шлет инфу сервер. Обычно он не может пропихнуть TLS Server Hello. Значит будут идти ретрансмиссии с прогрессивно увеличивающейся задержкой, пока tcp/ip стек серверной ОС не сдастся (а это может быть тоже очень долго), либо не настанет таймаут на уровне серверного приложения (видится намного короче, но все равно не 10 секунд). И только после FIN/RST от сервера conntrack переводится в состояние закрытия.
Если же ТСПУ после NAT, то NAT видит FIN/RST от клиента и переводит свой conntrack в состояние закрытия сразу после того, как клиент закрыл tcp сокет. ОС шлет FIN/RST, соединение уходит в закрытие, где таймаут значительно ниже
Таким образом вариант, где ТСПУ находится после NAT, склонен быстрее освобождать соединения, чем вариант ТСПУ до NAT. Но все равно не прям чтобы критически дольше. Простая проверка разных https серверов телнетом на 443 порт показывает, что обычно в течение минуты сервер уже тебя сбрасывает. Но на клиенте это происходит через 2 секунды - таймаут curl по умолчанию в блокчеке
Но есть еще 3-й вариант. ТСПУ может быть несколько на пути. 1 до NAT, другой после NAT. И если они оба резанут, то будет то самое “5 суток”. Кроме ТСПУ есть еще собственные DPI провайдера. Если оба режут TCP сеанс полностью без RST, это тоже самое.
Все мы знаем, что ТСПУ есть и на магистралах. Может на ростелеке сложились звезды именно так
Так что версия вполне реальная. Наверняка у всех тестеров не было внешнего IP. Верно ?
Я бы так это проверил. Перед тестом ставим бесконечную пингалку. Пинг создась mapping в NAT, который будет поддерживаться постоянными пингами. Посмотреть не прекратились ли пинги после “отвала инета”
Напрашивается какой-то постоянный конфиг для блокчека, с флагами, какие ветки вариаций заведомо не проверять или делать quick, а где искать force. Т.к. действительно полный перебор - это очень долго и обычно не нужно, кроме первого раза. Хотя тоже палка о двух концах, у меня он иногда выдаёт неожиданные стратегии.
Не знаю что за магия, но в zapret v71 всё летает просто с --dup-autottl. Даже когда ночью глушилки врубают - всё так же продолжает работать. Может только небольшая задержка появляется (~1 сек.) при открытии запрещёночки. Это на Ростелекоме, Ярославль.
dup работает и по udp, но непонятно чего вы этим добьетесь.
1 сек для мд5 убирается подбором dup-ttl или dup-autottl, чтобы доходило до дпи, но не до сервера. только на syn, иначе можно отлететь на ттл защите
для линух клиентов нужен дроп ицмп тайм эксидед, иначе сокет закрывается системой
У нас 1 ТСПУ до NAT - и два после - на четвертом и шестом хопе .По крайней мере так мне объяснили. За достоверность не ручаюсь. До всей этой котовасии пробивалось с -ttl 7. ТСПУ до NAT поставили с начала мая этого года. И начались проблемы с GBDPI и работоспособностью трубы. Проходила инфа ,что до осени всех провайдеров обязательно заставят установить доп.коробку до NAT. Зачем не знаю.У вас есть версии ? За инсайд не ручаюсь, но до этого инфа от источника по срокам обновления ПО коробок нашего прова и т.д. подтверждалась.
Наверняка у всех тестеров не было внешнего IP. Верно ?
Абсолютно верно.
Посмотреть не прекратились ли пинги после “отвала инета”
Пинги идут и после отвала . И что это значит ? В свое время , пингалка помогала подключаться варпу , и псифону , и вроде open vpn так советовали на форумах линуксоидов и это работало до октября 2024. Во всей этой истории удивляет что при подключении НОВОГО (не засветившегося в тестировании чекером) оборудования , в данной ситуации роутера , тестирование может идти успешно и до часа с лишним , а потом уже всегда повторяется описанный мной выше сценарий , такое впечатление , что ТСПУ или еще что вносит адрес оборудования клиента с которого идут запросы в некий лист , типа с оборудования подменяются пакеты и на те временный бан для охлаждения , чтобы не повадно было . Может такое быть на ваш взгляд ? У меня есть еще версия ,что когда стали активно рубить фейки на тспу , для пробива в стратегиях стали использовать множественные пакеты фейков , и возможно тспу рубит соединение принимая за мощную атаку фейками ?
C GDPI начались блокировки еще давно. У знакомого он уже в октябре не работал. Имеются ли динамические блокировки? Возможно. Но почему бы не перйти на zapret? Вероятно GDPI легко детектить
Выше я описал ситуацию с перебором стратегий для GBDPI и Zapret в т.ч. и что при этом происходит на нашем провайдере. Zapret , YTBystro , на данный момент работают и выполняют свои функции на моем прове ) Причем “из коробки” и старые версии. Я просто хотел чекером подготовить себе как можно больше разных рабочих стратегий , но попал на проблему описанную выше )
То что описывайте вы называется динамические блокировки. Что то подобное описывали тут еще год назадю но там закрывали доступ к какому то ресурсу а не отрубали интернет полностью.
Но дождемся bolvan может он обяснит подробнее
я, как и вы, не работаю в ркн и не знаю что они там творят
перед нат коробка - тут все понятно
ближе к кому ставят - от того и защищаются
видимо они хотят точечно действовать по подозрительным юзерам. после нат это невозможно.
еще они наверняка будут знать, что работают по юзерам, а не по техническим железякам и не по крупному бизнесу
юзеров не жалко
если пинги идут, можно еще тест сделать
до блокчека соединиться по персистент тцп конекшин с другим адресом. это может быть пара неткатов или ссш
добить инет блокчеком
если тцп сеанс не помер, то очень похоже на исчерпание нат лимита
старые конекты живы, новые не работают
Возможно глупый вопрос, но все же. Сегодня заметил что во время прогона блокчекером падал инет. Соединение обрывалось на 3-5 минут, затем все восстанавливалось. Начинал снова прогон, где то 10-15 минут сканирования - снова падает инет. В общем случилось такое 3 раза подряд и я это дело делать перестал. Весь остальной день интернет работает стабильно. Прогонял блокчекером для windows. Возможно ли что провайдер(тспу) детектит прогон и обрубает интернет? Или это было глюки провайдера/маршрутизатора, т.е просто совпадение.
полное отрубание инета это не динамические блокировки. динамические блокировки это когда ты идешь на ресурс и по времени тебя коррелируют и только потом отрубают доступ к этому ресурсу.
у меня такие блокировки уже давно, zapret как раз от них очень хорошо защищает потому что для тспу машины становится невозможно коррелировать когда там одни фейки
